linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH v1 0/6] mfd: Make use of software nodes
Date: Wed, 17 Jun 2020 00:40:35 +0300	[thread overview]
Message-ID: <CAHp75VfZMx8ip=Bo=gZQiGufJvh=7dtr61C3ZcZjETFrErTk6Q@mail.gmail.com> (raw)
In-Reply-To: <20200616200225.32mwzew3zw3nuiwh@mobilestation>

On Tue, Jun 16, 2020 at 11:03 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> On Mon, Jun 08, 2020 at 04:42:54PM +0300, Andy Shevchenko wrote:
> > Some devices would need to have a hierarchy of properties and
> > child nodes passed to the child or children of MFD. For such case
> > we may utilize software nodes, which is superior on device properties.
> >
> > Add support of software nodes to MFD core and convert one driver
> > to show how it looks like. This allows to get rid of legacy platform
> > data.
> >
> > The change has been tested on Intel Galileo Gen 2.
>
> I am wondering whether we could move the {gpio_base, ngpio, irq_shared}
> part into the gpio-dwapb.c driver and use either the ACPI-based or
> platform_device_id-based matching to get the device-specific resources
> info through the driver_data field. By doing so you wouldn't need to
> introduce a new "snps,gpio-base"-like property and propagate
> software_node-based properties, but still you could get rid of the
> dwapb_platform_data structure since all the info would be locally
> available.

The idea is to get rid of the driver being dependent on some quirks
when we may do it clearly and nicely.
We, by applying this series, make (keep) layers independent: board
code vs. driver code. Mixing them more is the opposite to what I
propose.

WRT property.
snps,gpio-base can be easily changed to *already in use* gpio-base or
being both converted to linux,gpio-base to explicitly show people that
this is internal stuff that must not be present in firmware nodes.

> If ACPI-based matching doesn't uniquely address the Quark GPIO node,
> then you could just replace the intel_quark_mfd_cells[0].name with
> something like "gpio-dwapb-quark", which then by the MFD core will be
> copied to the corresponding platform_device->name due to calling
> platform_device_alloc() with cell-name passed. That name will be used
> to match a platform_driver with id_table having that new name added.

Oh, that doesn't sound right. It makes things ugly.

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2020-06-16 21:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 13:42 [PATCH v1 0/6] mfd: Make use of software nodes Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 1/6] gpio: dwapb: Replace irq_shared flag with fwnode type check Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 2/6] gpio: dwapb: Read GPIO base from snps,gpio-base property Andy Shevchenko
2020-06-10 11:26   ` Linus Walleij
2020-06-10 13:41     ` Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 3/6] mfd: core: Propagate software node group to the sub devices Andy Shevchenko
2020-06-08 19:25   ` Lee Jones
2020-06-09 12:40     ` Andy Shevchenko
2020-06-17 12:51       ` Lee Jones
2020-06-08 13:42 ` [PATCH v1 4/6] mfd: intel_quark_i2c_gpio: Convert to use software nodes Andy Shevchenko
2020-06-10 11:38   ` Linus Walleij
2020-06-10 13:43     ` Andy Shevchenko
2020-06-08 13:42 ` [PATCH v1 5/6] gpio: dwapb: Get rid of legacy platform data Andy Shevchenko
2020-06-10 11:39   ` Linus Walleij
2020-06-10 13:47     ` Andy Shevchenko
2020-06-08 13:43 ` [PATCH v1 6/6] gpio: dwapb: Define magic number for IRQ and GPIO lines Andy Shevchenko
2020-06-16 20:02 ` [PATCH v1 0/6] mfd: Make use of software nodes Serge Semin
2020-06-16 21:40   ` Andy Shevchenko [this message]
2020-06-16 22:56     ` Serge Semin
2020-06-18  8:56       ` Andy Shevchenko
2020-06-19 22:12         ` Serge Semin
2020-06-20 10:13           ` Andy Shevchenko
2020-06-23  1:49             ` Serge Semin
2020-06-24 12:43               ` Andy Shevchenko

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='CAHp75VfZMx8ip=Bo=gZQiGufJvh=7dtr61C3ZcZjETFrErTk6Q@mail.gmail.com' \
    --to=andy.shevchenko@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=fancer.lancer@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).