From: William Qiu william.qiu@starfivetech.com
In JH7110 SoC, we need to go by-pass mode, so we need add the assigned-clock* properties to limit clock frquency.
Signed-off-by: William Qiu william.qiu@starfivetech.com Reviewed-by: Emil Renner Berthing emil.renner.berthing@canonical.com Signed-off-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: WangYuli wangyuli@uniontech.com --- .../riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi index 062b97c6e7df..4874e3bb42ab 100644 --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi @@ -204,6 +204,8 @@ &i2c6 {
&mmc0 { max-frequency = <100000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_SDIO0_SDCARD>; + assigned-clock-rates = <50000000>; bus-width = <8>; cap-mmc-highspeed; mmc-ddr-1_8v; @@ -220,6 +222,8 @@ &mmc0 {
&mmc1 { max-frequency = <100000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_SDIO1_SDCARD>; + assigned-clock-rates = <50000000>; bus-width = <4>; no-sdio; no-mmc;
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opti...
Rule: The upstream commit ID must be specified with a separate line above the commit text. Subject: [PATCH 6.6 1/4] riscv: dts: starfive: add assigned-clock* to limit frquency Link: https://lore.kernel.org/stable/D200DC520B462771%2B20240909074645.1161554-1-w...
Please ignore this mail if the patch is not relevant for upstream.
On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
From: William Qiu william.qiu@starfivetech.com
In JH7110 SoC, we need to go by-pass mode, so we need add the assigned-clock* properties to limit clock frquency.
Signed-off-by: William Qiu william.qiu@starfivetech.com Reviewed-by: Emil Renner Berthing emil.renner.berthing@canonical.com Signed-off-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: WangYuli wangyuli@uniontech.com
What makes any of the patches in this 4 patch series stable material?
Confused, Conor.
On 09/09/2024 12:17, Conor Dooley wrote:
On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
From: William Qiu william.qiu@starfivetech.com
In JH7110 SoC, we need to go by-pass mode, so we need add the assigned-clock* properties to limit clock frquency.
Signed-off-by: William Qiu william.qiu@starfivetech.com Reviewed-by: Emil Renner Berthing emil.renner.berthing@canonical.com Signed-off-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: WangYuli wangyuli@uniontech.com
What makes any of the patches in this 4 patch series stable material?
That's for stable? It needs to follow stable process rules, so proper commit ID.
Best regards, Krzysztof
On Mon, Sep 09, 2024 at 12:38:23PM +0200, Krzysztof Kozlowski wrote:
On 09/09/2024 12:17, Conor Dooley wrote:
On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
From: William Qiu william.qiu@starfivetech.com
In JH7110 SoC, we need to go by-pass mode, so we need add the assigned-clock* properties to limit clock frquency.
Signed-off-by: William Qiu william.qiu@starfivetech.com Reviewed-by: Emil Renner Berthing emil.renner.berthing@canonical.com Signed-off-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: WangYuli wangyuli@uniontech.com
What makes any of the patches in this 4 patch series stable material?
That's for stable? It needs to follow stable process rules, so proper commit ID.
[6.6] in the subject and Sasha/Greg/stable list on CC, so I figure it is for stable, yeah. Only one of these patches is a "fix", and not really a functional one, so I would like to know why this stuff is being backported. I think under some definition of "new device IDs and quirks" it could be suitable, but it'd be a looser definition than I personally agree with!
Oh, and also, the 4 patches aren't threaded - you should fix that WangYuli.
On 2024/9/9 19:17, Conor Dooley wrote:
[6.6] in the subject and Sasha/Greg/stable list on CC, so I figure it is for stable, yeah. Only one of these patches is a "fix", and not really a functional one, so I would like to know why this stuff is being backported. I think under some definition of "new device IDs and quirks" it could be suitable, but it'd be a looser definition than I personally agree with!
These submissions will help to ensure a more stable behavior for the RISC-V devices involved on the Linux-6.6.y kernel,and as far as I can tell,they won't introduce any new issues (please correct me if I'm wrong).
Oh, and also, the 4 patches aren't threaded - you should fix that
I apologize for my ignorance about the correct procedure...
For instance,for these four commits,I first used 'git format-patch -4' to create four consecutive .patch files,and then used 'git send-email --annotate --cover-letter --thread ./*.patch' to send them,but the result wasn't as expected...
I'm not sure where the problem lies...
WangYuli.
QAQ
On Thu, Sep 12, 2024 at 10:38:20AM +0800, WangYuli wrote:
On 2024/9/9 19:17, Conor Dooley wrote:
[6.6] in the subject and Sasha/Greg/stable list on CC, so I figure it is for stable, yeah. Only one of these patches is a "fix", and not really a functional one, so I would like to know why this stuff is being backported. I think under some definition of "new device IDs and quirks" it could be suitable, but it'd be a looser definition than I personally agree with!
These submissions will help to ensure a more stable behavior for the RISC-V devices involved on the Linux-6.6.y kernel,
I'll accept that argument for the first patch, but the three that are adding support for audio devices on the platform cannot really be described as making behaviour more stable. I don't hugely object to these being backported, but I would like a more accurate justification for it being done - even if that is just that "we are using this board with 6.6 and would like audio to work, which these 3 simple patches allow it to do".
and as far as I can tell,they won't introduce any new issues (please correct me if I'm wrong).
I don't know. Does this first patch require a driver change for the mmc driver to work correctly?
Oh, and also, the 4 patches aren't threaded - you should fix that
I apologize for my ignorance about the correct procedure...
For instance,for these four commits,I first used 'git format-patch -4' to create four consecutive .patch files,and then used 'git send-email --annotate --cover-letter --thread ./*.patch' to send them,but the result wasn't as expected...
I'm not sure where the problem lies...
I'm not sure, I don't send patches using that method. Usually I output my patches to a directory and call git send-email using the path to that directory.
Cheers, Conor.
On Mon, Sep 09, 2024 at 03:46:27PM +0800, WangYuli wrote:
From: William Qiu william.qiu@starfivetech.com
In JH7110 SoC, we need to go by-pass mode, so we need add the assigned-clock* properties to limit clock frquency.
Signed-off-by: William Qiu william.qiu@starfivetech.com Reviewed-by: Emil Renner Berthing emil.renner.berthing@canonical.com Signed-off-by: Conor Dooley conor.dooley@microchip.com Signed-off-by: WangYuli wangyuli@uniontech.com
.../riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
What is the git id of this change in Linus's tree?
Please fix this up and resend all 4 patches with the needed information.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Conor Dooley -
Greg KH -
kernel test robot -
Krzysztof Kozlowski -
WangYuli