| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZtcoFmK6NPLcIwVt@apocalypse>
Date: Tue, 3 Sep 2024 17:15:34 +0200
From: Andrea della Porta <andrea.porta@...e.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Andrea della Porta <andrea.porta@...e.com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Linus Walleij <linus.walleij@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Derek Kiernan <derek.kiernan@....com>,
Dragan Cvetic <dragan.cvetic@....com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Saravana Kannan <saravanak@...gle.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org, netdev@...r.kernel.org,
linux-pci@...r.kernel.org, linux-arch@...r.kernel.org,
Lee Jones <lee@...nel.org>, Andrew Lunn <andrew@...n.ch>,
Stefan Wahren <wahrenst@....net>
Subject: Re: [PATCH 08/11] misc: rp1: RaspberryPi RP1 misc driver
Hi Krzysztof,
On 18:52 Fri 30 Aug , Krzysztof Kozlowski wrote:
> On 30/08/2024 15:49, Andrea della Porta wrote:
> > Hi Krzysztof,
> >
> > On 10:38 Wed 21 Aug , Krzysztof Kozlowski wrote:
> >> On Tue, Aug 20, 2024 at 04:36:10PM +0200, Andrea della Porta wrote:
> >>> The RaspberryPi RP1 is ia PCI multi function device containing
> >>> peripherals ranging from Ethernet to USB controller, I2C, SPI
> >>> and others.
> >>> Implement a bare minimum driver to operate the RP1, leveraging
> >>> actual OF based driver implementations for the on-borad peripherals
> >>> by loading a devicetree overlay during driver probe.
> >>> The peripherals are accessed by mapping MMIO registers starting
> >>> from PCI BAR1 region.
> >>> As a minimum driver, the peripherals will not be added to the
> >>> dtbo here, but in following patches.
> >>>
> >>> Link: https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf
> >>> Signed-off-by: Andrea della Porta <andrea.porta@...e.com>
> >>> ---
> >>> MAINTAINERS | 2 +
> >>> arch/arm64/boot/dts/broadcom/rp1.dtso | 152 ++++++++++++
> >>
> >> Do not mix DTS with drivers.
> >>
> >> These MUST be separate.
> >
> > Separating the dtso from the driver in two different patches would mean
> > that the dtso patch would be ordered before the driver one. This is because
> > the driver embeds the dtbo binary blob inside itself, at build time. So
> > in order to build the driver, the dtso needs to be there also. This is not
>
> Sure, in such case DTS will have to go through the same tree as driver
> as an exception. Please document it in patch changelog (---).
Ack.
>
> > the standard approach used with 'normal' dtb/dtbo, where the dtb patch is
> > ordered last wrt the driver it refers to.
>
> It's not exactly the "ordered last" that matters, but lack of dependency
> and going through separate tree and branch - arm-soc/dts. Here there
> will be an exception how we handle patch, but still DTS is hardware
> description so should not be combined with driver code.
Ack.
>
> > Are you sure you want to proceed in this way?
>
>
> >
> >>
> >>> drivers/misc/Kconfig | 1 +
> >>> drivers/misc/Makefile | 1 +
> >>> drivers/misc/rp1/Kconfig | 20 ++
> >>> drivers/misc/rp1/Makefile | 3 +
> >>> drivers/misc/rp1/rp1-pci.c | 333 ++++++++++++++++++++++++++
> >>> drivers/misc/rp1/rp1-pci.dtso | 8 +
> >>> drivers/pci/quirks.c | 1 +
> >>> include/linux/pci_ids.h | 3 +
> >>> 10 files changed, 524 insertions(+)
> >>> create mode 100644 arch/arm64/boot/dts/broadcom/rp1.dtso
> >>> create mode 100644 drivers/misc/rp1/Kconfig
> >>> create mode 100644 drivers/misc/rp1/Makefile
> >>> create mode 100644 drivers/misc/rp1/rp1-pci.c
> >>> create mode 100644 drivers/misc/rp1/rp1-pci.dtso
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index 67f460c36ea1..1359538b76e8 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -19119,9 +19119,11 @@ F: include/uapi/linux/media/raspberrypi/
> >>> RASPBERRY PI RP1 PCI DRIVER
> >>> M: Andrea della Porta <andrea.porta@...e.com>
> >>> S: Maintained
> >>> +F: arch/arm64/boot/dts/broadcom/rp1.dtso
> >>> F: Documentation/devicetree/bindings/clock/raspberrypi,rp1-clocks.yaml
> >>> F: Documentation/devicetree/bindings/pinctrl/raspberrypi,rp1-gpio.yaml
> >>> F: drivers/clk/clk-rp1.c
> >>> +F: drivers/misc/rp1/
> >>> F: drivers/pinctrl/pinctrl-rp1.c
> >>> F: include/dt-bindings/clock/rp1.h
> >>> F: include/dt-bindings/misc/rp1.h
> >>> diff --git a/arch/arm64/boot/dts/broadcom/rp1.dtso b/arch/arm64/boot/dts/broadcom/rp1.dtso
> >>> new file mode 100644
> >>> index 000000000000..d80178a278ee
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/broadcom/rp1.dtso
> >>> @@ -0,0 +1,152 @@
> >>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >>> +
> >>> +#include <dt-bindings/gpio/gpio.h>
> >>> +#include <dt-bindings/interrupt-controller/irq.h>
> >>> +#include <dt-bindings/clock/rp1.h>
> >>> +#include <dt-bindings/misc/rp1.h>
> >>> +
> >>> +/dts-v1/;
> >>> +/plugin/;
> >>> +
> >>> +/ {
> >>> + fragment@0 {
> >>> + target-path="";
> >>> + __overlay__ {
> >>> + #address-cells = <3>;
> >>> + #size-cells = <2>;
> >>> +
> >>> + rp1: rp1@0 {
> >>> + compatible = "simple-bus";
> >>> + #address-cells = <2>;
> >>> + #size-cells = <2>;
> >>> + interrupt-controller;
> >>> + interrupt-parent = <&rp1>;
> >>> + #interrupt-cells = <2>;
> >>> +
> >>> + // ranges and dma-ranges must be provided by the includer
> >>> + ranges = <0xc0 0x40000000
> >>> + 0x01/*0x02000000*/ 0x00 0x00000000
> >>> + 0x00 0x00400000>;
> >>
> >> Are you 100% sure you do not have here dtc W=1 warnings?
> >
> > the W=1 warnings are:
> >
> > arch/arm64/boot/dts/broadcom/rp1.dtso:37.24-42.7: Warning (simple_bus_reg): /fragment@..._overlay__/rp1@...lk_xosc: missing or empty reg/ranges property
> > arch/arm64/boot/dts/broadcom/rp1.dtso:44.26-49.7: Warning (simple_bus_reg): /fragment@..._overlay__/rp1@...acb_pclk: missing or empty reg/ranges property
> > arch/arm64/boot/dts/broadcom/rp1.dtso:51.26-56.7: Warning (simple_bus_reg): /fragment@..._overlay__/rp1@...acb_hclk: missing or empty reg/ranges property
> > arch/arm64/boot/dts/broadcom/rp1.dtso:14.15-173.5: Warning (avoid_unnecessary_addr_size): /fragment@..._overlay__: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" property
> >
> > I don't see anything related to the ranges line you mentioned.
>
> Hm, indeed, but I would expect warning about unit address not matching
> ranges/reg.
>
> >
> >>
> >>> +
> >>> + dma-ranges =
> >>> + // inbound RP1 1x_xxxxxxxx -> PCIe 1x_xxxxxxxx
> >>> + <0x10 0x00000000
> >>> + 0x43000000 0x10 0x00000000
> >>> + 0x10 0x00000000>;
> >>> +
> >>> + clk_xosc: clk_xosc {
> >>
> >> Nope, switch to DTS coding style.
> >
> > Ack.
> >
> >>
> >>> + compatible = "fixed-clock";
> >>> + #clock-cells = <0>;
> >>> + clock-output-names = "xosc";
> >>> + clock-frequency = <50000000>;
> >>> + };
> >>> +
> >>> + macb_pclk: macb_pclk {
> >>> + compatible = "fixed-clock";
> >>> + #clock-cells = <0>;
> >>> + clock-output-names = "pclk";
> >>> + clock-frequency = <200000000>;
> >>> + };
> >>> +
> >>> + macb_hclk: macb_hclk {
> >>> + compatible = "fixed-clock";
> >>> + #clock-cells = <0>;
> >>> + clock-output-names = "hclk";
> >>> + clock-frequency = <200000000>;
> >>> + };
> >>> +
> >>> + rp1_clocks: clocks@...0018000 {
> >>
> >> Why do you mix MMIO with non-MMIO nodes? This really does not look
> >> correct.
> >>
> >
> > Right. This is already under discussion here:
> > https://lore.kernel.org/all/ZtBzis5CzQMm8loh@apocalypse/
> >
> > IIUC you proposed to instantiate the non-MMIO nodes (the three clocks) by
> > using CLK_OF_DECLARE.
>
> Depends. Where are these clocks? Naming suggests they might not be even
> part of this device. But if these are part of the device, then why this
> is not a clock controller (if they are controllable) or even removed
> (because we do not represent internal clock tree in DTS).
xosc is a crystal connected to the oscillator input of the RP1, so I would
consider it an external fixed-clock. If we were in the entire dts, I would have
put it in root under /clocks node, but here we're in the dtbo so I'm not sure
where else should I put it.
Regarding pclk and hclk, I'm still trying to understand where they come from.
If they are external clocks (since they are fixed-clock too), they should be
in the same node as xosc. CLK_OF_DECLARE does not seem to fit here because
there's no special management of these clocks, so no new clock definition is
needed.
If they are internal tree, I cannot simply get rid of them because rp1_eth node
references these two clocks (see clocks property), so they must be decalred
somewhere. Any hint about this?.
Many thanks,
Andrea
>
> Best regards,
> Krzysztof
>
Powered by blists - more mailing lists