* Re: [PATCH] r8169: RxConfig hack for the 8168evl.
From: David Miller @ 2012-06-23 4:49 UTC (permalink / raw)
To: romieu; +Cc: hayeswang, netdev, thomas.pi
In-Reply-To: <20120620220918.GA2785@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 21 Jun 2012 00:09:18 +0200
> The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards
> are very prone to NETDEV watchdog problems without this change. See
> https://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance.
>
> I don't know why it *works*. It's depressingly effective though.
>
> For the record:
> - the problem may go along IOMMU (AMD-Vi) errors but it really looks
> like a red herring.
> - the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,
> the chipset now fetches several Rx descriptors at a time.
> - long ago the driver ignored the RX_MULTI_EN bit.
> e542a2269f232d61270ceddd42b73a4348dee2bb changed the RxConfig
> settings. Whatever the problem it's now labeled a regression.
> - Realtek's own driver can identify two different 8168evl devices
> (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only
> sees one. It sucks.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied, thanks Francois.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache output dst for syncookies
From: David Miller @ 2012-06-23 4:47 UTC (permalink / raw)
To: brouer; +Cc: eric.dumazet, netdev, hans.schillstrom
In-Reply-To: <1340365654.4003.46.camel@localhost>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Fri, 22 Jun 2012 13:47:34 +0200
> On Wed, 2012-06-20 at 17:02 +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Don't cache output dst for syncookies, as this adds pressure on IP route
>> cache and rcu subsystem for no gain.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> Looks good to me.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless 2012-06-22
From: John W. Linville @ 2012-06-23 4:11 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20453.9687.225096.194368@gargle.gargle.HOWL>
On Sat, Jun 23, 2012 at 07:41:35AM +0530, Sujith Manoharan wrote:
> David Miller wrote:
> > From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> > Date: Sat, 23 Jun 2012 05:05:10 +0530
> >
> > > Sujith Manoharan wrote:
> > >> John W. Linville wrote:
> > >> > Mohammed Shafi Shajakhan (1):
> > >> > ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
> > >>
> > >> Um, this commit doesn't really fix anything - the timeout is also
> > >> arbitrary. Can you remove this from the 3.5 queue ? Thanks.
> > >
> > > A review of the patch later, I think it's good. At least there's a
> > > WARN_ON_ONCE() to indicate the situation in which the measurement fails.
> > > It might come in handy as a debugging aid.
> >
> > Thanks for wasting our time.
> >
> > Make these determinations when changes to into John's tree, not
> > later when he asks me to pull them into mine.
>
> The patch was under review:
> http://marc.info/?l=linux-wireless&m=134001371002288&w=2
Quibbling over the exact number of iterations for a timeout didn't
seem is important as avoiding an endless loop...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Ming Lei @ 2012-06-23 3:39 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Marius Bjørnstad Kotsbak
In-Reply-To: <CACVXFVNmquD6nhcJkumZsnXH7T+Ga3YNt9EAQ=-5HUkYwEdp7w@mail.gmail.com>
Sorry for mistaken triggered sending, :-(
On Sat, Jun 23, 2012 at 11:32 AM, Ming Lei <tom.leiming@gmail.com> wrote:
> On Fri, Jun 22, 2012 at 5:11 PM, Bjørn Mork <bjorn@mork.no> wrote:
>
>>
>> Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak@gmail.com>
>> Cc: <stable@vger.kernel.org> # v3.4
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>> ---
>> drivers/net/usb/qmi_wwan.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
>> index 3767a12..b01960f 100644
>> --- a/drivers/net/usb/qmi_wwan.c
>> +++ b/drivers/net/usb/qmi_wwan.c
>> @@ -197,6 +197,10 @@ err:
>> static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
>> {
>> struct usbnet *dev = usb_get_intfdata(intf);
>> +
>> + /* can be called while disconnecting */
>> + if (!dev)
>> + return 0;
>> return qmi_wwan_manage_power(dev, on);
>> }
>
Considered there isn't any protection between usbnet_disconnet and
wdm_open/wdm_close, you patch still doesn't work on the race, see
below:
+ if (!dev)
+ return 0;
-> usbnet_disconnect() is triggered and completed here, so
dev may point to a freed usbnet instance.
return qmi_wwan_manage_power(dev, on);
One fix I can think of is to export wdm_mutex or its lock/unlock
functions, and introduce the function of qmi_wwan_disconnect, which
will call usbnet_disconnect with holding wdm_mutex.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Oops while disconnecting
From: Ming Lei @ 2012-06-23 3:32 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Marius Bjørnstad Kotsbak
In-Reply-To: <1340356279-3124-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
On Fri, Jun 22, 2012 at 5:11 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
>
> Reported-by: Marius Bjørnstad Kotsbak <marius.kotsbak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> ---
> drivers/net/usb/qmi_wwan.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 3767a12..b01960f 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -197,6 +197,10 @@ err:
> static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
> {
> struct usbnet *dev = usb_get_intfdata(intf);
> +
> + /* can be called while disconnecting */
> + if (!dev)
> + return 0;
> return qmi_wwan_manage_power(dev, on);
> }
Considered there isn't any protection between usbnet_disconnet and
wdm_open/wdm_close, you patch still doesn't work on the race, see
below:
+ if (!dev)
+ return 0;
-> usbnet_disconnect() triggered and completed, so
return qmi_wwan_manage_power(dev, on);
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless 2012-06-22
From: Sujith Manoharan @ 2012-06-23 2:11 UTC (permalink / raw)
To: David Miller; +Cc: c_manoha, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20120622.165611.2220193371527786713.davem@davemloft.net>
David Miller wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
> Date: Sat, 23 Jun 2012 05:05:10 +0530
>
> > Sujith Manoharan wrote:
> >> John W. Linville wrote:
> >> > Mohammed Shafi Shajakhan (1):
> >> > ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
> >>
> >> Um, this commit doesn't really fix anything - the timeout is also
> >> arbitrary. Can you remove this from the 3.5 queue ? Thanks.
> >
> > A review of the patch later, I think it's good. At least there's a
> > WARN_ON_ONCE() to indicate the situation in which the measurement fails.
> > It might come in handy as a debugging aid.
>
> Thanks for wasting our time.
>
> Make these determinations when changes to into John's tree, not
> later when he asks me to pull them into mine.
The patch was under review:
http://marc.info/?l=linux-wireless&m=134001371002288&w=2
Sujith
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Michael Chan @ 2012-06-23 1:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, nsujir, mcarlson
In-Reply-To: <20120622175934.2cc253b7@nehalam.linuxnetplumber.net>
On Fri, 2012-06-22 at 17:59 -0700, Stephen Hemminger wrote:
> On Wed, 20 Jun 2012 17:06:32 -0700
> "Michael Chan" <mchan@broadcom.com> wrote:
>
> > Some tg3 devices have management firmware that can export data such as
> > temperature and other real time diagnostics data. Export this data to
> > sysfs so that userspace can access this information.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> Linux has existing sensor api's that can be used by existing
> services like SNMP. Wouldn't you like the it to just work with
> existing code API's?
>
Is it the lm-sensors API? The data that we are exporting is for the
Lights out management for the system OEMs. I need to check with the
OEM.
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Michael Chan @ 2012-06-23 1:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nsujir, mcarlson
In-Reply-To: <20120622.172651.932738000786251092.davem@davemloft.net>
On Fri, 2012-06-22 at 17:26 -0700, David Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Wed, 20 Jun 2012 17:06:32 -0700
>
> > Some tg3 devices have management firmware that can export data such as
> > temperature and other real time diagnostics data. Export this data to
> > sysfs so that userspace can access this information.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> I do not agree that sysfs is the appropriate place to export binary
> data.
>
What's your suggestion? ethtool?
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Stephen Hemminger @ 2012-06-23 0:59 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, nsujir, mcarlson
In-Reply-To: <1340237192-30052-3-git-send-email-mchan@broadcom.com>
On Wed, 20 Jun 2012 17:06:32 -0700
"Michael Chan" <mchan@broadcom.com> wrote:
> Some tg3 devices have management firmware that can export data such as
> temperature and other real time diagnostics data. Export this data to
> sysfs so that userspace can access this information.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Linux has existing sensor api's that can be used by existing
services like SNMP. Wouldn't you like the it to just work with
existing code API's?
^ permalink raw reply
* Re: [PATCH -v1 0/3] usbnet: usbnet: PM related fixes
From: David Miller @ 2012-06-23 0:34 UTC (permalink / raw)
To: ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, oneukum-l3A5Bk7waGM,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1340176553-32225-1-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
From: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Date: Wed, 20 Jun 2012 15:15:50 +0800
> The 3 patches fix some PM related problems.
>
> v1:
> - one line fix in 3/3: GFP_ATOMIC -> flags in rx_alloc_submit
All applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: David Miller @ 2012-06-23 0:26 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir, mcarlson
In-Reply-To: <1340237192-30052-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 20 Jun 2012 17:06:32 -0700
> Some tg3 devices have management firmware that can export data such as
> temperature and other real time diagnostics data. Export this data to
> sysfs so that userspace can access this information.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
I do not agree that sysfs is the appropriate place to export binary
data.
^ permalink raw reply
* [PATCH 1/4] netdev/phy: Handle IEEE802.3 clause 45 Ethernet PHYs
From: David Daney @ 2012-06-23 0:24 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree-discuss, David S. Miller,
netdev
Cc: linux-kernel, linux-mips, afleming, David Daney
In-Reply-To: <1340411056-18988-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <david.daney@cavium.com>
The IEEE802.3 clause 45 MDIO bus protocol allows for directly
addressing PHY registers using a 21 bit address, and is used by many
10G Ethernet PHYS. Already existing is the ability of MDIO bus
drivers to use clause 45, with the MII_ADDR_C45 flag. Here we add
struct phy_c45_device_ids to hold the device identifier registers
present in clause 45. struct phy_device gets a couple of new fields:
c45_ids to hold the identifiers and is_c45 to signal that it is clause
45.
Normally the MII_ADDR_C45 flag is ORed with the register address to
indicate a clause 45 transaction. Here we also use this flag in the
*device* address passed to get_phy_device() to indicate that probing
should be done with clause 45 transactions.
EXPORT phy_device_create() so that the follow-on patch to of_mdio.c
can use it to create phy devices for PHYs, that have non-standard
device identifier registers, based on the device tree bindings.
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/net/phy/phy_device.c | 110 +++++++++++++++++++++++++++++++++++++++---
include/linux/phy.h | 25 +++++++++-
2 files changed, 126 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 18ab0da..fa0f558 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -152,8 +152,8 @@ int phy_scan_fixups(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_scan_fixups);
-static struct phy_device* phy_device_create(struct mii_bus *bus,
- int addr, int phy_id)
+struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
+ struct phy_c45_device_ids *c45_ids)
{
struct phy_device *dev;
@@ -174,8 +174,12 @@ static struct phy_device* phy_device_create(struct mii_bus *bus,
dev->autoneg = AUTONEG_ENABLE;
+ dev->is_c45 = (addr & MII_ADDR_C45) != 0;
+ addr &= ~MII_ADDR_C45;
dev->addr = addr;
dev->phy_id = phy_id;
+ if (c45_ids)
+ dev->c45_ids = *c45_ids;
dev->bus = bus;
dev->dev.parent = bus->parent;
dev->dev.bus = &mdio_bus_type;
@@ -200,20 +204,104 @@ static struct phy_device* phy_device_create(struct mii_bus *bus,
return dev;
}
+EXPORT_SYMBOL(phy_device_create);
+
+/**
+ * get_phy_c45_ids - reads the specified addr for its 802.3-c45 IDs.
+ * @bus: the target MII bus
+ * @addr: PHY address on the MII bus
+ * @phy_id: where to store the ID retrieved.
+ * @c45_ids: where to store the c45 ID information.
+ *
+ * If the PHY devices-in-package appears to be valid, it and the
+ * corresponding identifiers are stored in @c45_ids, zero is stored
+ * in @phy_id. Otherwise 0xffffffff is stored in @phy_id. Returns
+ * zero on success.
+ *
+ */
+static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
+ struct phy_c45_device_ids *c45_ids) {
+ int phy_reg;
+ int i, reg_addr;
+
+ /*
+ * Find first non-zero Devices In package. Device
+ * zero is reserved, so don't probe it.
+ */
+ for (i = 1;
+ i < ARRAY_SIZE(c45_ids->device_ids) &&
+ c45_ids->devices_in_package == 0;
+ i++) {
+ reg_addr = MII_ADDR_C45 | i << 16 | 6;
+ phy_reg = mdiobus_read(bus, addr, reg_addr);
+ if (phy_reg < 0)
+ return -EIO;
+ c45_ids->devices_in_package = (phy_reg & 0xffff) << 16;
+
+
+ reg_addr = MII_ADDR_C45 | i << 16 | 5;
+ phy_reg = mdiobus_read(bus, addr, reg_addr);
+ if (phy_reg < 0)
+ return -EIO;
+ c45_ids->devices_in_package |= (phy_reg & 0xffff);
+
+ /*
+ * If mostly Fs, there is no device there,
+ * let's get out of here.
+ */
+ if ((c45_ids->devices_in_package & 0x1fffffff) == 0x1fffffff) {
+ *phy_id = 0xffffffff;
+ return 0;
+ }
+ }
+
+ /* Now probe Device Identifiers for each device present. */
+ for (i = 1; i < ARRAY_SIZE(c45_ids->device_ids); i++) {
+ if (!(c45_ids->devices_in_package & (1 << i)))
+ continue;
+
+ reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID1;
+ phy_reg = mdiobus_read(bus, addr, reg_addr);
+ if (phy_reg < 0)
+ return -EIO;
+ c45_ids->device_ids[i] = (phy_reg & 0xffff) << 16;
+
+
+ reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID2;
+ phy_reg = mdiobus_read(bus, addr, reg_addr);
+ if (phy_reg < 0)
+ return -EIO;
+ c45_ids->device_ids[i] |= (phy_reg & 0xffff);
+ }
+ *phy_id = 0;
+ return 0;
+}
/**
* get_phy_id - reads the specified addr for its ID.
* @bus: the target MII bus
* @addr: PHY address on the MII bus
* @phy_id: where to store the ID retrieved.
+ * @c45_ids: where to store the c45 ID information.
+ *
+ * Description: In the case of a 802.3-c22 PHY, reads the ID registers
+ * of the PHY at @addr on the @bus, stores it in @phy_id and returns
+ * zero on success.
+ *
+ * In the case of a 802.3-c45 PHY, get_phy_c45_ids() is invoked, and
+ * its return value is in turn returned.
*
- * Description: Reads the ID registers of the PHY at @addr on the
- * @bus, stores it in @phy_id and returns zero on success.
*/
-static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id)
+static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id,
+ struct phy_c45_device_ids *c45_ids)
{
int phy_reg;
+ if (addr & MII_ADDR_C45) {
+ addr &= ~MII_ADDR_C45;
+
+ return get_phy_c45_ids(bus, addr, phy_id, c45_ids);
+ }
/* Grab the bits from PHYIR1, and put them
* in the upper half */
phy_reg = mdiobus_read(bus, addr, MII_PHYSID1);
@@ -241,14 +329,17 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id)
*
* Description: Reads the ID registers of the PHY at @addr on the
* @bus, then allocates and returns the phy_device to represent it.
+ * If @addr & MII_ADDR_C45 is not zero, the PHY is assumed to be
+ * 802.3-c45.
*/
struct phy_device * get_phy_device(struct mii_bus *bus, int addr)
{
struct phy_device *dev = NULL;
u32 phy_id;
+ struct phy_c45_device_ids c45_ids = {0};
int r;
- r = get_phy_id(bus, addr, &phy_id);
+ r = get_phy_id(bus, addr, &phy_id, &c45_ids);
if (r)
return ERR_PTR(r);
@@ -256,7 +347,7 @@ struct phy_device * get_phy_device(struct mii_bus *bus, int addr)
if ((phy_id & 0x1fffffff) == 0x1fffffff)
return NULL;
- dev = phy_device_create(bus, addr, phy_id);
+ dev = phy_device_create(bus, addr, phy_id, &c45_ids);
return dev;
}
@@ -449,6 +540,11 @@ static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
/* Assume that if there is no driver, that it doesn't
* exist, and we should use the genphy driver. */
if (NULL == d->driver) {
+ if (phydev->is_c45) {
+ pr_err("No driver for phy %x\n", phydev->phy_id);
+ return -ENODEV;
+ }
+
d->driver = &genphy_driver.driver;
err = d->driver->probe(d);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index c291cae..92d53ee 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -83,8 +83,12 @@ typedef enum {
*/
#define MII_BUS_ID_SIZE (20 - 3)
-/* Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the 21 bit
- IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy chips. */
+/*
+ * Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the
+ * 21 bit IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy
+ * chips. Also may be ORed into the device address in
+ * get_phy_device().
+ */
#define MII_ADDR_C45 (1<<30)
struct device;
@@ -243,6 +247,16 @@ enum phy_state {
PHY_RESUMING
};
+/*
+ * phy_c45_device_ids: 802.3-c45 Device Identifiers
+ *
+ * devices_in_package: Bit vector of devices present.
+ * device_ids: The device identifer for each present device.
+ */
+struct phy_c45_device_ids {
+ u32 devices_in_package;
+ u32 device_ids[8];
+};
/* phy_device: An instance of a PHY
*
@@ -250,6 +264,8 @@ enum phy_state {
* bus: Pointer to the bus this PHY is on
* dev: driver model device structure for this PHY
* phy_id: UID for this device found during discovery
+ * c45_ids: 802.3-c45 Device Identifers if is_c45.
+ * is_c45: Set to true if this phy uses clause 45 addressing.
* state: state of the PHY for management purposes
* dev_flags: Device-specific flags used by the PHY driver.
* addr: Bus address of PHY
@@ -285,6 +301,9 @@ struct phy_device {
u32 phy_id;
+ struct phy_c45_device_ids c45_ids;
+ bool is_c45;
+
enum phy_state state;
u32 dev_flags;
@@ -480,6 +499,8 @@ static inline int phy_write(struct phy_device *phydev, u32 regnum, u16 val)
return mdiobus_write(phydev->bus, phydev->addr, regnum, val);
}
+struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
+ struct phy_c45_device_ids *c45_ids);
struct phy_device* get_phy_device(struct mii_bus *bus, int addr);
int phy_device_register(struct phy_device *phy);
int phy_init_hw(struct phy_device *phydev);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] netdev/phy: Add driver for Broadcom BCM87XX 10G Ethernet PHYs
From: David Daney @ 2012-06-23 0:24 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree-discuss, David S. Miller,
netdev
Cc: linux-kernel, linux-mips, afleming, David Daney
In-Reply-To: <1340411056-18988-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <david.daney@cavium.com>
Add a driver for BCM8706 and BCM8727 devices. These are a 10Gig PHYs
which use MII_ADDR_C45 addressing. They are always 10G full duplex, so
there is no autonegotiation. All we do is report link state and send
interrupts when it changes.
If the PHY has a device tree of_node associated with it, the
"broadcom,c45-reg-init" property is used to supply register
initialization values when config_init() is called.
Signed-off-by: David Daney <david.daney@cavium.com>
---
.../devicetree/bindings/net/broadcom-bcm87xx.txt | 29 +++
drivers/net/phy/Kconfig | 5 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/bcm87xx.c | 239 ++++++++++++++++++++
4 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
create mode 100644 drivers/net/phy/bcm87xx.c
diff --git a/Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt b/Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
new file mode 100644
index 0000000..7c86d5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
@@ -0,0 +1,29 @@
+The Broadcom BCM87XX devices are a family of 10G Ethernet PHYs. They
+have these bindings in addition to the standard PHY bindings.
+
+Compatible: Should contain "broadcom,bcm8706" or "broadcom,bcm8727" and
+ "ethernet-phy-ieee802.3-c45"
+
+Optional Properties:
+
+- broadcom,c45-reg-init : one of more sets of 4 cells. The first cell
+ is the MDIO Manageable Device (MMD) address, the second a register
+ address within the MMD, the third cell contains a mask to be ANDed
+ with the existing register value, and the fourth cell is ORed with
+ he result to yield the new register value. If the third cell has a
+ value of zero, no read of the existing value is performed.
+
+Example:
+
+ ethernet-phy@5 {
+ reg = <5>;
+ compatible = "broadcom,bcm8706", "ethernet-phy-ieee802.3-c45";
+ interrupt-parent = <&gpio>;
+ interrupts = <12 8>; /* Pin 12, active low */
+ /*
+ * Set PMD Digital Control Register for
+ * GPIO[1] Tx/Rx
+ * GPIO[0] R64 Sync Acquired
+ */
+ broadcom,c45-reg-init = <1 0xc808 0xff8f 0x70>;
+ };
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 944cdfb..3090dc6 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -67,6 +67,11 @@ config BCM63XX_PHY
---help---
Currently supports the 6348 and 6358 PHYs.
+config BCM87XX_PHY
+ tristate "Driver for Broadcom BCM8706 and BCM8727 PHYs"
+ help
+ Currently supports the BCM8706 and BCM8727 10G Ethernet PHYs.
+
config ICPLUS_PHY
tristate "Drivers for ICPlus PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index f51af68..6d2dc6c 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
obj-$(CONFIG_BCM63XX_PHY) += bcm63xx.o
+obj-$(CONFIG_BCM87XX_PHY) += bcm87xx.o
obj-$(CONFIG_ICPLUS_PHY) += icplus.o
obj-$(CONFIG_REALTEK_PHY) += realtek.o
obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
diff --git a/drivers/net/phy/bcm87xx.c b/drivers/net/phy/bcm87xx.c
new file mode 100644
index 0000000..b2f6a43
--- /dev/null
+++ b/drivers/net/phy/bcm87xx.c
@@ -0,0 +1,239 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2011 - 2012 Cavium, Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/of.h>
+
+#define PHY_ID_BCM8706 0x0143bdc1
+#define PHY_ID_BCM8727 0x0143bff0
+
+#define BCM87XX_PMD_RX_SIGNAL_DETECT (MII_ADDR_C45 | 0x1000a)
+#define BCM87XX_10GBASER_PCS_STATUS (MII_ADDR_C45 | 0x30020)
+#define BCM87XX_XGXS_LANE_STATUS (MII_ADDR_C45 | 0x40018)
+
+#define BCM87XX_LASI_CONTROL (MII_ADDR_C45 | 0x39002)
+#define BCM87XX_LASI_STATUS (MII_ADDR_C45 | 0x39005)
+
+#if IS_ENABLED(CONFIG_OF_MDIO)
+/*
+ * Set and/or override some configuration registers based on the
+ * marvell,reg-init property stored in the of_node for the phydev.
+ *
+ * broadcom,c45-reg-init = <devid reg mask value>,...;
+ *
+ * There may be one or more sets of <devid reg mask value>:
+ *
+ * devid: which sub-device to use.
+ * reg: the register.
+ * mask: if non-zero, ANDed with existing register value.
+ * value: ORed with the masked value and written to the regiser.
+ *
+ */
+static int bcm87xx_of_reg_init(struct phy_device *phydev)
+{
+ const __be32 *paddr;
+ const __be32 *paddr_end;
+ int len, ret;
+
+ if (!phydev->dev.of_node)
+ return 0;
+
+ paddr = of_get_property(phydev->dev.of_node,
+ "broadcom,c45-reg-init", &len);
+ if (!paddr)
+ return 0;
+
+ paddr_end = paddr + (len /= sizeof(*paddr));
+
+ ret = 0;
+
+ while (paddr + 3 < paddr_end) {
+ u16 devid = be32_to_cpup(paddr++);
+ u16 reg = be32_to_cpup(paddr++);
+ u16 mask = be32_to_cpup(paddr++);
+ u16 val_bits = be32_to_cpup(paddr++);
+ int val;
+ u32 regnum = MII_ADDR_C45 | (devid << 16) | reg;
+ val = 0;
+ if (mask) {
+ val = phy_read(phydev, regnum);
+ if (val < 0) {
+ ret = val;
+ goto err;
+ }
+ val &= mask;
+ }
+ val |= val_bits;
+
+ ret = phy_write(phydev, regnum, val);
+ if (ret < 0)
+ goto err;
+ }
+err:
+ return ret;
+}
+#else
+static int bcm87xx_of_reg_init(struct phy_device *phydev)
+{
+ return 0;
+}
+#endif /* CONFIG_OF_MDIO */
+
+static int bcm87xx_config_init(struct phy_device *phydev)
+{
+ phydev->supported = SUPPORTED_10000baseR_FEC;
+ phydev->advertising = ADVERTISED_10000baseR_FEC;
+ phydev->state = PHY_NOLINK;
+
+ bcm87xx_of_reg_init(phydev);
+
+ return 0;
+}
+
+static int bcm87xx_config_aneg(struct phy_device *phydev)
+{
+ return -EINVAL;
+}
+
+static int bcm87xx_read_status(struct phy_device *phydev)
+{
+ int rx_signal_detect;
+ int pcs_status;
+ int xgxs_lane_status;
+
+ rx_signal_detect = phy_read(phydev, BCM87XX_PMD_RX_SIGNAL_DETECT);
+ if (rx_signal_detect < 0)
+ return rx_signal_detect;
+
+ if ((rx_signal_detect & 1) == 0)
+ goto no_link;
+
+ pcs_status = phy_read(phydev, BCM87XX_10GBASER_PCS_STATUS);
+ if (pcs_status < 0)
+ return pcs_status;
+
+ if ((pcs_status & 1) == 0)
+ goto no_link;
+
+ xgxs_lane_status = phy_read(phydev, BCM87XX_XGXS_LANE_STATUS);
+ if (xgxs_lane_status < 0)
+ return xgxs_lane_status;
+
+ if ((xgxs_lane_status & 0x1000) == 0)
+ goto no_link;
+
+ phydev->speed = 10000;
+ phydev->link = 1;
+ phydev->duplex = 1;
+ return 0;
+
+no_link:
+ phydev->link = 0;
+ return 0;
+}
+
+static int bcm87xx_config_intr(struct phy_device *phydev)
+{
+ int reg, err;
+
+ reg = phy_read(phydev, BCM87XX_LASI_CONTROL);
+
+ if (reg < 0)
+ return reg;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ reg |= 1;
+ else
+ reg &= ~1;
+
+ err = phy_write(phydev, BCM87XX_LASI_CONTROL, reg);
+ return err;
+}
+
+static int bcm87xx_did_interrupt(struct phy_device *phydev)
+{
+ int reg;
+
+ reg = phy_read(phydev, BCM87XX_LASI_STATUS);
+
+ if (reg < 0) {
+ dev_err(&phydev->dev,
+ "Error: Read of BCM87XX_LASI_STATUS failed: %d\n", reg);
+ return 0;
+ }
+ return (reg & 1) != 0;
+}
+
+static int bcm87xx_ack_interrupt(struct phy_device *phydev)
+{
+ /* Reading the LASI status clears it. */
+ bcm87xx_did_interrupt(phydev);
+ return 0;
+}
+
+static int bcm8706_match_phy_device(struct phy_device *phydev)
+{
+ return phydev->c45_ids.device_ids[4] == PHY_ID_BCM8706;
+}
+
+static int bcm8727_match_phy_device(struct phy_device *phydev)
+{
+ return phydev->c45_ids.device_ids[4] == PHY_ID_BCM8727;
+}
+
+static struct phy_driver bcm8706_driver = {
+ .phy_id = PHY_ID_BCM8706,
+ .phy_id_mask = 0xffffffff,
+ .name = "Broadcom BCM8706",
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = bcm87xx_config_init,
+ .config_aneg = bcm87xx_config_aneg,
+ .read_status = bcm87xx_read_status,
+ .ack_interrupt = bcm87xx_ack_interrupt,
+ .config_intr = bcm87xx_config_intr,
+ .did_interrupt = bcm87xx_did_interrupt,
+ .match_phy_device = bcm8706_match_phy_device,
+ .driver = { .owner = THIS_MODULE },
+};
+
+static struct phy_driver bcm8727_driver = {
+ .phy_id = PHY_ID_BCM8727,
+ .phy_id_mask = 0xffffffff,
+ .name = "Broadcom BCM8727",
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = bcm87xx_config_init,
+ .config_aneg = bcm87xx_config_aneg,
+ .read_status = bcm87xx_read_status,
+ .ack_interrupt = bcm87xx_ack_interrupt,
+ .config_intr = bcm87xx_config_intr,
+ .did_interrupt = bcm87xx_did_interrupt,
+ .match_phy_device = bcm8727_match_phy_device,
+ .driver = { .owner = THIS_MODULE },
+};
+
+static int __init bcm87xx_init(void)
+{
+ int ret;
+
+ ret = phy_driver_register(&bcm8706_driver);
+ if (ret)
+ goto err;
+
+ ret = phy_driver_register(&bcm8727_driver);
+err:
+ return ret;
+}
+module_init(bcm87xx_init);
+
+static void __exit bcm87xx_exit(void)
+{
+ phy_driver_unregister(&bcm8706_driver);
+ phy_driver_unregister(&bcm8727_driver);
+}
+module_exit(bcm87xx_exit);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] netdev/phy/of: Add more methods for binding PHY devices to drivers.
From: David Daney @ 2012-06-23 0:24 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree-discuss, David S. Miller,
netdev
Cc: linux-kernel, linux-mips, afleming, David Daney
In-Reply-To: <1340411056-18988-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <david.daney@cavium.com>
Allow PHY drivers to supply their own device matching function
(match_phy_device()), or to be matched OF compatible properties.
PHYs following IEEE802.3 clause 45 have more than one device
identifier constants, which breaks the default device matching code.
Other 10G PHYs don't follow the standard manufacturer/device
identifier register layout standards, but they do use the standard
MDIO bus protocols for register access. Both of these require
adjustments to the PHY driver to device matching code.
If the there is an of_node associated with such a PHY, we can match it
to its driver using the "compatible" properties, just as we do with
certain platform devices. If the "compatible" property match fails,
first check if there is a driver supplied matching function, and if
not fall back to the existing identifier matching rules.
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/net/phy/mdio_bus.c | 7 +++++++
include/linux/phy.h | 7 +++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 31470b0..9a283b4 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -25,6 +25,7 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/device.h>
+#include <linux/of_device.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
@@ -308,6 +309,12 @@ static int mdio_bus_match(struct device *dev, struct device_driver *drv)
struct phy_device *phydev = to_phy_device(dev);
struct phy_driver *phydrv = to_phy_driver(drv);
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ if (phydrv->match_phy_device)
+ return phydrv->match_phy_device(phydev);
+
return ((phydrv->phy_id & phydrv->phy_id_mask) ==
(phydev->phy_id & phydrv->phy_id_mask));
}
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 92d53ee..bbd9e7f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -434,6 +434,13 @@ struct phy_driver {
/* Handles ethtool queries for hardware time stamping. */
int (*ts_info)(struct phy_device *phydev, struct ethtool_ts_info *ti);
+ /*
+ * Returns true if this is a suitable driver for the given
+ * phydev. If NULL, matching is based on phy_id and
+ * phy_id_mask.
+ */
+ int (*match_phy_device)(struct phy_device *phydev);
+
/* Handles SIOCSHWTSTAMP ioctl for hardware time stamping. */
int (*hwtstamp)(struct phy_device *phydev, struct ifreq *ifr);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] netdev/phy/of: Handle IEEE802.3 clause 45 Ethernet PHYs in of_mdiobus_register()
From: David Daney @ 2012-06-23 0:24 UTC (permalink / raw)
To: Grant Likely, Rob Herring,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
afleming-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Daney
In-Reply-To: <1340411056-18988-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Define two new "compatible" values for Ethernet
PHYs. "ethernet-phy-ieee802.3-c22" and "ethernet-phy-ieee802.3-c45"
are used to indicate a PHY uses the corresponding protocol.
If a PHY is "compatible" with "ethernet-phy-ieee802.3-c45", we
indicate this so that get_phy_device() can properly probe the device.
If get_phy_device() fails, it was probably due to failing the probe of
the PHY identifier registers. Since we have the device tree telling
us the PHY exists, go ahead and add it anyhow with a phy_id of zero.
There may be a driver match based on the "compatible" property.
Signed-off-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/net/phy.txt | 12 +++++++++++-
drivers/of/of_mdio.c | 14 +++++++++++---
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index bb8c742..7cd18fb 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -14,10 +14,20 @@ Required properties:
- linux,phandle : phandle for this node; likely referenced by an
ethernet controller node.
+Optional Properties:
+
+- compatible: Compatible list, may contain
+ "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
+ PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
+ specifications. If neither of these are specified, the default is to
+ assume clause 22. The compatible list may also contain other
+ elements.
+
Example:
ethernet-phy@0 {
- linux,phandle = <2452000>
+ compatible = "ethernet-phy-ieee802.3-c22";
+ linux,phandle = <2452000>;
interrupt-parent = <40000>;
interrupts = <35 1>;
reg = <0>;
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 2574abd..0f08aaf 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -79,11 +79,19 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
mdio->irq[addr] = PHY_POLL;
}
+ if (of_device_is_compatible(child,
+ "ethernet-phy-ieee802.3-c45"))
+ addr |= MII_ADDR_C45;
+
phy = get_phy_device(mdio, addr);
if (!phy || IS_ERR(phy)) {
- dev_err(&mdio->dev, "error probing PHY at address %i\n",
- addr);
- continue;
+ phy = phy_device_create(mdio, addr, 0, NULL);
+ if (!phy || IS_ERR(phy)) {
+ dev_err(&mdio->dev,
+ "error creating PHY at address %i\n",
+ addr);
+ continue;
+ }
}
/* Associate the OF node with the device structure so it
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/4] netdev/phy: 10G PHY support.
From: David Daney @ 2012-06-23 0:24 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree-discuss, David S. Miller,
netdev
Cc: linux-kernel, linux-mips, afleming, David Daney
From: David Daney <david.daney@cavium.com>
The existing PHY driver infrastructure supports IEEE 802.3 Clause 22
PHYs used with 10/100/1000MB Ethernet. For 10G Ethernet, many PHYs
use 802.3 Clause 45. These patches attempt to add core support for
this as well as a driver for BCM87XX 10G PHY devices.
This is reworked from patches I send about 9 months ago:
http://marc.info/?l=linux-netdev&m=131844282403852
Several of the patches have device tree bindings in them, so the
device tree people get to enjoy them too.
David Daney (4):
netdev/phy: Handle IEEE802.3 clause 45 Ethernet PHYs
netdev/phy/of: Handle IEEE802.3 clause 45 Ethernet PHYs in
of_mdiobus_register()
netdev/phy/of: Add more methods for binding PHY devices to drivers.
netdev/phy: Add driver for Broadcom BCM87XX 10G Ethernet PHYs
.../devicetree/bindings/net/broadcom-bcm87xx.txt | 29 +++
Documentation/devicetree/bindings/net/phy.txt | 12 +-
drivers/net/phy/Kconfig | 5 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/bcm87xx.c | 239 ++++++++++++++++++++
drivers/net/phy/mdio_bus.c | 7 +
drivers/net/phy/phy_device.c | 110 +++++++++-
drivers/of/of_mdio.c | 14 +-
include/linux/phy.h | 32 +++-
9 files changed, 436 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
create mode 100644 drivers/net/phy/bcm87xx.c
--
1.7.2.3
^ permalink raw reply
* Re: [PATCH 4/4] net/mlx4_en: Use atomic counter to decide when queue is full
From: David Miller @ 2012-06-23 0:23 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <1340270358-19504-5-git-send-email-yevgenyp@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Thu, 21 Jun 2012 12:19:17 +0300
> The Transmit and transmit completion flows execute from different contexts,
> which are not synchronized. Hence naive reading the of consumer index might
> give wrong value by the time it is being used, That could lead to a state of transmit timeout.
> Fix that by using atomic variable to maintain that index.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
I'm not convinced. There is only one place that actually changes
the counter.
So it seems more like you have a missing memory barrier somewhere.
Other drivers do not need to use something as expansive as an atomic
variable for this and neither should you.
I'm not applying this patch series, you'll need to resubmit it in
it's entirety once you fix this patch.
^ permalink raw reply
* Re: [PATCH net-next (v2) 0/6] bnx2x: link patch series
From: David Miller @ 2012-06-23 0:20 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, joe
In-Reply-To: <1340255123-22371-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Thu, 21 Jun 2012 08:05:17 +0300
> Hi Dave,
>
> This patch series change bnx2x's link code. It contains both
> semantic cleanup of the code as well as several patches that
> add new support for optical modules - better 1G SFP support,
> SFP+ Tx Fault support and implementation of the new ethtool API
> for accessing the module's eeprom (on the bnx2x side).
>
> Changes from Version 1:
> - Patch 2/6 - use usleep_range(small, small*2) instead of
> usleep_range(small, small).
>
>
> Please consider applying this patch-series to 'net-next'.
All applied, thanks.
^ permalink raw reply
* Re: next-20120620 build error in netfilter
From: Pablo Neira Ayuso @ 2012-06-23 0:20 UTC (permalink / raw)
To: valdis.kletnieks; +Cc: netdev, linux-kernel
In-Reply-To: <55558.1340217472@turing-police.cc.vt.edu>
On Wed, Jun 20, 2012 at 02:37:52PM -0400, valdis.kletnieks@vt.edu wrote:
> On Wed, 20 Jun 2012 19:28:01 +0200, Pablo Neira Ayuso said:
> > On Wed, Jun 20, 2012 at 01:14:33PM -0400, Valdis Kletnieks wrote:
> > > Today's linux-next fails to build with CONFIG_NF_NAT_NEEDED=y and CONFIG_NF_NAT=m
> > >
> > > LD init/built-in.o
> > > net/built-in.o:(.data+0x4408): undefined reference to `nf_nat_tcp_seq_adjust'
> > > make: *** [vmlinux] Error 1
> >
> > I guess you have NF_CT_NETLINK=y, right?
>
> Yes.
>
> Temporary workaround was setting NF_NAT=n (I don't use NAT, I just usually
> build all the netfilter modules as =m even if I don't use them, just to provide
> build coverage and trip over stuff like this).
Probably NF_CT_NETLINK=m is a better workaround.
Anyway, I've enqueued the following patch to fix this:
http://1984.lsi.us.es/git/nf-next/commit/?id=d584a61a931e6cbfef0dd811c4ae0250ec5987f4
So you can use your previous config.
Thanks.
^ permalink raw reply
* Re: linux-next: Tree for Jun 21 (netfilter)
From: Pablo Neira Ayuso @ 2012-06-23 0:19 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, netdev, netfilter-devel
In-Reply-To: <4FE4AB02.9020100@xenotime.net>
On Fri, Jun 22, 2012 at 10:27:30AM -0700, Randy Dunlap wrote:
> On 06/20/2012 11:12 PM, Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Uploads to ra/geb.kernel.org are broken right now, so the tree will not
> > be available until that is fixed and I have uploaded it.
> >
> > News: All my builds are now done with gcc 4.6.3 and binutils 2.22.
> >
> > Changes since 20120620:
>
> on x86_64:
>
> net/netfilter/nf_conntrack_netlink.c:1644:9: error: implicit declaration of function 'ctnetlink_secctx_size'
> net/netfilter/nf_conntrack_netlink.c:1652:9: error: implicit declaration of function 'ctnetlink_proto_size'
I'll pass this patch to David to fix this issue:
http://1984.lsi.us.es/git/nf-next/commit/?id=8e36c4b5b673edc6081599b8bd461e062e4910f4
thanks for the report Randy.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: fix Gobi device probing
From: David Miller @ 2012-06-23 0:17 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, H.Siebmanns
In-Reply-To: <1340282758-18085-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 21 Jun 2012 14:45:58 +0200
> Ignoring interfaces with additional descriptors is not a reliable
> method for locating the correct interface on Gobi devices. There
> is at least one device where this method fails:
> https://bbs.archlinux.org/viewtopic.php?id=143506
>
> The result is that the AT command port (interface #2) is hidden
> from qcserial, preventing traditional serial modem usage:
...
> Use static interface numbers taken from the interface map in
> qcserial for all Gobi devices instead:
...
> This should be more reliable over all, and will also prevent the
> noisy "probe failed" messages. The whitelisting logic is expected
> to be replaced by direct interface number matching in 3.6.
>
> Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
> Cc: <stable@vger.kernel.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
> Cc: <stable@vger.kernel.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
> Cc: <stable@vger.kernel.org> # v3.4
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Update netdev_alloc_frag to work more efficiently with TCP and GRO
From: Alexander Duyck @ 2012-06-23 0:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev, davem, jeffrey.t.kirsher
In-Reply-To: <1340368430.4604.10280.camel@edumazet-glaptop>
On 06/22/2012 05:33 AM, Eric Dumazet wrote:
> On Thu, 2012-06-21 at 07:07 +0200, Eric Dumazet wrote:
>> On Wed, 2012-06-20 at 21:07 -0700, Alexander Duyck wrote:
>>> On 6/20/2012 6:21 AM, Eric Dumazet wrote:
>>>> + nc->page = alloc_pages(GFP_ATOMIC | __GFP_COLD |
>>>> + (NETDEV_FRAG_ORDER ? __GFP_COMP : 0),
>>>> + NETDEV_FRAG_ORDER);
>>> I was wondering if you needed the check for NETDEV_FRAG_ORDER here.
>>> From what I can tell setting __GFP_COMP for an order 0 page has no
>>> effect since it only seems to get checked in prep_new_page and that is
>>> after a check to verify if the page is order 0 or not.
>> Good point, it seems some net drivers could be changed to remove
>> useless tests.
>>
>> I'll post some performance data as well.
> Here is the patch I tested here.
>
> Using 32768 bytes allocations is actually nice for MTU=9000 traffic,
> since we can fit 3 frames per 32KB instead of only 2 frames (using
> kmalloc-16384 slab))
>
> Also, I prefill page->_count with a high bias value, to avoid the
> get_page() we did for each allocated frag.
>
> In my profiles, the get_page() cost was dominant, because of false
> sharing with skb consumers (as they might run on different cpus)
>
> This way, when 32768 bytes are filled, we perform a single
> atomic_sub_return() and can recycle the page if we find we are the last
> user (this is what you did in your patch, when testing page->_count
> being 1)
This is working really nicely. On my system put_page dropped to
somewhere near the bottom of the perf top runs I was doing. In addition
netdev_alloc_frag dropped from about 4% CPU to 2%.
>
> Note : If I used max(PAGE_SIZE, 32678) for MAX_NETDEV_FRAGSIZE,
> gcc was not able to optimise get_order(MAX_NETDEV_FRAGSIZE), strange...
The issue is probably the type checking in the max macro. You might
have better luck using max_t and specifying a type.
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 5b21522..d31efa2 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -296,9 +296,18 @@ EXPORT_SYMBOL(build_skb);
> struct netdev_alloc_cache {
> struct page *page;
> unsigned int offset;
> + unsigned int pagecnt_bias;
> };
> static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
>
> +#if PAGE_SIZE > 32768
> +#define MAX_NETDEV_FRAGSIZE PAGE_SIZE
> +#else
> +#define MAX_NETDEV_FRAGSIZE 32768
> +#endif
> +
> +#define NETDEV_PAGECNT_BIAS (MAX_NETDEV_FRAGSIZE / \
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
> /**
> * netdev_alloc_frag - allocate a page fragment
> * @fragsz: fragment size
I'm assuming the reason for using the size of skb_shared_info here is
because you don't expect any requests to be smaller than that? I
suppose that is reasonable, but is there any reason why this couldn't be
a smaller value such as SMP_CACHE_BYTES?
> @@ -316,18 +325,25 @@ void *netdev_alloc_frag(unsigned int fragsz)
> nc = &__get_cpu_var(netdev_alloc_cache);
> if (unlikely(!nc->page)) {
> refill:
> - nc->page = alloc_page(GFP_ATOMIC | __GFP_COLD);
> + nc->page = alloc_pages(GFP_ATOMIC | __GFP_COLD | __GFP_COMP,
> + get_order(MAX_NETDEV_FRAGSIZE));
> + if (unlikely(!nc->page))
> + goto end;
> +recycle:
> + atomic_set(&nc->page->_count, NETDEV_PAGECNT_BIAS);
> + nc->pagecnt_bias = NETDEV_PAGECNT_BIAS;
> nc->offset = 0;
> }
> - if (likely(nc->page)) {
> - if (nc->offset + fragsz > PAGE_SIZE) {
> - put_page(nc->page);
> - goto refill;
> - }
> - data = page_address(nc->page) + nc->offset;
> - nc->offset += fragsz;
> - get_page(nc->page);
> + if (nc->offset + fragsz > MAX_NETDEV_FRAGSIZE) {
> + if (!atomic_sub_return(nc->pagecnt_bias,
> + &nc->page->_count))
> + goto recycle;
> + goto refill;
> }
> + data = page_address(nc->page) + nc->offset;
> + nc->offset += fragsz;
> + nc->pagecnt_bias--; /* avoid get_page()/get_page() false sharing */
> +end:
> local_irq_restore(flags);
> return data;
> }
> @@ -353,7 +369,7 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
> unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
> SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> - if (fragsz <= PAGE_SIZE && !(gfp_mask & __GFP_WAIT)) {
> + if (fragsz <= MAX_NETDEV_FRAGSIZE && !(gfp_mask & __GFP_WAIT)) {
> void *data = netdev_alloc_frag(fragsz);
>
> if (likely(data)) {
>
>
One idea I had that I have been trying to figure out how make work would
be to actually run the offset in the reverse direction so that you start
it at MAX_NETDEV_FRAGSIZE and work your way back down to 0. The
advantage to that approach is that you then only have to perform one
check instead of two and you can drop a goto. The only problem I have
been running into is that it doesn't seem to perform as well as your
patch but I am still working the details out.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] ipv4: Add sysctl knob to control early socket demux
From: David Miller @ 2012-06-23 0:15 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, jeffrey.t.kirsher, edumazet
In-Reply-To: <20120621235011.29846.29715.stgit@gitlad.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Thu, 21 Jun 2012 16:58:31 -0700
> This change is meant to add a control for disabling early socket demux.
> The main motivation behind this patch is to provide an option to disable
> the feature as it adds an additional cost to routing that reduces overall
> throughput by up to 5%. For example one of my systems went from 12.1Mpps
> to 11.6 after the early socket demux was added. It looks like the reason
> for the regression is that we are now having to perform two lookups, first
> the one for an established socket, and then the one for the routing table.
>
> By adding this patch and toggling the value for ip_early_demux to 0 I am
> able to get back to the 12.1Mpps I was previously seeing.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
I applied this for now, making a minor change to move the local
variables down into the new basic block you created.
There has got to be a way to make this really cheap. At the very
least we can have the GRO code store away the ports and therefore
allow us to just do a direct call to try and demux the socket. Thus,
we'd avoid all of pskb_may_pull() et al. packet validations, and
packet header pointer calculations.
Furthermore, we can reduce to overhead by making a special inet
established hash demux that doesn't check for time-wait sockets,
reducing the number of probes to 1 from 2.
^ permalink raw reply
* Re: [PATCH] smsc911x.c: encapsulate enable irq calls
From: David Miller @ 2012-06-23 0:07 UTC (permalink / raw)
To: mbrugger; +Cc: steve.glendinning, netdev
In-Reply-To: <1340363415-10118-1-git-send-email-mbrugger@iseebcn.com>
From: Matthias Brugger <mbrugger@iseebcn.com>
Date: Fri, 22 Jun 2012 13:10:15 +0200
> We encapsulate enbale irq functionality in a function call.
> As on probe the interrupts will be disabled twice, we delete
> one.
>
> Signed-off-by: Matthias Brugger <mbrugger@iseebcn.com>
Applied to net-next.
^ permalink raw reply
* Re: Bug in net/ipv6/ip6_fib.c:fib6_dump_table()
From: David Miller @ 2012-06-23 0:02 UTC (permalink / raw)
To: eric.dumazet
Cc: johunt, kaber, dbavatar, netdev, yoshfuji, jmorris, pekkas,
kuznet, linux-kernel
In-Reply-To: <1340388785.4604.11442.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 22 Jun 2012 20:13:05 +0200
> On Fri, 2012-06-22 at 08:44 -0500, Josh Hunt wrote:
>
>> Ahh. That makes sense and is what Alexey said before I just didn't put
>> it all together. So we are OK reverting this patch? I cannot find a path
>> where the walker's pointers are updated without the tb6_lock write_lock.
>>
>
> There was a bug somewhere, not sure we want to NULL dereference again.
Well:
1) Patrick McHardy has been inactive for a while, so do not expect
any insight from him.
2) Ben Greear isn't even on the CC: list of this discussion yet he
appears to be the person who reproduced the crash way back then
and is listed in the Tested-by tag of the commit.
As a result we aren't likely to get any insight from the one person
who actually could hit the crash.
I'm inclined to just revert simply because we have people active who
can reproduce regressions introduced by this change and nobody can
understand why the change is even necessary.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox