* Re: [PATCH 4/4] arm: dts: allwinner: drop underscore in node names
From: Jernej Škrabec @ 2024-03-26 22:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Corentin Labbe, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, Krzysztof Kozlowski
Cc: Krzysztof Kozlowski
In-Reply-To: <20240317184130.157695-4-krzysztof.kozlowski@linaro.org>
Dne nedelja, 17. marec 2024 ob 19:41:30 CET je Krzysztof Kozlowski napisal(a):
> Underscores should not be used in node names (dtc with W=2 warns about
> them), so replace them with hyphens. Use also generic name for pwrseq
> node, because generic naming is favored by Devicetree spec. All the
> clocks affected by this change use clock-output-names, so resulting
> clock name should not change. Functional impact checked with comparing
> before/after DTBs with dtx_diff and fdtdump.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
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 3/4] arm64: dts: allwinner: Orange Pi: delete node by phandle
From: Jernej Škrabec @ 2024-03-26 22:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Corentin Labbe, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <41dcd736-5e58-4b71-ba82-961cd2863a62@linaro.org>
Dne nedelja, 17. marec 2024 ob 19:42:51 CET je Krzysztof Kozlowski napisal(a):
> On 17/03/2024 19:41, Krzysztof Kozlowski wrote:
> > Delete node via phandle, not via full node path, to avoid easy mistakes
> > - if original node name changes, such deletion would be ineffective and
> > not reported by the dtc as error.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > ---
> > arch/arm/boot/dts/allwinner/sun8i-h2-plus-orangepi-r1.dts | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
> Eh, copy-paste, the subject prefix should be "ARM:".
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
I can fix it when applying.
Best regards,
Jernej
>
> Best regards,
> Krzysztof
>
>
_______________________________________________
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] arm64: dts: allwinner: drop underscore in node names
From: Jernej Škrabec @ 2024-03-26 22:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Corentin Labbe, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, Krzysztof Kozlowski
Cc: Krzysztof Kozlowski
In-Reply-To: <20240317184130.157695-2-krzysztof.kozlowski@linaro.org>
Dne nedelja, 17. marec 2024 ob 19:41:28 CET je Krzysztof Kozlowski napisal(a):
> Underscores should not be used in node names (dtc with W=2 warns about
> them), so replace them with hyphens. Use also generic name for pwrseq
> node, because generic naming is favored by Devicetree spec. All the
> clocks affected by this change use clock-output-names, so resulting
> clock name should not change. Functional impact checked with comparing
> before/after DTBs with dtx_diff and fdtdump.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
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/4] arm64: dts: allwinner: Pine H64: correctly remove reg_gmac_3v3
From: Jernej Škrabec @ 2024-03-26 22:16 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Corentin Labbe, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, Krzysztof Kozlowski
Cc: Krzysztof Kozlowski
In-Reply-To: <20240317184130.157695-1-krzysztof.kozlowski@linaro.org>
Dne nedelja, 17. marec 2024 ob 19:41:27 CET je Krzysztof Kozlowski napisal(a):
> There is no "reg_gmac_3v3" device node in sun50i-h6-pine-h64.dts,
> although there is "gmac-3v3" with "reg_gmac_3v3" label, so let's assume
> author wanted to remove that node. Delete node via phandle, not via
> full node path, to fix this.
>
> Fixes: f33a91175029 ("arm64: dts: allwinner: add pineh64 model B")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index b710f1a0f53a..1b6e5595ac6e 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -5,12 +5,12 @@
>
> #include "sun50i-h6-pine-h64.dts"
>
> +/delete-node/ ®_gmac_3v3;
> +
> / {
> model = "Pine H64 model B";
> compatible = "pine64,pine-h64-model-b", "allwinner,sun50i-h6";
>
> - /delete-node/ reg_gmac_3v3;
> -
> wifi_pwrseq: wifi_pwrseq {
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
>
_______________________________________________
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 v5 01/27] iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong PASID
From: Jason Gunthorpe @ 2024-03-26 22:10 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <ZgMcqr6427vk8ei7@google.com>
On Tue, Mar 26, 2024 at 07:06:18PM +0000, Mostafa Saleh wrote:
> On Tue, Mar 26, 2024 at 03:30:16PM -0300, Jason Gunthorpe wrote:
> > On Fri, Mar 22, 2024 at 05:48:52PM +0000, Mostafa Saleh wrote:
> > > Hi Jason,
> > >
> > > On Mon, Mar 04, 2024 at 07:43:49PM -0400, Jason Gunthorpe wrote:
> > > > The SVA code is wired to assume that the SVA is programmed onto the
> > > > mm->pasid. The current core code always does this, so it is fine.
> > > >
> > > > Add a check for clarity.
> > > >
> > > > Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> > > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > > > ---
> > > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > > index 2610e82c0ecd0d..347c2fdd865c1a 100644
> > > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > > > @@ -581,6 +581,9 @@ static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain,
> > > > int ret = 0;
> > > > struct mm_struct *mm = domain->mm;
> > > >
> > > > + if (mm_get_enqcmd_pasid(mm) != id)
> > > > + return -EINVAL;
> > > > +
> > > I am not sure if that is needed, the only caller in the tree is the IOMMU code
> > > and it does the right thing, as that check is removed later anyway, I don’t
> > > think this patch adds much.
> >
> > It really should be backported, when we get drivers that do other
> > things it creates a hazard. I've added a fixes line.
>
> Maybe I am misunderstanding the case, but AFAIU, the only caller for this is
> iommu_sva_bind_device() which is the function populating the pasid, so this
> condition should never hit with the current code.
Yes, but iommufd is going to break this soon.
> And Linux won’t backport new drivers, so there is no need to do that?
Heh, you never know what -stable will backport and the distros are
quite a bit more lax. Seems nicer to fail quickly than get all
corrupted.
Jason
_______________________________________________
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/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties
From: Laurent Pinchart @ 2024-03-26 21:53 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-gpio,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Linus Walleij, Bartosz Golaszewski, Eric Anholt, Stefan Wahren
In-Reply-To: <20240326213053.GA3562515-robh@kernel.org>
Hi Rob,
On Tue, Mar 26, 2024 at 04:30:53PM -0500, Rob Herring wrote:
> On Tue, Mar 26, 2024 at 02:49:01AM +0200, Laurent Pinchart wrote:
> > The raspberrypi,bcm2835-firmware devices requires a dma-ranges property,
> > and, as a result, also needs to specify #address-cells and #size-cells.
> > Those properties have been added to thebcm2835-rpi.dtsi in commits
> > be08d278eb09 ("ARM: dts: bcm283x: Add cells encoding format to firmware
> > bus") and 55c7c0621078 ("ARM: dts: bcm283x: Fix vc4's firmware bus DMA
> > limitations"), but the DT bindings haven't been updated, resulting in
> > validation errors:
>
> I don't understand. We treat no dma-ranges the same as empty dma-ranges
> (dma-ranges;). If we didn't, *every* DT would be broken.
>
> We should never have dma-ranges without ranges either.
Please see v2 :-)
https://lore.kernel.org/linux-arm-kernel/20240326195807.15163-3-laurent.pinchart@ideasonboard.com/
https://lore.kernel.org/linux-arm-kernel/20240326195807.15163-4-laurent.pinchart@ideasonboard.com/
--
Regards,
Laurent Pinchart
_______________________________________________
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 3/8] dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
From: Rob Herring @ 2024-03-26 21:37 UTC (permalink / raw)
To: Andre Przywara
Cc: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rafael J . Wysocki, linux-pm, devicetree,
linux-sunxi, linux-arm-kernel, Brandon Cheo Fusi, Martin Botka,
Martin Botka, Chris Morgan, Ryan Walklin
In-Reply-To: <20240326114743.712167-4-andre.przywara@arm.com>
On Tue, Mar 26, 2024 at 11:47:38AM +0000, Andre Przywara wrote:
> From: Martin Botka <martin.botka@somainline.org>
>
> Compared to the existing Allwinner H6 OPP scheme, the H616 uses a
> similar NVMEM based mechanism to determine the silicon revision, which
> is required to select the right frequency / voltage pair for the OPPs.
> However it limits the maximum frequency for some speed bins, also seems
> to not support all frequencies in all speed bins, which requires us to
> introduce the opp-supported-hw property.
>
> Add this property to the list of allowed properties, also drop the
> requirement for the revision specific opp-microvolt properties, since
> they might not be needed if using opp-supported-hw.
>
> Also use to opportunity to adjust some wording, and drop a sentence
> referring to the Linux driver and the OPP subsystem.
>
> Shorten the existing example and add another example, showcasing the
> opp-supported-hw property.
>
> Signed-off-by: Martin Botka <martin.botka@somainline.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../allwinner,sun50i-h6-operating-points.yaml | 86 +++++++++----------
> 1 file changed, 42 insertions(+), 44 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> index 51f62c3ae1947..d679b2e4a7199 100644
> --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
> @@ -13,25 +13,25 @@ maintainers:
> description: |
> For some SoCs, the CPU frequency subset and voltage value of each
> OPP varies based on the silicon variant in use. Allwinner Process
> - Voltage Scaling Tables defines the voltage and frequency value based
> - on the speedbin blown in the efuse combination. The
> - sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
> - provide the OPP framework with required information.
> + Voltage Scaling Tables define the voltage and frequency values based
> + on the speedbin blown in the efuse combination.
>
> allOf:
> - $ref: opp-v2-base.yaml#
>
> properties:
> compatible:
> - const: allwinner,sun50i-h6-operating-points
> + enum:
> + - allwinner,sun50i-h6-operating-points
> + - allwinner,sun50i-h616-operating-points
>
> nvmem-cells:
> description: |
> A phandle pointing to a nvmem-cells node representing the efuse
> - registers that has information about the speedbin that is used
> + register that has information about the speedbin that is used
> to select the right frequency/voltage value pair. Please refer
> - the for nvmem-cells bindings
> - Documentation/devicetree/bindings/nvmem/nvmem.txt and also
> + to the nvmem-cells bindings in
> + Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the
> examples below.
>
> opp-shared: true
> @@ -47,15 +47,17 @@ patternProperties:
> properties:
> opp-hz: true
> clock-latency-ns: true
> + opp-microvolt: true
> + opp-supported-hw:
As this is an array,
maxItems: 1
> + description: |
Don't need '|'.
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: Rob Herring @ 2024-03-26 21:34 UTC (permalink / raw)
To: Tan Chun Hau
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Emil Renner Berthing, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Simon Horman,
Bartosz Golaszewski, Andrew Halaney, Jisheng Zhang,
Uwe Kleine-König, Russell King, Ley Foon Tan, Jee Heng Sia,
netdev, devicetree, linux-kernel, linux-stm32, linux-arm-kernel,
linux-riscv
In-Reply-To: <20240326052505.197408-2-chunhau.tan@starfivetech.com>
On Mon, Mar 25, 2024 at 10:25:05PM -0700, Tan Chun Hau wrote:
> Add StarFive JH8100 dwmac support.
> The JH8100 dwmac shares the same driver code as the JH7110 dwmac
> and has only one reset signal.
>
> Please refer to below:
>
> JH8100: reset-names = "stmmaceth";
> JH7110: reset-names = "stmmaceth", "ahb";
> JH7100: reset-names = "ahb";
>
> Example usage of JH8100 in the device tree:
>
> gmac0: ethernet@16030000 {
> compatible = "starfive,jh8100-dwmac",
> "starfive,jh7110-dwmac",
> "snps,dwmac-5.20";
> ...
> };
>
> Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> ---
> .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> .../bindings/net/starfive,jh7110-dwmac.yaml | 54 ++++++++++++++-----
> 2 files changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 6b0341a8e0ea..a6d596b7dcf4 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -97,6 +97,7 @@ properties:
> - snps,dwxgmac-2.10
> - starfive,jh7100-dwmac
> - starfive,jh7110-dwmac
> + - starfive,jh8100-dwmac
>
> reg:
> minItems: 1
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index 0d1962980f57..ce018e9768d2 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -18,6 +18,7 @@ select:
> enum:
> - starfive,jh7100-dwmac
> - starfive,jh7110-dwmac
> + - starfive,jh8100-dwmac
> required:
> - compatible
>
> @@ -30,6 +31,10 @@ properties:
> - items:
> - const: starfive,jh7110-dwmac
> - const: snps,dwmac-5.20
> + - items:
> + - const: starfive,jh8100-dwmac
> + - const: starfive,jh7110-dwmac
> + - const: snps,dwmac-5.20
>
> reg:
> maxItems: 1
> @@ -107,20 +112,41 @@ allOf:
> contains:
> const: starfive,jh7110-dwmac
> then:
> - properties:
> - interrupts:
> - minItems: 3
> - maxItems: 3
> -
> - interrupt-names:
> - minItems: 3
> - maxItems: 3
interrupts and interrupt-names are the same, so you can leave them here
instead of duplicating them as you have.
> -
> - resets:
> - minItems: 2
> -
> - reset-names:
> - minItems: 2
> + if:
> + properties:
> + compatible:
> + contains:
> + const: starfive,jh8100-dwmac
> + then:
> + properties:
> + interrupts:
> + minItems: 3
> + maxItems: 3
> +
> + interrupt-names:
> + minItems: 3
> + maxItems: 3
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + const: stmmaceth
> + else:
> + properties:
> + interrupts:
> + minItems: 3
> + maxItems: 3
> +
> + interrupt-names:
> + minItems: 3
> + maxItems: 3
> +
> + resets:
> + minItems: 2
> +
> + reset-names:
> + minItems: 2
>
> unevaluatedProperties: false
>
> --
> 2.25.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties
From: Rob Herring @ 2024-03-26 21:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-gpio,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Linus Walleij, Bartosz Golaszewski, Eric Anholt, Stefan Wahren
In-Reply-To: <20240326004902.17054-2-laurent.pinchart@ideasonboard.com>
On Tue, Mar 26, 2024 at 02:49:01AM +0200, Laurent Pinchart wrote:
> The raspberrypi,bcm2835-firmware devices requires a dma-ranges property,
> and, as a result, also needs to specify #address-cells and #size-cells.
> Those properties have been added to thebcm2835-rpi.dtsi in commits
> be08d278eb09 ("ARM: dts: bcm283x: Add cells encoding format to firmware
> bus") and 55c7c0621078 ("ARM: dts: bcm283x: Fix vc4's firmware bus DMA
> limitations"), but the DT bindings haven't been updated, resulting in
> validation errors:
I don't understand. We treat no dma-ranges the same as empty dma-ranges
(dma-ranges;). If we didn't, *every* DT would be broken.
We should never have dma-ranges without ranges either.
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 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
From: Andy Shevchenko @ 2024-03-26 21:20 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <6f6c96d3-051a-4437-9c95-6b8be7847705@sirena.org.uk>
On Tue, Mar 26, 2024 at 08:26:11PM +0000, Mark Brown wrote:
> On Tue, Mar 26, 2024 at 10:12:12PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 08:02:57PM +0000, Mark Brown wrote:
>
> > > It is not clear to me that this makes the kernel side better, it just
> > > seems to be rewriting the platform data for the sake of it. If it was
> > > converting to DT there'd be some stuff from it being DT but this keeps
> > > everything as in kernel as board files, just in a more complex form.
>
> > Not really. The benefits with swnode conversion are the following:
>
> > - reducing custom APIs / data types between _shared_ (in a sense of
> > supporting zillion different platforms) driver and a certain board
> > file
>
> > - as an effect of the above, reducing kernel code base, and as the result
> > make maintenance easier and bug-free for that parts
>
> I'm more worried about the possibility of breaking things with swnode
> support than I am for board files - with board files you've got a good
> chance of failing to compile if things get messed up, with swnode you
> can typo a property or whatever and silently fail.
I understand that, but here it's consolidated in a single series
and not supposed to be modified in the future, only dropping or
properly converting.
Btw, you may say the same about the all patches that converts to
GPIO lookup tables (one typo in the not-so-often used GPIO line
device ID name), but I don't remember that kind of conversions
got much of objection.
> > - preparing a driver to be ready for any old board file conversion to DT
> > as it reduces that churn (you won't need to touch the driver code)
>
> The driver appears to already have DT support (there's a compatible for
> MMP2 in there)?
The MMP2 is using default number of chip select pins.
Also note that my reply is generic (I used 'a driver' form).
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] arm64: dts: ti: k3-j784s4: Use exact ranges for FSS node
From: Andrew Davis @ 2024-03-26 20:59 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew Davis
In-Reply-To: <20240326205920.40147-1-afd@ti.com>
The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
---
arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
index 77a8d99139ec1..c6d4bf79c1423 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
@@ -674,10 +674,13 @@ adc {
fss: bus@47000000 {
compatible = "simple-bus";
- reg = <0x00 0x47000000 0x00 0x100>;
#address-cells = <2>;
#size-cells = <2>;
- ranges;
+ ranges = <0x0 0x47000000 0x0 0x47000000 0x0 0x100>, /* FSS Control */
+ <0x0 0x47040000 0x0 0x47040000 0x0 0x100>, /* OSPI0 Control */
+ <0x0 0x47050000 0x0 0x47050000 0x0 0x100>, /* OSPI1 Control */
+ <0x5 0x00000000 0x5 0x00000000 0x1 0x0000000>, /* OSPI0 Memory */
+ <0x7 0x00000000 0x7 0x00000000 0x1 0x0000000>; /* OSPI1 Memory */
ospi0: spi@47040000 {
compatible = "ti,am654-ospi", "cdns,qspi-nor";
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: ti: k3-j721e: Use exact ranges for FSS node
From: Andrew Davis @ 2024-03-26 20:59 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew Davis
In-Reply-To: <20240326205920.40147-1-afd@ti.com>
The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index 4618b697fbc47..b33a1ca2236ff 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -346,10 +346,14 @@ wkup_i2c0: i2c@42120000 {
fss: bus@47000000 {
compatible = "simple-bus";
- reg = <0x0 0x47000000 0x0 0x100>;
#address-cells = <2>;
#size-cells = <2>;
- ranges;
+ ranges = <0x0 0x47000000 0x0 0x47000000 0x0 0x100>, /* FSS Control */
+ <0x0 0x47034000 0x0 0x47034000 0x0 0x100>, /* HBMC Control */
+ <0x0 0x47040000 0x0 0x47040000 0x0 0x100>, /* OSPI0 Control */
+ <0x0 0x47050000 0x0 0x47050000 0x0 0x100>, /* OSPI1 Control */
+ <0x5 0x00000000 0x5 0x00000000 0x1 0x0000000>, /* HBMC/OSPI0 Memory */
+ <0x7 0x00000000 0x7 0x00000000 0x1 0x0000000>; /* OSPI1 Memory */
hbmc_mux: mux-controller@47000004 {
compatible = "reg-mux";
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: ti: k3-am65: Use exact ranges for FSS node
From: Andrew Davis @ 2024-03-26 20:59 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew Davis
The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
---
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 6ff3ccc39fb44..babfcbb9ecf56 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -286,7 +286,11 @@ fss: bus@47000000 {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
- ranges;
+ ranges = <0x0 0x47000000 0x0 0x47000000 0x0 0x100>, /* FSS Control */
+ <0x0 0x47040000 0x0 0x47040000 0x0 0x100>, /* OSPI0 Control */
+ <0x0 0x47050000 0x0 0x47050000 0x0 0x100>, /* OSPI1 Control */
+ <0x5 0x00000000 0x5 0x00000000 0x1 0x0000000>, /* OSPI0 Memory */
+ <0x7 0x00000000 0x7 0x00000000 0x1 0x0000000>; /* OSPI1 Memory */
ospi0: spi@47040000 {
compatible = "ti,am654-ospi", "cdns,qspi-nor";
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: ti: k3-j7200: Use exact ranges for FSS node
From: Andrew Davis @ 2024-03-26 20:59 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew Davis
In-Reply-To: <20240326205920.40147-1-afd@ti.com>
The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
---
arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index 7cf21c99956e0..4fe39764ded40 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -520,10 +520,12 @@ mcu_spi2: spi@40320000 {
fss: bus@47000000 {
compatible = "simple-bus";
- reg = <0x00 0x47000000 0x00 0x100>;
#address-cells = <2>;
#size-cells = <2>;
- ranges;
+ ranges = <0x0 0x47000000 0x0 0x47000000 0x0 0x100>, /* FSS Control */
+ <0x0 0x47034000 0x0 0x47040000 0x0 0x100>, /* HBMC Control */
+ <0x0 0x47040000 0x0 0x47040000 0x0 0x100>, /* OSPI0 Control */
+ <0x5 0x00000000 0x5 0x00000000 0x1 0x0000000>; /* HBMC/OSPI0 Memory */
hbmc_mux: mux-controller@47000004 {
compatible = "reg-mux";
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/6] arm64: dts: ti: k3-am65: Remove UART baud rate selection
From: Andrew Davis @ 2024-03-26 20:55 UTC (permalink / raw)
To: Nishanth Menon
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240326202105.duim7cooxk4dwlz2@makeshift>
On 3/26/24 3:21 PM, Nishanth Menon wrote:
> On 13:54-20240326, Andrew Davis wrote:
>> As described in the binding document for the "current-speed" property:
>>
>> "This should only be present in case a driver has no chance to know the
>> baud rate of the slave device."
>>
>> This is not the case for the UART used in K3 devices, the current
>> baud-rate can be calculated from the registers. Having this property
>
> I do not understand the explanation above -> how does one do this?
> If you are talking of the 8250 divider registers, someone has to program
> those - how do you compute the baud rate from registers that aren't
> programmed? Note: I am not commenting on the rationale of removing the
> property, just trying to understand the assertion above.
>
This divider register, when "unprogrammed", has a default value. When one
wants to use a TTY/serial device they pick the baud-rate(stty, termios, etc.),
that then programs the register with the value they selected.
As stated below, this property does not program that register, it only
tells the driver what it should have already been set to. Some drivers
need this as they do not have a way to know what the divider is actually
set to.
Setting this in our case is wrong for two reasons:
1) Our driver can and does just check the divider itself.
2) We do not setup most of these UARTs before the kernel starts, so
if our driver *did* care about this property it would not reflect
the actual divider value (which is unprogrammed at this point).
Andrew
>> has the effect of actually skipping the baud-rate setup in some drivers
>> as it assumes it will already be set to this rate, which may not always
>> be the case.
>>
>> It seems this property's purpose was mistaken as selecting the desired
>> baud-rate, which it does not. It would have been wrong to select that
>> here anyway as DT is not the place for configuration, especially when
>> there are already more standard ways to set serial baud-rates.
>>
>> Signed-off-by: Andrew Davis <afd@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 -
>> arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 1 -
>> arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 1 -
>> 3 files changed, 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index ff857117d7193..670557c89f756 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -89,7 +89,6 @@ main_uart0: serial@2800000 {
>> reg = <0x00 0x02800000 0x00 0x100>;
>> interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
>> clock-frequency = <48000000>;
>> - current-speed = <115200>;
>> power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
>> status = "disabled";
>> };
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> index 6ff3ccc39fb44..4f808e5089755 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> @@ -43,7 +43,6 @@ mcu_uart0: serial@40a00000 {
>> reg = <0x00 0x40a00000 0x00 0x100>;
>> interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
>> clock-frequency = <96000000>;
>> - current-speed = <115200>;
>> power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
>> status = "disabled";
>> };
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
>> index 37527890ddeaf..eee072e44a42f 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
>> @@ -59,7 +59,6 @@ wkup_uart0: serial@42300000 {
>> reg = <0x42300000 0x100>;
>> interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
>> clock-frequency = <48000000>;
>> - current-speed = <115200>;
>> power-domains = <&k3_pds 150 TI_SCI_PD_EXCLUSIVE>;
>> status = "disabled";
>> };
>> --
>> 2.39.2
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH v1 00/10] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Mark Brown @ 2024-03-26 20:55 UTC (permalink / raw)
To: linux-spi, linux-kernel, linux-arm-kernel, Andy Shevchenko
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Arnd Bergmann
In-Reply-To: <20240326181027.1418989-1-andriy.shevchenko@linux.intel.com>
On Tue, 26 Mar 2024 20:07:50 +0200, Andy Shevchenko wrote:
> As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> its content is being used solely internally to SPI subsystem
> (PXA2xx drivers). Hence this refactoring series with the additional
> win of getting rid of legacy documentation.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[02/10] spi: pxa2xx: Keep PXA*_SSP types together
commit: dad983d8812975b53db83f02ae6b0ad15f018a9e
[03/10] spi: pxa2xx: Switch to use dev_err_probe()
commit: d5449432f794e75cd4f5e46bc33bfe6ce20b657d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND][PATCH v2 2/4] PM: EM: Change the em_adjust_new_capacity() to re-use code
From: Lukasz Luba @ 2024-03-26 20:36 UTC (permalink / raw)
To: Dietmar Eggemann
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
rafael, viresh.kumar, krzysztof.kozlowski, alim.akhtar,
m.szyprowski, mhiramat, linux-kernel, linux-pm
In-Reply-To: <ad20a727-bc3e-4408-8d87-fc6a16627bca@arm.com>
On 3/26/24 10:51, Dietmar Eggemann wrote:
> On 22/03/2024 12:08, Lukasz Luba wrote:
>
> Maybe better : "PM: EM: Refactoring em_adjust_new_capacity()" ?
>
>> There is going to be a new update function addressing chip binning.
>> Therefore, some common code which can be refactored and called from
>> upcoming changes and em_adjust_new_capacity(). In this way the code
>> duplication can be avoided.
>
> IMHO, that's hard to digest.
>
> Extract em_table_dup() and em_recalc_and_update() from
> em_adjust_new_capacity(). Both functions will be later reused by the
> 'update EM due to chip binning' functionality.
That looks good, I'll update it.
>
> [...]
>
>> +static int em_recalc_and_update(struct device *dev, struct em_perf_domain *pd,
>> + struct em_perf_table __rcu *em_table)
>> +{
>> + int ret;
>> +
>> + ret = em_compute_costs(dev, em_table->state, NULL, pd->nr_perf_states,
>> pd->flags);
>> - if (ret) {
>> - dev_warn(dev, "EM: compute costs failed\n");
>> - return;
>> - }
>> + if (ret)
>> + goto free_em_table;
>
> There seems to be a subtle change in this patch. When em_compute_costs()
> fails now em_table_free() is called. This wasn't the case before when
> em_compute_costs() was directly called from em_adjust_new_capacity().
Yes, I've refactored it to explicitly call to the same free_em_table
for both fails in the new code. It should have been done in old code.
>
> [...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND][PATCH v2 3/4] PM: EM: Add em_dev_update_chip_binning()
From: Lukasz Luba @ 2024-03-26 20:32 UTC (permalink / raw)
To: Dietmar Eggemann
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
rafael, viresh.kumar, krzysztof.kozlowski, alim.akhtar,
m.szyprowski, mhiramat, linux-kernel, linux-pm
In-Reply-To: <eb9f48f6-cca8-405b-82a2-352893a79f14@arm.com>
On 3/26/24 10:09, Dietmar Eggemann wrote:
> On 22/03/2024 12:08, Lukasz Luba wrote:
>
>> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
>> index 6960dd7393b2d..f7f7ae34ec552 100644
>> --- a/kernel/power/energy_model.c
>> +++ b/kernel/power/energy_model.c
>> @@ -808,3 +808,54 @@ static void em_update_workfn(struct work_struct *work)
>> {
>> em_check_capacity_update();
>> }
>> +
>> +/**
>> + * em_dev_update_chip_binning() - Update Energy Model with new values after
>
> s/with new values// ... IMHO this should be obvious ?
Make sense
>
>> + * the new voltage information is present in the OPPs.
>> + * @dev : Device for which the Energy Model has to be updated.
>> + *
>> + * This function allows to update easily the EM with new values available in
>> + * the OPP framework and DT. It can be used after the chip has been properly
>> + * verified by device drivers and the voltages adjusted for the 'chip binning'.
>> + * It uses the "dynamic-power-coefficient" DT property to calculate the power
>> + * values for EM. For power calculation it uses the new adjusted voltage
>> + * values known for OPPs, which might be changed after boot.
>
> The last two sentences describe what dev_pm_opp_calc_power() is doing.
> Maybe this can be made clearer here?
Or I can just remove this, since it's too detailed description.
>
>> + */
>> +int em_dev_update_chip_binning(struct device *dev)
>
> This is the old dev_pm_opp_of_update_em() right?
Yes, it is similar.
>
>> +{
>> + struct em_perf_table __rcu *em_table;
>> + struct em_perf_domain *pd;
>> + int i, ret;
>> +
>> + if (IS_ERR_OR_NULL(dev))
>> + return -EINVAL;
>
> When do you use if '(IS_ERR_OR_NULL(dev))' and when 'if(!dev)' for EM
> interface functions?
Sometimes IS_ERR_OR_NULL is used, especially for API function other
that register function.
>
>> + pd = em_pd_get(dev);
>> + if (!pd) {
>> + dev_warn(dev, "Couldn't find Energy Model\n");
>> + return -EINVAL;
>> + }
>> +
>> + em_table = em_table_dup(pd);
>> + if (!em_table) {
>> + dev_warn(dev, "EM: allocation failed\n");
>> + return -ENOMEM;
>> + }
>> +
>> + /* Update power values which might change due to new voltage in OPPs */
>> + for (i = 0; i < pd->nr_perf_states; i++) {
>> + unsigned long freq = em_table->state[i].frequency;
>> + unsigned long power;
>> +
>> + ret = dev_pm_opp_calc_power(dev, &power, &freq);
>> + if (ret) {
>> + em_table_free(em_table);
>> + return ret;
>> + }
>> +
>> + em_table->state[i].power = power;
>> + }
>> +
>> + return em_recalc_and_update(dev, pd, em_table);
>> +}
>> +EXPORT_SYMBOL_GPL(em_dev_update_chip_binning);
>
> In the previous version of 'chip-binning' you were using the new EM
> interface em_dev_compute_costs() (1) which is now replaced by
> em_recalc_and_update() -> em_compute_costs().
>
> https://lkml.kernel.org/r/20231220110339.1065505-2-lukasz.luba@arm.com
>
> Which leaves (1) still unused.
>
> That was why my concern back then that we shouldn't introduce EM
> interfaces without a user:
>
> https://lkml.kernel.org/r/8fc499cf-fca1-4465-bff7-a93dfd36f3c8@arm.com
>
> What happens now with em_dev_compute_costs()?
>
For now it's not used, but modules which will create new EMs
with custom power values will use it. When such a module have
e.g. 5 EMs for one PD and only switches on one of them, then
this em_dev_compute_costs() will be used at setup for those
5 EMs. Later it won't be used.
I don't wanted to combine the registration of new EM with
the compute cost, because that will create overhead in the
switching to new EM code path. Now we have only ~3us, which
was the main goal.
When our scmi-cpufreq get the support for EM update this
compute cost will be used there.
_______________________________________________
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 07/10] spi: pxa2xx: Provide num-cs for Sharp PDAs via device properties
From: Mark Brown @ 2024-03-26 20:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King
In-Reply-To: <ZgMsHFJObZ48Erzt@smile.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1307 bytes --]
On Tue, Mar 26, 2024 at 10:12:12PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 08:02:57PM +0000, Mark Brown wrote:
> > It is not clear to me that this makes the kernel side better, it just
> > seems to be rewriting the platform data for the sake of it. If it was
> > converting to DT there'd be some stuff from it being DT but this keeps
> > everything as in kernel as board files, just in a more complex form.
> Not really. The benefits with swnode conversion are the following:
> - reducing custom APIs / data types between _shared_ (in a sense of
> supporting zillion different platforms) driver and a certain board
> file
> - as an effect of the above, reducing kernel code base, and as the result
> make maintenance easier and bug-free for that parts
I'm more worried about the possibility of breaking things with swnode
support than I am for board files - with board files you've got a good
chance of failing to compile if things get messed up, with swnode you
can typo a property or whatever and silently fail.
> - preparing a driver to be ready for any old board file conversion to DT
> as it reduces that churn (you won't need to touch the driver code)
The driver appears to already have DT support (there's a compatible for
MMP2 in there)?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 17/19] Input: ambakmi - drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Depends on first amba patch.
---
drivers/input/serio/ambakmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
index 8fbfa448be4a..496bb7a312d2 100644
--- a/drivers/input/serio/ambakmi.c
+++ b/drivers/input/serio/ambakmi.c
@@ -195,7 +195,6 @@ MODULE_DEVICE_TABLE(amba, amba_kmi_idtable);
static struct amba_driver ambakmi_driver = {
.drv = {
.name = "kmi-pl050",
- .owner = THIS_MODULE,
.pm = pm_sleep_ptr(&amba_kmi_dev_pm_ops),
},
.id_table = amba_kmi_idtable,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 18/19] memory: pl353-smc: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
As memory controllers maintainer: this has my Ack. :)
Depends on first amba patch.
---
drivers/memory/pl353-smc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c
index 48540817e046..56e51737c81f 100644
--- a/drivers/memory/pl353-smc.c
+++ b/drivers/memory/pl353-smc.c
@@ -154,7 +154,6 @@ MODULE_DEVICE_TABLE(amba, pl353_ids);
static struct amba_driver pl353_smc_driver = {
.drv = {
- .owner = THIS_MODULE,
.name = "pl353-smc",
.pm = &pl353_smc_dev_pm_ops,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 16/19] dmaengine: pl330: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Depends on first amba patch.
---
drivers/dma/pl330.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 5f6d7f1e095f..b37ef28bb417 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -3265,7 +3265,6 @@ MODULE_DEVICE_TABLE(amba, pl330_ids);
static struct amba_driver pl330_driver = {
.drv = {
- .owner = THIS_MODULE,
.name = "dma-pl330",
.pm = &pl330_pm,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 19/19] vfio: amba: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Depends on first amba patch.
---
drivers/vfio/platform/vfio_amba.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
index 485c6f9161a9..ff8ff8480968 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -134,7 +134,6 @@ static struct amba_driver vfio_amba_driver = {
.id_table = vfio_amba_ids,
.drv = {
.name = "vfio-amba",
- .owner = THIS_MODULE,
},
.driver_managed_dma = true,
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 10/19] coresight: tmc: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-tmc-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index 72005b0c633e..0d251cae814f 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -602,7 +602,6 @@ MODULE_DEVICE_TABLE(amba, tmc_ids);
static struct amba_driver tmc_driver = {
.drv = {
.name = "coresight-tmc",
- .owner = THIS_MODULE,
.suppress_bind_attrs = true,
},
.probe = tmc_probe,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 08/19] coresight: etb10: drop owner assignment
From: Krzysztof Kozlowski @ 2024-03-26 20:23 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Krzysztof Kozlowski,
Eric Auger, Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Amba bus core already sets owner, so driver does not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/hwtracing/coresight/coresight-etb10.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 3aab182b562f..7edd3f1d0d46 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -844,7 +844,6 @@ MODULE_DEVICE_TABLE(amba, etb_ids);
static struct amba_driver etb_driver = {
.drv = {
.name = "coresight-etb10",
- .owner = THIS_MODULE,
.pm = &etb_dev_pm_ops,
.suppress_bind_attrs = true,
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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