[PATCH 1/2] gpio/mxc: get rid of the uses of cpu_is_mx()
Shawn Guo
shawn.guo at freescale.com
Wed Jul 6 01:21:53 EDT 2011
On Tue, Jul 05, 2011 at 06:42:38PM +0200, Sascha Hauer wrote:
> On Tue, Jul 05, 2011 at 11:32:28AM +0800, Shawn Guo wrote:
> > On Mon, Jul 04, 2011 at 09:04:55PM -0600, Grant Likely wrote:
> > > On Mon, Jul 4, 2011 at 9:01 PM, Shawn Guo <shawn.guo at freescale.com> wrote:
> > > > On Mon, Jul 04, 2011 at 06:44:57PM +0200, Sascha Hauer wrote:
> > > >> Read again. We have three different types of gpio irq controllers, they
> > > >> are first seen in the imx1, imx21 and imx31. So all others can be made
> > > >> compatible with these three. No need for imx-gpio, imx25-gpio and
> > > >> imx27-gpio. The mxc_gpio_devtype would look like this:
> > > >>
> > > >> static struct platform_device_id mxc_gpio_devtype[] = {
> > > >> {
> > > >> .name = "imx1-gpio",
> > > >> .driver_data = IMX1_GPIO,
> > > >> }, {
> > > >> .name = "imx21-gpio",
> > > >> .driver_data = IMX21_GPIO,
> > > >> }, {
> > > >> .name = "imx31-gpio",
> > > >> .driver_data = IMX31_GPIO,
> > > >> }, {
> > > >> }
> > > >> };
> > > >>
> > > > This is really what I want to do with dt match table. But before we
> > > > totally remove platform device probe and switch it over to dt, I'm
> > > > unsure we want to do this. It will require the following changes on
> > > > platform device code registration right now. I guess this is
> > > > something you do not want, right?
> > >
> > > What is the problem with the below changes? I see no issue with
> > > changing the static platform_device registrations in this way.
> > >
> > We end up to register "imx21-gpio" in imx27_soc_init, and "imx31-gpio"
> > in imx25/35/50/51/53 per-soc-init function. The may confuse people
> > who only look at platform device registration code. This is something
> > may concern Sascha. Let's see what he thinks.
>
> If we vote for doing this in the device tree then I see no problem doing
> so in the platform registration code aswell.
>
That's great. Will do so in the v3.
--
Regards,
Shawn
More information about the linux-arm-kernel
mailing list