netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Magnus Damm <magnus.damm@gmail.com>
To: Patrick Pannuto <ppannuto@codeaurora.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"damm@opensource.se" <damm@opensource.se>,
	"lethal@linux-sh.org" <lethal@linux-sh.org>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"eric.y.miao@gmail.com" <eric.y.miao@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	alan@lxorguk.ukuu.org.uk, zt.tmzt@gmail.com
Subject: Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
Date: Thu, 5 Aug 2010 11:32:16 +0900	[thread overview]
Message-ID: <AANLkTimkMy6_201XNGb41e7LivkvVHMkFZWVoA-7UmBo@mail.gmail.com> (raw)
In-Reply-To: <4C59E654.1090403@codeaurora.org>

On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto <ppannuto@codeaurora.org> wrote:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> RFC: http://lkml.org/lkml/2010/8/3/496
> Patch is unchanged from the RFC. Reviews seemed generally positive
> and it seemed this was desired functionality.

Thanks for your patch, it's really nice to see work done in this area!
I'd like to see something like this merged in the not so distant
future. At this point I'm not so concerned about the details, so I'll
restrict myself to this:

> /drivers/my_driver.c
>        static struct platform_driver my_driver = {
>                .driver = {
>                        .name   = "my-driver",
>                        .owner  = THIS_MODULE,
>                        .bus    = &my_bus_type,
>                },
>        };

I would really prefer not to have the bus type in the here. I
understand it's needed at this point, but I wonder if it's possible to
adjust the device<->driver matching for platform devices to allow any
type of pseudo-platform bus_type.

The reason why I'd like to avoid having the bus type in the driver is
that I'd like to reuse the platform driver across multiple
architectures and buses. For instance, on the SH architecture and
SH-Mobile ARM we have SoCs with SCIF hardware blocks driven by the
sh-sci.c serial driver. The sh-sci.c platform driver supports a wide
range of different SCI(F)(A)(B) hardware blocks, and on any given SoC
there is a mix of SCIF blocks spread out on different buses.

At this point our SH platform drivers are unaware where their driver
instanced are located on the SoC. The I/O address and IRQs are
assigned via struct resource and clocks are managed through clkdev. I
believe that adding the bus type in the driver will violate this
abstraction and make it more difficult to just instantiate a driver
somewhere on the SoC.

> /somewhere/my_device.c
>        static struct platform_device my_device = {
>                .name           = "my-device",
>                .id             = -1,
>                .dev.bus        = &my_bus_type,
>                .dev.parent     = &sub_bus_1.dev,
>        };

This I don't mind at all. Actually, this is the place where the
topology should be defined IMO.

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2010-08-05  2:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 22:14 [PATCH] platform: Facilitate the creation of pseduo-platform busses Patrick Pannuto
2010-08-05  0:16 ` Kevin Hilman
2010-08-05  0:57   ` Patrick Pannuto
2010-08-05 15:57     ` Kevin Hilman
2010-08-05 16:31       ` Patrick Pannuto
2010-08-05 22:24         ` Kevin Hilman
2010-08-05 23:16       ` Grant Likely
2010-08-06  1:25         ` Patrick Pannuto
2010-08-07  6:53           ` Grant Likely
2010-08-05  2:32 ` Magnus Damm [this message]
2010-08-05 15:27   ` Kevin Hilman
2010-08-05 17:43   ` Patrick Pannuto

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=AANLkTimkMy6_201XNGb41e7LivkvVHMkFZWVoA-7UmBo@mail.gmail.com \
    --to=magnus.damm@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=damm@opensource.se \
    --cc=eric.y.miao@gmail.com \
    --cc=gregkh@suse.de \
    --cc=lethal@linux-sh.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ppannuto@codeaurora.org \
    --cc=rjw@sisk.pl \
    --cc=zt.tmzt@gmail.com \
    /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).