| Message ID | D200DC520B462771+20240909074645.1161554-1-wangyuli@uniontech.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [6.6,1/4] riscv: dts: starfive: add assigned-clock* to limit frquency | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
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 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
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.
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;