From: "Markus Klotzbücher" <mk@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] PXA27x USB device
Date: Mon, 07 May 2007 13:55:41 +0200 [thread overview]
Message-ID: <871whsu9tu.fsf@denx.de> (raw)
In-Reply-To: <200705041347.13816.sr@denx.de> (Stefan Roese's message of "Fri, 4 May 2007 13:47:13 +0200")
Hi Stefan,
Stefan Roese <sr@denx.de> writes:
>> Hmm. Seems reasonable, especially if this structure will be used for all
>> drivers. But is this the case?
>
> It's a mess right now. Some cpu-specific drivers are under the drivers
> directory (like the fsl drivers/qe/* for example) and some in the cpu
> directories. We should move those drivers from time to time to the drivers
> directory. But this will take quite a while.
>
> If we have a consense with this location for the drivers, then at least we
> should start with moving *new* drivers directly into the "correct" place.
Yes, definitely. Now we only need to agree on where this is :-)
>> I still feel uncomfortable about placing
>> a cpu dependant host controller driver in a generic driver
>> directory. Will such a driver be maintained mainly by the USB Custodian
>> or the respective Architecture Custodian? I would assume the latter.
>
> This depends on the driver. If it's for example the ppc4xx ethernet driver it
> should be handled by the architecture custodian, but if it's the usb-ohci
> driver then it should be handled by the usb custodian. Most drivers will be
> handled (as they are right now) by the architecture custodian.
Yes, agreed.
> But I see your point. By moving those cpu-specific files into the drivers
> directory, the architecture custodians need to maintain files distributed all
> over the drivers directory and not specifically in the cpu/xxx directory. I
> never thought of this before.
This is why I favor the old way of storing cpu dependant drivers in the
appropriate cpu directory. This makes the responsibility clear and
allows to cleanly seperate arch and generic code. Isn't this similar to
linux where cpu dependant drivers are found in "arch/cpu/"?
Also, this is doesn't prohibit the cleaning up of "drivers" by adding
subsystem subdirectories for net, usb etc.
What do you think?
Best Regards
Markus Klotzb?cher
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2007-05-07 11:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-02 14:05 [U-Boot-Users] PXA27x USB device Rodolfo Giometti
2007-05-02 22:05 ` Bryan O'Donoghue
2007-05-03 7:49 ` Markus Klotzbücher
2007-05-03 8:29 ` Stefan Roese
2007-05-03 10:15 ` Rodolfo Giometti
2007-05-04 10:20 ` Markus Klotzbücher
2007-05-04 11:47 ` Stefan Roese
2007-05-04 12:31 ` Wolfgang Denk
2007-05-07 11:55 ` Markus Klotzbücher [this message]
2007-05-07 12:22 ` Stefan Roese
2007-05-07 13:23 ` Markus Klotzbücher
2007-05-07 15:22 ` Robert Schwebel
2007-05-07 19:58 ` Wolfgang Denk
2007-05-08 6:39 ` Markus Klotzbücher
2007-05-08 8:47 ` Rodolfo Giometti
2007-05-08 10:04 ` Markus Klotzbücher
2007-05-08 12:49 ` Rodolfo Giometti
2007-05-08 14:14 ` Loeliger Jon-LOELIGER
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=871whsu9tu.fsf@denx.de \
--to=mk@denx.de \
--cc=u-boot@lists.denx.de \
/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