Hi,

A question:

Several of the bindings here had only one
maintainer and history does not always point to a new one (although I did not
perform extensive digging). I added subsystem maintainer, because dtschema
requires such entry. This is not the best choice as simply subsystem maintainer
might not have the actual device (or its datasheets or any interest in it).

However dtschema requires a maintainer. Maybe we could add some
"orphaned" entry in such case?

Best regards,
Krzysztof

Krzysztof Kozlowski (5):
  dt-bindings: iio: Drop Joachim Eastwood
  dt-bindings: iio: Drop Bogdan Pricop
  dt-bindings: Drop Beniamin Bia and Stefan Popa
  dt-bindings: Drop Robert Jones
  dt-bindings: Drop Dan Murphy

 Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml       | 1 -
 Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml   | 1 -
 Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml    | 2 +-
 Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml      | 3 +--
 Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml | 2 +-
 Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml   | 2 +-
 Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml    | 2 +-
 .../devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml        | 1 -
 Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml    | 2 +-
 .../devicetree/bindings/leds/leds-class-multicolor.yaml        | 2 +-
 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml        | 2 +-
 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml       | 1 -
 Documentation/devicetree/bindings/net/ti,dp83822.yaml          | 2 +-
 Documentation/devicetree/bindings/net/ti,dp83867.yaml          | 2 +-
 Documentation/devicetree/bindings/net/ti,dp83869.yaml          | 2 +-
 Documentation/devicetree/bindings/power/supply/bq2515x.yaml    | 1 -
 Documentation/devicetree/bindings/power/supply/bq25980.yaml    | 1 -
 Documentation/devicetree/bindings/sound/tas2562.yaml           | 2 +-
 Documentation/devicetree/bindings/sound/tlv320adcx140.yaml     | 2 +-
 19 files changed, 13 insertions(+), 20 deletions(-)

-- 
2.34.1

On Mon,  8 Aug 2022 13:47:07 +0300 Krzysztof Kozlowski wrote:
> Several of the bindings here had only one
> maintainer and history does not always point to a new one (although I did not
> perform extensive digging). I added subsystem maintainer, because dtschema
> requires such entry. This is not the best choice as simply subsystem maintainer
> might not have the actual device (or its datasheets or any interest in it).
> 
> However dtschema requires a maintainer. Maybe we could add some
> "orphaned" entry in such case?

Integrating it with MAINTAINERS would be another option worth exploring
although slightly tangential.

How do you want this merged? It's all over the place subsystem-wise.

On 08/08/2022 21:52, Jakub Kicinski wrote:
> On Mon,  8 Aug 2022 13:47:07 +0300 Krzysztof Kozlowski wrote:
>> Several of the bindings here had only one
>> maintainer and history does not always point to a new one (although I did not
>> perform extensive digging). I added subsystem maintainer, because dtschema
>> requires such entry. This is not the best choice as simply subsystem maintainer
>> might not have the actual device (or its datasheets or any interest in it).
>>
>> However dtschema requires a maintainer. Maybe we could add some
>> "orphaned" entry in such case?
> 
> Integrating it with MAINTAINERS would be another option worth exploring
> although slightly tangential.
> 
> How do you want this merged? It's all over the place subsystem-wise.

I was thinking this could go via Rob's tree as fixes for current cycle,
so your Ack would be great. If there is preference, I can split it per
subsystem, but for such trivial updates it's a bit of a churn.


Best regards,
Krzysztof

On Tue, 9 Aug 2022 08:25:29 +0300 Krzysztof Kozlowski wrote:
> On 08/08/2022 21:52, Jakub Kicinski wrote:
> > Integrating it with MAINTAINERS would be another option worth exploring
> > although slightly tangential.
> > 
> > How do you want this merged? It's all over the place subsystem-wise.  
> 
> I was thinking this could go via Rob's tree as fixes for current cycle,
> so your Ack would be great

Sounds good!