* Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Sudeep Holla @ 2024-04-09 12:52 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Cristian Marussi, Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AS1PR04MB9431F99D49D6A777B09814FB88072@AS1PR04MB9431.eurprd04.prod.outlook.com>
On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote:
>
> ok, will add more comment in the patch for the commands.
>
No I meant add document/description similar to SCMI spec for each of these
commands. Not just one line comment. For std protocols, we can refer spec,
for these vendor protocols, just one like comment will not suffice. Describe
in more details and hence the request for separate TXT file for that.
Hope that is clear now, I have mentioned it several times already.
--
Regards,
Sudeep
_______________________________________________
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] perf: arm_cspmu: Don't touch interrupt registers if no interrupt was assigned
From: Robin Murphy @ 2024-04-09 12:53 UTC (permalink / raw)
To: Ilkka Koskinen
Cc: Besar Wicaksono, Suzuki K Poulose, Will Deacon, Mark Rutland,
Raag Jadav, linux-arm-kernel, linux-kernel
In-Reply-To: <8fdfceb2-90b3-a1a9-fa88-a45ece30c0bb@os.amperecomputing.com>
On 09/04/2024 2:05 am, Ilkka Koskinen wrote:
>
> On Mon, 8 Apr 2024, Robin Murphy wrote:
>> On 2024-04-05 11:33 pm, Ilkka Koskinen wrote:
>>>
>>> On Fri, 5 Apr 2024, Robin Murphy wrote:
>>>> On 2024-03-07 7:31 pm, Ilkka Koskinen wrote:
>>>>> The driver enabled and disabled interrupts even if no interrupt was
>>>>> assigned to the device.
>>>>
>>>> Why's that a concern - if the interrupt isn't routed anywhere,
>>>> surely it makes no difference what happens at the source end?
>>>
>>> The issue is that we have two PMUs attached to the same interrupt line.
>>> Unfortunately, I just don't seem to find time to add support for
>>> shared interrupts to the cspmu driver. Meanwhile, I assigned the
>>> interrupt to one of the PMUs while the other one has zero in the APMT
>>> table.
>>
>> I suspected something like that ;)
>>
>>> Without the patch, I can trigger "ghost interrupt" in the latter PMU.
>>
>> An occasional spurious interrupt should be no big deal. If it ends up
>> as a screaming spurious interrupt because we never handle the overflow
>> condition on the "other" PMU, then what matters most is that we never
>> handle the overflow, thus the "other" PMU is still useless since you
>> can't assume the user is going to read it frequently enough to avoid
>> losing information and getting nonsense counts back. So this hack
>> really isn't a viable solution for anything.
>
> IIRC, what happens is that kernel will disable the interrupt eventually
> due to unhandled spurious interrupts making the "working" PMU also useless.
Indeed, but if having one inaccurate PMU is fine, having more than one
is no big deal either, right? The moral of the story is that hacking the
firmware to lie about the hardware is just not a great idea.
TBH it's always seemed a bit broken that we allow probing without an IRQ
but then have no accommodation for overflow if so. Fixing that would be
a good thing in itself, and would at least have the side-effect of
allowing your hack to work, however much I may disapprove of that :)
FWIW it is still lingering some way down my to-do list to factor out the
fiddly IRQ-sharing/migration code into at least a helper library (if not
further into perf core itself) before it gets copy-pasted much more, and
it occurs to me that I could then easily factor the IRQ-substitute timer
approach from e.g. arm-ccn into that as well... The more I think about
it the more I might just convince myself that I want it for the driver
I'm currently working on and justify bumping it up the list, let's see...
Cheers,
Robin.
_______________________________________________
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] iommu/arm-smmu-v3: Retire disable_bypass parameter
From: Will Deacon @ 2024-04-09 12:55 UTC (permalink / raw)
To: joro, Robin Murphy
Cc: catalin.marinas, kernel-team, Will Deacon, iommu,
linux-arm-kernel
In-Reply-To: <ea3ac4cd595a81b5511729601b2f7d4668178438.1712335927.git.robin.murphy@arm.com>
On Fri, 05 Apr 2024 17:52:07 +0100, Robin Murphy wrote:
> The disable_bypass parameter has been mostly meaningless for a long time
> since the introduction of default domains. Its original intent is now
> fulfilled by the controls users have over the default domain type, and
> its remaining effect in the brief window between Stream Table
> initialisation and default domain creation hardly seems worth the
> complication. Furthermore, thanks to 2-level Stream Tables, disabling
> disable_bypass (there's another reason not to like it right there) has
> never guaranteed that any particular StreamID *will* bypass anyway - any
> device which might actually care about that wants RMRs - so there's not
> really much lost by taking away that option (which has already been
> non-default for nearing 6 years now).
>
> [...]
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3: Retire disable_bypass parameter
https://git.kernel.org/will/c/734554fdfce6
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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 v6 00/29] Update SMMUv3 to the modern iommu API (part 2/3)
From: Will Deacon @ 2024-04-09 12:54 UTC (permalink / raw)
To: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy,
Jason Gunthorpe
Cc: catalin.marinas, kernel-team, Will Deacon, Lu Baolu, Eric Auger,
Jean-Philippe Brucker, Joerg Roedel, Kevin Tian,
kernel test robot, Moritz Fischer, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameer Kolothum, Mostafa Saleh, Tony Zhu,
Yi Liu, Zhangfei Gao
In-Reply-To: <0-v6-228e7adf25eb+4155-smmuv3_newapi_p2_jgg@nvidia.com>
On Wed, 27 Mar 2024 15:07:46 -0300, Jason Gunthorpe wrote:
> Continuing the work of part 1 this focuses on the CD, PASID and SVA
> components:
>
> - attach_dev failure does not change the HW configuration.
>
> - Full PASID API support including:
> - S1/SVA domains attached to PASIDs
> - IDENTITY/BLOCKED/S1 attached to RID
> - Change of the RID domain while PASIDs are attached
>
> [...]
In the interests of making a dent (albeit a tiny one!) in this series
while review is ongoing, I've picked up 3-5 as they look ready to go.
Applied 3-5 to will (for-joerg/arm-smmu/updates), thanks!
[03/29] iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong PASID
https://git.kernel.org/will/c/fdc69d39e77f
[04/29] iommu/arm-smmu-v3: Do not ATC invalidate the entire domain
https://git.kernel.org/will/c/86e5ca098dd9
[05/29] iommu/arm-smmu-v3: Add a type for the CD entry
https://git.kernel.org/will/c/e8e4398d53f9
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v4 0/9] allocate dummy device dynamically
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo, Matthias Brugger, AngeloGioacchino Del Regno
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf
struct net_device shouldn't be embedded into any structure, instead,
the owner should use the private space to embed their state into
net_device.
But, in some cases the net_device is embedded inside the private
structure, which blocks the usage of zero-length arrays inside
net_device.
Create a helper to allocate a dummy device at dynamically runtime, and
move the Ethernet devices to use it, instead of embedding the dummy
device inside the private structure.
This fixes all the network cases plus some wireless drivers.
PS: Due to lack of hardware, unfortunately most these patches are
compiled tested only, except ath11k that was kindly tested by Kalle Valo.
---
Changelog:
v1:
* https://lore.kernel.org/all/20240327200809.512867-1-leitao@debian.org/
v2:
* Patch 1: Use a pre-defined name ("dummy#") for the dummy
net_devices.
* Patch 2-5: Added users for the new helper.
v3:
* Use free_netdev() instead of kfree() as suggested by Jakub.
* Change the free_netdev() place in ipa driver, as suggested by
Alex Elder.
* Set err in the error path in the Marvell driver, as suggested
by Simon Horman.
v4:
* Added a new patch to add dummy device at free_netdev(), as suggested
by Jakub.
* Added support for some wireless driver.
* Added some Acked-by and Reviewed-by.
Breno Leitao (9):
net: free_netdev: exit earlier if dummy
net: create a dummy net_device allocator
net: marvell: prestera: allocate dummy net_device dynamically
net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically
net: ipa: allocate dummy net_device dynamically
net: ibm/emac: allocate dummy net_device dynamically
wifi: qtnfmac: Use netdev dummy allocator helper
wifi: ath10k: allocate dummy net_device dynamically
wifi: ath11k: allocate dummy net_device dynamically
drivers/net/ethernet/ibm/emac/mal.c | 14 ++++-
drivers/net/ethernet/ibm/emac/mal.h | 2 +-
.../ethernet/marvell/prestera/prestera_rxtx.c | 15 ++++-
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 ++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
drivers/net/ipa/gsi.c | 12 ++--
drivers/net/ipa/gsi.h | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 9 ++-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
drivers/net/wireless/ath/ath10k/sdio.c | 2 +-
drivers/net/wireless/ath/ath10k/snoc.c | 4 +-
drivers/net/wireless/ath/ath10k/usb.c | 2 +-
drivers/net/wireless/ath/ath11k/ahb.c | 9 ++-
drivers/net/wireless/ath/ath11k/core.h | 2 +-
drivers/net/wireless/ath/ath11k/pcic.c | 21 +++++--
.../wireless/quantenna/qtnfmac/pcie/pcie.c | 3 +-
include/linux/netdevice.h | 3 +
net/core/dev.c | 57 ++++++++++++-------
19 files changed, 127 insertions(+), 53 deletions(-)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v4 1/9] net: free_netdev: exit earlier if dummy
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf, Jiri Pirko, Simon Horman, Daniel Borkmann,
Sebastian Andrzej Siewior
In-Reply-To: <20240409125738.1824983-1-leitao@debian.org>
For dummy devices, exit earlier at free_netdev() instead of executing
the whole function. This is necessary, because dummy devices are
special, and shouldn't have the second part of the function executed.
Otherwise reg_state, which is NETREG_DUMMY for dummy devices, will be
overwritten and there will be no way to identify that this is a dummy
device. Also, this device do not need the final put_device(), since
dummy devices are not registered (through register_netdevice()), where
the device reference is increased (at netdev_register_kobject() ->
device_add()).
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/core/dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 92f5bddbc2de..bf0a335781aa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -11051,7 +11051,8 @@ void free_netdev(struct net_device *dev)
dev->xdp_bulkq = NULL;
/* Compatibility with error handling in drivers */
- if (dev->reg_state == NETREG_UNINITIALIZED) {
+ if (dev->reg_state == NETREG_UNINITIALIZED ||
+ dev->reg_state == NETREG_DUMMY) {
netdev_freemem(dev);
return;
}
--
2.43.0
_______________________________________________
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 net-next v4 3/9] net: marvell: prestera: allocate dummy net_device dynamically
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf, Elad Nachman
In-Reply-To: <20240409125738.1824983-1-leitao@debian.org>
Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_device from the private struct by converting it
into a pointer. Then use the leverage the new alloc_netdev_dummy()
helper to allocate and initialize dummy devices.
[1] https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Elad Nachman <enachman@marvell.com>
---
.../net/ethernet/marvell/prestera/prestera_rxtx.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c b/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c
index cc2a9ae794be..39d9bf82c115 100644
--- a/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c
+++ b/drivers/net/ethernet/marvell/prestera/prestera_rxtx.c
@@ -96,7 +96,7 @@ struct prestera_sdma {
struct dma_pool *desc_pool;
struct work_struct tx_work;
struct napi_struct rx_napi;
- struct net_device napi_dev;
+ struct net_device *napi_dev;
u32 map_addr;
u64 dma_mask;
/* protect SDMA with concurrent access from multiple CPUs */
@@ -654,13 +654,21 @@ static int prestera_sdma_switch_init(struct prestera_switch *sw)
if (err)
goto err_evt_register;
- init_dummy_netdev(&sdma->napi_dev);
+ sdma->napi_dev = alloc_netdev_dummy(0);
+ if (!sdma->napi_dev) {
+ dev_err(dev, "not able to initialize dummy device\n");
+ err = -ENOMEM;
+ goto err_alloc_dummy;
+ }
- netif_napi_add(&sdma->napi_dev, &sdma->rx_napi, prestera_sdma_rx_poll);
+ netif_napi_add(sdma->napi_dev, &sdma->rx_napi, prestera_sdma_rx_poll);
napi_enable(&sdma->rx_napi);
return 0;
+err_alloc_dummy:
+ prestera_hw_event_handler_unregister(sw, PRESTERA_EVENT_TYPE_RXTX,
+ prestera_rxtx_handle_event);
err_evt_register:
err_tx_init:
prestera_sdma_tx_fini(sdma);
@@ -677,6 +685,7 @@ static void prestera_sdma_switch_fini(struct prestera_switch *sw)
napi_disable(&sdma->rx_napi);
netif_napi_del(&sdma->rx_napi);
+ free_netdev(sdma->napi_dev);
prestera_hw_event_handler_unregister(sw, PRESTERA_EVENT_TYPE_RXTX,
prestera_rxtx_handle_event);
prestera_sdma_tx_fini(sdma);
--
2.43.0
_______________________________________________
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 net-next v4 2/9] net: create a dummy net_device allocator
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf, Jiri Pirko, Simon Horman, Daniel Borkmann,
Sebastian Andrzej Siewior
In-Reply-To: <20240409125738.1824983-1-leitao@debian.org>
It is impossible to use init_dummy_netdev together with alloc_netdev()
as the 'setup' argument.
This is because alloc_netdev() initializes some fields in the net_device
structure, and later init_dummy_netdev() memzero them all. This causes
some problems as reported here:
https://lore.kernel.org/all/20240322082336.49f110cc@kernel.org/
Split the init_dummy_netdev() function in two. Create a new function called
init_dummy_netdev_core() that does not memzero the net_device structure.
Then have init_dummy_netdev() memzero-ing and calling
init_dummy_netdev_core(), keeping the old behaviour.
init_dummy_netdev_core() is the new function that could be called as an
argument for alloc_netdev().
Also, create a helper to allocate and initialize dummy net devices,
leveraging init_dummy_netdev_core() as the setup argument. This function
basically simplify the allocation of dummy devices, by allocating and
initializing it. Freeing the device continue to be done through
free_netdev()
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 54 ++++++++++++++++++++++++++-------------
2 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0c198620ac93..544767d218c0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4517,6 +4517,9 @@ static inline void netif_addr_unlock_bh(struct net_device *dev)
void ether_setup(struct net_device *dev);
+/* Allocate dummy net_device */
+struct net_device *alloc_netdev_dummy(int sizeof_priv);
+
/* Support for loadable net-drivers */
struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
unsigned char name_assign_type,
diff --git a/net/core/dev.c b/net/core/dev.c
index bf0a335781aa..5d2cb97d0ae6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -10413,25 +10413,12 @@ int register_netdevice(struct net_device *dev)
}
EXPORT_SYMBOL(register_netdevice);
-/**
- * init_dummy_netdev - init a dummy network device for NAPI
- * @dev: device to init
- *
- * This takes a network device structure and initialize the minimum
- * amount of fields so it can be used to schedule NAPI polls without
- * registering a full blown interface. This is to be used by drivers
- * that need to tie several hardware interfaces to a single NAPI
- * poll scheduler due to HW limitations.
+/* Initialize the core of a dummy net device.
+ * This is useful if you are calling this function after alloc_netdev(),
+ * since it does not memset the net_device fields.
*/
-void init_dummy_netdev(struct net_device *dev)
+static void init_dummy_netdev_core(struct net_device *dev)
{
- /* Clear everything. Note we don't initialize spinlocks
- * are they aren't supposed to be taken by any of the
- * NAPI code and this dummy netdev is supposed to be
- * only ever used for NAPI polls
- */
- memset(dev, 0, sizeof(struct net_device));
-
/* make sure we BUG if trying to hit standard
* register/unregister code path
*/
@@ -10452,8 +10439,28 @@ void init_dummy_netdev(struct net_device *dev)
* its refcount.
*/
}
-EXPORT_SYMBOL_GPL(init_dummy_netdev);
+/**
+ * init_dummy_netdev - init a dummy network device for NAPI
+ * @dev: device to init
+ *
+ * This takes a network device structure and initialize the minimum
+ * amount of fields so it can be used to schedule NAPI polls without
+ * registering a full blown interface. This is to be used by drivers
+ * that need to tie several hardware interfaces to a single NAPI
+ * poll scheduler due to HW limitations.
+ */
+void init_dummy_netdev(struct net_device *dev)
+{
+ /* Clear everything. Note we don't initialize spinlocks
+ * are they aren't supposed to be taken by any of the
+ * NAPI code and this dummy netdev is supposed to be
+ * only ever used for NAPI polls
+ */
+ memset(dev, 0, sizeof(struct net_device));
+ init_dummy_netdev_core(dev);
+}
+EXPORT_SYMBOL_GPL(init_dummy_netdev);
/**
* register_netdev - register a network device
@@ -11065,6 +11072,17 @@ void free_netdev(struct net_device *dev)
}
EXPORT_SYMBOL(free_netdev);
+/**
+ * alloc_netdev_dummy - Allocate and initialize a dummy net device.
+ * @sizeof_priv: size of private data to allocate space for
+ */
+struct net_device *alloc_netdev_dummy(int sizeof_priv)
+{
+ return alloc_netdev(sizeof_priv, "dummy#", NET_NAME_UNKNOWN,
+ init_dummy_netdev_core);
+}
+EXPORT_SYMBOL_GPL(alloc_netdev_dummy);
+
/**
* synchronize_net - Synchronize with packet receive processing
*
--
2.43.0
_______________________________________________
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 net-next v4 5/9] net: ipa: allocate dummy net_device dynamically
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf
In-Reply-To: <20240409125738.1824983-1-leitao@debian.org>
Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_device from the private struct by converting it
into a pointer. Then use the leverage the new alloc_netdev_dummy()
helper to allocate and initialize dummy devices.
[1] https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ipa/gsi.c | 12 ++++++++----
drivers/net/ipa/gsi.h | 2 +-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
index 9a0b1fe4a93a..d70be15e95a6 100644
--- a/drivers/net/ipa/gsi.c
+++ b/drivers/net/ipa/gsi.c
@@ -1730,10 +1730,10 @@ static int gsi_channel_setup_one(struct gsi *gsi, u32 channel_id)
gsi_channel_program(channel, true);
if (channel->toward_ipa)
- netif_napi_add_tx(&gsi->dummy_dev, &channel->napi,
+ netif_napi_add_tx(gsi->dummy_dev, &channel->napi,
gsi_channel_poll);
else
- netif_napi_add(&gsi->dummy_dev, &channel->napi,
+ netif_napi_add(gsi->dummy_dev, &channel->napi,
gsi_channel_poll);
return 0;
@@ -2369,12 +2369,14 @@ int gsi_init(struct gsi *gsi, struct platform_device *pdev,
/* GSI uses NAPI on all channels. Create a dummy network device
* for the channel NAPI contexts to be associated with.
*/
- init_dummy_netdev(&gsi->dummy_dev);
+ gsi->dummy_dev = alloc_netdev_dummy(0);
+ if (!gsi->dummy_dev)
+ return -ENOMEM;
init_completion(&gsi->completion);
ret = gsi_reg_init(gsi, pdev);
if (ret)
- return ret;
+ goto err_reg_exit;
ret = gsi_irq_init(gsi, pdev); /* No matching exit required */
if (ret)
@@ -2389,6 +2391,7 @@ int gsi_init(struct gsi *gsi, struct platform_device *pdev,
return 0;
err_reg_exit:
+ free_netdev(gsi->dummy_dev);
gsi_reg_exit(gsi);
return ret;
@@ -2399,6 +2402,7 @@ void gsi_exit(struct gsi *gsi)
{
mutex_destroy(&gsi->mutex);
gsi_channel_exit(gsi);
+ free_netdev(gsi->dummy_dev);
gsi_reg_exit(gsi);
}
diff --git a/drivers/net/ipa/gsi.h b/drivers/net/ipa/gsi.h
index 42063b227c18..6b7ec2a39676 100644
--- a/drivers/net/ipa/gsi.h
+++ b/drivers/net/ipa/gsi.h
@@ -155,7 +155,7 @@ struct gsi {
struct mutex mutex; /* protects commands, programming */
struct gsi_channel channel[GSI_CHANNEL_COUNT_MAX];
struct gsi_evt_ring evt_ring[GSI_EVT_RING_COUNT_MAX];
- struct net_device dummy_dev; /* needed for NAPI */
+ struct net_device *dummy_dev; /* needed for NAPI */
};
/**
--
2.43.0
_______________________________________________
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 net-next v4 4/9] net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo, Matthias Brugger, AngeloGioacchino Del Regno,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf
In-Reply-To: <20240409125738.1824983-1-leitao@debian.org>
Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_device from the private struct by converting it
into a pointer. Then use the leverage the new alloc_netdev_dummy()
helper to allocate and initialize dummy devices.
[1] https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 +++++++++++++----
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index caa13b9cedff..d7a96dc11c07 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1710,7 +1710,7 @@ static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,
if (IS_ERR(pp))
return pp;
- err = __xdp_rxq_info_reg(xdp_q, ð->dummy_dev, id,
+ err = __xdp_rxq_info_reg(xdp_q, eth->dummy_dev, id,
eth->rx_napi.napi_id, PAGE_SIZE);
if (err < 0)
goto err_free_pp;
@@ -4188,6 +4188,8 @@ static int mtk_free_dev(struct mtk_eth *eth)
metadata_dst_free(eth->dsa_meta[i]);
}
+ free_netdev(eth->dummy_dev);
+
return 0;
}
@@ -4983,9 +4985,14 @@ static int mtk_probe(struct platform_device *pdev)
/* we run 2 devices on the same DMA ring so we need a dummy device
* for NAPI to work
*/
- init_dummy_netdev(ð->dummy_dev);
- netif_napi_add(ð->dummy_dev, ð->tx_napi, mtk_napi_tx);
- netif_napi_add(ð->dummy_dev, ð->rx_napi, mtk_napi_rx);
+ eth->dummy_dev = alloc_netdev_dummy(0);
+ if (!eth->dummy_dev) {
+ err = -ENOMEM;
+ dev_err(eth->dev, "failed to allocated dummy device\n");
+ goto err_unreg_netdev;
+ }
+ netif_napi_add(eth->dummy_dev, ð->tx_napi, mtk_napi_tx);
+ netif_napi_add(eth->dummy_dev, ð->rx_napi, mtk_napi_rx);
platform_set_drvdata(pdev, eth);
schedule_delayed_work(ð->reset.monitor_work,
@@ -4993,6 +5000,8 @@ static int mtk_probe(struct platform_device *pdev)
return 0;
+err_unreg_netdev:
+ mtk_unreg_dev(eth);
err_deinit_ppe:
mtk_ppe_deinit(eth);
mtk_mdio_cleanup(eth);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 9ae3b8a71d0e..723fc637027c 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -1242,7 +1242,7 @@ struct mtk_eth {
spinlock_t page_lock;
spinlock_t tx_irq_lock;
spinlock_t rx_irq_lock;
- struct net_device dummy_dev;
+ struct net_device *dummy_dev;
struct net_device *netdev[MTK_MAX_DEVS];
struct mtk_mac *mac[MTK_MAX_DEVS];
int irq[3];
--
2.43.0
_______________________________________________
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 net-next v4 7/9] wifi: qtnfmac: Use netdev dummy allocator helper
From: Breno Leitao @ 2024-04-09 12:57 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, ath11k, ath10k, linux-wireless, geomatsi,
kvalo, Igor Mitsyanko
Cc: quic_jjohnson, leon, dennis.dalessandro, linux-kernel, netdev,
bpf
In-Reply-To: <20240409125738.1824983-1-leitao@debian.org>
There is a new dummy netdev allocator, use it instead of
alloc_netdev()/init_dummy_netdev combination.
Using alloc_netdev() with init_dummy_netdev might cause some memory
corruption at the driver removal side.
Fixes: 61cdb09ff760 ("wifi: qtnfmac: allocate dummy net_device dynamically")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
index f8f55db2f454..f66eb43094d4 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
@@ -372,8 +372,7 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto error;
}
- bus->mux_dev = alloc_netdev(0, "dummy", NET_NAME_UNKNOWN,
- init_dummy_netdev);
+ bus->mux_dev = alloc_netdev_dummy(0);
if (!bus->mux_dev) {
ret = -ENOMEM;
goto error;
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Peng Fan @ 2024-04-09 13:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: Peng Fan (OSS), Cristian Marussi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZhU6C2Ovh7xxeREP@bogus>
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX
> BBM protocol
>
> On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote:
> >
> > ok, will add more comment in the patch for the commands.
> >
>
> No I meant add document/description similar to SCMI spec for each of these
> commands. Not just one line comment. For std protocols, we can refer spec,
> for these vendor protocols, just one like comment will not suffice. Describe in
> more details and hence the request for separate TXT file for that.
> Hope that is clear now, I have mentioned it several times already.
I see, will try to work with our firmware developers to write the details.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] fw_devlink overlay fix
From: Herve Codina @ 2024-04-09 13:02 UTC (permalink / raw)
To: Saravana Kannan
Cc: Geert Uytterhoeven, Rob Herring, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi,
Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20240409053704.428336-1-saravanak@google.com>
Hi Saravana,
+CC Luca and Thomas
On Mon, 8 Apr 2024 22:37:01 -0700
Saravana Kannan <saravanak@google.com> wrote:
> Don't bother reviewing this patch. It needs to be tested and possibly
> refactored first.
>
> Geert and Herve,
>
> This patch serious should hopefully fix both of your use cases
> [1][2][3]. Can you please check to make sure the device links created
> to/from the overlay devices are to/from the right ones?
>
> I've only compile tested it. If I made some obvious mistake, feel free
> to fix it and give it a shot.
>
> Cc: Rob Herring <robh@kernel.org>
>
> [1] - https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
> [2] - https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
> [3] - https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
>
I tested your patches.
Concerning my use cases, they fix the issue described in
https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
But not the one described in
https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
A link is still present between the i2c@600 and the PCI device.
instead of the i2c@600 and the pci-ep-bus.
Adding the patch clearing the FWNODE_FLAG_NOT_DEVICE in device_add() available
at [1] on top of your patches fixes the link issue.
With this additional patch applied, the link is present between the i2c@600
and the pci-ep-bus.
[1] https://lore.kernel.org/lkml/20240220111044.133776-2-herve.codina@bootlin.com/
Best regards,
Hervé
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] Revert "treewide: Fix probing of devices in DT overlays"
From: Rob Herring @ 2024-04-09 13:14 UTC (permalink / raw)
To: Saravana Kannan
Cc: Herve Codina, Geert Uytterhoeven, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi
In-Reply-To: <20240409053704.428336-2-saravanak@google.com>
On Tue, Apr 9, 2024 at 12:37 AM Saravana Kannan <saravanak@google.com> wrote:
>
> This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924.
Please say *why* we are reverting. And you still need a S-o-b.
And you are missing some maintainers.
Rob
_______________________________________________
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 v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Vitor Soares @ 2024-04-09 13:22 UTC (permalink / raw)
To: Lucas Stach, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <9ce35b9bb5a15891f6bd01bd54b7dc84b3ba4021.camel@pengutronix.de>
Hi Lucas,
Thanks for your feedback.
On Tue, 2024-04-09 at 11:13 +0200, Lucas Stach wrote:
> Hi Vitor,
>
> Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares:
> > From: Vitor Soares <vitor.soares@toradex.com>
> >
> > The pgc_vpu_* nodes miss the reference to the power domain parent,
> > leading the system to hang during the resume.
> >
> This change is not correct. The vpumix domain is controlled through
> the
> imx8mm-vpu-blk-ctrl and must not be directly triggered by the child
> domains in order to guarantee proper power sequencing.
>
> If the sequencing is incorrect for resume, it needs to be fixed in
> the
> blk-ctrl driver. I'll happily assist if you have any questions about
> this intricate mix between GPC and blk-ctrl hardware/drivers.
I'm new into the topic, so I tried to follow same approach as in imx8mp
DT. I also checked the imx8mq DT and it only have one domain for the
VPU in the GPC. It seem blk-ctrl also dependes on pgc_vpu_* to work
properly.
The blk-ctrl driver hangs on imx8m_blk_ctrl_power_on() when access the
ip registers for the soft reset. I tried to power-up the before the
soft reset, but it didn't work.
Do you have an idea how we can address this within blk-ctrl?
Best regards,
Vitor
>
> Regards,
> Lucas
>
> > As these PU domains are nested inside the vpumix domain, let's
> > reference
> > it accordingly. After this change, the suspend/resume is working.
> >
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Cc: <stable@vger.kernel.org>
> > Closes:
> > https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> > Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
> > Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> > ---
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > index 8a1b42b94dce..97d0c6d23ad8 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
> > pgc_vpu_g1: power-domain@7
> > {
> > #power-domain-cells
> > = <0>;
> > reg =
> > <IMX8MM_POWER_DOMAIN_VPUG1>;
> > + power-domains =
> > <&pgc_vpumix>;
> > };
> >
> > pgc_vpu_g2: power-domain@8
> > {
> > #power-domain-cells
> > = <0>;
> > reg =
> > <IMX8MM_POWER_DOMAIN_VPUG2>;
> > + power-domains =
> > <&pgc_vpumix>;
> > };
> >
> > pgc_vpu_h1: power-domain@9
> > {
> > #power-domain-cells
> > = <0>;
> > reg =
> > <IMX8MM_POWER_DOMAIN_VPUH1>;
> > + power-domains =
> > <&pgc_vpumix>;
> > };
> >
> > pgc_dispmix:
> > power-domain@10 {
>
_______________________________________________
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 2/4] coresight: Add support for multiple output ports on the funnel
From: Tao Zhang @ 2024-04-09 13:22 UTC (permalink / raw)
To: Suzuki K Poulose, Mathieu Poirier, Alexander Shishkin,
Konrad Dybcio, Mike Leach, Rob Herring, Krzysztof Kozlowski
Cc: Jinlong Mao, Leo Yan, Greg Kroah-Hartman, coresight,
linux-arm-kernel, linux-kernel, devicetree, Tingwei Zhang,
Yuanfang Zhang, Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <a8947ac4-e251-47ba-b44a-6f4fc58f1aac@arm.com>
On 4/9/2024 3:13 PM, Suzuki K Poulose wrote:
> Hi
>
> On 29/03/2024 09:27, Tao Zhang wrote:
>>
>> On 3/22/2024 12:41 AM, Suzuki K Poulose wrote:
>>> On 21/03/2024 08:32, Tao Zhang wrote:
>>>> Funnel devices are now capable of supporting multiple-inputs and
>>>> multiple-outputs configuration with in built hardware filtering
>>>> for TPDM devices. Add software support to this function. Output
>>>> port is selected according to the source in the trace path.
>>>>
>>>> The source of the input port on funnels will be marked in the
>>>> device tree.
>>>> e.g.
>>>> tpdm@xxxxxxx {
>>>> ... ... ... ...
>>>> };
>>>>
>>>> funnel_XXX: funnel@xxxxxxx {
>>>> ... ... ... ...
>>>> out-ports {
>>>> ... ... ... ...
>>>> port@x {
>>>> ... ... ... ...
>>>> label = "xxxxxxx.tpdm"; <-- To label the source
>>>> }; corresponding to the output
>>>> ... ... ... ... connection "port@x". And this
>>>> }; is a hardware static
>>>> connections.
>>>> ... ... ... ... Here needs to refer to hardware
>>>> }; design.
>>>>
>>>> Then driver will parse the source label marked in the device tree, and
>>>> save it to the coresight path. When the function needs to know the
>>>> source label, it could obtain it from coresight path parameter.
>>>> Finally,
>>>> the output port knows which source it corresponds to, and it also
>>>> knows
>>>> which input port it corresponds to.
>>>
>>> Why do we need labels ? We have connection information for all devices
>>> (both in and out), so, why do we need this label to find a device ?
>>
>> Because our funnel's design has multi-output ports, the data stream
>> will not
>>
>> know which output port should pass in building the data trace path.
>> This source
>>
>> label can make the data stream find the right output port to go.
>>
>>>
>>> And also, I thought TPDM is a source device, why does a funnel output
>>> port link to a source ?
>>
>> No, this label doesn't mean this funnel output port link to a source,
>> it just let
>>
>> the output port know its data source.
>>
>>>
>>> Are these funnels programmable ? Or, are they static ? If they are
>>> static, do these need to be described in the DT ? If they are simply
>>> acting as a "LINK" (or HWFIFO ?)
>>
>> These funnels are static, and we will add the "label" to the DT to
>> describe the
>>
>> multi-output ports for these funnels.
>
> I think there is still a bit of confusion. By "Dynamic" I mean,
> the "dynamic funnel" (explicit port enablement via MMIO) vs "static
> funnel" (no programming, always ON).
>
> So, coming to your example, do we need to "explicitly" enable trace
> flow for an "input" and/or an "output" port in your "funnel" ?
Sorry for my misunderstanding in the previous mails. Our funnels are
programmable just like the common dynamic funnels.
In our solution, we just make funnels have multiple output ports
connected to different devices or ports. When we use it, we still
enable the input port through programming. Our solution is to know which
input port the expected data comes from based on the
source label corresponding to the output port. This way we can build the
expected trace path. In other respects, it is used the same
as common dynamic funnels.
Best,
Tao
>
>
>>
>> "If they are simply acting as a "LINK" (or HWFIFO ?) " I'm not sure
>> what's the meaning
>
> i.e, Like TMC-ETF in HWFIFO mode. In this mode, the TMC-ETF is acting
> like a cache for easing ATB data load, by providing h/w buffering.
> (In your case, it may not be providing any buffering, it doesn't matter
> either way, as it is not visible to the driver).
>
> Suzuki
>
>>
>> of this. Could you describe it in detail?
>>
>>
>> Best,
>>
>> Tao
>>
>>>
>>> Suzuki
>>>
>>>>
>>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-core.c | 81
>>>> ++++++++++++++++---
>>>> .../hwtracing/coresight/coresight-platform.c | 5 ++
>>>> include/linux/coresight.h | 2 +
>>>> 3 files changed, 75 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c
>>>> b/drivers/hwtracing/coresight/coresight-core.c
>>>> index 5dde597403b3..b1b5e6d9ec7a 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-core.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>>>> @@ -113,15 +113,63 @@ struct coresight_device
>>>> *coresight_get_percpu_sink(int cpu)
>>>> }
>>>> EXPORT_SYMBOL_GPL(coresight_get_percpu_sink);
>>>> +static struct coresight_device *coresight_get_source(struct
>>>> list_head *path)
>>>> +{
>>>> + struct coresight_device *csdev;
>>>> +
>>>> + if (!path)
>>>> + return NULL;
>>>> +
>>>> + csdev = list_first_entry(path, struct coresight_node,
>>>> link)->csdev;
>>>> + if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
>>>> + return NULL;
>>>> +
>>>> + return csdev;
>>>> +}
>>>> +
>>>> +/**
>>>> + * coresight_source_filter - checks whether the connection matches
>>>> the source
>>>> + * of path if connection is binded to specific source.
>>>> + * @path: The list of devices
>>>> + * @conn: The connection of one outport
>>>> + *
>>>> + * Return zero if the connection doesn't have a source binded or
>>>> source of the
>>>> + * path matches the source binds to connection.
>>>> + */
>>>> +static int coresight_source_filter(struct list_head *path,
>>>> + struct coresight_connection *conn)
>>>> +{
>>>> + int ret = 0;
>>>> + struct coresight_device *source = NULL;
>>>> +
>>>> + if (conn->source_label == NULL)
>>>> + return ret;
>>>> +
>>>> + source = coresight_get_source(path);
>>>> + if (source == NULL)
>>>> + return ret;
>>>> +
>>>> + if (strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>>>> + conn->source_label))
>>>> + ret = 0;
>>>> + else
>>>> + ret = -1;
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> static struct coresight_connection *
>>>> coresight_find_out_connection(struct coresight_device *src_dev,
>>>> - struct coresight_device *dest_dev)
>>>> + struct coresight_device *dest_dev,
>>>> + struct list_head *path)
>>>> {
>>>> int i;
>>>> struct coresight_connection *conn;
>>>> for (i = 0; i < src_dev->pdata->nr_outconns; i++) {
>>>> conn = src_dev->pdata->out_conns[i];
>>>> + if (coresight_source_filter(path, conn))
>>>> + continue;
>>>> if (conn->dest_dev == dest_dev)
>>>> return conn;
>>>> }
>>>> @@ -312,7 +360,8 @@ static void coresight_disable_sink(struct
>>>> coresight_device *csdev)
>>>> static int coresight_enable_link(struct coresight_device *csdev,
>>>> struct coresight_device *parent,
>>>> - struct coresight_device *child)
>>>> + struct coresight_device *child,
>>>> + struct list_head *path)
>>>> {
>>>> int ret = 0;
>>>> int link_subtype;
>>>> @@ -321,8 +370,8 @@ static int coresight_enable_link(struct
>>>> coresight_device *csdev,
>>>> if (!parent || !child)
>>>> return -EINVAL;
>>>> - inconn = coresight_find_out_connection(parent, csdev);
>>>> - outconn = coresight_find_out_connection(csdev, child);
>>>> + inconn = coresight_find_out_connection(parent, csdev, path);
>>>> + outconn = coresight_find_out_connection(csdev, child, path);
>>>> link_subtype = csdev->subtype.link_subtype;
>>>> if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG &&
>>>> IS_ERR(inconn))
>>>> @@ -341,7 +390,8 @@ static int coresight_enable_link(struct
>>>> coresight_device *csdev,
>>>> static void coresight_disable_link(struct coresight_device *csdev,
>>>> struct coresight_device *parent,
>>>> - struct coresight_device *child)
>>>> + struct coresight_device *child,
>>>> + struct list_head *path)
>>>> {
>>>> int i;
>>>> int link_subtype;
>>>> @@ -350,8 +400,8 @@ static void coresight_disable_link(struct
>>>> coresight_device *csdev,
>>>> if (!parent || !child)
>>>> return;
>>>> - inconn = coresight_find_out_connection(parent, csdev);
>>>> - outconn = coresight_find_out_connection(csdev, child);
>>>> + inconn = coresight_find_out_connection(parent, csdev, path);
>>>> + outconn = coresight_find_out_connection(csdev, child, path);
>>>> link_subtype = csdev->subtype.link_subtype;
>>>> if (link_ops(csdev)->disable) {
>>>> @@ -507,7 +557,7 @@ static void coresight_disable_path_from(struct
>>>> list_head *path,
>>>> case CORESIGHT_DEV_TYPE_LINK:
>>>> parent = list_prev_entry(nd, link)->csdev;
>>>> child = list_next_entry(nd, link)->csdev;
>>>> - coresight_disable_link(csdev, parent, child);
>>>> + coresight_disable_link(csdev, parent, child, path);
>>>> break;
>>>> default:
>>>> break;
>>>> @@ -588,7 +638,7 @@ int coresight_enable_path(struct list_head
>>>> *path, enum cs_mode mode,
>>>> case CORESIGHT_DEV_TYPE_LINK:
>>>> parent = list_prev_entry(nd, link)->csdev;
>>>> child = list_next_entry(nd, link)->csdev;
>>>> - ret = coresight_enable_link(csdev, parent, child);
>>>> + ret = coresight_enable_link(csdev, parent, child, path);
>>>> if (ret)
>>>> goto err;
>>>> break;
>>>> @@ -802,7 +852,8 @@ static void coresight_drop_device(struct
>>>> coresight_device *csdev)
>>>> */
>>>> static int _coresight_build_path(struct coresight_device *csdev,
>>>> struct coresight_device *sink,
>>>> - struct list_head *path)
>>>> + struct list_head *path,
>>>> + struct coresight_device *source)
>>>> {
>>>> int i, ret;
>>>> bool found = false;
>>>> @@ -814,7 +865,7 @@ static int _coresight_build_path(struct
>>>> coresight_device *csdev,
>>>> if (coresight_is_percpu_source(csdev) &&
>>>> coresight_is_percpu_sink(sink) &&
>>>> sink == per_cpu(csdev_sink,
>>>> source_ops(csdev)->cpu_id(csdev))) {
>>>> - if (_coresight_build_path(sink, sink, path) == 0) {
>>>> + if (_coresight_build_path(sink, sink, path, source) == 0) {
>>>> found = true;
>>>> goto out;
>>>> }
>>>> @@ -825,8 +876,12 @@ static int _coresight_build_path(struct
>>>> coresight_device *csdev,
>>>> struct coresight_device *child_dev;
>>>> child_dev = csdev->pdata->out_conns[i]->dest_dev;
>>>> + if (csdev->pdata->out_conns[i]->source_label &&
>>>> + !strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>>>> + csdev->pdata->out_conns[i]->source_label))
>>>> + continue;
>>>> if (child_dev &&
>>>> - _coresight_build_path(child_dev, sink, path) == 0) {
>>>> + _coresight_build_path(child_dev, sink, path, source)
>>>> == 0) {
>>>> found = true;
>>>> break;
>>>> }
>>>> @@ -871,7 +926,7 @@ struct list_head *coresight_build_path(struct
>>>> coresight_device *source,
>>>> INIT_LIST_HEAD(path);
>>>> - rc = _coresight_build_path(source, sink, path);
>>>> + rc = _coresight_build_path(source, sink, path, source);
>>>> if (rc) {
>>>> kfree(path);
>>>> return ERR_PTR(rc);
>>>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
>>>> b/drivers/hwtracing/coresight/coresight-platform.c
>>>> index 9d550f5697fa..f553fb20966d 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>>>> @@ -205,6 +205,7 @@ static int of_coresight_parse_endpoint(struct
>>>> device *dev,
>>>> struct fwnode_handle *rdev_fwnode;
>>>> struct coresight_connection conn = {};
>>>> struct coresight_connection *new_conn;
>>>> + const char *label;
>>>> do {
>>>> /* Parse the local port details */
>>>> @@ -243,6 +244,10 @@ static int of_coresight_parse_endpoint(struct
>>>> device *dev,
>>>> conn.dest_fwnode = fwnode_handle_get(rdev_fwnode);
>>>> conn.dest_port = rendpoint.port;
>>>> + conn.source_label = NULL;
>>>> + if (!of_property_read_string(ep, "label", &label))
>>>> + conn.source_label = label;
>>>> +
>>>> new_conn = coresight_add_out_conn(dev, pdata, &conn);
>>>> if (IS_ERR_VALUE(new_conn)) {
>>>> fwnode_handle_put(conn.dest_fwnode);
>>>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>>>> index e8b6e388218c..a9c06ef9bbb2 100644
>>>> --- a/include/linux/coresight.h
>>>> +++ b/include/linux/coresight.h
>>>> @@ -167,6 +167,7 @@ struct coresight_desc {
>>>> * struct coresight_connection - representation of a single
>>>> connection
>>>> * @src_port: a connection's output port number.
>>>> * @dest_port: destination's input port number @src_port is
>>>> connected to.
>>>> + * @source_label: source component's label.
>>>> * @dest_fwnode: destination component's fwnode handle.
>>>> * @dest_dev: a @coresight_device representation of the component
>>>> connected to @src_port. NULL until the device is created
>>>> @@ -195,6 +196,7 @@ struct coresight_desc {
>>>> struct coresight_connection {
>>>> int src_port;
>>>> int dest_port;
>>>> + const char *source_label;
>>>> struct fwnode_handle *dest_fwnode;
>>>> struct coresight_device *dest_dev;
>>>> struct coresight_sysfs_link *link;
>>>
>
_______________________________________________
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] perf vendor events arm64: AmpereOne/AmpereOneX: Mark L1D_CACHE_INVAL impacted by errata
From: James Clark @ 2024-04-09 13:33 UTC (permalink / raw)
To: Ilkka Koskinen
Cc: Will Deacon, Peter Zijlstra, Ingo Molnar, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, linux-arm-kernel,
linux-perf-users, linux-kernel, John Garry, Mike Leach, Leo Yan,
Arnaldo Carvalho de Melo, Namhyung Kim, Ian Rogers
In-Reply-To: <20240408214022.541839-1-ilkka@os.amperecomputing.com>
On 08/04/2024 22:40, Ilkka Koskinen wrote:
> L1D_CACHE_INVAL overcounts in certain situations. See AC03_CPU_41 and
> AC04_CPU_1 for more details. Mark the event impacted by the errata.
>
> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
> ---
> tools/perf/pmu-events/arch/arm64/ampere/ampereone/cache.json | 4 +++-
> tools/perf/pmu-events/arch/arm64/ampere/ampereonex/cache.json | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/cache.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/cache.json
> index 7a2b7b200f14..ac75f12e27bf 100644
> --- a/tools/perf/pmu-events/arch/arm64/ampere/ampereone/cache.json
> +++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereone/cache.json
> @@ -9,7 +9,9 @@
> "ArchStdEvent": "L1D_CACHE_REFILL_RD"
> },
> {
> - "ArchStdEvent": "L1D_CACHE_INVAL"
> + "ArchStdEvent": "L1D_CACHE_INVAL",
> + "Errata": "Errata AC03_CPU_41",
> + "BriefDescription": "L1D cache invalidate. Impacted by errata -"
> },
> {
> "ArchStdEvent": "L1D_TLB_REFILL_RD"
> diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/cache.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/cache.json
> index c50d8e930b05..f4bfe7083a6b 100644
> --- a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/cache.json
> +++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/cache.json
> @@ -9,7 +9,9 @@
> "ArchStdEvent": "L1D_CACHE_REFILL_RD"
> },
> {
> - "ArchStdEvent": "L1D_CACHE_INVAL"
> + "ArchStdEvent": "L1D_CACHE_INVAL",
> + "Errata": "Errata AC04_CPU_1",
> + "BriefDescription": "L1D cache invalidate. Impacted by errata -"
> },
> {
> "ArchStdEvent": "L1D_TLB_REFILL_RD"
Reviewed-by: James Clark <james.clark@arm.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 v2 1/5] ARM: dts: aspeed: greatlakes: correct Mellanox multi-host property
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Krzysztof Kozlowski, devicetree, Andrew Jeffery, Joel Stanley,
linux-arm-kernel, Conor Dooley, linux-kernel, linux-aspeed
In-Reply-To: <20240405064624.18997-1-krzysztof.kozlowski@linaro.org>
On Fri, 05 Apr 2024 08:46:20 +0200, Krzysztof Kozlowski wrote:
> "mlx,multi-host" is using incorrect vendor prefix and is not documented.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Changes in v2:
> 1. None
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-greatlakes.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y aspeed/aspeed-bmc-ampere-mtmitchell.dtb aspeed/aspeed-bmc-facebook-greatlakes.dtb aspeed/aspeed-bmc-facebook-harma.dtb aspeed/aspeed-bmc-facebook-yosemite4.dtb aspeed/aspeed-bmc-facebook-yosemitev2.dtb' for 20240405064624.18997-1-krzysztof.kozlowski@linaro.org:
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-harma.dtb: ftgmac@1e690000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'mellanox,multi-host' were unexpected)
from schema $id: http://devicetree.org/schemas/net/faraday,ftgmac100.yaml#
_______________________________________________
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] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Josua Mayer
Cc: Conor Dooley, Andrew Lunn, Gregory Clement, Krzysztof Kozlowski,
devicetree, Rob Herring, Yazan Shhady, Sebastian Hesselbarth,
linux-kernel, linux-arm-kernel
In-Reply-To: <20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com>
On Thu, 04 Apr 2024 17:35:04 +0200, Josua Mayer wrote:
> SolidRun CN9130 SoM is a mostly pin-comptible replacement for Armada 388
> SoM used in Clearfog and Clearfog Pro boards.
>
> 1. Add new binding for compatible strings closely matching the original.
>
> 2. Add device-tree includes for SoM and carrier shared design.
>
> 3. Add device-tree for both Clearfog Base and Pro.
>
> While dtbs_check is happy with LED descriptions behind dsa switch,
> functionally they require supporting code by Andrew Lunn:
> https://lore.kernel.org/r/20240401-v6-8-0-net-next-mv88e6xxx-leds-v4-v3-0-221b3fa55f78@lunn.ch
>
> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
> CN9130 SoM has a different footprint from Armada 388 SoM.
> Components on the carrier board below the SoM may collide causing
> damage, such as on Clearfog Base.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Changes in v2:
> - rewrote dt bindings dropping unnecessary compatibles
> (Reported-By: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>)
> - added bindings for two additional boards (cn9131/9132)
> support planned for the coming weeks, mostly serves
> illustrational purposes, to understand cn913x variants
> - cf-pro: add description for LEDs behind DSA switch
> - cf-base: add description for LEDs behind PHYs
> (Reported-By: Andrew Lunn <andrew@lunn.ch>)
> - Link to v1: https://lore.kernel.org/r/20240321-cn9130-som-v1-0-711127a409ae@solid-run.com
>
> ---
> Josua Mayer (3):
> dt-bindings: arm64: marvell: add solidrun cn9130 som based boards
> dt-bindings: arm64: marvell: add solidrun cn9132 CEX-7 evaluation board
> arm64: dts: add description for solidrun cn9130 som and clearfog boards
>
> .../bindings/arm/marvell/armada-7k-8k.yaml | 18 +
> arch/arm64/boot/dts/marvell/Makefile | 2 +
> arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 178 ++++++++++
> arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 367 +++++++++++++++++++++
> arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 193 +++++++++++
> arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 159 +++++++++
> 6 files changed, 917 insertions(+)
> ---
> base-commit: 4cece764965020c22cff7665b18a012006359095
> change-id: 20240318-cn9130-som-848e86acb0ac
>
> Sincerely,
> --
> Josua Mayer <josua@solid-run.com>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y marvell/cn9130-cf-base.dtb marvell/cn9130-cf-pro.dtb' for 20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com:
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: ap807: $nodename:0: 'ap807' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f0000000: $nodename:0: 'config-space@f0000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f0000000: timer: {'compatible': ['arm,armv8-timer'], 'interrupts': [[1, 13, 3848], [1, 14, 3848], [1, 11, 3848], [1, 10, 3848]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f0000000: pmu: {'compatible': ['arm,cortex-a72-pmu'], 'interrupt-parent': [[2]], 'interrupts': [[17]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/odmi@300000: failed to match any schema with compatible: ['marvell,odmi-controller']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/gicp@3f0040: failed to match any schema with compatible: ['marvell,ap806-gicp']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0100: failed to match any schema with compatible: ['marvell,armada-8k-pic']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0200: failed to match any schema with compatible: ['marvell,ap806-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/spi@510600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@6e0000: clocks: [[4, 4]] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@6e0000: clock-names: ['core'] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@6e0000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@6f4000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f4000/pinctrl: failed to match any schema with compatible: ['marvell,ap806-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: gpio@1040: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f4000/clock: failed to match any schema with compatible: ['marvell,ap807-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@6f8000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f8000/thermal-sensor@80: failed to match any schema with compatible: ['marvell,armada-ap807-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /ap807/config-space@f0000000/system-controller@6f8000/clock-cpu: failed to match any schema with compatible: ['marvell,ap807-cpu-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: cp0: $nodename:0: 'cp0' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: config-space@f2000000: $nodename:0: 'config-space@f2000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/phy@120000: failed to match any schema with compatible: ['marvell,comphy-cp110']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000: failed to match any schema with compatible: ['marvell,cp110-icu']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@10: failed to match any schema with compatible: ['marvell,cp110-icu-nsr']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@50: failed to match any schema with compatible: ['marvell,cp110-icu-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@440000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/system-controller@440000/clock: failed to match any schema with compatible: ['marvell,cp110-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: gpio@100: Unevaluated properties are not allowed ('gpio-ranges', 'sim-select-hog' were unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: ap807: $nodename:0: 'ap807' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: gpio@140: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f0000000: $nodename:0: 'config-space@f0000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f0000000: timer: {'compatible': ['arm,armv8-timer'], 'interrupts': [[1, 13, 3848], [1, 14, 3848], [1, 11, 3848], [1, 10, 3848]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f0000000: pmu: {'compatible': ['arm,cortex-a72-pmu'], 'interrupt-parent': [[2]], 'interrupts': [[17]]} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/system-controller@440000/pinctrl: failed to match any schema with compatible: ['marvell,cp115-standalone-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: system-controller@400000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/system-controller@400000/thermal-sensor@70: failed to match any schema with compatible: ['marvell,armada-cp110-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: usb@500000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode', 'vbus-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: usb@510000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: sata@540000: sata-port@1: 'anyOf' conditional failed, one must be fixed:
'phys' is a required property
'target-supply' is a required property
from schema $id: http://devicetree.org/schemas/ata/ahci-platform.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/spi@700600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/spi@700680: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/odmi@300000: failed to match any schema with compatible: ['marvell,odmi-controller']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/gicp@3f0040: failed to match any schema with compatible: ['marvell,ap806-gicp']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0100: failed to match any schema with compatible: ['marvell,armada-8k-pic']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/config-space@f2000000/trng@760000: failed to match any schema with compatible: ['marvell,armada-8k-rng', 'inside-secure,safexcel-eip76']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: mmc@780000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: crypto@800000: 'dma-coherent' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/interrupt-controller@3f0200: failed to match any schema with compatible: ['marvell,ap806-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/pcie@f2600000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@400000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/pcie@f2620000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-base.dtb: /cp0/pcie@f2640000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@420000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@440000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/xor@460000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/spi@510600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@6e0000: clocks: [[4, 4]] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@6e0000: clock-names: ['core'] is too short
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@6e0000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@6f4000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f4000/pinctrl: failed to match any schema with compatible: ['marvell,ap806-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: gpio@1040: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f4000/clock: failed to match any schema with compatible: ['marvell,ap807-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@6f8000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f8000/thermal-sensor@80: failed to match any schema with compatible: ['marvell,armada-ap807-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /ap807/config-space@f0000000/system-controller@6f8000/clock-cpu: failed to match any schema with compatible: ['marvell,ap807-cpu-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: cp0: $nodename:0: 'cp0' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: config-space@f2000000: $nodename:0: 'config-space@f2000000' does not match '^([a-z][a-z0-9\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/phy@120000: failed to match any schema with compatible: ['marvell,comphy-cp110']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000: failed to match any schema with compatible: ['marvell,cp110-icu']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@10: failed to match any schema with compatible: ['marvell,cp110-icu-nsr']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/interrupt-controller@1e0000/interrupt-controller@50: failed to match any schema with compatible: ['marvell,cp110-icu-sei']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@440000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/system-controller@440000/clock: failed to match any schema with compatible: ['marvell,cp110-clock']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: gpio@100: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: gpio@140: Unevaluated properties are not allowed ('gpio-ranges' was unexpected)
from schema $id: http://devicetree.org/schemas/gpio/gpio-mvebu.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/system-controller@440000/pinctrl: failed to match any schema with compatible: ['marvell,cp115-standalone-pinctrl']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: system-controller@400000: compatible: ['syscon', 'simple-mfd'] is too short
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/system-controller@400000/thermal-sensor@70: failed to match any schema with compatible: ['marvell,armada-cp110-thermal']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: usb@500000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode', 'vbus-supply' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: usb@510000: Unevaluated properties are not allowed ('dma-coherent', 'dr_mode' were unexpected)
from schema $id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: sata@540000: sata-port@1: 'anyOf' conditional failed, one must be fixed:
'phys' is a required property
'target-supply' is a required property
from schema $id: http://devicetree.org/schemas/ata/ahci-platform.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6a0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/xor@6c0000: failed to match any schema with compatible: ['marvell,armada-7k-xor', 'marvell,xor-v2']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/spi@700600: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/spi@700680: failed to match any schema with compatible: ['marvell,armada-380-spi']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/config-space@f2000000/trng@760000: failed to match any schema with compatible: ['marvell,armada-8k-rng', 'inside-secure,safexcel-eip76']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: mmc@780000: Unevaluated properties are not allowed ('dma-coherent' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/marvell,xenon-sdhci.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: crypto@800000: 'dma-coherent' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/pcie@f2600000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/pcie@f2620000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dtb: /cp0/pcie@f2640000: failed to match any schema with compatible: ['marvell,armada8k-pcie', 'snps,dw-pcie']
_______________________________________________
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: mt7622: fix "emmc" pinctrl mux
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Ryder Lee, Sean Wang, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, AngeloGioacchino Del Regno, devicetree,
Rafał Miłecki, linux-mediatek, Matthias Brugger
In-Reply-To: <20240408100040.25997-1-zajec5@gmail.com>
On Mon, 08 Apr 2024 12:00:40 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Value "emmc_rst" is a group name and should be part of the "groups"
> property.
>
> This fixes:
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: pinctrl@10211000: emmc-pins-default:mux:function: ['emmc', 'emmc_rst'] is too long
> from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
> arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: pinctrl@10211000: emmc-pins-default:mux:function: ['emmc', 'emmc_rst'] is too long
> from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
>
> Fixes: 3725ba3f5574 ("arm64: dts: mt7622: add pinctrl related device nodes")
> Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board")
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 4 ++--
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y mediatek/mt7622-bananapi-bpi-r64.dtb mediatek/mt7622-rfb1.dtb' for 20240408100040.25997-1-zajec5@gmail.com:
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: pinctrl@10211000: emmc-pins-default:mux:groups: ['emmc', 'emmc_rst'] is too long
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: pinctrl@10211000: emmc-pins-default:mux:groups: ['emmc', 'emmc_rst'] is too long
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
_______________________________________________
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 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Chukun Pan
Cc: devicetree, linux-kernel, Conor Dooley, Heiko Stuebner,
linux-arm-kernel, linux-rockchip, Krzysztof Kozlowski
In-Reply-To: <20240408124005.182565-1-amadeus@jmu.edu.cn>
On Mon, 08 Apr 2024 20:40:05 +0800, Chukun Pan wrote:
> There is a mx25u12835f spi flash on this board, enable it.
>
> [ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y rockchip/rk3568-rock-3a.dtb' for 20240408124005.182565-1-amadeus@jmu.edu.cn:
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:765.3-15: Warning (reg_format): /spi@fe300000/flash@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk356x.dtsi:1091.20-1100.4: Warning (spi_bus_bridge): /spi@fe300000: incorrect #address-cells for SPI bus
also defined at arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:760.6-770.3
arch/arm64/boot/dts/rockchip/rk356x.dtsi:1091.20-1100.4: Warning (spi_bus_bridge): /spi@fe300000: incorrect #size-cells for SPI bus
also defined at arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:760.6-770.3
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:763.10-769.4: Warning (avoid_default_addr_size): /spi@fe300000/flash@0: Relying on default #address-cells value
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts:763.10-769.4: Warning (avoid_default_addr_size): /spi@fe300000/flash@0: Relying on default #size-cells value
_______________________________________________
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 v4 1/2] dt-bindings: arm64: mediatek: add Kontron 3.5"-SBC-i1200
From: Rob Herring @ 2024-04-09 13:38 UTC (permalink / raw)
To: Michael Walle
Cc: Matthias Brugger, Sean Wang, Conor Dooley,
AngeloGioacchino Del Regno, linux-kernel, devicetree,
linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
linux-mediatek
In-Reply-To: <20240408080816.4134370-1-mwalle@kernel.org>
On Mon, 08 Apr 2024 10:08:15 +0200, Michael Walle wrote:
> Add the compatible string for the Kontron 3.5"-SBC-i1200 single board
> computer.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> v4:
> - rebase to latest next
>
> v3:
> - drop description and add to mt8395 existing entry
>
> v2:
> - convert enum to const as there is only one specific board
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y mediatek/mt8395-kontron-3-5-sbc-i1200.dtb' for 20240408080816.4134370-1-mwalle@kernel.org:
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: soc: jpgdec-master: {'compatible': ['mediatek,mt8195-jpgdec'], 'power-domains': [[43, 24]], 'iommus': [[130, 621], [130, 622], [130, 626], [130, 627], [130, 628], [130, 629]], '#address-cells': [[2]], '#size-cells': [[2]], 'ranges': True, 'jpgdec@1a040000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 436469760, 0, 65536]], 'iommus': [[130, 621], [130, 622], [130, 626], [130, 627], [130, 628], [130, 629]], 'interrupts': [[0, 343, 4, 0]], 'clocks': [[34, 3]], 'clock-names': ['jpgdec'], 'power-domains': [[43, 23]]}, 'jpgdec@1a050000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 436535296, 0, 65536]], 'iommus': [[130, 621], [130, 622], [130, 626], [130, 627], [130, 628], [130, 629]], 'interrupts': [[0, 344, 4, 0]], 'clocks': [[34, 4]], 'clock-names': ['jpgdec'], 'power-domains': [[43, 24]]}, 'jpgdec@1b040000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 453246976, 0, 65536]], 'iommus'
: [[112, 653], [112, 654], [112, 658], [112, 659], [112, 660], [112, 661]], 'interrupts': [[0, 348, 4, 0]], 'clocks': [[28, 3]], 'clock-names': ['jpgdec'], 'power-domains': [[43, 25]]}} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: soc: jpgenc-master: {'compatible': ['mediatek,mt8195-jpgenc'], 'power-domains': [[43, 27]], 'iommus': [[112, 647], [112, 648], [112, 649], [112, 652]], '#address-cells': [[2]], '#size-cells': [[2]], 'ranges': True, 'jpgenc@1a030000': {'compatible': ['mediatek,mt8195-jpgenc-hw'], 'reg': [[0, 436404224, 0, 65536]], 'iommus': [[130, 615], [130, 616], [130, 617], [130, 620]], 'interrupts': [[0, 342, 4, 0]], 'clocks': [[34, 2]], 'clock-names': ['jpgenc'], 'power-domains': [[43, 26]]}, 'jpgenc@1b030000': {'compatible': ['mediatek,mt8195-jpgenc-hw'], 'reg': [[0, 453181440, 0, 65536]], 'iommus': [[112, 647], [112, 648], [112, 649], [112, 652]], 'interrupts': [[0, 347, 4, 0]], 'clocks': [[28, 2]], 'clock-names': ['jpgenc'], 'power-domains': [[43, 27]]}} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: syscon@10001000: compatible: ['mediatek,mt8195-infracfg_ao', 'syscon', 'simple-mfd'] is too long
from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: /soc/pwrap@10024000/pmic: failed to match any schema with compatible: ['mediatek,mt6359']
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: /soc/pwrap@10024000/pmic/mt6359rtc: failed to match any schema with compatible: ['mediatek,mt6358-rtc']
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: infra-iommu@10315000: interrupts: [[0, 795, 4, 0], [0, 796, 4, 0], [0, 797, 4, 0], [0, 798, 4, 0], [0, 799, 4, 0]] is too long
from schema $id: http://devicetree.org/schemas/iommu/mediatek,iommu.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: ethernet@11021000: Unevaluated properties are not allowed ('snps,rxpbl', 'snps,txpbl' were unexpected)
from schema $id: http://devicetree.org/schemas/net/mediatek-dwmac.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: regulator: 'BUCK1', 'BUCK2', 'LDO1', 'LDO2', 'LDO3', 'LDO5', 'LDO6', 'LDO7' do not match any of the regexes: '^buck[12]$', '^ldo[123567]$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/regulator/mt6360-regulator.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: t-phy@11e30000: 'power-domains' does not match any of the regexes: '^(usb|pcie|sata)-phy@[0-9a-f]+$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: display@14f06000: clocks: [[30, 14], [30, 43], [30, 44]] is too long
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,split.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c015000: clock-names:0: 'pixel' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c015000: clock-names:1: 'engine' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: mutex@1c101000: 'clock-names', 'reg-names' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/soc/mediatek/mediatek,mutex.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c113000: clock-names:0: 'pixel' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c113000: clock-names:1: 'engine' was expected
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
arch/arm64/boot/dts/mediatek/mt8395-kontron-3-5-sbc-i1200.dtb: dp-intf@1c113000: Additional properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
_______________________________________________
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 0/5] Radxa NIO-12L: Supplies for CPU/GPU and improvements
From: Rob Herring @ 2024-04-09 13:39 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: devicetree, linux-mediatek, krzk+dt, conor+dt, linux-kernel,
kernel, matthias.bgg, linux-arm-kernel
In-Reply-To: <20240409114211.310462-1-angelogioacchino.delregno@collabora.com>
On Tue, 09 Apr 2024 13:42:06 +0200, AngeloGioacchino Del Regno wrote:
> This series performs various improvements and enables PHYs and USB Role
> Switching for proper PM support and to stop relying on the bootloader's
> pre-boot configuration.
> USB Role Switching doesn't include Alternate Modes yet, as this needs
> some more work.
>
> As for the regulator nodes, those were not probing correctly, producing
> unability to resume after PM suspend.
>
> AngeloGioacchino Del Regno (5):
> arm64: dts: mediatek: mt8395-nio-12l: Fix MT6360 regulator nodes names
> arm64: dts: medaitek: mt8395-nio-12l: Set i2c6 pins to bias-disable
> arm64: dts: mediatek: mt8395-nio-12l: Define RSEL in microamperes
> arm64: dts: mediatek: mt8395-nio-12l: Enable PHYs and USB role switch
> arm64: dts: mediatek: mt8395-nio-12l: Add power supplies for CPU/GPU
> scaling
>
> .../dts/mediatek/mt8395-radxa-nio-12l.dts | 106 ++++++++++++++++--
> 1 file changed, 94 insertions(+), 12 deletions(-)
>
> --
> 2.44.0
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y mediatek/mt8395-radxa-nio-12l.dtb' for 20240409114211.310462-1-angelogioacchino.delregno@collabora.com:
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: soc: jpgdec-master: {'compatible': ['mediatek,mt8195-jpgdec'], 'power-domains': [[47, 24]], 'iommus': [[137, 621], [137, 622], [137, 626], [137, 627], [137, 628], [137, 629]], '#address-cells': [[2]], '#size-cells': [[2]], 'ranges': True, 'jpgdec@1a040000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 436469760, 0, 65536]], 'iommus': [[137, 621], [137, 622], [137, 626], [137, 627], [137, 628], [137, 629]], 'interrupts': [[0, 343, 4, 0]], 'clocks': [[38, 3]], 'clock-names': ['jpgdec'], 'power-domains': [[47, 23]]}, 'jpgdec@1a050000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 436535296, 0, 65536]], 'iommus': [[137, 621], [137, 622], [137, 626], [137, 627], [137, 628], [137, 629]], 'interrupts': [[0, 344, 4, 0]], 'clocks': [[38, 4]], 'clock-names': ['jpgdec'], 'power-domains': [[47, 24]]}, 'jpgdec@1b040000': {'compatible': ['mediatek,mt8195-jpgdec-hw'], 'reg': [[0, 453246976, 0, 65536]], 'iommus': [[119,
653], [119, 654], [119, 658], [119, 659], [119, 660], [119, 661]], 'interrupts': [[0, 348, 4, 0]], 'clocks': [[32, 3]], 'clock-names': ['jpgdec'], 'power-domains': [[47, 25]]}} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: soc: jpgenc-master: {'compatible': ['mediatek,mt8195-jpgenc'], 'power-domains': [[47, 27]], 'iommus': [[119, 647], [119, 648], [119, 649], [119, 652]], '#address-cells': [[2]], '#size-cells': [[2]], 'ranges': True, 'jpgenc@1a030000': {'compatible': ['mediatek,mt8195-jpgenc-hw'], 'reg': [[0, 436404224, 0, 65536]], 'iommus': [[137, 615], [137, 616], [137, 617], [137, 620]], 'interrupts': [[0, 342, 4, 0]], 'clocks': [[38, 2]], 'clock-names': ['jpgenc'], 'power-domains': [[47, 26]]}, 'jpgenc@1b030000': {'compatible': ['mediatek,mt8195-jpgenc-hw'], 'reg': [[0, 453181440, 0, 65536]], 'iommus': [[119, 647], [119, 648], [119, 649], [119, 652]], 'interrupts': [[0, 347, 4, 0]], 'clocks': [[32, 2]], 'clock-names': ['jpgenc'], 'power-domains': [[47, 27]]}} should not be valid under {'type': 'object'}
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: pmic@34: charger: 'usb-otg-vbus' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6360.yaml#
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: charger: 'usb-otg-vbus' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/power/supply/mt6360_charger.yaml#
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: regulator: 'BUCK1', 'BUCK2', 'LDO1', 'LDO2', 'LDO3', 'LDO5', 'LDO6', 'LDO7' do not match any of the regexes: '^buck[12]$', '^ldo[123567]$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/regulator/mt6360-regulator.yaml#
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dtb: display@14f06000: clocks: [[34, 14], [34, 43], [34, 44]] is too long
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,split.yaml#
_______________________________________________
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 RFC] arm64: dts: mediatek: mt8183-kodama: Split into base and overlays
From: Rob Herring @ 2024-04-09 13:39 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: AngeloGioacchino Del Regno, Conor Dooley, devicetree,
Krzysztof Kozlowski, linux-mediatek, Matthias Brugger,
linux-arm-kernel, linux-kernel, dianders
In-Reply-To: <20240409095239.627000-1-wenst@chromium.org>
On Tue, 09 Apr 2024 17:52:38 +0800, Chen-Yu Tsai wrote:
> All the SKUs of Kodama share much of their .dts, as evident of the
> inclusion of a common .dtsi file. However this scheme builds each
> .dtb file as a complete device tree.
>
> To deduplicate this, make the common .dtsi file a .dts file, and the
> SKU specific .dts files into .dtso overlay source files. Have the build
> system assemble the SKU specific .dtb files from these components.
>
> The final composite .dtb files increase in size by around 54 kB, or 22.5%,
> due to the inclusion of symbols and fixup tables, and extra phandle
> properties. This could be slightly reduced by dropping the symbol and
> fixup tables after the overlays are fully applied if desired.
>
> However if the bootloader can assemble the end .dtb using the base .dtb
> and overlays, and only those are counted, then the combined size
> decreases by around 165 kB, or 68.7%.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Hi,
>
> This is part of the work I'm looking into and will present at EOSS 2024
> in Seattle [1].
>
> The idea is to reorganize device trees so that devices within a common
> family, instead of having a common .dtsi file, will share a base DTB
> and apply one or more overlays on top. This allows an upstream [2] or
> downstream [3] bundling script to be able to deduplicate the base DTB
> and get some space savings, however minor they are compared to the
> kernel binary executable.
>
> This patch gives a simple conversion, but we could even look into
> converting the entire MT8183 Kukui family, which are all based on the
> "Kukui" hardware reference design.
>
> There are some issues, hence the RFC:
>
> 1. The base .dtb doesn't have a valid board compatible string sequence
> yet. Suppose we used the sequence
>
> "google,kodama", "mediatek,mt8183"
>
> for the base .dtb in this conversion, would that be acceptable? The
> base .dtb would act like a fallback.
>
> 2. The composite .dtb files grow in size substantially, due to the base
> .dtb file being built with overlay support. The symbols and fixup
> tables could be trimmed out with `fdtput`, but there will still be
> extra phandles, and also nodes with /omit-if-no-ref/ that would
> have been removed.
> For this I could maybe come up with a program to minify the DTB. That
> would also work for existing composite .dtb files in-tree.
>
> 3. Such a scheme would require more awareness on the maintainer's part,
> and of the .dtbo authors. The maintainer needs to be aware of how
> the composite .dtb files are assembled. The authors need to know that
> certain constructs, such as /delete-property/ or /delete-node/, won't
> work.
>
> [1] https://eoss24.sched.com/event/1aBGe/second-source-component-probing-on-device-tree-platforms-chen-yu-tsai-google-llc
> [2] https://lore.kernel.org/linux-arm-kernel/20240329032836.141899-1-sjg@chromium.org/
> [3] https://crrev.com/c/5412876
>
> arch/arm64/boot/dts/mediatek/Makefile | 6 ++++++
> ...ukui-kodama-sku16.dts => mt8183-kukui-kodama-sku16.dtso} | 4 ++--
> ...ui-kodama-sku272.dts => mt8183-kukui-kodama-sku272.dtso} | 4 ++--
> ...ui-kodama-sku288.dts => mt8183-kukui-kodama-sku288.dtso} | 4 ++--
> ...ukui-kodama-sku32.dts => mt8183-kukui-kodama-sku32.dtso} | 4 ++--
> .../{mt8183-kukui-kodama.dtsi => mt8183-kukui-kodama.dts} | 0
> 6 files changed, 14 insertions(+), 8 deletions(-)
> rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku16.dts => mt8183-kukui-kodama-sku16.dtso} (90%)
> rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku272.dts => mt8183-kukui-kodama-sku272.dtso} (90%)
> rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku288.dts => mt8183-kukui-kodama-sku288.dtso} (90%)
> rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku32.dts => mt8183-kukui-kodama-sku32.dtso} (90%)
> rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama.dtsi => mt8183-kukui-kodama.dts} (100%)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y mediatek/mt8183-kukui-kodama.dtb' for 20240409095239.627000-1-wenst@chromium.org:
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed:
['mediatek,mt8183'] is too short
'mediatek,mt8183' is not one of ['mediatek,mt2701-evb']
'mediatek,mt8183' is not one of ['mediatek,mt2712-evb']
'mediatek,mt8183' is not one of ['mediatek,mt6580-evbp1']
'mediatek,mt8183' is not one of ['prestigio,pmt5008-3g']
'mediatek,mt8183' is not one of ['fairphone,fp1', 'mundoreader,bq-aquaris5']
'mediatek,mt8183' is not one of ['mediatek,mt6592-evb']
'mediatek,mt8183' is not one of ['mediatek,mt6755-evb']
'mediatek,mt8183' is not one of ['mediatek,mt6765-evb']
'mediatek,mt8183' is not one of ['mediatek,mt6779-evb']
'mediatek,mt8183' is not one of ['mediatek,mt6795-evb', 'sony,xperia-m5']
'mediatek,mt8183' is not one of ['archermind,mt6797-x20-dev', 'mediatek,mt6797-evb']
'mediatek,mt8183' is not one of ['bananapi,bpi-r64', 'mediatek,mt7622-rfb1']
'mediatek,mt8183' is not one of ['mediatek,mt7623a-rfb-emmc', 'mediatek,mt7623a-rfb-nand', 'mediatek,mt7623n-rfb-emmc', 'bananapi,bpi-r2']
'mediatek,mt8183' is not one of ['mediatek,mt7629-rfb']
'mediatek,mt8183' is not one of ['cudy,wr3000-v1', 'xiaomi,ax3000t']
'mediatek,mt8183' is not one of ['acelink,ew-7886cax', 'bananapi,bpi-r3', 'mediatek,mt7986a-rfb']
'mediatek,mt8183' is not one of ['mediatek,mt7986b-rfb']
'mediatek,mt8183' is not one of ['bananapi,bpi-r4']
'mediatek,mt8183' is not one of ['mediatek,mt8127-moose']
'mediatek,mt8183' is not one of ['mediatek,mt8135-evbp1']
'mediatek,mt8183' is not one of ['mediatek,mt8167-pumpkin']
'google,elm-rev8' was expected
'google,hana-rev6' was expected
'google,hana-rev7' was expected
'mediatek,mt8183' is not one of ['mediatek,mt8173-evb']
'google,burnet' was expected
'google,cozmo' was expected
'google,damu' was expected
'mediatek,mt8183' is not one of ['google,fennel-sku0', 'google,fennel-sku1', 'google,fennel-sku2', 'google,fennel-sku6', 'google,fennel-sku7']
'mediatek,mt8183' is not one of ['google,juniper-sku16', 'google,juniper-sku17']
'google,kakadu-rev3' was expected
'google,kakadu-rev3-sku22' was expected
'google,kappa' was expected
'mediatek,mt8183' is not one of ['google,katsu-sku32', 'google,katsu-sku38']
'mediatek,mt8183' is not one of ['google,kodama-sku16', 'google,kodama-sku272', 'google,kodama-sku288', 'google,kodama-sku32']
'mediatek,mt8183' is not one of ['google,krane-sku0', 'google,krane-sku176']
'mediatek,mt8183' is not one of ['google,makomo-sku0', 'google,makomo-sku1']
'mediatek,mt8183' is not one of ['google,pico-sku1', 'google,pico-sku2']
'mediatek,mt8183' is not one of ['google,willow-sku0', 'google,willow-sku1']
'mediatek,mt8183' is not one of ['mediatek,mt8183-evb']
'mediatek,mt8183' is not one of ['mediatek,mt8183-pumpkin']
'google,steelix-sku393219' was expected
'google,steelix-sku393220' was expected
'google,steelix-sku393221' was expected
'google,steelix-sku196609' was expected
'mediatek,mt8183' is not one of ['google,steelix-sku131072', 'google,steelix-sku131073']
'google,tentacruel-sku262147' was expected
'google,tentacruel-sku262151' was expected
'google,tentacruel-sku327681' was expected
'google,tentacruel-sku327683' was expected
'mediatek,mt8183' is not one of ['mediatek,mt8186-evb']
'mediatek,mt8183' is not one of ['mediatek,mt8188-evb']
'google,hayato-rev1' was expected
'google,hayato-rev5-sku2' was expected
'google,spherion-rev3' was expected
'google,spherion-rev4' was expected
'mediatek,mt8183' is not one of ['mediatek,mt8192-evb']
'mediatek,mt8183' is not one of ['google,tomato-rev2', 'google,tomato-rev1']
'google,tomato-rev4' was expected
'mediatek,mt8183' is not one of ['mediatek,mt8195-demo', 'mediatek,mt8195-evb']
'mediatek,mt8183' is not one of ['mediatek,mt8365-evk']
'mediatek,mt8183' is not one of ['mediatek,mt8390-evk']
'mediatek,mt8183' is not one of ['mediatek,mt8395-evk', 'radxa,nio-12l']
'mediatek,mt8183' is not one of ['mediatek,mt8516-pumpkin']
from schema $id: http://devicetree.org/schemas/arm/mediatek.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@c530000: failed to match any schema with compatible: ['mediatek,mt8183-mcucfg', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc0-pins-default:pins-clk:mediatek,pull-down-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc0-pins-uhs:pins-clk:mediatek,pull-down-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc0-pins-uhs:pins-ds:mediatek,pull-down-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc1-pins-default:pins-cmd-dat:mediatek,pull-up-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc1-pins-default:pins-clk:mediatek,pull-down-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc1-pins-uhs:pins-cmd-dat:mediatek,pull-up-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: mmc1-pins-uhs:pins-clk:mediatek,pull-down-adv:0:0: 10 is not one of [0, 1, 2, 3]
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: panel-pins-default: 'panel-reset' does not match any of the regexes: '^pins', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: uart1-pins-default:pins-rts: 'output-enable' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: uart1-pins-sleep:pins-rts: 'output-enable' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: pinctrl@10005000: 'audiopins', 'audiotdmoutoff', 'audiotdmouton', 'ec-ap-int-odl', 'gpio-line-names', 'h1-int-od-l', 'i2c0', 'i2c1', 'i2c2', 'i2c3', 'i2c4', 'i2c5', 'i2c6', 'pp1800-lcd-en', 'ppvarn-lcd-en', 'ppvarp-lcd-en', 'pwm0-pin-default', 'scp', 'spi0', 'spi1', 'spi2', 'spi3', 'spi4', 'spi5', 'touchdefault', 'ts3a227e_pins' do not match any of the regexes: '-pins(-[a-z]+)?$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/pwrap@1000d000/pmic: failed to match any schema with compatible: ['mediatek,mt6358']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/pwrap@1000d000/pmic/mt6358codec: failed to match any schema with compatible: ['mediatek,mt6358-sound']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/pwrap@1000d000/pmic/rtc: failed to match any schema with compatible: ['mediatek,mt6358-rtc']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/audio-controller@11220000: failed to match any schema with compatible: ['mediatek,mt8183-audiosys', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/audio-controller@11220000/mt8183-afe-pcm: failed to match any schema with compatible: ['mediatek,mt8183-audio']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@13000000: failed to match any schema with compatible: ['mediatek,mt8183-mfgcfg', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: dsi@14014000: 'port' is a required property
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dsi.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: dsi@14014000: Unevaluated properties are not allowed ('ports' was unexpected)
from schema $id: http://devicetree.org/schemas/display/mediatek/mediatek,dsi.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@15020000: failed to match any schema with compatible: ['mediatek,mt8183-imgsys', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@16000000: failed to match any schema with compatible: ['mediatek,mt8183-vdecsys', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@17000000: failed to match any schema with compatible: ['mediatek,mt8183-vencsys', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@19000000: failed to match any schema with compatible: ['mediatek,mt8183-ipu_conn', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@19010000: failed to match any schema with compatible: ['mediatek,mt8183-ipu_adl', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@19180000: failed to match any schema with compatible: ['mediatek,mt8183-ipu_core0', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@19280000: failed to match any schema with compatible: ['mediatek,mt8183-ipu_core1', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /soc/syscon@1a000000: failed to match any schema with compatible: ['mediatek,mt8183-camsys', 'syscon']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: thermal-zones: 'tboard1', 'tboard2', 'tzts1', 'tzts2', 'tzts3', 'tzts4', 'tzts5', 'tztsABB' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: /mt8183-sound: failed to match any schema with compatible: ['mediatek,mt8183_mt6358_ts3a227_max98357']
arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtb: bt-sco: '#sound-dai-cells' is a required property
from schema $id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml#
_______________________________________________
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 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
From: Rob Herring @ 2024-04-09 13:39 UTC (permalink / raw)
To: Stanislav Jakubek
Cc: Conor Dooley, phone-devel, linux-arm-kernel, linux-kernel,
Krzysztof Kozlowski, linux-arm-msm, Konrad Dybcio, devicetree,
Bjorn Andersson
In-Reply-To: <32c507337ab80c550fb1df08f7014d1e31eb4c32.1712480582.git.stano.jakubek@gmail.com>
On Sun, 07 Apr 2024 11:05:10 +0200, Stanislav Jakubek wrote:
> Document the Motorola Moto G (2013), which is a smartphone based
> on the Qualcomm MSM8226 SoC.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
> ---
> Changes in V3:
> - no changes
>
> Changes in V2:
> - collect Krzysztof's A-b
>
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/msm8226-motorola-falcon.dtb' for 32c507337ab80c550fb1df08f7014d1e31eb4c32.1712480582.git.stano.jakubek@gmail.com:
arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dtb: syscon@f9011000: compatible: 'anyOf' conditional failed, one must be fixed:
['syscon'] is too short
'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', '
rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl']
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
_______________________________________________
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