linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yunus Bas <Y.Bas@phytec.de>
To: "lee.jones@linaro.org" <lee.jones@linaro.org>
Cc: "stwiss.opensource@diasemi.com" <stwiss.opensource@diasemi.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mfd: mfd-core: Change "Failed to locate of_node" warning to debug
Date: Tue, 29 Jun 2021 09:41:24 +0000	[thread overview]
Message-ID: <b09a0919fb33cb7562f1902d461dcf830e925858.camel@phytec.de> (raw)
In-Reply-To: <YNritAU1p/R+WZ9I@dell>

Am Dienstag, dem 29.06.2021 um 10:07 +0100 schrieb Lee Jones:
> On Tue, 29 Jun 2021, Yunus Bas wrote:
> 
> > Am Donnerstag, dem 17.06.2021 um 09:27 +0100 schrieb Lee Jones:
> > > On Thu, 17 Jun 2021, Yunus Bas wrote:
> > > 
> > > > Hi Lee,
> > > > 
> > > > Am Mittwoch, dem 16.06.2021 um 10:03 +0100 schrieb Lee Jones:
> > > > > On Wed, 16 Jun 2021, Yunus Bas wrote:
> > > > > 
> > > > > > The MFD-core iterates through all subdevices of the
> > > > > > corresponding
> > > > > > MFD-device and checks, if the devicetree subnode has a
> > > > > > fitting
> > > > > > compatible.
> > > > > > When nothing is found, a warning is thrown. This can be the
> > > > > > case,
> > > > > > when it
> > > > > > is the intention to not use the MFD-device to it's full
> > > > > > content.
> > > > > > Therefore, change the warning to a debug print instead, to
> > > > > > also
> > > > > > avoid
> > > > > > irritations.
> > > > > > 
> > > > > > Signed-off-by: Yunus Bas <y.bas@phytec.de>
> > > > > > ---
> > > > > >  drivers/mfd/mfd-core.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-
> > > > > > core.c
> > > > > > index 6f02b8022c6d..e34c97088943 100644
> > > > > > --- a/drivers/mfd/mfd-core.c
> > > > > > +++ b/drivers/mfd/mfd-core.c
> > > > > > @@ -213,7 +213,7 @@ static int mfd_add_device(struct device
> > > > > > *parent,
> > > > > > int id,
> > > > > >                 }
> > > > > >  
> > > > > >                 if (!pdev->dev.of_node)
> > > > > > -                       pr_warn("%s: Failed to locate
> > > > > > of_node
> > > > > > [id:
> > > > > > %d]\n",
> > > > > > +                       pr_debug("%s: Failed to locate
> > > > > > of_node
> > > > > > [id:
> > > > > > %d]\n",
> > > > > >                                 cell->name, platform_id);
> > > > > >         }
> > > > > 
> > > > > Can you provide an example of a device tree where this is a
> > > > > problem?
> > > > 
> > > > Of course, sorry for the poor description.
> > > > 
> > > > Here is an example of the imx6qdl-phytec-phycore-som.dtsi which
> > > > uses
> > > > the DA9062 multi-functional device. The DA9062 has five mfd-
> > > > cell
> > > > devices with compatibles defined as subfunctions. The
> > > > devicetree
> > > > needs
> > > > and uses just three of them:
> > > > 
> > > > ...
> > > > pmic: pmic@58
> > > > {                                                      
> > > > compatible =
> > > > "dlg,da9062";                                           
> > > > pinctrl-names =
> > > > "default";                                           
> > > > pinctrl-0 =
> > > > <&pinctrl_pmic>;                                         
> > > > reg =
> > > > <0x58>;                                                        
> > > > interrupt-parent =
> > > > <&gpio1>;                                         
> > > > interrupts = <2
> > > > IRQ_TYPE_LEVEL_LOW>;                                 
> > > > #gpio-cells =
> > > > <2>;                                                   
> > > > da9062_rtc: rtc
> > > > {                                                    
> > > >     compatible = "dlg,da9062-
> > > > rtc";                                   
> > > >                                            
> > > > da9062_onkey: onkey
> > > > {                                                
> > > >     compatible = "dlg,da9062-
> > > > onkey";                                 
> > > > watchdog
> > > > {                                                           
> > > >     compatible = "dlg,da9062-
> > > > watchdog";                              
> > > >     dlg,use-sw-
> > > > pm;                                                   
> > > > }
> > > > ...
> > > 
> > > So, looking at the mfd_cells table, I see:
> > > 
> > >   static const struct mfd_cell da9061_devs[] = {
> > >         {
> > >                 .name           = "da9061-core",
> > >                 .num_resources  =
> > > ARRAY_SIZE(da9061_core_resources),
> > >                 .resources      = da9061_core_resources,
> > >         },
> > >         {
> > >                 .name           = "da9062-regulators",
> > >                 .num_resources  =
> > > ARRAY_SIZE(da9061_regulators_resources),
> > >                 .resources      = da9061_regulators_resources,
> > >         },
> > >         {
> > >                 .name           = "da9061-watchdog",
> > >                 .num_resources  =
> > > ARRAY_SIZE(da9061_wdt_resources),
> > >                 .resources      = da9061_wdt_resources,
> > >                 .of_compatible  = "dlg,da9061-watchdog",
> > >         },
> > >         {
> > >                 .name           = "da9061-thermal",
> > >                 .num_resources  =
> > > ARRAY_SIZE(da9061_thermal_resources),
> > >                 .resources      = da9061_thermal_resources,
> > >                 .of_compatible  = "dlg,da9061-thermal",
> > >         },
> > >         {
> > >                 .name           = "da9061-onkey",
> > >                 .num_resources  =
> > > ARRAY_SIZE(da9061_onkey_resources),
> > >                 .resources      = da9061_onkey_resources,
> > >                 .of_compatible = "dlg,da9061-onkey",
> > >         },
> > >   };
> > 
> > First of all, this is the wrong device. Further down is listed a
> > second
> > machine, the da9062, with more subdevices:
> > 
> > static const struct mfd_cell da9062_devs[] = { 
> >  { 
> >  .name = "da9062-core", 
> >  .num_resources = ARRAY_SIZE(da9062_core_resources), 
> >  .resources = da9062_core_resources, 
> >  }, 
> >  { 
> >  .name = "da9062-regulators", 
> >  .num_resources = ARRAY_SIZE(da9062_regulators_resources), 
> >  .resources = da9062_regulators_resources, 
> >  }, 
> >  { 
> >  .name = "da9062-watchdog", 
> >  .num_resources = ARRAY_SIZE(da9062_wdt_resources), 
> >  .resources = da9062_wdt_resources, 
> >  .of_compatible = "dlg,da9062-watchdog", 
> >  }, 
> >  { 
> >  .name = "da9062-thermal", 
> >  .num_resources = ARRAY_SIZE(da9062_thermal_resources), 
> >  .resources = da9062_thermal_resources, 
> >  .of_compatible = "dlg,da9062-thermal", 
> >  }, 
> >  { 
> >  .name = "da9062-rtc", 
> >  .num_resources = ARRAY_SIZE(da9062_rtc_resources), 
> >  .resources = da9062_rtc_resources, 
> >  .of_compatible = "dlg,da9062-rtc", 
> >  }, 
> >  { 
> >  .name = "da9062-onkey", 
> >  .num_resources = ARRAY_SIZE(da9062_onkey_resources), 
> >  .resources = da9062_onkey_resources, 
> >  .of_compatible = "dlg,da9062-onkey", 
> >  }, 
> >  { 
> >  .name = "da9062-gpio", 
> >  .num_resources = ARRAY_SIZE(da9062_gpio_resources), 
> >  .resources = da9062_gpio_resources, 
> >  .of_compatible = "dlg,da9062-gpio", 
> >  }, 
> > };
> > 
> > > 
> > > Not sure why "da9061-core" is even in there.  It looks like this
> > > would
> > > be referencing itself (if this driver's name contained the "-
> > > core"
> > > element).  So what from I can tell, I think this entry should
> > > actually
> > > just be removed.
> > > 
> > > With regards to "da9062-regulators", this looks like an oversight
> > > at
> > > best or a Linux hack at worst.  Device Tree is designed to be OS
> > > agnostic.  It should describe the H/W as-is, which would include
> > > the
> > > Regulator functionality.  Choosing to opt-out and instead use
> > > Linux
> > > specific systems (i.e. MFD) for device registration is a hack.
> > 
> > I think you're right here. But this is design specific and has not
> > much
> > to do with my request.
> > > 
> > > I've always said we should not mix DT and MFD in this way.
> > > 
> > > > Since the driver iterates through the mfd_cells-struct tries
> > > > matching
> > > > compatibles in the devicetree MFD node, it throws a warning
> > > > when
> > > > there
> > > > is no counterpart in the devicetree.
> > > > 
> > > > In fact, I could also evalutate oder devicetree's using MFD-
> > > > devices
> > > > not
> > > > to it's full content.
> > > >  
> > > > > 
> > > > > Probably worth popping that in the commit message too.
> > > > 
> > > > Yes, I will send a v2 ASAP. Thank you for the advice.
> > > 
> > > I think the current code is fine as it is.
> > > 
> > > It's the implementation that needs to change.
> > > 
> > > Maybe Steve would like to comment?
> > > 
> > 
> > The problem I want to address lies in the mfd_add_device function
> > in
> > the mfd-core:
> > 
> >     if (IS_ENABLED(CONFIG_OF) && parent->of_node && cell-
> > > of_compatible) {          
> >         for_each_child_of_node(parent->of_node, np)
> > {                 
> >             if (of_device_is_compatible(np, cell->of_compatible))
> > {   
> >                 /* Ignore 'disabled' devices error free
> > */            
> >                 if (!of_device_is_available(np))
> > {                    
> >                     ret =
> > 0;                                          
> >                     goto
> > fail_alias;                                  
> >                
> > }                                                     
> >                                                                    
> >   
> >                 ret = mfd_match_of_node_to_dev(pdev, np,
> > cell);       
> >                 if (ret == -
> > EAGAIN)                                   
> >                    
> > continue;                                         
> >                 if
> > (ret)                                              
> >                     goto
> > fail_alias;                                  
> >                                                                    
> >   
> >                
> > break;                                                
> >            
> > }                                                         
> >        
> > }                                                             
> >                                                                    
> >   
> >         if (!pdev-
> > >dev.of_node)                                       
> >             pr_info("%s: Failed to locate of_node [id:
> > %d]\n",        
> >                 cell->name,
> > platform_id);                             
> >     }
> > 
> > Interestingly, all subdevices defined in the driver are registered
> > as
> > platform devices from the MFD framework, regardless of a devicetree
> > entry or not. The preceding code checks the subdevice cells with an
> > additional compatible. In case a device has no devicetree entry, an
> > irritating failed-message is printed on the display. I'm not sure
> > if
> > this was the intention but the framework somehow forces the users
> > to
> > describe all subdevices of an MFD. I think the info print is not
> > needed. It makes more sense to set it as a debug print.
> 
> My current understanding is that; it's far more likely that the
> driver's use of the API is incorrect than the print itself.  I need
> to
> spend more time on this (time is no my friend at this present moment)
> in order to fully understand what's happening though.  Please bear
> with me.

Oh sorry, it wasn't my intention to push you :). Please take your time.


-- 
Mit freundlichen Grüßen
Yunus Bas

-Software Engineer-
PHYTEC Messtechnik GmbH
Robert-Koch-Str. 39
55129 Mainz
Germany
Tel.: +49 (0)6131 9221- 466
Web: www.phytec.de

Sie finden uns auch auf: Facebook, LinkedIn, Xing, YouTube

PHYTEC Messtechnik GmbH | Robert-Koch-Str. 39 | 55129 Mainz, Germany
Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber |
Handelsregister Mainz HRB 4656 | Finanzamt Mainz | St.Nr. 266500608, DE
149059855
This E-Mail may contain confidential or privileged information. If you
are not the intended recipient (or have received this E-Mail in error)
please notify the sender immediately and destroy this E-Mail. Any
unauthorized copying, disclosure or distribution of the material in
this E-Mail is strictly forbidden.


  reply	other threads:[~2021-06-29  9:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16  8:19 [PATCH] mfd: mfd-core: Change "Failed to locate of_node" warning to debug Yunus Bas
2021-06-16  9:03 ` Lee Jones
2021-06-17  7:46   ` Yunus Bas
2021-06-17  8:27     ` Lee Jones
2021-06-29  7:25       ` Yunus Bas
2021-06-29  9:07         ` Lee Jones
2021-06-29  9:41           ` Yunus Bas [this message]
2021-06-29 13:39         ` Lee Jones
2021-06-30  7:27           ` Yunus Bas
2021-06-30  8:42             ` Lee Jones
2021-06-30 10:55             ` Daniel Thompson
2021-06-30 12:33               ` Lee Jones
2021-07-01 15:34                 ` Yunus Bas
2021-07-01 16:45                   ` Lee Jones
2021-07-02 12:59                   ` Daniel Thompson
2021-07-02 18:36                     ` Lee Jones
2021-07-02 19:10                       ` Daniel Thompson
2021-07-05  7:24                         ` Yunus Bas
2021-07-05  7:31                           ` Lee Jones
2021-07-05  7:50                             ` Yunus Bas
2021-07-05  8:05                               ` 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=b09a0919fb33cb7562f1902d461dcf830e925858.camel@phytec.de \
    --to=y.bas@phytec.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stwiss.opensource@diasemi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).