On 7/13/20 7:01 PM, Rob Herring wrote: > On Wed, Jul 01, 2020 at 03:25:19PM +0200, Benjamin Gaignard wrote: >> Add schemas for firewall consumer and provider. >> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@xxxxxx> >> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> >> --- >> .../bindings/bus/stm32/firewall-consumer.yaml | 36 ++++++++++++++++++++++ >> .../bindings/bus/stm32/firewall-provider.yaml | 18 +++++++++++ >> 2 files changed, 54 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml >> create mode 100644 Documentation/devicetree/bindings/bus/stm32/firewall-provider.yaml >> >> diff --git a/Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml b/Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml >> new file mode 100644 >> index 000000000000..d3d76f99b38d >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/bus/stm32/firewall-consumer.yaml >> @@ -0,0 +1,36 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/bus/stm32/firewall-consumer.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Common Bus Firewall consumer binding > I'm all for common bindings, but I want to see more than 1 user before > accepting this. There's been some other postings for similar h/w > (AFAICT) recently. > >> + >> +description: | >> + Firewall properties provide the possible firewall bus controller >> + configurations for a device. >> + Bus firewall controllers are typically used to control if a hardware >> + block can perform read or write operations on bus. >> + The contents of the firewall bus configuration properties are defined by >> + the binding for the individual firewall controller device. >> + >> + The first configuration 'firewall-0' or the one named 'default' is >> + applied before probing the device itself. > This is a Linux implementation detail and debatable whether the core > should do this or drivers. I could prefix the property with 'st,stm32' so it will dedicated to STM32 SoCs. Will it sound better for you ? From Greg comments in the previous versions of this patch I understand that it isn't something to be done in the core. The best I can do here is to keep it as helpers for STM32 SoCs. > >> + >> +maintainers: >> + - Benjamin Gaignard <benjamin.gaignard@xxxxxx> >> + >> +# always select the core schema >> +select: true >> + >> +properties: >> + firewall-0: true >> + >> + firewall-names: true >> + >> +patternProperties: >> + "firewall-[0-9]": >> + $ref: "/schemas/types.yaml#/definitions/phandle-array" > So I guess multiple properties is to encode all the modes into DT like > pinctrl does. Is that really necessary? I don't think so as I wouldn't > expect modes to be defined by the consumer, but by the provider in this > case. To use pinctrl as a example, we could have pad setting per MMC > speed. That has to be in the consumer side as the pinctrl knows nothing > about MMC. I expect to be able to set phandle on different firewall controllers. I don't know if it is possible with the same structure than for pins controllers. > > Rob
