From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx•com>
To: "Michal Simek" <Monstr@seznam•cz>, <microblaze-uclinux@itee•uq.edu.au>
Cc: linuxppc-dev@ozlabs•org
Subject: RE: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
Date: Tue, 23 Oct 2007 09:25:02 -0700 [thread overview]
Message-ID: <20071023162504.CAFF01690066@mail124-blu.bigfish.com> (raw)
In-Reply-To: <1837.2996-6584-798350907-1193112476@seznam.cz>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs•or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Michal Simek
> Sent: Monday, October 22, 2007 9:08 PM
> To: microblaze-uclinux@itee•uq.edu.au
> Cc: Leonid; Wolfgang Reissnegger; Arnd Bergmann;=20
> linuxppc-dev@ozlabs•org
> Subject: RE: [microblaze-uclinux] Re: [microblaze-uclinux]=20
> RE: [PATCH v3] Device tree bindings for Xilinx devices
>=20
> >> In my opinion will be better generate only parameters which=20
> >> you want not all.
> >> That smells with unusable parameters.
> >
> >In the long term, this may be true. In the short term:
> >1) dtb size is not the key problem
> Yes of course
> >2) making sure that everything works is a key problem.
> >3) The code that generates the dts should be as simple as possible,
> >so that we can easily document what it does.
> Yes but you must document every parameter which your generate=20
> do. The better way is=20
> document only parameters which you want use.
No, that's exactly my point. The generator should document what it
*does*
i.e. When there is a parameter in the EDK file, then such and such
corresponding parameter will be generated in the dts. The devices and
drivers
will inevitably change over time: your proposal would result in
an unnecessary maintenance headache... The documentation of what the
individual
parameters are should be unambiguous from the EDK documentation.
The only things that the generator should handle 'specially', in my
opinion
are parameters that need to be munged to be standard names.
Steve
next prev parent reply other threads:[~2007-10-23 16:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 17:22 [PATCH v3] Device tree bindings for Xilinx devices Grant Likely
2007-10-18 17:49 ` Stephen Neuendorffer
2007-10-18 18:12 ` Grant Likely
2007-10-18 19:04 ` Stephen Neuendorffer
2007-10-19 23:42 ` Stephen Neuendorffer
2007-10-20 2:28 ` [microblaze-uclinux] " Michal Simek
2007-10-20 5:47 ` Grant Likely
2007-10-20 7:05 ` Michal Simek
2007-10-22 18:06 ` [microblaze-uclinux] " Stephen Neuendorffer
2007-10-23 4:07 ` Michal Simek
2007-10-23 4:34 ` David Gibson
2007-10-23 7:34 ` Michal Simek
2007-10-23 14:01 ` Grant Likely
2007-10-24 0:05 ` David Gibson
2007-10-23 16:25 ` Stephen Neuendorffer [this message]
2007-10-20 5:38 ` Grant Likely
2007-10-22 0:29 ` David Gibson
2007-10-24 1:15 ` [microblaze-uclinux] " Stephen Neuendorffer
2007-10-24 1:43 ` David Gibson
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=20071023162504.CAFF01690066@mail124-blu.bigfish.com \
--to=stephen.neuendorffer@xilinx$(echo .)com \
--cc=Monstr@seznam$(echo .)cz \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=microblaze-uclinux@itee$(echo .)uq.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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