From: Alistair Francis <email@example.com> To: Mark Brown <firstname.lastname@example.org> Cc: Lee Jones <email@example.com>, Alistair Francis <firstname.lastname@example.org>, Rob Herring <email@example.com>, firstname.lastname@example.org, dl-linux-imx <email@example.com>, Sascha Hauer <firstname.lastname@example.org>, devicetree <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org> Subject: Re: [PATCH v7 1/6] mfd: sy7636a: Initial commit Date: Fri, 30 Jul 2021 16:21:18 +1000 [thread overview] Message-ID: <CAKmqyKNUBzWuLSvLTqaCNhDpuficctvCgpk3ZEBVFuKeCrx86w@mail.gmail.com> (raw) In-Reply-To: <20210720202639.GE5042@sirena.org.uk> On Wed, Jul 21, 2021 at 6:26 AM Mark Brown <email@example.com> wrote: > > On Tue, Jul 20, 2021 at 05:09:02PM +0100, Lee Jones wrote: > > On Tue, 20 Jul 2021, Mark Brown wrote: > > > > At least the regulator probably shouldn't be - this is just a Linux > > > specific grouping of devices, it's not really directly a block in the > > > hardware in a way that's platform independent. > > > I've seen (and authored) regulator support in DT before. > > > What's changed? They're controlled by registers, right? > > Nothing's changed, I routinely push back on regulator drivers that have > a compatible string for a MFD subfunction like this. I do miss them > sometimes but try not to. Sorry, I just want to clarify what I should do. Are you saying that I shouldn't add the regulator to the device tree? Should I leave it as part of `sy7636a_cells` then? Alistair > > > Is the problem that the registers are usually split? > > It's just not really describing the hardware, it's encoding the way > Linux splits things up into the DT that adds no descriptive information. > We're not getting any information about where the IPs are in the device > or anything from the compatible, and typically it's describing a set of > disjoint IPs with minimal overlap in their configuration. If it's a > binding for something like an individual LDO or DCDC and we've got > multiple instances of that within a single chip then it starts to get > more useful but that's not what something like this is doing. We're not > gaining anything by putting a compatible string in there, all it does is > make the DT bigger and add some ABI. > > Similar issues exist with CODEC subfunctions - those are usually > describing huge piles of different IPs but we happen to want to pull > them together for Linux, typically including some clocking which if we > were going down to the level of describing components of the MFD in the > DT should be being described using their own bindings.
next prev parent reply other threads:[~2021-07-30 6:21 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-08 11:57 Alistair Francis 2021-07-08 11:58 ` [PATCH v7 2/6] thermal: sy7636a: Add thermal driver for sy7636a Alistair Francis 2021-07-20 15:02 ` Lee Jones 2021-07-28 8:23 ` Alistair Francis 2021-08-02 7:55 ` Lee Jones 2021-08-14 11:08 ` Daniel Lezcano 2021-07-08 11:58 ` [PATCH v7 3/6] hwmon: sy7636a: Add temperature " Alistair Francis 2021-07-20 14:59 ` Lee Jones 2021-08-02 9:48 ` Alistair Francis 2021-07-08 11:58 ` [PATCH v7 4/6] ARM: imx_v6_v7_defconfig: Enable silergy,sy7636a Alistair Francis 2021-07-08 11:58 ` [PATCH v7 5/6] ARM: dts: imx7d: remarkable2: " Alistair Francis 2021-07-08 11:58 ` [PATCH v7 6/6] ARM: dts: imx7d: remarkable2: Enable lcdif Alistair Francis 2021-07-20 14:53 ` [PATCH v7 1/6] mfd: sy7636a: Initial commit Lee Jones 2021-07-20 15:23 ` Mark Brown 2021-07-20 16:09 ` Lee Jones 2021-07-20 20:26 ` Mark Brown 2021-07-30 6:21 ` Alistair Francis [this message] 2021-07-30 11:13 ` Mark Brown 2021-08-02 9:26 ` Alistair Francis 2021-08-02 10:23 ` 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=CAKmqyKNUBzWuLSvLTqaCNhDpuficctvCgpk3ZEBVFuKeCrx86w@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v7 1/6] mfd: sy7636a: Initial commit' \ /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
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).