[U-Boot-Users] [PATCH/review] Blackfin: add support for BF538/BF539

[Mike Frysinger <vapier@gentoo.org>]

On Wednesday 04 June 2008, Detlev Zundel wrote:
> > On Sunday 01 June 2008, Wolfgang Denk wrote:
> >> In message <200806011718.32290.vapier@gentoo.org> you wrote:
> >> > > What is the licensing of this file, and who is the Copyright holder?
> >> >
> >> > it's all ADI written and owned.  we dont particularly care about the
> >> > license,
> >>
> >> Ummm... Mike, you are a well-know contributor to Free Software. Such a
> >> statement from someone like you is kind of a shock to me.
> >
> > the code in question is autogenerated.  people sniping it is no sweat off
> > our back.  in general, my willingness to freely give all my code away
> > doesnt mean i subscribe to the FSF mentality.
>
> Um actually, caring that a project stears clean of copyright violations

copyright violations != licensing violations

> that may later be used to take down the whole project has got zero to do
> with subscribing to "the FSF mentatlity".  Thinking about it, it doesn't
> even make sense to me that you express your distaste of the FSF from
> such a non-correlated topic.

i dont think people really care what my opinion is on the matter and it is 
certainly off topic on this list

> >> > but i guess i can tag it GPL-2.
> >>
> >> Your guess is not good enough. We need to know for sure. And if it's
> >> owned by ADI *you* cannot do that.
> >
> > i most certainly can.  seeing as how i'm an ADI employee and they've
> > given me carte blanche for managing this code and seeing as how i'm the
> > one who actually wrote all of it in the first place ...
>
> Those are arguments from common sense, but you also know that copyright
> violations ultimately will be decided by legal people.  Don't take such
> an important topic so lightheartedly.  This is really important for the
> whole project.

it isnt just common sense, it's fact.

> >> > > I do not think that we should allow such code in U-Boot.
> >> >
> >> > it is the designed programming style for all low level Blackfin
> >> > systems. it is unified across Linux, U-Boot, bare metal code, and the
> >> > official ADI propriety compiler.  i thought your point was to keep
> >> > U-Boot and Linux the same at the API level so code sharing is very
> >> > easy between it ?
> >>
> >> Yes, that's what we normally do.
> >>
> >> However here I'm really uncertain. Actually I am deeply disappointed
> >> that such code made it into the Linux kernel. This should have never
> >> happened.
> >
> > there was already a debate on lkml on the topic about obvious pros/cons,
> > but the code that's here is the result.  we take the stance of putting
> > more logic into the headers/arch code so that end developers (like
> > drivers) get a much easier time.  after all, the core stuff (like this)
> > rarely changes whereas end/drivers constantly churn.  we've already seen
> > substantially easier to manage drivers as a result in the kernel.
>
> As I did not follow this discussion, can you enlighten me to what the
> *actual* positive effect of defines like the following is (random pick)?
>
> #define pVR_CTL                        ((uint16_t volatile *)VR_CTL) /*
> Voltage Regulator Control Register (16-bit) */ #define bfin_read_VR_CTL()  
>           bfin_read16(VR_CTL)
> #define bfin_write_VR_CTL(val)         bfin_write16(VR_CTL, val)
>
> To me (as a simple code reader), this will ultimately only make the end
> c code harder to read.  As it does not contain all the details any more
> I potentially have to lookup every single define if I want to understand
> what is going on.
>
> Thinking hard, I cannot see a positive result.  At first I thought you
> may hide the actual data sizes in this define layer (disregarding the
> fact whether this is a good or bad thing to do), but this is not the
> case, as the types will permeate the layer.  So can you please tell me
> what positive effects this is supposed to have?

the data sizes are hidden from the developer (in so much that they dont need 
to worry about it in the important cases), we use functions to read/write 
values rather than pointers (which is common convention) and really is easier 
to read/manage), people dont have to look up random addresses in the HRM for 
their particular variant, etc...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080604/4d321eb5/attachment.pgp