All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <glikely@gmail.com>
To: Sylvain Munaut <tnt@246tnt.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC52xx: sysfs failure on adding new device driver
Date: Thu, 9 Jun 2005 08:54:42 -0600	[thread overview]
Message-ID: <528646bc05060907544d58da41@mail.gmail.com> (raw)
In-Reply-To: <42A827DC.8000803@246tNt.com>

On 6/9/05, Sylvain Munaut <tnt@246tnt.com> wrote:
>=20
> Grant Likely wrote:
> >>From what I can tell, I should be able to register more than one
> > driver for a particular device name (mpc52xx_psc).
>=20
> I always assumed that yes.
> But now looking more closely, I'm not sure what I based that assumption
> on ... And if not the case that's indeed a problem because that's what's
> used to support the different function supported by the PSCs.
I was assuming so too, and it seems that the device structure would
support it.  Who would know the answer to this?

>=20
> > Otherwise I would
> > need to change arch/ppc/syslib/mpc52xx_devices.c to have a different
> > name for each psc.
>=20
> No you shouldn't have to touch that. The
> mpc52xx_match_psc_function(idx, "spi") is there to know which driver
> should be used for what PSC and you're using it correctly so it _should_
> work.
I thought so, if I disable the mpc52xx_uart driver then my driver will
register correctly.  I agree that it is not desireable to touch
mpc52xx_devices.c
>=20
> > If I change the sysfs code to ignore the failure
> > to create a directory then the driver seems to register fine.
>=20
> A "better" quick-fix would be to change the platform_match
> (drivers/platform.c) to support "sub-fonctions". For example when using
> mpc52xx_psc.spi it only matches what's before the dot (if any) with the
> device name.
... so that a different directory will be created in sysfs for each
driver?  That's got possibilities.

>=20
> That changes the semantic of the driver names for the platform bus
> however, making the dot a "special" char.
Who needs to be asked about this?  Should I take this discussion over
the the LKML?

Thanks,
g.

  reply	other threads:[~2005-06-09 14:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-08 23:51 MPC52xx: sysfs failure on adding new device driver Grant Likely
2005-06-09 11:21 ` Mark Chambers
2005-06-09 11:32   ` Sylvain Munaut
2005-06-09 13:55     ` Wolfgang Denk
2005-06-09 15:28       ` Mark Chambers
2005-06-09 18:34         ` Grant Likely
2005-06-09 11:28 ` Sylvain Munaut
2005-06-09 14:54   ` Grant Likely [this message]
2005-06-09 15:20     ` Kumar Gala
2005-06-09 18:48       ` Grant Likely
2005-06-10 14:09         ` Sylvain Munaut
2005-06-10 16:06           ` Grant Likely
2005-06-13 19:08           ` Grant Likely
2005-06-09 19:56   ` Grant Likely

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=528646bc05060907544d58da41@mail.gmail.com \
    --to=glikely@gmail.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=tnt@246tnt.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.