public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v6] net: ll_temac: Add LL TEMAC driver to u-boot
Date: Mon, 28 Nov 2011 12:11:24 +0100	[thread overview]
Message-ID: <4ED36C5C.9080802@monstr.eu> (raw)
In-Reply-To: <1322424370.3870.370.camel@keto>

Stephan Linz wrote:
> Am Sonntag, den 27.11.2011, 20:09 +0100 schrieb Wolfgang Denk: 
>> Dear Stephan Linz,
>>
>> In message <1322419397-26326-2-git-send-email-linz@li-pro.net> you wrote:
>>> Xilinx LocalLink Tri-Mode Ether MAC driver can be
>>> used by Xilinx Microblaze or Xilinx ppc405/440 in
>>> SDMA and FIFO mode. DCR or XPS bus can be used.
>>>
>>> The driver uses and requires MII and PHYLIB.
>>>
>>> Signed-off-by: Stephan Linz <linz@li-pro.net>
>> ...
>>
>>> +static inline void xps_ll_temac_check_status(struct temac_reg *regs, u32 mask)
>>> +{
>>> +	unsigned timeout = 2000;
>>> +	while (timeout && (!(in_be32(&regs->rdy) & mask)))
>>> +		timeout--;
>> This has been asked before:  what exactly is the limit for the timeout
>> here?  2000 loops though that loop is not exactly a known value.
>> Please add some udelay() here (which is also good for triggering the
>> watchdog, should you have one running).
> 
> Hi Wolfgang,
> 
> I'll try to make the timeout handling more precise. Your argument with
> the watchdog is an interesting issue I forget completely. Thanks for the
> hint.
> 
>>
>>> +	if (!timeout)
>>> +		printf("%s: Timeout\n", __func__);
>> Why is this function void when you are know that you might have to
>> handle error situations (like a timeout)?
>>
>>> +static void xps_ll_temac_hostif_set(struct eth_device *dev, u8 phy_addr,
>>> +					u8 reg_addr, u16 phy_data)
>>> +{
>>> +	struct temac_reg *regs = (struct temac_reg *)dev->iobase;
>>> +
>>> +	out_be32(&regs->lsw, (phy_data & LSW_REGDAT_MASK));
>>> +	out_be32(&regs->ctl, CTL_WEN | TEMAC_MIIMWD);
>>> +	out_be32(&regs->lsw,
>>> +		((phy_addr << LSW_PHYAD_POS) & LSW_PHYAD_MASK) |
>>> +		(reg_addr & LSW_REGAD_MASK));
>>> +	out_be32(&regs->ctl, CTL_WEN | TEMAC_MIIMAI);
>>> +	xps_ll_temac_check_status(regs, RSE_MIIM_WR);
>>> +}
>> So what happens here if we have a timeout in
>> xps_ll_temac_check_status()?  SHould such an error not be handled?
> 
> Yes we should. I'll fix it.
> 
> 
>>> + * Undirect hostif read to ll_temac.
>> "Undirect"??  Or "Indirect" ?
>> "read to"??  Or "read from" ?
>>
>> Please fix globally.
> 
> yep.
> 
>>> +#ifdef DEBUG
>>> +static inline void read_phy_reg(struct eth_device *dev, u8 phy_addr)
>>> +{
>>> +	int j, result;
>>> +	debug("phy%d ", phy_addr);
>> Please always have one blank line between declarations and code.
>> Please fix globally.
> 
> yep.
> 
>>> +	if (ll_temac->ctrlreset)
>>> +		if (ll_temac->ctrlreset(dev))
>>> +			return -1;
>> Braces needed for multiline statements.  Please fix globally.
> 
> yep.
> 
>>> +/* halt device */
>>> +static void ll_temac_halt(struct eth_device *dev)
>>> +{
>>> +#ifdef ETH_HALTING
>>> +	struct ll_temac *ll_temac = dev->priv;
>>> +
>>> +	/* Disable Receiver */
>>> +	xps_ll_temac_indirect_set(dev, TEMAC_RCW0, 0);
>>> +
>>> +	/* Disable Transmitter */
>>> +	xps_ll_temac_indirect_set(dev, TEMAC_TC, 0);
>>> +
>>> +	if (ll_temac->ctrlhalt)
>>> +		ll_temac->ctrlhalt(dev);
>>> +#endif
>>> +}
>> ETH_HALTING is permanently undef'ed, so all this is dead code.  Please
>> remove.
> 
> @Michal: Is there any platform which can not halt the TEMAC? I have no
> problem with this code but I left ETH_HALTING undefined from original
> driver code. I would like to remove all the ETH_HALTING statements and
> hold this code.

I am not aware about any problem with halting. I had it there for debugging
purpose. You can simple remove ETH_HALTING statemets.

Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

  parent reply	other threads:[~2011-11-28 11:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-27 18:43 [U-Boot] LL TEMAC V6 refactored Stephan Linz
2011-11-27 18:43 ` [U-Boot] [PATCH v6] net: ll_temac: Add LL TEMAC driver to u-boot Stephan Linz
2011-11-27 19:09   ` Wolfgang Denk
2011-11-27 20:06     ` Stephan Linz
2011-11-27 22:29       ` Wolfgang Denk
2011-11-29 19:55         ` Stephan Linz
2011-11-28 11:06       ` Michal Simek
2011-11-28 11:11       ` Michal Simek [this message]
2011-11-28 11:35 ` [U-Boot] LL TEMAC V6 refactored Michal Simek
  -- strict thread matches above, loose matches on Subject: below --
2011-12-22 16:06 [U-Boot] [PATCH v6] net: ll_temac: Add LL TEMAC driver to u-boot Ricardo Ribalda Delgado
2011-12-22 18:52 ` Stephan Linz
2011-12-22 18:58   ` Ricardo Ribalda Delgado
2011-12-22 19:29     ` Stephan Linz
2011-12-22 21:03 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED36C5C.9080802@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox