| Message ID | 1450270975-17955-1-git-send-email-mans@mansr.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
Mark, This is the 1/1 you were missing. Am I the only one who is annoyed by scripts/get_maintainer.pl not returning all the addresses it should in cases like this? Is there some trick I'm missing? Mans Rullgard <mans@mansr.com> writes: > This adds a binding for the Wolfson WM8974 mono audio codec. > > Signed-off-by: Mans Rullgard <mans@mansr.com> > --- > The Linux driver for this device currently only supports I2C, but SPI > could easily be added if necessary, and DT bindings are supposed to be > generic. > --- > Documentation/devicetree/bindings/sound/wlf,wm8974.txt | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt > > diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt > new file mode 100644 > index 0000000..01d3a7c > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt > @@ -0,0 +1,15 @@ > +WM8974 audio CODEC > + > +This device supports both I2C and SPI (configured with pin strapping > +on the board). > + > +Required properties: > + - compatible: "wlf,wm8974" > + - reg: the I2C address or SPI chip select number of the device > + > +Examples: > + > +codec: wm8974@1a { > + compatible = "wlf,wm8974"; > + reg = <0x1a>; > +}; > -- > 2.6.3 >
On Wed, Dec 16, 2015 at 01:31:30PM +0000, Måns Rullgård wrote: > This is the 1/1 you were missing. I need the patch in a form I can apply. > Am I the only one who is annoyed by scripts/get_maintainer.pl not > returning all the addresses it should in cases like this? Is there some > trick I'm missing? You can't blindly rely on get_maintainers, it's prone to both false positives (CCing too many people, especially if you enable git matching when it often starts spamming people who are just doing global cleanups) and false negatives (if you don't enable git matching and it misses people who care about a specific driver).
Mark Brown <broonie@kernel.org> writes: > On Wed, Dec 16, 2015 at 01:31:30PM +0000, Måns Rullgård wrote: > >> This is the 1/1 you were missing. > > I need the patch in a form I can apply. I assumed your email client had some way of displaying the message I replied to. Guess I was wrong. >> Am I the only one who is annoyed by scripts/get_maintainer.pl not >> returning all the addresses it should in cases like this? Is there some >> trick I'm missing? > > You can't blindly rely on get_maintainers, it's prone to both false > positives (CCing too many people, especially if you enable git matching > when it often starts spamming people who are just doing global cleanups) > and false negatives (if you don't enable git matching and it misses > people who care about a specific driver). So in short, I'm supposed to magically divine who wants to see what.
On Wed, Dec 16, 2015 at 01:54:20PM +0000, Måns Rullgård wrote: > Mark Brown <broonie@kernel.org> writes: > > I need the patch in a form I can apply. > I assumed your email client had some way of displaying the message I > replied to. Guess I was wrong. My workflow for reviewing and applying patches is based around my inbox, as are most review flows in the kernel - things that aren't in my inbox *might* get looked at but it's unreliable. > > You can't blindly rely on get_maintainers, it's prone to both false > > positives (CCing too many people, especially if you enable git matching > > when it often starts spamming people who are just doing global cleanups) > > and false negatives (if you don't enable git matching and it misses > > people who care about a specific driver). > So in short, I'm supposed to magically divine who wants to see what. You're supposed to do like SubmittingPatches suggests make a judgement call based on things like looking at MAINTAINERS and the people that git shows are reviewing and applying patches or otherwise seem relevant - it's not really something that can be fully automated (for example, it might make sense to CC someone who worked on the specific thing you're changing even if they don't commonly review the file as a whole). Looking at git history will also help you ensure that the style you're presenting your changes in (for example things like the subject line) matches the general style people are using.
On Wed, Dec 16, 2015 at 01:31:30PM +0000, Måns Rullgård wrote: > Mark, > > This is the 1/1 you were missing. > > Am I the only one who is annoyed by scripts/get_maintainer.pl not > returning all the addresses it should in cases like this? Is there some > trick I'm missing? Documentation/devicetree/bindings/sound/ should probably be listed with the ALSA maintainer entry. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt new file mode 100644 index 0000000..01d3a7c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt @@ -0,0 +1,15 @@ +WM8974 audio CODEC + +This device supports both I2C and SPI (configured with pin strapping +on the board). + +Required properties: + - compatible: "wlf,wm8974" + - reg: the I2C address or SPI chip select number of the device + +Examples: + +codec: wm8974@1a { + compatible = "wlf,wm8974"; + reg = <0x1a>; +};
This adds a binding for the Wolfson WM8974 mono audio codec. Signed-off-by: Mans Rullgard <mans@mansr.com> --- The Linux driver for this device currently only supports I2C, but SPI could easily be added if necessary, and DT bindings are supposed to be generic. --- Documentation/devicetree/bindings/sound/wlf,wm8974.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt