All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
	broonie@kernel.org, michael@walle.cc,
	linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
	robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
	andriy.shevchenko@linux.intel.com, robin.murphy@arm.com,
	linus.walleij@linaro.org, linux@roeck-us.net
Subject: Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes
Date: Wed, 24 Jun 2020 10:51:33 -0500	[thread overview]
Message-ID: <d7774c42-fd41-9fab-2ea0-cd6bc7d35383@gmail.com> (raw)
In-Reply-To: <20200624074631.GE954398@dell>

On 2020-06-24 02:46, Lee Jones wrote:
> On Tue, 23 Jun 2020, Frank Rowand wrote:
> 
>> On 2020-06-23 14:59, Lee Jones wrote:


< big snip >

Thanks for the replies in the above portion.


>>>> But yes or no to my solution #2 (with some slight changes to
>>>> make it better (more gracious handling of the detected error) as
>>>> discussed elsewhere in the email thread)?
>>>
>>> Please see "[0]" above!
>>>
>>> AFAICT your solution #2 involves bombing out *all* devices if there is
>>> a duplicate compatible with no 'reg' property value.  This is a)
>>> over-kill and b) not an error, as I mentioned:
>>
>> As I mentioned above, I set you up to have this misunderstanding by
>> a mistake in one of my earlier emails.  So now that I have pointed
>> out what I meant here by "more gracious handling of the detected
>> error", what do you think of my amended solution #2?
> 
> Explained above, but the LT;DR is that it's not correct.

I don't agree with you, I think my solution is better.  Even if I
prefer my solution, I find your solution to be good enough.

So I am dropping my specific objection to returning -EAGAIN from
mfd_match_of_node_to_dev() when the node has previously been
allocated to a device.


> 
>>>>> It also suffers with false positives.
>>>
>>
>> Sorry for the very long response, but it seemed we were operating
>> under some different understandings and I hope I have clarified some
>> things.
> 
> Likewise. :)
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: andy.shevchenko@gmail.com, michael@walle.cc, robh+dt@kernel.org,
	broonie@kernel.org, devicetree@vger.kernel.org,
	linus.walleij@linaro.org, linux@roeck-us.net,
	andriy.shevchenko@linux.intel.com, robin.murphy@arm.com,
	gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes
Date: Wed, 24 Jun 2020 10:51:33 -0500	[thread overview]
Message-ID: <d7774c42-fd41-9fab-2ea0-cd6bc7d35383@gmail.com> (raw)
In-Reply-To: <20200624074631.GE954398@dell>

On 2020-06-24 02:46, Lee Jones wrote:
> On Tue, 23 Jun 2020, Frank Rowand wrote:
> 
>> On 2020-06-23 14:59, Lee Jones wrote:


< big snip >

Thanks for the replies in the above portion.


>>>> But yes or no to my solution #2 (with some slight changes to
>>>> make it better (more gracious handling of the detected error) as
>>>> discussed elsewhere in the email thread)?
>>>
>>> Please see "[0]" above!
>>>
>>> AFAICT your solution #2 involves bombing out *all* devices if there is
>>> a duplicate compatible with no 'reg' property value.  This is a)
>>> over-kill and b) not an error, as I mentioned:
>>
>> As I mentioned above, I set you up to have this misunderstanding by
>> a mistake in one of my earlier emails.  So now that I have pointed
>> out what I meant here by "more gracious handling of the detected
>> error", what do you think of my amended solution #2?
> 
> Explained above, but the LT;DR is that it's not correct.

I don't agree with you, I think my solution is better.  Even if I
prefer my solution, I find your solution to be good enough.

So I am dropping my specific objection to returning -EAGAIN from
mfd_match_of_node_to_dev() when the node has previously been
allocated to a device.


> 
>>>>> It also suffers with false positives.
>>>
>>
>> Sorry for the very long response, but it seemed we were operating
>> under some different understandings and I hope I have clarified some
>> things.
> 
> Likewise. :)
> 


  reply	other threads:[~2020-06-24 15:53 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11 19:10 [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes Lee Jones
2020-06-11 19:10 ` Lee Jones
2020-06-11 19:10 ` [PATCH v2 2/3] mfd: core: Fix formatting of MFD helpers Lee Jones
2020-06-11 19:10   ` Lee Jones
2020-06-12 12:27   ` Frank Rowand
2020-06-12 12:27     ` Frank Rowand
2020-06-11 19:10 ` [PATCH v2 3/3] mfd: core: Add OF_MFD_CELL_REG() helper Lee Jones
2020-06-11 19:10   ` Lee Jones
2020-06-12 12:28   ` Frank Rowand
2020-06-12 12:28     ` Frank Rowand
2020-06-12 12:26 ` [PATCH v2 1/3] mfd: core: Make a best effort attempt to match devices with the correct of_nodes Frank Rowand
2020-06-12 12:26   ` Frank Rowand
2020-06-15  1:19 ` Frank Rowand
2020-06-15  1:19   ` Frank Rowand
2020-06-15  9:26   ` Lee Jones
2020-06-15  9:26     ` Lee Jones
2020-06-18 17:34     ` Frank Rowand
2020-06-18 17:34       ` Frank Rowand
2020-06-22  8:50       ` Lee Jones
2020-06-22 14:32         ` Frank Rowand
2020-06-22 14:35           ` Frank Rowand
2020-06-22 15:10           ` Lee Jones
2020-06-22 18:01             ` Frank Rowand
2020-06-22 18:04               ` Frank Rowand
2020-06-22 19:11               ` Lee Jones
2020-06-22 22:23                 ` Frank Rowand
2020-06-23  1:17                   ` Frank Rowand
2020-06-23  1:37                     ` Frank Rowand
2020-06-23  6:47                   ` Lee Jones
2020-06-23 17:55                     ` Frank Rowand
2020-06-23 17:55                       ` Frank Rowand
2020-06-23 19:59                       ` Lee Jones
2020-06-23 19:59                         ` Lee Jones
2020-06-23 22:33                         ` Frank Rowand
2020-06-23 22:33                           ` Frank Rowand
2020-06-24  7:46                           ` Lee Jones
2020-06-24  7:46                             ` Lee Jones
2020-06-24 15:51                             ` Frank Rowand [this message]
2020-06-24 15:51                               ` Frank Rowand
2020-06-24 16:14                               ` Lee Jones
2020-06-24 16:14                                 ` Lee Jones
2020-06-24 16:25                                 ` Frank Rowand
2020-06-24 16:25                                   ` Frank Rowand
2020-06-22  8:09 ` Lee Jones
2020-06-22 16:09   ` Frank Rowand
2020-06-22 16:53     ` Lee Jones
2020-06-23 22:21 ` Frank Rowand
2020-06-23 22:21   ` Frank Rowand
2020-06-24  6:45   ` Lee Jones
2020-06-24  6:45     ` Lee Jones
2020-06-23 23:03 ` Frank Rowand
2020-06-23 23:03   ` Frank Rowand
2020-06-24  6:41   ` Lee Jones
2020-06-24  6:41     ` Lee Jones
2020-06-24  7:47     ` Michael Walle
2020-06-24  7:47       ` Michael Walle
2020-06-24  8:23       ` Lee Jones
2020-06-24  8:23         ` Lee Jones
2020-06-24  9:19         ` Michael Walle
2020-06-24  9:19           ` Michael Walle
2020-06-24 11:24           ` Lee Jones
2020-06-24 11:24             ` Lee Jones
  -- strict thread matches above, loose matches on Subject: below --
2020-06-11 19:12 Lee Jones
2020-06-11 19:12 ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d7774c42-fd41-9fab-2ea0-cd6bc7d35383@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=michael@walle.cc \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.