* [RFC PATCH net-next 02/22] net: dsa: mt7530: use p5_interface_select as data type for p5_intf_sel
From: arinc9.unal @ 2023-04-21 14:36 UTC (permalink / raw)
To: Sean Wang, Landen Chao, DENG Qingfang, Daniel Golle, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King
Cc: Arınç ÜNAL, Richard van Schagen,
Richard van Schagen, Frank Wunderlich, erkin.bozoglu, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20230421143648.87889-1-arinc.unal@arinc9.com>
From: Arınç ÜNAL <arinc.unal@arinc9.com>
Use the p5_interface_select enumeration as the data type for the
p5_intf_sel field. This ensures p5_intf_sel can only take the values
defined in the p5_interface_select enumeration.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
drivers/net/dsa/mt7530.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 845f5dd16d83..703f8a528317 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -674,13 +674,13 @@ struct mt7530_port {
};
/* Port 5 interface select definitions */
-enum p5_interface_select {
- P5_DISABLED = 0,
+typedef enum {
+ P5_DISABLED,
P5_INTF_SEL_PHY_P0,
P5_INTF_SEL_PHY_P4,
P5_INTF_SEL_GMAC5,
P5_INTF_SEL_GMAC5_SGMII,
-};
+} p5_interface_select;
struct mt7530_priv;
@@ -768,7 +768,7 @@ struct mt7530_priv {
bool mcm;
phy_interface_t p6_interface;
phy_interface_t p5_interface;
- unsigned int p5_intf_sel;
+ p5_interface_select p5_intf_sel;
u8 mirror_rx;
u8 mirror_tx;
struct mt7530_port ports[MT7530_NUM_PORTS];
--
2.37.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH net-next 01/22] net: dsa: mt7530: add missing @p5_interface to mt7530_priv description
From: arinc9.unal @ 2023-04-21 14:36 UTC (permalink / raw)
To: Sean Wang, Landen Chao, DENG Qingfang, Daniel Golle, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King
Cc: Arınç ÜNAL, Richard van Schagen,
Richard van Schagen, Frank Wunderlich, erkin.bozoglu, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20230421143648.87889-1-arinc.unal@arinc9.com>
From: Arınç ÜNAL <arinc.unal@arinc9.com>
Add the missing p5_interface field to the mt7530_priv description. Sort out
the description in the process.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
drivers/net/dsa/mt7530.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 5084f48a8869..845f5dd16d83 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -746,7 +746,8 @@ struct mt753x_info {
* @ports: Holding the state among ports
* @reg_mutex: The lock for protecting among process accessing
* registers
- * @p6_interface Holding the current port 6 interface
+ * @p6_interface: Holding the current port 6 interface
+ * @p5_interface: Holding the current port 5 interface
* @p5_intf_sel: Holding the current port 5 interface select
* @irq: IRQ number of the switch
* @irq_domain: IRQ domain of the switch irq_chip
--
2.37.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH net-next 00/22] net: dsa: MT7530, MT7531, and MT7988 improvements
From: arinc9.unal @ 2023-04-21 14:36 UTC (permalink / raw)
To: Sean Wang, Landen Chao, DENG Qingfang, Daniel Golle, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King
Cc: Richard van Schagen, Richard van Schagen, Frank Wunderlich,
erkin.bozoglu, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
Hello!
This patch series is focused on simplifying the code, and improving the
logic of the support for MT7530, MT7531, and MT7988 SoC switches.
There's also a fix for the switch on the MT7988 SoC.
Daniel, can you test this series on the MT7531 and MT7988 SoC switch?
The only missing piece to properly support multiple ports as CPU ports is
the fixes [0] [1] [2] from Richard.
I've got questions regarding patch 13 and 19.
For patch 19:
Daniel, does the switch on the MT7988 SoC require the register to fire
interrupts properly? The code uses an inclusive check which was untouched
when the MT7988 SoC switch support was added.
For patch 13:
Do I need to protect the register from being accessed by processes while
this operation is being done? I don't see this on mt7530_setup() but it's
being done on mt7530_setup_port5().
I have very thoroughly tested the patch series with every possible
configuration on the MCM and standalone MT7530 switch. I'll let the name of
the dtb files speak for themselves.
MT7621 Unielec:
only-gmac0-mt7621-unielec-u7621-06-16m.dtb
rgmii-only-gmac0-mt7621-unielec-u7621-06-16m.dtb
only-gmac1-mt7621-unielec-u7621-06-16m.dtb
gmac0-and-gmac1-mt7621-unielec-u7621-06-16m.dtb
phy0-muxing-mt7621-unielec-u7621-06-16m.dtb
phy4-muxing-mt7621-unielec-u7621-06-16m.dtb
port5-as-user-mt7621-unielec-u7621-06-16m.dtb
tftpboot 0x80008000 mips-uzImage.bin; tftpboot 0x83000000 mips-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootm 0x80008000 0x83000000 0x83f00000
MT7623 Bananapi:
only-gmac0-mt7623n-bananapi-bpi-r2.dtb
rgmii-only-gmac0-mt7623n-bananapi-bpi-r2.dtb
only-gmac1-mt7623n-bananapi-bpi-r2.dtb
gmac0-and-gmac1-mt7623n-bananapi-bpi-r2.dtb
phy0-muxing-mt7623n-bananapi-bpi-r2.dtb
phy4-muxing-mt7623n-bananapi-bpi-r2.dtb
port5-as-user-mt7623n-bananapi-bpi-r2.dtb
tftpboot 0x80008000 arm-uImage; tftpboot 0x83000000 arm-rootfs.cpio.uboot; tftpboot 0x83f00000 $dtb; bootm 0x80008000 0x83000000 0x83f00000
[0] https://lore.kernel.org/netdev/20230212213949.672443-1-richard@routerhints.com/
[1] https://lore.kernel.org/netdev/20230212215152.673221-1-richard@routerhints.com/
[2] https://lore.kernel.org/netdev/20230212214027.672501-1-richard@routerhints.com/
Arınç
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] wifi: mt7601u: delete dead code checking debugfs returns
From: Jakub Kicinski @ 2023-04-21 14:28 UTC (permalink / raw)
To: Wang Jikai
Cc: Kalle Valo, David S. Miller, Eric Dumazet, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno,
hust-os-kernel-patches, linux-wireless, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20230421092200.24456-1-wangjikai@hust.edu.cn>
On Fri, 21 Apr 2023 09:22:00 +0000 Wang Jikai wrote:
> Smatch reports that:
> drivers/net/wireless/mediatek/mt7601u/debugfs.c:130
> mt7601u_init_debugfs() warn: 'dir' is an error pointer or valid".
>
> Debugfs code is not supposed to need error checking so instead of
> changing this to if (IS_ERR()) the correct thing is to just delete
> the dead code.
>
> Signed-off-by: Wang Jikai <wangjikai@hust.edu.cn>
Acked-by: Jakub Kicinski <kuba@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/22] net: thunderx: Use alloc_ordered_workqueue() to create ordered workqueues
From: Jakub Kicinski @ 2023-04-21 14:28 UTC (permalink / raw)
To: Tejun Heo
Cc: jiangshanlai, linux-kernel, kernel-team, Sunil Goutham,
David S. Miller, Eric Dumazet, Paolo Abeni, linux-arm-kernel,
netdev
In-Reply-To: <ZEKaABXSb-KppyMO@slm.duckdns.org>
On Fri, 21 Apr 2023 04:13:20 -1000 Tejun Heo wrote:
> On Fri, Apr 21, 2023 at 07:01:08AM -0700, Jakub Kicinski wrote:
> > On Thu, 20 Apr 2023 16:50:30 -1000 Tejun Heo wrote:
> > > Signed-off-by: Tejun Heo <tj@kernel.org>
> > > Cc: Sunil Goutham <sgoutham@marvell.com>
> > > Cc: "David S. Miller" <davem@davemloft.net>
> > > Cc: Eric Dumazet <edumazet@google.com>
> > > Cc: Jakub Kicinski <kuba@kernel.org>
> > > Cc: Paolo Abeni <pabeni@redhat.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Cc: netdev@vger.kernel.org
> >
> > You take this via your tree directly to Linus T?
>
> Yeah, that'd be my preference unless someone is really against it.
Acked-by: Jakub Kicinski <kuba@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: mediatek: Enable all MT8192 clocks by default
From: Nícolas F. R. A. Prado @ 2023-04-21 14:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
linux-kernel, linux-mediatek, linux-arm-kernel, linux-clk
In-Reply-To: <20230421111125.2397368-1-wenst@chromium.org>
On Fri, Apr 21, 2023 at 07:11:25PM +0800, Chen-Yu Tsai wrote:
> Currently the base MT8192 clock drivers are enabled by default, but all
> the other clock drivers need to be enabled by hand. This is extremely
> confusing and inconvenient for end users. For the MT8192 platform to be
> useful, most if not all the clock drivers driving the hardware blocks
> need to be enabled.
>
> Enable them by default whenever MT8192 base clock driver is enabled.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Thanks,
Nícolas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/22] net: thunderx: Use alloc_ordered_workqueue() to create ordered workqueues
From: Tejun Heo @ 2023-04-21 14:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: jiangshanlai, linux-kernel, kernel-team, Sunil Goutham,
David S. Miller, Eric Dumazet, Paolo Abeni, linux-arm-kernel,
netdev
In-Reply-To: <20230421070108.638cce01@kernel.org>
On Fri, Apr 21, 2023 at 07:01:08AM -0700, Jakub Kicinski wrote:
> On Thu, 20 Apr 2023 16:50:30 -1000 Tejun Heo wrote:
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Cc: Sunil Goutham <sgoutham@marvell.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Jakub Kicinski <kuba@kernel.org>
> > Cc: Paolo Abeni <pabeni@redhat.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: netdev@vger.kernel.org
>
> You take this via your tree directly to Linus T?
Yeah, that'd be my preference unless someone is really against it.
Thanks.
--
tejun
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] i2c: lpi2c: cache peripheral clock rate
From: Sverdlin, Alexander @ 2023-04-21 14:10 UTC (permalink / raw)
To: alexander.stein@ew.tq-group.com, linux-imx@nxp.com
Cc: kernel@pengutronix.de, s.hauer@pengutronix.de, festevam@gmail.com,
shawnguo@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
aisheng.dong@nxp.com
In-Reply-To: <9272339.EvYhyI6sBW@steina-w>
Hello Alexander,
thanks for looking into that!
On Fri, 2023-04-21 at 15:48 +0200, Alexander Stein wrote:
> Unfortuantely this was just hiding another call path from
> lpi2c_imx_xfer to
> clk_bulk_prepare. Here is my kernel log:
Yes, soon after publishing the patch I reproduced your log as well,
that's why I didn't follow up on the original patch, as it indeed
doesn't solve all the LOCKDEP splats with lpi2c involved and I didn't
have time to look into this yet.
> [ 22.264508] ======================================================
> [ 22.270697] WARNING: possible circular locking dependency detected
> [ 22.276893] 6.3.0-rc7-next-20230420+ #6 Not tainted
> [ 22.281782] ------------------------------------------------------
> [ 22.287968] kworker/2:3/93 is trying to acquire lock:
> [ 22.293034] ffff800009d38bf8 (prepare_lock){+.+.}-{3:3}, at:
> clk_prepare_lock+0x48/0x9c
> [ 22.301095]
> [ 22.301095] but task is already holding lock:
> [ 22.306942] ffff0000039ab100 (i2c_register_adapter){+.+.}-{3:3},
> at:
> i2c_adapter_lock_bus+0x20/0x2c
> [ 22.316046]
> [ 22.316046] which lock already depends on the new lock.
> [ 22.316046]
> [ 22.324238]
> [ 22.324238] the existing dependency chain (in reverse order) is:
> [ 22.331727]
> [ 22.331727] -> #2 (i2c_register_adapter){+.+.}-{3:3}:
> [ 22.338295] __lock_acquire+0x370/0x6e8
> [ 22.342674] lock_acquire.part.0+0xcc/0x208
> [ 22.347399] lock_acquire+0x94/0x14c
> [ 22.351509] rt_mutex_lock_nested+0x5c/0x98
> [ 22.356235] i2c_adapter_lock_bus+0x20/0x2c
> [ 22.360961] i2c_transfer+0x80/0x114
> [ 22.365069] regmap_i2c_read+0x5c/0xa0
> [ 22.369362] _regmap_raw_read+0x110/0x2dc
> [ 22.373905] _regmap_bus_read+0x40/0x74
> [ 22.378274] _regmap_read+0x74/0x248
> [ 22.382393] regmap_read+0x48/0x70
> [ 22.386337] pcf85063_probe+0xf0/0x4f4
> [ 22.390640] i2c_device_probe+0x100/0x2d4
> [ 22.395206] call_driver_probe+0x28/0x15c
> [ 22.399750] really_probe+0x180/0x320
> [ 22.403946] __driver_probe_device+0x84/0x144
> [ 22.408837] driver_probe_device+0x38/0x150
> [ 22.413554] __device_attach_driver+0xcc/0x194
> [ 22.418532] bus_for_each_drv+0x80/0xdc
> [ 22.422910] __device_attach+0xa8/0x1f8
> [ 22.426545] systemd-journald[128]: Oldest entry in
> /var/log/journal/
> e4579cc7db6747028247b9b859e132d6/system.joural is older than the
> configured
> file retention duration (1month), suggesting rotation.
> [ 22.427278] device_initial_probe+0x10/0x18
> [ 22.427290] bus_probe_device+0xa4/0xa8
> [ 22.427299] device_add+0x3b0/0x508
> [ 22.427311] device_register+0x1c/0x28
> [ 22.427323] i2c_new_client_device+0x1c8/0x2bc
> [ 22.427333] of_i2c_register_device+0xb4/0xdc
> [ 22.427344] of_i2c_register_devices+0x80/0x154
> [ 22.456329] systemd-journald[128]: /var/log/journal/
> e4579cc7db6747028247b9b859e132d6/system.journal: Journal heaer limits
> reached
> or header out-of-date, rotating.
> [ 22.458176] i2c_register_adapter+0x184/0x4c8
> [ 22.458202] __i2c_add_numbered_adapter+0x5c/0xa4
> [ 22.502097] i2c_add_adapter+0xa0/0xcc
> [ 22.502122] lpi2c_imx_probe+0x23c/0x350
> [ 22.502135] platform_probe+0x64/0xfc
> [ 22.502146] call_driver_probe+0x28/0x15c
> [ 22.502155] really_probe+0x180/0x320
> [ 22.502164] __driver_probe_device+0x84/0x144
> [ 22.502173] driver_probe_device+0x38/0x150
> [ 22.502182] __device_attach_driver+0xcc/0x194
> [ 22.502191] bus_for_each_drv+0x80/0xdc
> [ 22.502204] __device_attach+0xa8/0x1f8
> [ 22.502212] device_initial_probe+0x10/0x18
> [ 22.502222] bus_probe_device+0xa4/0xa8
> [ 22.502230] deferred_probe_work_func+0xa0/0xf0
> [ 22.502239] process_one_work+0x284/0x5b0
> [ 22.502252] worker_thread+0x68/0x39c
> [ 22.502263] kthread+0x104/0x108
> [ 22.502274] ret_from_fork+0x10/0x20
> [ 22.502286]
> [ 22.502286] -> #1 (rtc_pcf85063:594:(&config->regmap)-
> >lock){+.+.}-{3:3}:
> [ 22.502310] __lock_acquire+0x370/0x6e8
> [ 22.502322] lock_acquire.part.0+0xcc/0x208
> [ 22.502332] lock_acquire+0x94/0x14c
> [ 22.502341] __mutex_lock+0x9c/0x838
> [ 22.502353] mutex_lock_nested+0x20/0x28
> [ 22.502364] regmap_lock_mutex+0x10/0x18
> [ 22.502377] regmap_read+0x38/0x70
> [ 22.502389] pcf85063_clkout_recalc_rate+0x2c/0x78
> [ 22.502403] __clk_core_init+0x46c/0x4e0
> [ 22.502417] __clk_register+0x160/0x23c
> [ 22.502429] devm_clk_register+0x58/0xb4
> [ 22.502441] pcf85063_probe+0x238/0x4f4
> [ 22.502451] i2c_device_probe+0x100/0x2d4
> [ 22.502465] call_driver_probe+0x28/0x15c
> [ 22.502473] really_probe+0x180/0x320
> [ 22.502482] __driver_probe_device+0x84/0x144
> [ 22.502491] driver_probe_device+0x38/0x150
> [ 22.502500] __device_attach_driver+0xcc/0x194
> [ 22.502509] bus_for_each_drv+0x80/0xdc
> [ 22.502521] __device_attach+0xa8/0x1f8
> [ 22.502530] device_initial_probe+0x10/0x18
> [ 22.502539] bus_probe_device+0xa4/0xa8
> [ 22.502548] device_add+0x3b0/0x508
> [ 22.502559] device_register+0x1c/0x28
> [ 22.502570] i2c_new_client_device+0x1c8/0x2bc
> [ 22.502580] of_i2c_register_device+0xb4/0xdc
> [ OK ] Started Network Time Synchronization[ 22.502589]
> of_i2c_register_devices+0x80/0x154
> .[ 22.502599] i2c_register_adapter+0x184/0x4c8
>
> [ 22.502607] __i2c_add_numbered_adapter+0x5c/0xa4
> [ 22.502616] i2c_add_adapter+0xa0/0xcc
> [ 22.502624] lpi2c_imx_probe+0x23c/0x350
> [ 22.502636] platform_probe+0x64/0xfc
> [ 22.502646] call_driver_probe+0x28/0x15c
> [ 22.502655] really_probe+0x180/0x320
> [ 22.502663] __driver_probe_device+0x84/0x144
> [ 22.502672] driver_probe_device+0x38/0x150
> [ 22.502681] __device_attach_driver+0xcc/0x194
> [ 22.502690] bus_for_each_drv+0x80/0xdc
> [ 22.502702] __device_attach+0xa8/0x1f8
> [ 22.502711] device_initial_probe+0x10/0x18
> [ 22.502720] bus_probe_device+0xa4/0xa8
> [ 22.502729] deferred_probe_work_func+0xa0/0xf0
> [ 22.502738] process_one_work+0x284/0x5b0
> [ 22.502749] worker_thread+0x68/0x39c
> [ 22.502760] kthread+0x104/0x108
> [ 22.502770] ret_from_fork+0x10/0x20
> [ 22.502779]
> [ 22.502779] -> #0 (prepare_lock){+.+.}-{3:3}:
> [ 22.502799] check_prev_add+0xb0/0xc80
> [ 22.502809] validate_chain+0x444/0x510
> [ 22.502818] __lock_acquire+0x370/0x6e8
> [ 22.502827] lock_acquire.part.0+0xcc/0x208
> [ 22.502837] lock_acquire+0x94/0x14c
> [ 22.502846] __mutex_lock+0x9c/0x838
> [ 22.502857] mutex_lock_nested+0x20/0x28
> [ 22.502867] clk_prepare_lock+0x48/0x9c
> [ 22.502878] clk_prepare+0x1c/0x3c
> [ 22.502890] clk_bulk_prepare+0x48/0xcc
> [ 22.502899] lpi2c_runtime_resume+0x30/0x84
> [ 22.502910] pm_generic_runtime_resume+0x28/0x3c
> [ 22.502923] __genpd_runtime_resume+0x2c/0xa0
> [ 22.502935] genpd_runtime_resume+0xbc/0x308
> [ 22.502944] __rpm_callback+0x44/0x19c
> [ 22.502953] rpm_callback+0x64/0x70
> [ 22.502962] rpm_resume+0x438/0x6d8
> [ 22.502970] __pm_runtime_resume+0x54/0xb0
> [ 22.502978] lpi2c_imx_master_enable+0x24/0x128
> [ 22.502989] lpi2c_imx_xfer+0x2c/0x3c8
> [ 22.502999] __i2c_transfer+0xe4/0x5a0
> [ 22.503008] i2c_transfer+0x90/0x114
> [ 22.503016] i2c_transfer_buffer_flags+0x58/0x84
> [ 22.503025] regmap_i2c_write+0x1c/0x4c
> [ 22.503035] _regmap_raw_write_impl+0x7dc/0x944
> [ 22.503044] _regmap_bus_raw_write+0x5c/0x74
> [ 22.503052] _regmap_write+0x64/0x238
> [ 22.503060] _regmap_update_bits+0x100/0x11c
> [ 22.503069] regmap_update_bits_base+0x60/0x90
> [ 22.503077] pca953x_gpio_set_value+0x74/0x90
> [ 22.503088] gpiod_set_raw_value_commit+0x6c/0x7c
> [ 22.503098] gpiod_set_value_nocheck+0x68/0x70
> [ 22.503107] gpiod_set_value_cansleep+0x3c/0xa8
> [ 22.503116] gpio_led_set_blocking+0x54/0x7c
> [ 22.503128] set_brightness_delayed+0x90/0xd8
> [ 22.503138] process_one_work+0x284/0x5b0
> [ 22.503149] worker_thread+0x68/0x39c
> [ 22.503160] kthread+0x104/0x108
> [ 22.503169] ret_from_fork+0x10/0x20
> [ 22.503179]
> [ 22.503179] other info that might help us debug this:
> [ 22.503179]
> [ 22.503183] Chain exists of:
> [ 22.503183] prepare_lock --> rtc_pcf85063:594:(&config->regmap)-
> >lock -->
> i2c_register_adapter
> [ 22.503183]
> [ 22.503207] Possible unsafe locking scenario:
> [ 22.503207]
> [ 22.503210] CPU0 CPU1
> [ 22.503213] ---- ----
> [ 22.503216] lock(i2c_register_adapter);
> [ 22.503225]
> lock(rtc_pcf85063:594:(&config-
> > regmap)->lock);
> [ 22.503235]
> lock(i2c_register_adapter);
> [ 22.503244] lock(prepare_lock);
> [ 22.503253]
> [ 22.503253] *** DEADLOCK ***
>
> Now lpi2c_runtime_resume will call into clk_prepare() which also
> calls
> clk_prepare_lock() (identical to clk_get_rate).
--
Alexander Sverdlin
Siemens AG
www.siemens.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8192-asurada-hayato: Enable Bluetooth
From: Nícolas F. R. A. Prado @ 2023-04-21 14:01 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, devicetree,
linux-kernel, linux-mediatek, linux-arm-kernel, Rob Herring,
Krzysztof Kozlowski
In-Reply-To: <20230421110327.2395804-1-wenst@chromium.org>
On Fri, Apr 21, 2023 at 07:03:27PM +0800, Chen-Yu Tsai wrote:
> Hayato's Realtek WiFi/BT module has it's Bluetooth function wired to
> UART1.
>
> Add and enable the relevant device nodes for it.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> .../dts/mediatek/mt8192-asurada-hayato-r1.dts | 80 +++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts b/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts
> index 43a823990a92..6a7d7870525b 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts
> @@ -40,9 +40,89 @@ CROS_STD_MAIN_KEYMAP
> >;
> };
>
> +&pio {
> + bt_pins: bt-pins {
> + bt_kill: pins-bt-kill {
Drop this label and for the other pinconfigs below as they'll never be
referenced.
> + pinmux = <PINMUX_GPIO144__FUNC_GPIO144>; /* BT_KILL_L */
I'd also drop this and the other comments, as they're already documented in the
gpio-line-names property.
> + output-low;
> + };
> +
> + bt_wake: pins-bt-wake {
> + pinmux = <PINMUX_GPIO22__FUNC_GPIO22>; /* bt to wake ap */
> + bias-pull-up;
> + };
> +
> + ap_wake_bt: pins-ap-wake-bt {
> + pinmux = <PINMUX_GPIO168__FUNC_GPIO168>; /* AP_WAKE_BT_H */
> + output-low;
> + };
> + };
> +
> + uart1_pins: uart1-pins {
> + pins-rx {
> + pinmux = <PINMUX_GPIO94__FUNC_URXD1>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + pins-tx {
> + pinmux = <PINMUX_GPIO95__FUNC_UTXD1>;
> + };
> +
> + pins-cts {
> + pinmux = <PINMUX_GPIO166__FUNC_UCTS1>;
> + input-enable;
> + };
> +
> + pins-rts {
> + pinmux = <PINMUX_GPIO167__FUNC_URTS1>;
> + output-enable;
Looks like the dt-binding doesn't currently support output-enable, but the
driver does, so please just add a patch with
output-enable: true
on mediatek,mt8192-pinctrl.yaml
> + };
> + };
> +
> + uart1_pins_sleep: uart1-pins-sleep {
"-pins" needs to come last in the name otherwise the dt-binding will complain.
> + pins-rx {
> + pinmux = <PINMUX_GPIO94__FUNC_GPIO94>;
> + input-enable;
> + bias-pull-up;
> + };
> + pins-tx {
> + pinmux = <PINMUX_GPIO95__FUNC_UTXD1>;
> + };
> + pins-cts {
> + pinmux = <PINMUX_GPIO166__FUNC_UCTS1>;
> + input-enable;
> + };
> + pins-rts {
> + pinmux = <PINMUX_GPIO167__FUNC_URTS1>;
> + output-enable;
> + };
> + };
> +};
> +
> &touchscreen {
> compatible = "hid-over-i2c";
> post-power-on-delay-ms = <10>;
> hid-descr-addr = <0x0001>;
> vdd-supply = <&pp3300_u>;
> };
> +
> +&uart1 {
> + status = "okay";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&uart1_pins>;
> + pinctrl-1 = <&uart1_pins_sleep>;
> + /delete-property/ interrupts;
> + interrupts-extended = <&gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>,
> + <&pio 94 IRQ_TYPE_EDGE_FALLING>;
> +
> + bluetooth: bluetooth {
I'd also drop this label and only introduce it if/when needed.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Thanks,
Nícolas
> + compatible = "realtek,rtl8822cs-bt";
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_pins>;
> +
> + enable-gpios = <&pio 144 GPIO_ACTIVE_HIGH>;
> + device-wake-gpios = <&pio 168 GPIO_ACTIVE_HIGH>;
> + host-wake-gpios = <&pio 22 GPIO_ACTIVE_LOW>;
> + };
> +};
> --
> 2.40.0.634.g4ca3ef3211-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 06/22] net: thunderx: Use alloc_ordered_workqueue() to create ordered workqueues
From: Jakub Kicinski @ 2023-04-21 14:01 UTC (permalink / raw)
To: Tejun Heo
Cc: jiangshanlai, linux-kernel, kernel-team, Sunil Goutham,
David S. Miller, Eric Dumazet, Paolo Abeni, linux-arm-kernel,
netdev
In-Reply-To: <20230421025046.4008499-7-tj@kernel.org>
On Thu, 20 Apr 2023 16:50:30 -1000 Tejun Heo wrote:
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Sunil Goutham <sgoutham@marvell.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: netdev@vger.kernel.org
You take this via your tree directly to Linus T?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] i2c: lpi2c: cache peripheral clock rate
From: Marc Kleine-Budde @ 2023-04-21 13:59 UTC (permalink / raw)
To: Alexander Stein
Cc: NXP Linux Team, A. Sverdlin, Dong Aisheng, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-i2c,
linux-arm-kernel, linux-kernel
In-Reply-To: <9272339.EvYhyI6sBW@steina-w>
[-- Attachment #1.1: Type: text/plain, Size: 611 bytes --]
On 21.04.2023 15:48:59, Alexander Stein wrote:
[...]
> Now lpi2c_runtime_resume will call into clk_prepare() which also calls
> clk_prepare_lock() (identical to clk_get_rate).
IIRC this is a general problem^w limitation of the clock framework,
clock providers cannot use clocks themselves in certain callback, e.g.
set_rate.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] i2c: lpi2c: cache peripheral clock rate
From: Alexander Stein @ 2023-04-21 13:48 UTC (permalink / raw)
To: NXP Linux Team, A. Sverdlin
Cc: Alexander Sverdlin, Dong Aisheng, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-i2c,
linux-arm-kernel, linux-kernel
In-Reply-To: <20230310130815.562418-1-alexander.sverdlin@siemens.com>
Hi,
sorry for the delay.
Am Freitag, 10. März 2023, 14:08:15 CEST schrieb A. Sverdlin:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
>
> One of the reasons to do it is to save some CPU cycles on cpu_freq_get()
> under mutex. The second reason if the (false-positive) lockdep splat caused
> by the recursive feature of the "prepare_lock" (one clock instance is I2C
> peripheral clock and another is pcf85063 RTC as clock provider):
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 5.15.71+... #1 Tainted: G O
> ------------------------------------------------------
> fs-value/2332 is trying to acquire lock:
> ffff8000096cae08 (prepare_lock){+.+.}-{3:3}, at: clk_prepare_lock
>
> but task is already holding lock:
> ffff000011021100 (i2c_register_adapter){+.+.}-{3:3}, at:
> i2c_adapter_lock_bus
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (i2c_register_adapter){+.+.}-{3:3}:
> lock_acquire
> rt_mutex_lock_nested
> i2c_adapter_lock_bus
> i2c_transfer
> regmap_i2c_read
> _regmap_raw_read
> _regmap_bus_read
> _regmap_read
> regmap_read
> pcf85063_probe
> i2c_device_probe
> really_probe
> __driver_probe_device
> driver_probe_device
> __device_attach_driver
> bus_for_each_drv
> __device_attach
> device_initial_probe
> bus_probe_device
> device_add
> device_register
> i2c_new_client_device
> of_i2c_register_devices
> i2c_register_adapter
> __i2c_add_numbered_adapter
> i2c_add_adapter
> lpi2c_imx_probe
> platform_probe
> really_probe
> __driver_probe_device
> driver_probe_device
> __device_attach_driver
> bus_for_each_drv
> __device_attach
> device_initial_probe
> bus_probe_device
> deferred_probe_work_func
> process_one_work
> worker_thread
> kthread
> ret_from_fork
>
> -> #1 (rtc_pcf85063:560:(&config->regmap)->lock){+.+.}-{3:3}:
> lock_acquire
> __mutex_lock
> mutex_lock_nested
> regmap_lock_mutex
> regmap_read
> pcf85063_clkout_recalc_rate
> __clk_register
> devm_clk_register
> pcf85063_probe
> i2c_device_probe
> really_probe
> __driver_probe_device
> driver_probe_device
> __device_attach_driver
> bus_for_each_drv
> __device_attach
> device_initial_probe
> bus_probe_device
> device_add
> device_register
> i2c_new_client_device
> of_i2c_register_devices
> i2c_register_adapter
> __i2c_add_numbered_adapter
> i2c_add_adapter
> lpi2c_imx_probe
> platform_probe
> really_probe
> __driver_probe_device
> driver_probe_device
> __device_attach_driver
> bus_for_each_drv
> __device_attach
> device_initial_probe
> bus_probe_device
> deferred_probe_work_func
> process_one_work
> worker_thread
> kthread
> ret_from_fork
>
> -> #0 (prepare_lock){+.+.}-{3:3}:
> __lock_acquire
> lock_acquire.part.0
> lock_acquire
> __mutex_lock
> mutex_lock_nested
> clk_prepare_lock
> clk_get_rate
> lpi2c_imx_xfer
> __i2c_transfer
> i2c_transfer
> regmap_i2c_read
> _regmap_raw_read
> regmap_raw_read
> regmap_bulk_read
> at24_read
> nvmem_reg_read
> bin_attr_nvmem_read
> sysfs_kf_bin_read
> kernfs_fop_read_iter
> new_sync_read
> vfs_read
> ksys_read
> __arm64_sys_read
> invoke_syscall
> ...
>
> other info that might help us debug this:
>
> Chain exists of:
> prepare_lock --> rtc_pcf85063:560:(&config->regmap)->lock -->
> i2c_register_adapter
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(i2c_register_adapter);
>
> lock(rtc_pcf85063:560:(&config->regmap)->lock); lock(i2c_register_adapter);
> lock(prepare_lock);
>
> *** DEADLOCK ***
>
> 4 locks held by .../2332:
> #0: ffff0000146eb288 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_read_iter
> #1: ffff000010fe4400 (kn->active#72){.+.+}-{0:0}, at: kernfs_fop_read_iter
> #2: ffff0000110168e8 (&at24->lock){+.+.}-{3:3}, at: at24_read
> #3: ffff000011021100 (i2c_register_adapter){+.+.}-{3:3}, at:
> i2c_adapter_lock_bus
>
> stack backtrace:
> CPU: 1 PID: 2332 Comm: ... Tainted: G O 5.15.71+... #1
> Hardware name: ... (DT)
> Call trace:
> dump_backtrace
> show_stack
> dump_stack_lvl
> dump_stack
> print_circular_bug
> check_noncircular
> __lock_acquire
> lock_acquire.part.0
> lock_acquire
> __mutex_lock
> mutex_lock_nested
> clk_prepare_lock
> clk_get_rate
> lpi2c_imx_xfer
> __i2c_transfer
> i2c_transfer
> regmap_i2c_read
> _regmap_raw_read
> regmap_raw_read
> regmap_bulk_read
> at24_read
> nvmem_reg_read
> bin_attr_nvmem_read
> sysfs_kf_bin_read
> kernfs_fop_read_iter
> new_sync_read
> vfs_read
> ksys_read
> __arm64_sys_read
> invoke_syscall
> ...
>
> Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver")
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 33 +++++++++++++++++++++++++++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> Changelog:
> v3: fixed build error reported by kernel test robot <lkp@intel.com>
>
> https://lore.kernel.org/oe-kbuild-all/202303102010.pAv56wKs-lkp@intel.com/
> v2: added clk_notifier as Alexander suggested
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
> b/drivers/i2c/busses/i2c-imx-lpi2c.c index 188f2a36d2fd6..5f1d1d4e018bd
> 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -100,6 +100,8 @@ struct lpi2c_imx_struct {
> __u8 *rx_buf;
> __u8 *tx_buf;
> struct completion complete;
> + struct notifier_block clk_change_nb;
> + unsigned int rate_per;
> unsigned int msglen;
> unsigned int delivered;
> unsigned int block_data;
> @@ -198,24 +200,37 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct
> *lpi2c_imx) } while (1);
> }
>
> +static int lpi2c_imx_clk_change_cb(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct clk_notifier_data *ndata = data;
> + struct lpi2c_imx_struct *lpi2c_imx = container_of(nb,
> + struct
lpi2c_imx_struct,
> +
clk_change_nb);
> +
> + if (action & POST_RATE_CHANGE)
> + lpi2c_imx->rate_per = ndata->new_rate;
> +
> + return NOTIFY_OK;
> +}
> +
> /* CLKLO = I2C_CLK_RATIO * CLKHI, SETHOLD = CLKHI, DATAVD = CLKHI/2 */
> static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
> {
> u8 prescale, filt, sethold, clkhi, clklo, datavd;
> - unsigned int clk_rate, clk_cycle;
> + unsigned int clk_cycle;
> enum lpi2c_imx_pincfg pincfg;
> unsigned int temp;
>
> lpi2c_imx_set_mode(lpi2c_imx);
>
> - clk_rate = clk_get_rate(lpi2c_imx->clks[0].clk);
> if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST)
> filt = 0;
> else
> filt = 2;
>
> for (prescale = 0; prescale <= 7; prescale++) {
> - clk_cycle = clk_rate / ((1 << prescale) * lpi2c_imx-
>bitrate)
> + clk_cycle = lpi2c_imx->rate_per / ((1 << prescale) *
lpi2c_imx->bitrate)
> - 3 - (filt >> 1);
> clkhi = (clk_cycle + I2C_CLK_RATIO) / (I2C_CLK_RATIO + 1);
> clklo = clk_cycle - clkhi;
> @@ -588,6 +603,18 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev) if (ret)
> return ret;
>
> + lpi2c_imx->clk_change_nb.notifier_call = lpi2c_imx_clk_change_cb;
> + ret = devm_clk_notifier_register(&pdev->dev, lpi2c_imx->clks[0].clk,
> + &lpi2c_imx->clk_change_nb);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "can't register peripheral clock
notifier\n");
> + lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
> + if (!lpi2c_imx->rate_per) {
> + dev_err(&pdev->dev, "can't get I2C peripheral clock
rate\n");
> + return -EINVAL;
> + }
> +
I would switch the order of the calls to devm_clk_notifier_register() and
clk_get_rate(). AFAICS this looks like a possible lost update. The notifier
might change rate_per before the (old) value from clk_get_rate is actually
assigned.
With this change you fix the following call chain (from a kernel log)
[ 4.562396] clk_prepare_lock+0x48/0x9c
[ 4.566740] clk_get_rate+0x1c/0x74
[ 4.570736] lpi2c_imx_config+0x4c/0x190
[ 4.575167] lpi2c_imx_master_enable+0x54/0x128
[ 4.580205] lpi2c_imx_xfer+0x2c/0x3c8
Unfortuantely this was just hiding another call path from lpi2c_imx_xfer to
clk_bulk_prepare. Here is my kernel log:
[ 22.264508] ======================================================
[ 22.270697] WARNING: possible circular locking dependency detected
[ 22.276893] 6.3.0-rc7-next-20230420+ #6 Not tainted
[ 22.281782] ------------------------------------------------------
[ 22.287968] kworker/2:3/93 is trying to acquire lock:
[ 22.293034] ffff800009d38bf8 (prepare_lock){+.+.}-{3:3}, at:
clk_prepare_lock+0x48/0x9c
[ 22.301095]
[ 22.301095] but task is already holding lock:
[ 22.306942] ffff0000039ab100 (i2c_register_adapter){+.+.}-{3:3}, at:
i2c_adapter_lock_bus+0x20/0x2c
[ 22.316046]
[ 22.316046] which lock already depends on the new lock.
[ 22.316046]
[ 22.324238]
[ 22.324238] the existing dependency chain (in reverse order) is:
[ 22.331727]
[ 22.331727] -> #2 (i2c_register_adapter){+.+.}-{3:3}:
[ 22.338295] __lock_acquire+0x370/0x6e8
[ 22.342674] lock_acquire.part.0+0xcc/0x208
[ 22.347399] lock_acquire+0x94/0x14c
[ 22.351509] rt_mutex_lock_nested+0x5c/0x98
[ 22.356235] i2c_adapter_lock_bus+0x20/0x2c
[ 22.360961] i2c_transfer+0x80/0x114
[ 22.365069] regmap_i2c_read+0x5c/0xa0
[ 22.369362] _regmap_raw_read+0x110/0x2dc
[ 22.373905] _regmap_bus_read+0x40/0x74
[ 22.378274] _regmap_read+0x74/0x248
[ 22.382393] regmap_read+0x48/0x70
[ 22.386337] pcf85063_probe+0xf0/0x4f4
[ 22.390640] i2c_device_probe+0x100/0x2d4
[ 22.395206] call_driver_probe+0x28/0x15c
[ 22.399750] really_probe+0x180/0x320
[ 22.403946] __driver_probe_device+0x84/0x144
[ 22.408837] driver_probe_device+0x38/0x150
[ 22.413554] __device_attach_driver+0xcc/0x194
[ 22.418532] bus_for_each_drv+0x80/0xdc
[ 22.422910] __device_attach+0xa8/0x1f8
[ 22.426545] systemd-journald[128]: Oldest entry in /var/log/journal/
e4579cc7db6747028247b9b859e132d6/system.joural is older than the configured
file retention duration (1month), suggesting rotation.
[ 22.427278] device_initial_probe+0x10/0x18
[ 22.427290] bus_probe_device+0xa4/0xa8
[ 22.427299] device_add+0x3b0/0x508
[ 22.427311] device_register+0x1c/0x28
[ 22.427323] i2c_new_client_device+0x1c8/0x2bc
[ 22.427333] of_i2c_register_device+0xb4/0xdc
[ 22.427344] of_i2c_register_devices+0x80/0x154
[ 22.456329] systemd-journald[128]: /var/log/journal/
e4579cc7db6747028247b9b859e132d6/system.journal: Journal heaer limits reached
or header out-of-date, rotating.
[ 22.458176] i2c_register_adapter+0x184/0x4c8
[ 22.458202] __i2c_add_numbered_adapter+0x5c/0xa4
[ 22.502097] i2c_add_adapter+0xa0/0xcc
[ 22.502122] lpi2c_imx_probe+0x23c/0x350
[ 22.502135] platform_probe+0x64/0xfc
[ 22.502146] call_driver_probe+0x28/0x15c
[ 22.502155] really_probe+0x180/0x320
[ 22.502164] __driver_probe_device+0x84/0x144
[ 22.502173] driver_probe_device+0x38/0x150
[ 22.502182] __device_attach_driver+0xcc/0x194
[ 22.502191] bus_for_each_drv+0x80/0xdc
[ 22.502204] __device_attach+0xa8/0x1f8
[ 22.502212] device_initial_probe+0x10/0x18
[ 22.502222] bus_probe_device+0xa4/0xa8
[ 22.502230] deferred_probe_work_func+0xa0/0xf0
[ 22.502239] process_one_work+0x284/0x5b0
[ 22.502252] worker_thread+0x68/0x39c
[ 22.502263] kthread+0x104/0x108
[ 22.502274] ret_from_fork+0x10/0x20
[ 22.502286]
[ 22.502286] -> #1 (rtc_pcf85063:594:(&config->regmap)->lock){+.+.}-{3:3}:
[ 22.502310] __lock_acquire+0x370/0x6e8
[ 22.502322] lock_acquire.part.0+0xcc/0x208
[ 22.502332] lock_acquire+0x94/0x14c
[ 22.502341] __mutex_lock+0x9c/0x838
[ 22.502353] mutex_lock_nested+0x20/0x28
[ 22.502364] regmap_lock_mutex+0x10/0x18
[ 22.502377] regmap_read+0x38/0x70
[ 22.502389] pcf85063_clkout_recalc_rate+0x2c/0x78
[ 22.502403] __clk_core_init+0x46c/0x4e0
[ 22.502417] __clk_register+0x160/0x23c
[ 22.502429] devm_clk_register+0x58/0xb4
[ 22.502441] pcf85063_probe+0x238/0x4f4
[ 22.502451] i2c_device_probe+0x100/0x2d4
[ 22.502465] call_driver_probe+0x28/0x15c
[ 22.502473] really_probe+0x180/0x320
[ 22.502482] __driver_probe_device+0x84/0x144
[ 22.502491] driver_probe_device+0x38/0x150
[ 22.502500] __device_attach_driver+0xcc/0x194
[ 22.502509] bus_for_each_drv+0x80/0xdc
[ 22.502521] __device_attach+0xa8/0x1f8
[ 22.502530] device_initial_probe+0x10/0x18
[ 22.502539] bus_probe_device+0xa4/0xa8
[ 22.502548] device_add+0x3b0/0x508
[ 22.502559] device_register+0x1c/0x28
[ 22.502570] i2c_new_client_device+0x1c8/0x2bc
[ 22.502580] of_i2c_register_device+0xb4/0xdc
[ OK ] Started Network Time Synchronization[ 22.502589]
of_i2c_register_devices+0x80/0x154
.[ 22.502599] i2c_register_adapter+0x184/0x4c8
[ 22.502607] __i2c_add_numbered_adapter+0x5c/0xa4
[ 22.502616] i2c_add_adapter+0xa0/0xcc
[ 22.502624] lpi2c_imx_probe+0x23c/0x350
[ 22.502636] platform_probe+0x64/0xfc
[ 22.502646] call_driver_probe+0x28/0x15c
[ 22.502655] really_probe+0x180/0x320
[ 22.502663] __driver_probe_device+0x84/0x144
[ 22.502672] driver_probe_device+0x38/0x150
[ 22.502681] __device_attach_driver+0xcc/0x194
[ 22.502690] bus_for_each_drv+0x80/0xdc
[ 22.502702] __device_attach+0xa8/0x1f8
[ 22.502711] device_initial_probe+0x10/0x18
[ 22.502720] bus_probe_device+0xa4/0xa8
[ 22.502729] deferred_probe_work_func+0xa0/0xf0
[ 22.502738] process_one_work+0x284/0x5b0
[ 22.502749] worker_thread+0x68/0x39c
[ 22.502760] kthread+0x104/0x108
[ 22.502770] ret_from_fork+0x10/0x20
[ 22.502779]
[ 22.502779] -> #0 (prepare_lock){+.+.}-{3:3}:
[ 22.502799] check_prev_add+0xb0/0xc80
[ 22.502809] validate_chain+0x444/0x510
[ 22.502818] __lock_acquire+0x370/0x6e8
[ 22.502827] lock_acquire.part.0+0xcc/0x208
[ 22.502837] lock_acquire+0x94/0x14c
[ 22.502846] __mutex_lock+0x9c/0x838
[ 22.502857] mutex_lock_nested+0x20/0x28
[ 22.502867] clk_prepare_lock+0x48/0x9c
[ 22.502878] clk_prepare+0x1c/0x3c
[ 22.502890] clk_bulk_prepare+0x48/0xcc
[ 22.502899] lpi2c_runtime_resume+0x30/0x84
[ 22.502910] pm_generic_runtime_resume+0x28/0x3c
[ 22.502923] __genpd_runtime_resume+0x2c/0xa0
[ 22.502935] genpd_runtime_resume+0xbc/0x308
[ 22.502944] __rpm_callback+0x44/0x19c
[ 22.502953] rpm_callback+0x64/0x70
[ 22.502962] rpm_resume+0x438/0x6d8
[ 22.502970] __pm_runtime_resume+0x54/0xb0
[ 22.502978] lpi2c_imx_master_enable+0x24/0x128
[ 22.502989] lpi2c_imx_xfer+0x2c/0x3c8
[ 22.502999] __i2c_transfer+0xe4/0x5a0
[ 22.503008] i2c_transfer+0x90/0x114
[ 22.503016] i2c_transfer_buffer_flags+0x58/0x84
[ 22.503025] regmap_i2c_write+0x1c/0x4c
[ 22.503035] _regmap_raw_write_impl+0x7dc/0x944
[ 22.503044] _regmap_bus_raw_write+0x5c/0x74
[ 22.503052] _regmap_write+0x64/0x238
[ 22.503060] _regmap_update_bits+0x100/0x11c
[ 22.503069] regmap_update_bits_base+0x60/0x90
[ 22.503077] pca953x_gpio_set_value+0x74/0x90
[ 22.503088] gpiod_set_raw_value_commit+0x6c/0x7c
[ 22.503098] gpiod_set_value_nocheck+0x68/0x70
[ 22.503107] gpiod_set_value_cansleep+0x3c/0xa8
[ 22.503116] gpio_led_set_blocking+0x54/0x7c
[ 22.503128] set_brightness_delayed+0x90/0xd8
[ 22.503138] process_one_work+0x284/0x5b0
[ 22.503149] worker_thread+0x68/0x39c
[ 22.503160] kthread+0x104/0x108
[ 22.503169] ret_from_fork+0x10/0x20
[ 22.503179]
[ 22.503179] other info that might help us debug this:
[ 22.503179]
[ 22.503183] Chain exists of:
[ 22.503183] prepare_lock --> rtc_pcf85063:594:(&config->regmap)->lock -->
i2c_register_adapter
[ 22.503183]
[ 22.503207] Possible unsafe locking scenario:
[ 22.503207]
[ 22.503210] CPU0 CPU1
[ 22.503213] ---- ----
[ 22.503216] lock(i2c_register_adapter);
[ 22.503225] lock(rtc_pcf85063:594:(&config-
>regmap)->lock);
[ 22.503235] lock(i2c_register_adapter);
[ 22.503244] lock(prepare_lock);
[ 22.503253]
[ 22.503253] *** DEADLOCK ***
Now lpi2c_runtime_resume will call into clk_prepare() which also calls
clk_prepare_lock() (identical to clk_get_rate).
Best regards,
Alexader
> pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_TIMEOUT);
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_get_noresume(&pdev->dev);
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] dt-bindings: usb: dwc3: xilinx: Add interrupt-names to include hibernation interrupt
From: Mehta, Piyush @ 2023-04-21 13:28 UTC (permalink / raw)
To: Rob Herring
Cc: gregkh@linuxfoundation.org, krzysztof.kozlowski+dt@linaro.org,
michal.simek@xilinx.com, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Simek, Michal, Paladugu, Siva Durga Prasad,
linux-arm-kernel@lists.infradead.org, git (AMD-Xilinx)
In-Reply-To: <20230418184026.GA2099329-robh@kernel.org>
Hi
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Wednesday, April 19, 2023 12:10 AM
> To: Mehta, Piyush <piyush.mehta@amd.com>
> Cc: gregkh@linuxfoundation.org; krzysztof.kozlowski+dt@linaro.org;
> michal.simek@xilinx.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Simek, Michal
> <michal.simek@amd.com>; Paladugu, Siva Durga Prasad
> <siva.durga.prasad.paladugu@amd.com>; linux-arm-
> kernel@lists.infradead.org; git (AMD-Xilinx) <git@amd.com>
> Subject: Re: [PATCH] dt-bindings: usb: dwc3: xilinx: Add interrupt-names to
> include hibernation interrupt
>
> On Wed, Apr 12, 2023 at 11:38:43AM +0530, Piyush Mehta wrote:
> > The hibernation feature enabled for Xilinx Versal NET SoC in DWC3 IP.
> > Added host mode interrupts and "usb-wakeup" interrupt-names optional
> > property in the binding schema to capture remote-wakeup and connect/
> > disconnect event in the hibernation state.
> >
> > Xilinx dwc3-core uses "host" and "otg" interrupts interrupt-names DT
> > properties from dwc3-core.
>
> Is wakeup really not implemented in the DWC3 core, but outside it?
Wakeup is implemented inside the dwc3-core.
Initially we planned to implement wakeup interrupt name/interrupt optional property in the dwc3-core.
However, looking at other vendor wakeup interrupt implementation (Commit: dd566faebe9f dt-bindings: usb: qcom,dwc3: refine interrupt requirements)
we moved wakeup property to xilinx USB binding.
>
> >
> > Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
> > ---
> > Note:
> > - Xilinx uses dwc3-cores interrupt-names DT property.
> > Link:
> > Xilinx-dwc3 core:
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bi
> ndings/usb/dwc3-xilinx.yaml#L129
> > dwc3-core:
> > https://github.com/torvalds/linux/blob/master/Documentation/devicetree
> > /bindings/usb/snps%2Cdwc3.yaml#L42
> > ---
> > Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> > b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> > index 098b73134a1b..abc32db2448a 100644
> > --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> > +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
> > @@ -44,6 +44,15 @@ properties:
> > - const: bus_clk
> > - const: ref_clk
> >
> > + interrupts:
> > + items:
> > + - description: Handle to the line usb-wakeup used to wake
> > + up the host processor.
> > +
> > + interrupt-names:
> > + items:
> > + - const: usb-wakeup
>
> 'wakeup' is the standard name. And you also need 'wakeup-source'
> property.
>
> > +
> > resets:
> > description:
> > A list of phandles for resets listed in reset-names.
> > --
> > 2.25.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 7/7] arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Daniel Golle <daniel@makrotopia.org>
Add pwm-fan and cooling-maps to BananaPi-R3 devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
this is based on Patch from openwrt. as my PWM-fan seems to need 5v pwm
signal and r3 only provides 3v3 on 3pin-socket it does not work for me.
---
.../dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
index 782519429497..29c018bbf29d 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
@@ -37,6 +37,15 @@ dcin: regulator-12vd {
regulator-always-on;
};
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ /* cooling level (0, 1, 2) - pwm inverted */
+ cooling-levels = <255 96 0>;
+ pwms = <&pwm 0 10000 0>;
+ status = "okay";
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -132,6 +141,28 @@ sfp2: sfp-2 {
};
};
+&cpu_thermal {
+ cooling-maps {
+ cpu-active-high {
+ /* active: set fan to cooling level 2 */
+ cooling-device = <&fan 2 2>;
+ trip = <&cpu_trip_active_high>;
+ };
+
+ cpu-active-low {
+ /* active: set fan to cooling level 1 */
+ cooling-device = <&fan 1 1>;
+ trip = <&cpu_trip_active_low>;
+ };
+
+ cpu-passive {
+ /* passive: set fan to cooling level 0 */
+ cooling-device = <&fan 0 0>;
+ trip = <&cpu_trip_passive>;
+ };
+ };
+};
+
&crypto {
status = "okay";
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 6/7] arm64: dts: mt7986: add thermal-zones
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Daniel Golle <daniel@makrotopia.org>
Add thermal-zones to mt7986 devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 40 +++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
index a409d5e845c2..845b29a9664a 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
@@ -603,4 +603,44 @@ wifi: wifi@18000000 {
memory-region = <&wmcpu_emi>;
};
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <1000>;
+ thermal-sensors = <&thermal 0>;
+
+ trips {
+ cpu_trip_crit: crit {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+
+ cpu_trip_hot: hot {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "hot";
+ };
+
+ cpu_trip_active_high: active-high {
+ temperature = <115000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_trip_active_low: active-low {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_trip_passive: passive {
+ temperature = <40000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ };
+ };
+ };
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 5/7] arm64: dts: mt7986: add PWM to BPI-R3
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
Add pwm node and pinctrl to BananaPi R3 devicetree.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
index 2b028141f1f7..782519429497 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
@@ -274,6 +274,13 @@ mux {
};
};
+ pwm_pins: pwm-pins {
+ mux {
+ function = "pwm";
+ groups = "pwm0", "pwm1_0";
+ };
+ };
+
spi_flash_pins: spi-flash-pins {
mux {
function = "spi";
@@ -344,6 +351,12 @@ mux {
};
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_pins>;
+ status = "okay";
+};
+
&spi0 {
pinctrl-names = "default";
pinctrl-0 = <&spi_flash_pins>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 1/7] dt-bindings: nvmem: mediatek: efuse: add support for mt7986
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
Add compatible string for mt7986 SoC.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
index 75e0a516e59a..e3894f9d566e 100644
--- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
@@ -27,6 +27,7 @@ properties:
- enum:
- mediatek,mt7622-efuse
- mediatek,mt7623-efuse
+ - mediatek,mt7986-efuse
- mediatek,mt8173-efuse
- mediatek,mt8183-efuse
- mediatek,mt8186-efuse
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 3/7] arm64: dts: mt7986: add thermal and efuse
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Daniel Golle <daniel@makrotopia.org>
Add thermal related nodes to mt7986 devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 37 ++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
index 51944690e790..a38965e23825 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
@@ -323,6 +323,15 @@ spi1: spi@1100b000 {
status = "disabled";
};
+ auxadc: adc@1100d000 {
+ compatible = "mediatek,mt7986-auxadc";
+ reg = <0 0x1100d000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_ADC_26M_CK>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
ssusb: usb@11200000 {
compatible = "mediatek,mt7986-xhci",
"mediatek,mtk-xhci";
@@ -361,6 +370,21 @@ mmc0: mmc@11230000 {
status = "disabled";
};
+ thermal: thermal@1100c800 {
+ #thermal-sensor-cells = <1>;
+ compatible = "mediatek,mt7986-thermal";
+ reg = <0 0x1100c800 0 0x800>;
+ interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&infracfg CLK_INFRA_THERM_CK>,
+ <&infracfg CLK_INFRA_ADC_26M_CK>,
+ <&infracfg CLK_INFRA_ADC_FRC_CK>;
+ clock-names = "therm", "auxadc", "adc_32k";
+ mediatek,auxadc = <&auxadc>;
+ mediatek,apmixedsys = <&apmixedsys>;
+ nvmem-cells = <&thermal_calibration>;
+ nvmem-cell-names = "calibration-data";
+ };
+
pcie: pcie@11280000 {
compatible = "mediatek,mt7986-pcie",
"mediatek,mt8192-pcie";
@@ -412,6 +436,18 @@ pcie_port: pcie-phy@11c00000 {
};
};
+ efuse: efuse@11d00000 {
+ compatible = "mediatek,mt7986-efuse",
+ "mediatek,efuse";
+ reg = <0 0x11d00000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ thermal_calibration: calib@274 {
+ reg = <0x274 0xc>;
+ };
+ };
+
usb_phy: t-phy@11e10000 {
compatible = "mediatek,mt7986-tphy",
"mediatek,generic-tphy-v2";
@@ -553,5 +589,4 @@ wifi: wifi@18000000 {
memory-region = <&wmcpu_emi>;
};
};
-
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 4/7] arm64: dts: mt7986: add PWM
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Daniel Golle <daniel@makrotopia.org>
This adds pwm node to mt7986.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
index a38965e23825..a409d5e845c2 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi
@@ -240,6 +240,20 @@ crypto: crypto@10320000 {
status = "disabled";
};
+ pwm: pwm@10048000 {
+ compatible = "mediatek,mt7986-pwm";
+ reg = <0 0x10048000 0 0x1000>;
+ #clock-cells = <1>;
+ #pwm-cells = <2>;
+ interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&topckgen CLK_TOP_PWM_SEL>,
+ <&infracfg CLK_INFRA_PWM_STA>,
+ <&infracfg CLK_INFRA_PWM1_CK>,
+ <&infracfg CLK_INFRA_PWM2_CK>;
+ clock-names = "top", "main", "pwm1", "pwm2";
+ status = "disabled";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt7986-uart",
"mediatek,mt6577-uart";
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 2/7] dt-bindings: iio: adc: Add support for MT7986
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
In-Reply-To: <20230421132047.42166-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
Add compatible string and specific clock property for mt7986.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
index 7f79a06e76f5..6168b44ea72c 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
@@ -26,6 +26,7 @@ properties:
- mediatek,mt2712-auxadc
- mediatek,mt6765-auxadc
- mediatek,mt7622-auxadc
+ - mediatek,mt7986-auxadc
- mediatek,mt8173-auxadc
- items:
- enum:
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Subject: [PATCH v1 0/7] Add mt7986 thermal and pwm
From: Frank Wunderlich @ 2023-04-21 13:20 UTC (permalink / raw)
To: linux-mediatek
Cc: Frank Wunderlich, Jonathan Cameron, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Hui.Liu,
Zhiyong Tao, Andrew-CT Chen, Lala Lin, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, Daniel Golle
From: Frank Wunderlich <frank-w@public-files.de>
This series add thermal and pwm related devicetree-nodes and necessary
dt-bindings.
I left pwm-fan for r3 for now as i cannot test this completely due to
missing 2 pin-jack and 3v3 pwm-level which my fan cannot handle (starts
spinning at ~3V).
Daniel Golle (4):
arm64: dts: mt7986: add thermal and efuse
arm64: dts: mt7986: add PWM
arm64: dts: mt7986: add thermal-zones
arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts
Frank Wunderlich (3):
dt-bindings: nvmem: mediatek: efuse: add support for mt7986
dt-bindings: iio: adc: Add support for MT7986
arm64: dts: mt7986: add PWM to BPI-R3
.../iio/adc/mediatek,mt2701-auxadc.yaml | 1 +
.../bindings/nvmem/mediatek,efuse.yaml | 1 +
.../dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 44 +++++++++
arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 89 +++++++++++++++++++
4 files changed, 135 insertions(+)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCHv2 0/2] Improve RK3588 clocks and power domains support
From: Heiko Stuebner @ 2023-04-21 12:56 UTC (permalink / raw)
To: Sebastian Reichel, linux-rockchip
Cc: Heiko Stuebner, Finley Xiao, Stephen Boyd, linux-kernel,
Boris Brezillon, kernel, Jagan Teki, linux-clk, Elaine Zhang,
Peter Geis, linux-arm-kernel, Michael Turquette
In-Reply-To: <20230403193250.108693-1-sebastian.reichel@collabora.com>
On Mon, 3 Apr 2023 21:32:48 +0200, Sebastian Reichel wrote:
> After this patchset the power-domain support for RK3588 is basically on par
> with the downstream implementation. More importantly the clock controller
> change unblocks support for any IP blocks using linked clocks. The clock
> controller change must be applied before the power-domain change to avoid
> accessing unclocked registers.
>
> Changes since PATCHv1:
> * https://lore.kernel.org/all/20230331163058.5688-1-sebastian.reichel@collabora.com/
> * Replace dsb(sy) with wmb() to fix COMPILE_TEST build on !arm64; direct replacement
> would be mb(), but write memory barrier should be enough here as far as I can tell
> * Added Tested-by from Vincent Legoll
>
> [...]
Applied, thanks!
[2/2] soc: rockchip: power-domain: add rk3588 mem module support
commit: 632a6b6593d5bfe9932490f8483195bbf50cbbb7
For 6.5, so this will get a rebase after 6.4-rc1.
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 06/13] dt-bindings: display/msm: Add SM6375 MDSS
From: Rob Herring @ 2023-04-21 12:56 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Robin Murphy, Rob Clark, Sean Paul, Dmitry Baryshkov, Will Deacon,
linux-arm-kernel, Krzysztof Kozlowski, Rob Herring, Daniel Vetter,
Joerg Roedel, iommu, freedreno, Krishna Manikandan, devicetree,
David Airlie, dri-devel, Marijn Suijten, linux-arm-msm,
linux-kernel, Abhinav Kumar
In-Reply-To: <20230411-topic-straitlagoon_mdss-v2-6-5def73f50980@linaro.org>
On Fri, 21 Apr 2023 00:31:15 +0200, Konrad Dybcio wrote:
> Document the SM6375 MDSS.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216 +++++++++++++++++++++
> 1 file changed, 216 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.example.dtb: dsi@5e94000: compatible: 'oneOf' conditional failed, one must be fixed:
'qcom,sm6375-dsi-ctrl' is not one of ['qcom,apq8064-dsi-ctrl', 'qcom,msm8916-dsi-ctrl', 'qcom,msm8953-dsi-ctrl', 'qcom,msm8974-dsi-ctrl', 'qcom,msm8996-dsi-ctrl', 'qcom,msm8998-dsi-ctrl', 'qcom,qcm2290-dsi-ctrl', 'qcom,sc7180-dsi-ctrl', 'qcom,sc7280-dsi-ctrl', 'qcom,sdm660-dsi-ctrl', 'qcom,sdm845-dsi-ctrl', 'qcom,sm8150-dsi-ctrl', 'qcom,sm8250-dsi-ctrl', 'qcom,sm8350-dsi-ctrl', 'qcom,sm8450-dsi-ctrl', 'qcom,sm8550-dsi-ctrl']
'qcom,sm6375-dsi-ctrl' is not one of ['dsi-ctrl-6g-qcm2290']
From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.example.dtb: dsi@5e94000: Unevaluated properties are not allowed ('compatible' was unexpected)
From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230411-topic-straitlagoon_mdss-v2-6-5def73f50980@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/13] dt-bindings: display/msm: Add SM6350 MDSS
From: Rob Herring @ 2023-04-21 12:56 UTC (permalink / raw)
To: Konrad Dybcio
Cc: linux-arm-kernel, dri-devel, Abhinav Kumar, Krzysztof Kozlowski,
linux-arm-msm, Will Deacon, Rob Herring, David Airlie,
Marijn Suijten, devicetree, Dmitry Baryshkov, Daniel Vetter,
Joerg Roedel, Sean Paul, Rob Clark, Robin Murphy, iommu,
Krishna Manikandan, linux-kernel, freedreno
In-Reply-To: <20230411-topic-straitlagoon_mdss-v2-4-5def73f50980@linaro.org>
On Fri, 21 Apr 2023 00:31:13 +0200, Konrad Dybcio wrote:
> Document the SM6350 MDSS.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214 +++++++++++++++++++++
> 1 file changed, 214 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.example.dtb: dsi@ae94000: compatible: 'oneOf' conditional failed, one must be fixed:
'qcom,sm6350-dsi-ctrl' is not one of ['qcom,apq8064-dsi-ctrl', 'qcom,msm8916-dsi-ctrl', 'qcom,msm8953-dsi-ctrl', 'qcom,msm8974-dsi-ctrl', 'qcom,msm8996-dsi-ctrl', 'qcom,msm8998-dsi-ctrl', 'qcom,qcm2290-dsi-ctrl', 'qcom,sc7180-dsi-ctrl', 'qcom,sc7280-dsi-ctrl', 'qcom,sdm660-dsi-ctrl', 'qcom,sdm845-dsi-ctrl', 'qcom,sm8150-dsi-ctrl', 'qcom,sm8250-dsi-ctrl', 'qcom,sm8350-dsi-ctrl', 'qcom,sm8450-dsi-ctrl', 'qcom,sm8550-dsi-ctrl']
'qcom,sm6350-dsi-ctrl' is not one of ['dsi-ctrl-6g-qcm2290']
From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.example.dtb: dsi@ae94000: Unevaluated properties are not allowed ('compatible' was unexpected)
From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230411-topic-straitlagoon_mdss-v2-4-5def73f50980@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/3] KVM: arm64: Floating point documentation updates and code tweaks
From: Marc Zyngier @ 2023-04-21 12:54 UTC (permalink / raw)
To: Will Deacon, Oliver Upton, Alexandru Elisei, James Morse,
Suzuki K Poulose, Mark Brown, Catalin Marinas
Cc: linux-arm-kernel, kvmarm
In-Reply-To: <20221214-kvm-arm64-sme-context-switch-v2-0-57ba0082e9ff@kernel.org>
On Tue, 07 Mar 2023 17:37:13 +0000, Mark Brown wrote:
> This series has some improvements to the documentation and code for the
> KVM floating point code, the main one being that it documents that the
> current behaviour where we disable streaming mode and ZA prior to
> running guests as being the intended behaviour. There's a more detailed
> discussion of that change in the patch commit log, but briefly we need
> to disable streaming mode in order to avoid EL1 triggering SME traps to
> itself due to executing instructions which should be valid.
>
> [...]
Applied to next, thanks!
[1/3] KVM: arm64: Document check for TIF_FOREIGN_FPSTATE
commit: 4c181e3d352e9280c84fb4b4c7a8940ce005374e
[2/3] KVM: arm64: Restructure check for SVE support in FP trap handler
commit: d071cefdcca39fdbcdd4bf36868448820dbac34b
[3/3] KVM: arm64: Clarify host SME state management
commit: aaa2f14e6f3f34de8edfb13566110a0fe0d88785
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox