* Re: [PATCH] ipv6: release referenct of ip6_null_entry's dst entry in __ip6_del_rt
From: David Miller @ 2012-09-21 17:16 UTC (permalink / raw)
To: gaofeng; +Cc: netdev
In-Reply-To: <1348118734-2967-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Thu, 20 Sep 2012 13:25:34 +0800
> as we hold dst_entry before we call __ip6_del_rt,
> so we should alse call dst_release not only return
> -ENOENT when the rt6_info is ip6_null_entry.
>
> and we already hold the dst entry, so I think it's
> safe to call dst_release out of the write-read lock.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
I cannot find a code path where we can actually end up
with an ip6_null_entry here and I'd much rather declare
this condition as a bug.
Patrick McHardy added this check back in 2006:
commit 6c813a7297e3af4cd7c3458e09e9ee3d161c6830
Author: Patrick McHardy <kaber@trash.net>
Date: Sun Aug 6 22:22:47 2006 -0700
[IPV6]: Fix crash in ip6_del_rt
But the ipv6 code has changed substantially since then.
^ permalink raw reply
* Re: [PATCH net-next 3/3] ptp: derive the device name from the parent device
From: Ben Hutchings @ 2012-09-21 17:19 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, David Miller, Jacob Keller, Jeff Kirsher, John Stultz,
Matthew Vick
In-Reply-To: <9f2ed4a62d52182eeab86ad3dca7f6feeb68368a.1348245523.git.richardcochran@gmail.com>
On Fri, 2012-09-21 at 19:00 +0200, Richard Cochran wrote:
> PTP Hardware Clock device have a name that appears under sysfs that should
> identify the underlying device. Instead of leaving it up to the driver to
> invent a name, this patch changes the registration to automatically use
> the name from the parent device.
I thought you wanted the driver name and not the parent device name?
[...]
> diff --git a/drivers/ptp/ptp_clock.c b/drivers/ptp/ptp_clock.c
> index 6e47450..60fa259 100644
> --- a/drivers/ptp/ptp_clock.c
> +++ b/drivers/ptp/ptp_clock.c
[...]
> @@ -219,11 +220,13 @@ struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info)
> init_waitqueue_head(&ptp->tsev_wq);
>
> /* Create a new device in our class. */
> - ptp->dev = device_create(ptp_class, NULL, ptp->devid, ptp,
> + ptp->dev = device_create(ptp_class, parent, ptp->devid, ptp,
> "ptp%d", ptp->index);
> if (IS_ERR(ptp->dev))
> goto no_device;
>
> + ptp->name = parent ? dev_name(parent) : dev_name(ptp->dev);
> +
The fallback of using dev_name(ptp->dev) is a bit sad, as that's the
same name userland already has when it reads this attribute.
[...]
> diff --git a/drivers/ptp/ptp_ixp46x.c b/drivers/ptp/ptp_ixp46x.c
> index e03c406..c0939b1 100644
> --- a/drivers/ptp/ptp_ixp46x.c
> +++ b/drivers/ptp/ptp_ixp46x.c
> @@ -241,7 +241,6 @@ static int ptp_ixp_enable(struct ptp_clock_info *ptp,
>
> static struct ptp_clock_info ptp_ixp_caps = {
> .owner = THIS_MODULE,
> - .name = "IXP46X timer",
> .max_adj = 66666655,
> .n_ext_ts = N_EXT_TS,
> .pps = 0,
> @@ -298,7 +297,7 @@ static int __init ptp_ixp_init(void)
>
> ixp_clock.caps = ptp_ixp_caps;
>
> - ixp_clock.ptp_clock = ptp_clock_register(&ixp_clock.caps);
> + ixp_clock.ptp_clock = ptp_clock_register(&ixp_clock.caps, NULL);
[...]
I think this should really register a platform driver and a platform
device to be the parent of the clock device. And then you don't need
the fallback for parent == NULL.
Since David has pulled the addition of PTP/PHC support to sfc, that will
need to be adjusted as well.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: remove unnecessary call rt6_clean_expires
From: David Miller @ 2012-09-21 17:19 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev, gaofeng
In-Reply-To: <1348119118-23416-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 20 Sep 2012 13:31:58 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> the from of dst_entry and rt6i_flags of rt6_info have been zeroed out in
> ip6_blackhole_route or after calling ip6_dst_alloc, so it is unnecessary
> to call rt6_clean_expires again.
>
> Cc: Gao feng <gaofeng@cn.fujitsu.com>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
I still don't like this change.
The rt6_clean_expires() calls actually do some work (clear the
RTF_EXPIRES) bit in two of the cases you are changing.
And more importantly, having the rt6_clean_expires() call makes
it easier to audit and make sure this is handled in all the
necessary situations.
The whole point of having an abstracted helper function is so
that we don't have code directly manipulating RTF_EXPIRES.
I'm not applying this patch, sorry.
^ permalink raw reply
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: David Miller @ 2012-09-21 17:20 UTC (permalink / raw)
To: jjolly; +Cc: linux-kernel, venkat.x.venkatsubra, netdev
In-Reply-To: <20120920071134.GF14393@linux-tkdk.sfcn.org>
From: John Jolly <jjolly@suse.com>
Date: Thu, 20 Sep 2012 01:11:34 -0600
> Attempting an rds connection from the IP address of an IPoIB interface
> to itself causes a kernel panic due to a BUG_ON() being triggered. Making
> the test less strict allows rds-ping to work without crashing the machine.
>
> A local unprivileged user could use this flaw to crash the sytem.
Please read Documentation/SubmittingPatches to learn how to properly
submit a change, in particular your patch submission was missing a
proper signoff.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200
From: David Miller @ 2012-09-21 17:22 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, fangxiaozhi, tschaefer, dcbw, shawn7400
In-Reply-To: <1348125485-3404-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 20 Sep 2012 09:18:05 +0200
> This is the net-next version of the previously posted patch with the
> same title. I totally forgot that I had messed with the .driver_info
> fields, making it impossible to apply the same patch to both net and
> net-next.
>
> Sorry about that. Please apply this version to net-next. The other
> one should still be applied to net (if still possible) and stable.
Ok I applied this to net-next, and it should help with the merge
resolution between net and net-next, which BTW Stephen Rothwell
already had to deal with.
^ permalink raw reply
* Re: regression: tethering fails in 3.5 with iwlwifi
From: David Miller @ 2012-09-21 17:24 UTC (permalink / raw)
To: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
Cc: artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, johannes-cdvu00un1VgdHxzADdlk8Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1348151149.31352.109.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 20 Sep 2012 16:25:49 +0200
> Please remove this hack and try the following bugfix in raw handler
>
> icmp_filter() should not modify skb, or else its caller should not
> assume ip_hdr() is unchanged.
Right, good catch.
Please submit this fix formally Eric, thanks a lot.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 net] bnx2x: remove false warning regarding interrupt number
From: David Miller @ 2012-09-21 17:27 UTC (permalink / raw)
To: ariele; +Cc: netdev, eilong
In-Reply-To: <1348154801-6592-1-git-send-email-ariele@broadcom.com>
From: "Ariel Elior" <ariele@broadcom.com>
Date: Thu, 20 Sep 2012 18:26:41 +0300
> Since version 7.4 the FW configures in the pci config space the max
> number of interrupts available to the physical function, instead of
> the exact number to use.
> This causes a false warning in driver when comparing the number of
> configured interrupts to the number about to be used.
>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: sysctl for initial receive window
From: Jesper Dangaard Brouer @ 2012-09-21 17:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Nandita Dukkipati
In-Reply-To: <1348241111.2669.580.camel@edumazet-glaptop>
On Fri, 2012-09-21 at 17:25 +0200, Eric Dumazet wrote:
> On Fri, 2012-09-21 at 10:55 +0200, Jesper Dangaard Brouer wrote:
> > Make it possible to adjust the TCP default initial advertised receive
> > window, via sysctl /proc/sys/net/ipv4/tcp_init_recv_window.
> >
> > The window size is this value multiplied by the MSS of the connection.
> > The default value is (still) 10, as descibed in commit 356f039822b
> > (TCP: increase default initial receive window.)
> >
> > Allow minimum value of 1, but recommend against setting value below 2
> > in the documentation.
> >
> > Its possible to control/override this value per route table entry via
> > the iproute2 option initrwnd. Having the global default exported via
> > sysctl, helps determine the default setting, and make is easier to
> > adjust.
>
> I was wondering why its not symmetric :
>
> If we add a sysctl for initial receive window, we need another one for
> initial send window ?
Yes, that was also part of my plan (I just didn't have time to complete
it). I'll implement the sysctl for initial congestion window, next
week.
Just wanted some initial feedback, on if this sysctl approach is
acceptable or not.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] gianfar: Change default HW Tx queue scheduling mode
From: David Miller @ 2012-09-21 17:35 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, paul.gortmaker
In-Reply-To: <1348156674-31551-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Thu, 20 Sep 2012 18:57:54 +0300
> The TXSCHED setting may be changed at runtime, via sysfs, for devices
> using multiple H/W Tx queues. For single queue devices this config
> option is disabled, as the TXSCHED setting is superfluous in those cases.
Please, no special driver specific sysfs knobs.
Extend ethtool as necessary for your needs, so that any driver can
provide this kind of configurability in a consistent way for users..
^ permalink raw reply
* Re: New commands to configure IOV features
From: Ben Hutchings @ 2012-09-21 17:35 UTC (permalink / raw)
To: Yinghai Lu
Cc: Rose, Gregory V, Bjorn Helgaas, Yuval Mintz, davem@davemloft.net,
netdev@vger.kernel.org, Ariel Elior, Eilon Greenstein, linux-pci
In-Reply-To: <CAE9FiQXqFnrXT8ibD2zsmeTj-VzXb8sAOjUtryBOxEXj216pQQ@mail.gmail.com>
On Thu, 2012-09-20 at 22:50 -0700, Yinghai Lu wrote:
[...]
> Index: linux-2.6/include/linux/pci.h
> ===================================================================
> --- linux-2.6.orig/include/linux/pci.h
> +++ linux-2.6/include/linux/pci.h
> @@ -663,6 +663,7 @@ struct pci_driver {
> const struct pci_device_id *id_table; /* must be non-NULL for probe to be called */
> int (*probe) (struct pci_dev *dev, const struct pci_device_id *id); /* New device inserted */
> void (*remove) (struct pci_dev *dev); /* Device removed (NULL if not a hot-plug capable driver) */
> + void (*set_max_vfs) (struct pci_dev *dev); /* enable sriov */
> int (*suspend) (struct pci_dev *dev, pm_message_t state); /* Device suspended */
> int (*suspend_late) (struct pci_dev *dev, pm_message_t state);
> int (*resume_early) (struct pci_dev *dev);
Not sure about this; the driver may fail to enable those VFs and it
would be nice to be able to report that failure directly.
That said, this is 'max_vfs' (a limit) and if the driver fails to set up
all the VFs then the *limit* may still be changed.
> Subject: [PATCH] PCI: Add max_vfs in sysfs per pci device where supports
>
> driver later need to check dev->max_vfs in /sys
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
[...]
> +static ssize_t
> +max_vfs_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + unsigned long val;
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if (strict_strtoul(buf, 0, &val) < 0)
> + return -EINVAL;
> +
> + pdev->max_vfs = val;
> +
> + if (pdev->is_added) {
No locking required here?
> + int err;
> + err = device_schedule_callback(dev, max_vfs_callback);
Any particular reason this should be a callback?
[...]
> Index: linux-2.6/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ linux-2.6/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -129,13 +129,6 @@ static struct notifier_block dca_notifie
> };
> #endif
>
> -#ifdef CONFIG_PCI_IOV
> -static unsigned int max_vfs;
> -module_param(max_vfs, uint, 0);
> -MODULE_PARM_DESC(max_vfs,
> - "Maximum number of virtual functions to allocate per
> physical function - default is zero and maximum value is 63");
> -#endif /* CONFIG_PCI_IOV */
> -
> static unsigned int allow_unsupported_sfp;
> module_param(allow_unsupported_sfp, uint, 0);
> MODULE_PARM_DESC(allow_unsupported_sfp,
> @@ -4528,7 +4521,7 @@ static int __devinit ixgbe_sw_init(struc
> #ifdef CONFIG_PCI_IOV
> /* assign number of SR-IOV VFs */
> if (hw->mac.type != ixgbe_mac_82598EB)
> - adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
> + adapter->num_vfs = (pdev->max_vfs > 63) ? 0 : pdev->max_vfs;
We are trying to make all SR-IOV capable drivers work the same, so this
weird limiting behaviour should not be retained.
So I think the correct assignment is:
adapter->num_vfs = min(pdev->max_vfs, 63);
> #endif
> /* enable itr by default in dynamic mode */
> @@ -7249,8 +7242,9 @@ static int __devinit ixgbe_probe(struct
>
> #ifdef CONFIG_PCI_IOV
> ixgbe_enable_sriov(adapter, ii);
> -
> #endif
> + adapter->ixgbe_info = ii;
> +
> netdev->features = NETIF_F_SG |
> NETIF_F_IP_CSUM |
> NETIF_F_IPV6_CSUM |
> @@ -7720,11 +7714,42 @@ static const struct pci_error_handlers i
> .resume = ixgbe_io_resume,
> };
>
> +static void ixgbe_set_max_vfs(struct pci_dev *pdev)
> +{
> +#ifdef CONFIG_PCI_IOV
> + struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
> + struct net_device *netdev = adapter->netdev;
> + struct ixgbe_hw *hw = &adapter->hw;
> + int num_vfs = 0;
> +
> + /* assign number of SR-IOV VFs */
> + if (hw->mac.type != ixgbe_mac_82598EB)
> + num_vfs = (pdev->max_vfs > 63) ? 0 : pdev->max_vfs;
> +
> + /* no change */
> + if (adapter->num_vfs == num_vfs)
> + return;
> +
> + if (!num_vfs) {
> + /* disable sriov */
> + ixgbe_disable_sriov(adapter);
> + adapter->num_vfs = 0;
> + } else if (!adapter->num_vfs && num_vfs) {
> + /* enable sriov */
> + adapter->num_vfs = num_vfs;
> + ixgbe_enable_sriov(adapter, adapter->ixgbe_info);
> + } else {
> + /* increase or decrease */
Indeed, increase or decrease is not supported either in our PCI API or
in the SR-IOV spec. I think I would prefer the PCI core to filter out
unsupported changes (i.e. not call set_max_vfs and maybe report an
error), but I'm not sure about that.
Ben.
> + }
> +#endif
> +}
> +
[...]
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 3/3] ptp: derive the device name from the parent device
From: Richard Cochran @ 2012-09-21 17:37 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, David Miller, Jacob Keller, Jeff Kirsher, John Stultz,
Matthew Vick
In-Reply-To: <1348247965.2521.11.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, Sep 21, 2012 at 06:19:25PM +0100, Ben Hutchings wrote:
> On Fri, 2012-09-21 at 19:00 +0200, Richard Cochran wrote:
> > PTP Hardware Clock device have a name that appears under sysfs that should
> > identify the underlying device. Instead of leaving it up to the driver to
> > invent a name, this patch changes the registration to automatically use
> > the name from the parent device.
>
> I thought you wanted the driver name and not the parent device name?
Yes, I originally wanted the driver name, because it gives the user
information about the expected performance. But here I am bowing to
Jacob's suggestion that we really need to identify the device. Intel
cards with two ports have *two* clocks. Sad but true.
> > + ptp->name = parent ? dev_name(parent) : dev_name(ptp->dev);
> > +
>
> The fallback of using dev_name(ptp->dev) is a bit sad, as that's the
> same name userland already has when it reads this attribute.
This fallback only exists for the ixp46x, since that driver has no
proper platform or device tree device.
> > - ixp_clock.ptp_clock = ptp_clock_register(&ixp_clock.caps);
> > + ixp_clock.ptp_clock = ptp_clock_register(&ixp_clock.caps, NULL);
> [...]
>
> I think this should really register a platform driver and a platform
> device to be the parent of the clock device. And then you don't need
> the fallback for parent == NULL.
That chip is long past EOL, and its PTP capabilities are pretty poor,
and so it is not worth the trouble of fixing it up.
All other (and future) drivers must provide the pointer.
> Since David has pulled the addition of PTP/PHC support to sfc, that will
> need to be adjusted as well.
Okay, I will add that to the series.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v2] ipconfig: add nameserver IPs to kernel-parameter ip=
From: David Miller @ 2012-09-21 17:37 UTC (permalink / raw)
To: chf.fritz
Cc: rob, kuznet, j.weitzel, jmorris, yoshfuji, kaber, linux-doc,
linux-kernel, netdev, hjk, daniel
In-Reply-To: <1348177730.3858.98.camel@mars>
From: Christoph Fritz <chf.fritz@googlemail.com>
Date: Thu, 20 Sep 2012 23:48:50 +0200
> diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt
> index ffdd9d8..4ed7875 100644
> --- a/Documentation/filesystems/nfs/nfsroot.txt
> +++ b/Documentation/filesystems/nfs/nfsroot.txt
> @@ -158,6 +158,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
>
> Default: any
>
> + <dns0-ip> IP address of first nameserver.
> + Value gets exported by /proc/net/pnp which is often linked
> + on embedded systems by /etc/resolv.conf.
> +
> + <dns1-ip> IP address of secound nameserver.
> + Same as above.
> +
>
> nfsrootdebug
>
This documentation update is not sufficient.
You have to properly show, in the lines above where you made your change,
where the new settings are placed in the "ip=" option.
^ permalink raw reply
* RE: [PATCH net-next 3/3] ptp: derive the device name from the parent device
From: Keller, Jacob E @ 2012-09-21 17:39 UTC (permalink / raw)
To: Richard Cochran, Ben Hutchings
Cc: netdev@vger.kernel.org, David Miller, Kirsher, Jeffrey T,
John Stultz, Vick, Matthew
In-Reply-To: <20120921173709.GB6129@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Friday, September 21, 2012 10:37 AM
> To: Ben Hutchings
> Cc: netdev@vger.kernel.org; David Miller; Keller, Jacob E; Kirsher,
> Jeffrey T; John Stultz; Vick, Matthew
> Subject: Re: [PATCH net-next 3/3] ptp: derive the device name from the
> parent device
>
> On Fri, Sep 21, 2012 at 06:19:25PM +0100, Ben Hutchings wrote:
> > On Fri, 2012-09-21 at 19:00 +0200, Richard Cochran wrote:
> > > PTP Hardware Clock device have a name that appears under sysfs that
> > > should identify the underlying device. Instead of leaving it up to
> > > the driver to invent a name, this patch changes the registration to
> > > automatically use the name from the parent device.
> >
> > I thought you wanted the driver name and not the parent device name?
>
> Yes, I originally wanted the driver name, because it gives the user
> information about the expected performance. But here I am bowing to
> Jacob's suggestion that we really need to identify the device. Intel cards
> with two ports have *two* clocks. Sad but true.
>
With the device, it is possible to lookup the driver.
- Jake
> Thanks,
> Richard
^ permalink raw reply
* RE: [PATCH net-next 3/3] ptp: derive the device name from the parent device
From: Ben Hutchings @ 2012-09-21 17:40 UTC (permalink / raw)
To: Keller, Jacob E
Cc: Richard Cochran, netdev@vger.kernel.org, David Miller,
Kirsher, Jeffrey T, John Stultz, Vick, Matthew
In-Reply-To: <02874ECE860811409154E81DA85FBB5818BFF5B4@ORSMSX105.amr.corp.intel.com>
On Fri, 2012-09-21 at 17:39 +0000, Keller, Jacob E wrote:
> > -----Original Message-----
> > From: Richard Cochran [mailto:richardcochran@gmail.com]
> > Sent: Friday, September 21, 2012 10:37 AM
> > To: Ben Hutchings
> > Cc: netdev@vger.kernel.org; David Miller; Keller, Jacob E; Kirsher,
> > Jeffrey T; John Stultz; Vick, Matthew
> > Subject: Re: [PATCH net-next 3/3] ptp: derive the device name from the
> > parent device
> >
> > On Fri, Sep 21, 2012 at 06:19:25PM +0100, Ben Hutchings wrote:
> > > On Fri, 2012-09-21 at 19:00 +0200, Richard Cochran wrote:
> > > > PTP Hardware Clock device have a name that appears under sysfs that
> > > > should identify the underlying device. Instead of leaving it up to
> > > > the driver to invent a name, this patch changes the registration to
> > > > automatically use the name from the parent device.
> > >
> > > I thought you wanted the driver name and not the parent device name?
> >
> > Yes, I originally wanted the driver name, because it gives the user
> > information about the expected performance. But here I am bowing to
> > Jacob's suggestion that we really need to identify the device. Intel cards
> > with two ports have *two* clocks. Sad but true.
> >
>
> With the device, it is possible to lookup the driver.
For PCI devices, yes. But there is really no guarantee that device
names (as in dev_name()) are globally unique either.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/3 V2] phy/micrel: Implement support for KSZ8021
From: David Miller @ 2012-09-21 17:42 UTC (permalink / raw)
To: marex; +Cc: netdev, david.choi, nobuhiro.iwamatsu.yj, fabio.estevam,
shawn.guo
In-Reply-To: <1348195976-31703-1-git-send-email-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Fri, 21 Sep 2012 04:52:54 +0200
> + phy_write(phydev, MII_KSZPHY_OMSO,
> + KSZPHY_OMSO_B_CAST_OFF | KSZPHY_OMSO_RMII_OVERRIDE);
This is not indented properly. The goal is not to exclusively use
TAB characters to indent code until it sort-of looks fine.
Rather, the goal is to properly line up function arguments with
the first column after the openning parenthesis on the previous
line. Using TAB and SPACE characters, as needed.
> + .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
> + | SUPPORTED_Asym_Pause),
This is similarly not styled properly.
Besies being indented imporperly on the second line, the final "|"
character should be at the end of the first line, rather than
start the second line.
Resubmit this entire patch series, not just this one patch, once
you've made these corrections.
Thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: fix return value check in fib6_add()
From: David Miller @ 2012-09-21 17:44 UTC (permalink / raw)
To: weiyj.lk; +Cc: kuznet, jmorris, yoshfuji, kaber, yongjun_wei, netdev
In-Reply-To: <CAPgLHd9vdKJfj1yUqU+zDaH6PiuqY8ZG_V5B1py--NiDwa+WkA@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Fri, 21 Sep 2012 12:29:56 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function fib6_add_1() returns ERR_PTR()
> or NULL pointer. The ERR_PTR() case check is missing in fib6_add().
>
> dpatch engine is used to generated this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thanks.
Longer term fib6_add_1() should consistently return errno pointers,
rather than a mixture of NULL and errno pointers.
^ permalink raw reply
* Re: [PATCH 1/1] gianfar: fix phc index build failure
From: David Miller @ 2012-09-21 17:46 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, stable
In-Reply-To: <24134c2d3a9bcbe65f1becd809b98d9c2559212d.1348203988.git.richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com>
Date: Fri, 21 Sep 2012 07:11:12 +0200
> This patch fixes a build failure introduced in commit 66636287. Not only
> was a global variable inconsistently named, but also it was not exported
> as it should have been.
>
> This fix is also needed in stable version 3.5.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Applied and queued up for -stable, thanks.
> Cc: <stable@vger.kernel.org>
Do not add -stable CC:'s to networking patches, please instead simply
ask me to queue it up for -stable as I take care of networking stable
submissions myself rather than via the automated procedure.
^ permalink raw reply
* Re: [PATCH] stmmac: fix return value check in stmmac_open_ext_timer()
From: David Miller @ 2012-09-21 17:47 UTC (permalink / raw)
To: weiyj.lk; +Cc: peppe.cavallaro, yongjun_wei, netdev
In-Reply-To: <CAPgLHd87SqVa40-SGrgEfRAPWj1dr9aGPDD7b3aALCqka2ssuA@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Fri, 21 Sep 2012 15:06:10 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function clk_get() returns ERR_PTR()
> and never returns NULL pointer. The NULL test in the error
> handling should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] net/irda: sh_sir: fix return value check in sh_sir_set_baudrate()
From: David Miller @ 2012-09-21 17:47 UTC (permalink / raw)
To: weiyj.lk; +Cc: samuel, yongjun_wei, netdev
In-Reply-To: <CAPgLHd9DZuXtx2atvpLV3bHC9tnv+CNaKhvEWzv6f3iS--vfcg@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Fri, 21 Sep 2012 15:13:55 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> In case of error, the function clk_get() returns ERR_PTR()
> and never returns NULL pointer. The NULL test in the error
> handling should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v4 0/1] Add support of ECMPv6
From: David Miller @ 2012-09-21 17:48 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: bernat, netdev, yoshfuji
In-Reply-To: <1348221545-14747-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 21 Sep 2012 11:59:04 +0200
> v4: remove compilation options to choose multipath algorithm for next hop
> selection. Now the choice can be done at run time via
> /proc/sys/net/ipv6/route/multipath_algorithm
Please specify this in the routing configuration protocol, rather than
via some obscure procfs file.
Thanks.
^ permalink raw reply
* Re: [PATCH] mISDN: suppress compiler warning
From: David Miller @ 2012-09-21 17:49 UTC (permalink / raw)
To: pebolle; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <1348223124.1581.15.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Fri, 21 Sep 2012 12:25:24 +0200
> Building the hfcpci driver triggers this GCC warning:
> drivers/isdn/hardware/mISDN/hfcpci.c:2298:2: warning: ignoring return value of 'driver_for_each_device', declared with attribute warn_unused_result [-Wunused-result]
>
> That return value is apparently ignored because _hfcpci_softirq() will
> always return 0. Suppress this warning in the way a few other drivers do
> that too.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
This is pretty pointless and I'm therefore not applying it.
^ permalink raw reply
* Re: pull-request: can 2012-09-21
From: David Miller @ 2012-09-21 17:51 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1348225535-24976-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 21 Sep 2012 13:05:33 +0200
> two patches for the v3.6 release cycle. Ira W. Snyder fixed support for the
> older version of the Janz CMOD-IO Carrier Board. I found and fixed an oops in
> the ti_hecc driver, which occurs when removing the module if the network
> interface is still open.
...
> The following changes since commit c0d680e577ff171e7b37dbdb1b1bf5451e851f04:
>
> net: do not disable sg for packets requiring no checksum (2012-09-20 22:23:40 -0400)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-can/linux-can.git fixes-for-3.6
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: sysctl for initial receive window
From: David Miller @ 2012-09-21 17:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: brouer, netdev, nanditad
In-Reply-To: <1348241111.2669.580.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Sep 2012 17:25:11 +0200
> On Fri, 2012-09-21 at 10:55 +0200, Jesper Dangaard Brouer wrote:
>> Make it possible to adjust the TCP default initial advertised receive
>> window, via sysctl /proc/sys/net/ipv4/tcp_init_recv_window.
>>
>> The window size is this value multiplied by the MSS of the connection.
>> The default value is (still) 10, as descibed in commit 356f039822b
>> (TCP: increase default initial receive window.)
>>
>> Allow minimum value of 1, but recommend against setting value below 2
>> in the documentation.
>>
>> Its possible to control/override this value per route table entry via
>> the iproute2 option initrwnd. Having the global default exported via
>> sysctl, helps determine the default setting, and make is easier to
>> adjust.
>
> I was wondering why its not symmetric :
>
> If we add a sysctl for initial receive window, we need another one for
> initial send window ?
Unlike the routing configuration, this is susceptible to serious abuse.
All it takes is for one jackass vendor to say that this should be set
to 1,000 in in sysctl.conf when using their product.
Whereas setting it on a per-route basis forces the person doing it
to actually consider that there might be ramifications that have to
do with the paths on which you are making this adjustment.
I would only let this in if you hard limited the setting to it's
current setting, 10. So people could decrease it.
^ permalink raw reply
* Re: [PATCH] net: change return values from -EACCES to -EPERM
From: David Miller @ 2012-09-21 17:58 UTC (permalink / raw)
To: zhaohongjiang37; +Cc: netdev, serge.hallyn, ebiederm
In-Reply-To: <505C2745.4080704@gmail.com>
From: Zhao Hongjiang <zhaohongjiang37@gmail.com>
Date: Fri, 21 Sep 2012 16:37:25 +0800
> From: Zhao Hongjiang <zhaohongjiang@huawei.com>
>
> Change return value from -EACCES to -EPERM when the permission check fails.
>
> Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/3 V2] phy/micrel: Implement support for KSZ8021
From: Marek Vasut @ 2012-09-21 18:04 UTC (permalink / raw)
To: David Miller
Cc: netdev, david.choi, nobuhiro.iwamatsu.yj, fabio.estevam,
shawn.guo
In-Reply-To: <20120921.134215.1719885507288305623.davem@davemloft.net>
Dear David Miller,
> From: Marek Vasut <marex@denx.de>
> Date: Fri, 21 Sep 2012 04:52:54 +0200
>
> > + phy_write(phydev, MII_KSZPHY_OMSO,
> > + KSZPHY_OMSO_B_CAST_OFF | KSZPHY_OMSO_RMII_OVERRIDE);
>
> This is not indented properly. The goal is not to exclusively use
> TAB characters to indent code until it sort-of looks fine.
The goal was to avoid checkpatch trouble.
> Rather, the goal is to properly line up function arguments with
> the first column after the openning parenthesis on the previous
> line. Using TAB and SPACE characters, as needed.
>
> > + .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
> > + | SUPPORTED_Asym_Pause),
>
> This is similarly not styled properly.
This is copy-pasted from other entry. I'd hate to reformat the whole file.
> Besies being indented imporperly on the second line, the final "|"
> character should be at the end of the first line, rather than
> start the second line.
DTTO here.
> Resubmit this entire patch series, not just this one patch, once
> you've made these corrections.
>
> Thanks.
Best regards,
Marek Vasut
^ 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