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

[Detlev Zundel <dzu@denx.de>]

Hi Mike,

>> Um actually, caring that a project stears clean of copyright violations
>
> copyright violations != licensing violations

Yes of course, you are right here.

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

Indeed, why did you bring it up then?

>> 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), 

Even if I don't like hiding data sizes at such a place, I cannot follow
your argument.  If you have correct typing on the called functions,
surely these types are in no way encapsulated by these shim-macros.

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

I also cannot follow this.  The macro substitution uses a symbolic
constant named exactly like the macro.  What _exactly_ is that giving
you?

To be honest, as far as I can see, all other architectures get by
without such "macros" without loosing anything and the arguments you
gave this far did not convince me that they are needed.

I do not even want to think about e.g. the 4xx maintainers coming up
with one macro per soc register...

Cheers
  Detlev

-- 
It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.
             -- Miles Bader in <20030607122005.GA1086@gnu.org>
--
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