Re: [Linux-parport] [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.
On 30/06/14 09:48, Matwey V. Kornilov wrote: The detection of Intel EPP bug is known to produce much false positives. The new option is introduced to force enable EPP in spite of the test result. I can confirm that this check produces false positives on a range of hardware - I no longer have the machine that I experienced the problem with but when I posted about the issue in the past I had several responses from other users suffering from the problem. Tested-by: Heiko Andreas Sommer Signed-off-by: Matwey V. Kornilov --- drivers/parport/parport_pc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c index 4b851bb..1a15b9c 100644 --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -105,6 +105,9 @@ static int user_specified; (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO)) static int verbose_probing; #endif +#ifdef CONFIG_PARPORT_1284 +static int force_epp; +#endif static int pci_registered_parport; static int pnp_registered_parport; @@ -1765,7 +1768,7 @@ static int parport_EPP_supported(struct parport *pb) return 0; /* No way to clear timeout */ /* Check for Intel bug. */ -if (intel_bug_present(pb)) +if (!force_epp && intel_bug_present(pb)) return 0; pb->modes |= PARPORT_MODE_EPP; @@ -3148,6 +3151,10 @@ module_param_array(dma, charp, NULL, 0); MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation"); module_param(verbose_probing, int, 0644); #endif +#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, "Do not disable EPP when it is detected to be broken (default is false)"); I think this needs some more explanation - how about "Disable check for broken Intel EPP hardware that gives false positives on 2002 and newer hardware" The 2002 date is based upon http://thread.gmane.org/gmane.linux.parport/322/focus=326 Last time fixing this was discussed Jonathan Nieder did some digging in the history and technical details and posted at the tail of the thread at https://groups.google.com/forum/?_escaped_fragment_=topic/linux.debian.bugs.dist/nhK1ZU4x0Ok#!topic/linux.debian.bugs.dist/nhK1ZU4x0Ok +module_param(force_epp, int, 0); +#endif #ifdef CONFIG_PCI static char *init_mode; MODULE_PARM_DESC(init_mode, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-parport] [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.
On 30/06/14 09:48, Matwey V. Kornilov wrote: The detection of Intel EPP bug is known to produce much false positives. The new option is introduced to force enable EPP in spite of the test result. I can confirm that this check produces false positives on a range of hardware - I no longer have the machine that I experienced the problem with but when I posted about the issue in the past I had several responses from other users suffering from the problem. Tested-by: Heiko Andreas Sommer hsom...@eso.org Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru --- drivers/parport/parport_pc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c index 4b851bb..1a15b9c 100644 --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -105,6 +105,9 @@ static int user_specified; (defined(CONFIG_PARPORT_1284) defined(CONFIG_PARPORT_PC_FIFO)) static int verbose_probing; #endif +#ifdef CONFIG_PARPORT_1284 +static int force_epp; +#endif static int pci_registered_parport; static int pnp_registered_parport; @@ -1765,7 +1768,7 @@ static int parport_EPP_supported(struct parport *pb) return 0; /* No way to clear timeout */ /* Check for Intel bug. */ -if (intel_bug_present(pb)) +if (!force_epp intel_bug_present(pb)) return 0; pb-modes |= PARPORT_MODE_EPP; @@ -3148,6 +3151,10 @@ module_param_array(dma, charp, NULL, 0); MODULE_PARM_DESC(verbose_probing, Log chit-chat during initialisation); module_param(verbose_probing, int, 0644); #endif +#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, Do not disable EPP when it is detected to be broken (default is false)); I think this needs some more explanation - how about Disable check for broken Intel EPP hardware that gives false positives on 2002 and newer hardware The 2002 date is based upon http://thread.gmane.org/gmane.linux.parport/322/focus=326 Last time fixing this was discussed Jonathan Nieder did some digging in the history and technical details and posted at the tail of the thread at https://groups.google.com/forum/?_escaped_fragment_=topic/linux.debian.bugs.dist/nhK1ZU4x0Ok#!topic/linux.debian.bugs.dist/nhK1ZU4x0Ok +module_param(force_epp, int, 0); +#endif #ifdef CONFIG_PCI static char *init_mode; MODULE_PARM_DESC(init_mode, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Frees gate after if statement in clk-sunxi.c
On 14/06/14 19:11, Nick wrote: Signed-off-by: Nick --- drivers/clk/sunxi/clk-sunxi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index 4264834..6f4fc51 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -42,6 +42,7 @@ static void __init sun4i_osc_clk_setup(struct device_node *node) u32 rate; if (of_property_read_u32(node, "clock-frequency", )) + kree(gate); return; There are no braces around this so the function of this code as written is an unconditional return and the return shouldn't be indented. I suspect, without reading the rest of the file, that that isn't what you intended. /* allocate fixed-rate and gate clock structs */ Adam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Frees gate after if statement in clk-sunxi.c
On 14/06/14 19:11, Nick wrote: Signed-off-by: Nick xerofo...@gmail.com --- drivers/clk/sunxi/clk-sunxi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index 4264834..6f4fc51 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -42,6 +42,7 @@ static void __init sun4i_osc_clk_setup(struct device_node *node) u32 rate; if (of_property_read_u32(node, clock-frequency, rate)) + kree(gate); return; There are no braces around this so the function of this code as written is an unconditional return and the return shouldn't be indented. I suspect, without reading the rest of the file, that that isn't what you intended. /* allocate fixed-rate and gate clock structs */ Adam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] ARM: dts: kirkwood: fix mislocated pcie-controller nodes
On 30/04/14 13:56, Sebastian Hesselbarth wrote:
Commit 54397d85349f
("ARM: kirkwood: Relocate PCIe device tree nodes")
moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
bus node. For some reason, two boards were not properly converted
and have their pci-controller nodes still in the ocp bus node.
As the corresponding SoC pcie-controller does not exist anymore,
it is likely that pcie is broken on those boards since above commit.
Fix it by moving the pcie related nodes to the correct location.
Signed-off-by: Sebastian Hesselbarth
I've tried this patch on NSA320, as expected it doesn't make any
observable difference as there is nothing connected to the PCIe bus
(hence not really worth a tested by). It matters more on the NSA310 as
that uses PCIe for Ethernet.
Regards
Adam Baker
---
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 18 ++
arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi | 18 ++
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
index 2cb0dc529165..4bf358c28be2 100644
--- a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
+++ b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
@@ -30,6 +30,16 @@
bootargs = "console=ttyS0,115200n8 earlyprintk";
};
+ mbus {
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ status = "okay";
+ };
+ };
+};
+
ocp@f100 {
pinctrl@1 {
pmx_usb_led: pmx-usb-led {
@@ -73,14 +83,6 @@
ehci@5 {
status = "okay";
};
-
- pcie-controller {
- status = "okay";
-
- pcie@1,0 {
- status = "okay";
- };
- };
};
gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
b/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
index 843b8b561e5e..b88810df7ca2 100644
--- a/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
@@ -4,6 +4,16 @@
/ {
model = "ZyXEL NSA310";
+ mbus {
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ status = "okay";
+ };
+ };
+ };
+
ocp@f100 {
pinctrl: pinctrl@1 {
@@ -51,14 +61,6 @@
status = "okay";
nr-ports = <2>;
};
-
- pcie-controller {
- status = "okay";
-
- pcie@1,0 {
- status = "okay";
- };
- };
};
gpio_poweroff {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] ARM: dts: kirkwood: fix mislocated pcie-controller nodes
On 30/04/14 13:56, Sebastian Hesselbarth wrote:
Commit 54397d85349f
(ARM: kirkwood: Relocate PCIe device tree nodes)
moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
bus node. For some reason, two boards were not properly converted
and have their pci-controller nodes still in the ocp bus node.
As the corresponding SoC pcie-controller does not exist anymore,
it is likely that pcie is broken on those boards since above commit.
Fix it by moving the pcie related nodes to the correct location.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
I've tried this patch on NSA320, as expected it doesn't make any
observable difference as there is nothing connected to the PCIe bus
(hence not really worth a tested by). It matters more on the NSA310 as
that uses PCIe for Ethernet.
Regards
Adam Baker
---
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 18 ++
arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi | 18 ++
2 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
index 2cb0dc529165..4bf358c28be2 100644
--- a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
+++ b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
@@ -30,6 +30,16 @@
bootargs = console=ttyS0,115200n8 earlyprintk;
};
+ mbus {
+ pcie-controller {
+ status = okay;
+
+ pcie@1,0 {
+ status = okay;
+ };
+ };
+};
+
ocp@f100 {
pinctrl@1 {
pmx_usb_led: pmx-usb-led {
@@ -73,14 +83,6 @@
ehci@5 {
status = okay;
};
-
- pcie-controller {
- status = okay;
-
- pcie@1,0 {
- status = okay;
- };
- };
};
gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
b/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
index 843b8b561e5e..b88810df7ca2 100644
--- a/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-nsa3x0-common.dtsi
@@ -4,6 +4,16 @@
/ {
model = ZyXEL NSA310;
+ mbus {
+ pcie-controller {
+ status = okay;
+
+ pcie@1,0 {
+ status = okay;
+ };
+ };
+ };
+
ocp@f100 {
pinctrl: pinctrl@1 {
@@ -51,14 +61,6 @@
status = okay;
nr-ports = 2;
};
-
- pcie-controller {
- status = okay;
-
- pcie@1,0 {
- status = okay;
- };
- };
};
gpio_poweroff {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] bridge: disable snooping if there is no querier
On 25/07/13 14:56, Linus Lüssing wrote:
If there is no querier on a link then we won't get periodic reports and
therefore won't be able to learn about multicast listeners behind ports,
potentially leading to lost multicast packets, especially for multicast
listeners that joined before the creation of the bridge.
These lost multicast packets can appear since c5c23260594
("bridge: Add multicast_querier toggle and disable queries by default")
in particular.
With this patch we are flooding multicast packets if our querier is
disabled and if we didn't detect any other querier.
A grace period of the Maximum Response Delay of the querier is added to
give multicast responses enough time to arrive and to be learned from
before disabling the flooding behaviour again.
Signed-off-by: Linus Lüssing
If the lack of queries if there is no other querier is unacceptable to
the majority of users (and I believe it is) then surely the sensible
option is to have the multicast querier toggle enabled by default.
The toggle was added in the first place because the queries were
reported to be generating issues with certain other equipment. This may
have been because the queries by default have an invalid IP address
(although I have been unable to identify what equipment they caused
problems with so can't verify this).
If the only reason to turn the querier off is because it interferes with
other equipment then the solution to it being off by default isn't to
generate queries in some instances even if it is off but rather to turn
it on by default and only turn it off if it causes problems. If
multicast_query_use_ifaddr was also enabled by default the the
likelihood of the querier causing problems elsewhere should be reduced.
Regards
Adam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] bridge: disable snooping if there is no querier
On 25/07/13 14:56, Linus Lüssing wrote: If there is no querier on a link then we won't get periodic reports and therefore won't be able to learn about multicast listeners behind ports, potentially leading to lost multicast packets, especially for multicast listeners that joined before the creation of the bridge. These lost multicast packets can appear since c5c23260594 (bridge: Add multicast_querier toggle and disable queries by default) in particular. With this patch we are flooding multicast packets if our querier is disabled and if we didn't detect any other querier. A grace period of the Maximum Response Delay of the querier is added to give multicast responses enough time to arrive and to be learned from before disabling the flooding behaviour again. Signed-off-by: Linus Lüssinglinus.luess...@web.de If the lack of queries if there is no other querier is unacceptable to the majority of users (and I believe it is) then surely the sensible option is to have the multicast querier toggle enabled by default. The toggle was added in the first place because the queries were reported to be generating issues with certain other equipment. This may have been because the queries by default have an invalid IP address (although I have been unable to identify what equipment they caused problems with so can't verify this). If the only reason to turn the querier off is because it interferes with other equipment then the solution to it being off by default isn't to generate queries in some instances even if it is off but rather to turn it on by default and only turn it off if it causes problems. If multicast_query_use_ifaddr was also enabled by default the the likelihood of the querier causing problems elsewhere should be reduced. Regards Adam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}
On Friday 26 October 2007 20:10, Roland Dreier wrote: > > Well it could be something quite simple, in the module loader it is > looping > through all modules to look for a device with the correct USB/PCI > ID. > Currently, after the first occurence it loads the module and doesn't > continue, > it should perhaps be relatively easy that it checks if the > driver returned -ENODEV > and continues looping to search for another > driver. > > But a driver (especially a driver for something as hot-pluggable as a > USB device) shouldn't return -ENODEV just because no devices are > present at the moment. It should just load successfully and wait for > a device to appear. The function that is returning ENODEV is the driver probe function. According to Documentation/DocBook/writing_usb_driver/ch03.html when that function is called "The driver now needs to verify that this device is actually one that it can accept. If so, it returns 0. If not, or if any error occurs during initialization, an errorcode (such as -ENOMEM or -ENODEV) is returned from the probe function." It isn't a device the driver can accept so it returns -ENODEV Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}
On Friday 26 October 2007 20:10, Roland Dreier wrote: Well it could be something quite simple, in the module loader it is looping through all modules to look for a device with the correct USB/PCI ID. Currently, after the first occurence it loads the module and doesn't continue, it should perhaps be relatively easy that it checks if the driver returned -ENODEV and continues looping to search for another driver. But a driver (especially a driver for something as hot-pluggable as a USB device) shouldn't return -ENODEV just because no devices are present at the moment. It should just load successfully and wait for a device to appear. The function that is returning ENODEV is the driver probe function. According to Documentation/DocBook/writing_usb_driver/ch03.html when that function is called The driver now needs to verify that this device is actually one that it can accept. If so, it returns 0. If not, or if any error occurs during initialization, an errorcode (such as -ENOMEM or -ENODEV) is returned from the probe function. It isn't a device the driver can accept so it returns -ENODEV Adam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}
On Thursday 25 October 2007 00:22, Parag Warudkar wrote: > I have a Belkin USB Wireless adapter with ID 050d:705a. > Both rt2500usb.c and rt73usb.c claim that they can drive the device with > this ID. > > When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and > rt2500usb get loaded and fight for the register writes and fail. rt2500usb > is not able to drive my device. So I have to manually rmmod/modprobe or > delete rt2500usb.ko and depmod every time I get a new kernel. > > If only rt73usb is loaded everything works well. To me it > sounds like rt2500usb should not be driving 050d:705a. > Unfortunately Belkin have sold both RT73 and RT2500 devices with that USB ID. You don't say what distro you are runing or what version of RT2x00 it ships with but last time I checked with the git version of rt2x00 it tried to load both drivers but the rt2500 driver noticed it was the wrong hardware and shut down. My Belkin stick is busy right now but I'll test that still works later. > There is another ID 050d:7050 which is also claimed to be handled by both > rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no > way to be sure as I don't have device with this ID) the following patch > makes sure only rt73usb claims the 2 devices. > There are a few such devices but they are all cases where there are reliable reports of manufacturers shipping both device types with one USB ID. There are some cases where the alternate chipset with the same USB ID isn't even a ralink device but there isn't much we can do about those. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Rt2400-devel] [PATCH] rt2500usb - Don't claim 050d:705{0/a}
On Thursday 25 October 2007 00:22, Parag Warudkar wrote: I have a Belkin USB Wireless adapter with ID 050d:705a. Both rt2500usb.c and rt73usb.c claim that they can drive the device with this ID. When using the distro kernel as well as custom 2.4.24-rc1 both rt73usb and rt2500usb get loaded and fight for the register writes and fail. rt2500usb is not able to drive my device. So I have to manually rmmod/modprobe or delete rt2500usb.ko and depmod every time I get a new kernel. If only rt73usb is loaded everything works well. To me it sounds like rt2500usb should not be driving 050d:705a. Unfortunately Belkin have sold both RT73 and RT2500 devices with that USB ID. You don't say what distro you are runing or what version of RT2x00 it ships with but last time I checked with the git version of rt2x00 it tried to load both drivers but the rt2500 driver noticed it was the wrong hardware and shut down. My Belkin stick is busy right now but I'll test that still works later. There is another ID 050d:7050 which is also claimed to be handled by both rt3500usb and rt73usb. Assuming rt73usb can drive this as well (I have no way to be sure as I don't have device with this ID) the following patch makes sure only rt73usb claims the 2 devices. There are a few such devices but they are all cases where there are reliable reports of manufacturers shipping both device types with one USB ID. There are some cases where the alternate chipset with the same USB ID isn't even a ralink device but there isn't much we can do about those. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
