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: 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: Mon, 22 Jun 2020 09:50:09 +0100	[thread overview]
Message-ID: <20200622085009.GP954398@dell> (raw)
In-Reply-To: <eef50a78-8571-5600-4fee-c824fd4a7f69@gmail.com>

On Thu, 18 Jun 2020, Frank Rowand wrote:

> On 2020-06-15 04:26, Lee Jones wrote:
> > On Sun, 14 Jun 2020, Frank Rowand wrote:
> > 
> >> Hi Lee,
> >>
> >> I'm looking at 5.8-rc1.
> >>
> >> The only use of OF_MFD_CELL() where the same compatible is specified
> >> for multiple elements of a struct mfd_cell array is for compatible
> >> "stericsson,ab8500-pwm" in drivers/mfd/ab8500-core.c:
> >>
> >>         OF_MFD_CELL("ab8500-pwm",
> >>                     NULL, NULL, 0, 1, "stericsson,ab8500-pwm"),
> >>         OF_MFD_CELL("ab8500-pwm",
> >>                     NULL, NULL, 0, 2, "stericsson,ab8500-pwm"),
> >>         OF_MFD_CELL("ab8500-pwm",
> >>                     NULL, NULL, 0, 3, "stericsson,ab8500-pwm"),
> 
>          OF_MFD_CELL("ab8500-pwm",
>                      NULL, NULL, 0, 0, "stericsson,ab8500-pwm"),
> 
>          OF_MFD_CELL_REG("ab8500-pwm-mc",
>                          NULL, NULL, 0, 0, "stericsson,ab8500-pwm", 0),
>          OF_MFD_CELL_REG("ab8500-pwm-mc",
>                          NULL, NULL, 0, 1, "stericsson,ab8500-pwm", 1),
>          OF_MFD_CELL_REG("ab8500-pwm-mc",
>                          NULL, NULL, 0, 2, "stericsson,ab8500-pwm", 2),
> 
> >>
> >> The only .dts or .dtsi files where I see compatible "stericsson,ab8500-pwm"
> >> are:
> >>
> >>    arch/arm/boot/dts/ste-ab8500.dtsi
> >>    arch/arm/boot/dts/ste-ab8505.dtsi
> >>
> >> These two .dtsi files only have a single node with this compatible.
> >> Chasing back to .dts and .dtsi files that include these two .dtsi
> >> files, I see no case where there are multiple nodes with this
> >> compatible.
> >>
> >> So it looks to me like there is no .dts in mainline that is providing
> >> the three "stericsson,ab8500-pwm" nodes that drivers/mfd/ab8500-core.c
> >> is expecting.  No case that there are multiple mfd child nodes where
> >> mfd_add_device() would assign the first of n child nodes with the
> >> same compatible to multiple devices.
> >>
> >> So it appears to me that drivers/mfd/ab8500-core.c is currently broken.
> >> Am I missing something here?
> >>
> >> If I am correct, then either drivers/mfd/ab8500-core.c or
> >> ste-ab8500.dtsi and ste-ab8505.dtsi need to be fixed.
> > 
> > Your analysis is correct.
> 
> OK, if I'm not overlooking anything, that is good news.
> 
> Existing .dts source files only have one "ab8500-pwm" child.  They already
> work correcly.
> 
> Create a new compatible for the case of multiple children.  In my example
> I will add "-mc" (multiple children) to the existing compatible.  There
> is likely a better name, but this lets me provide an example.
> 
> Modify drivers/mfd/ab8500-core.c to use the new compatible, and new .dts
> source files with multiple children use the new compatible:
> 
>          OF_MFD_CELL("ab8500-pwm",
>                      NULL, NULL, 0, 0, "stericsson,ab8500-pwm"),
> 
>          OF_MFD_CELL_REG("ab8500-pwm-mc",
>                          NULL, NULL, 0, 0, "stericsson,ab8500-pwm", 0),
>          OF_MFD_CELL_REG("ab8500-pwm-mc",
>                          NULL, NULL, 0, 1, "stericsson,ab8500-pwm", 1),
>          OF_MFD_CELL_REG("ab8500-pwm-mc",
>                          NULL, NULL, 0, 2, "stericsson,ab8500-pwm", 2),
> 
> The "OF_MFD_CELL" entry is the existing entry, which will handle current
> .dts source files.  The new "OF_MFD_CELL_REG" entries will handle new
> .dts source files.

Sorry, but I'm not sure what the above exercise is supposed to solve.

Could you explain it for me please?

> And of course the patch that creates OF_MFD_CELL_REG() needs to precede
> this change.
> 
> I would remove the fallback code in the existing patch that tries to
> handle an incorrect binding.  Just error out if the binding is not
> used properly.

What fallback code?

> > Although it's not "broken", it just works when it really shouldn't.
> > 
> > I will be fixing the 'ab8500-pwm' case in due course.
> > 
> >> Moving forward, your proposed OF_MFD_CELL_REG() method seems a good
> >> approach (I have not completely read the actual code in the patch yet
> >> though).
> > 
> > Thanks.
> > 
> 

-- 
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-22  8:50 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 [this message]
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
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=20200622085009.GP954398@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.