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

[Detlev Zundel <dzu@denx.de>]

Hi Mike,

> 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
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.

>> > 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.

Having said that, I have to admit that in the concrete case of the heaps
of defines doing nothing serious, I don't see a big problem either.

>> > > 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?

Cheers
  Detlev

-- 
Shin: a device for finding furniture in the dark.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de