Re: [PATCH net-next v2 2/2] net: ethernet: mediatek: support custom GMAC label
On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
>
> For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
>
> Suggested-by: René van Dorst
> Signed-off-by: Ilya Lipnitskiy
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 6b00c12c6c43..df3cda63a8c5 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
>
> static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> {
> + const char *label = of_get_property(np, "label", NULL);
> const __be32 *_id = of_get_property(np, "reg", NULL);
> phy_interface_t phy_mode;
> struct phylink *phylink;
> @@ -2867,9 +2868,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct
> device_node *np)
> return -EINVAL;
> }
>
> - eth->netdev[id] = alloc_etherdev(sizeof(*mac));
> + eth->netdev[id] = alloc_netdev(sizeof(*mac), label ? label : "eth%d",
> +NET_NAME_UNKNOWN, ether_setup);
'label' is generally supposed to correspond to the sticker for the
device connector for a human to id. I can't really tell if that's the
case here. I don't see how 'gmacX' vs. 'ethX' maps to DSA master vs.
slave.
I don't think this should be handled within a specific driver either. If
we're going to have a way to name things, then fix it in
alloc_etherdev().
It can also be argued that device naming for userspace is a userspace
(udev) problem.
Rob
Re: [PATCH v5 net-next 10/10] dt-bindings: net: korina: Add DT bindings for IDT 79RC3243x SoCs
On Fri, Apr 16, 2021 at 03:35:36PM +0200, Thomas Bogendoerfer wrote:
> On Fri, Apr 16, 2021 at 12:29:46PM +0300, Sergei Shtylyov wrote:
> > On 16.04.2021 11:52, Thomas Bogendoerfer wrote:
> >
> > > Add device tree bindings for ethernet controller integrated into
> > > IDT 79RC3243x SoCs.
> > >
> > > Signed-off-by: Thomas Bogendoerfer
> > > ---
> > > .../bindings/net/idt,3243x-emac.yaml | 74 +++
> > > 1 file changed, 74 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> > > b/Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> > > new file mode 100644
> > > index ..3697af5cb66f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> > > @@ -0,0 +1,74 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/net/idt,3243x-emac.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: IDT 79rc3243x Ethernet controller
> > > +
> > > +description: Ethernet controller integrated into IDT 79RC3243x family
> > > SoCs
> > > +
> > > +maintainers:
> > > + - Thomas Bogendoerfer
> > > +
> > > +allOf:
> > > + - $ref: ethernet-controller.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > +const: idt,3243x-emac
> > > +
> > > + reg:
> > > +maxItems: 3
> > > +
> > > + reg-names:
> > > +items:
> > > + - const: korina_regs
> > > + - const: korina_dma_rx
> > > + - const: korina_dma_tx
> > > +
> > > + interrupts:
> > > +items:
> > > + - description: RX interrupt
> > > + - description: TX interrupt
> > > +
> > > + interrupt-names:
> > > +items:
> > > + - const: korina_rx
> > > + - const: korina_tx
> > > +
> > > + clocks:
> > > +maxItems: 1
> > > +
> > > + clock-names:
> > > +items:
> > > + - const: mdioclk
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - reg-names
> > > + - interrupts
> > > + - interrupt-names
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +
> > > +ethernet@6 {
> > > +compatible = "idt,3243x-emac";
> > > +
> > > +reg = <0x6 0x1>,
> > > + <0x4 0x14>,
> > > + <0x40014 0x14>;
> > > +reg-names = "korina_regs",
> > > +"korina_dma_rx",
> > > +"korina_dma_tx";
> > > +
> > > +interrupts-extended = <&rcpic3 0>, <&rcpic3 1>;
> >
> >You use this prop, yet don't describe it?
>
> that's just interrupt-parent and interrupts in one statement. And since
> make dt_binding_check didn't complained I thought that's good this way.
> Rob, do I need to describe interrupts-extended as well ?
No, the tooling handles both cases. What the parent is is outside the
scope of a binding.
> I could change that to interrupt-parent/interrupts as the driver no
> longer uses dma under/overrun interrupts, which have a different
> interrupt-parent.
Humm, you should be describing the interrupt connections the h/w block
has, not what the driver uses (today) or not.
Rob
Re: [PATCH v5 net-next 10/10] dt-bindings: net: korina: Add DT bindings for IDT 79RC3243x SoCs
On Fri, Apr 16, 2021 at 10:52:06AM +0200, Thomas Bogendoerfer wrote:
> Add device tree bindings for ethernet controller integrated into
> IDT 79RC3243x SoCs.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> .../bindings/net/idt,3243x-emac.yaml | 74 +++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> b/Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> new file mode 100644
> index ..3697af5cb66f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/idt,3243x-emac.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/idt,3243x-emac.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: IDT 79rc3243x Ethernet controller
> +
> +description: Ethernet controller integrated into IDT 79RC3243x family SoCs
> +
> +maintainers:
> + - Thomas Bogendoerfer
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> +const: idt,3243x-emac
> +
> + reg:
> +maxItems: 3
> +
> + reg-names:
> +items:
> + - const: korina_regs
> + - const: korina_dma_rx
> + - const: korina_dma_tx
What's korina?
In any case, just drop as it is redundant.
> +
> + interrupts:
> +items:
> + - description: RX interrupt
> + - description: TX interrupt
> +
> + interrupt-names:
> +items:
> + - const: korina_rx
> + - const: korina_tx
Just rx and tx.
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +items:
> + - const: mdioclk
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - interrupt-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> +ethernet@6 {
> +compatible = "idt,3243x-emac";
> +
> +reg = <0x6 0x1>,
> + <0x4 0x14>,
> + <0x40014 0x14>;
> +reg-names = "korina_regs",
> +"korina_dma_rx",
> +"korina_dma_tx";
> +
> +interrupts-extended = <&rcpic3 0>, <&rcpic3 1>;
> +interrupt-names = "korina_rx", "korina_tx";
> +
> +clocks = <&iclk>;
> +clock-names = "mdioclk";
> +};
> --
> 2.29.2
>
Re: [PATCH net-next v4 2/2] of: net: fix of_get_mac_addr_nvmem() for non-platform devices
On Fri, Apr 16, 2021 at 2:30 AM Michael Walle wrote:
>
> Am 2021-04-16 05:24, schrieb Benjamin Herrenschmidt:
> > On Mon, 2021-04-12 at 19:47 +0200, Michael Walle wrote:
> >>
> >> /**
> >> * of_get_phy_mode - Get phy mode for given device_node
> >> @@ -59,15 +60,39 @@ static int of_get_mac_addr(struct device_node *np,
> >> const char *name, u8 *addr)
> >> static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
> >> {
> >> struct platform_device *pdev = of_find_device_by_node(np);
> >> + struct nvmem_cell *cell;
> >> + const void *mac;
> >> + size_t len;
> >> int ret;
> >>
> >> - if (!pdev)
> >> - return -ENODEV;
> >> + /* Try lookup by device first, there might be a
> >> nvmem_cell_lookup
> >> +* associated with a given device.
> >> +*/
> >> + if (pdev) {
> >> + ret = nvmem_get_mac_address(&pdev->dev, addr);
> >> + put_device(&pdev->dev);
> >> + return ret;
> >> + }
> >> +
> >
> > This smells like the wrong band aid :)
> >
> > Any struct device can contain an OF node pointer these days.
>
> But not all nodes might have an associated device, see DSA for example.
I believe what Ben is saying and what I said earlier is going from dev
-> OF node is right and OF node -> dev is wrong. If you only have an
OF node, then use an of_* function.
> And as the name suggests of_get_mac_address() operates on a node. So
> if a driver calls of_get_mac_address() it should work on the node. What
> is wrong IMHO, is that the ethernet drivers where the corresponding
> board
> has a nvmem_cell_lookup registered is calling of_get_mac_address(node).
> It should rather call eth_get_mac_address(dev) in the first place.
>
> One would need to figure out if there is an actual device (with an
> assiciated of_node), then call eth_get_mac_address(dev) and if there
> isn't a device call of_get_mac_address(node).
Yes, I think we're all in agreement.
> But I don't know if that is easy to figure out. Well, one could start
> with just the device where nvmem_cell_lookup is used. Then we could
> drop the workaround above.
Start with the ones just passing dev.of_node directly:
$ git grep 'of_get_mac_address(.*of_node)'
drivers/net/ethernet/aeroflex/greth.c: addr =
of_get_mac_address(ofdev->dev.of_node);
drivers/net/ethernet/altera/altera_tse_main.c: macaddr =
of_get_mac_address(pdev->dev.of_node);
drivers/net/ethernet/arc/emac_main.c: mac_addr =
of_get_mac_address(dev->of_node);
drivers/net/ethernet/broadcom/bgmac-bcma.c: mac =
of_get_mac_address(bgmac->dev->of_node);
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c: mac =
of_get_mac_address(pdev->dev.of_node);
drivers/net/ethernet/ethoc.c: mac =
of_get_mac_address(pdev->dev.of_node);
drivers/net/ethernet/ezchip/nps_enet.c: mac_addr =
of_get_mac_address(dev->of_node);
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c: mac_addr =
of_get_mac_address(ofdev->dev.of_node);
drivers/net/ethernet/marvell/pxa168_eth.c: mac_addr =
of_get_mac_address(pdev->dev.of_node);
drivers/net/ethernet/marvell/sky2.c:iap =
of_get_mac_address(hw->pdev->dev.of_node);
drivers/net/ethernet/mediatek/mtk_eth_soc.c:mac_addr =
of_get_mac_address(mac->of_node);
drivers/net/ethernet/microchip/lan743x_main.c: mac_addr =
of_get_mac_address(pdev->dev.of_node);
drivers/net/ethernet/qualcomm/qca_spi.c:mac =
of_get_mac_address(spi->dev.of_node);
drivers/net/ethernet/qualcomm/qca_uart.c: mac =
of_get_mac_address(serdev->dev.of_node);
drivers/net/ethernet/wiznet/w5100-spi.c:const void *mac =
of_get_mac_address(spi->dev.of_node);
drivers/net/ethernet/xilinx/xilinx_axienet_main.c: mac_addr =
of_get_mac_address(pdev->dev.of_node);
drivers/net/ethernet/xilinx/xilinx_emaclite.c: mac_address =
of_get_mac_address(ofdev->dev.of_node);
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c: mac_addr =
of_get_mac_address(rt2x00dev->dev->of_node);
drivers/staging/octeon/ethernet.c: mac =
of_get_mac_address(priv->of_node);
drivers/staging/wfx/main.c: macaddr =
of_get_mac_address(wdev->dev->of_node);
net/ethernet/eth.c: addr = of_get_mac_address(dev->of_node);
Then this will find most of the rest:
git grep -W 'of_get_mac_address([a-z]*)'| grep -E '(node|np)'
Rob
Re: [PATCH net-next 1/3] dt-bindings: net: add nvmem-mac-address-offset property
On Wed, Apr 14, 2021 at 05:43:49PM +0200, Andrew Lunn wrote: > On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: > > It is already possible to read the MAC address via a NVMEM provider. But > > there are boards, esp. with many ports, which only have a base MAC > > address stored. Thus we need to have a way to provide an offset per > > network device. > > We need to see what Rob thinks of this. There was recently a patchset > to support swapping the byte order of the MAC address in a NVMEM. Rob > said the NVMEM provider should have the property, not the MAC driver. > This does seems more ethernet specific, so maybe it should be an > Ethernet property? There was also this one[1]. I'm not totally opposed, but don't want to see a never ending addition of properties to try to describe any possible transformation. Rob [1] https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200920095724.8251-4-ansuels...@gmail.com/
Re: [PATCH v2 1/2] dt-bindings: net: can: Document transceiver implementation as phy
On Thu, 15 Apr 2021 21:16:34 +0530, Aswath Govindraju wrote: > From: Faiz Abbas > > Some transceivers need a configuration step (for example, pulling the > standby or enable lines) for them to start sending messages. The > transceiver can be implemented as a phy with the configuration done in the > phy driver. The bit rate limitation can the be obtained by the driver using > the phy node. > > Document the above implementation in the bosch mcan bindings > > Signed-off-by: Faiz Abbas > Signed-off-by: Aswath Govindraju > --- > Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 0/2] brcmfmac: support parse country code map from DT
On Thu, Apr 15, 2021 at 06:47:26PM +0800, Shawn Guo wrote: > This is a couple of patches adding optional brcm,ccode-map bindings for > brcmfmac driver to parse country code map from DT. > > Changes for v2: > - Rebase bindings patch on top of yaml conversion patch [1]. > - Improve commit log with Arend's explanation on why this data could >be put in device tree. > - Use pattern to define mapping string as suggested by Rob. > - Use brcmf_err() instead of dev_warn() and print error code. > - Use sscanf() to validate mapping string. > - Use brcmf_dbg(INFO, ...) to print country code entry. > - Separate BRCMF_BUSTYPE_SDIO bus_type check from general DT validation. > > [1] > https://patchwork.kernel.org/project/linux-wireless/patch/20210315105911.138553-1-linus.wall...@linaro.org/ As that's in my tree, I'm applying patch 1. Patch 2 should go via the wireless tree. Rob
Re: [PATCH v2 1/2] dt-bindings: bcm4329-fmac: add optional brcm,ccode-map
On Thu, 15 Apr 2021 18:47:27 +0800, Shawn Guo wrote: > Add optional brcm,ccode-map property to support translation from ISO3166 > country code to brcmfmac firmware country code and revision. > > The country revision is needed because the RF parameters that provide > regulatory compliance are tweaked per platform/customer. So depending > on the RF path tight to the chip, certain country revision needs to be > specified. As such they could be seen as device specific calibration > data which is a good fit into device tree. > > Signed-off-by: Shawn Guo > Reviewed-by: Arend van Spriel > --- > .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 > 1 file changed, 8 insertions(+) > Applied, thanks!
Re: [PATCH v2 net-next 5/5] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote: > The 'dsa,tag-protocol' is used to force a switch tree to use a > particular tag protocol, typically because the Ethernet controller > that it is connected to is not compatible with the default one. > > Signed-off-by: Tobias Waldekranz > --- > Documentation/devicetree/bindings/net/dsa/dsa.yaml | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > index 8a3494db4d8d..c4dec0654c6a 100644 > --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > @@ -70,6 +70,15 @@ patternProperties: >device is what the switch port is connected to > $ref: /schemas/types.yaml#/definitions/phandle > > + dsa,tag-protocol: 'dsa' is not a vendor. 'dsa-tag-protocol' instead. > +description: > + Instead of the default, the switch will use this tag protocol > if > + possible. Useful when a device supports multiple protcols and > + the default is incompatible with the Ethernet device. > +enum: > + - dsa > + - edsa > + >phy-handle: true > >phy-mode: true > -- > 2.25.1 >
Re: [PATCH 3/4] dt-bindings: net: can: Document transceiver implementation as phy
On Wed, Apr 14, 2021 at 1:49 AM Aswath Govindraju wrote: > > Hi Rob, > > On 12/04/21 11:21 pm, Rob Herring wrote: > > On Fri, Apr 09, 2021 at 07:10:53PM +0530, Aswath Govindraju wrote: > >> From: Faiz Abbas > >> > >> Some transceivers need a configuration step (for example, pulling the > >> standby or enable lines) for them to start sending messages. The > >> transceiver can be implemented as a phy with the configuration done in the > >> phy driver. The bit rate limitation can the be obtained by the driver using > >> the phy node. > >> > >> Document the above implementation in the bosch mcan bindings > >> > >> Signed-off-by: Faiz Abbas > >> Signed-off-by: Aswath Govindraju > >> --- > >> Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> index 798fa5fb7bb2..2c01899b1a3e 100644 > >> --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > >> @@ -109,6 +109,12 @@ properties: > >>can-transceiver: > >> $ref: can-transceiver.yaml# > >> > >> + phys: > >> +minItems: 1 > > > > maxItems: 1 > > Will add this in the respin. > > > > >> + > >> + phy-names: > >> +const: can_transceiver > > > > Kind of a pointless name. You don't really need a name if there's a > > single entry. > > > > This name used by devm_phy_optional_get() in m_can driver to get the phy > data structure. With no name, you'll get the 1st one. Looks like the phy subsystem warns on this. That's wrong, so please fix that. Rob
Re: [PATCH 1/4] dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers
On Tue, Apr 13, 2021 at 2:41 AM Marc Kleine-Budde wrote: > > On 12.04.2021 12:49:56, Rob Herring wrote: > > On Mon, Apr 12, 2021 at 12:19:30PM +0200, Marc Kleine-Budde wrote: > > > On 4/9/21 3:40 PM, Aswath Govindraju wrote: > > > > Add binding documentation for TI TCAN104x CAN transceivers. > > > > > > > > Signed-off-by: Aswath Govindraju > > > > --- > > > > .../bindings/phy/ti,tcan104x-can.yaml | 56 +++ > > > > 1 file changed, 56 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml > > > > b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml > > > > new file mode 100644 > > > > index ..4abfc30a97d0 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml > > > > @@ -0,0 +1,56 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#"; > > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > > > > + > > > > +title: TCAN104x CAN TRANSCEIVER PHY > > > > + > > > > +maintainers: > > > > + - Aswath Govindraju > > > > + > > > > +properties: > > > > + $nodename: > > > > +pattern: "^tcan104x-phy" > > > > + > > > > + compatible: > > > > +enum: > > > > + - ti,tcan1042 > > > > + - ti,tcan1043 > > > > > > Can you create a generic standby only and a generic standby and enable > > > transceiver? > > > > As a fallback compatible fine, but no generic binding please. A generic > > binding can't describe any timing requirements between the 2 GPIO as > > well as supplies when someone wants to add those (and they will). > > Right - that makes sense. > > > > > + > > > > + '#phy-cells': > > > > +const: 0 > > > > + > > > > + standby-gpios: > > > > +description: > > > > + gpio node to toggle standby signal on transceiver > > > > +maxItems: 1 > > > > + > > > > + enable-gpios: > > > > +description: > > > > + gpio node to toggle enable signal on transceiver > > > > +maxItems: 1 > > > > + > > > > + max-bitrate: > > > > +$ref: /schemas/types.yaml#/definitions/uint32 > > > > +description: > > > > + max bit rate supported in bps > > > > We already have 'max-speed' for serial devices, use that. > > There is already the neither Ethernet PHY (PHYLINK/PHYLIB) nor generic > PHY (GENERIC_PHY) can-transceiver binding > Documentation/devicetree/bindings/net/can/can-transceiver.yaml which > specifies max-bitrate. I don't have strong feelings whether to use > max-bitrate or max-speed. Okay, max-bitrate is fine. > > Speaking about Ethernet PHYs, what are to pros and cons to use the > generic PHY compared to the Ethernet PHY infrastructure? For higher speed ethernet, both are used. There's the serdes phy and the ethernet phy with serdes phy using the generic phy binding. For CAN, it probably comes down to what's a better fit. Rob
Re: [PATCH net-next 1/4] dt-bindings: net: qcom,ipa: add some compatible strings
On Fri, Apr 09, 2021 at 03:40:21PM -0500, Alex Elder wrote: > Add existing supported platform "qcom,sc7180-ipa" to the set of IPA > compatible strings. Also add newly-supported "qcom,sdx55-ipa", > "qcom,sc7280-ipa". > > Signed-off-by: Alex Elder > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index 8f86084bf12e9..2645a02cf19bf 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -43,7 +43,11 @@ description: > > properties: >compatible: > -const: "qcom,sdm845-ipa" > +oneOf: > + - const: "qcom,sc7180-ipa" > + - const: "qcom,sc7280-ipa" > + - const: "qcom,sdm845-ipa" > + - const: "qcom,sdx55-ipa" Use enum instead of oneOf + const. And drop the quotes. > >reg: > items: > -- > 2.27.0 >
Re: [RFC PATCH 2/3] dt-bindings: net: xilinx_axienet: Introduce dmaengine binding support
On Fri, Apr 09, 2021 at 11:43:21PM +0530, Radhey Shyam Pandey wrote: > The axiethernet driver will now use dmaengine framework to communicate > with dma controller IP instead of built-in dma programming sequence. > > To request dma transmit and receive channels the axiethernet driver uses > generic dmas, dma-names properties. It deprecates axistream-connected Huh, you just added the property and now deprecating? > property, remove axidma reg and interrupt properties from the ethernet > node. Just to highlight that these DT changes are not backward compatible > due to major driver restructuring/cleanup done in adopting the dmaengine > framework. Aren't users going to care this isn't a backwards compatible change? > > Signed-off-by: Radhey Shyam Pandey > --- > .../devicetree/bindings/net/xilinx_axienet.yaml| 40 > +- > 1 file changed, 24 insertions(+), 16 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml > b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml > index 6a00e03e8804..0ea3972fefef 100644 > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml > @@ -14,10 +14,8 @@ description: | >offloading TX/RX checksum calculation off the processor. > >Management configuration is done through the AXI interface, while payload > is > - 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. > - > + sent and received through means of an AXI DMA controller using dmaengine > + framework. > > allOf: >- $ref: "ethernet-controller.yaml#" > @@ -36,19 +34,13 @@ properties: > >reg: > description: > - Address and length of the IO space, as well as the address > - and length of the AXI DMA controller IO space, unless > - axistream-connected is specified, in which case the reg > - attribute of the node referenced by it is used. > -maxItems: 2 > + Address and length of the IO space. > +maxItems: 1 > >interrupts: > description: > - Can point to at most 3 interrupts. TX DMA, RX DMA, and optionally > Ethernet > - core. If axistream-connected is specified, the TX/RX DMA interrupts > should > - be on that node instead, and only the Ethernet core interrupt is > optionally > - specified here. > -maxItems: 3 > + Ethernet core interrupt. > +maxItems: 1 > >phy-handle: true > > @@ -109,15 +101,29 @@ properties: >for the AXI DMA controller used by this device. 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. > +deprecated: true > >mdio: true > > + dmas: > +items: > + - description: TX DMA Channel phandle and DMA request line number > + - description: RX DMA Channel phandle and DMA request line number > + > + dma-names: > +items: > + - const: tx_chan0 > + - const: rx_chan0 > + > + > required: >- compatible >- reg >- interrupts >- xlnx,rxmem >- phy-handle > + - dmas > + - dma-names > > additionalProperties: false > > @@ -127,11 +133,13 @@ examples: >compatible = "xlnx,axi-ethernet-1.00.a"; >device_type = "network"; >interrupt-parent = <µblaze_0_axi_intc>; > - interrupts = <2>, <0>, <1>; > + interrupts = <1>; >clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk"; >clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; >phy-mode = "mii"; > - reg = <0x40c0 0x4>,<0x50c0 0x4>; > + reg = <0x40c0 0x4>; > + dmas = <&xilinx_dma 0>, <&xilinx_dma 1>; > + dma-names = "tx_chan0", "rx_chan0"; Is there a chan1? Typical dma-names are just 'tx' and 'rx'. >xlnx,rxcsum = <0x2>; >xlnx,rxmem = <0x800>; >xlnx,txcsum = <0x2>; > -- > 2.7.4 >
Re: [PATCH 3/4] dt-bindings: net: can: Document transceiver implementation as phy
On Fri, Apr 09, 2021 at 07:10:53PM +0530, Aswath Govindraju wrote: > From: Faiz Abbas > > Some transceivers need a configuration step (for example, pulling the > standby or enable lines) for them to start sending messages. The > transceiver can be implemented as a phy with the configuration done in the > phy driver. The bit rate limitation can the be obtained by the driver using > the phy node. > > Document the above implementation in the bosch mcan bindings > > Signed-off-by: Faiz Abbas > Signed-off-by: Aswath Govindraju > --- > Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > index 798fa5fb7bb2..2c01899b1a3e 100644 > --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml > @@ -109,6 +109,12 @@ properties: >can-transceiver: > $ref: can-transceiver.yaml# > > + phys: > +minItems: 1 maxItems: 1 > + > + phy-names: > +const: can_transceiver Kind of a pointless name. You don't really need a name if there's a single entry. > + > required: >- compatible >- reg > -- > 2.17.1 >
Re: [PATCH 1/4] dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers
On Mon, Apr 12, 2021 at 12:19:30PM +0200, Marc Kleine-Budde wrote:
> On 4/9/21 3:40 PM, Aswath Govindraju wrote:
> > Add binding documentation for TI TCAN104x CAN transceivers.
> >
> > Signed-off-by: Aswath Govindraju
> > ---
> > .../bindings/phy/ti,tcan104x-can.yaml | 56 +++
> > 1 file changed, 56 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > new file mode 100644
> > index ..4abfc30a97d0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#";
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > +
> > +title: TCAN104x CAN TRANSCEIVER PHY
> > +
> > +maintainers:
> > + - Aswath Govindraju
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^tcan104x-phy"
> > +
> > + compatible:
> > +enum:
> > + - ti,tcan1042
> > + - ti,tcan1043
>
> Can you create a generic standby only and a generic standby and enable
> transceiver?
As a fallback compatible fine, but no generic binding please. A generic
binding can't describe any timing requirements between the 2 GPIO as
well as supplies when someone wants to add those (and they will).
>
> > +
> > + '#phy-cells':
> > +const: 0
> > +
> > + standby-gpios:
> > +description:
> > + gpio node to toggle standby signal on transceiver
> > +maxItems: 1
> > +
> > + enable-gpios:
> > +description:
> > + gpio node to toggle enable signal on transceiver
> > +maxItems: 1
> > +
> > + max-bitrate:
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +description:
> > + max bit rate supported in bps
We already have 'max-speed' for serial devices, use that.
> > +minimum: 1
> > +
> > +required:
> > + - compatible
> > + - '#phy-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +transceiver1: tcan104x-phy {
> > + compatible = "ti,tcan1043";
> > + #phy-cells = <0>;
> > + max-bitrate = <500>;
> > + standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>;
> > + enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_LOW>;
> > +};
> >
>
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Embedded Linux | https://www.pengutronix.de |
> Vertretung West/Dortmund | Phone: +49-231-2826-924 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
Re: [RFC PATCH 1/3] dt-bindings: net: xilinx_axienet: convert bindings document to yaml
On Fri, 09 Apr 2021 23:43:20 +0530, Radhey Shyam Pandey wrote: > Convert the bindings document for Xilinx AXI Ethernet Subsystem > from txt to yaml. No changes to existing binding description. > > Signed-off-by: Radhey Shyam Pandey > --- > Pending: Fix below remaining dt_binding_check warning: > > ethernet@40c0: 'device_type' does not match any of > the regexes: 'pinctrl-[0-9]+ > --- > .../devicetree/bindings/net/xilinx_axienet.txt | 80 --- > .../devicetree/bindings/net/xilinx_axienet.yaml| 147 > + > MAINTAINERS| 1 + > 3 files changed, 148 insertions(+), 80 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt > create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/xilinx_axienet.example.dt.yaml: ethernet@40c0: 'device_type' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/xilinx_axienet.yaml See https://patchwork.ozlabs.org/patch/1464502 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
On Thu, Apr 08, 2021 at 07:30:21PM +0800, Shawn Guo wrote:
> Add optional brcm,ccode-map property to support translation from ISO3166
> country code to brcmfmac firmware country code and revision.
>
> Signed-off-by: Shawn Guo
> ---
> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> 1 file changed, 7 insertions(+)
Can you convert this to schema first.
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index cffb2d6876e3..a65ac4384c04 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -15,6 +15,12 @@ Optional properties:
> When not specified the device will use in-band SDIO interrupts.
> - interrupt-names : name of the out-of-band interrupt, which must be set
> to "host-wake".
> + - brcm,ccode-map : multiple strings for translating ISO3166 country code to
> + brcmfmac firmware country code and revision. Each string must be in
> + format "AA-BB-num" where:
> + AA is the ISO3166 country code which must be 2 characters.
> + BB is the firmware country code which must be 2 characters.
> + num is the revision number which must fit into signed integer.
Signed? So "AA-BB--num"?
You should be able to do something like:
items:
pattern: '^[A-Z][A-Z]-[A-Z][A-Z]-[0-9]+$'
>
> Example:
>
> @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> interrupt-parent = <&pio>;
> interrupts = <10 8>; /* PH10 / EINT10 */
> interrupt-names = "host-wake";
> + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
> };
> };
> --
> 2.17.1
>
Re: [PATCH net-next 1/3] dt-bindings: net: add new properties for of_get_mac_address from nvmem
On Fri, Apr 9, 2021 at 4:07 AM Joakim Zhang wrote: > > From: Fugang Duan > > Currently, of_get_mac_address supports NVMEM, some platforms What's of_get_mac_address? This is a binding patch. Don't mix Linux things in it. > MAC address that read from NVMEM efuse requires to swap bytes > order, so add new property "nvmem_macaddr_swap" to specify the > behavior. If the MAC address is valid from NVMEM, add new property > "nvmem-mac-address" in ethernet node. > > Update these two properties in the binding documentation. > > Signed-off-by: Fugang Duan > Signed-off-by: Joakim Zhang > --- > .../bindings/net/ethernet-controller.yaml | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml > b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > index e8f04687a3e0..c868c295aabf 100644 > --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml > +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > @@ -32,6 +32,15 @@ properties: >- minItems: 6 > maxItems: 6 > > + nvmem-mac-address: > +allOf: > + - $ref: /schemas/types.yaml#definitions/uint8-array > + - minItems: 6 > +maxItems: 6 > +description: > + Specifies the MAC address that was read from nvmem-cells and > dynamically > + add the property in device node; Why can't you use local-mac-address or mac-address? Those too can come from some other source. > + >max-frame-size: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > @@ -52,6 +61,11 @@ properties: >nvmem-cell-names: > const: mac-address > > + nvmem_macaddr_swap: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + swap bytes order for the 6 bytes of MAC address So 'nvmem-mac-address' needs to be swapped or it's swapped before writing? In any case, this belongs in the nvmem provider. Rob
Re: [PATCH 2/2] of: net: fix of_get_mac_addr_nvmem() for PCI and DSA nodes
On Mon, Apr 5, 2021 at 11:47 AM Michael Walle wrote:
>
> of_get_mac_address() already supports fetching the MAC address by an
> nvmem provider. But until now, it was just working for platform devices.
> Esp. it was not working for DSA ports and PCI devices. It gets more
> common that PCI devices have a device tree binding since SoCs contain
> integrated root complexes.
>
> Use the nvmem of_* binding to fetch the nvmem cells by a struct
> device_node. We still have to try to read the cell by device first
> because there might be a nvmem_cell_lookup associated with that device.
>
> Signed-off-by: Michael Walle
> ---
> Please note, that I've kept the nvmem_get_mac_address() which operates
> on a device. The new of_get_mac_addr_nvmem() is almost identical and
> there are no users of the former function right now, but it seems to be
> the "newer" version to get the MAC address for a "struct device". Thus
> I've kept it. Please advise, if I should kill it though.
It seems kind of backwards from how we normally design this type of
API where the API with a struct device will call a firmware specific
version if there's a firmware handle. But certainly, I don't think we
should be operating on platform device if we can help it.
> drivers/of/of_net.c | 37 +++--
> 1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> index 2344ad7fff5e..2323c6063eaf 100644
> --- a/drivers/of/of_net.c
> +++ b/drivers/of/of_net.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * of_get_phy_mode - Get phy mode for given device_node
> @@ -56,18 +57,42 @@ static int of_get_mac_addr(struct device_node *np, const
> char *name, u8 *addr)
> return -ENODEV;
> }
>
> -static int of_get_mac_addr_nvmem(struct device_node *np, u8 addr)
> +static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
> {
> struct platform_device *pdev = of_find_device_by_node(np);
> + struct nvmem_cell *cell;
> + const void *mac;
> + size_t len;
> int ret;
>
> - if (!pdev)
> - return -ENODEV;
> + /* Try lookup by device first, there might be a nvmem_cell_lookup
> +* associated with a given device.
> +*/
> + if (pdev) {
> + ret = nvmem_get_mac_address(&pdev->dev, addr);
> + put_device(&pdev->dev);
> + return ret;
> + }
> +
> + cell = of_nvmem_cell_get(np, "mac-address");
> + if (IS_ERR(cell))
> + return PTR_ERR(cell);
> +
> + mac = nvmem_cell_read(cell, &len);
> + nvmem_cell_put(cell);
> +
> + if (IS_ERR(mac))
> + return PTR_ERR(mac);
> +
> + if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
> + kfree(mac);
> + return -EINVAL;
> + }
>
> - ret = nvmem_get_mac_address(&pdev->dev, addr);
> - put_device(&pdev->dev);
> + ether_addr_copy(addr, mac);
> + kfree(mac);
>
> - return ret;
> + return 0;
> }
>
> /**
> --
> 2.20.1
>
Re: [PATCH net-next 3/3] dt-bindings: net: dsa: Document dsa,tag-protocol property
On Fri, Mar 26, 2021 at 11:56:48AM +0100, Tobias Waldekranz wrote: > The 'dsa,tag-protocol' is used to force a switch tree to use a > particular tag protocol, typically because the Ethernet controller > that it is connected to is not compatible with the default one. > > Signed-off-by: Tobias Waldekranz > --- > Documentation/devicetree/bindings/net/dsa/dsa.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > index 8a3494db4d8d..5dcfab049aa2 100644 > --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml > @@ -70,6 +70,13 @@ patternProperties: >device is what the switch port is connected to > $ref: /schemas/types.yaml#/definitions/phandle > > + dsa,tag-protocol: 'dsa' is not a vendor. > +description: > + Instead of the default, the switch will use this tag protocol > if > + possible. Useful when a device supports multiple protcols and > + the default is incompatible with the Ethernet device. > +$ref: /schemas/types.yaml#/definitions/string You need to define the possible strings. > + >phy-handle: true > >phy-mode: true > -- > 2.25.1 >
Re: [PATCHv1 1/6] dt-bindings: net: ethernet-phy: Fix the parsing of ethernet-phy compatible string
On Thu, 25 Mar 2021 12:42:20 +, Anand Moon wrote:
> Fix the parsing of check of pattern ethernet-phy-ieee802.3 used
> by the device tree to initialize the mdio phy.
>
> As per the of_mdio below 2 are valid compatible string
> "ethernet-phy-ieee802.3-c22"
> "ethernet-phy-ieee802.3-c45"
>
> Cc: Rob Herring
> Signed-off-by: Anand Moon
> ---
> Documentation/devicetree/bindings/net/ethernet-phy.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ethernet-phy.example.dt.yaml:
ethernet-phy@0: compatible: 'oneOf' conditional failed, one must be fixed:
['ethernet-phy-id0141.0e90', 'ethernet-phy-ieee802.3-c45'] is too long
Additional items are not allowed ('ethernet-phy-ieee802.3-c45' was
unexpected)
'ethernet-phy-ieee802.3-c22' was expected
'ethernet-phy-ieee802.3-c45' was expected
'ethernet-phy-id0141.0e90' does not match
'^ethernet-phy-ieee[0-9]{3}\\.[0-9][-][a-f0-9]{4}$'
From schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ethernet-phy.yaml
See https://patchwork.ozlabs.org/patch/1458341
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
Re: [PATCH net-next v3 v3 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Wed, Mar 24, 2021 at 11:19 AM Robert Hancock wrote: > > On Wed, 2021-03-24 at 11:08 -0600, Rob Herring wrote: > > On Fri, Mar 12, 2021 at 01:52:13PM -0600, Robert Hancock wrote: > > > Update DT bindings to describe all of the clocks that the axienet > > > driver will now be able to make use of. > > > > > > Signed-off-by: Robert Hancock > > > --- > > > .../bindings/net/xilinx_axienet.txt | 25 ++- > > > 1 file changed, 19 insertions(+), 6 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > index 2cd452419ed0..b8e4894bc634 100644 > > > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > > > @@ -42,11 +42,23 @@ Optional properties: > > > support both 1000BaseX and SGMII modes. If set, the phy-mode > > > should be set to match the mode selected on core reset (i.e. > > > by the basex_or_sgmii core input line). > > > -- clocks : AXI bus clock for the device. Refer to common clock > > > bindings. > > > - Used to calculate MDIO clock divisor. If not specified, it > > > is > > > - auto-detected from the CPU clock (but only on platforms > > > where > > > - this is possible). New device trees should specify this - > > > the > > > - auto detection is only for backward compatibility. > > > +- clock-names: Tuple listing input clock names. Possible clocks: > > > + s_axi_lite_clk: Clock for AXI register slave interface > > > + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS > > > interfaces > > > + ref_clk: Ethernet reference clock, used by signal delay > > > + primitives and transceivers > > > + mgt_clk: MGT reference clock (used by optional internal > > > + PCS/PMA PHY) > > > > '_clk' is redundant. > > True, but there are existing device trees which already referenced these names > because those are what was used by the Xilinx version of this driver and hence > the Xilinx device tree generation software. So for compatibility I think we > are > kind of stuck with those names.. upstream? If not, then it doesn't matter what downstream is doing. However, this isn't that important, so it's fine. Acked-by: Rob Herring
Re: [PATCH net-next 1/2] dt-bindings: ethernet-controller: create a type for PHY interface modes
On Wed, Mar 24, 2021 at 11:35:55AM +0100, Marek Behún wrote: > In order to be able to define a property describing an array of PHY > interface modes, we need to change the current scalar > `phy-connection-type`, which lists the possible PHY interface modes, to > an array of length 1 (otherwise we would need to define the same list at > two different places). > > Moreover Rob Herring says that we cannot reuse the values of a property; > we need to $ref a type. > > Move the definition of possible PHY interface modes from the > `phy-connection-type` property to an array type definition > `phy-connection-type-array`, and simply reference this type in the > original property. Why not just extend phy-connection-type to support more than 1 entry?
Re: [PATCH net-next v3 v3 1/2] dt-bindings: net: xilinx_axienet: Document additional clocks
On Fri, Mar 12, 2021 at 01:52:13PM -0600, Robert Hancock wrote: > Update DT bindings to describe all of the clocks that the axienet > driver will now be able to make use of. > > Signed-off-by: Robert Hancock > --- > .../bindings/net/xilinx_axienet.txt | 25 ++- > 1 file changed, 19 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > index 2cd452419ed0..b8e4894bc634 100644 > --- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt > +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.txt > @@ -42,11 +42,23 @@ Optional properties: > support both 1000BaseX and SGMII modes. If set, the phy-mode > should be set to match the mode selected on core reset (i.e. > by the basex_or_sgmii core input line). > -- clocks : AXI bus clock for the device. Refer to common clock bindings. > - Used to calculate MDIO clock divisor. If not specified, it is > - auto-detected from the CPU clock (but only on platforms where > - this is possible). New device trees should specify this - the > - auto detection is only for backward compatibility. > +- clock-names: Tuple listing input clock names. Possible clocks: > + s_axi_lite_clk: Clock for AXI register slave interface > + axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces > + ref_clk: Ethernet reference clock, used by signal delay > +primitives and transceivers > + mgt_clk: MGT reference clock (used by optional internal > +PCS/PMA PHY) '_clk' is redundant. > + > + Note that if s_axi_lite_clk is not specified by name, the > + first clock of any name is used for this. If that is also not > + specified, the clock rate is auto-detected from the CPU clock > + (but only on platforms where this is possible). New device > + trees should specify all applicable clocks by name - the > + fallbacks to an unnamed clock or to CPU clock are only for > + backward compatibility. > +- clocks: Phandles to input clocks matching clock-names. Refer to common > + clock bindings. > - axistream-connected: Reference to another node which contains the resources > for the AXI DMA controller used by this device. > If this is specified, the DMA-related resources from that > @@ -62,7 +74,8 @@ Example: > device_type = "network"; > interrupt-parent = <µblaze_0_axi_intc>; > interrupts = <2 0 1>; > - clocks = <&axi_clk>; > + clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", > "mgt_clk"; > + clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>; > phy-mode = "mii"; > reg = <0x40c0 0x4 0x50c0 0x4>; > xlnx,rxcsum = <0x2>; > -- > 2.27.0 >
Re: [PATCH 1/5] dt-bindings: soc: qcom: wcnss: Add firmware-name property
On Thu, 11 Mar 2021 16:33:14 -0800, Bjorn Andersson wrote: > The WCNSS needs firmware which differs between platforms, and possibly > boards. Add a new property "firmware-name" to allow the DT to specify > the platform/board specific path to this firmware file. > > Signed-off-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.txt | 7 +++ > 1 file changed, 7 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 00/10] Rid W=1 warnings from OF
On Tue, Mar 23, 2021 at 2:36 AM Lee Jones wrote: > > On Mon, 22 Mar 2021, Rob Herring wrote: > > > On Thu, Mar 18, 2021 at 4:40 AM Lee Jones wrote: > > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > kernel builds, which are currently overwhelmingly riddled with > > > niggly little warnings. > > > > > > v2: > > > - Provided some descriptions to exported functions > > > > > > Lee Jones (10): > > > of: device: Fix function name in header and provide missing > > > descriptions > > > of: dynamic: Fix incorrect parameter name and provide missing > > > descriptions > > > of: platform: Demote kernel-doc abuse > > > of: base: Fix some formatting issues and provide missing descriptions > > > of: property: Provide missing member description and remove excess > > > param > > > of: address: Provide descriptions for 'of_address_to_resource's params > > > of: fdt: Demote kernel-doc abuses and fix function naming > > > of: of_net: Provide function name and param description > > > of: overlay: Fix function name disparity > > > of: of_reserved_mem: Demote kernel-doc abuses > > > > > > drivers/of/address.c | 3 +++ > > > drivers/of/base.c| 16 +++- > > > drivers/of/device.c | 7 ++- > > > drivers/of/dynamic.c | 4 +++- > > > drivers/of/fdt.c | 23 --- > > > drivers/of/of_net.c | 3 +++ > > > drivers/of/of_reserved_mem.c | 6 +++--- > > > drivers/of/overlay.c | 2 +- > > > drivers/of/platform.c| 2 +- > > > drivers/of/property.c| 2 +- > > > 10 files changed, 44 insertions(+), 24 deletions(-) > > > > I still see some warnings (note this is with DT files added to doc > > build). Can you send follow-up patches: > > > > ../include/linux/of.h:1193: warning: Function parameter or member > > 'output' not described in 'of_property_read_string_index' > > ../include/linux/of.h:1193: warning: Excess function parameter > > 'out_string' description in 'of_property_read_string_index' > > ../include/linux/of.h:1461: warning: cannot understand function > > prototype: 'enum of_overlay_notify_action ' > > ../drivers/of/base.c:1781: warning: Excess function parameter 'prob' > > description in '__of_add_property' > > ../drivers/of/base.c:1804: warning: Excess function parameter 'prob' > > description in 'of_add_property' > > ../drivers/of/base.c:1855: warning: Function parameter or member > > 'prop' not described in 'of_remove_property' > > ../drivers/of/base.c:1855: warning: Excess function parameter 'prob' > > description in 'of_remove_property' > > You don't want much do you! ;) Hey, want to fix all the schema warnings for me? ;) > > Sure, I plan to clean up all of the kernel with subsequent patches. > > > BTW, there some more which I guess W=1 doesn't find: > > > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:906: WARNING: Block quote ends without a blank > > line; unexpected unindent. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1465: WARNING: Definition list ends without a > > blank line; unexpected unindent. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1469: WARNING: Definition list ends without a > > blank line; unexpected unindent. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1473: WARNING: Definition list ends without a > > blank line; unexpected unindent. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1517: WARNING: Definition list ends without a > > blank line; unexpected unindent. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1521: WARNING: Definition list ends without a > > blank line; unexpected unindent. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1526: WARNING: Unexpected indentation. > > /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: > > ../drivers/of/base.c:1528: WARNING: Block quote ends without a blank > > line; unexpected unind
Re: [PATCH v5 02/24] dt-bindings: introduce silabs,wfx.yaml
On Mon, 15 Mar 2021 14:24:39 +0100, Jerome Pouiller wrote: > From: Jérôme Pouiller > > Prepare the inclusion of the wfx driver in the kernel. > > Signed-off-by: Jérôme Pouiller > --- > .../bindings/net/wireless/silabs,wfx.yaml | 133 ++ > 1 file changed, 133 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > Reviewed-by: Rob Herring
Re: [PATCH v2 00/10] Rid W=1 warnings from OF
On Thu, Mar 18, 2021 at 4:40 AM Lee Jones wrote: > > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > v2: > - Provided some descriptions to exported functions > > Lee Jones (10): > of: device: Fix function name in header and provide missing > descriptions > of: dynamic: Fix incorrect parameter name and provide missing > descriptions > of: platform: Demote kernel-doc abuse > of: base: Fix some formatting issues and provide missing descriptions > of: property: Provide missing member description and remove excess > param > of: address: Provide descriptions for 'of_address_to_resource's params > of: fdt: Demote kernel-doc abuses and fix function naming > of: of_net: Provide function name and param description > of: overlay: Fix function name disparity > of: of_reserved_mem: Demote kernel-doc abuses > > drivers/of/address.c | 3 +++ > drivers/of/base.c| 16 +++- > drivers/of/device.c | 7 ++- > drivers/of/dynamic.c | 4 +++- > drivers/of/fdt.c | 23 --- > drivers/of/of_net.c | 3 +++ > drivers/of/of_reserved_mem.c | 6 +++--- > drivers/of/overlay.c | 2 +- > drivers/of/platform.c| 2 +- > drivers/of/property.c| 2 +- > 10 files changed, 44 insertions(+), 24 deletions(-) I still see some warnings (note this is with DT files added to doc build). Can you send follow-up patches: ../include/linux/of.h:1193: warning: Function parameter or member 'output' not described in 'of_property_read_string_index' ../include/linux/of.h:1193: warning: Excess function parameter 'out_string' description in 'of_property_read_string_index' ../include/linux/of.h:1461: warning: cannot understand function prototype: 'enum of_overlay_notify_action ' ../drivers/of/base.c:1781: warning: Excess function parameter 'prob' description in '__of_add_property' ../drivers/of/base.c:1804: warning: Excess function parameter 'prob' description in 'of_add_property' ../drivers/of/base.c:1855: warning: Function parameter or member 'prop' not described in 'of_remove_property' ../drivers/of/base.c:1855: warning: Excess function parameter 'prob' description in 'of_remove_property' BTW, there some more which I guess W=1 doesn't find: /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:906: WARNING: Block quote ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1465: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1469: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1473: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1517: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1521: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1526: WARNING: Unexpected indentation. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1528: WARNING: Block quote ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1529: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1533: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:19: ../drivers/of/base.c:1705: WARNING: Definition list ends without a blank line; unexpected unindent. /home/rob/proj/git/linux-dt/Documentation/driver-api/devicetree:49: ../drivers/of/overlay.c:1183: WARNING: Inline emphasis start-string without end-string. Rob
Re: [PATCH 1/2] dt-bindings: dp83867: Add binding for LED mode configuration
On Fri, 19 Mar 2021 16:57:09 +0100, Michael Tretter wrote:
> The DP83867 supports four configurable LED pins. Describe the
> multiplexing of functions to the LEDs via device tree.
>
> Signed-off-by: Michael Tretter
> ---
> .../devicetree/bindings/net/ti,dp83867.yaml | 24 +++
> include/dt-bindings/net/ti-dp83867.h | 16 +
> 2 files changed, 40 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ti,dp83867.yaml:
properties:ti,dp83867-led-mode-names:items: 'anyOf' conditional failed, one
must be fixed:
{'anyOf': {'items': [{'const': 'led-0'}, {'const': 'led-1'}, {'const':
'led-2'}, {'const': 'led-gpio'}]}} is not of type 'array'
{'items': [{'const': 'led-0'}, {'const': 'led-1'}, {'const': 'led-2'},
{'const': 'led-gpio'}]} is not of type 'array'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ti,dp83867.yaml:
properties:ti,dp83867-led-mode-names:items: {'anyOf': {'items': [{'const':
'led-0'}, {'const': 'led-1'}, {'const': 'led-2'}, {'const': 'led-gpio'}]}} is
not of type 'array'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ti,dp83867.yaml:
properties:ti,dp83867-led-mode-names:items: 'oneOf' conditional failed, one
must be fixed:
{'anyOf': {'items': [{'const': 'led-0'}, {'const': 'led-1'}, {'const':
'led-2'}, {'const': 'led-gpio'}]}} is not of type 'array'
{'items': [{'const': 'led-0'}, {'const': 'led-1'}, {'const': 'led-2'},
{'const': 'led-gpio'}]} is not of type 'array'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/ti,dp83867.yaml:
ignoring, error in schema: properties: ti,dp83867-led-mode-names: items
warning: no schema found in file:
./Documentation/devicetree/bindings/net/ti,dp83867.yaml
See https://patchwork.ozlabs.org/patch/1455937
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
[PATCH] dt-bindings: Drop type references on common properties
Users of common properties shouldn't have a type definition as the common schemas already have one. Drop all the unnecessary type references in the tree. A meta-schema update to catch these is pending. Cc: Nicolas Saenz Julienne Cc: Maxime Ripard Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: Bjorn Andersson Cc: Krzysztof Kozlowski Cc: Marc Kleine-Budde Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Srinivas Kandagatla Cc: Ohad Ben-Cohen Cc: Mark Brown Cc: Cheng-Yi Chiang Cc: Benson Leung Cc: Zhang Rui Cc: Daniel Lezcano Cc: Greg Kroah-Hartman Cc: Stefan Wahren Cc: Masahiro Yamada Cc: Odelu Kukatla Cc: Alex Elder Cc: Suman Anna Cc: Kuninori Morimoto Cc: Dmitry Baryshkov Cc: linux-g...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-remotep...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 + Documentation/devicetree/bindings/arm/cpus.yaml | 2 -- .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 1 - .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml| 3 +-- .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 1 - .../devicetree/bindings/interconnect/qcom,rpmh.yaml | 1 - .../bindings/memory-controllers/nvidia,tegra210-emc.yaml | 2 +- Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml | 1 - Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 - Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml | 2 -- .../devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml | 2 +- Documentation/devicetree/bindings/sound/ak4642.yaml | 2 -- .../devicetree/bindings/sound/google,cros-ec-codec.yaml | 2 +- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml| 1 - .../devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml | 1 - Documentation/devicetree/bindings/usb/usb.yaml | 1 - 16 files changed, 5 insertions(+), 23 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml index a2c63c8b1d10..c6144c8421fa 100644 --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml @@ -26,10 +26,7 @@ properties: - const: simple-mfd mboxes: -$ref: '/schemas/types.yaml#/definitions/phandle' -description: | - Phandle to the firmware device's Mailbox. - (See: ../mailbox/mailbox.txt for more information) +maxItems: 1 clocks: type: object diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 26b886b20b27..6be4a8852ee5 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -256,13 +256,11 @@ properties: where voltage is in V, frequency is in MHz. power-domains: -$ref: '/schemas/types.yaml#/definitions/phandle-array' description: List of phandles and PM domain specifiers, as defined by bindings of the PM domain provider (see also ../power_domain.txt). power-domain-names: -$ref: '/schemas/types.yaml#/definitions/string-array' description: A list of power domain name strings sorted in the same order as the power-domains property. diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml index c13faf3e6581..3a7d5d731712 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml @@ -73,7 +73,6 @@ properties: clock-output-names: description: Name of the LCD pixel clock created. -$ref: /schemas/types.yaml#/definitions/string-array maxItems: 1 dmas: diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml index 1a54db04f29d..bcafa494ed7a 100644 --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml @@ -43,8 +43,7 @@ properties: gpio-ranges: true - gpio-ranges-group-names: -$ref: /schemas/types.yaml#/definitions/string-array + gpio-ranges-group-names: true socionext,interrupt-ranges: description: | diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 6f2398cdc82d..1e7894e524f9 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.ya
Re: [PATCH v1 7/7] dt-bindings: net: qcom-ipa: Document qcom,msm8998-ipa compatible
On Thu, Feb 11, 2021 at 06:50:15PM +0100, AngeloGioacchino Del Regno wrote: > MSM8998 support has been added: document the new compatible. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index b063c6c1077a..9dacd224b606 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -46,6 +46,7 @@ properties: > oneOf: >- items: >- enum: > + - "qcom,msm8998-ipa" Also, don't need quotes on these. >- "qcom,sdm845-ipa" >- "qcom,sc7180-ipa" > > -- > 2.30.0 >
Re: [PATCH v1 6/7] dt-bindings: net: qcom-ipa: Document qcom,sc7180-ipa compatible
On Thu, Feb 11, 2021 at 06:50:14PM +0100, AngeloGioacchino Del Regno wrote: > The driver supports SC7180, but the binding was not documented. > Just add it. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index 8a2d12644675..b063c6c1077a 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -43,7 +43,11 @@ description: > > properties: >compatible: > -const: "qcom,sdm845-ipa" > +oneOf: > + - items: > + - enum: Just enum, you don't need oneOf when only 1. And items is implied when only 1 entry. > + - "qcom,sdm845-ipa" > + - "qcom,sc7180-ipa" > >reg: > items: > -- > 2.30.0 >
[PATCH v2 2/2] driver core: platform: Drop of_device_node_put() wrapper
of_device_node_put() is just a wrapper for of_node_put(). The platform
driver core is already polluted with of_node pointers and the only 'get'
already uses of_node_get() (though typically the get would happen in
of_device_alloc()).
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Frank Rowand
Signed-off-by: Rob Herring
---
v2:
- Fix build
---
drivers/base/platform.c | 2 +-
include/linux/of_device.h | 7 ---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 95fd1549f87d..9d5171e5f967 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -571,7 +571,7 @@ static void platform_device_release(struct device *dev)
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
- of_device_node_put(&pa->pdev.dev);
+ of_node_put(pa->pdev.dev.of_node);
kfree(pa->pdev.dev.platform_data);
kfree(pa->pdev.mfd_cell);
kfree(pa->pdev.resource);
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index d7a407dfeecb..1d7992a02e36 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -38,11 +38,6 @@ extern int of_device_request_module(struct device *dev);
extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int of_device_uevent_modalias(struct device *dev, struct
kobj_uevent_env *env);
-static inline void of_device_node_put(struct device *dev)
-{
- of_node_put(dev->of_node);
-}
-
static inline struct device_node *of_cpu_device_node_get(int cpu)
{
struct device *cpu_dev;
@@ -94,8 +89,6 @@ static inline int of_device_uevent_modalias(struct device
*dev,
return -ENODEV;
}
-static inline void of_device_node_put(struct device *dev) { }
-
static inline const struct of_device_id *of_match_device(
const struct of_device_id *matches, const struct device *dev)
{
--
2.27.0
[PATCH v2 1/2] of: Remove of_dev_{get,put}()
of_dev_get() and of_dev_put are just wrappers for get_device()/put_device()
on a platform_device. There's also already platform_device_{get,put}()
wrappers for this purpose. Let's update the few users and remove
of_dev_{get,put}().
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Frank Rowand
Cc: Patrice Chotard
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Julia Lawall
Cc: Gilles Muller
Cc: Nicolas Palix
Cc: Michal Marek
Cc: linuxppc-...@lists.ozlabs.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: co...@systeme.lip6.fr
Signed-off-by: Rob Herring
---
v2:
- Fix build
---
arch/powerpc/platforms/pseries/ibmebus.c | 4 ++--
drivers/net/ethernet/ibm/emac/core.c | 15 ---
drivers/of/device.c | 21 -
drivers/of/platform.c| 4 ++--
drivers/of/unittest.c| 2 +-
drivers/usb/dwc3/dwc3-st.c | 2 +-
include/linux/of_device.h| 3 ---
scripts/coccinelle/free/put_device.cocci | 1 -
8 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c
b/arch/powerpc/platforms/pseries/ibmebus.c
index 8c6e509f6967..a15ab33646b3 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -355,12 +355,12 @@ static int ibmebus_bus_device_probe(struct device *dev)
if (!drv->probe)
return error;
- of_dev_get(of_dev);
+ get_device(dev);
if (of_driver_match_device(dev, dev->driver))
error = drv->probe(of_dev);
if (error)
- of_dev_put(of_dev);
+ put_device(dev);
return error;
}
diff --git a/drivers/net/ethernet/ibm/emac/core.c
b/drivers/net/ethernet/ibm/emac/core.c
index c00b9097eeea..471be6ec7e8a 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2390,11 +2391,11 @@ static int emac_check_deps(struct emac_instance *dev,
static void emac_put_deps(struct emac_instance *dev)
{
- of_dev_put(dev->mal_dev);
- of_dev_put(dev->zmii_dev);
- of_dev_put(dev->rgmii_dev);
- of_dev_put(dev->mdio_dev);
- of_dev_put(dev->tah_dev);
+ platform_device_put(dev->mal_dev);
+ platform_device_put(dev->zmii_dev);
+ platform_device_put(dev->rgmii_dev);
+ platform_device_put(dev->mdio_dev);
+ platform_device_put(dev->tah_dev);
}
static int emac_of_bus_notify(struct notifier_block *nb, unsigned long action,
@@ -2435,7 +2436,7 @@ static int emac_wait_deps(struct emac_instance *dev)
for (i = 0; i < EMAC_DEP_COUNT; i++) {
of_node_put(deps[i].node);
if (err)
- of_dev_put(deps[i].ofdev);
+ platform_device_put(deps[i].ofdev);
}
if (err == 0) {
dev->mal_dev = deps[EMAC_DEP_MAL_IDX].ofdev;
@@ -2444,7 +2445,7 @@ static int emac_wait_deps(struct emac_instance *dev)
dev->tah_dev = deps[EMAC_DEP_TAH_IDX].ofdev;
dev->mdio_dev = deps[EMAC_DEP_MDIO_IDX].ofdev;
}
- of_dev_put(deps[EMAC_DEP_PREV_IDX].ofdev);
+ platform_device_put(deps[EMAC_DEP_PREV_IDX].ofdev);
return err;
}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index aedfaaafd3e7..9a748855b39d 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -33,27 +33,6 @@ const struct of_device_id *of_match_device(const struct
of_device_id *matches,
}
EXPORT_SYMBOL(of_match_device);
-struct platform_device *of_dev_get(struct platform_device *dev)
-{
- struct device *tmp;
-
- if (!dev)
- return NULL;
- tmp = get_device(&dev->dev);
- if (tmp)
- return to_platform_device(tmp);
- else
- return NULL;
-}
-EXPORT_SYMBOL(of_dev_get);
-
-void of_dev_put(struct platform_device *dev)
-{
- if (dev)
- put_device(&dev->dev);
-}
-EXPORT_SYMBOL(of_dev_put);
-
int of_device_add(struct platform_device *ofdev)
{
BUG_ON(ofdev->dev.of_node == NULL);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 79bd5f5a1bf1..020bf860c72c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -687,7 +687,7 @@ static int of_platform_notify(struct notifier_block *nb,
pdev_parent = of_find_device_by_node(rd->dn->parent);
pdev = of_platform_device_create(rd->dn, NULL,
pdev_parent ? &pdev_parent->dev : NULL);
- of_dev_put(pdev_parent);
+ platform_device_put(pdev_parent);
if (pdev =
[PATCH v2 0/2] of: of_device.h cleanups
This is a couple of cleanups for of_device.h. They fell out from my
attempt at decoupling of_device.h and of_platform.h which is a mess
and I haven't finished, but there's no reason to wait on these.
Rob
Rob Herring (2):
of: Remove of_dev_{get,put}()
driver core: platform: Drop of_device_node_put() wrapper
arch/powerpc/platforms/pseries/ibmebus.c | 4 ++--
drivers/base/platform.c | 2 +-
drivers/net/ethernet/ibm/emac/core.c | 15 ---
drivers/of/device.c | 21 -
drivers/of/platform.c| 4 ++--
drivers/of/unittest.c| 2 +-
drivers/usb/dwc3/dwc3-st.c | 2 +-
include/linux/of_device.h| 10 --
scripts/coccinelle/free/put_device.cocci | 1 -
9 files changed, 15 insertions(+), 46 deletions(-)
--
2.27.0
[PATCH 2/2] driver core: platform: Drop of_device_node_put() wrapper
of_device_node_put() is just a wrapper for of_node_put(). The platform
driver core is already polluted with of_node pointers and the only 'get'
already uses of_node_get() (though typically the get would happen in
of_device_alloc()).
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Frank Rowand
Signed-off-by: Rob Herring
---
drivers/base/platform.c | 2 +-
include/linux/of_device.h | 7 ---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 95fd1549f87d..c31bc9e92dd1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -571,7 +571,7 @@ static void platform_device_release(struct device *dev)
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
- of_device_node_put(&pa->pdev.dev);
+ of_node_put(&pa->pdev.dev->of_node);
kfree(pa->pdev.dev.platform_data);
kfree(pa->pdev.mfd_cell);
kfree(pa->pdev.resource);
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index d7a407dfeecb..1d7992a02e36 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -38,11 +38,6 @@ extern int of_device_request_module(struct device *dev);
extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int of_device_uevent_modalias(struct device *dev, struct
kobj_uevent_env *env);
-static inline void of_device_node_put(struct device *dev)
-{
- of_node_put(dev->of_node);
-}
-
static inline struct device_node *of_cpu_device_node_get(int cpu)
{
struct device *cpu_dev;
@@ -94,8 +89,6 @@ static inline int of_device_uevent_modalias(struct device
*dev,
return -ENODEV;
}
-static inline void of_device_node_put(struct device *dev) { }
-
static inline const struct of_device_id *of_match_device(
const struct of_device_id *matches, const struct device *dev)
{
--
2.27.0
[PATCH 1/2] of: Remove of_dev_{get,put}()
of_dev_get() and of_dev_put are just wrappers for get_device()/put_device()
on a platform_device. There's also already platform_device_{get,put}()
wrappers for this purpose. Let's update the few users and remove
of_dev_{get,put}().
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Frank Rowand
Cc: Patrice Chotard
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Julia Lawall
Cc: Gilles Muller
Cc: Nicolas Palix
Cc: Michal Marek
Cc: linuxppc-...@lists.ozlabs.org
Cc: netdev@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: co...@systeme.lip6.fr
Signed-off-by: Rob Herring
---
arch/powerpc/platforms/pseries/ibmebus.c | 4 ++--
drivers/net/ethernet/ibm/emac/core.c | 15 ---
drivers/of/device.c | 21 -
drivers/of/platform.c| 4 ++--
drivers/of/unittest.c| 2 +-
drivers/usb/dwc3/dwc3-st.c | 2 +-
include/linux/of_device.h| 3 ---
scripts/coccinelle/free/put_device.cocci | 1 -
8 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c
b/arch/powerpc/platforms/pseries/ibmebus.c
index 8c6e509f6967..c29328fe94e8 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -355,12 +355,12 @@ static int ibmebus_bus_device_probe(struct device *dev)
if (!drv->probe)
return error;
- of_dev_get(of_dev);
+ get_device(dev);
if (of_driver_match_device(dev, dev->driver))
error = drv->probe(of_dev);
if (error)
- of_dev_put(of_dev);
+ put_device(of_dev);
return error;
}
diff --git a/drivers/net/ethernet/ibm/emac/core.c
b/drivers/net/ethernet/ibm/emac/core.c
index c00b9097eeea..471be6ec7e8a 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2390,11 +2391,11 @@ static int emac_check_deps(struct emac_instance *dev,
static void emac_put_deps(struct emac_instance *dev)
{
- of_dev_put(dev->mal_dev);
- of_dev_put(dev->zmii_dev);
- of_dev_put(dev->rgmii_dev);
- of_dev_put(dev->mdio_dev);
- of_dev_put(dev->tah_dev);
+ platform_device_put(dev->mal_dev);
+ platform_device_put(dev->zmii_dev);
+ platform_device_put(dev->rgmii_dev);
+ platform_device_put(dev->mdio_dev);
+ platform_device_put(dev->tah_dev);
}
static int emac_of_bus_notify(struct notifier_block *nb, unsigned long action,
@@ -2435,7 +2436,7 @@ static int emac_wait_deps(struct emac_instance *dev)
for (i = 0; i < EMAC_DEP_COUNT; i++) {
of_node_put(deps[i].node);
if (err)
- of_dev_put(deps[i].ofdev);
+ platform_device_put(deps[i].ofdev);
}
if (err == 0) {
dev->mal_dev = deps[EMAC_DEP_MAL_IDX].ofdev;
@@ -2444,7 +2445,7 @@ static int emac_wait_deps(struct emac_instance *dev)
dev->tah_dev = deps[EMAC_DEP_TAH_IDX].ofdev;
dev->mdio_dev = deps[EMAC_DEP_MDIO_IDX].ofdev;
}
- of_dev_put(deps[EMAC_DEP_PREV_IDX].ofdev);
+ platform_device_put(deps[EMAC_DEP_PREV_IDX].ofdev);
return err;
}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index aedfaaafd3e7..9a748855b39d 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -33,27 +33,6 @@ const struct of_device_id *of_match_device(const struct
of_device_id *matches,
}
EXPORT_SYMBOL(of_match_device);
-struct platform_device *of_dev_get(struct platform_device *dev)
-{
- struct device *tmp;
-
- if (!dev)
- return NULL;
- tmp = get_device(&dev->dev);
- if (tmp)
- return to_platform_device(tmp);
- else
- return NULL;
-}
-EXPORT_SYMBOL(of_dev_get);
-
-void of_dev_put(struct platform_device *dev)
-{
- if (dev)
- put_device(&dev->dev);
-}
-EXPORT_SYMBOL(of_dev_put);
-
int of_device_add(struct platform_device *ofdev)
{
BUG_ON(ofdev->dev.of_node == NULL);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 79bd5f5a1bf1..020bf860c72c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -687,7 +687,7 @@ static int of_platform_notify(struct notifier_block *nb,
pdev_parent = of_find_device_by_node(rd->dn->parent);
pdev = of_platform_device_create(rd->dn, NULL,
pdev_parent ? &pdev_parent->dev : NULL);
- of_dev_put(pdev_parent);
+ platform_device_put(pdev_parent);
if (pdev == NU
[PATCH 0/2] of: of_device.h cleanups
This is a couple of cleanups for of_device.h. They fell out from my
attempt at decoupling of_device.h and of_platform.h which is a mess
and I haven't finished, but there's no reason to wait on these.
Rob
Rob Herring (2):
of: Remove of_dev_{get,put}()
driver core: platform: Drop of_device_node_put() wrapper
arch/powerpc/platforms/pseries/ibmebus.c | 4 ++--
drivers/base/platform.c | 2 +-
drivers/net/ethernet/ibm/emac/core.c | 15 ---
drivers/of/device.c | 21 -
drivers/of/platform.c| 4 ++--
drivers/of/unittest.c| 2 +-
drivers/usb/dwc3/dwc3-st.c | 2 +-
include/linux/of_device.h| 10 --
scripts/coccinelle/free/put_device.cocci | 1 -
9 files changed, 15 insertions(+), 46 deletions(-)
--
2.27.0
Re: [PATCH v2 net-next 2/4] dt-bindings: net: Add bindings for Qualcomm QCA807x
On Wed, Feb 10, 2021 at 01:55:21PM +0100, Robert Marko wrote:
> Add DT bindings for Qualcomm QCA807x PHYs.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> Changes in v2:
> * Drop LED properties
> * Directly define PSGMII/QSGMII SerDes driver values
>
> .../devicetree/bindings/net/qcom,qca807x.yaml | 70 +++
> 1 file changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/qcom,qca807x.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
> b/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
> new file mode 100644
> index ..0867f5e698cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/qcom,qca807x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QCA807x PHY
> +
> +maintainers:
> + - Robert Marko
> +
> +description: |
> + Bindings for Qualcomm QCA807x PHYs
> +
> +allOf:
> + - $ref: ethernet-phy.yaml#
> +
> +properties:
> + reg:
> +maxItems: 1
> +
> + qcom,fiber-enable:
> +description: |
> + If present, then PHYs combo port is configured to operate in combo
> + mode. In combo mode autodetection of copper and fiber media is
> + used in order to support both of them.
> + Combo mode can be strapped as well, if not strapped this property
> + will set combo support anyway.
> +type: boolean
> +
> + qcom,psgmii-az:
> +description: |
> + If present, then PSMGII PHY will advertise 802.3-az support to
> + the MAC.
Sounds like a standard thing that should be common?
> +type: boolean
> +
> + gpio-controller: true
> + "#gpio-cells":
> +const: 2
> +
> + qcom,tx-driver-strength:
> +description: PSGMII/QSGMII SerDes TX driver strength control in mV.
Use standard unit suffix as defined in property-units.txt.
Again, seems like a common property?
> +$ref: /schemas/types.yaml#/definitions/uint32
Then you can drop this.
> +enum: [140, 160, 180, 200, 220, 240, 260, 280, 300, 320, 400, 500, 600]
> +
> + qcom,control-dac:
> +description: Analog MDI driver amplitude and bias current.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> +required:
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> +compatible = "ethernet-phy-ieee802.3-c22";
> +reg = <0>;
> +
> +qcom,control-dac = ;
> + };
> +};
> --
> 2.29.2
>
Re: [PATCH v12 net-next 01/15] doc: marvell: add CM3 address space and PPv2.3 description
On Wed, 10 Feb 2021 11:48:06 +0200, stef...@marvell.com wrote: > From: Stefan Chulski > > Patch adds CM3 address space and PPv2.3 description. > > Signed-off-by: Stefan Chulski > Acked-by: Marcin Wojtas > --- > Documentation/devicetree/bindings/net/marvell-pp2.txt | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH 02/16] dt-bindings: net: Add Baikal-T1 GMAC bindings
On Mon, Feb 08, 2021 at 05:08:06PM +0300, Serge Semin wrote:
> Baikal-T1 SoC is equipped with two DW GMAC v3.73a-based 1GBE ethernet
> interfaces synthesized with: RGMII PHY interface, AXI-DMA and APB3 CSR,
> 16KB Tx/Rx FIFOs and PBL up to half of that, PTP, PMT, TCP/IP CoE, up to 4
> outstanding AXI read/write requests, maximum AXI burst length of 16 beats,
> up to eight MAC address slots, one GPI and one GPO ports. Generic DW
> MAC/STMMAC driver will easily handle the DT-node describing the Baikal-T1
> GMAC network devices, but the bindings still needs to be created to have a
> better understanding of what the interface looks like.
>
> Signed-off-by: Serge Semin
>
> ---
>
> Rob, please note I couldn't declare the axi-config object properties
> constraints
> without specifying the properties type and description. If I remove them the
> dt_binding_check will curse with the error:
>
> >> .../baikal,bt1-gmac.yaml: properties:axi-config:properties:snps,blen:
> >> 'description' is a required property
> >> .../baikal,bt1-gmac.yaml:
> >> properties:axi-config:properties:snps,wr_osr_lmt: 'oneOf' conditional
> >> failed, one must be fixed:
> 'type' is a required property
> Additional properties are not allowed ('maximum' was unexpected)
> >> ...
>
> I did't know what to do with these errors, so I just created normal sub-node
> properties with stricter constraints than they are specified in the main
> snps,dwmac.yaml schema. Any suggestion what is a better way to apply
> additional constraints on sub-node properties?
Yes, that's known problem which I don't have a solution for. I think the
solution is checking all properties have a type defined once and only
once. That would also make sure we don't have 2 property names with
different types. With that we can loosen the meta-schema checks. In the
vast majority of cases though we need a type, so the exceptions like
here will need to duplicate the type and description.
Reviewed-by: Rob Herring
> ---
> .../bindings/net/baikal,bt1-gmac.yaml | 150 ++
> 1 file changed, 150 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml
Re: [PATCH 01/16] dt-bindings: net: dwmac: Add DW GMAC GPIOs properties
On Mon, Feb 08, 2021 at 05:08:05PM +0300, Serge Semin wrote: > Synopsys DesignWare Ethernet controllers can be synthesized with > General-Purpose IOs support. GPIOs can work either as inputs or as outputs > thus belong to the gpi_i and gpo_o ports respectively. The ports width > (number of possible inputs/outputs) and the configuration registers layout > depend on the IP-core version. For instance, DW GMAC can have from 0 to 4 > GPIs and from 0 to 4 GPOs, while DW xGMAC have a wider ports width up to > 16 pins of each one. > > So the DW MAC DT-node can be equipped with "ngpios" property, which can't > have a value greater than 32, standard GPIO-related properties like > "gpio-controller" and "#gpio-cells", and, if GPIs are supposed to be > detected, IRQ-controller related properties. > > Signed-off-by: Serge Semin > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > index bdc437b14878..fcca23d3727e 100644 > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > @@ -110,6 +110,23 @@ properties: >reset-names: > const: stmmaceth > > + ngpios: > +description: > + Total number of GPIOs the MAC supports. The property shall include both > + the GPI and GPO ports width. > +minimum: 1 > +maximum: 32 Does the driver actually need this? I'd omit it if just to validate consumers are in range. Are GPI and GPO counts independent? If so, this isn't really sufficient. Rob
Re: [PATCH] dt-bindings: can: rcar_canfd: Group tuples in pin control properties
On Thu, 04 Feb 2021 13:59:37 +0100, Geert Uytterhoeven wrote: > To improve human readability and enable automatic validation, the tuples > in "pinctrl-*" properties should be grouped using angle brackets. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks!
Re: [PATCH v2 07/24] dt-bindings: net: dwmac: Detach Generic DW MAC bindings
On Mon, Feb 08, 2021 at 04:55:51PM +0300, Serge Semin wrote: > Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes > describing generic DW MAC devices and as DT schema with common properties > to be evaluated against a vendor-specific DW MAC IP-cores. Due to such > dual-purpose design the "compatible" property of the common DW MAC schema > needs to contain the vendor-specific strings to successfully pass the > schema evaluation in case if it's referenced from the vendor-specific DT > bindings. That's a bad design from maintainability point of view, since > adding/removing any DW MAC-based device bindings requires the common > schema modification. In order to fix that let's detach the schema which > provides the generic DW MAC DT nodes evaluation into a dedicated DT > bindings file preserving the common DW MAC properties declaration in the > snps,dwmac.yaml file. By doing so we'll still provide a common properties > evaluation for each vendor-specific MAC bindings which refer to the > common bindings file, while the generic DW MAC DT nodes will be checked > against the new snps,dwmac-generic.yaml DT schema. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Add a note to the snps,dwmac-generic.yaml bindings file description of > a requirement to create a new DT bindings file for the vendor-specific > versions of the DW MAC. > --- > .../bindings/net/snps,dwmac-generic.yaml | 154 ++ > .../devicetree/bindings/net/snps,dwmac.yaml | 139 +--- > 2 files changed, 155 insertions(+), 138 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > new file mode 100644 > index ..6c3bf5b2f890 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml > @@ -0,0 +1,154 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Synopsys DesignWare Generic MAC Device Tree Bindings > + > +maintainers: > + - Alexandre Torgue > + - Giuseppe Cavallaro > + - Jose Abreu > + > +description: > + The primary purpose of this bindings file is to validate the Generic > + Synopsys Desginware MAC DT nodes defined in accordance with the select > + schema. All new vendor-specific versions of the DW *MAC IP-cores must > + be described in a dedicated DT bindings file. > + > +# Select the DT nodes, which have got compatible strings either as just a > +# single string with IP-core name optionally followed by the IP version or > +# two strings: one with IP-core name plus the IP version, another as just > +# the IP-core name. > +select: > + properties: > +compatible: > + oneOf: > +- items: > +- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$" Use '' instead of "" and you can skip the double \. With that, Reviewed-by: Rob Herring > +- items: > +- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$" > +- const: snps,dwmac > +- items: > +- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$" > +- const: snps,dwxgmac
Re: [PATCH V2 net-next 1/2] dt-bindings: net: document BCM4908 Ethernet controller
On Sun, Feb 07, 2021 at 11:26:31PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> BCM4908 is a family of SoCs with integrated Ethernet controller.
>
> Signed-off-by: Rafał Miłecki
> ---
> .../bindings/net/brcm,bcm4908enet.yaml| 45 +++
> 1 file changed, 45 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
> b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
> new file mode 100644
> index ..5f12f51c5b19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/brcm,bcm4908enet.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/brcm,bcm4908enet.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom BCM4908 Ethernet controller
> +
> +description: Broadcom's Ethernet controller integrated into BCM4908 family
> SoCs
> +
> +maintainers:
> + - Rafał Miłecki
> +
allOf:
- $ref: 'ethernet-controller.yaml#'
> +properties:
> + compatible:
> +const: brcm,bcm4908enet
Normal convention is 'brcm,bcm4908-enet'. (And update the filename/$id)
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +description: RX interrupt
> +
> + interrupt-names:
> +const: rx
Don't really need *-names when only 1 possible entry.
> +
> +required:
> + - reg
> + - interrupts
> + - interrupt-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +ethernet@80002000 {
> +compatible = "brcm,bcm4908enet";
> +reg = <0x80002000 0x1000>;
> +
> +interrupts = ;
> +interrupt-names = "rx";
> +};
> --
> 2.26.2
>
Re: [PATCH v2 04/24] dt-bindings: net: dwmac: Refactor snps,*-config properties
On Mon, Feb 08, 2021 at 04:55:48PM +0300, Serge Semin wrote: > Currently the "snps,axi-config", "snps,mtl-rx-config" and > "snps,mtl-tx-config" properties are declared as a single phandle reference > to a node with corresponding parameters defined. That's not good for > several reasons. First of all scattering around a device tree some > particular device-specific configs with no visual relation to that device > isn't suitable from maintainability point of view. That leads to a > disturbed representation of the actual device tree mixing actual device > nodes and some vendor-specific configs. Secondly using the same configs > set for several device nodes doesn't represent well the devices structure, > since the interfaces these configs describe in hardware belong to > different devices and may actually differ. In the later case having the > configs node separated from the corresponding device nodes gets to be > even unjustified. > > So instead of having a separate DW *MAC configs nodes we suggest to > define them as sub-nodes of the device nodes, which interfaces they > actually describe. By doing so we'll make the DW *MAC nodes visually > correct describing all the aspects of the IP-core configuration. Thus > we'll be able to describe the configs sub-nodes bindings right in the > snps,dwmac.yaml file. > > Note the former "snps,axi-config", "snps,mtl-rx-config" and > "snps,mtl-tx-config" properties have been marked as deprecated in favor of > the added by this commit "axi-config", "mtl-rx-config" and "mtl-tx-config" > sub-nodes respectively. > > Signed-off-by: Serge Semin > > --- > > Note this change will work only if DT-schema tool is fixed like this: > > --- a/meta-schemas/nodes.yaml 2021-02-08 14:20:56.732447780 +0300 > +++ b/meta-schemas/nodes.yaml 2021-02-08 14:21:00.736492245 +0300 > @@ -22,6 +22,7 @@ > - unevaluatedProperties > - deprecated > - required > +- not > - allOf > - anyOf > - oneOf Can you send me a patch or GH PR. There is another way to express. More below. > > So a property with name "not" would be allowed and the "not-required" > pattern would work. > > Changelog v2: > - Add the new sub-nodes "axi-config", "mtl-rx-config" and "mtl-tx-config" > describing the nodes now deprecated properties were supposed to > refer to. > - Fix invalid identation in the "snps,route-*" property settings. > - Use correct syntax of the JSON pointers, so the later would begin > with a '/' after the '#'. > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 389 +- > 1 file changed, 297 insertions(+), 92 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > index 03d58bf9965f..4dda9ffa822c 100644 > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > @@ -150,73 +150,264 @@ properties: >in a different mode than the PHY in order to function. > >snps,axi-config: > +deprecated: true > $ref: /schemas/types.yaml#/definitions/phandle > description: > - AXI BUS Mode parameters. Phandle to a node that can contain the > - following properties > -* snps,lpi_en, enable Low Power Interface > -* snps,xit_frm, unlock on WoL > -* snps,wr_osr_lmt, max write outstanding req. limit > -* snps,rd_osr_lmt, max read outstanding req. limit > -* snps,kbbe, do not cross 1KiB boundary. > -* snps,blen, this is a vector of supported burst length. > -* snps,fb, fixed-burst > -* snps,mb, mixed-burst > -* snps,rb, rebuild INCRx Burst > + AXI BUS Mode parameters. Phandle to a node that contains the properties > + described in the 'axi-config' sub-node. > + > + axi-config: > +type: object > +description: AXI BUS Mode parameters > + > +properties: > + snps,lpi_en: > +$ref: /schemas/types.yaml#/definitions/flag > +description: Enable Low Power Interface > + > + snps,xit_frm: > +$ref: /schemas/types.yaml#/definitions/flag > +description: Unlock on WoL > + > + snps,wr_osr_lmt: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Max write outstanding req. limit > +default: 1 > +minimum: 0 > +maximum: 15 > + > + snps,rd_osr_lmt: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: Max read outstanding req. limit > +default: 1 > +minimum: 0 > +maximum: 15 > + > + snps,kbbe: > +$ref: /schemas/types.yaml#/definitions/flag > +description: Do not cross 1KiB boundary > + > + snps,blen: > +$ref: /schemas/types.yaml#/definitions/uint32-array > +description: A vector of supported burst lengths > +minItems: 7 > +maxItems: 7 > +items: > + enum: [256, 128, 64, 32, 16, 8, 4,
Re: [PATCH v2 03/24] dt-bindings: net: dwmac: Fix the TSO property declaration
On Mon, 08 Feb 2021 16:55:47 +0300, Serge Semin wrote: > Indeed the STMMAC driver doesn't take the vendor-specific compatible > string into account to parse the "snps,tso" boolean property. It just > makes sure the node is compatible with DW MAC 4.x, 5.x and DW xGMAC > IP-cores. The original allwinner sunXi bindings file also didn't have the > TSO-related property declared. Taking all of that into account fix the > conditional statement so the TSO-property would be evaluated for the > compatibles having the corresponding IP-core version. > > While at it move the whole allOf-block from the tail of the binding file > to the head of it, as it's normally done in the most of the DT schemas. > > Signed-off-by: Serge Semin > > --- > > Note this won't break the bindings description, since the "snps,tso" > property isn't parsed by the Allwinner SunX GMAC glue driver, but only > by the generic platform DT-parser. > > Changelog v2: > - Use correct syntax of the JSON pointers, so the later would begin > with a '/' after the '#'. > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 52 +-- > 1 file changed, 24 insertions(+), 28 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH RESEND] dt-bindings: ethernet-controller: fix fixed-link specification
On Mon, 01 Feb 2021 10:02:20 +, Russell King wrote:
> The original fixed-link.txt allowed a pause property for fixed link.
> This has been missed in the conversion to yaml format.
>
> Fixes: 9d3de3c58347 ("dt-bindings: net: Add YAML schemas for the generic
> Ethernet options")
> Signed-off-by: Russell King
> ---
>
> Resending now that kernel.org is fixed.
>
> .../devicetree/bindings/net/ethernet-controller.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
Applied, thanks!
Re: [PATCH net-next 1/8] dt-bindings: net: dsa: dt bindings for microchip lan937x
On Thu, Jan 28, 2021 at 12:11:05PM +0530, Prasanna Vengateshan wrote:
> Documentation in .yaml format and updates to the MAINTAINERS
> Also 'make dt_binding_check' is passed
>
> Signed-off-by: Prasanna Vengateshan
> ---
> .../bindings/net/dsa/microchip,lan937x.yaml | 115 ++
> MAINTAINERS | 1 +
> 2 files changed, 116 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
> b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
> new file mode 100644
> index ..8531ca603f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/microchip,lan937x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LAN937x Ethernet Switch Series Tree Bindings
> +
> +maintainers:
> + - woojung@microchip.com
> + - prasanna.vengates...@microchip.com
> +
> +allOf:
> + - $ref: dsa.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - microchip,lan9370
> + - microchip,lan9371
> + - microchip,lan9372
> + - microchip,lan9373
> + - microchip,lan9374
> +
> + reg:
> +maxItems: 1
> +
> + spi-max-frequency:
> +maximum: 5000
> +
> + reset-gpios:
> +description: Optional gpio specifier for a reset line
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +//Ethernet switch connected via spi to the host, CPU port wired to eth1
> +eth1 {
ethernet {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + fixed-link {
> +speed = <1000>;
> +full-duplex;
> + };
> +};
> +
> +spi1 {
spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-0 = <&pinctrl_spi_ksz>;
> + cs-gpios = <0>, <0>, <0>, <&pioC 28 0>;
> + id = <1>;
These 3 are relevant to the example, drop
> +
> + lan9374: switch@0 {
> +compatible = "microchip,lan9374";
> +reg = <0>;
> +
> +spi-max-frequency = <4400>;
> +
> +ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> +reg = <0>;
> +label = "lan1";
> + };
> + port@1 {
> +reg = <1>;
> +label = "lan2";
> + };
> + port@2 {
> +reg = <7>;
> +label = "lan3";
> + };
> + port@3 {
> +reg = <2>;
> +label = "lan4";
> + };
> + port@4 {
> +reg = <6>;
> +label = "lan5";
> + };
> + port@5 {
> +reg = <3>;
> +label = "lan6";
> + };
> + port@6 {
> +reg = <4>;
> +label = "cpu";
> +ethernet = <ð1>;
> +fixed-link {
> + speed = <1000>;
> + full-duplex;
> +};
> + };
> + port@7 {
> +reg = <5>;
> +label = "lan7";
> +fixed-link {
> + speed = <1000>;
> + full-duplex;
> +};
> + };
> +};
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 650deb973913..455670f37231 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11688,6 +11688,7 @@ M:unglinuxdri...@microchip.com
> L: netdev@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
> +F: Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
> F: drivers/net/dsa/microchip/*
> F: include/linux/platform_data/microchip-ksz.h
> F: net/dsa/tag_ksz.c
> --
> 2.25.1
>
Re: [PATCH net-next v2 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding
On Mon, 25 Jan 2021 12:43:21 +0800, DENG Qingfang wrote: > Add device tree binding to support MT7530 GPIO controller. > > Signed-off-by: DENG Qingfang > --- > Changes v1 -> v2: > No changes. > > Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 ++ > 1 file changed, 6 insertions(+) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH net-next 1/2] dt: ar803x: document SmartEEE properties
On Thu, 14 Jan 2021 10:45:44 +, Russell King wrote: > The SmartEEE feature of Atheros AR803x PHYs can cause the link to > bounce. Add DT properties to allow SmartEEE to be disabled, and to > allow the Tw parameters for 100M and 1G links to be configured. > > Signed-off-by: Russell King > --- > .../devicetree/bindings/net/qca,ar803x.yaml | 16 > 1 file changed, 16 insertions(+) > Reviewed-by: Rob Herring
Re: [RFC PATCH v3 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings
On Fri, Jan 15, 2021 at 02:53:32PM +0100, Steen Hegelund wrote: > Document the Sparx5 switch device driver bindings > > Signed-off-by: Steen Hegelund > Signed-off-by: Lars Povlsen > --- > .../bindings/net/microchip,sparx5-switch.yaml | 211 ++ > 1 file changed, 211 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml > > diff --git > a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml > b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml > new file mode 100644 > index ..479a36874fe5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml > @@ -0,0 +1,211 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Microchip Sparx5 Ethernet switch controller > + > +maintainers: > + - Lars Povlsen > + - Steen Hegelund > + > +description: | > + The SparX-5 Enterprise Ethernet switch family provides a rich set of > + Enterprise switching features such as advanced TCAM-based VLAN and > + QoS processing enabling delivery of differentiated services, and > + security through TCAM-based frame processing using versatile content > + aware processor (VCAP). > + > + IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported > + with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K > + IPv6 (S,G) multicast groups. > + > + L3 security features include source guard and reverse path > + forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and > + IP tunnels (IP over GRE/IP). > + > + The SparX-5 switch family targets managed Layer 2 and Layer 3 > + equipment in SMB, SME, and Enterprise where high port count > + 1G/2.5G/5G/10G switching with 10G/25G aggregation links is required. > + > +properties: > + $nodename: > +pattern: "^switch@[0-9a-f]+$" > + > + compatible: > +const: microchip,sparx5-switch > + > + reg: > +minItems: 2 > + > + reg-names: > +items: > + - const: devices > + - const: gcb > + > + interrupts: > +maxItems: 1 > +description: Interrupt used for reception of packets to the CPU > + > + mac-address: > +maxItems: 1 The MAC address is 1 byte? > +description: > + Specifies the MAC address that is used as the template for the MAC > + addresses assigned to the ports provided by the driver. If not > provided > + a randomly generated MAC address will be used. > + > + ethernet-ports: > +type: object > +properties: > + '#address-cells': > +const: 1 > + '#size-cells': > +const: 0 > + > +patternProperties: > + "^port@[0-9]+$": Unit-addresses are hex. > +type: object > +description: Switch ports > + > +allOf: > + - $ref: ethernet-controller.yaml# > + > +properties: > + reg: > +description: Switch port number > + > + bandwidth: Needs a vendor prefix. > +maxItems: 1 Not an array. Drop. > +$ref: /schemas/types.yaml#definitions/uint32 > +description: Specifies bandwidth in Mbit/s allocated to the port. 0-2^32 allowed? > + > + phys: > +maxItems: 1 > +description: > + phandle of a Ethernet SerDes PHY. This defines which SerDes > + instance will handle the Ethernet traffic. > + > + phy-handle: > +maxItems: 1 Always a single item. (Note phys is not, so that's correct.) > +description: > + phandle of a Ethernet PHY. This is optional and if provided > it > + points to the cuPHY used by the Ethernet SerDes. > + > + phy-mode: > +maxItems: 1 Not an array. Drop. I'd assume it's some subset of modes? > +description: > + This specifies the interface used by the Ethernet SerDes > towards the > + phy or SFP. > + > + sfp: > +maxItems: 1 'sfp' is already defined as a single item. Drop > +description: > + phandle of an SFP. This is optional and used when not > specifying > + a cuPHY. It points to the SFP node that describes the SFP > used by > + the Ethernet SerDes. > + > + managed: > +maxItems: 1 > +description: > + SFP management. This must be provided when specifying an SFP. 'managed: true' is sufficient. It's already described in ethernet-controller.yaml and the schema expresses the 2nd sentence. > + > + sd_sgpio: Vendor specific? Then needs a vendor prefix. s/_/-/ > +$ref: /schemas/types.yaml#/definitions/uint32 > +maxItems: 1 A uint32 is always 1 item. Drop. > +description: > + I
Re: [RFC PATCH v3 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings
On Fri, 15 Jan 2021 14:53:32 +0100, Steen Hegelund wrote: > Document the Sparx5 switch device driver bindings > > Signed-off-by: Steen Hegelund > Signed-off-by: Lars Povlsen > --- > .../bindings/net/microchip,sparx5-switch.yaml | 211 ++ > 1 file changed, 211 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml:92:16: [warning] wrong indentation: expected 14 but found 15 (indentation) dtschema/dtc warnings/errors: See https://patchwork.ozlabs.org/patch/1427023 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH net-next 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding
On Mon, 11 Jan 2021 13:44:27 +0800, DENG Qingfang wrote: > Add device tree binding to support MT7530 GPIO controller. > > Signed-off-by: DENG Qingfang > --- > Documentation/devicetree/bindings/net/dsa/mt7530.txt | 6 ++ > 1 file changed, 6 insertions(+) > Acked-by: Rob Herring
Re: [PATCH net-next 2/4] dt-bindings: net: remove modem-remoteproc property
On Tue, Jan 12, 2021 at 01:28:29PM -0600, Alex Elder wrote: > The IPA driver uses the remoteproc SSR notifier now, rather than the > temporary IPA notification system used initially. As a result it no > longer needs a property identifying the modem subsystem DT node. > > Use GIC_SPI rather than 0 in the example interrupt definition. > > Signed-off-by: Alex Elder > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 13 ++--- > 1 file changed, 2 insertions(+), 11 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > index 8a2d12644675b..a8cff214ee11f 100644 > --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml > +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml > @@ -113,13 +113,6 @@ properties: >performing early IPA initialization, including loading and >validating firwmare used by the GSI. > > - modem-remoteproc: > -$ref: /schemas/types.yaml#/definitions/phandle > -description: > - This defines the phandle to the remoteproc node representing > - the modem subsystem. This is requied so the IPA driver can > - receive and act on notifications of modem up/down events. > - >memory-region: > maxItems: 1 > description: > @@ -135,7 +128,6 @@ required: >- interrupts >- interconnects >- qcom,smem-states > - - modem-remoteproc > > oneOf: >- required: > @@ -168,7 +160,6 @@ examples: > compatible = "qcom,sdm845-ipa"; > > modem-init; > -modem-remoteproc = <&mss_pil>; > > iommus = <&apps_smmu 0x720 0x3>; > reg = <0x1e4 0x7000>, > @@ -178,8 +169,8 @@ examples: > "ipa-shared", > "gsi"; > > -interrupts-extended = <&intc 0 311 IRQ_TYPE_EDGE_RISING>, > - <&intc 0 432 IRQ_TYPE_LEVEL_HIGH>, > +interrupts-extended = <&intc GIC_SPI 311 > IRQ_TYPE_EDGE_RISING>, > + <&intc GIC_SPI 432 > IRQ_TYPE_LEVEL_HIGH>, You need the include file. ><&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, ><&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>; > interrupt-names = "ipa", > -- > 2.20.1 >
Re: [PATCH net-next 2/4] dt-bindings: net: remove modem-remoteproc property
On Tue, 12 Jan 2021 13:28:29 -0600, Alex Elder wrote: > The IPA driver uses the remoteproc SSR notifier now, rather than the > temporary IPA notification system used initially. As a result it no > longer needs a property identifying the modem subsystem DT node. > > Use GIC_SPI rather than 0 in the example interrupt definition. > > Signed-off-by: Alex Elder > --- > Documentation/devicetree/bindings/net/qcom,ipa.yaml | 13 ++--- > 1 file changed, 2 insertions(+), 11 deletions(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/net/qcom,ipa.example.dts:49.46-47 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [scripts/Makefile.lib:344: Documentation/devicetree/bindings/net/qcom,ipa.example.dt.yaml] Error 1 make: *** [Makefile:1370: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1425462 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH 1/2] dt-bindings: net: bluetooth: Add rtl8723ds-bluetooth
On Sat, 02 Jan 2021 22:38:03 +0100, John-Eric Kamps wrote: > Add binding documentation for bluetooth part of RTL8723DS > > Signed-off-by: John-Eric Kamps > --- > Documentation/devicetree/bindings/net/realtek-bluetooth.yaml | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH 1/4] dt-bindings: net: renesas,etheravb: Add additional clocks
On Mon, 28 Dec 2020 15:31:17 -0600, Adam Ford wrote: > The AVB driver assumes there is an external clock, but it could > be driven by an external clock. In order to enable a programmable > clock, it needs to be added to the clocks list and enabled in the > driver. Since there currently only one clock, there is no > clock-names list either. > > Update bindings to add the additional optional clock, and explicitly > name both of them. > > Signed-off-by: Adam Ford > --- > .../devicetree/bindings/net/renesas,etheravb.yaml | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH 1/5] dt-bindings: net: renesas,etheravb: Add r8a779a0 support
On Sun, 27 Dec 2020 14:04:02 +0100, Wolfram Sang wrote: > Document the compatible value for the RAVB block in the Renesas R-Car > V3U (R8A779A0) SoC. This variant has no stream buffer, so we only need > to add the new compatible. > > Signed-off-by: Wolfram Sang > --- > Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v5 10/11] dt-bindings: usb: convert mediatek, mtu3.txt to YAML schema
On Fri, 25 Dec 2020 15:52:57 +0800, Chunfeng Yun wrote: > Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml > > Signed-off-by: Chunfeng Yun > --- > v5: changes suggested by Rob > 1. remove unnecessary maxItems > 2. define all phys supported > > v4: > 1. refer to usb-drd.yaml insstead of usb/generic.txt > the following ones suggested by Rob: > 2. add the number of phys supported > 3. fix indentation of wakeup > 4. add examples for port and connector > > v3: > 1. fix yamllint warning > 2. remove pinctrl* properties > 3. remove unnecessary '|' > 4. drop unused labels in example > > v2: new patch > --- > .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 --- > .../bindings/usb/mediatek,mtu3.yaml | 287 ++ > 2 files changed, 287 insertions(+), 108 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > Reviewed-by: Rob Herring
Re: [PATCH v5 09/11] dt-bindings: usb: convert mediatek, mtk-xhci.txt to YAML schema
On Fri, 25 Dec 2020 15:52:56 +0800, Chunfeng Yun wrote: > Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml > > Signed-off-by: Chunfeng Yun > --- > v5: changes suggested by Rob > 1. refer to usb-xhci.yaml instead of usb-hcd.yaml > 2. remove unnecessary maxItems > 3. add items for all phys may be supported > 4. change pattern, and limit pattern length of patternProperties > > v4: update it according to Rob's suggestion > 1. modify dictionary of phys > 2. fix endentation in "mediatek,syscon-wakeup" items > 3. remove reference to usb-hcd.yaml > > v3: > 1. fix yamllint warning > 2. remove pinctrl* properties supported by default suggested by Rob > 3. drop unused labels > 4. modify description of mediatek,syscon-wakeup > 5. remove type of imod-interval-ns > > v2: new patch > --- > .../bindings/usb/mediatek,mtk-xhci.txt| 121 > .../bindings/usb/mediatek,mtk-xhci.yaml | 178 ++ > 2 files changed, 178 insertions(+), 121 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > create mode 100644 > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > Reviewed-by: Rob Herring
Re: [PATCH v5 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
On Fri, 25 Dec 2020 15:52:48 +0800, Chunfeng Yun wrote: > Convert usb-device.txt to YAML schema usb-device.yaml > > Signed-off-by: Chunfeng Yun > --- > v5: changes suggested by Rob: > 1. limit the pattern length > 2. remove properties description for hard wired USB devices in usb-hcd.yaml > > depends on series: > https://patchwork.kernel.org/project/linux-usb/list/?series=399561 > [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema > > v4: no changes, update dependent series: > https://patchwork.kernel.org/project/linux-usb/list/?series=399561 > [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema > > v3: > 1. remove $nodenmae and items key word for compatilbe; > 2. add additionalProperties; > > The followings are suggested by Rob: > 3. merge the following patch > [v2,1/4] dt-bindings: usb: convert usb-device.txt to YAML schema > [v2,2/4] dt-bindings: usb: add properties for hard wired devices > 4. define the unit-address for hard-wired device in usb-hcd.yaml, > also define its 'reg' and 'compatible'; > 5. This series is base on Serge's series: > > https://patchwork.kernel.org/project/linux-usb/cover/2020090853.14112-1-sergey.se...@baikalelectronics.ru/ > [v4,00/18] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema > > v2 changes suggested by Rob: > 1. modify pattern to support any USB class > 2. convert usb-device.txt into usb-device.yaml > --- > .../devicetree/bindings/usb/usb-device.txt| 102 -- > .../devicetree/bindings/usb/usb-device.yaml | 124 ++ > .../devicetree/bindings/usb/usb-hcd.yaml | 19 +++ > 3 files changed, 143 insertions(+), 102 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt > create mode 100644 Documentation/devicetree/bindings/usb/usb-device.yaml > Reviewed-by: Rob Herring
Re: [PATCH v4 02/24] dt-bindings: introduce silabs,wfx.yaml
On Wed, Dec 23, 2020 at 04:39:03PM +0100, Jerome Pouiller wrote:
> From: Jérôme Pouiller
Commit message?
checkpatch.pl reports trailing whitespace errors.
>
> Signed-off-by: Jérôme Pouiller
> ---
> .../bindings/net/wireless/silabs,wfx.yaml | 133 ++
> 1 file changed, 133 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
> b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
> new file mode 100644
> index ..487d46c5fdc0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020, Silicon Laboratories, Inc.
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/net/wireless/silabs,wfx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Silicon Labs WFxxx devicetree bindings
> +
> +maintainers:
> + - Jérôme Pouiller
> +
> +description: >
> + Support for the Wifi chip WFxxx from Silicon Labs. Currently, the only
> device
> + from the WFxxx series is the WF200 described here:
> + https://www.silabs.com/documents/public/data-sheets/wf200-datasheet.pdf
> +
> + The WF200 can be connected via SPI or via SDIO.
> +
> + For SDIO:
> +
> +Declaring the WFxxx chip in device tree is mandatory (usually, the
> VID/PID is
> +sufficient for the SDIO devices).
> +
> +It is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without
> +it, you may encounter issues during reboot. The mmc-pwrseq should be
> +compatible with mmc-pwrseq-simple. Please consult
> +Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt for more
> +information.
> +
> + For SPI:
> +
> +In add of the properties below, please consult
> +Documentation/devicetree/bindings/spi/spi-controller.yaml for optional
> SPI
> +related properties.
> +
> +properties:
> + compatible:
> +const: silabs,wf200
> +
> + reg:
> +description:
> + When used on SDIO bus, must be set to 1. When used on SPI bus,
> it is
> + the chip select address of the device as defined in the SPI devices
> + bindings.
> +maxItems: 1
> +
> + spi-max-frequency: true
> +
> + interrupts:
> +description: The interrupt line. Triggers IRQ_TYPE_LEVEL_HIGH and
> + IRQ_TYPE_EDGE_RISING are both supported by the chip and the driver.
> When
> + SPI is used, this property is required. When SDIO is used, the
> "in-band"
> + interrupt provided by the SDIO bus is used unless an interrupt is
> defined
> + in the Device Tree.
> +maxItems: 1
> +
> + reset-gpios:
> +description: (SPI only) Phandle of gpio that will be used to reset chip
> + during probe. Without this property, you may encounter issues with warm
> + boot. (For legacy purpose, the gpio in inverted when compatible ==
> + "silabs,wfx-spi")
> +
> + For SDIO, the reset gpio should declared using a mmc-pwrseq.
> +maxItems: 1
> +
> + wakeup-gpios:
> +description: Phandle of gpio that will be used to wake-up chip. Without
> this
> + property, driver will disable most of power saving features.
> +maxItems: 1
> +
> + silabs,antenna-config-file:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: Use an alternative file for antenna configuration (aka
> + "Platform Data Set" in Silabs jargon). Default is 'wf200.pds'.
> +
> + local-mac-address: true
> +
> + mac-address: true
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +wifi@0 {
> +compatible = "silabs,wf200";
> +pinctrl-names = "default";
> +pinctrl-0 = <&wfx_irq &wfx_gpios>;
> +reg = <0>;
> +interrupts-extended = <&gpio 16 IRQ_TYPE_EDGE_RISING>;
> +wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> +spi-max-frequency = <4200>;
> +};
> +};
> +
> + - |
> +#include
> +#include
> +
> +wfx_pwrseq: wfx_pwrseq {
> +compatible = "mmc-pwrseq-simple";
> +pinctrl-names = "default";
> +pinctrl-0 = <&wfx_reset>;
> +reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> +};
> +
> +mmc0 {
> +mmc-pwrseq = <&wfx_pwrseq>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +wifi@1 {
> +compatible = "silabs,wf200";
> +pinctrl-names = "default";
> +pinctrl-0 = <&wfx_wakeup>;
> +reg = <1>;
> +wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +...
> --
> 2.29.2
>
Re: [PATCH] dt-bindings: Add missing array size constraints
On Tue, Jan 05, 2021 at 02:04:14PM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote: > > DT properties which can have multiple entries need to specify what the > > entries are and define how many entries there can be. In the case of > > only a single entry, just 'maxItems: 1' is sufficient. > > > > Add the missing entry constraints. These were found with a modified > > meta-schema. Unfortunately, there are a few cases where the size > > constraints are not defined such as common bindings, so the meta-schema > > can't be part of the normal checks. > > > > Cc: Jens Axboe > > Cc: Stephen Boyd > > Cc: Thierry Reding > > Cc: MyungJoo Ham > > Cc: Chanwoo Choi > > Cc: Linus Walleij > > Cc: Bartosz Golaszewski > > Cc: Jonathan Cameron > > Cc: Dmitry Torokhov > > Cc: Thomas Gleixner > > Cc: Marc Zyngier > > Cc: Mauro Carvalho Chehab > > Cc: Chen-Yu Tsai > > Cc: Ulf Hansson > > Cc: "David S. Miller" > > Cc: Jakub Kicinski > > Cc: Sebastian Reichel > > Cc: Ohad Ben-Cohen > > Cc: Bjorn Andersson > > Cc: Greg Kroah-Hartman > > Signed-off-by: Rob Herring > > > > > diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > index 247ef00381ea..f76b25f7fc7a 100644 > > --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > @@ -83,6 +83,7 @@ properties: > >Phandle of a companion. > > > >phys: > > +maxItems: 1 > > description: PHY specifier for the USB PHY > > > >phy-names: > > diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > index 2178bcc401bc..8e2bd61f2075 100644 > > --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > @@ -71,6 +71,7 @@ properties: > >Overrides the detected port count > > > >phys: > > +maxItems: 1 > > description: PHY specifier for the USB PHY > > > >phy-names: > > diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > index 678396eeeb78..f506225a4d57 100644 > > --- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > +++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > @@ -40,7 +40,7 @@ properties: > >- const: mc > > > >phys: > > -description: PHY specifier for the USB PHY > > +maxItems: 1 > > > >usb-role-switch: > > type: boolean > > Any reason you dropped the description for this entry, but not the other > ones above? No, I should have dropped those too. I dropped cases of genericish descriptions on common properties. There's nothing specific to this binding here really. > > > diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > index 388245b91a55..adce36e48bc9 100644 > > --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > @@ -15,13 +15,14 @@ properties: > >- const: ti,j721e-usb > > > >reg: > > -description: module registers > > +maxItems: 1 > > > >power-domains: > > description: > >PM domain provider node and an args specifier containing > >the USB device id value. See, > >Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt > > +maxItems: 1 > > > >clocks: > > description: Clock phandles to usb2_refclk and lpm_clk > > Same here, why remove the description? Really, the question is why keep 'description' on power-domains. Perhaps there's a little value in the reference to sci-pm-domain.txt, so I left it. Rob
[PATCH] dt-bindings: Add missing array size constraints
DT properties which can have multiple entries need to specify what the entries are and define how many entries there can be. In the case of only a single entry, just 'maxItems: 1' is sufficient. Add the missing entry constraints. These were found with a modified meta-schema. Unfortunately, there are a few cases where the size constraints are not defined such as common bindings, so the meta-schema can't be part of the normal checks. Cc: Jens Axboe Cc: Stephen Boyd Cc: Thierry Reding Cc: MyungJoo Ham Cc: Chanwoo Choi Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: Jonathan Cameron Cc: Dmitry Torokhov Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Mauro Carvalho Chehab Cc: Chen-Yu Tsai Cc: Ulf Hansson Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Sebastian Reichel Cc: Ohad Ben-Cohen Cc: Bjorn Andersson Cc: Greg Kroah-Hartman Signed-off-by: Rob Herring --- Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-g...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-remotep...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-ser...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org --- .../socionext,uniphier-system-cache.yaml | 4 ++-- .../bindings/ata/sata_highbank.yaml | 1 + .../bindings/clock/canaan,k210-clk.yaml | 1 + .../bindings/display/brcm,bcm2711-hdmi.yaml | 1 + .../bindings/display/brcm,bcm2835-hdmi.yaml | 1 + .../display/panel/jdi,lt070me05000.yaml | 1 + .../display/panel/mantix,mlaf057we51-x.yaml | 3 ++- .../display/panel/novatek,nt36672a.yaml | 1 + .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 +- .../devicetree/bindings/eeprom/at25.yaml | 3 +-- .../bindings/extcon/extcon-ptn5150.yaml | 2 ++ .../bindings/gpio/gpio-pca95xx.yaml | 1 + .../bindings/iio/adc/adi,ad7768-1.yaml| 2 ++ .../bindings/iio/adc/aspeed,ast2400-adc.yaml | 1 + .../bindings/iio/adc/lltc,ltc2496.yaml| 2 +- .../bindings/iio/adc/qcom,spmi-vadc.yaml | 1 + .../bindings/iio/adc/st,stm32-adc.yaml| 2 ++ .../iio/magnetometer/asahi-kasei,ak8975.yaml | 1 + .../iio/potentiometer/adi,ad5272.yaml | 1 + .../input/touchscreen/elan,elants_i2c.yaml| 1 + .../interrupt-controller/fsl,intmux.yaml | 2 +- .../interrupt-controller/st,stm32-exti.yaml | 2 ++ .../allwinner,sun4i-a10-video-engine.yaml | 1 + .../devicetree/bindings/media/i2c/imx219.yaml | 1 + .../memory-controllers/exynos-srom.yaml | 2 ++ .../bindings/misc/fsl,dpaa2-console.yaml | 1 + .../bindings/mmc/mmc-controller.yaml | 2 ++ .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 1 + .../bindings/net/ti,k3-am654-cpts.yaml| 1 + .../phy/allwinner,sun4i-a10-usb-phy.yaml | 2 ++ .../phy/allwinner,sun50i-a64-usb-phy.yaml | 2 ++ .../phy/allwinner,sun50i-h6-usb-phy.yaml | 2 ++ .../phy/allwinner,sun5i-a13-usb-phy.yaml | 2 ++ .../phy/allwinner,sun6i-a31-usb-phy.yaml | 2 ++ .../phy/allwinner,sun8i-a23-usb-phy.yaml | 2 ++ .../phy/allwinner,sun8i-a83t-usb-phy.yaml | 2 ++ .../phy/allwinner,sun8i-h3-usb-phy.yaml | 2 ++ .../phy/allwinner,sun8i-r40-usb-phy.yaml | 2 ++ .../phy/allwinner,sun8i-v3s-usb-phy.yaml | 2 ++ .../phy/allwinner,sun9i-a80-usb-phy.yaml | 19 --- .../phy/socionext,uniphier-ahci-phy.yaml | 2 +- .../phy/socionext,uniphier-pcie-phy.yaml | 2 +- .../phy/socionext,uniphier-usb3hs-phy.yaml| 2 +- .../phy/socionext,uniphier-usb3ss-phy.yaml| 2 +- .../bindings/phy/ti,phy-gmii-sel.yaml | 2 +- .../pinctrl/aspeed,ast2400-pinctrl.yaml | 3 +-- .../pinctrl/aspeed,ast2500-pinctrl.yaml | 4 ++-- .../bindings/power/supply/bq25980.yaml| 1 + .../bindings/remoteproc/ingenic,vpu.yaml | 2 +- .../remoteproc/ti,omap-remoteproc.yaml| 3 +++ .../bindings/riscv/sifive-l2-cache.yaml | 1 + .../bindings/serial/renesas,hscif.yaml| 2 ++ .../bindings/serial/renesas,scif.yaml | 2 ++ .../bindings/serial/renesas,scifa.yaml| 2 ++ .../bindings/serial/renesas,scifb.yaml| 2 ++ .../sound/allwinner,sun4i-a10-codec.yaml | 1 + .../bindings/sound/google,sc7180-trogdor.yaml | 1 + .../bindings/sound/samsung,aries-wm8994.yaml | 3 +++ .../bindings/sound/samsung,midas-audio.yaml | 2 ++ .../devicetree/bindings/sound/tas2562.yaml| 2 ++ .../devicetree/bindings/sound/tas2770.yaml| 2 ++ .../bindings/sound/tlv320adcx140.yaml | 1 + .../devicetree/bindings/spi/renesas,rspi.yaml | 2 ++ .../devicetree/bindings/sram/sram.yaml| 2 ++ .../timer/allwi
Re: [PATCH 2/4] dt-bindings: net: Add bindings for Qualcomm QCA807x
On Wed, Dec 23, 2020 at 01:56:33AM +0100, Andrew Lunn wrote: > > + gpio-controller: true > > + "#gpio-cells": > > +const: 2 > > + > > + qcom,single-led-1000: > > +description: | > > + If present, then dedicated 1000 Mbit will light up for 1000Base-T. > > + This is a workround for boards with a single LED instead of two. > > +type: boolean > > + > > + qcom,single-led-100: > > +description: | > > + If present, then dedicated 1000 Mbit will light up for 100Base-TX. > > + This is a workround for boards with a single LED instead of two. > > +type: boolean > > + > > + qcom,single-led-10: > > +description: | > > + If present, then dedicated 1000 Mbit will light up for 10Base-Te. > > + This is a workround for boards with a single LED instead of two. > > +type: boolean > > Sorry, but no. Please look at the work being done for allow PHY LEDs > to be controlled via the LED subsystem. > > > + qcom,tx-driver-strength: > > +description: PSGMII/QSGMII TX driver strength control. > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] > > Please use the actual values here, and have the driver convert to the > value poked into the register. So the property would be > qcom,tx-driver-strength-mv and it would have the value 220 for > example. The LED binding has properties for specifying the current already. And it's max current which is the h/w property where as anything less is just software configuration (IOW, doesn't belong in DT).
[PATCH] dt-bindings: net: qcom,ipa: Drop unnecessary type ref on 'memory-region'
'memory-region' is a common property, so it doesn't need a type ref here. Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Alex Elder Cc: netdev@vger.kernel.org Signed-off-by: Rob Herring --- I'll take this via the DT tree. Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index d0cbbcf1b0e5..8a2d12644675 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -121,7 +121,6 @@ properties: receive and act on notifications of modem up/down events. memory-region: -$ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: If present, a phandle for a reserved memory area that holds -- 2.27.0
Re: [RFC PATCH v2 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings
On Thu, Dec 17, 2020 at 08:51:27AM +0100, Steen Hegelund wrote:
> Document the Sparx5 switch device driver bindings
>
> Signed-off-by: Steen Hegelund
> Signed-off-by: Lars Povlsen
> ---
> .../bindings/net/microchip,sparx5-switch.yaml | 178 ++
> 1 file changed, 178 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
> b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
> new file mode 100644
> index ..6e3ef8285e9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
> @@ -0,0 +1,178 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip Sparx5 Ethernet switch controller
> +
> +maintainers:
> + - Lars Povlsen
> + - Steen Hegelund
> +
> +description: |
> + The SparX-5 Enterprise Ethernet switch family provides a rich set of
> + Enterprise switching features such as advanced TCAM-based VLAN and
> + QoS processing enabling delivery of differentiated services, and
> + security through TCAM-based frame processing using versatile content
> + aware processor (VCAP).
> +
> + IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported
> + with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K
> + IPv6 (S,G) multicast groups.
> +
> + L3 security features include source guard and reverse path
> + forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and
> + IP tunnels (IP over GRE/IP).
> +
> + The SparX-5 switch family targets managed Layer 2 and Layer 3
> + equipment in SMB, SME, and Enterprise where high port count
> + 1G/2.5G/5G/10G switching with 10G/25G aggregation links is required.
> +
> +properties:
> + $nodename:
> +pattern: "^switch@[0-9a-f]+$"
> +
> + compatible:
> +const: microchip,sparx5-switch
> +
> + reg:
> +minItems: 2
> +
> + reg-names:
> +minItems: 2
This is the default based on 'items' length.
> +items:
> + - const: devices
> + - const: gcb
> +
> + interrupts:
> +maxItems: 1
> +description: Interrupt used for reception of packets to the CPU
> +
> + ethernet-ports:
> +type: object
> +properties:
> + '#address-cells':
> +const: 1
> + '#size-cells':
> +const: 0
> +
> +patternProperties:
> + "^port@[0-9]+$":
> +type: object
> +description: Switch ports
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + reg:
> +description: Switch port number
> +
> + max-speed:
> +maxItems: 1
Is that an array?
> +description: Bandwidth allocated to this port
> +
> + phys:
How many? (maxItems)
> +description: phandle of a Ethernet Serdes PHY
> +
> + phy-handle:
> +description: phandle of a Ethernet PHY
> +
> + phy-mode:
> +description: Interface between the serdes and the phy
The whole set of modes defined is supported?
> +
> + sfp:
> +description: phandle of an SFP
> +
> + managed:
> +maxItems: 1
An array?
> +description: SFP management
> +
> +required:
> + - reg
> + - max-speed
> + - phys
> +
> +oneOf:
> + - required:
> + - phy-handle
> + - phy-mode
> + - required:
> + - sfp
> + - managed
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - ethernet-ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +switch: switch@6 {
> + compatible = "microchip,sparx5-switch";
> + reg = <0x1000 0x80>,
> + <0x1101 0x1b0>;
> + reg-names = "devices", "gcb";
> +
> + interrupts = ;
> + ethernet-ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port0: port@0 {
> + reg = <0>;
> + max-speed = <1000>;
> + phys = <&serdes 13>;
> + phy-handle = <&phy0>;
> + phy-mode = "qsgmii";
> +};
> +/* ... */
> +/* Then the 25G interfaces */
> +port60: port@60 {
> + reg = <60>;
> + max-speed = <25000>;
> + phys = <&serdes 29>;
> + sfp = <&sfp_eth60>;
> + managed = "in-band-status";
> +};
> +port61: port@61 {
> + reg = <61>;
> + max-speed = <25000>;
> + phys = <&serdes 30>;
> + sfp = <&sfp_eth61>;
> + managed = "in-band-status";
> +};
> +port62: port@62 {
> +
Re: [PATCH v4 10/11] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
On Wed, Dec 16, 2020 at 05:30:11PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v4:
> 1. refer to usb-drd.yaml insstead of usb/generic.txt
> the following ones suggested by Rob:
> 2. add the number of phys supported
> 3. fix indentation of wakeup
> 4. add examples for port and connector
>
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties
> 3. remove unnecessary '|'
> 4. drop unused labels in example
>
> v2: new patch
> ---
> .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 ---
> .../bindings/usb/mediatek,mtu3.yaml | 278 ++
> 2 files changed, 278 insertions(+), 108 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> deleted file mode 100644
> index a82ca438aec1..
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> +++ /dev/null
> @@ -1,108 +0,0 @@
> -The device node for Mediatek USB3.0 DRD controller
> -
> -Required properties:
> - - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc,
> - when using "mediatek,mtu3" compatible string, you need SoC specific
> - ones in addition, one of:
> - - "mediatek,mt8173-mtu3"
> - - reg : specifies physical base address and size of the registers
> - - reg-names: should be "mac" for device IP and "ippc" for IP port control
> - - interrupts : interrupt used by the device IP
> - - power-domains : a phandle to USB power domain node to control USB's
> - mtcmos
> - - vusb33-supply : regulator of USB avdd3.3v
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller,
> - the following clocks are optional:
> - "ref_ck", "mcu_ck" and "dma_ck";
> - - phys : see usb-hcd.yaml in the current directory
> - - dr_mode : should be one of "host", "peripheral" or "otg",
> - refer to usb/generic.txt
> -
> -Optional properties:
> - - #address-cells, #size-cells : should be '2' if the device has sub-nodes
> - with 'reg' property
> - - ranges : allows valid 1:1 translation between child's address space and
> - parent's address space
> - - extcon : external connector for vbus and idpin changes detection, needed
> - when supports dual-role mode.
> - it's considered valid for compatibility reasons, not allowed for
> - new bindings, and use "usb-role-switch" property instead.
> - - vbus-supply : reference to the VBUS regulator, needed when supports
> - dual-role mode.
> - it's considered valid for compatibility reasons, not allowed for
> - new bindings, and put into a usb-connector node.
> - see connector/usb-connector.yaml.
> - - pinctrl-names : a pinctrl state named "default" is optional, and need be
> - defined if auto drd switch is enabled, that means the property dr_mode
> - is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
> - is not set.
> - - pinctrl-0 : pin control group
> - See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> -
> - - maximum-speed : valid arguments are "super-speed", "high-speed" and
> - "full-speed"; refer to usb/generic.txt
> - - usb-role-switch : use USB Role Switch to support dual-role switch, but
> - not extcon; see usb/generic.txt.
> - - enable-manual-drd : supports manual dual-role switch via debugfs; usually
> - used when receptacle is TYPE-A and also wants to support dual-role
> - mode.
> - - wakeup-source: enable USB remote wakeup of host mode.
> - - mediatek,syscon-wakeup : phandle to syscon used to access the register
> - of the USB wakeup glue layer between SSUSB and SPM; it depends on
> - "wakeup-source", and has two arguments:
> - - the first one : register base address of the glue layer in syscon;
> - - the second one : hardware version of the glue layer
> - - 1 : used by mt8173 etc
> - - 2 : used by mt2712 etc
> - - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> - bit1 for u3port1, ... etc;
> -
> -additionally the properties from usb-hcd.yaml (in the current directory) are
> -supported.
> -
> -Sub-nodes:
> -The xhci should be added as subnode to mtu3 as shown in the following example
> -if host mode is enabled. The DT binding details of xhci can be found in:
> -Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> -
> -The port would be added as subnode if use "usb-role-switch" property.
> - see graph.txt
> -
> -Example:
> -ssusb: usb@11271000 {
> - compatible = "mediatek,mt8173-mtu3";
> - reg = <0 0x11271000 0 0x3000>,
> -
Re: [PATCH v4 09/11] dt-bindings: usb: convert mediatek,mtk-xhci.txt to YAML schema
On Wed, Dec 16, 2020 at 05:30:10PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v4: update it according to Rob's suggestion
> 1. modify dictionary of phys
> 2. fix endentation in "mediatek,syscon-wakeup" items
> 3. remove reference to usb-hcd.yaml
>
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties supported by default suggested by Rob
> 3. drop unused labels
> 4. modify description of mediatek,syscon-wakeup
> 5. remove type of imod-interval-ns
>
> v2: new patch
> ---
> .../bindings/usb/mediatek,mtk-xhci.txt| 121 -
> .../bindings/usb/mediatek,mtk-xhci.yaml | 171 ++
> 2 files changed, 171 insertions(+), 121 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> create mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> deleted file mode 100644
> index 42d8814f903a..
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> +++ /dev/null
> @@ -1,121 +0,0 @@
> -MT8173 xHCI
> -
> -The device node for Mediatek SOC USB3.0 host controller
> -
> -There are two scenarios: the first one only supports xHCI driver;
> -the second one supports dual-role mode, and the host is based on xHCI
> -driver. Take account of backward compatibility, we divide bindings
> -into two parts.
> -
> -1st: only supports xHCI driver
> -
> -
> -Required properties:
> - - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
> - "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
> - addition, one of:
> - - "mediatek,mt8173-xhci"
> - - reg : specifies physical base address and size of the registers
> - - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
> - - interrupts : interrupt used by the controller
> - - power-domains : a phandle to USB power domain node to control USB's
> - mtcmos
> - - vusb33-supply : regulator of USB avdd3.3v
> -
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain
> - "sys_ck": controller clock used by normal mode,
> - the following ones are optional:
> - "ref_ck": reference clock used by low power mode etc,
> - "mcu_ck": mcu_bus clock for register access,
> - "dma_ck": dma_bus clock for data transfer by DMA,
> - "xhci_ck": controller clock
> -
> - - phys : see usb-hcd.yaml in the current directory
> -
> -Optional properties:
> - - wakeup-source : enable USB remote wakeup;
> - - mediatek,syscon-wakeup : phandle to syscon used to access the register
> - of the USB wakeup glue layer between xHCI and SPM; it depends on
> - "wakeup-source", and has two arguments:
> - - the first one : register base address of the glue layer in syscon;
> - - the second one : hardware version of the glue layer
> - - 1 : used by mt8173 etc
> - - 2 : used by mt2712 etc
> - - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> - bit1 for u3port1, ... etc;
> - - vbus-supply : reference to the VBUS regulator;
> - - usb3-lpm-capable : supports USB3.0 LPM
> - - pinctrl-names : a pinctrl state named "default" must be defined
> - - pinctrl-0 : pin control group
> - See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> - - imod-interval-ns: default interrupt moderation interval is 5000ns
> -
> -additionally the properties from usb-hcd.yaml (in the current directory) are
> -supported.
> -
> -Example:
> -usb30: usb@1127 {
> - compatible = "mediatek,mt8173-xhci";
> - reg = <0 0x1127 0 0x1000>,
> - <0 0x11280700 0 0x0100>;
> - reg-names = "mac", "ippc";
> - interrupts = ;
> - power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
> - <&pericfg CLK_PERI_USB0>,
> - <&pericfg CLK_PERI_USB1>;
> - clock-names = "sys_ck", "ref_ck";
> - phys = <&phy_port0 PHY_TYPE_USB3>,
> -<&phy_port1 PHY_TYPE_USB2>;
> - vusb33-supply = <&mt6397_vusb_reg>;
> - vbus-supply = <&usb_p1_vbus>;
> - usb3-lpm-capable;
> - mediatek,syscon-wakeup = <&pericfg 0x400 1>;
> - wakeup-source;
> - imod-interval-ns = <1>;
> -};
> -
> -2nd: dual-role mode with xHCI driver
> -
> -
> -In the case, xhci is added as subnode to mtu3. An example and the DT binding
> -details of mtu3 can be found in:
> -Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> -
> -Required
Re: [PATCH v4 07/11] dt-bindings: phy: convert MIPI DSI PHY binding to YAML schema
On Wed, 16 Dec 2020 17:30:08 +0800, Chunfeng Yun wrote: > Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml > > Cc: Chun-Kuang Hu > Cc: Philipp Zabel > Signed-off-by: Chunfeng Yun > --- > v4: > 1. add maintainer Philipp add support mt8183 suggested by Chun-Kuang > 2. use keyword multipleOf suggested by Rob > 3. fix typo of 'MIPI' in title > > v3: new patch > --- > .../display/mediatek/mediatek,dsi.txt | 18 +--- > .../bindings/phy/mediatek,dsi-phy.yaml| 85 +++ > 2 files changed, 86 insertions(+), 17 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml > Reviewed-by: Rob Herring
Re: [PATCH v4 02/11] dt-bindings: net: btusb: change reference file name
On Wed, 16 Dec 2020 17:30:03 +0800, Chunfeng Yun wrote: > Due to usb-device.txt is converted into usb-device.yaml, > so modify reference file names at the same time. > > Signed-off-by: Chunfeng Yun > --- > v2~v4: no changes > --- > Documentation/devicetree/bindings/net/btusb.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH v4 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
On Wed, Dec 16, 2020 at 05:30:02PM +0800, Chunfeng Yun wrote:
> Convert usb-device.txt to YAML schema usb-device.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v4: no changes, update dependent series:
> https://patchwork.kernel.org/project/linux-usb/list/?series=399561
> [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
>
> v3:
> 1. remove $nodenmae and items key word for compatilbe;
> 2. add additionalProperties;
>
> The followings are suggested by Rob:
> 3. merge the following patch
> [v2,1/4] dt-bindings: usb: convert usb-device.txt to YAML schema
> [v2,2/4] dt-bindings: usb: add properties for hard wired devices
> 4. define the unit-address for hard-wired device in usb-hcd.yaml,
> also define its 'reg' and 'compatible';
> 5. This series is base on Serge's series:
>
> https://patchwork.kernel.org/project/linux-usb/cover/2020090853.14112-1-sergey.se...@baikalelectronics.ru/
> [v4,00/18] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
>
> v2 changes suggested by Rob:
> 1. modify pattern to support any USB class
> 2. convert usb-device.txt into usb-device.yaml
> ---
> .../devicetree/bindings/usb/usb-device.txt| 102 --
> .../devicetree/bindings/usb/usb-device.yaml | 125 ++
> .../devicetree/bindings/usb/usb-hcd.yaml | 33 +
> 3 files changed, 158 insertions(+), 102 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
> create mode 100644 Documentation/devicetree/bindings/usb/usb-device.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
> b/Documentation/devicetree/bindings/usb/usb-device.txt
> deleted file mode 100644
> index 036be172b1ae..
> --- a/Documentation/devicetree/bindings/usb/usb-device.txt
> +++ /dev/null
> @@ -1,102 +0,0 @@
> -Generic USB Device Properties
> -
> -Usually, we only use device tree for hard wired USB device.
> -The reference binding doc is from:
> -http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
> -
> -Four types of device-tree nodes are defined: "host-controller nodes"
> -representing USB host controllers, "device nodes" representing USB devices,
> -"interface nodes" representing USB interfaces and "combined nodes"
> -representing simple USB devices.
> -
> -A combined node shall be used instead of a device node and an interface node
> -for devices of class 0 or 9 (hub) with a single configuration and a single
> -interface.
> -
> -A "hub node" is a combined node or an interface node that represents a USB
> -hub.
> -
> -
> -Required properties for device nodes:
> -- compatible: "usbVID,PID", where VID is the vendor id and PID the product
> id.
> - The textual representation of VID and PID shall be in lower case
> hexadecimal
> - with leading zeroes suppressed. The other compatible strings from the above
> - standard binding could also be used, but a device adhering to this binding
> - may leave out all except for "usbVID,PID".
> -- reg: the number of the USB hub port or the USB host-controller port to
> which
> - this device is attached. The range is 1-255.
> -
> -
> -Required properties for device nodes with interface nodes:
> -- #address-cells: shall be 2
> -- #size-cells: shall be 0
> -
> -
> -Required properties for interface nodes:
> -- compatible: "usbifVID,PID.configCN.IN", where VID is the vendor id, PID is
> - the product id, CN is the configuration value and IN is the interface
> - number. The textual representation of VID, PID, CN and IN shall be in lower
> - case hexadecimal with leading zeroes suppressed. The other compatible
> - strings from the above standard binding could also be used, but a device
> - adhering to this binding may leave out all except for
> - "usbifVID,PID.configCN.IN".
> -- reg: the interface number and configuration value
> -
> -The configuration component is not included in the textual representation of
> -an interface-node unit address for configuration 1.
> -
> -
> -Required properties for combined nodes:
> -- compatible: "usbVID,PID", where VID is the vendor id and PID the product
> id.
> - The textual representation of VID and PID shall be in lower case
> hexadecimal
> - with leading zeroes suppressed. The other compatible strings from the above
> - standard binding could also be used, but a device adhering to this binding
> - may leave out all except for "usbVID,PID".
> -- reg: the number of the USB hub port or the USB host-controller port to
> which
> - this device is attached. The range is 1-255.
> -
> -
> -Required properties for hub nodes with device nodes:
> -- #address-cells: shall be 1
> -- #size-cells: shall be 0
> -
> -
> -Required properties for host-controller nodes with device nodes:
> -- #address-cells: shall be 1
> -- #size-cells: shall be 0
> -
> -
> -Example:
> -
> -&usb1 { /* host controller */
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - hub@1 {
[PATCH] dt-bindings: Fix JSON pointers
The correct syntax for JSON pointers begins with a '/' after the '#'. Without a '/', the string should be interpretted as a subschema identifier. The jsonschema module currently doesn't handle subschema identifiers and incorrectly allows JSON pointers to begin without a '/'. Let's fix this before it becomes a problem when jsonschema module is fixed. Converted with: perl -p -i -e 's/yaml#definitions/yaml#\/definitions/g' `find Documentation/devicetree/bindings/ -name "*.yaml"` Cc: Maxime Ripard Cc: Vinod Koul Cc: Guenter Roeck Cc: Jonathan Cameron Cc: Lars-Peter Clausen Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Pavel Machek Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Andrew Lunn Cc: Florian Fainelli Cc: Sebastian Reichel Cc: Greg Kroah-Hartman Cc: Mark Brown Cc: netdev@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/idle-states.yaml | 2 +- .../bus/allwinner,sun50i-a64-de2.yaml | 2 +- .../bindings/bus/baikal,bt1-axi.yaml | 2 +- .../bindings/connector/usb-connector.yaml | 10 ++--- .../devicetree/bindings/dma/dma-common.yaml | 4 +- .../devicetree/bindings/dma/dma-router.yaml | 2 +- .../devicetree/bindings/dma/ingenic,dma.yaml | 2 +- .../bindings/dma/snps,dma-spear1340.yaml | 10 ++--- .../devicetree/bindings/eeprom/at24.yaml | 4 +- .../devicetree/bindings/eeprom/at25.yaml | 4 +- .../bindings/hwmon/moortec,mr75203.yaml | 2 +- .../bindings/hwmon/sensirion,shtc1.yaml | 4 +- .../devicetree/bindings/hwmon/ti,tmp513.yaml | 2 +- .../bindings/iio/light/upisemi,us5182.yaml| 2 +- .../iio/proximity/semtech,sx9310.yaml | 6 +-- .../devicetree/bindings/input/gpio-keys.yaml | 12 +++--- .../interrupt-controller/mti,gic.yaml | 4 +- .../interrupt-controller/ti,pruss-intc.yaml | 2 +- .../interrupt-controller/ti,sci-inta.yaml | 2 +- .../bindings/leds/backlight/common.yaml | 4 +- .../devicetree/bindings/leds/common.yaml | 16 .../devicetree/bindings/leds/leds-lp55xx.yaml | 10 ++--- .../net/allwinner,sun8i-a83t-emac.yaml| 6 +-- .../bindings/net/amlogic,meson-dwmac.yaml | 2 +- .../devicetree/bindings/net/dsa/dsa.yaml | 6 +-- .../bindings/net/ethernet-controller.yaml | 24 ++-- .../devicetree/bindings/net/ethernet-phy.yaml | 20 +- .../bindings/net/fsl,qoriq-mc-dpmac.yaml | 2 +- .../devicetree/bindings/net/mdio.yaml | 2 +- .../bindings/net/mediatek,star-emac.yaml | 2 +- .../devicetree/bindings/net/qcom,ipa.yaml | 2 +- .../devicetree/bindings/net/snps,dwmac.yaml | 38 +-- .../bindings/net/socionext,uniphier-ave4.yaml | 2 +- .../bindings/net/ti,cpsw-switch.yaml | 2 +- .../devicetree/bindings/net/ti,dp83867.yaml | 12 +++--- .../devicetree/bindings/net/ti,dp83869.yaml | 8 ++-- .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 4 +- .../bindings/net/wireless/qcom,ath11k.yaml| 2 +- .../devicetree/bindings/phy/ti,omap-usb2.yaml | 4 +- .../power/mediatek,power-controller.yaml | 12 +++--- .../bindings/power/supply/cw2015_battery.yaml | 2 +- .../devicetree/bindings/powerpc/sleep.yaml| 2 +- .../devicetree/bindings/serial/8250.yaml | 6 +-- .../bindings/soc/ti/k3-ringacc.yaml | 2 +- .../sound/allwinner,sun4i-a10-codec.yaml | 2 +- .../bindings/sound/st,stm32-sai.yaml | 4 +- 46 files changed, 138 insertions(+), 138 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/arm/idle-states.yaml index ea805c1e6b20..52bce5dbb11f 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.yaml +++ b/Documentation/devicetree/bindings/arm/idle-states.yaml @@ -313,7 +313,7 @@ patternProperties: wakeup-latency-us by this duration. idle-state-name: -$ref: /schemas/types.yaml#definitions/string +$ref: /schemas/types.yaml#/definitions/string description: A string used as a descriptive name for the idle state. diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml index 0503651cd214..863a287ebc7e 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -34,7 +34,7 @@ properties: description: The SRAM that needs to be claimed to access the display engine bus. -$ref: /schemas/types.yaml#definitions/phandle-array +$ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 ranges: true diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml index 0bee4694578a..4ac78b44e45e 100644 ---
Re: [PATCH 07/25] dt-bindings: net: dwmac: Detach Generic DW MAC bindings
On Mon, Dec 14, 2020 at 12:15:57PM +0300, Serge Semin wrote:
> Currently the snps,dwmac.yaml DT bindings file is used for both DT nodes
> describing generic DW MAC devices and as DT schema with common properties
> to be evaluated against a vendor-specific DW MAC IP-cores. Due to such
> dual-purpose design the "compatible" property of the common DW MAC schema
> needs to contain the vendor-specific strings to successfully pass the
> schema evaluation in case if it's referenced from the vendor-specific DT
> bindings. That's a bad design from maintainability point of view, since
> adding/removing any DW MAC-based device bindings requires the common
> schema modification. In order to fix that let's detach the schema which
> provides the generic DW MAC DT nodes evaluation into a dedicated DT
> bindings file preserving the common DW MAC properties declaration in the
> snps,dwmac.yaml file. By doing so we'll still provide a common properties
> evaluation for each vendor-specific MAC bindings which refer to the
> common bindings file, while the generic DW MAC DT nodes will be checked
> against the new snps,dwmac-generic.yaml DT schema.
I'm okay with the change, but it needs a big fat note that
snps,dwmac-generic.yaml should not have new users. New users should have
an SoC specific compatible. History has shown that even IP versions are
not enough to handle all the integration crap vendors do.
>
> Signed-off-by: Serge Semin
> ---
> .../bindings/net/snps,dwmac-generic.yaml | 148 ++
> .../devicetree/bindings/net/snps,dwmac.yaml | 139 +---
> 2 files changed, 149 insertions(+), 138 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
> b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
> new file mode 100644
> index ..f1b387911390
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac-generic.yaml
> @@ -0,0 +1,148 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/snps,dwmac-generic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare Generic MAC Device Tree Bindings
> +
> +maintainers:
> + - Alexandre Torgue
> + - Giuseppe Cavallaro
> + - Jose Abreu
> +
> +# Select the DT nodes, which have got compatible strings either as just a
> +# single string with IP-core name optionally followed by the IP version or
> +# two strings: one with IP-core name plus the IP version, another as just
> +# the IP-core name.
> +select:
> + properties:
> +compatible:
> + oneOf:
> +- items:
> +- pattern: "^snps,dw(xg)+mac(-[0-9]+\\.[0-9]+a?)?$"
> +- items:
> +- pattern: "^snps,dwmac-[0-9]+\\.[0-9]+a?$"
> +- const: snps,dwmac
> +- items:
> +- pattern: "^snps,dwxgmac-[0-9]+\\.[0-9]+a?$"
> +- const: snps,dwxgmac
> +
> + required:
> +- compatible
> +
> +allOf:
> + - $ref: snps,dwmac.yaml#
> +
> +properties:
> + compatible:
> +oneOf:
> + - description: Generic Synopsys DW MAC
> +oneOf:
> + - items:
> + - enum:
> + - snps,dwmac-3.50a
> + - snps,dwmac-3.610
> + - snps,dwmac-3.70a
> + - snps,dwmac-3.710
> + - snps,dwmac-4.00
> + - snps,dwmac-4.10a
> + - snps,dwmac-4.20a
> + - const: snps,dwmac
> + - const: snps,dwmac
> + - description: Generic Synopsys DW xGMAC
> +oneOf:
> + - items:
> + - enum:
> + - snps,dwxgmac-2.10
> + - const: snps,dwxgmac
> + - const: snps,dwxgmac
> + - description: ST SPEAr SoC Family GMAC
> +deprecated: true
> +const: st,spear600-gmac
> +
> + reg:
> +maxItems: 1
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +gmac0: ethernet@e080 {
> + compatible = "snps,dwxgmac-2.10", "snps,dwxgmac";
> + reg = <0xe080 0x8000>;
> + interrupt-parent = <&vic1>;
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
> + mac-address = []; /* Filled in by U-Boot */
> + max-frame-size = <3800>;
> + phy-mode = "gmii";
> + snps,multicast-filter-bins = <256>;
> + snps,perfect-filter-entries = <128>;
> + rx-fifo-depth = <16384>;
> + tx-fifo-depth = <16384>;
> + clocks = <&clock>;
> + clock-names = "stmmaceth";
> + snps,axi-config = <&stmmac_axi_setup>;
> + snps,mtl-rx-config = <&mtl_rx_setup>;
> + snps,mtl-tx-config = <&mtl_tx_setup>;
> + mdio0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = "snps,dwmac-mdio";
> +phy1: ethernet-phy@0 {
> + reg = <0
Re: [PATCH 05/25] dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description
On Mon, 14 Dec 2020 12:15:55 +0300, Serge Semin wrote: > Current clocks description doesn't provide a comprehensive notion about > what "stmmaceth" and "pclk" actually represent from the IP-core manual > point of view. The bindings file states: > stmmaceth - "GMAC main clock", > apb - "Peripheral registers interface clock". > It isn't that easy to understand what they actually mean especially seeing > the DW *MAC manual operates with clock definitions like Application, > System, Host, CSR, Transmit, Receive, etc clocks. Moreover the clocks > usage in the driver doesn't shade a full light on their essence. What > inferred from there is that the "stmmaceth" name has been assigned to the > common clock, which feeds both system and CSR interfaces. But what about > "apb"? The bindings defines it as the clock for "peripheral registers > interface". So it's close to the CSR clock in the IP-core manual notation. > If so then when "apb" clock is specified aside with the "stmmaceth", it > represents a case when the DW *MAC is synthesized with CSR_SLV_CLK=y > (separate system and CSR clocks). But even though the "apb" clock is > requested in the MAC driver, the driver doesn't actually use it as a > separate CSR clock where the IP-core manual requires. All of that makes me > thinking that the case of separate system and CSR clocks isn't correctly > implemented in the driver. > > Let's start with elaborating the clocks description so anyone reading > the DW *MAC bindings file would understand that "stmmaceth" is the > system clock and "pclk" is actually the CSR clock. Indeed in accordance > with sheets depicted in [1]: > system/application clock can be either of: hclk_i, aclk_i, clk_app_i; > CSR clock can be either of: hclk_i, aclk_i, clk_app_i, clk_csr_i. > (Most likely the similar definitions present in the others IP-core > manuals.) So the CSR clock can be tied to the application clock > considering the later as the main clock, but not the other way around. In > case if there is only "stmmaceth" clock specified in a DT node, then it > will be considered as a source of clocks for both application and CSR. But > if "pclk" is also specified in the list of the device clocks, then it will > be perceived as the separate CSR clock. > > [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, > October 2013, p. 564. > > Signed-off-by: Serge Semin > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH 06/25] dt-bindings: net: dwmac: Add Tx/Rx clock sources
On Mon, Dec 14, 2020 at 12:15:56PM +0300, Serge Semin wrote: > Generic DW *MAC can be connected to an external Tramit and Receive clock s/Tramit/Transmit/ > generators. Add the corresponding clocks description and clock-names to > the generic bindings schema so new DW *MAC-based bindings wouldn't declare > its own names of the same clocks. > > Signed-off-by: Serge Semin > --- > .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > index e1ebe5c8b1da..74820f491346 100644 > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > @@ -126,6 +126,18 @@ properties: >MCI, CSR and SMA interfaces run on this clock. If it's omitted, >the CSR interfaces are considered as synchronous to the system >clock domain. > + - description: > + GMAC Tx clock or so called Transmit clock. The clock is supplied > + by an external with respect to the DW MAC clock generator. > + The clock source and its frequency depends on the DW MAC xMII mode. > + In case if it's supplied by PHY/SerDes this property can be > + omitted. > + - description: > + GMAC Rx clock or so called Receive clock. The clock is supplied > + by an external with respect to the DW MAC clock generator. > + The clock source and its frequency depends on the DW MAC xMII mode. > + In case if it's supplied by PHY/SerDes or it's synchronous to > + the Tx clock this property can be omitted. >- description: >PTP reference clock. This clock is used for programming the >Timestamp Addend Register. If not passed then the system > @@ -139,6 +151,8 @@ properties: >enum: > - stmmaceth > - pclk > +- tx > +- rx > - ptp_ref > >resets: > -- > 2.29.2 >
Re: [PATCH 06/25] dt-bindings: net: dwmac: Add Tx/Rx clock sources
On Mon, 14 Dec 2020 12:15:56 +0300, Serge Semin wrote: > Generic DW *MAC can be connected to an external Tramit and Receive clock > generators. Add the corresponding clocks description and clock-names to > the generic bindings schema so new DW *MAC-based bindings wouldn't declare > its own names of the same clocks. > > Signed-off-by: Serge Semin > --- > .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++ > 1 file changed, 14 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH 03/25] dt-bindings: net: dwmac: Fix the TSO property declaration
On Mon, Dec 14, 2020 at 12:15:53PM +0300, Serge Semin wrote: > Indeed the STMMAC driver doesn't take the vendor-specific compatible > string into account to parse the "snps,tso" boolean property. It just > makes sure the node is compatible with DW MAC 4.x, 5.x and DW xGMAC > IP-cores. Fix the conditional statement so the TSO-property would be > evaluated for the compatibles having the corresponding IP-core version. > > While at it move the whole allOf-block from the tail of the binding file > to the head of it, as it's normally done in the most of the DT schemas. > > Signed-off-by: Serge Semin > > --- > > Note this won't break the bindings description, since the "snps,tso" > property isn't parsed by the Allwinner SunX GMAC glue driver, but only > by the generic platform DT-parser. But still should be valid for Allwinner? > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 52 +-- > 1 file changed, 24 insertions(+), 28 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > index e084fbbf976e..0dd543c6c08e 100644 > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml > @@ -37,6 +37,30 @@ select: >required: > - compatible > > +allOf: > + - $ref: "ethernet-controller.yaml#" > + - if: > + properties: > +compatible: > + contains: > +enum: > + - snps,dwmac-4.00 > + - snps,dwmac-4.10a > + - snps,dwmac-4.20a > + - snps,dwmac-5.10a > + - snps,dwxgmac > + - snps,dwxgmac-2.10 > + > + required: > +- compatible > +then: > + properties: > +snps,tso: > + $ref: /schemas/types.yaml#definitions/flag > + description: > +Enables the TSO feature otherwise it will be managed by > +MAC HW capability register. BTW, I prefer that properties are defined unconditionally, and then restricted in conditional schemas (or ones that include this schema). > + > properties: > ># We need to include all the compatibles from schemas that will > @@ -314,34 +338,6 @@ dependencies: >snps,reset-active-low: ["snps,reset-gpio"] >snps,reset-delay-us: ["snps,reset-gpio"] > > -allOf: > - - $ref: "ethernet-controller.yaml#" > - - if: > - properties: > -compatible: > - contains: > -enum: > - - allwinner,sun7i-a20-gmac This does not have a fallback, so snps,tso is no longer validated. I didn't check the rest. > - - allwinner,sun8i-a83t-emac > - - allwinner,sun8i-h3-emac > - - allwinner,sun8i-r40-emac > - - allwinner,sun8i-v3s-emac > - - allwinner,sun50i-a64-emac > - - snps,dwmac-4.00 > - - snps,dwmac-4.10a > - - snps,dwmac-4.20a > - - snps,dwxgmac > - - snps,dwxgmac-2.10 > - - st,spear600-gmac > - > -then: > - properties: > -snps,tso: > - $ref: /schemas/types.yaml#definitions/flag > - description: > -Enables the TSO feature otherwise it will be managed by > -MAC HW capability register. > - > additionalProperties: true > > examples: > -- > 2.29.2 >
Re: [PATCH 02/25] dt-bindings: net: dwmac: Extend number of PBL values
On Mon, 14 Dec 2020 12:15:52 +0300, Serge Semin wrote: > In accordance with [1] the permitted PBL values can be set as one of > [1, 2, 4, 8, 16, 32]. The rest of the values results in undefined > behavior. At the same time some of the permitted values can be also > invalid depending on the controller FIFOs size and the data bus width. > Seeing due to having too many variables all the possible PBL property > constraints can't be implemented in the bindings schema, let's extend > the set of permitted PBL values to be as much as the configuration > register supports leaving the undefined behaviour cases for developers > to handle. > > [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, > October 2013, p. 380. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/net/snps,dwmac.yaml | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH 01/25] dt-bindings: net: dwmac: Validate PBL for all IP-cores
On Mon, 14 Dec 2020 12:15:51 +0300, Serge Semin wrote: > Indeed the maximum DMA burst length can be programmed not only for DW > xGMACs, Allwinner EMACs and Spear SoC GMAC, but in accordance with [1] > for Generic DW *MAC IP-cores. Moreover the STMMAC set of drivers parse > the property and then apply the configuration for all supported DW MAC > devices. All of that makes the property being available for all IP-cores > the bindings supports. Let's make sure the PBL-related properties are > validated for all of them by the common DW MAC DT schema. > > [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, > October 2013, p. 380. > > Signed-off-by: Serge Semin > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 69 +++ > 1 file changed, 26 insertions(+), 43 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties
On Tue, Dec 15, 2020 at 2:54 AM Serge Semin
wrote:
>
> Hello Rob,
>
> On Mon, Dec 14, 2020 at 08:30:06AM -0600, Rob Herring wrote:
> > On Mon, Dec 14, 2020 at 12:15:54PM +0300, Serge Semin wrote:
> > > Currently the "snps,axi-config", "snps,mtl-rx-config" and
> > > "snps,mtl-tx-config" properties are declared as a single phandle reference
> > > to a node with corresponding parameters defined. That's not good for
> > > several reasons. First of all scattering around a device tree some
> > > particular device-specific configs with no visual relation to that device
> > > isn't suitable from maintainability point of view. That leads to a
> > > disturbed representation of the actual device tree mixing actual device
> > > nodes and some vendor-specific configs. Secondly using the same configs
> > > set for several device nodes doesn't represent well the devices structure,
> > > since the interfaces these configs describe in hardware belong to
> > > different devices and may actually differ. In the later case having the
> > > configs node separated from the corresponding device nodes gets to be
> > > even unjustified.
> > >
> > > So instead of having a separate DW *MAC configs nodes we suggest to
> > > define them as sub-nodes of the device nodes, which interfaces they
> > > actually describe. By doing so we'll make the DW *MAC nodes visually
> > > correct describing all the aspects of the IP-core configuration. Thus
> > > we'll be able to describe the configs sub-nodes bindings right in the
> > > snps,dwmac.yaml file.
> > >
> > > Note the former "snps,axi-config", "snps,mtl-rx-config" and
> > > "snps,mtl-tx-config" bindings have been marked as deprecated.
> > >
> > > Signed-off-by: Serge Semin
> > >
> > > ---
> > >
> > > Note the current DT schema tool requires the vendor-specific properties
> > > to be
> > > defined in accordance with the schema:
> > > dtschema/meta-schemas/vendor-props.yaml
> > > It means the property can be;
> > > - boolean,
> > > - string,
> > > - defined with $ref and additional constraints,
> > > - defined with allOf: [ $ref ] and additional constraints.
> > >
> > > The modification provided by this commit needs to extend that definition
> > > to
> > > make the DT schema tool correctly parse this schema. That is we need to
> > > let
> > > the vendors-specific properties to also accept the oneOf-based combined
> > > sub-schema. Like this:
> > >
> > > --- a/dtschema/meta-schemas/vendor-props.yaml
> > > +++ b/dtschema/meta-schemas/vendor-props.yaml
> > > @@ -48,15 +48,24 @@
> > >- properties: # A property with a type and additional constraints
> > >$ref:
> > > pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > > - allOf:
> > > -items:
> > > - - properties:
> > > +
> > > +if:
> > > + not:
> > > +required:
> > > + - $ref
> > > +then:
> > > + patternProperties:
> > > +"^(all|one)Of$":
> > > + contains:
> > > +properties:
> > >$ref:
> > > pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > > required:
> > >- $ref
> > > -oneOf:
> > > +
> > > +anyOf:
> > >- required: [ $ref ]
> > >- required: [ allOf ]
> > > + - required: [ oneOf ]
> > >
> > > ...
> > > ---
> > > .../devicetree/bindings/net/snps,dwmac.yaml | 380 +-
> > > 1 file changed, 288 insertions(+), 92 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > index 0dd543c6c08e..44aa88151cba 100644
> > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > @@ -150,69 +150,251 @@ properties:
> > >in a different mode than the PHY in order to function.
> > >
> > >snps,axi-config:
> > > -$ref: /schemas/
Re: [PATCH RFC v2 1/5] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
On Sun, Dec 13, 2020 at 05:59:05PM +0100, Martin Blumenstingl wrote:
> Hi Rob,
>
> On Mon, Dec 7, 2020 at 8:17 PM Rob Herring wrote:
> >
> > On Sun, Nov 15, 2020 at 07:52:06PM +0100, Martin Blumenstingl wrote:
> > > Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX
> > > delay register which allows picoseconds precision. Deprecate the old
> > > "amlogic,rx-delay-ns" in favour of a new "amlogic,rgmii-rx-delay-ps"
> > > property.
> > >
> > > For older SoCs the only known supported values were 0ns and 2ns. The new
> > > SoCs have 200ps precision and support RGMII RX delays between 0ps and
> > > 3000ps.
> > >
> > > While here, also update the description of the RX delay to indicate
> > > that:
> > > - with "rgmii" or "rgmii-id" the RX delay should be specified
> > > - with "rgmii-id" or "rgmii-rxid" the RX delay is added by the PHY so
> > > any configuration on the MAC side is ignored
> > > - with "rmii" the RX delay is not applicable and any configuration is
> > > ignored
> > >
> > > Signed-off-by: Martin Blumenstingl
> > > ---
> > > .../bindings/net/amlogic,meson-dwmac.yaml | 61 +--
> > > 1 file changed, 56 insertions(+), 5 deletions(-)
> >
> > Don't we have common properties for this now?
> I did a quick:
> $ grep -R rx-delay Documentation/devicetree/bindings/net/
>
> I could find "rx-delay" without vendor prefix, but that's not using
> any unit in the name (ns, ps, ...)
> Please let me know if you aware of any "generic" property for the RX
> delay in picosecond precision
{rx,tx}-internal-delay-ps in ethernet-controller.yaml and
ethernet-phy.yaml.
Re: [net-next PATCH v12 1/4] dt-bindings: net: Add 5GBASER phy interface mode
On Fri, 11 Dec 2020 22:46:04 +1000, Pavana Sharma wrote: > Add 5gbase-r PHY interface mode. > > Signed-off-by: Pavana Sharma > --- > Documentation/devicetree/bindings/net/ethernet-controller.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties
On Mon, Dec 14, 2020 at 12:15:54PM +0300, Serge Semin wrote:
> Currently the "snps,axi-config", "snps,mtl-rx-config" and
> "snps,mtl-tx-config" properties are declared as a single phandle reference
> to a node with corresponding parameters defined. That's not good for
> several reasons. First of all scattering around a device tree some
> particular device-specific configs with no visual relation to that device
> isn't suitable from maintainability point of view. That leads to a
> disturbed representation of the actual device tree mixing actual device
> nodes and some vendor-specific configs. Secondly using the same configs
> set for several device nodes doesn't represent well the devices structure,
> since the interfaces these configs describe in hardware belong to
> different devices and may actually differ. In the later case having the
> configs node separated from the corresponding device nodes gets to be
> even unjustified.
>
> So instead of having a separate DW *MAC configs nodes we suggest to
> define them as sub-nodes of the device nodes, which interfaces they
> actually describe. By doing so we'll make the DW *MAC nodes visually
> correct describing all the aspects of the IP-core configuration. Thus
> we'll be able to describe the configs sub-nodes bindings right in the
> snps,dwmac.yaml file.
>
> Note the former "snps,axi-config", "snps,mtl-rx-config" and
> "snps,mtl-tx-config" bindings have been marked as deprecated.
>
> Signed-off-by: Serge Semin
>
> ---
>
> Note the current DT schema tool requires the vendor-specific properties to be
> defined in accordance with the schema: dtschema/meta-schemas/vendor-props.yaml
> It means the property can be;
> - boolean,
> - string,
> - defined with $ref and additional constraints,
> - defined with allOf: [ $ref ] and additional constraints.
>
> The modification provided by this commit needs to extend that definition to
> make the DT schema tool correctly parse this schema. That is we need to let
> the vendors-specific properties to also accept the oneOf-based combined
> sub-schema. Like this:
>
> --- a/dtschema/meta-schemas/vendor-props.yaml
> +++ b/dtschema/meta-schemas/vendor-props.yaml
> @@ -48,15 +48,24 @@
>- properties: # A property with a type and additional constraints
>$ref:
> pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> - allOf:
> -items:
> - - properties:
> +
> +if:
> + not:
> +required:
> + - $ref
> +then:
> + patternProperties:
> +"^(all|one)Of$":
> + contains:
> +properties:
>$ref:
> pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> required:
>- $ref
> -oneOf:
> +
> +anyOf:
>- required: [ $ref ]
>- required: [ allOf ]
> + - required: [ oneOf ]
>
> ...
> ---
> .../devicetree/bindings/net/snps,dwmac.yaml | 380 +-
> 1 file changed, 288 insertions(+), 92 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 0dd543c6c08e..44aa88151cba 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -150,69 +150,251 @@ properties:
>in a different mode than the PHY in order to function.
>
>snps,axi-config:
> -$ref: /schemas/types.yaml#definitions/phandle
> -description:
> - AXI BUS Mode parameters. Phandle to a node that can contain the
> - following properties
> -* snps,lpi_en, enable Low Power Interface
> -* snps,xit_frm, unlock on WoL
> -* snps,wr_osr_lmt, max write outstanding req. limit
> -* snps,rd_osr_lmt, max read outstanding req. limit
> -* snps,kbbe, do not cross 1KiB boundary.
> -* snps,blen, this is a vector of supported burst length.
> -* snps,fb, fixed-burst
> -* snps,mb, mixed-burst
> -* snps,rb, rebuild INCRx Burst
> +description: AXI BUS Mode parameters
> +oneOf:
> + - deprecated: true
> +$ref: /schemas/types.yaml#definitions/phandle
> + - type: object
> +properties:
Anywhere have have the same node/property string meaning 2 different
things is a pain, let's not create another one. Just define a new node
'axi-config'. Or just put all the properties into the node directly.
Grouping them has little purpose.
> + snps,lpi_en:
> +$ref: /schemas/types.yaml#definitions/flag
> +description: Enable Low Power Interface
> +
> + snps,xit_frm:
> +$ref: /schemas/types.yaml#definitions/flag
> +description: Unlock on WoL
> +
> + snps,wr_osr_lmt:
> +$ref: /schemas/types.yaml#definitions/uint32
> +description: Max write outsta
Re: [patch 19/30] PCI: mobiveil: Use irq_data_get_irq_chip_data()
On Thu, Dec 10, 2020 at 1:42 PM Thomas Gleixner wrote: > > Going through a full irq descriptor lookup instead of just using the proper > helper function which provides direct access is suboptimal. > > In fact it _is_ wrong because the chip callback needs to get the chip data > which is relevant for the chip while using the irq descriptor variant > returns the irq chip data of the top level chip of a hierarchy. It does not > matter in this case because the chip is the top level chip, but that > doesn't make it more correct. > > Signed-off-by: Thomas Gleixner > Cc: Karthikeyan Mitran > Cc: Hou Zhiqiang > Cc: Lorenzo Pieralisi > Cc: Rob Herring > Cc: Bjorn Helgaas > Cc: linux-...@vger.kernel.org > --- > drivers/pci/controller/mobiveil/pcie-mobiveil-host.c |8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) Reviewed-by: Rob Herring
Re: [patch 18/30] PCI: xilinx-nwl: Use irq_data_get_irq_chip_data()
On Thu, Dec 10, 2020 at 1:42 PM Thomas Gleixner wrote: > > Going through a full irq descriptor lookup instead of just using the proper > helper function which provides direct access is suboptimal. > > In fact it _is_ wrong because the chip callback needs to get the chip data > which is relevant for the chip while using the irq descriptor variant > returns the irq chip data of the top level chip of a hierarchy. It does not > matter in this case because the chip is the top level chip, but that > doesn't make it more correct. > > Signed-off-by: Thomas Gleixner > Cc: Lorenzo Pieralisi > Cc: Rob Herring > Cc: Bjorn Helgaas > Cc: Michal Simek > Cc: linux-...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > --- > drivers/pci/controller/pcie-xilinx-nwl.c |8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH net-next v3 3/3] dt-bindings: net: dsa: add bindings for xrs700x switches
On Mon, Dec 07, 2020 at 04:03:55PM -0600, George McCollister wrote:
> Add documentation and an example for Arrow SpeedChips XRS7000 Series
> single chip Ethernet switches.
>
> Signed-off-by: George McCollister
> Reviewed-by: Florian Fainelli
> ---
> .../devicetree/bindings/net/dsa/arrow,xrs700x.yaml | 74
> ++
> 1 file changed, 74 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
> b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
> new file mode 100644
> index ..05ed36ce02ec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/arrow,xrs700x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arrow SpeedChips XRS7000 Series Switch Device Tree Bindings
> +
> +allOf:
> + - $ref: dsa.yaml#
> +
> +maintainers:
> + - George McCollister
> +
> +description:
> + The Arrow SpeedChips XRS7000 Series of single chip gigabit Ethernet
> switches
> + are designed for critical networking applications. They have up to three
> + RGMII ports and one RMII port and are managed via i2c or mdio.
> +
> +properties:
> + compatible:
> +oneOf:
> + - enum:
> + - arrow,xrs7003e
> + - arrow,xrs7003f
> + - arrow,xrs7004e
> + - arrow,xrs7004f
> +
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +switch@8 {
> +compatible = "arrow,xrs7004e";
> +reg = <0x8>;
> +
> +status = "okay";
Don't show status in examples.
> +ports {
ethernet-ports is preferred.
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@1 {
And ethernet-port
> +reg = <1>;
> +label = "lan0";
> +phy-handle = <&swphy0>;
> +phy-mode = "rgmii-id";
> +};
> +port@2 {
> +reg = <2>;
> +label = "lan1";
> +phy-handle = <&swphy1>;
> +phy-mode = "rgmii-id";
> +};
> +port@3 {
> +reg = <3>;
> +label = "cpu";
> +ethernet = <&fec1>;
> +fixed-link {
> +speed = <1000>;
> +full-duplex;
> +};
> +};
> +};
> +};
> +};
> --
> 2.11.0
>
Re: [PATCH v2 2/2] dt-bindings: net: dsa: lantiq, lantiq-gswip: add example for xRX330
On Sun, Dec 06, 2020 at 02:27:13PM +0100, Aleksander Jan Bajkowski wrote:
> Add compatible string and example for xRX300 and xRX330.
>
> Signed-off-by: Aleksander Jan Bajkowski
> ---
> .../bindings/net/dsa/lantiq-gswip.txt | 110 +-
> 1 file changed, 109 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
> b/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
> index 886cbe8ffb38..7a90a6a1b065 100644
> --- a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
> @@ -3,7 +3,8 @@ Lantiq GSWIP Ethernet switches
>
> Required properties for GSWIP core:
>
> -- compatible : "lantiq,xrx200-gswip" for the embedded GSWIP in the
> +- compatible : "lantiq,xrx200-gswip", "lantiq,xrx300-gswip" or
> + "lantiq,xrx330-gswip" for the embedded GSWIP in the
> xRX200 SoC
> - reg: memory range of the GSWIP core registers
> : memory range of the GSWIP MDIO registers
> @@ -141,3 +142,110 @@ switch@e108000 {
> };
> };
> };
> +
> +Ethernet switch on the GRX330 SoC:
A new compatible string doesn't justify a new example.
Consider converting to DT schema.
> +
> +switch@e108000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "lantiq,xrx300-gswip";
> + reg = < 0xe108000 0x3100/* switch */
> + 0xe10b100 0xd8 /* mdio */
> + 0xe10b1d8 0x130 /* mii */
> + >;
> + dsa,member = <0 0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + phy-mode = "internal";
> + phy-handle = <&phy1>;
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + phy-mode = "internal";
> + phy-handle = <&phy2>;
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan3";
> + phy-mode = "internal";
> + phy-handle = <&phy3>;
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "lan4";
> + phy-mode = "internal";
> + phy-handle = <&phy4>;
> + };
> +
> + port@6 {
> + reg = <0x6>;
> + label = "cpu";
> + ethernet = <ð0>;
> + };
> + };
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "lantiq,xrx200-mdio";
> + reg = <0>;
> +
> + phy1: ethernet-phy@1 {
> + reg = <0x1>;
> + };
> + phy2: ethernet-phy@2 {
> + reg = <0x2>;
> + };
> + phy3: ethernet-phy@3 {
> + reg = <0x3>;
> + };
> + phy4: ethernet-phy@4 {
> + reg = <0x4>;
> + };
> + };
> +
> + gphy-fw {
> + compatible = "lantiq,xrx330-gphy-fw", "lantiq,gphy-fw";
> + lantiq,rcu = <&rcu0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gphy@20 {
> + reg = <0x20>;
> +
> + resets = <&reset0 31 30>;
> + reset-names = "gphy";
> + };
> +
> + gphy@68 {
> + reg = <0x68>;
> +
> + resets = <&reset0 29 28>;
> + reset-names = "gphy";
> + };
> +
> + gphy@ac {
> + reg = <0xac>;
> +
> + resets = <&reset0 28 13>;
> + reset-names = "gphy";
> + };
> +
> + gphy@264 {
> + reg = <0x264>;
> +
> + resets = <&reset0 10 10>;
> + reset-names = "gphy";
> + };
> + };
> +};
> --
> 2.20.1
>
Re: [PATCH net-next v5 2/9] dt-bindings: net: dsa: microchip,ksz: add interrupt property
On Thu, 03 Dec 2020 11:21:10 +0100, Christian Eggers wrote: > The devices have an optional interrupt line. > > Signed-off-by: Christian Eggers > --- > .../devicetree/bindings/net/dsa/microchip,ksz.yaml | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings::Add compatible strings
On Tue, 01 Dec 2020 21:26:10 -1000, xiao.ma wrote: > From: "xiao.ma" > > Add delta,q54sj108a2 to trivial-devices.yaml. > > Signed-off-by: xiao.ma > --- > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Applied with subject fixed. 'git log --oneline ' will give you an idea of what the subject should look like. Rob
Re: [PATCH v3 10/11] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
On Wed, Nov 18, 2020 at 04:21:25PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties
> 3. remove unnecessary '|'
> 4. drop unused labels in example
>
> v2: new patch
> ---
> .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 -
> .../bindings/usb/mediatek,mtu3.yaml | 218 ++
> 2 files changed, 218 insertions(+), 108 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> deleted file mode 100644
> index a82ca438aec1..
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> +++ /dev/null
> @@ -1,108 +0,0 @@
> -The device node for Mediatek USB3.0 DRD controller
> -
> -Required properties:
> - - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc,
> - when using "mediatek,mtu3" compatible string, you need SoC specific
> - ones in addition, one of:
> - - "mediatek,mt8173-mtu3"
> - - reg : specifies physical base address and size of the registers
> - - reg-names: should be "mac" for device IP and "ippc" for IP port control
> - - interrupts : interrupt used by the device IP
> - - power-domains : a phandle to USB power domain node to control USB's
> - mtcmos
> - - vusb33-supply : regulator of USB avdd3.3v
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller,
> - the following clocks are optional:
> - "ref_ck", "mcu_ck" and "dma_ck";
> - - phys : see usb-hcd.yaml in the current directory
> - - dr_mode : should be one of "host", "peripheral" or "otg",
> - refer to usb/generic.txt
> -
> -Optional properties:
> - - #address-cells, #size-cells : should be '2' if the device has sub-nodes
> - with 'reg' property
> - - ranges : allows valid 1:1 translation between child's address space and
> - parent's address space
> - - extcon : external connector for vbus and idpin changes detection, needed
> - when supports dual-role mode.
> - it's considered valid for compatibility reasons, not allowed for
> - new bindings, and use "usb-role-switch" property instead.
> - - vbus-supply : reference to the VBUS regulator, needed when supports
> - dual-role mode.
> - it's considered valid for compatibility reasons, not allowed for
> - new bindings, and put into a usb-connector node.
> - see connector/usb-connector.yaml.
> - - pinctrl-names : a pinctrl state named "default" is optional, and need be
> - defined if auto drd switch is enabled, that means the property dr_mode
> - is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
> - is not set.
> - - pinctrl-0 : pin control group
> - See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> -
> - - maximum-speed : valid arguments are "super-speed", "high-speed" and
> - "full-speed"; refer to usb/generic.txt
> - - usb-role-switch : use USB Role Switch to support dual-role switch, but
> - not extcon; see usb/generic.txt.
> - - enable-manual-drd : supports manual dual-role switch via debugfs; usually
> - used when receptacle is TYPE-A and also wants to support dual-role
> - mode.
> - - wakeup-source: enable USB remote wakeup of host mode.
> - - mediatek,syscon-wakeup : phandle to syscon used to access the register
> - of the USB wakeup glue layer between SSUSB and SPM; it depends on
> - "wakeup-source", and has two arguments:
> - - the first one : register base address of the glue layer in syscon;
> - - the second one : hardware version of the glue layer
> - - 1 : used by mt8173 etc
> - - 2 : used by mt2712 etc
> - - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> - bit1 for u3port1, ... etc;
> -
> -additionally the properties from usb-hcd.yaml (in the current directory) are
> -supported.
> -
> -Sub-nodes:
> -The xhci should be added as subnode to mtu3 as shown in the following example
> -if host mode is enabled. The DT binding details of xhci can be found in:
> -Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> -
> -The port would be added as subnode if use "usb-role-switch" property.
> - see graph.txt
> -
> -Example:
> -ssusb: usb@11271000 {
> - compatible = "mediatek,mt8173-mtu3";
> - reg = <0 0x11271000 0 0x3000>,
> - <0 0x11280700 0 0x0100>;
> - reg-names = "mac", "ippc";
> - interrupts = ;
> - phys = <&phy_port0 PHY_TYPE_USB3>,
> -<&phy_port1 PHY_TYPE_USB2>;
> - power-domains = <&scpsys MT8173_POWER_DOMA
Re: [PATCH v3 09/11] dt-bindings: usb: convert mediatek,mtk-xhci.txt to YAML schema
On Wed, Nov 18, 2020 at 04:21:24PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties supported by default suggested by Rob
> 3. drop unused labels
> 4. modify description of mediatek,syscon-wakeup
> 5. remove type of imod-interval-ns
>
> v2: new patch
> ---
> .../bindings/usb/mediatek,mtk-xhci.txt| 121 -
> .../bindings/usb/mediatek,mtk-xhci.yaml | 171 ++
> 2 files changed, 171 insertions(+), 121 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> create mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> deleted file mode 100644
> index 42d8814f903a..
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> +++ /dev/null
> @@ -1,121 +0,0 @@
> -MT8173 xHCI
> -
> -The device node for Mediatek SOC USB3.0 host controller
> -
> -There are two scenarios: the first one only supports xHCI driver;
> -the second one supports dual-role mode, and the host is based on xHCI
> -driver. Take account of backward compatibility, we divide bindings
> -into two parts.
> -
> -1st: only supports xHCI driver
> -
> -
> -Required properties:
> - - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
> - "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
> - addition, one of:
> - - "mediatek,mt8173-xhci"
> - - reg : specifies physical base address and size of the registers
> - - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
> - - interrupts : interrupt used by the controller
> - - power-domains : a phandle to USB power domain node to control USB's
> - mtcmos
> - - vusb33-supply : regulator of USB avdd3.3v
> -
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain
> - "sys_ck": controller clock used by normal mode,
> - the following ones are optional:
> - "ref_ck": reference clock used by low power mode etc,
> - "mcu_ck": mcu_bus clock for register access,
> - "dma_ck": dma_bus clock for data transfer by DMA,
> - "xhci_ck": controller clock
> -
> - - phys : see usb-hcd.yaml in the current directory
> -
> -Optional properties:
> - - wakeup-source : enable USB remote wakeup;
> - - mediatek,syscon-wakeup : phandle to syscon used to access the register
> - of the USB wakeup glue layer between xHCI and SPM; it depends on
> - "wakeup-source", and has two arguments:
> - - the first one : register base address of the glue layer in syscon;
> - - the second one : hardware version of the glue layer
> - - 1 : used by mt8173 etc
> - - 2 : used by mt2712 etc
> - - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> - bit1 for u3port1, ... etc;
> - - vbus-supply : reference to the VBUS regulator;
> - - usb3-lpm-capable : supports USB3.0 LPM
> - - pinctrl-names : a pinctrl state named "default" must be defined
> - - pinctrl-0 : pin control group
> - See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> - - imod-interval-ns: default interrupt moderation interval is 5000ns
> -
> -additionally the properties from usb-hcd.yaml (in the current directory) are
> -supported.
> -
> -Example:
> -usb30: usb@1127 {
> - compatible = "mediatek,mt8173-xhci";
> - reg = <0 0x1127 0 0x1000>,
> - <0 0x11280700 0 0x0100>;
> - reg-names = "mac", "ippc";
> - interrupts = ;
> - power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
> - <&pericfg CLK_PERI_USB0>,
> - <&pericfg CLK_PERI_USB1>;
> - clock-names = "sys_ck", "ref_ck";
> - phys = <&phy_port0 PHY_TYPE_USB3>,
> -<&phy_port1 PHY_TYPE_USB2>;
> - vusb33-supply = <&mt6397_vusb_reg>;
> - vbus-supply = <&usb_p1_vbus>;
> - usb3-lpm-capable;
> - mediatek,syscon-wakeup = <&pericfg 0x400 1>;
> - wakeup-source;
> - imod-interval-ns = <1>;
> -};
> -
> -2nd: dual-role mode with xHCI driver
> -
> -
> -In the case, xhci is added as subnode to mtu3. An example and the DT binding
> -details of mtu3 can be found in:
> -Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> -
> -Required properties:
> - - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
> - "mediatek,mtk-
Re: [PATCH v3 07/11] dt-bindings: phy: convert MIP DSI PHY binding to YAML schema
On Wed, Nov 18, 2020 at 04:21:22PM +0800, Chunfeng Yun wrote:
> Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
>
> Cc: Chun-Kuang Hu
> Signed-off-by: Chunfeng Yun
> ---
> v3: new patch
> ---
> .../display/mediatek/mediatek,dsi.txt | 18 +---
> .../bindings/phy/mediatek,dsi-phy.yaml| 83 +++
> 2 files changed, 84 insertions(+), 17 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index f06f24d405a5..8238a86686be 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -22,23 +22,7 @@ Required properties:
> MIPI TX Configuration Module
>
>
> -The MIPI TX configuration module controls the MIPI D-PHY.
> -
> -Required properties:
> -- compatible: "mediatek,-mipi-tx"
> -- the supported chips are mt2701, 7623, mt8173 and mt8183.
> -- reg: Physical base address and length of the controller's registers
> -- clocks: PLL reference clock
> -- clock-output-names: name of the output clock line to the DSI encoder
> -- #clock-cells: must be <0>;
> -- #phy-cells: must be <0>.
> -
> -Optional properties:
> -- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
> -the step is 200.
> -- nvmem-cells: A phandle to the calibration data provided by a nvmem device.
> If
> - unspecified default values shall be used.
> -- nvmem-cell-names: Should be "calibration-data"
> +See phy/mediatek,dsi-phy.yaml
>
> Example:
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> new file mode 100644
> index ..87f8df251ab0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
> +
> +maintainers:
> + - Chun-Kuang Hu
> + - Chunfeng Yun
> +
> +description: The MIPI DSI PHY supports up to 4-lane output.
> +
> +properties:
> + $nodename:
> +pattern: "^dsi-phy@[0-9a-f]+$"
> +
> + compatible:
> +enum:
> + - mediatek,mt2701-mipi-tx
> + - mediatek,mt7623-mipi-tx
> + - mediatek,mt8173-mipi-tx
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: PLL reference clock
> +
> + clock-output-names:
> +maxItems: 1
> +
> + "#phy-cells":
> +const: 0
> +
> + "#clock-cells":
> +const: 0
> +
> + nvmem-cells:
> +maxItems: 1
> +description: A phandle to the calibration data provided by a nvmem
> device,
> + if unspecified, default values shall be used.
> +
> + nvmem-cell-names:
> +items:
> + - const: calibration-data
> +
> + drive-strength-microamp:
> +description: adjust driving current, the step is 200.
multipleOf: 200
> +$ref: /schemas/types.yaml#/definitions/uint32
Can drop. Standard unit suffixes have a type already.
> +minimum: 2000
> +maximum: 6000
> +default: 4600
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-output-names
> + - "#phy-cells"
> + - "#clock-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +dsi-phy@10215000 {
> +compatible = "mediatek,mt8173-mipi-tx";
> +reg = <0x10215000 0x1000>;
> +clocks = <&clk26m>;
> +clock-output-names = "mipi_tx0_pll";
> +drive-strength-microamp = <4000>;
> +nvmem-cells= <&mipi_tx_calibration>;
> +nvmem-cell-names = "calibration-data";
> +#clock-cells = <0>;
> +#phy-cells = <0>;
> +};
> +
> +...
> --
> 2.18.0
>
Re: [PATCH v3 04/11] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
On Wed, 18 Nov 2020 16:21:19 +0800, Chunfeng Yun wrote: > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v3: > 1. fix dt_binding_check error in example after add mtu3.yaml > Changes suggested by Rob: > 2. fix wrong indentation > 3. remove '|' due to no formatting to preserve > 4. add a space after '#' > 5. drop unused labels and status in examples > 6. modify file mode > > v2: > 1. modify description and compatible > --- > .../bindings/phy/mediatek,tphy.yaml | 260 ++ > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- > 2 files changed, 260 insertions(+), 162 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt > Reviewed-by: Rob Herring
Re: [PATCH v3 03/11] dt-bindings: phy: convert phy-mtk-xsphy.txt to YAML schema
On Wed, 18 Nov 2020 16:21:18 +0800, Chunfeng Yun wrote: > Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v3: > 1. remove type for property with standard unit suffix suggested by Rob > 2. remove '|' for descritpion > 3. fix yamllint warning > > v2: > 1. modify description and compatible definition suggested by Rob > --- > .../bindings/phy/mediatek,xsphy.yaml | 199 ++ > .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 -- > 2 files changed, 199 insertions(+), 109 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt > Reviewed-by: Rob Herring
Re: [PATCH RFC v2 1/5] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
On Sun, Nov 15, 2020 at 07:52:06PM +0100, Martin Blumenstingl wrote: > Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX > delay register which allows picoseconds precision. Deprecate the old > "amlogic,rx-delay-ns" in favour of a new "amlogic,rgmii-rx-delay-ps" > property. > > For older SoCs the only known supported values were 0ns and 2ns. The new > SoCs have 200ps precision and support RGMII RX delays between 0ps and > 3000ps. > > While here, also update the description of the RX delay to indicate > that: > - with "rgmii" or "rgmii-id" the RX delay should be specified > - with "rgmii-id" or "rgmii-rxid" the RX delay is added by the PHY so > any configuration on the MAC side is ignored > - with "rmii" the RX delay is not applicable and any configuration is > ignored > > Signed-off-by: Martin Blumenstingl > --- > .../bindings/net/amlogic,meson-dwmac.yaml | 61 +-- > 1 file changed, 56 insertions(+), 5 deletions(-) Don't we have common properties for this now? > > diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > index 6b057b117aa0..62a1e92a645c 100644 > --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml > @@ -74,17 +74,68 @@ allOf: > Any configuration is ignored when the phy-mode is set to "rmii". > > amlogic,rx-delay-ns: > + deprecated: true >enum: > - 0 > - 2 >default: 0 > + description: > +The internal RGMII RX clock delay in nanoseconds. Deprecated, use > +amlogic,rgmii-rx-delay-ps instead. > + > +amlogic,rgmii-rx-delay-ps: > + default: 0 >description: > The internal RGMII RX clock delay (provided by this IP block) in > -nanoseconds. When phy-mode is set to "rgmii" then the RX delay > -should be explicitly configured. When the phy-mode is set to > -either "rgmii-id" or "rgmii-rxid" the RX clock delay is already > -provided by the PHY. Any configuration is ignored when the > -phy-mode is set to "rmii". > +picoseconds. When phy-mode is set to "rgmii" or "rgmii-id" then > +the RX delay should be explicitly configured. When the phy-mode > +is set to either "rgmii-id" or "rgmii-rxid" the RX clock delay > +is already provided by the PHY so any configuration here is > +ignored. Also any configuration is ignored when the phy-mode is > +set to "rmii". > + > + - if: > + properties: > +compatible: > + contains: > +enum: > + - amlogic,meson8b-dwmac > + - amlogic,meson8m2-dwmac > + - amlogic,meson-gxbb-dwmac > + - amlogic,meson-axg-dwmac > +then: > + properties: > +amlogic,rgmii-rx-delay-ps: > + enum: > +- 0 > +- 2000 > + > + - if: > + properties: > +compatible: > + contains: > +enum: > + - amlogic,meson-g12a-dwmac > +then: > + properties: > +amlogic,rgmii-rx-delay-ps: > + enum: > +- 0 > +- 200 > +- 400 > +- 600 > +- 800 > +- 1000 > +- 1200 > +- 1400 > +- 1600 > +- 1800 > +- 2000 > +- 2200 > +- 2400 > +- 2600 > +- 2800 > +- 3000 > > properties: >compatible: > -- > 2.29.2 >
Re: [PATCH v9 1/4] dt-bindings: phy: Add sparx5-serdes bindings
On Mon, 07 Dec 2020 13:13:42 +0100, Steen Hegelund wrote: > Document the Sparx5 ethernet serdes phy driver bindings. > > Signed-off-by: Lars Povlsen > Signed-off-by: Steen Hegelund > --- > .../bindings/phy/microchip,sparx5-serdes.yaml | 100 ++ > 1 file changed, 100 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
Re: [PATCH net-next v4 3/4] dt-bindings: dp83td510: Add binding for DP83TD510 Ethernet PHY
On Tue, Nov 17, 2020 at 02:15:54PM -0600, Dan Murphy wrote:
> The DP83TD510 is a 10M single twisted pair Ethernet PHY
>
> Signed-off-by: Dan Murphy
> ---
> .../devicetree/bindings/net/ti,dp83td510.yaml | 64 +++
> 1 file changed, 64 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,dp83td510.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/ti,dp83td510.yaml
> b/Documentation/devicetree/bindings/net/ti,dp83td510.yaml
> new file mode 100644
> index ..d3c97bb4d820
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,dp83td510.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/net/ti,dp83td510.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: TI DP83TD510 ethernet PHY
> +
> +allOf:
> + - $ref: "ethernet-controller.yaml#"
> + - $ref: "ethernet-phy.yaml#"
> +
> +maintainers:
> + - Dan Murphy
> +
> +description: |
> + The PHY is an twisted pair 10Mbps Ethernet PHY that support MII, RMII and
> + RGMII interfaces.
> +
> + Specifications about the Ethernet PHY can be found at:
> +http://www.ti.com/lit/ds/symlink/dp83td510e.pdf
> +
> +properties:
> + reg:
> +maxItems: 1
> +
> + tx-fifo-depth:
> +description: |
> + Transmitt FIFO depth for RMII mode. The PHY only exposes 4 nibble
> + depths. The valid nibble depths are 4, 5, 6 and 8.
> +enum: [ 4, 5, 6, 8 ]
> +default: 5
> +
> + rx-internal-delay-ps:
> +description: |
> + Setting this property to a non-zero number sets the RX internal delay
> + for the PHY. The internal delay for the PHY is fixed to 30ns relative
> + to receive data.
I'm confused. The delay is 30ns +/- whatever is set here?
> +
> + tx-internal-delay-ps:
> +description: |
> + Setting this property to a non-zero number sets the TX internal delay
> + for the PHY. The internal delay for the PHY has a range of -4 to 4ns
> + relative to transmit data.
Sounds like constraints?
We do have a problem handling negative values though. Addressing in dtc
was rejected, so we'll need to fixup the schema with unsigned values.
But here it should just be negative values.
> +
> +unevaluatedProperties: false
> +
> +required:
> + - reg
> +
> +examples:
> + - |
> +mdio0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy0: ethernet-phy@0 {
> +reg = <0>;
> +tx-rx-output-high;
> +tx-fifo-depth = <5>;
> +rx-internal-delay-ps = <1>;
> +tx-internal-delay-ps = <1>;
> + };
> +};
> --
> 2.29.2
>
Re: [PATCH net-next v4 2/4] dt-bindings: net: Add Rx/Tx output configuration for 10base T1L
On Tue, Nov 17, 2020 at 02:15:53PM -0600, Dan Murphy wrote: > Per the 802.3cg spec the 10base T1L can operate at 2 different > differential voltages 1v p2p and 2.4v p2p. The abiility of the PHY to 1.1V? > drive that output is dependent on the PHY's on board power supply. > This common feature is applicable to all 10base T1L PHYs so this binding > property belongs in a top level ethernet document. > > Signed-off-by: Dan Murphy > --- > Documentation/devicetree/bindings/net/ethernet-phy.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml > b/Documentation/devicetree/bindings/net/ethernet-phy.yaml > index 6dd72faebd89..bda1ce51836b 100644 > --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml > +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml > @@ -174,6 +174,12 @@ properties: >PHY's that have configurable TX internal delays. If this property is >present then the PHY applies the TX delay. > > + max-tx-rx-p2p-microvolt: > +description: | Don't need '|' if no formatting. > + Configures the Tx/Rx p2p differential output voltage for 10base-T1L > PHYs. > +enum: [ 1100, 2400 ] > +default: 2400 Aren't you off by 1000? > + > required: >- reg > > -- > 2.29.2 >
