[PATCH v2 00/11] Add Mobileye EyeQ5 support to the Nomadik I2C controller & use hrtimers for timeouts

[PATCH v2 00/11] Add Mobileye EyeQ5 support to the Nomadik I2C controller & use hrtimers for timeouts

[Théo Lebrun]

Hi,

This series adds two tangent features to the Nomadik I2C controller:

 - Add a new compatible to support Mobileye EyeQ5 which uses the same IP
   block as Nomadik.

   It has two quirks to be handled:
    - The memory bus only supports 32-bit accesses. Avoid readb() and
      writeb() calls that might generate byte load/store instructions.
    - We must write a value into a shared register region (OLB)
      depending on the I2C bus speed.

 - Allow xfer timeouts below one jiffy by using a waitqueue and hrtimers
   instead of a completion.

   The situation to be addressed is:
    - Many devices on the same I2C bus.
    - One xfer to each device is sent at regular interval.
    - One device gets stuck and does not answer.
    - With long timeouts, following devices won't get their message. A
      shorter timeout ensures we can still talk to the following
      devices.

   This clashes a bit with the current i2c_adapter timeout field that
   stores a jiffies amount. We therefore avoid it and store the value
   in a private struct field, as a µs amount. If the timeout is less
   than a jiffy duration, we switch from standard jiffies timeout to
   hrtimers.

There is one patch targeting a hwmon dt-bindings file:
Documentation/devicetree/bindings/hwmon/lm75.yaml. The rest is touching
the I2C bus driver, its bindings and platform devicetrees.

About dependencies:
 - The series is based upon v6.8-rc6.
 - For testing on EyeQ5 hardware and devicetree patches, we need the
   base platform series from Grégory [0] and its dependency [1]. Both
   in mips-next [2].
 - Devicetree commits require the EyeQ5 syscon series [3] that provides
   the reset controller node.
 - The LM75 dt-bindings patch depends on the common schema
   hwmon-common.yaml series from Krzysztof [4]. Found in hwmon-next [5].

Have a nice day,
Théo Lebrun

[0]: https://lore.kernel.org/lkml/20240216174227.409400-1-gregory.clement@bootlin.com/
[1]: https://lore.kernel.org/linux-mips/20240209-regname-v1-0-2125efa016ef@flygoat.com/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/log/
[3]: https://lore.kernel.org/lkml/20240227-mbly-clk-v8-0-c57fbda7664a@bootlin.com/
[4]: https://lore.kernel.org/lkml/20240224-dt-bindings-hwmon-common-v2-0-b446eecf5480@linaro.org/
[5]: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git/log/?h=hwmon-next

To: Linus Walleij <linus.walleij@linaro.org>
To: Andi Shyti <andi.shyti@kernel.org>
To: Rob Herring <robh+dt@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <linux-i2c@vger.kernel.org>
Cc: <devicetree@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: <linux-mips@vger.kernel.org>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Tawfik Bayouk <tawfik.bayouk@mobileye.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>

Changes in v2:
- dt-bindings: i2c: st,nomadic-i2c:
  - Drop timeout-usecs property, rely on generic i2c-transfer-timeout-us.
  - Use phandle to syscon with cell args; remove mobileye,id prop; move
    mobileye,olb from if-statement to top-level.
- dt-bindings: hwmon: lm75:
  - Inherit from hwmon-common.yaml rather than declare generic label property.
- i2c: nomadik: (ie driver code)
  - Parse i2c-transfer-timeout-us rather than custom timeout-usecs property.
  - Introduce readb/writeb helpers with fallback to readl/writel.
  - Avoid readb() on Mobileye.
  - Use mobileye,olb cell args to get controller index rather than mobileye,id.
  - Take 5 Reviewed-by Linus Walleij.
- MIPS: mobileye: (ie devicetrees)
  - Use mobileye,olb with cell args rather than mobileye,id.
  - Squash reset commit.
  - Add i2c-transfer-timeout-us value of 10ms to all controllers.
  - Rename LM75 instance from tmp112@48 to temperature-sensor@48.
- Link to v1: https://lore.kernel.org/r/20240215-mbly-i2c-v1-0-19a336e91dca@bootlin.com

---
Théo Lebrun (11):
      dt-bindings: i2c: nomadik: add mobileye,eyeq5-i2c bindings and example
      dt-bindings: hwmon: lm75: use common hwmon schema
      i2c: nomadik: rename private struct pointers from dev to priv
      i2c: nomadik: simplify IRQ masking logic
      i2c: nomadik: use bitops helpers
      i2c: nomadik: support short xfer timeouts using waitqueue & hrtimer
      i2c: nomadik: replace jiffies by ktime for FIFO flushing timeout
      i2c: nomadik: fetch i2c-transfer-timeout-us property from devicetree
      i2c: nomadik: support Mobileye EyeQ5 I2C controller
      MIPS: mobileye: eyeq5: add 5 I2C controller nodes
      MIPS: mobileye: eyeq5: add evaluation board I2C temp sensor

 Documentation/devicetree/bindings/hwmon/lm75.yaml  |   3 +-
 .../devicetree/bindings/i2c/st,nomadik-i2c.yaml    |  48 +-
 arch/mips/boot/dts/mobileye/eyeq5-epm5.dts         |   8 +
 arch/mips/boot/dts/mobileye/eyeq5.dtsi             |  75 +++
 drivers/i2c/busses/i2c-nomadik.c                   | 720 ++++++++++++---------
 5 files changed, 541 insertions(+), 313 deletions(-)
---
base-commit: a6cc37d1a531e1c99e7989001a0529b443397900
change-id: 20231023-mbly-i2c-7c2fbbb1299f

Best regards,
-- 
Théo Lebrun <theo.lebrun@bootlin.com>

[PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Théo Lebrun]

Reference common hwmon schema which has the generic "label" property,
parsed by Linux hwmon subsystem.

To: Jean Delvare <jdelvare@suse.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
 Documentation/devicetree/bindings/hwmon/lm75.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index ed269e428a3d..29bd7460cc26 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -57,6 +57,7 @@ required:
   - reg
 
 allOf:
+  - $ref: hwmon-common.yaml#
   - if:
       not:
         properties:
@@ -71,7 +72,7 @@ allOf:
       properties:
         interrupts: false
 
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |

-- 
2.44.0

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Rob Herring]

On Thu, 29 Feb 2024 19:10:50 +0100, Théo Lebrun wrote:
> Reference common hwmon schema which has the generic "label" property,
> parsed by Linux hwmon subsystem.
> 
> To: Jean Delvare <jdelvare@suse.com>
> To: Guenter Roeck <linux@roeck-us.net>
> Cc: linux-hwmon@vger.kernel.org
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
>  Documentation/devicetree/bindings/hwmon/lm75.yaml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

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/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/lm75.yaml:
Error in referenced schema matching $id: http://devicetree.org/schemas/hwmon/hwmon-common.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/lm75.example.dtb: sensor@48: False schema does not allow {'compatible': ['st,stlm75'], 'reg': [[72]], 'vs-supply': [[4294967295]], '$nodename': ['sensor@48']}
	from schema $id: http://devicetree.org/schemas/hwmon/lm75.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/lm75.example.dtb: temperature-sensor@48: False schema does not allow {'compatible': ['ams,as6200'], 'reg': [[72]], 'vs-supply': [[4294967295]], 'interrupts': [[17, 3]], '$nodename': ['temperature-sensor@48']}
	from schema $id: http://devicetree.org/schemas/hwmon/lm75.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240229-mbly-i2c-v2-2-b32ed18c098c@bootlin.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

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 after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Krzysztof Kozlowski]

On 29/02/2024 19:10, Théo Lebrun wrote:
> Reference common hwmon schema which has the generic "label" property,
> parsed by Linux hwmon subsystem.
> 

Please do not mix independent patchsets. You create unneeded
dependencies blocking this patch. This patch depends on hwmon work, so
it cannot go through different tree.

If you insist to combine independent patches, then at least clearly
express merging strategy or dependency in patch changelog --- .


> To: Jean Delvare <jdelvare@suse.com>
> To: Guenter Roeck <linux@roeck-us.net>
> Cc: linux-hwmon@vger.kernel.org
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Guenter Roeck]

On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> On 29/02/2024 19:10, Théo Lebrun wrote:
>> Reference common hwmon schema which has the generic "label" property,
>> parsed by Linux hwmon subsystem.
>>
> 
> Please do not mix independent patchsets. You create unneeded
> dependencies blocking this patch. This patch depends on hwmon work, so
> it cannot go through different tree.
> 
> If you insist to combine independent patches, then at least clearly
> express merging strategy or dependency in patch changelog --- .
> 

For my part I have to say that I don't know what to do with it.
Rob's robot reported errors, so I won't apply it, and I don't
feel comfortable giving it an ack either because of those errors.

Guenter

> 
>> To: Jean Delvare <jdelvare@suse.com>
>> To: Guenter Roeck <linux@roeck-us.net>
>> Cc: linux-hwmon@vger.kernel.org
>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>> ---
> 
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Théo Lebrun]

Hello,

On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > On 29/02/2024 19:10, Théo Lebrun wrote:
> >> Reference common hwmon schema which has the generic "label" property,
> >> parsed by Linux hwmon subsystem.
> >>
> > 
> > Please do not mix independent patchsets. You create unneeded
> > dependencies blocking this patch. This patch depends on hwmon work, so
> > it cannot go through different tree.

I had to pick between this or dtbs_check failing on my DTS that uses a
label on temperature-sensor@48.

> > If you insist to combine independent patches, then at least clearly
> > express merging strategy or dependency in patch changelog --- .

I do not know how such indirect conflicts are usually resolved. Hwmon
can take it but MIPS might want to also take it to have valid DTS.

Any advice?

> For my part I have to say that I don't know what to do with it.
> Rob's robot reported errors, so I won't apply it, and I don't
> feel comfortable giving it an ack either because of those errors.

Can reproduce the error when patch "dt-bindings: hwmon: add common
properties" is not applied. Cannot reproduce when patch is applied.
Commit d590900b62f0 on hwmon-next. Cannot reproduce with hwmon-next as
parent.

Regards,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Krzysztof Kozlowski]

On 01/03/2024 10:41, Théo Lebrun wrote:
> Hello,
> 
> On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
>> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
>>> On 29/02/2024 19:10, Théo Lebrun wrote:
>>>> Reference common hwmon schema which has the generic "label" property,
>>>> parsed by Linux hwmon subsystem.
>>>>
>>>
>>> Please do not mix independent patchsets. You create unneeded
>>> dependencies blocking this patch. This patch depends on hwmon work, so
>>> it cannot go through different tree.
> 
> I had to pick between this or dtbs_check failing on my DTS that uses a
> label on temperature-sensor@48.

I don't see how is that relevant. You can organize your branches as you
wish, e.g. base one b4 branch on another and you will not have any warnings.

> 
>>> If you insist to combine independent patches, then at least clearly
>>> express merging strategy or dependency in patch changelog --- .
> 
> I do not know how such indirect conflicts are usually resolved. Hwmon
> can take it but MIPS might want to also take it to have valid DTS.
> 
> Any advice?

I don't see any conflict.


> 
>> For my part I have to say that I don't know what to do with it.
>> Rob's robot reported errors, so I won't apply it, and I don't
>> feel comfortable giving it an ack either because of those errors.
> 
> Can reproduce the error when patch "dt-bindings: hwmon: add common
> properties" is not applied. Cannot reproduce when patch is applied.
> Commit d590900b62f0 on hwmon-next. Cannot reproduce with hwmon-next as
> parent.

Yeah, but we see the error reported and it means something is missing.

Best regards,
Krzysztof

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Théo Lebrun]

Hello,

On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> On 01/03/2024 10:41, Théo Lebrun wrote:
> > Hello,
> > 
> > On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> >> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> >>> On 29/02/2024 19:10, Théo Lebrun wrote:
> >>>> Reference common hwmon schema which has the generic "label" property,
> >>>> parsed by Linux hwmon subsystem.
> >>>>
> >>>
> >>> Please do not mix independent patchsets. You create unneeded
> >>> dependencies blocking this patch. This patch depends on hwmon work, so
> >>> it cannot go through different tree.
> > 
> > I had to pick between this or dtbs_check failing on my DTS that uses a
> > label on temperature-sensor@48.
>
> I don't see how is that relevant. You can organize your branches as you
> wish, e.g. base one b4 branch on another and you will not have any warnings.

That is what I do, I however do not want mips-next to have errors when
running dtbs_check. Having dtbs_check return errors is not an issue?

> >>> If you insist to combine independent patches, then at least clearly
> >>> express merging strategy or dependency in patch changelog --- .
> > 
> > I do not know how such indirect conflicts are usually resolved. Hwmon
> > can take it but MIPS might want to also take it to have valid DTS.
> > 
> > Any advice?
>
> I don't see any conflict.

I shouldn't have called that a conflict, more like a dependency.

> >> For my part I have to say that I don't know what to do with it.
> >> Rob's robot reported errors, so I won't apply it, and I don't
> >> feel comfortable giving it an ack either because of those errors.
> > 
> > Can reproduce the error when patch "dt-bindings: hwmon: add common
> > properties" is not applied. Cannot reproduce when patch is applied.
> > Commit d590900b62f0 on hwmon-next. Cannot reproduce with hwmon-next as
> > parent.
>
> Yeah, but we see the error reported and it means something is missing.

Yes, this series depends on "dt-bindings: hwmon: add common properties"
which the bot doesn't know it needs to apply.

Should I submit this patch independently and have my DTS be broken wrt
dtbs_check?

Have a nice day,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Krzysztof Kozlowski]

On 01/03/2024 11:44, Théo Lebrun wrote:
> Hello,
> 
> On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
>> On 01/03/2024 10:41, Théo Lebrun wrote:
>>> Hello,
>>>
>>> On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
>>>> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
>>>>> On 29/02/2024 19:10, Théo Lebrun wrote:
>>>>>> Reference common hwmon schema which has the generic "label" property,
>>>>>> parsed by Linux hwmon subsystem.
>>>>>>
>>>>>
>>>>> Please do not mix independent patchsets. You create unneeded
>>>>> dependencies blocking this patch. This patch depends on hwmon work, so
>>>>> it cannot go through different tree.
>>>
>>> I had to pick between this or dtbs_check failing on my DTS that uses a
>>> label on temperature-sensor@48.
>>
>> I don't see how is that relevant. You can organize your branches as you
>> wish, e.g. base one b4 branch on another and you will not have any warnings.
> 
> That is what I do, I however do not want mips-next to have errors when
> running dtbs_check. Having dtbs_check return errors is not an issue?

You should ask your maintainer, but I don't understand how this is
achievable anyway. Subsystem bindings *should not* go via MIPS-next, so
how are you going to solve this?

And why MIPS shall be different than all other ARM/RISC-V SoCs?

Best regards,
Krzysztof

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Théo Lebrun]

Hello,

On Fri Mar 1, 2024 at 12:35 PM CET, Krzysztof Kozlowski wrote:
> On 01/03/2024 11:44, Théo Lebrun wrote:
> > On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> >> On 01/03/2024 10:41, Théo Lebrun wrote:
> >>> On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> >>>> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> >>>>> On 29/02/2024 19:10, Théo Lebrun wrote:
> >>>>>> Reference common hwmon schema which has the generic "label" property,
> >>>>>> parsed by Linux hwmon subsystem.
> >>>>>
> >>>>> Please do not mix independent patchsets. You create unneeded
> >>>>> dependencies blocking this patch. This patch depends on hwmon work, so
> >>>>> it cannot go through different tree.
> >>>
> >>> I had to pick between this or dtbs_check failing on my DTS that uses a
> >>> label on temperature-sensor@48.
> >>
> >> I don't see how is that relevant. You can organize your branches as you
> >> wish, e.g. base one b4 branch on another and you will not have any warnings.
> > 
> > That is what I do, I however do not want mips-next to have errors when
> > running dtbs_check. Having dtbs_check return errors is not an issue?
>
> You should ask your maintainer, but I don't understand how this is
> achievable anyway. Subsystem bindings *should not* go via MIPS-next, so
> how are you going to solve this?

I thought it'd go in hwmon-next and be picked up by mips-next as well.
It's clear now that the right approach is to send the lm75.yaml patch
alone.

I'll wait some more before sending a new revision that drops this
lm75.yaml patch.

Have a nice day,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Krzysztof Kozlowski]

On 01/03/2024 15:09, Théo Lebrun wrote:
>>>> I don't see how is that relevant. You can organize your branches as you
>>>> wish, e.g. base one b4 branch on another and you will not have any warnings.
>>>
>>> That is what I do, I however do not want mips-next to have errors when
>>> running dtbs_check. Having dtbs_check return errors is not an issue?
>>
>> You should ask your maintainer, but I don't understand how this is
>> achievable anyway. Subsystem bindings *should not* go via MIPS-next, so
>> how are you going to solve this?
> 
> I thought it'd go in hwmon-next and be picked up by mips-next as well.
> It's clear now that the right approach is to send the lm75.yaml patch
> alone.

Then mips-next-dts branch would be based on subsystem branch with driver
changes? That violates the policy of not creating dependencies between
DTS and drivers.

What matters is final or even future release, not intermediate state.

Best regards,
Krzysztof

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Rob Herring]

On Fri, Mar 01, 2024 at 11:44:37AM +0100, Théo Lebrun wrote:
> Hello,
> 
> On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> > On 01/03/2024 10:41, Théo Lebrun wrote:
> > > Hello,
> > > 
> > > On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> > >> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > >>> On 29/02/2024 19:10, Théo Lebrun wrote:
> > >>>> Reference common hwmon schema which has the generic "label" property,
> > >>>> parsed by Linux hwmon subsystem.
> > >>>>
> > >>>
> > >>> Please do not mix independent patchsets. You create unneeded
> > >>> dependencies blocking this patch. This patch depends on hwmon work, so
> > >>> it cannot go through different tree.
> > > 
> > > I had to pick between this or dtbs_check failing on my DTS that uses a
> > > label on temperature-sensor@48.
> >
> > I don't see how is that relevant. You can organize your branches as you
> > wish, e.g. base one b4 branch on another and you will not have any warnings.
> 
> That is what I do, I however do not want mips-next to have errors when
> running dtbs_check. Having dtbs_check return errors is not an issue?

That's a good goal, but difficult to achieve as you can see. Given 
dtbs_check in general has tons of warnings already, we currently don't 
worry about more warnings in specific branches. We just look at mainline 
and linux-next. And for that it's still so many, I'm just looking at 
general trends. It runs daily here[1].

As we get more platforms trying to stay at zero warnings, then we'll 
need to revisit this. I imagine that will mean all schemas have to go in 
1 branch with acks from subsystem maintainers. That's the opposite of 
what we do now. And then .dts branches will have to merge in the schema 
branch as needed. There are some checks (make dt_compatible_check) to 
for drivers vs. the schemas, so we'd have the same issue with 
intermittent warnings. But the drivers should be more decoupled from the 
schemas than the dts files.

Rob

[1] https://gitlab.com/robherring/linux-dt/-/jobs

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Théo Lebrun]

Hello,

On Fri Mar 1, 2024 at 4:35 PM CET, Rob Herring wrote:
> On Fri, Mar 01, 2024 at 11:44:37AM +0100, Théo Lebrun wrote:
> > Hello,
> > 
> > On Fri Mar 1, 2024 at 11:13 AM CET, Krzysztof Kozlowski wrote:
> > > On 01/03/2024 10:41, Théo Lebrun wrote:
> > > > Hello,
> > > > 
> > > > On Fri Mar 1, 2024 at 7:53 AM CET, Guenter Roeck wrote:
> > > >> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > > >>> On 29/02/2024 19:10, Théo Lebrun wrote:
> > > >>>> Reference common hwmon schema which has the generic "label" property,
> > > >>>> parsed by Linux hwmon subsystem.
> > > >>>>
> > > >>>
> > > >>> Please do not mix independent patchsets. You create unneeded
> > > >>> dependencies blocking this patch. This patch depends on hwmon work, so
> > > >>> it cannot go through different tree.
> > > > 
> > > > I had to pick between this or dtbs_check failing on my DTS that uses a
> > > > label on temperature-sensor@48.
> > >
> > > I don't see how is that relevant. You can organize your branches as you
> > > wish, e.g. base one b4 branch on another and you will not have any warnings.
> > 
> > That is what I do, I however do not want mips-next to have errors when
> > running dtbs_check. Having dtbs_check return errors is not an issue?
>
> That's a good goal, but difficult to achieve as you can see. Given 
> dtbs_check in general has tons of warnings already, we currently don't 
> worry about more warnings in specific branches. We just look at mainline 
> and linux-next. And for that it's still so many, I'm just looking at 
> general trends. It runs daily here[1].

Here's my opportunity to ask a question I've had for a while: do you
have a way to filter out dtbs that are known to be bad actors (ie have
many many warnings)? Maybe a list of platforms you talk about below
that aim at zero warnings?

Another way to ask this: what would be a good default DT_SCHEMA_FILES
value? Not filtering leads to way too many errors.

Regards,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Rob Herring]

On Thu, Feb 29, 2024 at 10:53:07PM -0800, Guenter Roeck wrote:
> On 2/29/24 22:37, Krzysztof Kozlowski wrote:
> > On 29/02/2024 19:10, Théo Lebrun wrote:
> > > Reference common hwmon schema which has the generic "label" property,
> > > parsed by Linux hwmon subsystem.
> > > 
> > 
> > Please do not mix independent patchsets. You create unneeded
> > dependencies blocking this patch. This patch depends on hwmon work, so
> > it cannot go through different tree.
> > 
> > If you insist to combine independent patches, then at least clearly
> > express merging strategy or dependency in patch changelog --- .
> > 
> 
> For my part I have to say that I don't know what to do with it.
> Rob's robot reported errors, so I won't apply it, and I don't
> feel comfortable giving it an ack either because of those errors.

You can apply it. Those are just related to not finding 
hwmon-common.yaml which you have, and Théo confirmed it works on 
hwmon-next.

Rob

Re: [PATCH v2 02/11] dt-bindings: hwmon: lm75: use common hwmon schema

[Guenter Roeck]

On Thu, Feb 29, 2024 at 07:10:50PM +0100, Théo Lebrun wrote:
> Reference common hwmon schema which has the generic "label" property,
> parsed by Linux hwmon subsystem.
> 
> To: Jean Delvare <jdelvare@suse.com>
> To: Guenter Roeck <linux@roeck-us.net>
> Cc: linux-hwmon@vger.kernel.org
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Applied to hwmon-next.

Thanks,
Guenter

Re: [PATCH v2 00/11] Add Mobileye EyeQ5 support to the Nomadik I2C controller & use hrtimers for timeouts

[Andi Shyti]

Hi Theo,

> Théo Lebrun (11):
>       dt-bindings: i2c: nomadik: add mobileye,eyeq5-i2c bindings and example
>       dt-bindings: hwmon: lm75: use common hwmon schema
>       i2c: nomadik: rename private struct pointers from dev to priv
>       i2c: nomadik: simplify IRQ masking logic
>       i2c: nomadik: use bitops helpers
>       i2c: nomadik: support short xfer timeouts using waitqueue & hrtimer
>       i2c: nomadik: replace jiffies by ktime for FIFO flushing timeout
>       i2c: nomadik: fetch i2c-transfer-timeout-us property from devicetree
>       i2c: nomadik: support Mobileye EyeQ5 I2C controller
>       MIPS: mobileye: eyeq5: add 5 I2C controller nodes
>       MIPS: mobileye: eyeq5: add evaluation board I2C temp sensor

what's your plan for this series? If you extract into a separate
series the refactoring patches that are not dependent on the
bindings I could queue them up for the merge window.

Andi

Re: [PATCH v2 00/11] Add Mobileye EyeQ5 support to the Nomadik I2C controller & use hrtimers for timeouts

[Théo Lebrun]

Hello Andi,

On Wed Mar 6, 2024 at 2:49 AM CET, Andi Shyti wrote:
> > Théo Lebrun (11):
> >       dt-bindings: i2c: nomadik: add mobileye,eyeq5-i2c bindings and example
> >       dt-bindings: hwmon: lm75: use common hwmon schema
> >       i2c: nomadik: rename private struct pointers from dev to priv
> >       i2c: nomadik: simplify IRQ masking logic
> >       i2c: nomadik: use bitops helpers
> >       i2c: nomadik: support short xfer timeouts using waitqueue & hrtimer
> >       i2c: nomadik: replace jiffies by ktime for FIFO flushing timeout
> >       i2c: nomadik: fetch i2c-transfer-timeout-us property from devicetree
> >       i2c: nomadik: support Mobileye EyeQ5 I2C controller
> >       MIPS: mobileye: eyeq5: add 5 I2C controller nodes
> >       MIPS: mobileye: eyeq5: add evaluation board I2C temp sensor
>
> what's your plan for this series? If you extract into a separate
> series the refactoring patches that are not dependent on the
> bindings I could queue them up for the merge window.

V3 is ready and will be sent today. I think we can get trailers from
dt-bindings maintainers as the discussion has been caried out on this
revision.

Am I being too optimistic of seeing this series queued before the merge
window?

Thanks Andi,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com