Hello,
On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
Sorry, Baruch. I missed two comments in the last reply.
On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
quoted
Hi Shawn,
Please add netdev@vger.kernel.org to the Cc of all your fec driver patches.
I was aware of this after I sent out the patch set last night.
Can I just resend all the patches in v2 and get netdev@vger.kernel.org
included?
[I just added netdev for this reply. I think adding it for v2 is OK
then. For those interested, the whole series can be found at
http://thread.gmane.org/gmane.linux.ports.arm.kernel/100902
.]
quoted
On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
[...]
quoted
quoted
+ /*
+ * try to get mac address in following order:
+ *
+ * 1) kernel command line fec_mac=xx:xx:xx...
+ */
+ iap = fec_mac_default;
+
+ /*
+ * 2) from flash or fuse (via platform data)
+ */
Again, how do you handle the dual MAC case?
For the platform data case, the following patch reads both mac
addresses.
[PATCH 09/10] ARM: mx28: read fec mac address from ocotp
+static int __init mx28evk_fec_get_mac(void)
+{
+ int i, ret;
+ u32 val;
+
+ /*
+ * OCOTP only stores the last 4 octets for each mac address,
+ * so hard-coding the first two octets as Freescale OUI (00:04:9f)
+ * is needed.
+ */
+ for (i = 0; i < 2; i++) {
+ ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
+ if (ret)
+ goto error;
+
+ mx28_fec_pdata[i].mac[0] = 0x00;
+ mx28_fec_pdata[i].mac[1] = 0x04;
+ mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
+ mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
+ mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
+ mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
have unwanted effects (practical, don't know about legal ones).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hi Uwe,
On Wed, Dec 29, 2010 at 11:37:58AM +0100, Uwe Kleine-König wrote:
Hello,
On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
quoted
Sorry, Baruch. I missed two comments in the last reply.
On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
quoted
Hi Shawn,
Please add netdev@vger.kernel.org to the Cc of all your fec driver patches.
I was aware of this after I sent out the patch set last night.
Can I just resend all the patches in v2 and get netdev@vger.kernel.org
included?
[I just added netdev for this reply. I think adding it for v2 is OK
then. For those interested, the whole series can be found at
http://thread.gmane.org/gmane.linux.ports.arm.kernel/100902
.]
Thanks.
quoted
quoted
On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
[...]
quoted
quoted
+ /*
+ * try to get mac address in following order:
+ *
+ * 1) kernel command line fec_mac=xx:xx:xx...
+ */
+ iap = fec_mac_default;
+
+ /*
+ * 2) from flash or fuse (via platform data)
+ */
Again, how do you handle the dual MAC case?
For the platform data case, the following patch reads both mac
addresses.
[PATCH 09/10] ARM: mx28: read fec mac address from ocotp
+static int __init mx28evk_fec_get_mac(void)
+{
+ int i, ret;
+ u32 val;
+
+ /*
+ * OCOTP only stores the last 4 octets for each mac address,
+ * so hard-coding the first two octets as Freescale OUI (00:04:9f)
+ * is needed.
+ */
+ for (i = 0; i < 2; i++) {
+ ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
+ if (ret)
+ goto error;
+
+ mx28_fec_pdata[i].mac[0] = 0x00;
+ mx28_fec_pdata[i].mac[1] = 0x04;
+ mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
+ mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
+ mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
+ mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
have unwanted effects (practical, don't know about legal ones).
Yes, it is 0x9f.
--
Regards,
Shawn
Hi Shawn,
On Wed, Dec 29, 2010 at 07:08:29PM +0800, Shawn Guo wrote:
On Wed, Dec 29, 2010 at 11:37:58AM +0100, Uwe Kleine-König wrote:
quoted
On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
quoted
quoted
On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
[...]
quoted
quoted
+ /*
+ * try to get mac address in following order:
+ *
+ * 1) kernel command line fec_mac=xx:xx:xx...
+ */
+ iap = fec_mac_default;
+
+ /*
+ * 2) from flash or fuse (via platform data)
+ */
Again, how do you handle the dual MAC case?
For the platform data case, the following patch reads both mac
addresses.
[PATCH 09/10] ARM: mx28: read fec mac address from ocotp
+static int __init mx28evk_fec_get_mac(void)
+{
+ int i, ret;
+ u32 val;
+
+ /*
+ * OCOTP only stores the last 4 octets for each mac address,
+ * so hard-coding the first two octets as Freescale OUI (00:04:9f)
+ * is needed.
+ */
+ for (i = 0; i < 2; i++) {
+ ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
+ if (ret)
+ goto error;
+
+ mx28_fec_pdata[i].mac[0] = 0x00;
+ mx28_fec_pdata[i].mac[1] = 0x04;
+ mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
+ mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
+ mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
+ mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
have unwanted effects (practical, don't know about legal ones).
Yes, it is 0x9f.
Then maybe hardcode that, or at least warn if it's not?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hi Uwe,
On Wed, Dec 29, 2010 at 12:10:19PM +0100, Uwe Kleine-König wrote:
Hi Shawn,
On Wed, Dec 29, 2010 at 07:08:29PM +0800, Shawn Guo wrote:
quoted
On Wed, Dec 29, 2010 at 11:37:58AM +0100, Uwe Kleine-König wrote:
quoted
On Wed, Dec 29, 2010 at 06:30:15PM +0800, Shawn Guo wrote:
quoted
quoted
On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
[...]
quoted
quoted
+ /*
+ * try to get mac address in following order:
+ *
+ * 1) kernel command line fec_mac=xx:xx:xx...
+ */
+ iap = fec_mac_default;
+
+ /*
+ * 2) from flash or fuse (via platform data)
+ */
Again, how do you handle the dual MAC case?
For the platform data case, the following patch reads both mac
addresses.
[PATCH 09/10] ARM: mx28: read fec mac address from ocotp
+static int __init mx28evk_fec_get_mac(void)
+{
+ int i, ret;
+ u32 val;
+
+ /*
+ * OCOTP only stores the last 4 octets for each mac address,
+ * so hard-coding the first two octets as Freescale OUI (00:04:9f)
+ * is needed.
+ */
+ for (i = 0; i < 2; i++) {
+ ret = mxs_read_ocotp(0x20 + i * 0x10, 1, &val);
+ if (ret)
+ goto error;
+
+ mx28_fec_pdata[i].mac[0] = 0x00;
+ mx28_fec_pdata[i].mac[1] = 0x04;
+ mx28_fec_pdata[i].mac[2] = (val >> 24) & 0xff;
+ mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
+ mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
+ mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
uuh. Is ((val >> 24) & 0xff) supposed to be 0x9f? If not this might
have unwanted effects (practical, don't know about legal ones).
Yes, it is 0x9f.
Then maybe hardcode that, or at least warn if it's not?
Will hard-code it.
--
Regards,
Shawn