[PATCH v3] ethernet/arc/arc_emac - Add new driver

Andy Shevchenko andy.shevchenko at gmail.com
Fri Jun 14 06:50:41 EST 2013


On Thu, Jun 13, 2013 at 11:25 PM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> On 06/13/2013 10:25 PM, Andy Shevchenko wrote:
>> On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
>> <Alexey.Brodkin at synopsys.com> wrote:
>>> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
>>> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
>>> ARCAngel4/ML50x.

>>> +++ b/drivers/net/ethernet/arc/arc_emac.h

> And what about function names? Do you think it worth to shorten them too
> since most of them aren't visible outside (static).

It's better to keep them in their namespace. So, leave them as is.

>>> +struct arc_emac_priv {

>>> +};

>> It seems you missed my comments against the names of the members. Can
>> you address them or comment why not?
>
> You mean to add description in kerneldoc format for all the fields in
> structures?

Not only that one. About member names as well.

> Well while in general it could be "a proper way" of documenting sources
> I found it not that convenient especially in case of really long structures.

> In my case "arc_emac_priv" structure has 21 members, so right before
> structure itself there will be another at least 21 line of comments.

Not an argument, you understand.

> Moreover: "The kernel-doc function comments describe each parameter to
> the function, in order, with the @name lines."

> While I don't think that each and every member needs description.

Describe them in couple of words.

> At
> least some pairs like Tx/Rx I believe may share the only comment saying
> "Pointers to BD rings - CPU side".

What BD means? May be it worth to describe as well?

> Also I barely can find an example of strict usage of kernel-doc format
> for data structures in drivers nearby.
>
> For example take a look at STMMAC - drivers/net/ethernet/stmicro/stmmac/
> Lots of structures defined, non with kernel-doc description.

Again, not an excuse :-)

> Still you think the only way to go is to add kernel-doc description then
> I'll add it ASAP, might be it will be a good example for other developers.

Right.

>>> +++ b/drivers/net/ethernet/arc/arc_emac_main.c
>>

>>> +static int arc_emac_poll(struct napi_struct *napi, int budget)
>>> +{

>>> +       unsigned int i, loop, work_done = 0;

>>> +       for (loop = 0; loop < RX_BD_NUM; loop++) {

>>> +               work_done++;
>>> +               if (work_done >= budget)
>>> +                       break;
>>
>> Those three could easily go to the for () on the top of this function.
>
> Correct. It should be like this on top of the "arc_emac_poll":
> ====
>                 if (work_done >= budget)
>                         break;
>                 work_done++;
> ====

I meant something like
for (loop = 0; loop < RX_BD_NUM && work_done < budget; loop++, work_done++)

>>> +static int arc_emac_open(struct net_device *ndev)
>>> +{
>>
>>> +       /* Set Poll rate so that it polls every 1 ms */
>>> +       arc_reg_set(priv, R_POLLRATE,
>>> +                    priv->clock_frequency / 1000000);
>>
>> I don't understand how you end up with 1ms here. 1000000 is just a
>> magic number, clock_frequency generally is an arbitrary value.

I meant how do you guarantee this is 1ms? What if clock_frequency is not 100MHz?

--
With Best Regards,
Andy Shevchenko


More information about the devicetree-discuss mailing list