* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Linus Torvalds @ 2014-12-08 22:23 UTC (permalink / raw)
To: Theodore Ts'o, Kirill A. Shutemov, Linus Torvalds, Al Viro,
Linux Kernel Mailing List, linux-fsdevel, Network Development
In-Reply-To: <20141208221401.GA4991@thunk.org>
On Mon, Dec 8, 2014 at 2:14 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> running trinity as root should be quite safe in a VM. :-)
It's not so much the safety that I'd worry about, it's the "you can
legitimately just reboot it or cause kernel corruption as root". You
may not cause any problems outside of the VM, but any oopses inside
the VM might be due to trinity just doing bad things as root, rather
than kernel bugs..
Of course, it's probably hard to hit things like laoding random
modules etc, since even without signature requirements there are tons
of ELF sanity checks and other things. So it might be hard to actually
do those kinds of "corrupt kernel memory as root" things with trinity.
Linus
^ permalink raw reply
* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Dave Jones @ 2014-12-08 22:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Ts'o, Kirill A. Shutemov, Al Viro,
Linux Kernel Mailing List, linux-fsdevel, Network Development
In-Reply-To: <CA+55aFz26Xvfs4iePpGgJotw+uwFCKduGqyM57adgfGepQYp_w@mail.gmail.com>
On Mon, Dec 08, 2014 at 02:23:06PM -0800, Linus Torvalds wrote:
> On Mon, Dec 8, 2014 at 2:14 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> >
> > running trinity as root should be quite safe in a VM. :-)
>
> It's not so much the safety that I'd worry about, it's the "you can
> legitimately just reboot it or cause kernel corruption as root". You
> may not cause any problems outside of the VM, but any oopses inside
> the VM might be due to trinity just doing bad things as root, rather
> than kernel bugs..
>
> Of course, it's probably hard to hit things like laoding random
> modules etc, since even without signature requirements there are tons
> of ELF sanity checks and other things. So it might be hard to actually
> do those kinds of "corrupt kernel memory as root" things with trinity.
It also goes out of its way to avoid doing obviously stupid things,
like using /dev/mem as an fd, plus a whole bunch of similar sysfs/procfs
knobs. There are still likely a whole bunch of similar things that
might have horrible effects too. It's been on my todo for a while to
revisit that particular case and blacklist a bunch of other things.
And then there's obviously "don't do this syscall, ever" or "with these
args" type things, which could use expanding.. It's a big effort tbh.
I'm amazed that Sasha, Kirill and everyone else running it as root in
vm's aren't buried alive in false-positives.
Dave
^ permalink raw reply
* Re: [PATCH nf-next 1/2] netfilter: conntrack: cache route for forwarded connections
From: Florian Westphal @ 2014-12-08 22:33 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, netdev, brouer
In-Reply-To: <1418052964-4632-2-git-send-email-fw@strlen.de>
Florian Westphal <fw@strlen.de> wrote:
> + if (likely(dst))
> + skb_dst_set_noref_force(skb, dst);
Note that Hannes submitted a patch vs. net-next that removes
skb_dst_set_noref_force().
So depending on the oder in which the patches are applied
(iff they are...) the above should read
skb_dst_set_noref(skb, dst);
instead.
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Dan Williams @ 2014-12-08 22:41 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: Pali Rohár, Marcel Holtmann, Greg Kroah-Hartman, Ming Lei,
Pavel Machek, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Aaro Koskinen, Kalle Valo,
Sebastian Reichel, David Gnedt
In-Reply-To: <5485FF17.1070504@gmail.com>
On Mon, 2014-12-08 at 21:42 +0200, Ivaylo Dimitrov wrote:
>
> On 8.12.2014 21:26, Dan Williams wrote:
> >
> > a) change driver to prefer a new "wl1251-nvs-n900.bin" file, but fall
> > back to "wl1251-nvs.bin" if the first one isn't present
> > b) have a "wl1251-cal-nvs-update" service that, if wl1521-nvs-n900.bin
> > is *not* present mounts the CAL MTD, reads the data, writes it out into
> > wl1521-nvs-n900.bin, and the rmmod/modprobes the driver
> >
> > and done? Stuff that's not N900 just wouldn't ship the update service
> > and would proceed like none of this happened.
> >
> > Dan
> >
> >
>
> That would mean that the driver should not be built-in, as afaik we
> cannot rmmod built-in drivers. Sure, it will work after a reboot, but
> this is a bit hacky, agree?
>
> Also, new NVS file needs to be loaded when fcc regulation changes(flying
> abroad), so that would mean that the device would be outside of those
> until reboot (in case of built-in driver)
Regulatory stuff needs to be hooked into CRDA or the existing regulatory
codepaths, not some other path. So when cfg80211 sets the regulatory
domain on the driver the driver needs to get the necessary NVS data.
Either the NVS for every domain (which cannot be a lot of them) gets
hardcoded into the driver, and then selected based on what cfg80211
says, or the driver needs to ask userspace for the NVS data based on
what cfg80211 says. In all cases, cfg80211 drives the regulatory domain
[1].
a) How many regulatory domains does the driver support, how much data is
there for each domain, and can that be put into the driver instead of
getting it from the CAL partition?
b) what do *other* (non-N900) wl1251 devices do for regulatory data?
Dan
[1] unless there's some *restriction* hardcoded into the EEPROM of the
device, which in the case of the N900 there isn't, since the regulatory
data changes based on the MCC/MNC of the cellular side.
^ permalink raw reply
* Re: [PATCH net-next v5 1/3] bridge: new mode flag to indicate mode 'undefined'
From: Scott Feldman @ 2014-12-08 22:43 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <1418076261-24593-2-git-send-email-roopa@cumulusnetworks.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
On Mon, Dec 8, 2014 at 2:04 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds mode BRIDGE_MODE_UNDEF for cases where mode is not needed.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> ---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> index 296a556..05f0869 100644
> --- a/include/uapi/linux/if_bridge.h
> +++ b/include/uapi/linux/if_bridge.h
> @@ -106,6 +106,7 @@ struct __fdb_entry {
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> #define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
> +#define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
>
> /* Bridge management nested attributes
> * [IFLA_AF_SPEC] = {
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 2/3] rocker: remove swdev mode
From: Scott Feldman @ 2014-12-08 22:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <1418076261-24593-3-git-send-email-roopa@cumulusnetworks.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
On Mon, Dec 8, 2014 at 2:04 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Remove use of 'swdev' mode in rocker. rocker dev offloads
> can use the BRIDGE_FLAGS_SELF to indicate offload to hardware.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> net/core/rtnetlink.c | 10 ++++++++--
> 2 files changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> index fded127..a841f7a 100644
> --- a/drivers/net/ethernet/rocker/rocker.c
> +++ b/drivers/net/ethernet/rocker/rocker.c
> @@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> struct nlattr *protinfo;
> - struct nlattr *afspec;
> struct nlattr *attr;
> - u16 mode;
> int err;
>
> protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> IFLA_PROTINFO);
> - afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
> -
> - if (afspec) {
> - attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
> - if (attr) {
> - if (nla_len(attr) < sizeof(mode))
> - return -EINVAL;
> -
> - mode = nla_get_u16(attr);
> - if (mode != BRIDGE_MODE_SWDEV)
> - return -EINVAL;
> - }
> - }
> -
> if (protinfo) {
> attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
> if (attr) {
> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> u32 filter_mask)
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> - u16 mode = BRIDGE_MODE_SWDEV;
> + u16 mode = BRIDGE_MODE_UNDEF;
> u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
>
> return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 61cb7e7..3863e3b 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2734,11 +2734,17 @@ int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> if (!br_afspec)
> goto nla_put_failure;
>
> - if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF) ||
> - nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
> + if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF)) {
> nla_nest_cancel(skb, br_afspec);
> goto nla_put_failure;
> }
> +
> + if (mode != BRIDGE_MODE_UNDEF) {
> + if (nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
> + nla_nest_cancel(skb, br_afspec);
> + goto nla_put_failure;
> + }
> + }
> nla_nest_end(skb, br_afspec);
>
> protinfo = nla_nest_start(skb, IFLA_PROTINFO | NLA_F_NESTED);
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 3/3] bridge: remove mode BRIDGE_MODE_SWDEV
From: Scott Feldman @ 2014-12-08 22:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <1418076261-24593-4-git-send-email-roopa@cumulusnetworks.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
On Mon, Dec 8, 2014 at 2:04 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch removes bridge mode swdev.
> Users can use BRIDGE_FLAGS_SELF to indicate swdev offload
> if needed.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> include/uapi/linux/if_bridge.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> index 05f0869..b03ee8f 100644
> --- a/include/uapi/linux/if_bridge.h
> +++ b/include/uapi/linux/if_bridge.h
> @@ -105,7 +105,6 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> -#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
> #define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
>
> /* Bridge management nested attributes
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] remove bridge mode BRIDGE_MODE_SWDEV
From: Scott Feldman @ 2014-12-08 22:49 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <1418076261-24593-1-git-send-email-roopa@cumulusnetworks.com>
Roopa, thanks for fixing this. I'm a little lost on status of the
iproute2 patches related to this change and earlier changes. Would
you and Jiri respin one set of iproute2 patches that gets us the final
answer? It was getting a little messy with patches on top of
yet-to-be-accepted patches. Thanks.
On Mon, Dec 8, 2014 at 2:04 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> BRIDGE_MODE_SWDEV was introduced to indicate switchdev offloads
> for bridging from user space (In other words to call into the hw switch
> port driver directly). But user can use existing BRIDGE_FLAGS_SELF
> to call into the hw switch port driver today. swdev mode is not required
> anymore. So, this patch removes it.
>
> v4 - v5
> incorporate comments
> - Define BRIDGE_MODE_UNDEF to handle cases where mode is not defined
> - reverse the order of patches
> - include patch comments in all patches
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Roopa Prabhu (3):
> bridge: new mode flag to indicate mode 'undefined'
> rocker: remove swdev mode
> bridge: remove mode 'swdev'
>
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> include/uapi/linux/if_bridge.h | 2 +-
> net/core/rtnetlink.c | 10 ++++++++--
> 3 files changed, 10 insertions(+), 20 deletions(-)
>
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Dan Williams @ 2014-12-08 22:51 UTC (permalink / raw)
To: Pali Rohár
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412082036.14609@pali>
On Mon, 2014-12-08 at 20:36 +0100, Pali Rohár wrote:
> On Monday 08 December 2014 20:26:53 Dan Williams wrote:
> > On Mon, 2014-12-08 at 20:15 +0100, Pali Rohár wrote:
> > > On Monday 08 December 2014 19:50:17 Marcel Holtmann wrote:
> > > > Hi Pali,
> > > >
> > > > >>>>>> On Saturday 06 December 2014 13:49:54 Pavel Machek
> > > > >>>>>> wrote: /**
> > > > >>>>>>
> > > > >>>>>> + * request_firmware_prefer_user: - prefer usermode
> > > > >>>>>> helper for loading firmware + * @firmware_p:
> > > > >>>>>> pointer to firmware image
> > > > >>>>>> + * @name: name of firmware file
> > > > >>>>>> + * @device: device for which firmware is being
> > > > >>>>>> loaded + *
> > > > >>>>>> + * This function works pretty much like
> > > > >>>>>> request_firmware(), but it prefer + * usermode
> > > > >>>>>> helper. If usermode helper fails then it fallback
> > > > >>>>>> to direct access. + * Usefull for dynamic or model
> > > > >>>>>> specific firmware data. + **/
> > > > >>>>>> +int request_firmware_prefer_user(const struct
> > > > >>>>>> firmware **firmware_p, +
> > > > >>>>>> const char *name, struct device *device) +{
> > > > >>>>>> + int ret;
> > > > >>>>>> + __module_get(THIS_MODULE);
> > > > >>>>>> + ret = _request_firmware(firmware_p, name,
> > > > >>>>>> device, +
> > > > >>>>>> FW_OPT_UEVENT
> > > > >>>>>>
> > > > >>>>>> | FW_OPT_PREFER_USER); +
> > > > >>>>>>
> > > > >>>>>> module_put(THIS_MODULE); + return ret;
> > > > >>>>>> +}
> > > > >>>>>> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> > > > >>>>>
> > > > >>>>> I'd like to introduce request_firmware_user() which
> > > > >>>>> only requests firmware from user space, and this
> > > > >>>>> way is simpler and more flexible since we have
> > > > >>>>> request_firmware_direct() already.
> > > > >>>>
> > > > >>>> Why would a driver care about what program provides
> > > > >>>> the firmware? It shouldn't at all, and we want to
> > > > >>>> get rid of the userspace firmware loader, not
> > > > >>>> encourage drivers to use it "exclusively" at all.
> > > > >>>
> > > > >>> Do not remove it! Without userspace firmware loader it
> > > > >>> is impossible to load dynamic firmware files.
> > > > >>
> > > > >> why is this dynamic in the first place. It does not
> > > > >> sound like dynamic data to me at all. This is like the
> > > > >> WiFi MAC address(es) or Bluetooth BD_ADDR. They are
> > > > >> all static information. The only difference is that
> > > > >> they are on the host accessibly filesystem or storage
> > > > >> and not on the device itself.
> > > > >>
> > > > >> To be honest, for Bluetooth we solved this now. If the
> > > > >> device is missing key information like the calibration
> > > > >> data or BD_ADDR, then it comes up unconfigured. A
> > > > >> userspace process can then go and load the right data
> > > > >> into it and then the device becomes available as
> > > > >> Bluetooth device.
> > > > >>
> > > > >> Trying to use request_firmware to load some random data
> > > > >> and insist on going through userspace helper for that
> > > > >> sounds crazy to me. Especially since we are trying
> > > > >> hard to get away from the userspace loader. Forcing to
> > > > >> keep it for new stuff sounds backwards to me.
> > > > >>
> > > > >> With the special Nokia partition in mind, why hasn't
> > > > >> this been turned into a mountable filesystem or into a
> > > > >> driver/subsystem that can access the data direct from
> > > > >> the kernel. I advocated for this some time ago. Maybe
> > > > >> there should be a special subsystem for access to
> > > > >> these factory persistent information that drivers then
> > > > >> just can access. I seem to remember that some systems
> > > > >> provide these via ACPI. Why does the ARM platform has
> > > > >> to be special here?
> > > > >>
> > > > >> And the problem of getting Ethernet and WiFi MAC
> > > > >> address and Bluetooth BD_ADDR comes up many many
> > > > >> times. Why not have something generic here. And don't
> > > > >> tell me request_firmware is that generic solution ;)
> > > > >>
> > > > >> Regards
> > > > >>
> > > > >> Marcel
> > > > >
> > > > > Hi Marcel. I think you did not understand this problem.
> > > > > This discussion is not about mac address. Please read
> > > > > email thread again and if there are some unclear pars,
> > > > > then ask. Thanks!
> > > >
> > > > I think that I pretty clearly understand the problem.
> > > > Calibration data, MAC address, what is the difference? For
> > > > me this is all the same. It is data that is specific to a
> > > > device or type of devices and it is stored somewhere
> > > > else. In most cases in some immutable memory/flash area.
> > >
> > > Those calibration data (in form of binary NVS firmware file)
> > > needs to be sent to wl1251 chip. Mac address is not needed
> > > at this step (and kernel generate some random if is not
> > > provided).
> > >
> > > (Just to note wl1271 driver loads both MAC address and NVS
> > > data via one firmware file which is prepared by userspace,
> > > but this discussion is about wl1251...)
> > >
> > > > What you want is access to this data since the kernel
> > > > driver needs it. Do I get this so far ;)
> > >
> > > Yes, we need to provide NVS data to kernel when kernel ask
> > > for them.
> > >
> > > > So my take is that request_firmware is not the right way
> > > > to get this data. Or more precisely make sure that this
> > > > data is available to kernel drivers. And what I am seeing
> > > > here is that instead of actually solving the bigger
> > > > problem, we just hack around it with request_firmware.
> > > > Now surprisingly the request_firmware loads files
> > > > directly from the kernel and all the hacks do not work
> > > > anymore.
> > > >
> > > > Regards
> > > >
> > > > Marcel
> > >
> > > Just read emails again...
> > >
> > > Our problem is:
> > >
> > > linux-firmware.git tree provides two binary firmware files:
> > >
> > > ti-connectivity/wl1251-fw.bin
> > > ti-connectivity/wl1251-nvs.bin
> > >
> > > First is firmware file, second NVS file with generic
> > > calibration data. Kernel driver wl1251 now loads both
> > > firmware files via request_firmware. Generic calibration
> > > data are enough for wl1251 chip (it should work). But
> > > devices have own calibration data stored somewhere else.
> > >
> > > On Nokia N900 NVS data are generated on-the-fly from some
> > > bytes from CAL (/dev/mtd1), from state of cellular network
> > > and from some other regulation settings.
> > >
> > > So I think that files stored in linux-firmware.git tree
> > > (which are also installed into /lib/firmware/) should be
> > > loaded with request_firmware function. Or not? Do you think
> > > something else? What other developers think?
> > >
> > > I'm against kernel driver for CAL (/dev/mtd1) for more
> > > reasons:
> > >
> > > 1) we have userspace open source code, but licensed under
> > > GPLv3. And until kernel change license, we cannot include
> > > it.
> > >
> > > 2) NVS data are (probably) not in one place, plus they
> > > depends on something other.
> > >
> > > 3) If manufacture XYZ create new device with its own storage
> > > format of calibration data this means that correct solution
> > > for XYZ is also to implement new kernel fs driver for its
> > > own format. Do you really want to have in kernel all those
> > > drivers for all different (proprietary) storage formats?
> > >
> > > 4) It does not help us with existence of generic file
> > > /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
> > > from linux-firmware.git tree.
> >
> > a) change driver to prefer a new "wl1251-nvs-n900.bin" file,
>
> Why to "*-n900.bin" ? wl1251 driver is used on other devices too.
Is the CAL data format generic to all wl1251 devices? Or is the stuff
in the CAL partition Nokia-specific?
> > but fall back to "wl1251-nvs.bin" if the first one isn't
> > present
>
> > b) have a "wl1251-cal-nvs-update" service that, if
> > wl1521-nvs-n900.bin is *not* present mounts the CAL MTD,
> > reads the data, writes it out into wl1521-nvs-n900.bin, and
> > the rmmod/modprobes the driver
> >
>
> Quote:
> > On Nokia N900 NVS data are generated on-the-fly from some bytes
> > from CAL (/dev/mtd1), from state of cellular network and from
> > some other regulation settings.
>
> This basically means to rewrite it every boot or everytime when
> country was changed (for regulation settings). And Ii really do
> not want to do that.
I'm not sure why it would be set every boot, if it already existed?
Isn't the CAL data just the default regulatory domain? Whatever
*changes* the CAL data would clearly need to invalidate the
existing .bin file too. But...
You have to re-send regulatory information to the chip anyway, whenever
cfg80211 changes the regulatory domain of the device. (iw reg set
Poland)
You have to re-send the regulatory information to the chip anyway,
whenever the user registers with an operator. (eg, MCC/MNC is now a
Polish operator).
In either case, you need to adjust the regulatory domain of the device
on-the-fly.
You also need to set the default regulatory domain at bootup, from the
CAL data, just in case the phone is in airplane mode and no MCC/MNC is
available.
The mechanism for each should be the same, through the normal
mac80211/cfg80211 hooks to set the regulatory domain.
> And rmmod is not working on statically linked drivers into
> zImage. So this is not solution.
>
> > and done? Stuff that's not N900 just wouldn't ship the update
> > service and would proceed like none of this happened.
> >
> > Dan
>
> Again, what is wrong with userspace firmware helper? I think that
> it fix this problem in a clean way without any hacks (like CAL in
> kernel or creating new FS specially for parsing NVS and so on) in
> kernel. And in userspace we can implement program which generate
> NVS firmware data on-the-fly and send them to kernel in
> compatible format of ti-connectivity/wl1251-nvs.bin
Because that has other issues as Greg describes. What's wrong with a
*udev* helper that pushes the information down to the chip after the MTD
partition is mounted? Why does it have to a firmware helper?
Also, changing the regulatory information based on MCC/MNC implies that
you have to get the different regulatory information from somewhere.
Where is that information stored? Also in the CAL partition? Or
somewhere else? How big is all that information?
Dan
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] remove bridge mode BRIDGE_MODE_SWDEV
From: Roopa Prabhu @ 2014-12-08 23:00 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <CAE4R7bBUDQztn-Pk-xRxVJbGbnjE2_CnyDn3-k3PWPUu7mFJsw@mail.gmail.com>
On 12/8/14, 2:49 PM, Scott Feldman wrote:
> Roopa, thanks for fixing this. I'm a little lost on status of the
> iproute2 patches related to this change and earlier changes. Would
> you and Jiri respin one set of iproute2 patches that gets us the final
> answer? It was getting a little messy with patches on top of
> yet-to-be-accepted patches. Thanks.
scott, the iproute2 v3 patch was the last (hopefully final) patch and
jiri and you signed-off on that
Its here:
http://patchwork.ozlabs.org/patch/418350/
Thanks for the review.
>
> On Mon, Dec 8, 2014 at 2:04 PM, <roopa@cumulusnetworks.com> wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> BRIDGE_MODE_SWDEV was introduced to indicate switchdev offloads
>> for bridging from user space (In other words to call into the hw switch
>> port driver directly). But user can use existing BRIDGE_FLAGS_SELF
>> to call into the hw switch port driver today. swdev mode is not required
>> anymore. So, this patch removes it.
>>
>> v4 - v5
>> incorporate comments
>> - Define BRIDGE_MODE_UNDEF to handle cases where mode is not defined
>> - reverse the order of patches
>> - include patch comments in all patches
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Roopa Prabhu (3):
>> bridge: new mode flag to indicate mode 'undefined'
>> rocker: remove swdev mode
>> bridge: remove mode 'swdev'
>>
>> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
>> include/uapi/linux/if_bridge.h | 2 +-
>> net/core/rtnetlink.c | 10 ++++++++--
>> 3 files changed, 10 insertions(+), 20 deletions(-)
>>
>> --
>> 1.7.10.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 23:23 UTC (permalink / raw)
To: Dan Williams
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <1418079067.31640.13.camel@dcbw.local>
[-- Attachment #1: Type: Text/Plain, Size: 248 bytes --]
On Monday 08 December 2014 23:51:07 Dan Williams wrote:
> Is the CAL data format generic to all wl1251 devices? Or is
> the stuff in the CAL partition Nokia-specific?
>
Specific for Nokia devices.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 23:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ming Lei, Pavel Machek, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141208205721.GA14895@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 544 bytes --]
On Monday 08 December 2014 21:57:21 Greg Kroah-Hartman wrote:
> Use your own custom usermode helper for stuff like this, not
> the firmware interface. But use a binary sysfs file if you
> want, that seems to make sense for it...
>
> greg k-h
Patch for telling permanent mac address from userspace via sysfs
file was rejected for inclusion into mainline kernel.
So I do not think that now maintainers of network subsystem allow
it for nvs data...
https://lkml.org/lkml/2013/12/8/35
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Dan Williams @ 2014-12-08 23:42 UTC (permalink / raw)
To: Pali Rohár
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412090023.18173@pali>
On Tue, 2014-12-09 at 00:23 +0100, Pali Rohár wrote:
> On Monday 08 December 2014 23:51:07 Dan Williams wrote:
> > Is the CAL data format generic to all wl1251 devices? Or is
> > the stuff in the CAL partition Nokia-specific?
> >
>
> Specific for Nokia devices.
Ok, but then something must transform that data into a format that the
wl1251 chip can consume, correct? What do other wl1251 platforms do to
retrieve this information and set regulatory region?
Dan
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 23:52 UTC (permalink / raw)
To: Dan Williams
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <1418082137.31640.14.camel@dcbw.local>
[-- Attachment #1: Type: Text/Plain, Size: 973 bytes --]
On Tuesday 09 December 2014 00:42:17 Dan Williams wrote:
> On Tue, 2014-12-09 at 00:23 +0100, Pali Rohár wrote:
> > On Monday 08 December 2014 23:51:07 Dan Williams wrote:
> > > Is the CAL data format generic to all wl1251 devices? Or
> > > is the stuff in the CAL partition Nokia-specific?
> >
> > Specific for Nokia devices.
>
> Ok, but then something must transform that data into a format
> that the wl1251 chip can consume, correct? What do other
> wl1251 platforms do to retrieve this information and set
> regulatory region?
>
> Dan
It looks like wl1251 driver supports standard way to set
regulatory settings. There is application which reads CAL data,
cellular network info, ... and sent it to kernel (via Nokia
specific netlink interface patch). And binary data which are sent
are in same format as file wl1251-nvs.bin. And some bits which
deterministically send to kernl depends on fcc.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH net-next] net: systemport: allow changing MAC address
From: Florian Fainelli @ 2014-12-08 23:59 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Hook a ndo_set_mac_address callback, update the internal Ethernet MAC in
the netdevice structure, and finally write that address down to the
UniMAC registers. If the interface is down, and most likely clock gated,
we do not update the registers but just the local copy, such that next
ndo_open() call will effectively write down the address.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index c1d255972dae..a91a8c263391 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1409,6 +1409,27 @@ static void topctrl_flush(struct bcm_sysport_priv *priv)
topctrl_writel(priv, 0, TX_FLUSH_CNTL);
}
+static int bcm_sysport_change_mac(struct net_device *dev, void *p)
+{
+ struct bcm_sysport_priv *priv = netdev_priv(dev);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EINVAL;
+
+ memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+
+ /* interface is disabled, changes to MAC will be reflected on next
+ * open call
+ */
+ if (!netif_running(dev))
+ return 0;
+
+ umac_set_hw_addr(priv, dev->dev_addr);
+
+ return 0;
+}
+
static void bcm_sysport_netif_start(struct net_device *dev)
{
struct bcm_sysport_priv *priv = netdev_priv(dev);
@@ -1628,6 +1649,7 @@ static const struct net_device_ops bcm_sysport_netdev_ops = {
.ndo_stop = bcm_sysport_stop,
.ndo_set_features = bcm_sysport_set_features,
.ndo_set_rx_mode = bcm_sysport_set_rx_mode,
+ .ndo_set_mac_address = bcm_sysport_change_mac,
};
#define REV_FMT "v%2x.%02x"
--
2.1.0
^ permalink raw reply related
* Nothing is better than you!
From: Jessica Kuku @ 2014-12-08 18:00 UTC (permalink / raw)
Hi Dear,
May peace be with you. I am Miss Jessica. Actually, We may not known in person but relationship can start like this!. Please, I'm sorry if I am embarrassing you by my gesture.
I really wish to be your friend, learn to know you and to have a place in your heart for an ideal relationship with us. I will be very happy if you contact me for my picture and more about me.
See you soon?
Thanks in advance and remain blessed!
Jessica
^ permalink raw reply
* Re: is the commit 571dcfde2371 (net-next) a proper fix?
From: David Miller @ 2014-12-09 0:35 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: chenhc, peppe.cavallaro, netdev
In-Reply-To: <1418034200.17201.45.camel@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 08 Dec 2014 12:23:20 +0200
> It seems for me that commit 571dcfde2371 (stmmac: platform: fix default
> values of the filter bins setting) is redundant (moreover, it could be a
> cause of crash in some cases when there is no platform data defined in
> case of CONFIG_OF).
>
> In case of no OF the platform data should be provided by platform code
> where the defaults are set. What did I miss?
You missed follow-up fix:
commit 28603d13997e2ef47f18589cc9a44553aad49c86
Author: Huacai Chen <chenhc@lemote.com>
Date: Thu Nov 27 21:05:34 2014 +0800
stmmac: platform: Move plat_dat checking earlier
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-12-09 0:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pali Rohár, Pavel Machek, John W. Linville,
Grazvydas Ignotas,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141208205721.GA14895-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Tue, Dec 9, 2014 at 4:57 AM, Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Mon, Dec 08, 2014 at 05:47:30PM +0100, Pali Rohár wrote:
>> On Monday 08 December 2014 17:37:14 Greg Kroah-Hartman wrote:
>> > On Mon, Dec 08, 2014 at 11:18:18PM +0800, Ming Lei wrote:
>> > > On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
>> <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > > > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>> > > > /**
>> > > >
>> > > > + * request_firmware_prefer_user: - prefer usermode helper
>> > > > for loading firmware + * @firmware_p: pointer to firmware
>> > > > image
>> > > > + * @name: name of firmware file
>> > > > + * @device: device for which firmware is being loaded
>> > > > + *
>> > > > + * This function works pretty much like
>> > > > request_firmware(), but it prefer + * usermode helper. If
>> > > > usermode helper fails then it fallback to direct access.
>> > > > + * Usefull for dynamic or model specific firmware data.
>> > > > + **/
>> > > > +int request_firmware_prefer_user(const struct firmware
>> > > > **firmware_p, + const char
>> > > > *name, struct device *device) +{
>> > > > + int ret;
>> > > > + __module_get(THIS_MODULE);
>> > > > + ret = _request_firmware(firmware_p, name, device,
>> > > > + FW_OPT_UEVENT |
>> > > > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
>> > > > + return ret;
>> > > > +}
>> > > > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>> > >
>> > > I'd like to introduce request_firmware_user() which only
>> > > requests firmware from user space, and this way is simpler
>> > > and more flexible since we have request_firmware_direct()
>> > > already.
>> >
>> > Why would a driver care about what program provides the
>> > firmware? It shouldn't at all, and we want to get rid of the
>> > userspace firmware loader, not encourage drivers to use it
>> > "exclusively" at all.
>> >
>>
>> Do not remove it! Without userspace firmware loader it is
>> impossible to load dynamic firmware files.
>
> You should not be loading "dynamic" firmware files with the firmware
> interface, as that's not a "firmware" file anymore, it's a "special
> binary file that my driver needs to be created and sent into the
> kernel."
It is reasonable to put firmware somewhere instead of default
search path, maybe in network.
>
> Use your own custom usermode helper for stuff like this, not the
> firmware interface. But use a binary sysfs file if you want, that seems
> to make sense for it...
It sounds like implementing an variant of request_firmware_user(), :-)
Thanks,
Ming Lei
--
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 v2] ipvs: uninitialized data with IP_VS_IPV6
From: Simon Horman @ 2014-12-09 0:52 UTC (permalink / raw)
To: Julian Anastasov
Cc: Dan Carpenter, Wensong Zhang, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netdev, lvs-devel,
netfilter-devel, coreteam, kernel-janitors
In-Reply-To: <alpine.LFD.2.11.1412072032420.1885@ja.home.ssi.bg>
On Sun, Dec 07, 2014 at 08:39:35PM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Sat, 6 Dec 2014, Dan Carpenter wrote:
>
> > The app_tcp_pkt_out() function expects "*diff" to be set and ends up
> > using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.
> >
> > The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
> > for noticing that.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > v2: fix app_tcp_pkt_in() as well. This is an old bug.
>
> Thanks! It will not break seqs for IPv6 control
> connection, only that we do not support FTP yet :( I have
> the doubt whether this should be classified as bugfix :)
> I guess, it is a net-next material, right?
Agreed, I have queued it up in ipvs-next.
I'll send a pull request to Pablo if Dan doesn't object
to it going there.
> Simon, please apply.
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
>
> > diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
> > index 1d5341f..5d3daae 100644
> > --- a/net/netfilter/ipvs/ip_vs_ftp.c
> > +++ b/net/netfilter/ipvs/ip_vs_ftp.c
> > @@ -183,6 +183,8 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > struct nf_conn *ct;
> > struct net *net;
> >
> > + *diff = 0;
> > +
> > #ifdef CONFIG_IP_VS_IPV6
> > /* This application helper doesn't work with IPv6 yet,
> > * so turn this into a no-op for IPv6 packets
> > @@ -191,8 +193,6 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > return 1;
> > #endif
> >
> > - *diff = 0;
> > -
> > /* Only useful for established sessions */
> > if (cp->state != IP_VS_TCP_S_ESTABLISHED)
> > return 1;
> > @@ -322,6 +322,9 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > struct ip_vs_conn *n_cp;
> > struct net *net;
> >
> > + /* no diff required for incoming packets */
> > + *diff = 0;
> > +
> > #ifdef CONFIG_IP_VS_IPV6
> > /* This application helper doesn't work with IPv6 yet,
> > * so turn this into a no-op for IPv6 packets
> > @@ -330,9 +333,6 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
> > return 1;
> > #endif
> >
> > - /* no diff required for incoming packets */
> > - *diff = 0;
> > -
> > /* Only useful for established sessions */
> > if (cp->state != IP_VS_TCP_S_ESTABLISHED)
> > return 1;
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: [PATCH net-next 0/3] timestamping updates
From: David Miller @ 2014-12-09 1:21 UTC (permalink / raw)
To: willemb; +Cc: netdev, luto, richardcochran
In-Reply-To: <1417404155-28607-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Sun, 30 Nov 2014 22:22:32 -0500
> The main goal for this patchset is to allow correlating timestamps
> with the egress interface. Also introduce a warning, as discussed
> previously, and update the tests to verify the new feature.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] mips: bpf: Fix broken BPF_MOD
From: David Miller @ 2014-12-09 1:23 UTC (permalink / raw)
To: kda; +Cc: netdev, markos.chandras
In-Reply-To: <1417427822-12729-1-git-send-email-kda@linux-powerpc.org>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Mon, 1 Dec 2014 12:57:02 +0300
> Remove optimize_div() from BPF_MOD | BPF_K case
> since we don't know the dividend and fix the
> emit_mod() by reading the mod operation result from HI register
>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Applied and queue up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] test: bpf: expand DIV_KX to DIV_MOD_KX
From: David Miller @ 2014-12-09 1:23 UTC (permalink / raw)
To: kda; +Cc: netdev, ast
In-Reply-To: <1417428745-20199-1-git-send-email-kda@linux-powerpc.org>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Mon, 1 Dec 2014 13:12:25 +0300
> Expand DIV_KX to use BPF_MOD operation in the
> DIV_KX bpf 'classic' test.
>
> CC: Alexei Starovoitov <ast@plumgrid.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add support for vNIC hot removal
From: David Miller @ 2014-12-09 1:24 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1417469319-7356-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Mon, 1 Dec 2014 13:28:39 -0800
> This patch adds proper handling of the vNIC hot removal event, which includes
> a rescind-channel-offer message from the host side that triggers vNIC close and
> removal. In this case, the notices to the host during close and removal is not
> necessary because the channel is rescinded. This patch blocks these unnecessary
> messages, and lets vNIC removal process complete normally.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: bcmgenet: enable driver to work without a device tree
From: David Miller @ 2014-12-09 1:27 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli
In-Reply-To: <20141202001808.9B0E6220728@puck.mtv.corp.google.com>
From: Petri Gynther <pgynther@google.com>
Date: Mon, 1 Dec 2014 16:18:08 -0800 (PST)
> Modify bcmgenet driver so that it can be used on Broadcom 7xxx
> MIPS-based STB platforms without a device tree.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH V2 net-next] udp: Neaten and reduce size of compute_score functions
From: David Miller @ 2014-12-09 1:29 UTC (permalink / raw)
To: joe; +Cc: eric.dumazet, netdev, linux-kernel
In-Reply-To: <1417494546.4894.12.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 01 Dec 2014 20:29:06 -0800
> The compute_score functions are a bit difficult to read.
>
> Neaten them a bit to reduce object sizes and make them a
> bit more intelligible.
>
> Return early to avoid indentation and avoid unnecessary
> initializations.
>
> (allyesconfig, but w/ -O2 and no profiling)
>
> $ size net/ipv[46]/udp.o.*
> text data bss dec hex filename
> 28680 1184 25 29889 74c1 net/ipv4/udp.o.new
> 28756 1184 25 29965 750d net/ipv4/udp.o.old
> 17600 1010 2 18612 48b4 net/ipv6/udp.o.new
> 17632 1010 2 18644 48d4 net/ipv6/udp.o.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ 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