Building driver for Silicon Labs CP2200 Ethernet chip

[Arnout Vandecappelle]

Chris Johns wrote:
> Arnout Vandecappelle wrote:
>> Chris Johns wrote:
>>> Many thanks for this driver. I have a couple of questions, one of
>>> which is more generic than specific to this driver.
>>>
>>> When does a user need to use CP220X_DO_SHUTDOWN ? I cannot see any
>>> documentation about this define.
>>  Oops, indeed I forgot to document that.
>>
>>  The board I was using had a hardware bug, due to which it was unable to
>> issue a reset of the CP2200 chip.  Therefore, once the chip was shut
>> down it was impossible to start it again.  I therefore had to remove the
>> shutdown from the driver.
>>
>>  Probably a better option would be to record this in the driver
>> configuration, so it can be set from the BSP or from the
application... However, I discovered this problem only at the last
minute, so I didn't
>> implement it that way.
>>
>>  Actually, perhaps it's best to simply remove the #ifdefs: on any
>> working board, they shouldn't be needed and shutdown should always be
>> used.  Of course, I never tested that code...
>>
>
> Is the shutdown needed ?
 It saves 200mW; this is significant.

> Can the device be reinitialised with the driver if it needs to be ?
 Yes, on condition that the board and bsp provide the possibility to
trigger the reset pin (which is not the case on my board).

> If do I would leave the the defines and add a comment at the top to
 OK.

 Can you add this comment?

/*
 * CP220X_DO_SHUTDOWN
 *
 * This option is inserted into the code because the board on which this
driver
 * was developed does not allow a reset of the chip.  Resetting is the
only way
 * to exit from shutdown mode...
 *
 * Since this feature has never been tested, it remains disabled for
now.  If you'd
 * like to try it, enable this define in the header and make sure the bsp's
 * cp220x_do_reset_hard() is properly implemented (pulling the nRST pin
low).
 *
 * Note: without this define, the driver powers the chip down to "memory
mode"
 * when the interface is brought down.  Exit from memory mode is possible by
 * resetting PHY, which is done when the interface is brought up.
 */

>>> I see the driver has printf and being based on the cs8900 I am the
>>> source of this. Should we have these driver use printf or should they
>>> use printk now it exists ?
>>
>>  I'm not sure what exactly the difference is between printf and printk,
>> except that printk can be called from interrupt context.  Since none of
>> the prints are from interrupt context, and since with printk my terminal
>> tended to drop newlines, I went for printf...  I'm sure these are not
>> good reasons :-)
>>
>
> I used printf because printk did not exist then. The reason is to
support a tiny RTEMS for small memory targets. On targets that support
printf the printk call should map to stdout.
 Sounds like printk should be used then...  I'm afraid I did use some
formatters which are not supported by printk, like %hhx, %*s, %<length>s.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                     arnout at mind be
Senior Embedded Software Architect       +32-16-286540
Mind Embedded Development (an Essensium division)