From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Wim Van Sebroeck <wim@iguana.be>,
linux-gpio@vger.kernel.org,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
David Cohen <david.a.cohen@intel.com>,
Simon Guinot <simon.guinot@sequanux.org>,
Bruno Randolf <br1@einfach.org>,
platform-driver-x86 <platform-driver-x86@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Seth Heasley <seth.heasley@intel.com>,
Darren Hart <dvhart@linux.intel.com>,
kernel <kernel@savoirfairelinux.com>
Subject: Re: [PATCH] gpio: add GPIO support for SMSC SCH311x
Date: Tue, 10 Dec 2013 23:05:49 -0500 (EST) [thread overview]
Message-ID: <1395016599.620093.1386734749325.JavaMail.root@mail> (raw)
In-Reply-To: <CACRpkdZxjKamJvOMqdgN5zG5DrZvDNTCaVSiyaHSawkLxvUrFA@mail.gmail.com>
Hi Linus,
You wrote:
> > This patch adds support for the GPIOs found on the SMSC "Super I/O"
> > chips
> > SCH311x.
> >
> > The chip detection and I/O functions are copied from sch311x_wdt.c
> >
> > Signed-off-by: Bruno Randolf <br1@einfach.org>
> >
> > ---
> > Notes:
> > - All GPIOs are now supported, driver data is runtime allocated
> > and I tried to address all comments as far as possible.
> > - Still a platform device is registered, similar to gpio-f7188x.c
>
> So I have a problem with this design pattern so I need to ask
> Matthew Garret about this:
>
> - Driver *always* performs some port-mapped I/O probe on
> some random ports as a compulsory initcall.
>
> - No other hardware discovery.
>
> - If detecting magic, registers a platform device.
>
> - Then handles this device by also providing a device
> driver for it.
>
> - All of this is placed in one file.
>
> Matthew is this how discovery and registration of x86 platform
> drivers for port-mapped devices should work or are we doing
> something weird here?
>
> Since earlier we have:
>
> drivers/gpio/gpio-f7188x.c - exactly the same pattern
>
> drivers/gpio/gpio-it8761e.c - doesn't even bother to create a
> platform
> device, goes on and creates a gpio_chip without any device
>
> drivers/gpio/gpio-sch.c - port-mapped but platform device is
> created by an MFD which is probed from PCI (seems fine).
>
> drivers/gpio/gpio-ts5500.c - aha, created from
> arch/x86/platform/ts5500/ts5500.c, a "board file".
Because of the lack of mechanism such as DMI, there's no safe way to verify the
machine at the GPIO driver level. However, the board code (which registers the
platform device) does a safe check by looking for some magic in the RAM.
Would it be safer if we make GPIO_TS5500 depends on TS5500?
> This is a bit heterogeneous, but I can't claim to understand how
> x86 want to register its devices so need some input here.
>
> Maybe this is all the right way to do things, but I want to
> be hammered down by some convincing arguments first.
Best,
Vivien
next prev parent reply other threads:[~2013-12-11 4:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 0:23 [PATCH] gpio: add GPIO support for SMSC SCH311x Bruno Randolf
2013-12-04 1:06 ` David Cohen
2013-12-10 11:51 ` Linus Walleij
2013-12-10 17:05 ` Matthew Garrett
2013-12-11 4:05 ` Vivien Didelot [this message]
2013-12-12 19:50 ` Linus Walleij
2013-12-16 2:46 ` Vivien Didelot
2013-12-20 9:07 ` Linus Walleij
-- strict thread matches above, loose matches on Subject: below --
2013-11-28 0:18 Bruno Randolf
2013-11-29 14:40 ` Linus Walleij
2013-11-29 15:02 ` Mika Westerberg
2013-11-29 19:55 ` Linus Walleij
2013-11-29 17:21 ` Bruno Randolf
2013-11-29 20:00 ` Linus Walleij
2013-11-29 20:37 ` Simon Guinot
2013-12-04 12:33 ` Linus Walleij
2013-11-29 18:56 ` Simon Guinot
2013-12-02 12:43 ` Bruno Randolf
2013-12-05 16:56 ` Simon Guinot
2013-12-10 10:18 ` Bruno Randolf
2013-12-10 11:44 ` Simon Guinot
2013-12-10 12:19 ` Bruno Randolf
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=1395016599.620093.1386734749325.JavaMail.root@mail \
--to=vivien.didelot@savoirfairelinux.com \
--cc=br1@einfach.org \
--cc=david.a.cohen@intel.com \
--cc=dvhart@linux.intel.com \
--cc=kernel@savoirfairelinux.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=mjg59@srcf.ucam.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=seth.heasley@intel.com \
--cc=simon.guinot@sequanux.org \
--cc=wim@iguana.be \
/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).