From: Chintan Vankar <[email protected]>
Change offset in mux-reg-masks property for serdes_ln_ctrl node
since reg-mux property is used in compatible.
Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
Signed-off-by: Chintan Vankar <[email protected]>
Acked-by: Andrew Davis <[email protected]>
Signed-off-by: Siddharth Vadapalli <[email protected]>
---
Hello,
This patch is based on linux-next tagged next-20240213.
The v4 of this patch is a part of the series at:
https://lore.kernel.org/r/[email protected]/
Since the v4 series mentioned above has open comments on the other
patches in the series, this patch is being posted separately to unblock
other dependent series which rely on the fix implemented by this patch.
Changes since v4:
- Rebased patch on linux-next tagged next-20240213.
Regards,
Siddharth.
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 3cb964982792..3b7f0eca977b 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 {
compatible = "reg-mux";
reg = <0x00004080 0x30>;
#mux-control-cells = <1>;
- mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
- <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */
- <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
- <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */
- <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
- <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */
+ mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */
+ <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */
+ <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */
+ <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */
+ <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */
+ <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */
idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
<J784S4_SERDES0_LANE1_PCIE1_LANE1>,
<J784S4_SERDES0_LANE2_IP3_UNUSED>,
--
2.34.1
Hi!
2024-02-13 at 09:03, Siddharth Vadapalli wrote:
> From: Chintan Vankar <[email protected]>
>
> Change offset in mux-reg-masks property for serdes_ln_ctrl node
> since reg-mux property is used in compatible.
>
> Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
> Signed-off-by: Chintan Vankar <[email protected]>
> Acked-by: Andrew Davis <[email protected]>
> Signed-off-by: Siddharth Vadapalli <[email protected]>
> ---
> Hello,
>
> This patch is based on linux-next tagged next-20240213.
> The v4 of this patch is a part of the series at:
> https://lore.kernel.org/r/[email protected]/
>
> Since the v4 series mentioned above has open comments on the other
> patches in the series, this patch is being posted separately to unblock
> other dependent series which rely on the fix implemented by this patch.
>
> Changes since v4:
> - Rebased patch on linux-next tagged next-20240213.
>
> Regards,
> Siddharth.
>
> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 3cb964982792..3b7f0eca977b 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 {
> compatible = "reg-mux";
> reg = <0x00004080 0x30>;
> #mux-control-cells = <1>;
> - mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
> - <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */
> - <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
> - <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */
> - <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
> - <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */
> + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */
> + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */
> + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */
> + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */
> + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */
> + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */
> idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
> <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
> <J784S4_SERDES0_LANE2_IP3_UNUSED>,
Ouch. I suspect there is a similar problem in
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:
fss: bus@47000000 {
compatible = "simple-bus";
reg = <0x0 0x47000000 0x0 0x100>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
hbmc_mux: mux-controller@47000004 {
compatible = "reg-mux";
reg = <0x00 0x47000004 0x00 0x2>;
#mux-control-cells = <1>;
- mux-reg-masks = <0x4 0x2>; /* HBMC select */
+ mux-reg-masks = <0x0 0x2>; /* HBMC select */
};
Who knows what non-upstreamed devices and devicetrees are affected?
I guess we need to revert 2765149273f4 ("mux: mmio: use reg property
when parent device is not a syscon") unless someone sees a sane way
to fix this.
Cheers,
Peter
On 2/13/24 3:19 AM, Peter Rosin wrote:
> Hi!
>
> 2024-02-13 at 09:03, Siddharth Vadapalli wrote:
>> From: Chintan Vankar <[email protected]>
>>
>> Change offset in mux-reg-masks property for serdes_ln_ctrl node
>> since reg-mux property is used in compatible.
>>
>> Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
>> Signed-off-by: Chintan Vankar <[email protected]>
>> Acked-by: Andrew Davis <[email protected]>
>> Signed-off-by: Siddharth Vadapalli <[email protected]>
>> ---
>> Hello,
>>
>> This patch is based on linux-next tagged next-20240213.
>> The v4 of this patch is a part of the series at:
>> https://lore.kernel.org/r/[email protected]/
>>
>> Since the v4 series mentioned above has open comments on the other
>> patches in the series, this patch is being posted separately to unblock
>> other dependent series which rely on the fix implemented by this patch.
>>
>> Changes since v4:
>> - Rebased patch on linux-next tagged next-20240213.
>>
>> Regards,
>> Siddharth.
>>
>> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> index 3cb964982792..3b7f0eca977b 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 {
>> compatible = "reg-mux";
>> reg = <0x00004080 0x30>;
>> #mux-control-cells = <1>;
>> - mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
>> - <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */
>> - <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
>> - <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */
>> - <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
>> - <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */
>> + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */
>> + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */
>> + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */
>> + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */
>> + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */
>> + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */
>> idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
>> <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
>> <J784S4_SERDES0_LANE2_IP3_UNUSED>,
>
> Ouch. I suspect there is a similar problem in
> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:
>
>
> fss: bus@47000000 {
> compatible = "simple-bus";
> reg = <0x0 0x47000000 0x0 0x100>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> hbmc_mux: mux-controller@47000004 {
> compatible = "reg-mux";
> reg = <0x00 0x47000004 0x00 0x2>;
> #mux-control-cells = <1>;
> - mux-reg-masks = <0x4 0x2>; /* HBMC select */
> + mux-reg-masks = <0x0 0x2>; /* HBMC select */
> };
>
> Who knows what non-upstreamed devices and devicetrees are affected?
> I guess we need to revert 2765149273f4 ("mux: mmio: use reg property
> when parent device is not a syscon") unless someone sees a sane way
> to fix this.
There are only two in-tree nodes with "reg-mux" with a reg property: the
one this patch fixes, and the hbmc_mux you point out, both in TI devices.
I'd say it is safe to assume we are the only users, and our non-upstreamed
DTs depend on that patch, reverting it would cause more issues for
out-of-tree users than just fixing the two broken nodes above.
Andrew
>
> Cheers,
> Peter
On 24/02/13 11:08AM, Andrew Davis wrote:
> On 2/13/24 3:19 AM, Peter Rosin wrote:
> > Hi!
> >
> > 2024-02-13 at 09:03, Siddharth Vadapalli wrote:
> > > From: Chintan Vankar <[email protected]>
> > >
> > > Change offset in mux-reg-masks property for serdes_ln_ctrl node
> > > since reg-mux property is used in compatible.
> > >
> > > Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
> > > Signed-off-by: Chintan Vankar <[email protected]>
> > > Acked-by: Andrew Davis <[email protected]>
> > > Signed-off-by: Siddharth Vadapalli <[email protected]>
> > > ---
..
> > > + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */
> > > + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */
> > > + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */
> > > + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */
> > > + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */
> > > + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */
> > > idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
> > > <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
> > > <J784S4_SERDES0_LANE2_IP3_UNUSED>,
> >
> > Ouch. I suspect there is a similar problem in
> > arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:
> >
> >
> > fss: bus@47000000 {
> > compatible = "simple-bus";
> > reg = <0x0 0x47000000 0x0 0x100>;
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> >
> > hbmc_mux: mux-controller@47000004 {
> > compatible = "reg-mux";
> > reg = <0x00 0x47000004 0x00 0x2>;
> > #mux-control-cells = <1>;
> > - mux-reg-masks = <0x4 0x2>; /* HBMC select */
> > + mux-reg-masks = <0x0 0x2>; /* HBMC select */
> > };
> >
> > Who knows what non-upstreamed devices and devicetrees are affected?
> > I guess we need to revert 2765149273f4 ("mux: mmio: use reg property
> > when parent device is not a syscon") unless someone sees a sane way
> > to fix this.
>
> There are only two in-tree nodes with "reg-mux" with a reg property: the
> one this patch fixes, and the hbmc_mux you point out, both in TI devices.
> I'd say it is safe to assume we are the only users, and our non-upstreamed
> DTs depend on that patch, reverting it would cause more issues for
> out-of-tree users than just fixing the two broken nodes above.
Peter,
Is it alright for this patch to be merged, given Andrew's response above?
The problem with "hbmc_mux" node that you pointed out above could be fixed
by another patch. Please let me know.
Regards,
Siddharth.
On 2/15/24 10:56 PM, Siddharth Vadapalli wrote:
> On 24/02/13 11:08AM, Andrew Davis wrote:
>> On 2/13/24 3:19 AM, Peter Rosin wrote:
>>> Hi!
>>>
>>> 2024-02-13 at 09:03, Siddharth Vadapalli wrote:
>>>> From: Chintan Vankar <[email protected]>
>>>>
>>>> Change offset in mux-reg-masks property for serdes_ln_ctrl node
>>>> since reg-mux property is used in compatible.
>>>>
>>>> Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
>>>> Signed-off-by: Chintan Vankar <[email protected]>
>>>> Acked-by: Andrew Davis <[email protected]>
>>>> Signed-off-by: Siddharth Vadapalli <[email protected]>
>>>> ---
> ...
>
>>>> + mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */
>>>> + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */
>>>> + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */
>>>> + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */
>>>> + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */
>>>> + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */
>>>> idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
>>>> <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
>>>> <J784S4_SERDES0_LANE2_IP3_UNUSED>,
>>>
>>> Ouch. I suspect there is a similar problem in
>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:
>>>
>>>
>>> fss: bus@47000000 {
>>> compatible = "simple-bus";
>>> reg = <0x0 0x47000000 0x0 0x100>;
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>> ranges;
>>>
>>> hbmc_mux: mux-controller@47000004 {
>>> compatible = "reg-mux";
>>> reg = <0x00 0x47000004 0x00 0x2>;
>>> #mux-control-cells = <1>;
>>> - mux-reg-masks = <0x4 0x2>; /* HBMC select */
>>> + mux-reg-masks = <0x0 0x2>; /* HBMC select */
>>> };
>>>
>>> Who knows what non-upstreamed devices and devicetrees are affected?
>>> I guess we need to revert 2765149273f4 ("mux: mmio: use reg property
>>> when parent device is not a syscon") unless someone sees a sane way
>>> to fix this.
>>
>> There are only two in-tree nodes with "reg-mux" with a reg property: the
>> one this patch fixes, and the hbmc_mux you point out, both in TI devices.
>> I'd say it is safe to assume we are the only users, and our non-upstreamed
>> DTs depend on that patch, reverting it would cause more issues for
>> out-of-tree users than just fixing the two broken nodes above.
>
> Peter,
>
> Is it alright for this patch to be merged, given Andrew's response above?
> The problem with "hbmc_mux" node that you pointed out above could be fixed
> by another patch. Please let me know.
The hbmc_mux fix is now also posted:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
Andrew
>
> Regards,
> Siddharth.
Hi Siddharth Vadapalli,
On Tue, 13 Feb 2024 13:33:48 +0530, Siddharth Vadapalli wrote:
> Change offset in mux-reg-masks property for serdes_ln_ctrl node
> since reg-mux property is used in compatible.
>
>
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl
commit: 9a0c0a9baa2d1f906589d715f9baeab93e7fcdcb
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Vignesh