diff mbox series

[v4,4/7] dt-bindings: iio: accel: adxl345: Add spi-3wire

Message ID 20240325153356.46112-5-l.rubusch@gmail.com (mailing list archive)
State Changes Requested
Headers show
Series iio: accel: adxl345: Add spi-3wire feature | expand

Commit Message

Lothar Rubusch March 25, 2024, 3:33 p.m. UTC
Add spi-3wire because the driver optionally supports spi-3wire.

Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
 Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml | 2 ++
 1 file changed, 2 insertions(+)

Comments

Krzysztof Kozlowski March 25, 2024, 6:32 p.m. UTC | #1
On 25/03/2024 16:33, Lothar Rubusch wrote:
> Add spi-3wire because the driver optionally supports spi-3wire.

This is a friendly reminder during the review process.

It seems my or other reviewer's previous comments were not fully
addressed. Maybe the feedback got lost between the quotes, maybe you
just forgot to apply it. Please go back to the previous discussion and
either implement all requested changes or keep discussing them.

Thank you.

> 
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---

This is a friendly reminder during the review process.

It looks like you received a tag and forgot to add it.

If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.

https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577

If a tag was not added on purpose, please state why and what changed.

Best regards,
Krzysztof
Lothar Rubusch March 25, 2024, 9:05 p.m. UTC | #2
On Mon, Mar 25, 2024 at 7:32 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 16:33, Lothar Rubusch wrote:
> > Add spi-3wire because the driver optionally supports spi-3wire.
>
> This is a friendly reminder during the review process.
>
> It seems my or other reviewer's previous comments were not fully
> addressed. Maybe the feedback got lost between the quotes, maybe you
> just forgot to apply it. Please go back to the previous discussion and
> either implement all requested changes or keep discussing them.
>
> Thank you.
>

You refer yourself to the above mentioned wording. Would replacing
"driver" by "device" in the dt-bindings patch comment be sufficient?
Did I miss something else?

> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > ---
>
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
> If you do not know the process, here is a short explanation:
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> versions, under or above your Signed-off-by tag. Tag is "received", when
> provided in a message replied to you on the mailing list. Tools like b4
> can help here. However, there's no need to repost patches *only* to add

Just for confirmation: when I receive a feedback, requesting a change.
And, I accept the change request. This means, I received a tag
"Reviewed-by" which I have to mention in the upcoming patch version
where this change is implemented and in that particular patch?

> the tags. The upstream maintainer will do that for tags received on the
> version they apply.
>

I'm pretty sure we will still see further iterations. So, I apply the
tags in the next version, already scheduled. Ok?

> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
>

Going over the books I feel it does not make sense to still mention
feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
does it? Your link mentiones "However if the patch has changed
substantially in followin version, these tags might not be applicable
anymore"
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L579

> If a tag was not added on purpose, please state why and what changed.
>
> Best regards,
> Krzysztof
>

I give it a try with b4. Let's see.
Krzysztof Kozlowski March 25, 2024, 9:40 p.m. UTC | #3
On 25/03/2024 22:05, Lothar Rubusch wrote:
> On Mon, Mar 25, 2024 at 7:32 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 25/03/2024 16:33, Lothar Rubusch wrote:
>>> Add spi-3wire because the driver optionally supports spi-3wire.
>>
>> This is a friendly reminder during the review process.
>>
>> It seems my or other reviewer's previous comments were not fully
>> addressed. Maybe the feedback got lost between the quotes, maybe you
>> just forgot to apply it. Please go back to the previous discussion and
>> either implement all requested changes or keep discussing them.
>>
>> Thank you.
>>
> 
> You refer yourself to the above mentioned wording. Would replacing
> "driver" by "device" in the dt-bindings patch comment be sufficient?
> Did I miss something else?

Yes, the wording, but isn't the device require 3-wire mode? Don't just
replace one word with another, but write the proper rationale for your
hardware.

> 
>>>
>>> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
>>> ---
>>
>> This is a friendly reminder during the review process.
>>
>> It looks like you received a tag and forgot to add it.
>>
>> If you do not know the process, here is a short explanation:
>> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
>> versions, under or above your Signed-off-by tag. Tag is "received", when
>> provided in a message replied to you on the mailing list. Tools like b4
>> can help here. However, there's no need to repost patches *only* to add
> 
> Just for confirmation: when I receive a feedback, requesting a change.
> And, I accept the change request. This means, I received a tag
> "Reviewed-by" which I have to mention in the upcoming patch version
> where this change is implemented and in that particular patch?

Please go through the docs. Yes, you received a tag which should be
included with the change.

Reviewer's feedback should not be ignored.


> 
>> the tags. The upstream maintainer will do that for tags received on the
>> version they apply.
>>
> 
> I'm pretty sure we will still see further iterations. So, I apply the
> tags in the next version, already scheduled. Ok?
> 
>> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
>>
> 
> Going over the books I feel it does not make sense to still mention
> feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
> does it? Your link mentiones "However if the patch has changed

I don't understand. When did you receive the tag? v3, right? So what do
you mean by v1 and v2?


Best regards,
Krzysztof
Lothar Rubusch March 25, 2024, 10:09 p.m. UTC | #4
On Mon, Mar 25, 2024 at 10:40 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 22:05, Lothar Rubusch wrote:
> > On Mon, Mar 25, 2024 at 7:32 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 25/03/2024 16:33, Lothar Rubusch wrote:
> >>> Add spi-3wire because the driver optionally supports spi-3wire.
> >>
> >> This is a friendly reminder during the review process.
> >>
> >> It seems my or other reviewer's previous comments were not fully
> >> addressed. Maybe the feedback got lost between the quotes, maybe you
> >> just forgot to apply it. Please go back to the previous discussion and
> >> either implement all requested changes or keep discussing them.
> >>
> >> Thank you.
> >>
> >
> > You refer yourself to the above mentioned wording. Would replacing
> > "driver" by "device" in the dt-bindings patch comment be sufficient?
> > Did I miss something else?
>
> Yes, the wording, but isn't the device require 3-wire mode? Don't just
> replace one word with another, but write the proper rationale for your
> hardware.
>
It does not require 3-wire SPI. By default the device communicates
regular SPI. It can be configured, though, to communicate 3-wire. The
given patch offers this as option in the DT.

> >
> >>>
> >>> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> >>> ---
> >>
> >> This is a friendly reminder during the review process.
> >>
> >> It looks like you received a tag and forgot to add it.
> >>
> >> If you do not know the process, here is a short explanation:
> >> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> >> versions, under or above your Signed-off-by tag. Tag is "received", when
> >> provided in a message replied to you on the mailing list. Tools like b4
> >> can help here. However, there's no need to repost patches *only* to add
> >
> > Just for confirmation: when I receive a feedback, requesting a change.
> > And, I accept the change request. This means, I received a tag
> > "Reviewed-by" which I have to mention in the upcoming patch version
> > where this change is implemented and in that particular patch?
>
> Please go through the docs. Yes, you received a tag which should be
> included with the change.
>
> Reviewer's feedback should not be ignored.
>
>
> >
> >> the tags. The upstream maintainer will do that for tags received on the
> >> version they apply.
> >>
> >
> > I'm pretty sure we will still see further iterations. So, I apply the
> > tags in the next version, already scheduled. Ok?
> >
> >> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
> >>
> >
> > Going over the books I feel it does not make sense to still mention
> > feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
> > does it? Your link mentiones "However if the patch has changed
>
> I don't understand. When did you receive the tag? v3, right? So what do
> you mean by v1 and v2?
>

V1: The first version of the 3wire patch. I have split the single
patch upon some feedback (yours?!) - V2... So, my current
interpretation is, that every feedback I need to mention as
Reviewed-by tag, no?

>
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski March 26, 2024, 6:30 a.m. UTC | #5
On 25/03/2024 23:09, Lothar Rubusch wrote:
>>
>>
>>>
>>>> the tags. The upstream maintainer will do that for tags received on the
>>>> version they apply.
>>>>
>>>
>>> I'm pretty sure we will still see further iterations. So, I apply the
>>> tags in the next version, already scheduled. Ok?
>>>
>>>> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
>>>>
>>>
>>> Going over the books I feel it does not make sense to still mention
>>> feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
>>> does it? Your link mentiones "However if the patch has changed
>>
>> I don't understand. When did you receive the tag? v3, right? So what do
>> you mean by v1 and v2?
>>
> 
> V1: The first version of the 3wire patch. I have split the single
> patch upon some feedback (yours?!) - V2... So, my current
> interpretation is, that every feedback I need to mention as
> Reviewed-by tag, no?

What? Feedback is not review. It's clearly explained in submitting
patches. Please read it.

Best regards,
Krzysztof
Lothar Rubusch March 26, 2024, 8:17 p.m. UTC | #6
On Tue, Mar 26, 2024 at 7:30 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 23:09, Lothar Rubusch wrote:
> >>
> >>
> >>>
> >>>> the tags. The upstream maintainer will do that for tags received on the
> >>>> version they apply.
> >>>>
> >>>
> >>> I'm pretty sure we will still see further iterations. So, I apply the
> >>> tags in the next version, already scheduled. Ok?
> >>>
> >>>> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
> >>>>
> >>>
> >>> Going over the books I feel it does not make sense to still mention
> >>> feedback ("Reveiewed-by") for the v1 or v2 of the patch here in a v5,
> >>> does it? Your link mentiones "However if the patch has changed
> >>
> >> I don't understand. When did you receive the tag? v3, right? So what do
> >> you mean by v1 and v2?
> >>
> >
> > V1: The first version of the 3wire patch. I have split the single
> > patch upon some feedback (yours?!) - V2... So, my current
> > interpretation is, that every feedback I need to mention as
> > Reviewed-by tag, no?
>
> What? Feedback is not review. It's clearly explained in submitting
> patches. Please read it.
>

Exactly. My missunderstanding here is this:  Why did you send me a
reminder that I forgot to add "Reviewed-by" tag in your last mail?
Could you please clarify your last mail? You wrote:
"(...)
This is a friendly reminder during the review process.

It looks like you received a tag and forgot to add it.

If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, (...)"

AFAIK noone literally had told me: "please add a Reviewed-by me tag",
or did I miss something? I'm a bit lost here, sorry.

> Best regards,
> Krzysztof
>
Krzysztof Kozlowski March 27, 2024, 5:02 a.m. UTC | #7
On 26/03/2024 21:17, Lothar Rubusch wrote:
>>>
>>> V1: The first version of the 3wire patch. I have split the single
>>> patch upon some feedback (yours?!) - V2... So, my current
>>> interpretation is, that every feedback I need to mention as
>>> Reviewed-by tag, no?
>>
>> What? Feedback is not review. It's clearly explained in submitting
>> patches. Please read it.
>>
> 
> Exactly. My missunderstanding here is this:  Why did you send me a
> reminder that I forgot to add "Reviewed-by" tag in your last mail?
> Could you please clarify your last mail? You wrote:
> "(...)
> This is a friendly reminder during the review process.
> 
> It looks like you received a tag and forgot to add it.
> 
> If you do not know the process, here is a short explanation:
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> versions, (...)"
> 
> AFAIK noone literally had told me: "please add a Reviewed-by me tag",
> or did I miss something? I'm a bit lost here, sorry.
> 

What was this then:

https://lore.kernel.org/all/9700cc88-bddb-480d-9417-04b2ff539a2f@linaro.org/

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
index 07cacc3f6..280ed479e 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
@@ -32,6 +32,8 @@  properties:
 
   spi-cpol: true
 
+  spi-3wire: true
+
   interrupts:
     maxItems: 1