linux-kernel - RE: [PATCH v2 2/4] mfd: Add RZ/V2M PWC core driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 Jan 2023 15:46:56 +0000
From:   Fabrizio Castro <fabrizio.castro.jz@...esas.com>
To:     Lee Jones <lee@...nel.org>
CC:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Sebastian Reichel <sre@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Jacopo Mondi <jacopo@...ndi.org>
Subject: RE: [PATCH v2 2/4] mfd: Add RZ/V2M PWC core driver

Hi Lee,

Thanks for your reply.

> 
> On Tue, 03 Jan 2023, Fabrizio Castro wrote:
> 
> > Hi Lees,
> >
> > Thanks for your feedback!
> >
> Could you please tell your mailer to remove mail headers from the body
> please.

I wish my mailer could that automatically. I need to remember to manually
remove it, and sometimes I forget, sadly.

> > >
> > > Could you both elaborate further please?
> >
> > I have nothing against MFD
> 
> Okay, just checking.  I'll withdraw my next command then. :)
> 
> $ rm -rf drivers/mfd

:)

> 
> > > If you do not have any resources to share, you can simply register
> each
> > > of the devices via Device Tree.  I do not see a valid reason to force
> a
> > > parent / child relationship for your use-case.
> >
> > There would probably be overlapping on the same memory region, which
> would
> > lead to ioremapping the same region multiple times, which is something
> > I would prefer to avoid if possible.
> 
> Okay, so you *do* have shared resources.
> 
> In which case, why is simple-mfd not working for you?

The corresponding dt-bindings got rejected, unfortunately. I had to drop
simple-mfd as a result of dropping the children of my simple-mfd DT node.

> 
> > > Many people attempt to use MFD as a dumping ground / workaround for a
> > > bunch of reasons.  Some valid, others not so much.
> >
> > As it turns out, it looks like I don't have valid reasons to use MFD,
> > therefore I'll switch to a single, non MFD, driver.
> >
> > Thank you for taking the time to look into this though! Really
> > appreciated.
> 
> Although it is considered okay to have a multi-purpose driver in any one
> of the subsystems, it's sometimes nicer to split the various
> functionality to be looked after (maintained) by their respective
> subject matter experts.

I am 100% with you. That would be my preference, too.

> You have to do what's right in any given
> situation.
> 
> Ultimately it's a call you need to make with the maintainer(s).

Yeah, that's why the change of direction.

Thanks,
Fab

> 
> --
> Lee Jones [李琼斯]