All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
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 17:14:35 +0100	[thread overview]
Message-ID: <20200624161435.GI954398@dell> (raw)
In-Reply-To: <d7774c42-fd41-9fab-2ea0-cd6bc7d35383@gmail.com>

On Wed, 24 Jun 2020, Frank Rowand wrote:

> 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.

NP.

> >>>> 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.

I still don't see how it could work, but please feel free to submit a
subsequent patch and we can discuss it on its own merits.

> 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.

Great.  Thanks for taking an interest.

Does this mean I can apply your Reviewed-by?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
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: Lee Jones <lee.jones@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
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 17:14:35 +0100	[thread overview]
Message-ID: <20200624161435.GI954398@dell> (raw)
In-Reply-To: <d7774c42-fd41-9fab-2ea0-cd6bc7d35383@gmail.com>

On Wed, 24 Jun 2020, Frank Rowand wrote:

> 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.

NP.

> >>>> 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.

I still don't see how it could work, but please feel free to submit a
subsequent patch and we can discuss it on its own merits.

> 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.

Great.  Thanks for taking an interest.

Does this mean I can apply your Reviewed-by?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-06-24 16:16 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
2020-06-24 15:51                               ` Frank Rowand
2020-06-24 16:14                               ` Lee Jones [this message]
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=20200624161435.GI954398@dell \
    --to=lee.jones@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.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.