* [PATCH RFC] igb: Fix false positive return of igb_get_auto_rd_done for 82580
From: Guenter Roeck @ 2011-06-21 19:02 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don
Cc: e1000-devel, netdev, Tong Ho, Guenter Roeck
From: Tong Ho <tong.ho@ericsson.com>
82580 re-reads the port specific portion of eeprom after port reset.
If called immediately after a reset, igb_get_auto_rd_done() returns
false positive because the done bit has yet to transition from 1 to 0.
Add wrfl() immediately after resetting 82580 port or device,
plus a 1ms delay, to avoid the problem.
Signed-off-by: Tong Ho <tong.ho@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
Sent as RFC since I am not entirely sure if the solution is the correct one
to address the problem we are seeing. If there is a better solution, please
let me know.
drivers/net/igb/e1000_82575.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.c b/drivers/net/igb/e1000_82575.c
index 0f563c8..28dae48 100644
--- a/drivers/net/igb/e1000_82575.c
+++ b/drivers/net/igb/e1000_82575.c
@@ -1735,10 +1735,10 @@ static s32 igb_reset_hw_82580(struct e1000_hw *hw)
ctrl |= E1000_CTRL_RST;
wr32(E1000_CTRL, ctrl);
+ wrfl();
/* Add delay to insure DEV_RST has time to complete */
- if (global_device_reset)
- msleep(5);
+ msleep(global_device_reset ? 5 : 1);
ret_val = igb_get_auto_rd_done(hw);
if (ret_val) {
--
1.7.3.1
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Mitch Bradley @ 2011-06-21 19:04 UTC (permalink / raw)
To: Grant Likely
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jeremy Kerr,
Sascha Hauer
In-Reply-To: <BANLkTiny9xDwiUww9Ys+jQZ0SHdQATABUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 6/21/2011 8:42 AM, Grant Likely wrote:
> On Tue, Jun 21, 2011 at 12:32 PM, Mitch Bradley<wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
>> I wonder if it makes sense to create a new device node "/linux-devices" to express a desired mapping from device nodes to /dev entries? The properties could be the names of device special files and the values the corresponding node phandles.
>
> I've been trying /really/ hard to avoid doing something like that
> because a lot of the time the desired Linux dev name is a
> implementation detail, and a potentially unstable one at that. If
> Linux requires certain devices to have certain names because that is
> how it hooks up clocks (which is the current situation on some
> platforms), then I'd rather have Linux encode a lookup of the
> preferred name, at least until the that particular implementation
> detail goes away.
>
> As for enumerating devices, I don't think this is a Linux-specific
> thing. In this case it is entirely reasonable to want to say /this
> node/ is the second serial port, and /that node/ is the third, which
> is information needed regardless of the client OS.
This reminds me a little of the "slot-names" property defined by the PCI
bus binding. It was intended to correlate PCI device numbers with the
corresponding externally-visible labeling of the slot, so that error
messages could identify a slot using a name that had some meaning to a user.
The notion of "first" and "second" is, of course, rather difficult to
define precisely. What aspect of the device establishes the order?
The "slot-names" property was useful for systems from e.g. Sun, where
one vendor controlled the whole system rollup. It was almost useless
for cases where the one vendor supplied the motherboard and others put
it in various cases.
>
> g.
>
>
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Grant Likely @ 2011-06-21 19:13 UTC (permalink / raw)
To: Shawn Guo
Cc: patches, netdev, devicetree-discuss, Jason Liu, linux-kernel,
Jeremy Kerr, Sascha Hauer, linux-arm-kernel, David Gibson
In-Reply-To: <20110621135558.GB9228@S2101-09.ap.freescale.net>
On Tue, Jun 21, 2011 at 7:55 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> Hi Grant,
>
> I just gave a try to use aliases node for identify the device index.
> Please take a look and let me know if it's what you expect.
Thanks Shawn. This is definitely on track. Comments below...
>
> On Sun, Jun 19, 2011 at 03:30:02PM +0800, Shawn Guo wrote:
> [...]
>> > >
>> > > +#ifdef CONFIG_OF
>> > > +static int serial_imx_probe_dt(struct imx_port *sport,
>> > > + struct platform_device *pdev)
>> > > +{
>> > > + struct device_node *node = pdev->dev.of_node;
>> > > + const __be32 *line;
>> > > +
>> > > + if (!node)
>> > > + return -ENODEV;
>> > > +
>> > > + line = of_get_property(node, "id", NULL);
>> > > + if (!line)
>> > > + return -ENODEV;
>> > > +
>> > > + sport->port.line = be32_to_cpup(line) - 1;
>> >
>> > Hmmm, I really would like to be rid of this. Instead, if uarts must
>> > be enumerated, the driver should look for a /aliases/uart* property
>> > that matches the of_node. Doing it that way is already established in
>> > the OpenFirmware documentation, and it ensures there are no overlaps
>> > in the global namespace.
>> >
>>
>> I just gave one more try to avoid using 'aliases', and you gave a
>> 'no' again. Now, I know how hard you are on this. Okay, I start
>> thinking about your suggestion seriously :)
>>
>> > We do need some infrastructure to make that easier though. Would you
>> > have time to help put that together?
>> >
>> Ok, I will give it a try.
>>
>
> diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
> index da0381a..f4a5c3c 100644
> --- a/arch/arm/boot/dts/imx51-babbage.dts
> +++ b/arch/arm/boot/dts/imx51-babbage.dts
> @@ -18,6 +18,12 @@
> compatible = "fsl,imx51-babbage", "fsl,imx51";
> interrupt-parent = <&tzic>;
>
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + };
> +
Hmmm. David Gibson had tossed out an idea of automatically generating
aliases from labels. It may be time to revisit that idea.
David, perhaps using this format for a label should turn it into an
alias (prefix label with an asterisk):
*thealias: i2c@12340000 { /*...*/ };
.... although that approach gets *really* hairy when considering that
different boards will want different enumeration. How would one
override an automatic alias defined by an included .dts file?
> chosen {
> bootargs = "console=ttymxc0,115200 root=/dev/mmcblk0p3 rootwait";
> };
> @@ -47,29 +53,29 @@
> reg = <0x70000000 0x40000>;
> ranges;
>
> - uart@7000c000 {
> + uart2: uart@7000c000 {
> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
> reg = <0x7000c000 0x4000>;
> interrupts = <33>;
> id = <3>;
> - fsl,has-rts-cts;
> + fsl,uart-has-rtscts;
> };
> };
>
> - uart@73fbc000 {
> + uart0: uart@73fbc000 {
> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
> reg = <0x73fbc000 0x4000>;
> interrupts = <31>;
> id = <1>;
> - fsl,has-rts-cts;
> + fsl,uart-has-rtscts;
> };
>
> - uart@73fc0000 {
> + uart1: uart@73fc0000 {
> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
> reg = <0x73fc0000 0x4000>;
> interrupts = <32>;
> id = <2>;
> - fsl,has-rts-cts;
> + fsl,uart-has-rtscts;
> };
> };
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 632ebae..13df5d2 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -737,6 +737,37 @@ err0:
> EXPORT_SYMBOL(of_parse_phandles_with_args);
>
> /**
> + * of_get_device_index - Get device index by looking up "aliases" node
> + * @np: Pointer to device node that asks for device index
> + * @name: The device alias without index number
> + *
> + * Returns the device index if find it, else returns -ENODEV.
> + */
> +int of_get_device_index(struct device_node *np, const char *alias)
> +{
> + struct device_node *aliases = of_find_node_by_name(NULL, "aliases");
> + struct property *prop;
> + char name[32];
> + int index = 0;
> +
> + if (!aliases)
> + return -ENODEV;
> +
> + while (1) {
> + snprintf(name, sizeof(name), "%s%d", alias, index);
> + prop = of_find_property(aliases, name, NULL);
> + if (!prop)
> + return -ENODEV;
> + if (np == of_find_node_by_path(prop->value))
> + break;
> + index++;
> + }
Rather than parsing the alias strings everytime, it would probably be
better to preprocess all the properties in the aliases node and create
a lookup table of alias->node references that can be walked quickly
and trivially.
Also, when obtaining an enumeration for a device, you'll need to be
careful about what number gets returned. If the node doesn't match a
given alias, but aliases do exist for other devices of like type, then
you need to be careful not to assign a number already assigned to
another device via an alias (this of course assumes the driver
supports dynamics enumeration, which many drivers will). It would be
\> +
> + return index;
> +}
> +EXPORT_SYMBOL(of_get_device_index);
> +
> +/**
> * prom_add_property - Add a property to a node
> */
> int prom_add_property(struct device_node *np, struct property *prop)
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index da436e0..852668f 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1271,18 +1271,18 @@ static int serial_imx_probe_dt(struct imx_port *sport,
> struct device_node *node = pdev->dev.of_node;
> const struct of_device_id *of_id =
> of_match_device(imx_uart_dt_ids, &pdev->dev);
> - const __be32 *line;
> + int line;
>
> if (!node)
> return -ENODEV;
>
> - line = of_get_property(node, "id", NULL);
> - if (!line)
> + line = of_get_device_index(node, "serial");
> + if (IS_ERR_VALUE(line))
> return -ENODEV;
Personally, it an alias isn't present, then I'd dynamically assign a port id.
>
> - sport->port.line = be32_to_cpup(line) - 1;
> + sport->port.line = line;
>
> - if (of_get_property(node, "fsl,has-rts-cts", NULL))
> + if (of_get_property(node, "fsl,uart-has-rtscts", NULL))
> sport->have_rtscts = 1;
>
> if (of_get_property(node, "fsl,irda-mode", NULL))
> diff --git a/include/linux/of.h b/include/linux/of.h
> index bfc0ed1..3153752 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -213,6 +213,8 @@ extern int of_parse_phandles_with_args(struct device_node *np,
> const char *list_name, const char *cells_name, int index,
> struct device_node **out_node, const void **out_args);
>
> +extern int of_get_device_index(struct device_node *np, const char *alias);
> +
> extern int of_machine_is_compatible(const char *compat);
>
> extern int prom_add_property(struct device_node* np, struct property* prop);
>
> --
> Regards,
> Shawn
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Mitch Bradley @ 2011-06-21 19:35 UTC (permalink / raw)
To: Grant Likely
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Jason Liu,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jeremy Kerr,
Sascha Hauer
In-Reply-To: <BANLkTim4vunTm1176MRw3pqRZnunu4=9jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
What is the problem with
aliases{
serial0 = "/uart@7000c000";
}
Properties in the alias node are supposed to have string values.
On 6/21/2011 9:13 AM, Grant Likely wrote:
> On Tue, Jun 21, 2011 at 7:55 AM, Shawn Guo<shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> Hi Grant,
>>
>> I just gave a try to use aliases node for identify the device index.
>> Please take a look and let me know if it's what you expect.
>
> Thanks Shawn. This is definitely on track. Comments below...
>
>>
>> On Sun, Jun 19, 2011 at 03:30:02PM +0800, Shawn Guo wrote:
>> [...]
>>>>>
>>>>> +#ifdef CONFIG_OF
>>>>> +static int serial_imx_probe_dt(struct imx_port *sport,
>>>>> + struct platform_device *pdev)
>>>>> +{
>>>>> + struct device_node *node = pdev->dev.of_node;
>>>>> + const __be32 *line;
>>>>> +
>>>>> + if (!node)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + line = of_get_property(node, "id", NULL);
>>>>> + if (!line)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + sport->port.line = be32_to_cpup(line) - 1;
>>>>
>>>> Hmmm, I really would like to be rid of this. Instead, if uarts must
>>>> be enumerated, the driver should look for a /aliases/uart* property
>>>> that matches the of_node. Doing it that way is already established in
>>>> the OpenFirmware documentation, and it ensures there are no overlaps
>>>> in the global namespace.
>>>>
>>>
>>> I just gave one more try to avoid using 'aliases', and you gave a
>>> 'no' again. Now, I know how hard you are on this. Okay, I start
>>> thinking about your suggestion seriously :)
>>>
>>>> We do need some infrastructure to make that easier though. Would you
>>>> have time to help put that together?
>>>>
>>> Ok, I will give it a try.
>>>
>>
>> diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
>> index da0381a..f4a5c3c 100644
>> --- a/arch/arm/boot/dts/imx51-babbage.dts
>> +++ b/arch/arm/boot/dts/imx51-babbage.dts
>> @@ -18,6 +18,12 @@
>> compatible = "fsl,imx51-babbage", "fsl,imx51";
>> interrupt-parent =<&tzic>;
>>
>> + aliases {
>> + serial0 =&uart0;
>> + serial1 =&uart1;
>> + serial2 =&uart2;
>> + };
>> +
>
> Hmmm. David Gibson had tossed out an idea of automatically generating
> aliases from labels. It may be time to revisit that idea.
>
> David, perhaps using this format for a label should turn it into an
> alias (prefix label with an asterisk):
>
> *thealias: i2c@12340000 { /*...*/ };
>
> .... although that approach gets *really* hairy when considering that
> different boards will want different enumeration. How would one
> override an automatic alias defined by an included .dts file?
>
>> chosen {
>> bootargs = "console=ttymxc0,115200 root=/dev/mmcblk0p3 rootwait";
>> };
>> @@ -47,29 +53,29 @@
>> reg =<0x70000000 0x40000>;
>> ranges;
>>
>> - uart@7000c000 {
>> + uart2: uart@7000c000 {
>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>> reg =<0x7000c000 0x4000>;
>> interrupts =<33>;
>> id =<3>;
>> - fsl,has-rts-cts;
>> + fsl,uart-has-rtscts;
>> };
>> };
>>
>> - uart@73fbc000 {
>> + uart0: uart@73fbc000 {
>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>> reg =<0x73fbc000 0x4000>;
>> interrupts =<31>;
>> id =<1>;
>> - fsl,has-rts-cts;
>> + fsl,uart-has-rtscts;
>> };
>>
>> - uart@73fc0000 {
>> + uart1: uart@73fc0000 {
>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>> reg =<0x73fc0000 0x4000>;
>> interrupts =<32>;
>> id =<2>;
>> - fsl,has-rts-cts;
>> + fsl,uart-has-rtscts;
>> };
>> };
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 632ebae..13df5d2 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -737,6 +737,37 @@ err0:
>> EXPORT_SYMBOL(of_parse_phandles_with_args);
>>
>> /**
>> + * of_get_device_index - Get device index by looking up "aliases" node
>> + * @np: Pointer to device node that asks for device index
>> + * @name: The device alias without index number
>> + *
>> + * Returns the device index if find it, else returns -ENODEV.
>> + */
>> +int of_get_device_index(struct device_node *np, const char *alias)
>> +{
>> + struct device_node *aliases = of_find_node_by_name(NULL, "aliases");
>> + struct property *prop;
>> + char name[32];
>> + int index = 0;
>> +
>> + if (!aliases)
>> + return -ENODEV;
>> +
>> + while (1) {
>> + snprintf(name, sizeof(name), "%s%d", alias, index);
>> + prop = of_find_property(aliases, name, NULL);
>> + if (!prop)
>> + return -ENODEV;
>> + if (np == of_find_node_by_path(prop->value))
>> + break;
>> + index++;
>> + }
>
> Rather than parsing the alias strings everytime, it would probably be
> better to preprocess all the properties in the aliases node and create
> a lookup table of alias->node references that can be walked quickly
> and trivially.
>
> Also, when obtaining an enumeration for a device, you'll need to be
> careful about what number gets returned. If the node doesn't match a
> given alias, but aliases do exist for other devices of like type, then
> you need to be careful not to assign a number already assigned to
> another device via an alias (this of course assumes the driver
> supports dynamics enumeration, which many drivers will). It would be
>
> \> +
>> + return index;
>> +}
>> +EXPORT_SYMBOL(of_get_device_index);
>> +
>> +/**
>> * prom_add_property - Add a property to a node
>> */
>> int prom_add_property(struct device_node *np, struct property *prop)
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index da436e0..852668f 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -1271,18 +1271,18 @@ static int serial_imx_probe_dt(struct imx_port *sport,
>> struct device_node *node = pdev->dev.of_node;
>> const struct of_device_id *of_id =
>> of_match_device(imx_uart_dt_ids,&pdev->dev);
>> - const __be32 *line;
>> + int line;
>>
>> if (!node)
>> return -ENODEV;
>>
>> - line = of_get_property(node, "id", NULL);
>> - if (!line)
>> + line = of_get_device_index(node, "serial");
>> + if (IS_ERR_VALUE(line))
>> return -ENODEV;
>
> Personally, it an alias isn't present, then I'd dynamically assign a port id.
>
>>
>> - sport->port.line = be32_to_cpup(line) - 1;
>> + sport->port.line = line;
>>
>> - if (of_get_property(node, "fsl,has-rts-cts", NULL))
>> + if (of_get_property(node, "fsl,uart-has-rtscts", NULL))
>> sport->have_rtscts = 1;
>>
>> if (of_get_property(node, "fsl,irda-mode", NULL))
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index bfc0ed1..3153752 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -213,6 +213,8 @@ extern int of_parse_phandles_with_args(struct device_node *np,
>> const char *list_name, const char *cells_name, int index,
>> struct device_node **out_node, const void **out_args);
>>
>> +extern int of_get_device_index(struct device_node *np, const char *alias);
>> +
>> extern int of_machine_is_compatible(const char *compat);
>>
>> extern int prom_add_property(struct device_node* np, struct property* prop);
>>
>> --
>> Regards,
>> Shawn
>>
>>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/3] serial/imx: add device tree support
From: Grant Likely @ 2011-06-21 19:38 UTC (permalink / raw)
To: Mitch Bradley
Cc: patches, netdev, devicetree-discuss, Jason Liu, linux-kernel,
linux-arm-kernel, Jeremy Kerr, Sascha Hauer, Shawn Guo
In-Reply-To: <4E00F290.2010303@firmworks.com>
On Tue, Jun 21, 2011 at 1:35 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> What is the problem with
>
> aliases{
> serial0 = "/uart@7000c000";
> }
>
> Properties in the alias node are supposed to have string values.
?
Not sure I follow. Indeed, properties in the aliases node are string values.
Are you referring to how I was proposing some dtc syntax for
generating the alias strings?
g.
>
>
> On 6/21/2011 9:13 AM, Grant Likely wrote:
>>
>> On Tue, Jun 21, 2011 at 7:55 AM, Shawn Guo<shawn.guo@freescale.com>
>> wrote:
>>>
>>> Hi Grant,
>>>
>>> I just gave a try to use aliases node for identify the device index.
>>> Please take a look and let me know if it's what you expect.
>>
>> Thanks Shawn. This is definitely on track. Comments below...
>>
>>>
>>> On Sun, Jun 19, 2011 at 03:30:02PM +0800, Shawn Guo wrote:
>>> [...]
>>>>>>
>>>>>> +#ifdef CONFIG_OF
>>>>>> +static int serial_imx_probe_dt(struct imx_port *sport,
>>>>>> + struct platform_device *pdev)
>>>>>> +{
>>>>>> + struct device_node *node = pdev->dev.of_node;
>>>>>> + const __be32 *line;
>>>>>> +
>>>>>> + if (!node)
>>>>>> + return -ENODEV;
>>>>>> +
>>>>>> + line = of_get_property(node, "id", NULL);
>>>>>> + if (!line)
>>>>>> + return -ENODEV;
>>>>>> +
>>>>>> + sport->port.line = be32_to_cpup(line) - 1;
>>>>>
>>>>> Hmmm, I really would like to be rid of this. Instead, if uarts must
>>>>> be enumerated, the driver should look for a /aliases/uart* property
>>>>> that matches the of_node. Doing it that way is already established in
>>>>> the OpenFirmware documentation, and it ensures there are no overlaps
>>>>> in the global namespace.
>>>>>
>>>>
>>>> I just gave one more try to avoid using 'aliases', and you gave a
>>>> 'no' again. Now, I know how hard you are on this. Okay, I start
>>>> thinking about your suggestion seriously :)
>>>>
>>>>> We do need some infrastructure to make that easier though. Would you
>>>>> have time to help put that together?
>>>>>
>>>> Ok, I will give it a try.
>>>>
>>>
>>> diff --git a/arch/arm/boot/dts/imx51-babbage.dts
>>> b/arch/arm/boot/dts/imx51-babbage.dts
>>> index da0381a..f4a5c3c 100644
>>> --- a/arch/arm/boot/dts/imx51-babbage.dts
>>> +++ b/arch/arm/boot/dts/imx51-babbage.dts
>>> @@ -18,6 +18,12 @@
>>> compatible = "fsl,imx51-babbage", "fsl,imx51";
>>> interrupt-parent =<&tzic>;
>>>
>>> + aliases {
>>> + serial0 =&uart0;
>>> + serial1 =&uart1;
>>> + serial2 =&uart2;
>>> + };
>>> +
>>
>> Hmmm. David Gibson had tossed out an idea of automatically generating
>> aliases from labels. It may be time to revisit that idea.
>>
>> David, perhaps using this format for a label should turn it into an
>> alias (prefix label with an asterisk):
>>
>> *thealias: i2c@12340000 { /*...*/ };
>>
>> .... although that approach gets *really* hairy when considering that
>> different boards will want different enumeration. How would one
>> override an automatic alias defined by an included .dts file?
>>
>>> chosen {
>>> bootargs = "console=ttymxc0,115200 root=/dev/mmcblk0p3
>>> rootwait";
>>> };
>>> @@ -47,29 +53,29 @@
>>> reg =<0x70000000 0x40000>;
>>> ranges;
>>>
>>> - uart@7000c000 {
>>> + uart2: uart@7000c000 {
>>> compatible = "fsl,imx51-uart",
>>> "fsl,imx21-uart";
>>> reg =<0x7000c000 0x4000>;
>>> interrupts =<33>;
>>> id =<3>;
>>> - fsl,has-rts-cts;
>>> + fsl,uart-has-rtscts;
>>> };
>>> };
>>>
>>> - uart@73fbc000 {
>>> + uart0: uart@73fbc000 {
>>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>>> reg =<0x73fbc000 0x4000>;
>>> interrupts =<31>;
>>> id =<1>;
>>> - fsl,has-rts-cts;
>>> + fsl,uart-has-rtscts;
>>> };
>>>
>>> - uart@73fc0000 {
>>> + uart1: uart@73fc0000 {
>>> compatible = "fsl,imx51-uart", "fsl,imx21-uart";
>>> reg =<0x73fc0000 0x4000>;
>>> interrupts =<32>;
>>> id =<2>;
>>> - fsl,has-rts-cts;
>>> + fsl,uart-has-rtscts;
>>> };
>>> };
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index 632ebae..13df5d2 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -737,6 +737,37 @@ err0:
>>> EXPORT_SYMBOL(of_parse_phandles_with_args);
>>>
>>> /**
>>> + * of_get_device_index - Get device index by looking up "aliases"
>>> node
>>> + * @np: Pointer to device node that asks for device index
>>> + * @name: The device alias without index number
>>> + *
>>> + * Returns the device index if find it, else returns -ENODEV.
>>> + */
>>> +int of_get_device_index(struct device_node *np, const char *alias)
>>> +{
>>> + struct device_node *aliases = of_find_node_by_name(NULL,
>>> "aliases");
>>> + struct property *prop;
>>> + char name[32];
>>> + int index = 0;
>>> +
>>> + if (!aliases)
>>> + return -ENODEV;
>>> +
>>> + while (1) {
>>> + snprintf(name, sizeof(name), "%s%d", alias, index);
>>> + prop = of_find_property(aliases, name, NULL);
>>> + if (!prop)
>>> + return -ENODEV;
>>> + if (np == of_find_node_by_path(prop->value))
>>> + break;
>>> + index++;
>>> + }
>>
>> Rather than parsing the alias strings everytime, it would probably be
>> better to preprocess all the properties in the aliases node and create
>> a lookup table of alias->node references that can be walked quickly
>> and trivially.
>>
>> Also, when obtaining an enumeration for a device, you'll need to be
>> careful about what number gets returned. If the node doesn't match a
>> given alias, but aliases do exist for other devices of like type, then
>> you need to be careful not to assign a number already assigned to
>> another device via an alias (this of course assumes the driver
>> supports dynamics enumeration, which many drivers will). It would be
>>
>> \> +
>>>
>>> + return index;
>>> +}
>>> +EXPORT_SYMBOL(of_get_device_index);
>>> +
>>> +/**
>>> * prom_add_property - Add a property to a node
>>> */
>>> int prom_add_property(struct device_node *np, struct property *prop)
>>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>>> index da436e0..852668f 100644
>>> --- a/drivers/tty/serial/imx.c
>>> +++ b/drivers/tty/serial/imx.c
>>> @@ -1271,18 +1271,18 @@ static int serial_imx_probe_dt(struct imx_port
>>> *sport,
>>> struct device_node *node = pdev->dev.of_node;
>>> const struct of_device_id *of_id =
>>> of_match_device(imx_uart_dt_ids,&pdev->dev);
>>> - const __be32 *line;
>>> + int line;
>>>
>>> if (!node)
>>> return -ENODEV;
>>>
>>> - line = of_get_property(node, "id", NULL);
>>> - if (!line)
>>> + line = of_get_device_index(node, "serial");
>>> + if (IS_ERR_VALUE(line))
>>> return -ENODEV;
>>
>> Personally, it an alias isn't present, then I'd dynamically assign a port
>> id.
>>
>>>
>>> - sport->port.line = be32_to_cpup(line) - 1;
>>> + sport->port.line = line;
>>>
>>> - if (of_get_property(node, "fsl,has-rts-cts", NULL))
>>> + if (of_get_property(node, "fsl,uart-has-rtscts", NULL))
>>> sport->have_rtscts = 1;
>>>
>>> if (of_get_property(node, "fsl,irda-mode", NULL))
>>> diff --git a/include/linux/of.h b/include/linux/of.h
>>> index bfc0ed1..3153752 100644
>>> --- a/include/linux/of.h
>>> +++ b/include/linux/of.h
>>> @@ -213,6 +213,8 @@ extern int of_parse_phandles_with_args(struct
>>> device_node *np,
>>> const char *list_name, const char *cells_name, int index,
>>> struct device_node **out_node, const void **out_args);
>>>
>>> +extern int of_get_device_index(struct device_node *np, const char
>>> *alias);
>>> +
>>> extern int of_machine_is_compatible(const char *compat);
>>>
>>> extern int prom_add_property(struct device_node* np, struct property*
>>> prop);
>>>
>>> --
>>> Regards,
>>> Shawn
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] irda: fix smsc-ircc2 section mismatch warning
From: Randy Dunlap @ 2011-06-21 19:39 UTC (permalink / raw)
To: netdev; +Cc: irda-users, Samuel Ortiz
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix section mismatch warning:
WARNING: drivers/net/irda/smsc-ircc2.o(.devinit.text+0x1a7): Section mismatch in reference from the function smsc_ircc_pnp_probe() to the function .init.text:smsc_ircc_open()
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/irda/smsc-ircc2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-30-rc4.orig/drivers/net/irda/smsc-ircc2.c
+++ lnx-30-rc4/drivers/net/irda/smsc-ircc2.c
@@ -515,7 +515,7 @@ static const struct net_device_ops smsc_
* Try to open driver instance
*
*/
-static int __init smsc_ircc_open(unsigned int fir_base, unsigned int sir_base, u8 dma, u8 irq)
+static int __devinit smsc_ircc_open(unsigned int fir_base, unsigned int sir_base, u8 dma, u8 irq)
{
struct smsc_ircc_cb *self;
struct net_device *dev;
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Randy Dunlap @ 2011-06-21 20:09 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <20110621130040.12035.62533.sendpatchset@prarit.bos.redhat.com>
On Tue, 21 Jun 2011 09:00:40 -0400 Prarit Bhargava wrote:
> Add Network Sysrq Support
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>
> diff --git a/Documentation/networking/sysrq-ping.txt b/Documentation/networking/sysrq-ping.txt
> new file mode 100644
> index 0000000..efa8be3
> --- /dev/null
> +++ b/Documentation/networking/sysrq-ping.txt
> @@ -0,0 +1,26 @@
> +In some circumstances, a system can hang/lockup in such a way that the system
> +is completely unresponsive to keyboard or console input but is still
> +responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> +net/ipv4/sysrq-ping.ko which allows a root user to configure the system for a
or it can be built-in the kernel image... (i.e., not a loadable module)
> +remote sysrq.
> +
> +To use this do:
> +
> +mount -t debugfs none /sys/kernel/debug/
> +echo 1 > /proc/sys/kernel/sysrq
> +echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> +echo 1 > /sys/kernel/debug/network_sysrq_enable
so all of this (insecure) stuff has to be done before you suspect that
you need it .. in case the local keyboard/console is dead.
> +
> +Then on another system you can do:
> +
> +ping -c 1 -p <hex digit val><hex val of sysrq> <target_system_name>
What are the <up to 30 hex digits> for?
> +
> +ex) sysrq-m, m is ascii 0x6d
e.g., sysrq-m (m is ASCII 0x6d)
> +
> + ping -c 1 p 1623a06f554d46d676d <target_system_name>
> +
> +Note that the network sysrq automatically disables after the receipt of
> +the ping, ie) it is single-shot mode. If you want to use this again, you
i.e., it is single-shot mode.
> +must complete the above four steps again.
> +
> +Hint: 'man ascii' ;)
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index cbb505b..03bb7b1 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,11 @@ config TCP_MD5SIG
> on the Internet.
>
> If unsure, say N.
> +
> +config SYSRQ_PING
> + tristate
Needs a prompt?
> + default m
Please do not enable random code to be built.
> + help
> + Allows execution of sysrq-X commands via ping over ipv4. This is a
No ipv6 support? future?
> + known security hazard and should not be used in unsecure
insecure
> + environments.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Reported regression against commit a05d2ad
From: Herton Ronaldo Krzesinski @ 2011-06-21 20:15 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: lamont, sconklin, tim.gardner, netdev
Hi,
after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
got a regression report about timeout in tcp connections
(https://launchpad.net/bugs/791512).
We tried help reporter with a bisect process, but it was taking some
time, so we reverted some suspect commits, until we isolated it to
commit "af_unix: Only allow recv on connected seqpacket sockets."
With only commit a05d2ad reverted, testing results so far indicate the
issue doesn't happen.
I'm unfamiliar with unix sockets code, so can't see at first why this
commit in particular is causing problems, for now I can only say may be
something at application level using unix sockets regressed with it (?).
I'm just reporting it right now, and we plan to revert it for that kernel
until more info is found about it.
I'm adding reporter to CC (Lamont), in case more details are necessary
etc.
--
[]'s
Herton
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Florian Westphal @ 2011-06-21 20:37 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Prarit Bhargava, netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <20110621130929.ddd107f7.rdunlap@xenotime.net>
Randy Dunlap <rdunlap@xenotime.net> wrote:
> > diff --git a/Documentation/networking/sysrq-ping.txt b/Documentation/networking/sysrq-ping.txt
> > new file mode 100644
> > index 0000000..efa8be3
> > --- /dev/null
> > +++ b/Documentation/networking/sysrq-ping.txt
> > @@ -0,0 +1,26 @@
> > +In some circumstances, a system can hang/lockup in such a way that the system
> > +is completely unresponsive to keyboard or console input but is still
> > +responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> > +net/ipv4/sysrq-ping.ko which allows a root user to configure the system for a
>
> or it can be built-in the kernel image... (i.e., not a loadable module)
>
> > +remote sysrq.
> > +
> > +To use this do:
> > +
> > +mount -t debugfs none /sys/kernel/debug/
> > +echo 1 > /proc/sys/kernel/sysrq
> > +echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> > +echo 1 > /sys/kernel/debug/network_sysrq_enable
>
> so all of this (insecure) stuff has to be done before you suspect that
> you need it .. in case the local keyboard/console is dead.
There is an xt_SYSREQ module in xtables-addons package (i.e., a
netfilter target), it supports hashed passwords and has some sequence
number scheme to avoid replays.
I think it would make more sense to merge that upstream, simply because
it seems to be a bit more advanced...
^ permalink raw reply
* Re: Reported regression against commit a05d2ad
From: Tim Gardner @ 2011-06-21 20:38 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: Eric W. Biederman, lamont, sconklin, netdev
In-Reply-To: <20110621201528.GB2249@herton-IdeaPad-Y430>
On 06/21/2011 02:15 PM, Herton Ronaldo Krzesinski wrote:
> Hi,
>
> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
> got a regression report about timeout in tcp connections
> (https://launchpad.net/bugs/791512).
>
> We tried help reporter with a bisect process, but it was taking some
> time, so we reverted some suspect commits, until we isolated it to
> commit "af_unix: Only allow recv on connected seqpacket sockets."
>
> With only commit a05d2ad reverted, testing results so far indicate the
> issue doesn't happen.
>
> I'm unfamiliar with unix sockets code, so can't see at first why this
> commit in particular is causing problems, for now I can only say may be
> something at application level using unix sockets regressed with it (?).
> I'm just reporting it right now, and we plan to revert it for that kernel
> until more info is found about it.
>
> I'm adding reporter to CC (Lamont), in case more details are necessary
> etc.
>
I believe we're also homing in on the same regression in 2.6.38.6
('af_unix: Only allow recv on connected seqpacket sockets.'). The
functional part of the patch is:
+
+ if (sk->sk_state != TCP_ESTABLISHED)
+ return -ENOTCONN;
+
+ return unix_dgram_recvmsg(iocb, sock, msg, size, flags);
What happens with out of order receives? Would fragmentation have an impact?
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* [PATCH net-next 0/3] Three possible UDP fixes.
From: Paul Gortmaker @ 2011-06-21 20:43 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Paul Gortmaker
These were originally found on a 2.6.34 baseline, but I looked
at them and couldn't see any reason why they wouldn't be valid
fixes on net-next. But I'll feel better when someone like
Dave and/or Eric sanity checks them too.
There was one thing that was a consideration. In the 3rd patch,
where we clear MSG_TRUNC bit -- is there anything in there that
we really need to be concerned about preserving on the retry,
or could we just unconditionally do "msg->msg_flags = 0" ?
I wasn't sure, and so sticking with clearing the offending bit
seemed like the most cautious approach.
Thanks,
Paul.
---
Mark Asselstine (1):
net: ipv4: fix potential memory leak by assigning uhash_entries
Xufeng Zhang (2):
ipv6/udp: Use the correct variable to determine non-blocking condition
udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
net/ipv4/udp.c | 5 ++++-
net/ipv6/udp.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
--
1.7.4.4
^ permalink raw reply
* [PATCH net-next 1/3] net: ipv4: fix potential memory leak by assigning uhash_entries
From: Paul Gortmaker @ 2011-06-21 20:43 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Mark Asselstine, Paul Gortmaker
In-Reply-To: <1308689020-1873-1-git-send-email-paul.gortmaker@windriver.com>
From: Mark Asselstine <mark.asselstine@windriver.com>
Commit f86dcc5a [udp: dynamically size hash tables at boot time]
introduced the uhash_entries boot option and made sure to keep
it set within acceptable limits -- if used. It did not assign a
default value, however, so it defaults to zero. This results in
alloc_large_system_hash() being relied upon to specify an acceptable
number of hash entries, something it can't be relied on to always do
correctly. For example, when it fails to set an acceptable minimum
(UDP_HTABLE_SIZE_MIN) we get a second allocation and a memory leak.
So we need to set a default value for uhash_entries to ensure we get
the required minimum and prevent a second allocation.
This was found by using DEBUG_KMEMLEAK, producing the following log:
unreferenced object 0xc1b0d000 (size 4096):
comm "swapper", pid 1, jiffies 4294667562 (age 136.225s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<c10e9027>] create_object+0xd7/0x210
[<c15d73d7>] kmemleak_alloc+0x27/0x50
[<c1877032>] alloc_large_system_hash+0x16d/0x1f7
[<c189121d>] udp_table_init+0x43/0xf8
[<c18912e4>] udp_init+0x12/0x74
[<c1891637>] inet_init+0x179/0x250
[<c10011f0>] do_one_initcall+0x30/0x160
[<c18607c9>] kernel_init+0xb9/0x14e
[<c15fcff6>] kernel_thread_helper+0x6/0xd
[<ffffffff>] 0xffffffff
This is fairly easy to reproduce using ARCH=x86 defconfig (i386_defconfig)
enabling DEBUG_KMEMLEAK and running on a system with 32MB of memory
(qemu -m 32). With systems with larger amounts of memory we may not
see this leak since the logic in alloc_large_system_hash() will result
in a large enough (>UDP_HTABLE_SIZE_MIN) number of entries being set.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/ipv4/udp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index abca870..6f53a5a 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2155,7 +2155,7 @@ void udp4_proc_exit(void)
}
#endif /* CONFIG_PROC_FS */
-static __initdata unsigned long uhash_entries;
+static __initdata unsigned long uhash_entries = UDP_HTABLE_SIZE_MIN;
static int __init set_uhash_entries(char *str)
{
if (!str)
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 2/3] ipv6/udp: Use the correct variable to determine non-blocking condition
From: Paul Gortmaker @ 2011-06-21 20:43 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Xufeng Zhang, Paul Gortmaker
In-Reply-To: <1308689020-1873-1-git-send-email-paul.gortmaker@windriver.com>
From: Xufeng Zhang <xufeng.zhang@windriver.com>
udpv6_recvmsg() function is not using the correct variable to determine
whether or not the socket is in non-blocking operation, this will lead
to unexpected behavior when a UDP checksum error occurs.
Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:
err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
flags & ~MSG_DONTWAIT, &addr_len);
i.e. with udpv6_recvmsg() getting these values:
int noblock = flags & MSG_DONTWAIT
int flags = flags & ~MSG_DONTWAIT
So, when udp checksum error occurs, the execution will go to
csum_copy_err, and then the problem happens:
csum_copy_err:
...............
if (flags & MSG_DONTWAIT)
return -EAGAIN;
goto try_again;
...............
But it will always go to try_again as MSG_DONTWAIT has been cleared
from flags at call time -- only noblock contains the original value
of MSG_DONTWAIT, so the test should be:
if (noblock)
return -EAGAIN;
This is also consistent with what the ipv4/udp code does.
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/ipv6/udp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 41f8c9c..1e7a43f 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -453,7 +453,7 @@ csum_copy_err:
}
unlock_sock_fast(sk, slow);
- if (flags & MSG_DONTWAIT)
+ if (noblock)
return -EAGAIN;
goto try_again;
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 3/3] udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
From: Paul Gortmaker @ 2011-06-21 20:43 UTC (permalink / raw)
To: davem, eric.dumazet; +Cc: netdev, Xufeng Zhang, Paul Gortmaker
In-Reply-To: <1308689020-1873-1-git-send-email-paul.gortmaker@windriver.com>
From: Xufeng Zhang <xufeng.zhang@windriver.com>
Consider this scenario: When the size of the first received udp packet
is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
However, if checksum error happens and this is a blocking socket, it will
goto try_again loop to receive the next packet. But if the size of the
next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
receive the next packet, MSG_TRUNC is still set, which is wrong.
Fix this problem by clearing MSG_TRUNC flag when starting over for a
new packet.
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/ipv4/udp.c | 3 +++
net/ipv6/udp.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 6f53a5a..15d550c 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1249,6 +1249,9 @@ csum_copy_err:
if (noblock)
return -EAGAIN;
+
+ /* starting over for a new packet */
+ msg->msg_flags &= ~MSG_TRUNC;
goto try_again;
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 1e7a43f..328985c 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -455,6 +455,9 @@ csum_copy_err:
if (noblock)
return -EAGAIN;
+
+ /* starting over for a new packet */
+ msg->msg_flags &= ~MSG_TRUNC;
goto try_again;
}
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH]: Add Network Sysrq Support
From: Randy Dunlap @ 2011-06-21 20:46 UTC (permalink / raw)
To: Florian Westphal
Cc: Prarit Bhargava, netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <20110621203720.GB16021@Chamillionaire.breakpoint.cc>
On Tue, 21 Jun 2011 22:37:20 +0200 Florian Westphal wrote:
> Randy Dunlap <rdunlap@xenotime.net> wrote:
> > > diff --git a/Documentation/networking/sysrq-ping.txt b/Documentation/networking/sysrq-ping.txt
> > > new file mode 100644
> > > index 0000000..efa8be3
> > > --- /dev/null
> > > +++ b/Documentation/networking/sysrq-ping.txt
> > > @@ -0,0 +1,26 @@
> > > +In some circumstances, a system can hang/lockup in such a way that the system
> > > +is completely unresponsive to keyboard or console input but is still
> > > +responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> > > +net/ipv4/sysrq-ping.ko which allows a root user to configure the system for a
> >
> > or it can be built-in the kernel image... (i.e., not a loadable module)
> >
> > > +remote sysrq.
> > > +
> > > +To use this do:
> > > +
> > > +mount -t debugfs none /sys/kernel/debug/
> > > +echo 1 > /proc/sys/kernel/sysrq
> > > +echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> > > +echo 1 > /sys/kernel/debug/network_sysrq_enable
> >
> > so all of this (insecure) stuff has to be done before you suspect that
> > you need it .. in case the local keyboard/console is dead.
>
> There is an xt_SYSREQ module in xtables-addons package (i.e., a
> netfilter target), it supports hashed passwords and has some sequence
> number scheme to avoid replays.
>
> I think it would make more sense to merge that upstream, simply because
> it seems to be a bit more advanced...
in which case I would prefer this patch instead of a netfilter patch. :)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: Reported regression against commit a05d2ad
From: Eric W. Biederman @ 2011-06-21 20:49 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: lamont, sconklin, tim.gardner, netdev
In-Reply-To: <20110621201528.GB2249@herton-IdeaPad-Y430>
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> writes:
> Hi,
>
> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
> got a regression report about timeout in tcp connections
> (https://launchpad.net/bugs/791512).
>
> We tried help reporter with a bisect process, but it was taking some
> time, so we reverted some suspect commits, until we isolated it to
> commit "af_unix: Only allow recv on connected seqpacket sockets."
>
> With only commit a05d2ad reverted, testing results so far indicate the
> issue doesn't happen.
>
> I'm unfamiliar with unix sockets code, so can't see at first why this
> commit in particular is causing problems, for now I can only say may be
> something at application level using unix sockets regressed with it (?).
> I'm just reporting it right now, and we plan to revert it for that kernel
> until more info is found about it.
The only thing commit a05d2ad will prevent is a non-sense use of a
af_unix socket, and on recent enough kernels a NULL pointer deference.
I respectfully suggest that the bug is elsewhere perhaps a broken user
space application out there that needs to be fixed, or you have a kernel
memory stomp that removing patch a05d2ad happens to shift the memory
layout to be harmful in a different way.
af_unix sockets have nothing to do with tcp and only happen to use
the TCP_ESTABLISHED flag to indicated connected or non-connected
sockets.
Eric
> I'm adding reporter to CC (Lamont), in case more details are necessary
> etc.
^ permalink raw reply
* Re: [net-next 04/17] ixgbevf: provide 64 bit statistics
From: Jeff Kirsher @ 2011-06-21 20:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, Stephen Hemminger, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <1308584788.26922.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
On Mon, 2011-06-20 at 08:46 -0700, Eric Dumazet wrote:
> Le lundi 20 juin 2011 à 05:29 -0700, Jeff Kirsher a écrit :
>
> > I will drop Stephen's patch from this series and look forward to
> your
> > fixes. Thanks Eric.
> >
> >
>
> Here is an updated patch :
>
> [PATCH net-next] ixgbevf: provide 64 bit statistics
>
> Compute statistics per ring using 64 bits, and provide
> network device stats in 64 bits.
>
> It should make this driver multiqueue operations faster (no more cache
> line ping pongs on netdev->stats structure)
>
> Use u64_stats_sync infrastructure so that its safe on 32bit arches as
> well.
>
> Based on a prior patch from Stephen Hemminger
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Stephen Hemminger <shemminger@vyatta.com>
Thanks Eric, I have added the patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Reported regression against commit a05d2ad
From: Eric W. Biederman @ 2011-06-21 20:54 UTC (permalink / raw)
To: tim.gardner; +Cc: Herton Ronaldo Krzesinski, lamont, sconklin, netdev
In-Reply-To: <4E01015A.2030709@canonical.com>
Tim Gardner <tim.gardner@canonical.com> writes:
> On 06/21/2011 02:15 PM, Herton Ronaldo Krzesinski wrote:
>> Hi,
>>
>> after update to one of the latest 2.6.32.x stable kernels for Ubuntu, we
>> got a regression report about timeout in tcp connections
>> (https://launchpad.net/bugs/791512).
>>
>> We tried help reporter with a bisect process, but it was taking some
>> time, so we reverted some suspect commits, until we isolated it to
>> commit "af_unix: Only allow recv on connected seqpacket sockets."
>>
>> With only commit a05d2ad reverted, testing results so far indicate the
>> issue doesn't happen.
>>
>> I'm unfamiliar with unix sockets code, so can't see at first why this
>> commit in particular is causing problems, for now I can only say may be
>> something at application level using unix sockets regressed with it (?).
>> I'm just reporting it right now, and we plan to revert it for that kernel
>> until more info is found about it.
>>
>> I'm adding reporter to CC (Lamont), in case more details are necessary
>> etc.
>>
>
> I believe we're also homing in on the same regression in 2.6.38.6 ('af_unix:
> Only allow recv on connected seqpacket sockets.'). The functional part of the
> patch is:
>
> +
> + if (sk->sk_state != TCP_ESTABLISHED)
> + return -ENOTCONN;
> +
> + return unix_dgram_recvmsg(iocb, sock, msg, size, flags);
>
> What happens with out of order receives? Would fragmentation have an
> impact?
That code path has absolutely nothing to do with packets that come in
over the wire. Zilch, zero, nada. Fragments don't matter because
fragments can not possibly hit that code path. IP packets can not
possibly hit that code path.
Eric
^ permalink raw reply
* Re: [PATCH RFC] igb: Fix false positive return of igb_get_auto_rd_done for 82580
From: Jeff Kirsher @ 2011-06-21 21:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Brandeburg, Jesse, Wyborny, Carolyn, Duyck, Alexander H,
Ronciak, John, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, Tong Ho
In-Reply-To: <1308682969-20690-1-git-send-email-guenter.roeck@ericsson.com>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Tue, 2011-06-21 at 12:02 -0700, Guenter Roeck wrote:
> From: Tong Ho <tong.ho@ericsson.com>
>
> 82580 re-reads the port specific portion of eeprom after port reset.
> If called immediately after a reset, igb_get_auto_rd_done() returns
> false positive because the done bit has yet to transition from 1 to 0.
>
> Add wrfl() immediately after resetting 82580 port or device,
> plus a 1ms delay, to avoid the problem.
>
> Signed-off-by: Tong Ho <tong.ho@ericsson.com>
> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
> ---
> Sent as RFC since I am not entirely sure if the solution is the
> correct one
> to address the problem we are seeing. If there is a better solution,
> please
> let me know.
Thank you for the suggested patch. Carolyn is the maintainer for igb
and we will look into this issue you are seeing and the suggested fix.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] packet: Add fanout support.
From: David Miller @ 2011-06-21 21:31 UTC (permalink / raw)
To: xiaosuo; +Cc: victor, netdev
In-Reply-To: <BANLkTikgTqGY=S9UVik6wjSp5WE4WLmKtA@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 21 Jun 2011 21:05:24 +0800
> On Tue, Jun 21, 2011 at 6:46 PM, David Miller <davem@davemloft.net> wrote:
>> From: Victor Julien <victor@inliniac.net>
>> Date: Tue, 21 Jun 2011 12:39:11 +0200
>>
>>> The hash based on skb->rxhash, does that result in a "flow" based
>>> distribution over the listeners? So all packets sharing a tuple
>>> being sent to the same socket?
>>
>> Yes, that's exactly right.
>
> But not for fragments, in additional.
That's a fundamental issue in the RFS code which I've proposed
solutions for.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
From: David Miller @ 2011-06-21 21:35 UTC (permalink / raw)
To: sven-KaDOiPu9UxWEi8DpZVb4nw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1308661983-4113-1-git-send-email-sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Date: Tue, 21 Jun 2011 15:13:03 +0200
> I cannot speak on behalf of the batman-adv developers due to conflicts
> in the opinion about the ongoing development. The batman-adv module is
> still maintained by Marek Lindner and Simon Wunderlich. Those are the
> main persons behind the visions of batman-adv. Therefore, the state of
> module hasn't changed.
>
> Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> Cc: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r@public.gmane.org
You have to be kidding me.
All of this effort was placed to get this thing merged into the
main tree, and then moved out of staging.
And now you're just going to give up and jump ship and take exactly
zero responsibility for that burdon you've placed upon us?
You make me feel like a real idiot for sticking around and maintaining
the Linux networking for more than 15 years. Maybe 13 years ago I
should have stepped down just because I disagreed with a few other
people.
^ permalink raw reply
* Re: [RFC PATCH] packet: Add fanout support.
From: David Miller @ 2011-06-21 21:39 UTC (permalink / raw)
To: victor; +Cc: xiaosuo, netdev
In-Reply-To: <4E009C5A.8060208@inliniac.net>
From: Victor Julien <victor@inliniac.net>
Date: Tue, 21 Jun 2011 15:27:54 +0200
> From a Suricata IDS point of view, I would need to have the
> fragments of a flow/tuple on the same socket.
Currently you would, they would all go to the first socket in
the fanout.
^ permalink raw reply
* Re: [RFT PATCH 0/9] Cleanup and extension of netdev features
From: Ben Greear @ 2011-06-21 21:43 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, David S. Miller, Ben Hutchings
In-Reply-To: <cover.1308596962.git.mirq-linux@rere.qmqm.pl>
On 06/20/2011 12:14 PM, Michał Mirosław wrote:
> This is a preview of the cleanups pending after getting rid of old
> ethtool ops from remaining drivers.
Even when skipping patch 1 (seems this was just merged earlier today),
these patches do not all apply to net-next.
They are also full of white-space warnings.
Please re-post them when you sync against upstream
and I'll try to do some testing.
Also, do you have a cooresponding patch against ethtool
to make it able to handle the new 64-bit flags?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFT PATCH 0/9] Cleanup and extension of netdev features
From: Ben Hutchings @ 2011-06-21 21:52 UTC (permalink / raw)
To: Ben Greear; +Cc: Michał Mirosław, netdev, David S. Miller
In-Reply-To: <4E011080.7000008@candelatech.com>
On Tue, 2011-06-21 at 14:43 -0700, Ben Greear wrote:
> On 06/20/2011 12:14 PM, Michał Mirosław wrote:
> > This is a preview of the cleanups pending after getting rid of old
> > ethtool ops from remaining drivers.
>
> Even when skipping patch 1 (seems this was just merged earlier today),
> these patches do not all apply to net-next.
>
> They are also full of white-space warnings.
>
> Please re-post them when you sync against upstream
> and I'll try to do some testing.
>
> Also, do you have a cooresponding patch against ethtool
> to make it able to handle the new 64-bit flags?
It doesn't handle named features at all yet, though Michał has
previously prepared patches to do so.
Ben.
--
Ben Hutchings, Senior Software 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]: Add Network Sysrq Support
From: Flavio Leitner @ 2011-06-21 22:05 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: netdev, davem, agospoda, nhorman, lwoodman
In-Reply-To: <20110621130040.12035.62533.sendpatchset@prarit.bos.redhat.com>
On 06/21/2011 10:00 AM, Prarit Bhargava wrote:
> Add Network Sysrq Support
>
> In some circumstances, a system can hang/lockup in such a way that the system
> is completely unresponsive to keyboard or console input but is still
> responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> net/ipv4/sysrq-ping.ko which allows a root user to configure the system for
> a remote sysrq.
>
> To use this do:
>
> mount -t debugfs none /sys/kernel/debug/
> echo 1 > /proc/sys/kernel/sysrq
> echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> echo 1 > /sys/kernel/debug/network_sysrq_enable
>
> Then on another system on the network you can do:
>
> ping -c 1 -p <up to 30 hex digit val><hex val of sysrq> <target_system_name>
>
> ex) sysrq-m, m is ascii 0x6d
>
> ping -c 1 p 1623a06f554d46d676d <target_system_name>
missing '-' in front of 'p'
>
> Note that the network sysrq automatically disables after the receipt of
> the ping, ie) it is single-shot mode. If you want to use this again, you
> must complete the above four steps again.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>
> diff --git a/Documentation/networking/sysrq-ping.txt b/Documentation/networking/sysrq-ping.txt
> new file mode 100644
> index 0000000..efa8be3
> --- /dev/null
> +++ b/Documentation/networking/sysrq-ping.txt
> @@ -0,0 +1,26 @@
> +In some circumstances, a system can hang/lockup in such a way that the system
> +is completely unresponsive to keyboard or console input but is still
> +responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> +net/ipv4/sysrq-ping.ko which allows a root user to configure the system for a
> +remote sysrq.
> +
> +To use this do:
> +
> +mount -t debugfs none /sys/kernel/debug/
> +echo 1 > /proc/sys/kernel/sysrq
> +echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> +echo 1 > /sys/kernel/debug/network_sysrq_enable
> +
> +Then on another system you can do:
> +
> +ping -c 1 -p <hex digit val><hex val of sysrq> <target_system_name>
> +
> +ex) sysrq-m, m is ascii 0x6d
> +
> + ping -c 1 p 1623a06f554d46d676d <target_system_name>
again -p
> +
> +Note that the network sysrq automatically disables after the receipt of
> +the ping, ie) it is single-shot mode. If you want to use this again, you
> +must complete the above four steps again.
> +
> +Hint: 'man ascii' ;)
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index cbb505b..03bb7b1 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,11 @@ config TCP_MD5SIG
> on the Internet.
>
> If unsure, say N.
> +
> +config SYSRQ_PING
> + tristate
> + default m
prompt?
> + help
> + Allows execution of sysrq-X commands via ping over ipv4. This is a
> + known security hazard and should not be used in unsecure
> + environments.
> diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
> index f2dc69c..c23c15e 100644
> --- a/net/ipv4/Makefile
> +++ b/net/ipv4/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
> obj-$(CONFIG_TCP_CONG_YEAH) += tcp_yeah.o
> obj-$(CONFIG_TCP_CONG_ILLINOIS) += tcp_illinois.o
> obj-$(CONFIG_NETLABEL) += cipso_ipv4.o
> +obj-$(CONFIG_SYSRQ_PING) += sysrq-ping.o
>
> obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
> xfrm4_output.o
> diff --git a/net/ipv4/sysrq-ping.c b/net/ipv4/sysrq-ping.c
> new file mode 100644
> index 0000000..67a6d0e
> --- /dev/null
> +++ b/net/ipv4/sysrq-ping.c
> @@ -0,0 +1,207 @@
> +/*
> + * network_sysrq.c - allow sysrq to be executed over a network via ping
> + *
> + * written by: Prarit Bhargava <prarit@redhat.com>
> + * Andy Gospodarek <agospoda@redhat.com>
> + * Neil Horman <nhorman@redhat.com>
> + *
> + * based on work by: Larry Woodman <lwoodman@redhat.com>
> + *
> + * To use this do:
> + *
> + * mount -t debugfs none /sys/kernel/debug/
> + * echo 1 > /proc/sys/kernel/sysrq
> + * echo <hex digit val> > /sys/kernel/debug/network_sysrq_magic
> + * echo 1 > /sys/kernel/debug/network_sysrq_enable
> + *
> + * Then on another system you can do:
> + *
> + * ping -c 1 -p <hex digit val><hex val of sysrq> <target_system_name>
> + *
> + * ex) sysrq-m, m is 0x6d
> + *
> + * ping -c 1 p 1623a06f554d46d676d <target_system_name>
again -p
> + *
> + * Note that the network sysrq automatically disables after the receipt of
> + * *ANY* ping. If you want to use this again, you must complete the
> + * above four steps again.
why not leave it running? perhaps disable it for some time to
filter any ping retransmission, for instance netsysrq_reenable=10 seconds.
and then do if (time_after(jiffies, last_ping + netsysrq_reenable))...
I have an USB KVM console, so often when testing workload, the USB takes
ages to register the keyboard and I'd like to shot some sysrq+t or w,
so if it disables after the first one, I can't get more traces because
I simply can't enable it again.
> + *
> + */
> +
> +#include <linux/debugfs.h>
> +#include <linux/icmp.h>
> +#include <linux/init.h>
> +#include <linux/ip.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/netdevice.h>
> +#include <linux/sysrq.h>
> +
> +#include <net/xfrm.h>
> +
> +static u8 network_sysrq_enable; /* set in debugfs network_sysrq_enable */
> +static u16 network_sysrq_magic[16]; /* 15 bytes leaves 1 feature byte */
> +static int network_sysrq_magic_len;
> +
> +static int to_hex(int val)
> +{
> + if ((val >= '0') && (val <= '9'))
> + return val - 0x30;
> +
> + if ((val >= 'a') && (val <= 'f'))
> + return val - 0x37;
> +
> + if ((val >= 'A') && (val <= 'F'))
> + return val - 0x57;
> +
> + return -1;
> +}
> +
> +static bool network_sysrq_armed(void)
> +{
> + int i;
> +
> + if (!network_sysrq_enable)
> + return false;
> + if (!network_sysrq_magic_len)
> + return false;
> + for (i = 0; i < 16; i++)
> + if (network_sysrq_magic[i] != 0)
> + return true;
> + return false;
> +}
> +
> +static void network_sysrq_disable(void)
> +{
> + network_sysrq_enable = 0;
> + memset(network_sysrq_magic, 0, 32);
> + network_sysrq_magic_len = 0;
> +}
> +
> +static ssize_t network_sysrq_seq_write(struct file *file,
> + const char __user *ubuf,
> + size_t count, loff_t *ppos)
> +{
> + int i, j, hi, lo;
> + char buf[33];
> + memset(buf, 0, sizeof(buf));
> +
> + if (count >= 33)
> + return -EINVAL;
> +
> + if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
> + return -EFAULT;
> +
> + for (i = 0, j = 0; i < count - 2 ; i += 2, j++) {
> + hi = to_hex(buf[i]);
> + lo = to_hex(buf[i+1]) & 0x0f;
> + if ((hi == -1) || (lo == -1)) {
> + network_sysrq_disable();
> + return -EINVAL;
> + }
> + network_sysrq_magic[j] = (u16)(hi << 4) + lo;
> + }
> + network_sysrq_magic_len = j;
> +
> + return count;
> +}
> +
> +static int network_sysrq_seq_show(struct seq_file *m, void *p)
> +{
> + int i;
> +
> + for (i = 0; i < network_sysrq_magic_len; i++)
> + seq_printf(m, "%02x", network_sysrq_magic[i]);
> + seq_printf(m, "\n");
> + return 0;
> +}
> +
> +static int network_sysrq_fops_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, network_sysrq_seq_show, inode->i_private);
> +}
> +
> +static const struct file_operations xnetwork_sysrq_fops = {
> + .open = network_sysrq_fops_open,
> + .write = network_sysrq_seq_write,
> + .read = seq_read,
> + .llseek = seq_lseek,
> +};
> +
> +static int network_sysrq_func(struct sk_buff *skb, struct net_device *dev,
> + struct packet_type *pt,
> + struct net_device *orig_dev)
> +{
> + struct icmphdr *icmph;
> + char *found;
> +
> + if (ip_hdr(skb)->protocol != IPPROTO_ICMP)
> + goto end;
> +
> + if (!skb_pull(skb, sizeof(struct iphdr)))
> + goto end;
> +
> + skb_reset_transport_header(skb);
> + icmph = icmp_hdr(skb);
> +
> + if (!skb_pull(skb, sizeof(*icmph)))
> + goto end;
> +
> + /* is this a ping? */
> + if (icmph->type != ICMP_ECHO)
> + goto end;
What about a whitelist of source MAC or IP addresses to accept the sysrq?
I'm thinking on a situation where we leave the systems with this enabled
and then an ordinary user starts pinging the network guessing the hexa to
cause reboots.
Tested here and it works.
Tested-by: Flavio Leitner <fbl@redhat.com>
fbl
> + if (network_sysrq_armed()) {
> + found = strnstr(skb->data, (char *)network_sysrq_magic,
> + skb->len - skb->data_len);
> + if (found)
> + handle_sysrq(found[network_sysrq_magic_len]);
> + network_sysrq_disable();
> + }
> +end:
> + kfree_skb(skb);
> + return 0;
> +}
> +
> +static struct packet_type network_sysrq_type = {
> + .type = cpu_to_be16(ETH_P_IP),
> + .func = network_sysrq_func,
> +};
> +
> +static struct dentry *network_sysrq_enable_dentry;
> +static struct dentry *network_sysrq_magic_dentry;
> +
> +int __init init_network_sysrq(void)
> +{
> + network_sysrq_enable_dentry = debugfs_create_u8("network_sysrq_enable",
> + S_IWUGO | S_IRUGO,
> + NULL,
> + &network_sysrq_enable);
> + if (!network_sysrq_enable_dentry)
> + return -EIO;
> +
> + network_sysrq_magic_dentry = debugfs_create_file("network_sysrq_magic",
> + S_IWUGO | S_IRUGO,
> + NULL,
> + &network_sysrq_magic,
> + &xnetwork_sysrq_fops);
> + if (!network_sysrq_magic_dentry) {
> + debugfs_remove(network_sysrq_enable_dentry);
> + return -EIO;
> + }
> +
> + dev_add_pack(&network_sysrq_type);
> + return 0;
> +}
> +
> +void __exit cleanup_network_sysrq(void)
> +{
> + dev_remove_pack(&network_sysrq_type);
> + debugfs_remove(network_sysrq_enable_dentry);
> + debugfs_remove(network_sysrq_magic_dentry);
> +}
> +
> +module_init(init_network_sysrq);
> +module_exit(cleanup_network_sysrq);
> +
> +MODULE_LICENSE("GPL");
> --
> 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
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