RE: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Hilman, Kevin
> Sent: Tuesday, January 25, 2011 2:52 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap@xxxxxxxxxxxxxxx; Varadarajan, Charulatha; tony@xxxxxxxxxxx
> Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller
> in board_init
> 
> "Hiremath, Vaibhav" <hvaibhav@xxxxxx> writes:
> 
> >> >
> >> > With addition of HWMOD support to GPIO, the Ethernet controller
> >> > goes undetected for OMAP35xEVM. So explicitely assert the reset
> signal
> >> to
> >> > Ethernet controller smsc911x -
> >> >
> >> > 	- GPIO7 (>=RevG version of EVM's)
> >> > 	- GPIO64 (<=RevD version of EVM's)
> >> >
> >> > I have tested this patch on RevG version of EVM with ES3.1 Si.
> >> > This patch is based on intial version from Charulatha V.
> >> >
> >> > Signed-off-by: Vaibhav Hiremath <hvaibhav@xxxxxx>
> >>
> >> This didn't apply cleanly to l-o master, with or without your previous
> >> patches which touch the EVM board file.
> >>
> > [Hiremath, Vaibhav] may be order in which you apply the patches is
> different, but should have been trivial to fix, right?
> > I would suggest you to use newer version.
> 
> The order of applying doesn't matter.  Applying the original patch alone
> didn't apply, applying it after the other didn't apply.   V2 doesn't
> apply cleanly either.
> 
> Please be sure it applies cleanly to:
> 
> commit 5b698d68c1a9ebeae76a0e4ca4dbfdb10357143d
> Author: Thomas Weber <weber@xxxxxxxxxxxxx>
> Date:   Thu Jan 20 14:12:11 2011 +0000
> 
>     omap: omap-mcbsp: Fix building after replacement
> 
>     Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in
>     commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95.
> 
> 
> If your series of EVM patches are interdependent, I suggest sending them
> as a series, so it's clear that they are dependent on each other.
> Also, please Cc linux-arm-kernel on OMAP patches intended for upstream.
> 
[Hiremath, Vaibhav] My head is pointing to same commit. But I think you are right, I should have made complete series of patches. Since these patches are functionally/logically not dependent on each other so I did not make it as a series.

Let me create series and send it again.

> This one (network GPIO) should be separated out though, and go into
> .38-rc (as well as -stable) since omap3evm is has not been bootable
> since 2.6.37.
> 
[Hiremath, Vaibhav] I agree.

> >> > ---
> >> > NOTE: I have not been able to test it on older version of EVM's.
> >>
> >> After manually applying,
> >>
> >> Tested-by: Kevin Hilman <khilman@xxxxxx>
> >>
> >> I tested on my rev D board with DHCP + nfs rootfs and it's working well.
> >>
> > [Hiremath, Vaibhav] Thanks a lot for validating it.
> >
> >> While testing though, I also noticed that the smsc driver is dumping
> >> some warnings (below) while trying to get the MAC address, resulting in
> >> not using the actual MAC but generating a random one.
> >>
> >> This isn't related to your patch, since it also happens with l-o master,
> >> but was wondering if you saw the same thing?
> >>
> > [Hiremath, Vaibhav] Yes I did see this message, and this is coming from
> >
> > #ifdef CONFIG_DEBUG_SPINLOCK
> > #define SMSC_ASSERT_MAC_LOCK(pdata) \
> >                 WARN_ON(!spin_is_locked(&pdata->mac_lock))
> >
> > And the root-cause is, in __init function we are calling
> smsc911x_read_mac_address->smsc911x_mac_read without holding mac_lock.
> >
> > I will submit the patch to net mailing list for this.
> 
> Thanks, please Cc linux-omap as well.
> 
[Hiremath, Vaibhav] Will do.

Thanks,
Vaibhav
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux