| Message ID | 20171012152450.12454-1-jbrunet@baylibre.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Jerome, On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: > The meson efuse driver seems to be compatible with more SoCs than > initially thought. Let's use the most generic compatible he have in > DT instead of the gxbb specific one > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > --- > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- > drivers/nvmem/meson-efuse.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > index fafd85bd67a6..0260524292fe 100644 > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > @@ -1,7 +1,7 @@ > = Amlogic eFuse device tree bindings = > > Required properties: > -- compatible: should be "amlogic,meson-gxbb-efuse" > +- compatible: should be "amlogic,meson-gx-efuse" have you checked with the devicetree maintainers how they want the documentation to look like in this case? (I don't know if the old one should be kept instead of removing it) > > = Data cells = > Are child nodes of eFuse, bindings of which as described in > @@ -10,7 +10,7 @@ bindings/nvmem/nvmem.txt > Example: > > efuse: efuse { > - compatible = "amlogic,meson-gxbb-efuse"; > + compatible = "amlogic,meson-gx-efuse"; > #address-cells = <1>; > #size-cells = <1>; > > diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c > index 70bfc9839bb2..e90c6d68a263 100644 > --- a/drivers/nvmem/meson-efuse.c > +++ b/drivers/nvmem/meson-efuse.c > @@ -44,7 +44,7 @@ static struct nvmem_config econfig = { > }; > > static const struct of_device_id meson_efuse_match[] = { > - { .compatible = "amlogic,meson-gxbb-efuse", }, > + { .compatible = "amlogic,meson-gx-efuse", }, > { /* sentinel */ }, > }; > MODULE_DEVICE_TABLE(of, meson_efuse_match); > -- > 2.13.6 > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic
On Fri, 2017-10-13 at 21:14 +0200, Martin Blumenstingl wrote: > Hi Jerome, > > On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: > > The meson efuse driver seems to be compatible with more SoCs than > > initially thought. Let's use the most generic compatible he have in > > DT instead of the gxbb specific one > > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > > --- > > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- > > drivers/nvmem/meson-efuse.c | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > index fafd85bd67a6..0260524292fe 100644 > > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > @@ -1,7 +1,7 @@ > > = Amlogic eFuse device tree bindings = > > > > Required properties: > > -- compatible: should be "amlogic,meson-gxbb-efuse" > > +- compatible: should be "amlogic,meson-gx-efuse" > > have you checked with the devicetree maintainers how they want the > documentation to look like in this case? You mean "Should we put every compatible existing (in DT) in the documentation" From what I've seen, at least in meson drivers, only the matched ones are listed. That's a good question though. We tend to put soc specific compatible "in case" we need them later on. Should we document those ? > (I don't know if the old one should be kept instead of removing it) > > > > > = Data cells = > > Are child nodes of eFuse, bindings of which as described in > > @@ -10,7 +10,7 @@ bindings/nvmem/nvmem.txt > > Example: > > > > efuse: efuse { > > - compatible = "amlogic,meson-gxbb-efuse"; > > + compatible = "amlogic,meson-gx-efuse"; > > #address-cells = <1>; > > #size-cells = <1>; > > > > diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c > > index 70bfc9839bb2..e90c6d68a263 100644 > > --- a/drivers/nvmem/meson-efuse.c > > +++ b/drivers/nvmem/meson-efuse.c > > @@ -44,7 +44,7 @@ static struct nvmem_config econfig = { > > }; > > > > static const struct of_device_id meson_efuse_match[] = { > > - { .compatible = "amlogic,meson-gxbb-efuse", }, > > + { .compatible = "amlogic,meson-gx-efuse", }, > > { /* sentinel */ }, > > }; > > MODULE_DEVICE_TABLE(of, meson_efuse_match); > > -- > > 2.13.6 > > > > > > _______________________________________________ > > linux-amlogic mailing list > > linux-amlogic@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-amlogic
On Fri, Oct 13, 2017 at 09:39:13PM +0200, Jerome Brunet wrote: > On Fri, 2017-10-13 at 21:14 +0200, Martin Blumenstingl wrote: > > Hi Jerome, > > > > On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com> wrote: > > > The meson efuse driver seems to be compatible with more SoCs than > > > initially thought. Let's use the most generic compatible he have in > > > DT instead of the gxbb specific one > > > > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > > > --- > > > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- > > > drivers/nvmem/meson-efuse.c | 2 +- > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > index fafd85bd67a6..0260524292fe 100644 > > > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > @@ -1,7 +1,7 @@ > > > = Amlogic eFuse device tree bindings = > > > > > > Required properties: > > > -- compatible: should be "amlogic,meson-gxbb-efuse" > > > +- compatible: should be "amlogic,meson-gx-efuse" Same comment as for the firmware. > > > > have you checked with the devicetree maintainers how they want the > > documentation to look like in this case? > > You mean "Should we put every compatible existing (in DT) in the documentation" > From what I've seen, at least in meson drivers, only the matched ones are > listed. > > That's a good question though. > We tend to put soc specific compatible "in case" we need them later on. Should > we document those ? Absolutely. Rob
On Tue, 2017-10-17 at 15:52 -0500, Rob Herring wrote: > On Fri, Oct 13, 2017 at 09:39:13PM +0200, Jerome Brunet wrote: > > On Fri, 2017-10-13 at 21:14 +0200, Martin Blumenstingl wrote: > > > Hi Jerome, > > > > > > On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com> > > > wrote: > > > > The meson efuse driver seems to be compatible with more SoCs than > > > > initially thought. Let's use the most generic compatible he have in > > > > DT instead of the gxbb specific one > > > > > > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > > > > --- > > > > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- > > > > drivers/nvmem/meson-efuse.c | 2 +- > > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > index fafd85bd67a6..0260524292fe 100644 > > > > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > @@ -1,7 +1,7 @@ > > > > = Amlogic eFuse device tree bindings = > > > > > > > > Required properties: > > > > -- compatible: should be "amlogic,meson-gxbb-efuse" > > > > +- compatible: should be "amlogic,meson-gx-efuse" > > Same comment as for the firmware. > > > > > > > have you checked with the devicetree maintainers how they want the > > > documentation to look like in this case? > > > > You mean "Should we put every compatible existing (in DT) in the > > documentation" > > From what I've seen, at least in meson drivers, only the matched ones are > > listed. > > > > That's a good question though. > > We tend to put soc specific compatible "in case" we need them later on. > > Should > > we document those ? > > Absolutely. My understanding is that this documentation is the documentation of the bindings used by the driver. If I understand your point, we should document bindings (compatible in that case) that are in fact not fact by the driver. This means that if someone refer only to the documentation, he might be surprised by the result. > > Rob
On Wed, Oct 18, 2017 at 2:31 AM, Jerome Brunet <jbrunet@baylibre.com> wrote: > On Tue, 2017-10-17 at 15:52 -0500, Rob Herring wrote: >> On Fri, Oct 13, 2017 at 09:39:13PM +0200, Jerome Brunet wrote: >> > On Fri, 2017-10-13 at 21:14 +0200, Martin Blumenstingl wrote: >> > > Hi Jerome, >> > > >> > > On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com> >> > > wrote: >> > > > The meson efuse driver seems to be compatible with more SoCs than >> > > > initially thought. Let's use the most generic compatible he have in >> > > > DT instead of the gxbb specific one >> > > > >> > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> >> > > > --- >> > > > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- >> > > > drivers/nvmem/meson-efuse.c | 2 +- >> > > > 2 files changed, 3 insertions(+), 3 deletions(-) >> > > > >> > > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt >> > > > b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt >> > > > index fafd85bd67a6..0260524292fe 100644 >> > > > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt >> > > > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt >> > > > @@ -1,7 +1,7 @@ >> > > > = Amlogic eFuse device tree bindings = >> > > > >> > > > Required properties: >> > > > -- compatible: should be "amlogic,meson-gxbb-efuse" >> > > > +- compatible: should be "amlogic,meson-gx-efuse" >> >> Same comment as for the firmware. >> >> > > >> > > have you checked with the devicetree maintainers how they want the >> > > documentation to look like in this case? >> > >> > You mean "Should we put every compatible existing (in DT) in the >> > documentation" >> > From what I've seen, at least in meson drivers, only the matched ones are >> > listed. >> > >> > That's a good question though. >> > We tend to put soc specific compatible "in case" we need them later on. >> > Should >> > we document those ? >> >> Absolutely. > > My understanding is that this documentation is the documentation of the bindings > used by the driver. No, the binding doc should be sufficient to validate the dts. > If I understand your point, we should document bindings (compatible in that > case) that are in fact not fact by the driver. This means that if someone refer > only to the documentation, he might be surprised by the result. How so? Rob
On Thu, 2017-10-19 at 16:10 -0500, Rob Herring wrote: > On Wed, Oct 18, 2017 at 2:31 AM, Jerome Brunet <jbrunet@baylibre.com> wrote: > > On Tue, 2017-10-17 at 15:52 -0500, Rob Herring wrote: > > > On Fri, Oct 13, 2017 at 09:39:13PM +0200, Jerome Brunet wrote: > > > > On Fri, 2017-10-13 at 21:14 +0200, Martin Blumenstingl wrote: > > > > > Hi Jerome, > > > > > > > > > > On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com> > > > > > wrote: > > > > > > The meson efuse driver seems to be compatible with more SoCs than > > > > > > initially thought. Let's use the most generic compatible he have in > > > > > > DT instead of the gxbb specific one > > > > > > > > > > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > > > > > > --- > > > > > > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- > > > > > > drivers/nvmem/meson-efuse.c | 2 +- > > > > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic- > > > > > > efuse.txt > > > > > > b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > > > index fafd85bd67a6..0260524292fe 100644 > > > > > > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > > > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt > > > > > > @@ -1,7 +1,7 @@ > > > > > > = Amlogic eFuse device tree bindings = > > > > > > > > > > > > Required properties: > > > > > > -- compatible: should be "amlogic,meson-gxbb-efuse" > > > > > > +- compatible: should be "amlogic,meson-gx-efuse" > > > > > > Same comment as for the firmware. > > > > > > > > > > > > > have you checked with the devicetree maintainers how they want the > > > > > documentation to look like in this case? > > > > > > > > You mean "Should we put every compatible existing (in DT) in the > > > > documentation" > > > > From what I've seen, at least in meson drivers, only the matched ones > > > > are > > > > listed. > > > > > > > > That's a good question though. > > > > We tend to put soc specific compatible "in case" we need them later on. > > > > Should > > > > we document those ? > > > > > > Absolutely. > > > > My understanding is that this documentation is the documentation of the > > bindings > > used by the driver. > > No, the binding doc should be sufficient to validate the dts. > > > If I understand your point, we should document bindings (compatible in that > > case) that are in fact not fact by the driver. This means that if someone > > refer > > only to the documentation, he might be surprised by the result. > > How so? Compatible not matched. If the compatible is documented, I would expect "a driver" to match on it If we document every compatible used in DTS, some won't be matched. IMO, the current way (document the driver - the matched bindings) is easier and more predictable. > > Rob
diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt index fafd85bd67a6..0260524292fe 100644 --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt @@ -1,7 +1,7 @@ = Amlogic eFuse device tree bindings = Required properties: -- compatible: should be "amlogic,meson-gxbb-efuse" +- compatible: should be "amlogic,meson-gx-efuse" = Data cells = Are child nodes of eFuse, bindings of which as described in @@ -10,7 +10,7 @@ bindings/nvmem/nvmem.txt Example: efuse: efuse { - compatible = "amlogic,meson-gxbb-efuse"; + compatible = "amlogic,meson-gx-efuse"; #address-cells = <1>; #size-cells = <1>; diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c index 70bfc9839bb2..e90c6d68a263 100644 --- a/drivers/nvmem/meson-efuse.c +++ b/drivers/nvmem/meson-efuse.c @@ -44,7 +44,7 @@ static struct nvmem_config econfig = { }; static const struct of_device_id meson_efuse_match[] = { - { .compatible = "amlogic,meson-gxbb-efuse", }, + { .compatible = "amlogic,meson-gx-efuse", }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, meson_efuse_match);
The meson efuse driver seems to be compatible with more SoCs than initially thought. Let's use the most generic compatible he have in DT instead of the gxbb specific one Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> --- Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++-- drivers/nvmem/meson-efuse.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)