From: Evan Green <evgreen@chromium.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Peter Rosin <peda@axentia.se>, Wolfram Sang <wsa@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Peter Korsgaard <peter.korsgaard@barco.com>,
linux-i2c <linux-i2c@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v3 2/2] i2c: i2c-mux-gpio: Enable this driver in ACPI land
Date: Wed, 9 Dec 2020 15:03:29 -0800 [thread overview]
Message-ID: <CAE=gft6_YYszA8k8zALEcDR9LbEtUG8RQKRB793vPgDqdGd7Fw@mail.gmail.com> (raw)
In-Reply-To: <CAE=gft4LDh7TmvMgL4_eov5=1Nh0PYVRDxn4eCLsDd5JJyCwAw@mail.gmail.com>
Very sorry to ping. Is there anything I can do to help get this reviewed?
-Evan
On Mon, Nov 30, 2020 at 11:11 AM Evan Green <evgreen@chromium.org> wrote:
>
> Hi Andy, Peter,
>
> On Fri, Nov 20, 2020 at 10:59 AM Evan Green <evgreen@chromium.org> wrote:
> >
> > On Thu, Nov 19, 2020 at 7:24 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > >
> > > On Thu, Nov 19, 2020 at 1:40 AM Evan Green <evgreen@chromium.org> wrote:
> > > >
> > > > Enable i2c-mux-gpio devices to be defined via ACPI. The idle-state
> > > > property translates directly to a fwnode_property_*() call. The child
> > > > reg property translates naturally into _ADR in ACPI.
> > > >
> > > > The i2c-parent binding is a relic from the days when the bindings
> > > > dictated that all direct children of an I2C controller had to be I2C
> > > > devices. These days that's no longer required. The i2c-mux can sit as a
> > > > direct child of its parent controller, which is where it makes the most
> > > > sense from a hardware description perspective. For the ACPI
> > > > implementation we'll assume that's always how the i2c-mux-gpio is
> > > > instantiated.
> > >
> > > ...
> > >
> > > > +#ifdef CONFIG_ACPI
> > > > +
> > > > +static int i2c_mux_gpio_get_acpi_adr(struct device *dev,
> > > > + struct fwnode_handle *fwdev,
> > > > + unsigned int *adr)
> > > > +
> > > > +{
> > > > + unsigned long long adr64;
> > > > + acpi_status status;
> > > > +
> > > > + status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwdev),
> > > > + METHOD_NAME__ADR,
> > > > + NULL, &adr64);
> > > > +
> > > > + if (!ACPI_SUCCESS(status)) {
> > > > + dev_err(dev, "Cannot get address\n");
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + *adr = adr64;
> > > > + if (*adr != adr64) {
> > > > + dev_err(dev, "Address out of range\n");
> > > > + return -ERANGE;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +#else
> > > > +
> > > > +static int i2c_mux_gpio_get_acpi_adr(struct device *dev,
> > > > + struct fwnode_handle *fwdev,
> > > > + unsigned int *adr)
> > > > +{
> > > > + return -EINVAL;
> > > > +}
> > > > +
> > > > +#endif
> > >
> > > I'm wondering if you may use acpi_find_child_device() here.
> > > Or is it a complementary function?
> >
> > I think it's complementary. The code above is "I have a device, I want
> > its _ADR". whereas acpi_find_child_device() is "I have an _ADR, I want
> > its device". I could flip things around to use this, but it would turn
> > the code from linear into quadratic. I'd have to scan each possible
> > address and call acpi_find_child_device() with that _ADR to see if
> > there's a child device there.
> >
> > >
> > > ...
> > >
> > > > + device_for_each_child_node(dev, child) {
> > > > + if (is_of_node(child)) {
> > > > + fwnode_property_read_u32(child, "reg", values + i);
> > > > +
> > > > + } else if (is_acpi_node(child)) {
> > > > + rc = i2c_mux_gpio_get_acpi_adr(dev, child, values + i);
> > > > + if (rc)
> > > > + return rc;
> > > > + }
> > > > +
> > > > i++;
> > > > }
> > >
> > > And for this I already told in two different threads with similar code
> > > that perhaps we need common helper that will check reg followed by
> > > _ADR.
> >
> > Oh, I'm not aware of those threads. I'd need some advice: I guess a
> > new fwnode_* API would make sense for this, but I had trouble coming
> > up with a generic interface. _ADR is just a blobbo 64 bit int, but
> > DT's "reg" is a little more flexible, having a length, and potentially
> > being an array. I suppose it would have to be something like:
> >
> > int fwnode_property_read_reg(const struct fwnode_handle *fwnode,
> > size_t index, uint64_t *addr, uint64_t *len);
> >
> > But then ACPI would always return 0 for length, and only index 0 would
> > ever work? I'm worried I'm designing an API that's only useful to me.
> >
> > I tried to look around for other examples of this specific pattern of
> > _ADR then "reg", but struggled to turn up much.
>
> Any thoughts on this?
>
> > -Evan
> >
> > >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
next prev parent reply other threads:[~2020-12-09 23:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 23:40 [RESEND PATCH v3 0/2] i2c: i2c-mux-gpio: Enable this driver in ACPI land Evan Green
2020-11-18 23:40 ` [RESEND PATCH v3 1/2] i2c: i2c-mux-gpio: Factor out pdev->dev in _probe_dt() Evan Green
2021-01-15 9:30 ` Peter Rosin
2021-01-17 11:53 ` Wolfram Sang
2020-11-18 23:40 ` [RESEND PATCH v3 2/2] i2c: i2c-mux-gpio: Enable this driver in ACPI land Evan Green
2020-11-19 15:25 ` Andy Shevchenko
2020-11-20 18:59 ` Evan Green
2020-11-30 19:11 ` Evan Green
2020-12-09 23:03 ` Evan Green [this message]
2021-01-05 10:25 ` Wolfram Sang
2021-01-14 18:17 ` Evan Green
2021-01-14 19:53 ` Wolfram Sang
2021-01-15 9:29 ` Peter Rosin
2021-01-19 12:10 ` Andy Shevchenko
2021-01-17 11:54 ` Wolfram Sang
2021-01-17 17:15 ` Evan Green
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='CAE=gft6_YYszA8k8zALEcDR9LbEtUG8RQKRB793vPgDqdGd7Fw@mail.gmail.com' \
--to=evgreen@chromium.org \
--cc=andy.shevchenko@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=peter.korsgaard@barco.com \
--cc=rdunlap@infradead.org \
--cc=wsa@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).