> "Peter" == Peter Korsgaard <[EMAIL PROTECTED]> writes:
Hi,
Peter> I'll give your driver a try and report back.
Ok, the driver seems to be working (after fixing up the accessor
routines for my hw setup) and performance is comparable to Dustin's
driver.
It would be nice if the driver would
> "Steve" == Steve Glendinning <[EMAIL PROTECTED]> writes:
Hi,
>> What's the problem with Dustin's driver? It seems to work fine here
>> with a lan9117. Why not just add lan921x support to the existing
>> driver?
Steve> I have heard Dustin's driver works very well on PXA, but on
Steve>
Hi Peter,
> What's the problem with Dustin's driver? It seems to work fine here
> with a lan9117. Why not just add lan921x support to the existing
> driver?
I have heard Dustin's driver works very well on PXA, but on others it
doesn't even compile (hence why it depends on ARCH_PXA).
Dustin's dr
> "Steve" == Steve Glendinning <[EMAIL PROTECTED]> writes:
Hi,
Steve> Attached is a driver for SMSC's LAN911x and LAN921x families
Steve> of embedded ethernet controllers.
Steve> There is an existing smc911x driver in the tree; this is intended to
Steve> replace it. Dustin McIntire (the
Hi Jeff,
> Where is the hard_start_xmit/TX-completion locking?
The entire PIO Tx operation is performed within hard_start_xmit, so should
be covered by netif_tx_lock.
Regards,
--
Steve Glendinning
SMSC GmbH
m: +44 777 933 9124
e: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
Where is the hard_start_xmit/TX-completion locking?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Steve Glendinning wrote:
Attached is a driver for SMSC's LAN911x and LAN921x families of embedded
ethernet controllers. There is an existing smc911x driver in the tree;
this is intended to replace it.
This driver contains workarounds for all known hardware issues, and has
been tested on all fla
Hi Jeff,
> What are the arguments for adding a duplicate driver, again?
The current driver is completely arm specific (does not even compile on
!arm). While arm is certainly a popular arch for us, we also have many
customers on sh, x86 and others. Currently there is no in-kernel support
for
On Thu, 3 Aug 2006, [EMAIL PROTECTED] wrote:
Hi Scott,
I think the main concern that my co-workers here at SOMA Networks
and I have is that having two drivers dilutes the community effort.
There's also the fact that smc911x seems to have DMA support, which
smsc911x does not. Unless there are
Hi Scott,
> I think the main concern that my co-workers here at SOMA Networks
> and I have is that having two drivers dilutes the community effort.
> There's also the fact that smc911x seems to have DMA support, which
> smsc911x does not. Unless there are plans to enhance smsc911x with
> DMA supp
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> Mezigues :
[...]
> > Does the platform guarantees that the register write has actually
> reached
> > the real register when the udelay is issued ?
>
> I think so, but maybe you can help me check. The LAN911x device is always
> directly connected to a si
On Wed, Aug 02, 2006 at 08:23:40PM +0100, [EMAIL PROTECTED] wrote:
> > Does this need the magic "for (addr=1; addr <=32; addr++)" trick that
> > has become idiomatic for PHY discovery in our drivers?
>
> I don't understand the question - surely 32 is not a valid PHY address?
That's why it is mag
Hi Francois,
Thanks again for all your feedback. I have implemented most of your
suggestions,
> > /* Enable phy clocks to the MAC */
> > hwcfg &= (~HW_CFG_PHY_CLK_SEL_);
> > hwcfg |= HW_CFG_PHY_CLK_SEL_EXT_P
Hi John,
Thanks for all your feedback.
> > +/* waits for MAC not busy, with timeout. Assumes MacPhyAccessLock
has
> > + * already been acquired */
> > +static int smsc911x_mac_notbusy(struct smsc911x_data *pdata)
> > +{
> > +int i;
> > +
> > +for (i = 0; i < 40; i++) {
>
On Tue, 1 Aug 2006, [EMAIL PROTECTED] wrote:
Hi Scott
Sorry to be coming in late, but I'm curious about why this work is being
submitted as a separate driver, rather than as patches against the
driver
from Dustin McIntire that was added a few months ago. Is the intention
to
go forward wit
[...]
> /* Writes a packet to the TX_DATA_FIFO */
> static inline void
> smsc911x_tx_writefifo(struct smsc911x_data *pdata, unsigned int *buf,
> unsigned int wordcount)
> {
> while (wordcount--) {
> smsc911x_reg_write(*buf++, pdata, TX_DATA_FIFO);
> }
Hi Scott
> Sorry to be coming in late, but I'm curious about why this work is being
> submitted as a separate driver, rather than as patches against the
driver
> from Dustin McIntire that was added a few months ago. Is the intention
to
> go forward with two different drivers for these chips?
On Tue, 1 Aug 2006, Steve Glendinning wrote:
Attached is a driver patch for SMSC911x family of ethernet chips,
generated against 2.6.18-rc1 sources. There's a similar driver in the
tree; this one has been tested by SMSC on all flavors of the chip and
claimed to be efficient.
Updated after feed
On Tue, Aug 01, 2006 at 04:12:15PM +0100, Steve Glendinning wrote:
> > > Attached is a driver patch for SMSC911x family of ethernet chips,
> > > generated against 2.6.18-rc1 sources. There's a similar driver in the
> > > tree; this one has been tested by SMSC on all flavors of the chip and
> > > cl
Hi Francois,
Thanks for your feedback, I have a few questions.
> > +return serviced;
> > +}
> > +
> > +/* Autodetects and initialises external phy for SMSC9115 and SMSC9117
flavors.
> > + * If something goes wrong, returns -ENODEV to revert back to
internal phy. */
> > +static int s
Could the tasklet be replaced by using NAPI (dev->poll) routine?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[...]
> diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
> new file mode 100644
> index 000..12bbe67
> --- /dev/null
> +++ b/drivers/net/smsc911x.c
[...]
> +/* Tasklet declarations */
> +static unsigned long rx_tasklet_parameter;
> +static void smsc911x_rx_tasklet(unsigned long data
> +/* Tasklet declarations */
> +static unsigned long rx_tasklet_parameter;
> +static void smsc911x_rx_tasklet(unsigned long data);
> +
> +DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0);
You can make this local with
static DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0);
-
To unsubscribe
23 matches
Mail list logo
