| 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: <CH2PR02MB70009C7F41F729A7FA02023DC70B0@CH2PR02MB7000.namprd02.prod.outlook.com>
Date: Mon, 27 Jan 2020 09:28:04 +0000
From: Radhey Shyam Pandey <radheys@...inx.com>
To: Andre Przywara <andre.przywara@....com>,
Rob Herring <robh@...nel.org>
CC: "David S . Miller" <davem@...emloft.net>,
Michal Simek <michals@...inx.com>,
Robert Hancock <hancock@...systems.ca>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mark Rutland <mark.rutland@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH 14/14] net: axienet: Update devicetree binding
documentation
> -----Original Message-----
> From: Andre Przywara <andre.przywara@....com>
> Sent: Friday, January 24, 2020 9:59 PM
> To: Rob Herring <robh@...nel.org>
> Cc: David S . Miller <davem@...emloft.net>; Radhey Shyam Pandey
> <radheys@...inx.com>; Michal Simek <michals@...inx.com>; Robert Hancock
> <hancock@...systems.ca>; netdev@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; Mark Rutland
> <mark.rutland@....com>; devicetree@...r.kernel.org
> Subject: Re: [PATCH 14/14] net: axienet: Update devicetree binding
> documentation
>
> On Tue, 21 Jan 2020 15:51:09 -0600
> Rob Herring <robh@...nel.org> wrote:
>
> Hi Rob,
>
> thanks for having a look!
>
> > On Fri, Jan 10, 2020 at 11:54:15AM +0000, Andre Przywara wrote:
> > > This adds documentation about the newly introduced, optional
> > > "xlnx,addrwidth" property to the binding documentation.
> > >
> > > While at it, clarify the wording on some properties, replace obsolete
> > > .txt file references with their new .yaml counterparts, and add a more
> > > modern example, using the axistream-connected property.
> > >
> > > Cc: Rob Herring <robh+dt@...nel.org>
> > > Cc: Mark Rutland <mark.rutland@....com>
> > > Cc: devicetree@...r.kernel.org
> > > Signed-off-by: Andre Przywara <andre.przywara@....com>
> > > ---
> > > .../bindings/net/xilinx_axienet.txt | 57 ++++++++++++++++---
> > > 1 file changed, 50 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> > > index 7360617cdedb..78c278c5200f 100644
> > > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> > > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
> > > @@ -12,7 +12,8 @@ sent and received through means of an AXI DMA
> controller. This driver
> > > includes the DMA driver code, so this driver is incompatible with AXI DMA
> > > driver.
> > >
> > > -For more details about mdio please refer phy.txt file in the same directory.
> > > +For more details about mdio please refer to the ethernet-phy.yaml file in
> > > +the same directory.
> > >
> > > Required properties:
> > > - compatible : Must be one of "xlnx,axi-ethernet-1.00.a",
> > > @@ -27,14 +28,14 @@ Required properties:
> > > instead, and only the Ethernet core interrupt is optionally
> > > specified here.
> > > - phy-handle : Should point to the external phy device.
> > > - See ethernet.txt file in the same directory.
> > > -- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the
> hardware
> > > + See the ethernet-controller.yaml file in the same directory.
> > > +- xlnx,rxmem : Size of the RXMEM buffer in the hardware, in bytes.
> > >
> > > Optional properties:
> > > -- phy-mode : See ethernet.txt
> > > +- phy-mode : See ethernet-controller.yaml.
> > > - xlnx,phy-type : Deprecated, do not use, but still accepted in
> preference
> > > to phy-mode.
> > > -- xlnx,txcsum : 0 or empty for disabling TX checksum offload,
> > > +- xlnx,txcsum : 0 for disabling TX checksum offload (default if
> omitted),
> > > 1 to enable partial TX checksum offload,
> > > 2 to enable full TX checksum offload
> > > - xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum
> offload
> > > @@ -48,10 +49,20 @@ Optional properties:
> > > If this is specified, the DMA-related resources from that
> > > device (DMA registers and DMA TX/RX interrupts) rather
> > > than this one will be used.
> > > - - mdio : Child node for MDIO bus. Must be defined if PHY
> access is
> > > +- mdio : Child node for MDIO bus. Must be defined if PHY
> access is
> > > required through the core's MDIO interface (i.e. always,
> > > unless the PHY is accessed through a different bus).
> > >
> > > +Required properties for axistream-connected subnode:
> > > +- reg : Address and length of the AXI DMA controller MMIO
> space.
> > > +- interrupts : A list of 2 interrupts: TX DMA and RX DMA, in that order.
> > > +
> > > +Optional properties for axistream-connected subnode:
> > > +- xlnx,addrwidth: Specifies the configured address width of the DMA. Newer
> > > + versions of the IP allow setting this to a value between
> > > + 32 and 64. Defaults to 32 bits if not specified.
> >
> > I think this should be expressed using dma-ranges. This is exactly the
> > purpose of dma-ranges and we shouldn't need a device specific property
> > for this sort of thing.
dma-ranges define the relationship between the physical address spaces of the
parent and child nodes. In this case, ethernet and dma (parent-child) have
the same view of physical address space. Do we mean to use the child-size
dma-range field and determine the address width?
>
> OK, after talking to Robin about it, I think I will indeed drop the whole usage of
> xlnx,addrwidth altogether.
> Some thoughts:
> - An integrator would choose the addrwidth value in the IP to be big enough for
> the whole bus. In our case it's actually 40 bits, because this is the max address
> size the interconnect supports. So any possible physical address the kernel could
> come up with would be valid for the DMA IP.
> - Because of this we set the DMA mask to either 64-bit or 32-bit, depending on
> the auto detection of the MSB registers.
> - If some integrator screws this up anyway, they can always set dma-ranges in
> the parent to limit the address range. IIUC, no further code would be needed in
> the Ethernet driver, as this would be handled by some (DMA?) framework?
I think the current driver design will be simplified once we switch to the
dmaengine framework and use the xilinx dma(drivers/dma/xilinx_dma.c) driver.
The address width parsing is already handled by the dma driver. I am working
on an RFC to remove dma code from axiethernet and planning to post patchset.
Hopefully, that should address all concerns.
>
> Does that make sense?
>
> Cheers,
> Andre
Powered by blists - more mailing lists