* Re: [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
@ 2011-10-13 20:17 ` Oliver Hartkopp
2011-11-02 20:55 ` [PATCH] MAINTAINERS: Add can-gw include to maintained files Oliver Hartkopp
` (5 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Oliver Hartkopp @ 2011-10-13 20:17 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can, netdev
On 10/13/11 13:42, Marc Kleine-Budde wrote:
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
> ---
> MAINTAINERS | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aac56f9..5008b08 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1671,7 +1671,7 @@ CAN NETWORK LAYER
> M: Oliver Hartkopp <socketcan@hartkopp.net>
> M: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
> M: Urs Thuermann <urs.thuermann@volkswagen.de>
> -L: socketcan-core@lists.berlios.de (subscribers-only)
> +L: linux-can@vger.kernel.org
> L: netdev@vger.kernel.org
> W: http://developer.berlios.de/projects/socketcan/
> S: Maintained
> @@ -1683,7 +1683,7 @@ F: include/linux/can/raw.h
>
> CAN NETWORK DRIVERS
> M: Wolfgang Grandegger <wg@grandegger.com>
> -L: socketcan-core@lists.berlios.de (subscribers-only)
> +L: linux-can@vger.kernel.org
> L: netdev@vger.kernel.org
> W: http://developer.berlios.de/projects/socketcan/
> S: Maintained
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH] MAINTAINERS: Add can-gw include to maintained files
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
2011-10-13 20:17 ` Oliver Hartkopp
@ 2011-11-02 20:55 ` Oliver Hartkopp
2011-11-03 22:12 ` David Miller
2012-02-14 19:27 ` [PATCH] can: sja1000 fix isr hang when hw is unplugged under load Oliver Hartkopp
` (4 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Oliver Hartkopp @ 2011-11-02 20:55 UTC (permalink / raw)
To: netdev; +Cc: linux-can
Commit c1aabdf379bc2feeb0df7057ed5bad96f492133e (can-gw: add netlink based
CAN routing) added a new include file that's neither referenced by any of
the CAN maintainers.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 479beaa..abeb3f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1716,6 +1716,7 @@ F: include/linux/can.h
F: include/linux/can/core.h
F: include/linux/can/bcm.h
F: include/linux/can/raw.h
+F: include/linux/can/gw.h
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg@grandegger.com>
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH] can: sja1000 fix isr hang when hw is unplugged under load
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
2011-10-13 20:17 ` Oliver Hartkopp
2011-11-02 20:55 ` [PATCH] MAINTAINERS: Add can-gw include to maintained files Oliver Hartkopp
@ 2012-02-14 19:27 ` Oliver Hartkopp
2012-02-15 16:51 ` [PATCH v2] " Oliver Hartkopp
` (3 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Oliver Hartkopp @ 2012-02-14 19:27 UTC (permalink / raw)
To: linux-can
In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
hardware can cause an infinite loop in the common sja1000 isr.
Use the already retrieved status register to indicate a possible hardware
removal and double check by reading the mode register in sja1000_probe_chip.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index ebbcfca..37773fb 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -492,6 +492,9 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
while ((isrc = priv->read_reg(priv, REG_IR)) && (n < SJA1000_MAX_IRQ)) {
n++;
status = priv->read_reg(priv, REG_SR);
+ /* check for absent controller due to hw unplug */
+ if (status == 0xFF && !sja1000_probe_chip(dev))
+ return IRQ_NONE;
if (isrc & IRQ_WUI)
netdev_warn(dev, "wakeup interrupt\n");
@@ -508,6 +511,9 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
while (status & SR_RBS) {
sja1000_rx(dev);
status = priv->read_reg(priv, REG_SR);
+ /* check for absent controller */
+ if (status == 0xFF && !sja1000_probe_chip(dev))
+ return IRQ_NONE;
}
}
if (isrc & (IRQ_DOI | IRQ_EI | IRQ_BEI | IRQ_EPI | IRQ_ALI)) {
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
` (2 preceding siblings ...)
2012-02-14 19:27 ` [PATCH] can: sja1000 fix isr hang when hw is unplugged under load Oliver Hartkopp
@ 2012-02-15 16:51 ` Oliver Hartkopp
2012-02-17 20:27 ` Marc Kleine-Budde
2012-03-25 6:43 ` [PATCH] iwlwifi: fix unused variable warning Oliver Hartkopp
` (2 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Oliver Hartkopp @ 2012-02-15 16:51 UTC (permalink / raw)
To: linux-can
In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
hardware can cause an infinite loop in the common sja1000 isr.
Use the already retrieved status register to indicate a possible hardware
removal and double check by reading the mode register in sja1000_is_absent.
v2: Create a new function to not print information in irq context.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 04a3f1b..192b0d1 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -95,11 +95,16 @@ static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
spin_unlock_irqrestore(&priv->cmdreg_lock, flags);
}
+static int sja1000_is_absent(struct sja1000_priv *priv)
+{
+ return (priv->read_reg(priv, REG_MOD) == 0xFF);
+}
+
static int sja1000_probe_chip(struct net_device *dev)
{
struct sja1000_priv *priv = netdev_priv(dev);
- if (priv->reg_base && (priv->read_reg(priv, 0) == 0xFF)) {
+ if (priv->reg_base && sja1000_is_absent(priv)) {
printk(KERN_INFO "%s: probing @0x%lX failed\n",
DRV_NAME, dev->base_addr);
return 0;
@@ -493,6 +498,9 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
while ((isrc = priv->read_reg(priv, REG_IR)) && (n < SJA1000_MAX_IRQ)) {
n++;
status = priv->read_reg(priv, REG_SR);
+ /* check for absent controller due to hw unplug */
+ if (status == 0xFF && sja1000_is_absent(priv))
+ return IRQ_NONE;
if (isrc & IRQ_WUI)
dev_warn(dev->dev.parent, "wakeup interrupt\n");
@@ -509,6 +517,9 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
while (status & SR_RBS) {
sja1000_rx(dev);
status = priv->read_reg(priv, REG_SR);
+ /* check for absent controller */
+ if (status == 0xFF && sja1000_is_absent(priv))
+ return IRQ_NONE;
}
}
if (isrc & (IRQ_DOI | IRQ_EI | IRQ_BEI | IRQ_EPI | IRQ_ALI)) {
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-15 16:51 ` [PATCH v2] " Oliver Hartkopp
@ 2012-02-17 20:27 ` Marc Kleine-Budde
2012-02-18 14:19 ` Oliver Hartkopp
2012-02-18 14:33 ` Wolfgang Grandegger
0 siblings, 2 replies; 24+ messages in thread
From: Marc Kleine-Budde @ 2012-02-17 20:27 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
> hardware can cause an infinite loop in the common sja1000 isr.
>
> Use the already retrieved status register to indicate a possible hardware
> removal and double check by reading the mode register in sja1000_is_absent.
>
> v2: Create a new function to not print information in irq context.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks for the patch. I'm going to commit it to can-next. Any objections?
Marc
P.S.:
Please make it based on can-next/master next time, it fails to apply due
to Wolfgang's dev_LEVEL -> netdev_LEVEL patch. But it's trivial to
apply, by hand :)
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-17 20:27 ` Marc Kleine-Budde
@ 2012-02-18 14:19 ` Oliver Hartkopp
2012-02-18 17:00 ` Marc Kleine-Budde
2012-02-20 11:02 ` Marc Kleine-Budde
2012-02-18 14:33 ` Wolfgang Grandegger
1 sibling, 2 replies; 24+ messages in thread
From: Oliver Hartkopp @ 2012-02-18 14:19 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can
On 17.02.2012 21:27, Marc Kleine-Budde wrote:
> On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>> hardware can cause an infinite loop in the common sja1000 isr.
>>
>> Use the already retrieved status register to indicate a possible hardware
>> removal and double check by reading the mode register in sja1000_is_absent.
>>
>> v2: Create a new function to not print information in irq context.
>>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Thanks for the patch. I'm going to commit it to can-next. Any objections?
Indeed it should go into stable 3.2 too, as it was the first kernel, where the
EMS PCMCIA driver was integrated.
So putting it into Daves net-tree for 3.3rc fixes and announce it for stable
3.2 seems correct to me.
> P.S.:
> Please make it based on can-next/master next time, it fails to apply due
> to Wolfgang's dev_LEVEL -> netdev_LEVEL patch. But it's trivial to
> apply, by hand :)
The patch was based on the latest 3.3rc3 from Linus's tree, which was my
intention (see above).
Tnx,
Oliver
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-18 14:19 ` Oliver Hartkopp
@ 2012-02-18 17:00 ` Marc Kleine-Budde
2012-02-20 11:02 ` Marc Kleine-Budde
1 sibling, 0 replies; 24+ messages in thread
From: Marc Kleine-Budde @ 2012-02-18 17:00 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
On 02/18/2012 03:19 PM, Oliver Hartkopp wrote:
>> Thanks for the patch. I'm going to commit it to can-next. Any objections?
>
>
> Indeed it should go into stable 3.2 too, as it was the first kernel, where the
> EMS PCMCIA driver was integrated.
>
> So putting it into Daves net-tree for 3.3rc fixes and announce it for stable
> 3.2 seems correct to me.
Ahh, thanks for the info, I wasn't aware of that.
>
>> P.S.:
>> Please make it based on can-next/master next time, it fails to apply due
>
>> to Wolfgang's dev_LEVEL -> netdev_LEVEL patch. But it's trivial to
>> apply, by hand :)
>
>
> The patch was based on the latest 3.3rc3 from Linus's tree, which was my
> intention (see above).
got it :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-18 14:19 ` Oliver Hartkopp
2012-02-18 17:00 ` Marc Kleine-Budde
@ 2012-02-20 11:02 ` Marc Kleine-Budde
2012-02-21 8:07 ` Oliver Hartkopp
1 sibling, 1 reply; 24+ messages in thread
From: Marc Kleine-Budde @ 2012-02-20 11:02 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
On 02/18/2012 03:19 PM, Oliver Hartkopp wrote:
>>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>>> hardware can cause an infinite loop in the common sja1000 isr.
>>>
>>> Use the already retrieved status register to indicate a possible hardware
>>> removal and double check by reading the mode register in sja1000_is_absent.
>>>
>>> v2: Create a new function to not print information in irq context.
>>>
>>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Indeed it should go into stable 3.2 too, as it was the first kernel, where the
> EMS PCMCIA driver was integrated.
I just send it to David, including Cc to stable and Wolfgang's Acked-by.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-20 11:02 ` Marc Kleine-Budde
@ 2012-02-21 8:07 ` Oliver Hartkopp
2012-02-21 9:03 ` Marc Kleine-Budde
0 siblings, 1 reply; 24+ messages in thread
From: Oliver Hartkopp @ 2012-02-21 8:07 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can
On 20.02.2012 12:02, Marc Kleine-Budde wrote:
> On 02/18/2012 03:19 PM, Oliver Hartkopp wrote:
>>>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>>>> hardware can cause an infinite loop in the common sja1000 isr.
>>>>
>>>> Use the already retrieved status register to indicate a possible hardware
>>>> removal and double check by reading the mode register in sja1000_is_absent.
>>>>
>>>> v2: Create a new function to not print information in irq context.
>>>>
>>>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
>> Indeed it should go into stable 3.2 too, as it was the first kernel, where the
>> EMS PCMCIA driver was integrated.
>
> I just send it to David, including Cc to stable and Wolfgang's Acked-by.
Are you sure you sent it CC to stable?
Didn't see that in the mail.
Regards,
Oliver
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-17 20:27 ` Marc Kleine-Budde
2012-02-18 14:19 ` Oliver Hartkopp
@ 2012-02-18 14:33 ` Wolfgang Grandegger
2012-02-18 15:34 ` Oliver Hartkopp
1 sibling, 1 reply; 24+ messages in thread
From: Wolfgang Grandegger @ 2012-02-18 14:33 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Oliver Hartkopp, linux-can
On 02/17/2012 09:27 PM, Marc Kleine-Budde wrote:
> On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>> hardware can cause an infinite loop in the common sja1000 isr.
>>
>> Use the already retrieved status register to indicate a possible hardware
>> removal and double check by reading the mode register in sja1000_is_absent.
>>
>> v2: Create a new function to not print information in irq context.
>>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Thanks for the patch. I'm going to commit it to can-next. Any objections?
Sorry for the late response but what is this double check good for? All
register reads will return 0xff if the card is unplugged. And if the
double check is OK we will continue even we have realized a clear
failure (status was 0xff).
Wolfgang.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-18 14:33 ` Wolfgang Grandegger
@ 2012-02-18 15:34 ` Oliver Hartkopp
2012-02-18 16:44 ` Wolfgang Grandegger
0 siblings, 1 reply; 24+ messages in thread
From: Oliver Hartkopp @ 2012-02-18 15:34 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Marc Kleine-Budde, linux-can
On 18.02.2012 15:33, Wolfgang Grandegger wrote:
> On 02/17/2012 09:27 PM, Marc Kleine-Budde wrote:
>> On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
>>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>>> hardware can cause an infinite loop in the common sja1000 isr.
>>>
>>> Use the already retrieved status register to indicate a possible hardware
>>> removal and double check by reading the mode register in sja1000_is_absent.
>>>
>>> v2: Create a new function to not print information in irq context.
>>>
>>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>
>> Thanks for the patch. I'm going to commit it to can-next. Any objections?
>
> Sorry for the late response but what is this double check good for? All
> register reads will return 0xff if the card is unplugged. And if the
> double check is OK we will continue even we have realized a clear
> failure (status was 0xff).
Hi Wolfgang,
i checked the SJA1000 spec. The status register can potentially hold the value
0xFF by specification. So even when it's not very likely that it holds 0xFF -
it can be. Additionally you may have SJA1000 FPGA cores that do not behave
exactly like the SJA1000 itself.
To double check the unlikely case i do a read on the mode register, which has
some bits definitely set to "0" which is a strong indication for the
controller removal.
Regards,
Oliver
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-18 15:34 ` Oliver Hartkopp
@ 2012-02-18 16:44 ` Wolfgang Grandegger
2012-02-18 17:00 ` Marc Kleine-Budde
0 siblings, 1 reply; 24+ messages in thread
From: Wolfgang Grandegger @ 2012-02-18 16:44 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Marc Kleine-Budde, linux-can
On 02/18/2012 04:34 PM, Oliver Hartkopp wrote:
> On 18.02.2012 15:33, Wolfgang Grandegger wrote:
>
>> On 02/17/2012 09:27 PM, Marc Kleine-Budde wrote:
>>> On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
>>>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>>>> hardware can cause an infinite loop in the common sja1000 isr.
>>>>
>>>> Use the already retrieved status register to indicate a possible hardware
>>>> removal and double check by reading the mode register in sja1000_is_absent.
>>>>
>>>> v2: Create a new function to not print information in irq context.
>>>>
>>>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>>
>>> Thanks for the patch. I'm going to commit it to can-next. Any objections?
>>
>> Sorry for the late response but what is this double check good for? All
>> register reads will return 0xff if the card is unplugged. And if the
>> double check is OK we will continue even we have realized a clear
>> failure (status was 0xff).
>
>
> Hi Wolfgang,
>
> i checked the SJA1000 spec. The status register can potentially hold the value
> 0xFF by specification. So even when it's not very likely that it holds 0xFF -
> it can be. Additionally you may have SJA1000 FPGA cores that do not behave
> exactly like the SJA1000 itself.
>
> To double check the unlikely case i do a read on the mode register, which has
> some bits definitely set to "0" which is a strong indication for the
> controller removal.
OK, no more objections. Hope to find some time soon to test my PCAN PCcard.
Wolfgang.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-18 16:44 ` Wolfgang Grandegger
@ 2012-02-18 17:00 ` Marc Kleine-Budde
2012-02-18 17:13 ` Wolfgang Grandegger
0 siblings, 1 reply; 24+ messages in thread
From: Marc Kleine-Budde @ 2012-02-18 17:00 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Oliver Hartkopp, linux-can
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]
On 02/18/2012 05:44 PM, Wolfgang Grandegger wrote:
> On 02/18/2012 04:34 PM, Oliver Hartkopp wrote:
>> On 18.02.2012 15:33, Wolfgang Grandegger wrote:
>>
>>> On 02/17/2012 09:27 PM, Marc Kleine-Budde wrote:
>>>> On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
>>>>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>>>>> hardware can cause an infinite loop in the common sja1000 isr.
>>>>>
>>>>> Use the already retrieved status register to indicate a possible hardware
>>>>> removal and double check by reading the mode register in sja1000_is_absent.
>>>>>
>>>>> v2: Create a new function to not print information in irq context.
>>>>>
>>>>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>>>
>>>> Thanks for the patch. I'm going to commit it to can-next. Any objections?
>>>
>>> Sorry for the late response but what is this double check good for? All
>>> register reads will return 0xff if the card is unplugged. And if the
>>> double check is OK we will continue even we have realized a clear
>>> failure (status was 0xff).
>>
>>
>> Hi Wolfgang,
>>
>> i checked the SJA1000 spec. The status register can potentially hold the value
>> 0xFF by specification. So even when it's not very likely that it holds 0xFF -
>> it can be. Additionally you may have SJA1000 FPGA cores that do not behave
>> exactly like the SJA1000 itself.
>>
>> To double check the unlikely case i do a read on the mode register, which has
>> some bits definitely set to "0" which is a strong indication for the
>> controller removal.
>
> OK, no more objections. Hope to find some time soon to test my PCAN PCcard.
Can I add your Acked-by to the patch?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2] can: sja1000 fix isr hang when hw is unplugged under load
2012-02-18 17:00 ` Marc Kleine-Budde
@ 2012-02-18 17:13 ` Wolfgang Grandegger
0 siblings, 0 replies; 24+ messages in thread
From: Wolfgang Grandegger @ 2012-02-18 17:13 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Oliver Hartkopp, linux-can
On 02/18/2012 06:00 PM, Marc Kleine-Budde wrote:
> On 02/18/2012 05:44 PM, Wolfgang Grandegger wrote:
>> On 02/18/2012 04:34 PM, Oliver Hartkopp wrote:
>>> On 18.02.2012 15:33, Wolfgang Grandegger wrote:
>>>
>>>> On 02/17/2012 09:27 PM, Marc Kleine-Budde wrote:
>>>>> On 02/15/2012 05:51 PM, Oliver Hartkopp wrote:
>>>>>> In the case of hotplug enabled devices (PCMCIA/PCIeC) the removal of the
>>>>>> hardware can cause an infinite loop in the common sja1000 isr.
>>>>>>
>>>>>> Use the already retrieved status register to indicate a possible hardware
>>>>>> removal and double check by reading the mode register in sja1000_is_absent.
>>>>>>
>>>>>> v2: Create a new function to not print information in irq context.
>>>>>>
>>>>>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>>>>
>>>>> Thanks for the patch. I'm going to commit it to can-next. Any objections?
>>>>
>>>> Sorry for the late response but what is this double check good for? All
>>>> register reads will return 0xff if the card is unplugged. And if the
>>>> double check is OK we will continue even we have realized a clear
>>>> failure (status was 0xff).
>>>
>>>
>>> Hi Wolfgang,
>>>
>>> i checked the SJA1000 spec. The status register can potentially hold the value
>>> 0xFF by specification. So even when it's not very likely that it holds 0xFF -
>>> it can be. Additionally you may have SJA1000 FPGA cores that do not behave
>>> exactly like the SJA1000 itself.
>>>
>>> To double check the unlikely case i do a read on the mode register, which has
>>> some bits definitely set to "0" which is a strong indication for the
>>> controller removal.
>>
>> OK, no more objections. Hope to find some time soon to test my PCAN PCcard.
>
> Can I add your Acked-by to the patch?
Yes. I do not expect any more problems.
Wolfgang.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] iwlwifi: fix unused variable warning
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
` (3 preceding siblings ...)
2012-02-15 16:51 ` [PATCH v2] " Oliver Hartkopp
@ 2012-03-25 6:43 ` Oliver Hartkopp
2012-03-26 1:49 ` Guy, Wey-Yi
2012-04-03 19:56 ` [PATCH RFC] can: add hash table for single EFF id filter list Oliver Hartkopp
2012-05-08 20:20 ` [PATCH] can: update documentation wording error frames -> error messages Oliver Hartkopp
6 siblings, 1 reply; 24+ messages in thread
From: Oliver Hartkopp @ 2012-03-25 6:43 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Wey-Yi Guy, Intel Linux Wireless
In the case of disabled CONFIG_IWLWIFI_DEBUGFS option the compiler complains
about the unused variable 'img'. Fix this by moving the 'img' definition.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/drivers/net/wireless/iwlwifi/iwl-mac80211.c b/drivers/net/wireless/iwlwifi/iwl-mac80211.c
index b6805f8..0f5db8b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-mac80211.c
+++ b/drivers/net/wireless/iwlwifi/iwl-mac80211.c
@@ -437,7 +437,6 @@ static int iwlagn_mac_resume(struct ieee80211_hw *hw)
unsigned long flags;
u32 base, status = 0xffffffff;
int ret = -EIO;
- const struct fw_img *img;
IWL_DEBUG_MAC80211(priv, "enter\n");
mutex_lock(&priv->mutex);
@@ -458,6 +457,8 @@ static int iwlagn_mac_resume(struct ieee80211_hw *hw)
#ifdef CONFIG_IWLWIFI_DEBUGFS
if (ret == 0) {
+ const struct fw_img *img;
+
img = &(priv->fw->img[IWL_UCODE_WOWLAN]);
if (!priv->wowlan_sram) {
priv->wowlan_sram =
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH RFC] can: add hash table for single EFF id filter list
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
` (4 preceding siblings ...)
2012-03-25 6:43 ` [PATCH] iwlwifi: fix unused variable warning Oliver Hartkopp
@ 2012-04-03 19:56 ` Oliver Hartkopp
2012-05-08 20:20 ` [PATCH] can: update documentation wording error frames -> error messages Oliver Hartkopp
6 siblings, 0 replies; 24+ messages in thread
From: Oliver Hartkopp @ 2012-04-03 19:56 UTC (permalink / raw)
To: linux-can@vger.kernel.org
To reduce the linear traversal in one linked list of _single_ EFF CAN
frame subscriptions the 29 bit identifier is hashed to 10 bits.
The hash function maps the three sections of the 29 bit can_id via XOR which
produces uniformly distributed entries in a 10 bit array of hlists.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
Hi all,
this idea was in my mind for a long time now. The question is:
Are single EFF id subscriptions used widely in real-world use cases?
Of course this hash table approach adds a list of 1024 pointers to the struct
which is attached to each CAN netdevice. But when single EFF id subscriptions
are used, the filter is performed with heavily reduced cpu load at runtime.
Any thoughts and/or feedback?
Tnx,
Oliver
diff --git a/net/can/af_can.c b/net/can/af_can.c
index 0ce2ad0..df32073 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -316,6 +316,28 @@ static struct dev_rcv_lists *find_dev_rcv_lists(struct net_device *dev)
}
/**
+ * effhash - hash function for 29 bit CAN identifier reduction
+ * @can_id: 29 bit CAN identifier
+ *
+ * Description:
+ * To reduce the linear traversal in one linked list of _single_ EFF CAN
+ * frame subscriptions the 29 bit identifier is mapped to 10 bits.
+ *
+ * Return:
+ * Hash value from 0x000 - 0x3FF
+ */
+static unsigned int effhash(canid_t can_id)
+{
+ unsigned int hash;
+
+ hash = (can_id>>20) & 0x3FF;
+ hash ^= (can_id>>10) & 0x3FF;
+ hash ^= can_id & 0x3FF;
+
+ return hash;
+}
+
+/**
* find_rcv_list - determine optimal filterlist inside device filter struct
* @can_id: pointer to CAN identifier of a given can_filter
* @mask: pointer to CAN mask of a given can_filter
@@ -378,10 +400,8 @@ static struct hlist_head *find_rcv_list(canid_t *can_id, canid_t *mask,
!(*can_id & CAN_RTR_FLAG)) {
if (*can_id & CAN_EFF_FLAG) {
- if (*mask == (CAN_EFF_MASK | CAN_EFF_RTR_FLAGS)) {
- /* RFC: a future use-case for hash-tables? */
- return &d->rx[RX_EFF];
- }
+ if (*mask == (CAN_EFF_MASK | CAN_EFF_RTR_FLAGS))
+ return &d->rx_eff[effhash(*can_id)];
} else {
if (*mask == (CAN_SFF_MASK | CAN_EFF_RTR_FLAGS))
return &d->rx_sff[*can_id];
@@ -615,7 +635,7 @@ static int can_rcv_filter(struct dev_rcv_lists *d, struct sk_buff *skb)
return matches;
if (can_id & CAN_EFF_FLAG) {
- hlist_for_each_entry_rcu(r, n, &d->rx[RX_EFF], list) {
+ hlist_for_each_entry_rcu(r, n, &d->rx_eff[effhash(can_id)], list) {
if (r->can_id == can_id) {
deliver(skb, r);
matches++;
diff --git a/net/can/af_can.h b/net/can/af_can.h
index fd882db..3631399 100644
--- a/net/can/af_can.h
+++ b/net/can/af_can.h
@@ -59,12 +59,13 @@ struct receiver {
char *ident;
};
-enum { RX_ERR, RX_ALL, RX_FIL, RX_INV, RX_EFF, RX_MAX };
+enum { RX_ERR, RX_ALL, RX_FIL, RX_INV, RX_MAX };
/* per device receive filters linked at dev->ml_priv */
struct dev_rcv_lists {
struct hlist_head rx[RX_MAX];
struct hlist_head rx_sff[0x800];
+ struct hlist_head rx_eff[0x400];
int remove_on_zero_entries;
int entries;
};
diff --git a/net/can/proc.c b/net/can/proc.c
index ba873c3..419d349 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c
@@ -80,7 +80,6 @@ static const char rx_list_name[][8] = {
[RX_ALL] = "rx_all",
[RX_FIL] = "rx_fil",
[RX_INV] = "rx_inv",
- [RX_EFF] = "rx_eff",
};
/* receive filters subscribed for 'all' CAN devices */
@@ -456,6 +455,69 @@ static const struct file_operations can_rcvlist_sff_proc_fops = {
.release = single_release,
};
+static inline void can_rcvlist_eff_proc_show_one(struct seq_file *m,
+ struct net_device *dev,
+ struct dev_rcv_lists *d)
+{
+ int i;
+ int all_empty = 1;
+
+ /* check wether at least one list is non-empty */
+ for (i = 0; i < 0x400; i++)
+ if (!hlist_empty(&d->rx_eff[i])) {
+ all_empty = 0;
+ break;
+ }
+
+ if (!all_empty) {
+ can_print_recv_banner(m);
+ for (i = 0; i < 0x400; i++) {
+ if (!hlist_empty(&d->rx_eff[i]))
+ can_print_rcvlist(m, &d->rx_eff[i], dev);
+ }
+ } else
+ seq_printf(m, " (%s: no entry)\n", DNAME(dev));
+}
+
+static int can_rcvlist_eff_proc_show(struct seq_file *m, void *v)
+{
+ struct net_device *dev;
+ struct dev_rcv_lists *d;
+
+ /* RX_EFF */
+ seq_puts(m, "\nreceive list 'rx_eff':\n");
+
+ rcu_read_lock();
+
+ /* eff receive list for 'all' CAN devices (dev == NULL) */
+ d = &can_rx_alldev_list;
+ can_rcvlist_eff_proc_show_one(m, NULL, d);
+
+ /* eff receive list for registered CAN devices */
+ for_each_netdev_rcu(&init_net, dev) {
+ if (dev->type == ARPHRD_CAN && dev->ml_priv)
+ can_rcvlist_eff_proc_show_one(m, dev, dev->ml_priv);
+ }
+
+ rcu_read_unlock();
+
+ seq_putc(m, '\n');
+ return 0;
+}
+
+static int can_rcvlist_eff_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, can_rcvlist_eff_proc_show, NULL);
+}
+
+static const struct file_operations can_rcvlist_eff_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = can_rcvlist_eff_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
/*
* proc utility functions
*/
@@ -495,8 +557,8 @@ void can_init_proc(void)
&can_rcvlist_proc_fops, (void *)RX_FIL);
pde_rcvlist_inv = proc_create_data(CAN_PROC_RCVLIST_INV, 0644, can_dir,
&can_rcvlist_proc_fops, (void *)RX_INV);
- pde_rcvlist_eff = proc_create_data(CAN_PROC_RCVLIST_EFF, 0644, can_dir,
- &can_rcvlist_proc_fops, (void *)RX_EFF);
+ pde_rcvlist_eff = proc_create(CAN_PROC_RCVLIST_EFF, 0644, can_dir,
+ &can_rcvlist_eff_proc_fops);
pde_rcvlist_sff = proc_create(CAN_PROC_RCVLIST_SFF, 0644, can_dir,
&can_rcvlist_sff_proc_fops);
}
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH] can: update documentation wording error frames -> error messages
2011-10-13 11:42 [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org Marc Kleine-Budde
` (5 preceding siblings ...)
2012-04-03 19:56 ` [PATCH RFC] can: add hash table for single EFF id filter list Oliver Hartkopp
@ 2012-05-08 20:20 ` Oliver Hartkopp
2012-05-08 20:38 ` Marc Kleine-Budde
6 siblings, 1 reply; 24+ messages in thread
From: Oliver Hartkopp @ 2012-05-08 20:20 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can@vger.kernel.org, Heinz-Jürgen Oertel
As Heinz-Juergen Oertel pointed out 'CAN error frames' are a already defined
term for the CAN protocol violation indication on the wire.
To avoid confusion with the error messages created by CAN drivers available
via CAN RAW sockets update the documentation and change the naming from
'error frames' to 'error messages' or 'error message frames'.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 56ca3b7..28d9b14 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -232,16 +232,16 @@ solution for a couple of reasons:
arbitration problems and error frames caused by the different
ECUs. The occurrence of detected errors are important for diagnosis
and have to be logged together with the exact timestamp. For this
- reason the CAN interface driver can generate so called Error Frames
- that can optionally be passed to the user application in the same
- way as other CAN frames. Whenever an error on the physical layer
+ reason the CAN interface driver can generate so called Error Message
+ Frames that can optionally be passed to the user application in the
+ same way as other CAN frames. Whenever an error on the physical layer
or the MAC layer is detected (e.g. by the CAN controller) the driver
- creates an appropriate error frame. Error frames can be requested by
- the user application using the common CAN filter mechanisms. Inside
- this filter definition the (interested) type of errors may be
- selected. The reception of error frames is disabled by default.
- The format of the CAN error frame is briefly described in the Linux
- header file "include/linux/can/error.h".
+ creates an appropriate error message frame. Error messages frames can
+ be requested by the user application using the common CAN filter
+ mechanisms. Inside this filter definition the (interested) type of
+ errors may be selected. The reception of error messages is disabled
+ by default. The format of the CAN error message frame is briefly
+ described in the Linux header file "include/linux/can/error.h".
4. How to use Socket CAN
------------------------
@@ -383,7 +383,7 @@ solution for a couple of reasons:
defaults are set at RAW socket binding time:
- The filters are set to exactly one filter receiving everything
- - The socket only receives valid data frames (=> no error frames)
+ - The socket only receives valid data frames (=> no error message frames)
- The loopback of sent CAN frames is enabled (see chapter 3.2)
- The socket does not receive its own sent frames (in loopback mode)
@@ -434,7 +434,7 @@ solution for a couple of reasons:
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
As described in chapter 3.4 the CAN interface driver can generate so
- called Error Frames that can optionally be passed to the user
+ called Error Message Frames that can optionally be passed to the user
application in the same way as other CAN frames. The possible
errors are divided into different error classes that may be filtered
using the appropriate error mask. To register for every possible
@@ -527,7 +527,7 @@ solution for a couple of reasons:
rcvlist_all - list for unfiltered entries (no filter operations)
rcvlist_eff - list for single extended frame (EFF) entries
- rcvlist_err - list for error frames masks
+ rcvlist_err - list for error message frames masks
rcvlist_fil - list for mask/value filters
rcvlist_inv - list for mask/value filters (inverse semantic)
rcvlist_sff - list for single standard frame (SFF) entries
@@ -784,13 +784,13 @@ solution for a couple of reasons:
$ ip link set canX type can restart-ms 100
Alternatively, the application may realize the "bus-off" condition
- by monitoring CAN error frames and do a restart when appropriate with
- the command:
+ by monitoring CAN error message frames and do a restart when
+ appropriate with the command:
$ ip link set canX type can restart
- Note that a restart will also create a CAN error frame (see also
- chapter 3.4).
+ Note that a restart will also create a CAN error message frame (see
+ also chapter 3.4).
6.6 Supported CAN hardware
diff --git a/include/linux/can.h b/include/linux/can.h
index 9a19bcb..17334c0 100644
--- a/include/linux/can.h
+++ b/include/linux/can.h
@@ -21,7 +21,7 @@
/* special address description flags for the CAN_ID */
#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */
#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */
-#define CAN_ERR_FLAG 0x20000000U /* error frame */
+#define CAN_ERR_FLAG 0x20000000U /* error message frame */
/* valid bits in CAN ID for frame formats */
#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */
@@ -32,14 +32,14 @@
* Controller Area Network Identifier structure
*
* bit 0-28 : CAN identifier (11/29 bit)
- * bit 29 : error frame flag (0 = data frame, 1 = error frame)
+ * bit 29 : error message frame flag (0 = data frame, 1 = error message)
* bit 30 : remote transmission request flag (1 = rtr frame)
* bit 31 : frame format flag (0 = standard 11 bit, 1 = extended 29 bit)
*/
typedef __u32 canid_t;
/*
- * Controller Area Network Error Frame Mask structure
+ * Controller Area Network Error Message Frame Mask structure
*
* bit 0-28 : error class mask (see include/linux/can/error.h)
* bit 29-31 : set to zero
@@ -97,7 +97,7 @@ struct sockaddr_can {
* <received_can_id> & mask == can_id & mask
*
* The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
- * filter for error frames (CAN_ERR_FLAG bit set in mask).
+ * filter for error message frames (CAN_ERR_FLAG bit set in mask).
*/
struct can_filter {
canid_t can_id;
diff --git a/include/linux/can/error.h b/include/linux/can/error.h
index 63e855e..7b7148b 100644
--- a/include/linux/can/error.h
+++ b/include/linux/can/error.h
@@ -1,7 +1,7 @@
/*
* linux/can/error.h
*
- * Definitions of the CAN error frame to be filtered and passed to the user.
+ * Definitions of the CAN error messages to be filtered and passed to the user.
*
* Author: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
@@ -12,7 +12,7 @@
#ifndef CAN_ERROR_H
#define CAN_ERROR_H
-#define CAN_ERR_DLC 8 /* dlc for error frames */
+#define CAN_ERR_DLC 8 /* dlc for error message frames */
/* error class (mask) in can_id */
#define CAN_ERR_TX_TIMEOUT 0x00000001U /* TX timeout (by netdevice driver) */
diff --git a/net/can/af_can.c b/net/can/af_can.c
index 0ce2ad0..6efcd37 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -334,8 +334,8 @@ static struct dev_rcv_lists *find_dev_rcv_lists(struct net_device *dev)
* relevant bits for the filter.
*
* The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
- * filter for error frames (CAN_ERR_FLAG bit set in mask). For error frames
- * there is a special filterlist and a special rx path filter handling.
+ * filter for error messages (CAN_ERR_FLAG bit set in mask). For error msg
+ * frames there is a special filterlist and a special rx path filter handling.
*
* Return:
* Pointer to optimal filterlist for the given can_id/mask pair.
@@ -347,7 +347,7 @@ static struct hlist_head *find_rcv_list(canid_t *can_id, canid_t *mask,
{
canid_t inv = *can_id & CAN_INV_FILTER; /* save flag before masking */
- /* filter for error frames in extra filterlist */
+ /* filter for error message frames in extra filterlist */
if (*mask & CAN_ERR_FLAG) {
/* clear CAN_ERR_FLAG in filter entry */
*mask &= CAN_ERR_MASK;
@@ -408,7 +408,7 @@ static struct hlist_head *find_rcv_list(canid_t *can_id, canid_t *mask,
* <received_can_id> & mask == can_id & mask
*
* The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
- * filter for error frames (CAN_ERR_FLAG bit set in mask).
+ * filter for error message frames (CAN_ERR_FLAG bit set in mask).
*
* The provided pointer to the sk_buff is guaranteed to be valid as long as
* the callback function is running. The callback function must *not* free
@@ -578,7 +578,7 @@ static int can_rcv_filter(struct dev_rcv_lists *d, struct sk_buff *skb)
return 0;
if (can_id & CAN_ERR_FLAG) {
- /* check for error frame entries only */
+ /* check for error message frame entries only */
hlist_for_each_entry_rcu(r, n, &d->rx[RX_ERR], list) {
if (can_id & r->mask) {
deliver(skb, r);
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH] can: update documentation wording error frames -> error messages
2012-05-08 20:20 ` [PATCH] can: update documentation wording error frames -> error messages Oliver Hartkopp
@ 2012-05-08 20:38 ` Marc Kleine-Budde
2012-05-09 17:09 ` Heinz-Jürgen Oertel
0 siblings, 1 reply; 24+ messages in thread
From: Marc Kleine-Budde @ 2012-05-08 20:38 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-can@vger.kernel.org, Heinz-Jürgen Oertel
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On 05/08/2012 10:20 PM, Oliver Hartkopp wrote:
> As Heinz-Juergen Oertel pointed out 'CAN error frames' are a already defined
> term for the CAN protocol violation indication on the wire.
>
> To avoid confusion with the error messages created by CAN drivers available
> via CAN RAW sockets update the documentation and change the naming from
> 'error frames' to 'error messages' or 'error message frames'.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Sounds reasonable. Heinz-Jürgen, can I add your Acked-by: to this patch?
It means that you've read the patch and think this is a good change.
Marc
P.S.: Oliver, try to use: "git send-email", it much easier for you to
send patches than to copy/paste it to thunderbird.
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] can: update documentation wording error frames -> error messages
2012-05-08 20:38 ` Marc Kleine-Budde
@ 2012-05-09 17:09 ` Heinz-Jürgen Oertel
0 siblings, 0 replies; 24+ messages in thread
From: Heinz-Jürgen Oertel @ 2012-05-09 17:09 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Oliver Hartkopp, linux-can@vger.kernel.org
Hello,
I can not check before Saturday. Sorry.
Heinz
Heinz-Jürgen Oertel
Am 08.05.2012 um 22:38 schrieb "Marc Kleine-Budde" <mkl@pengutronix.de>:
> On 05/08/2012 10:20 PM, Oliver Hartkopp wrote:
>> As Heinz-Juergen Oertel pointed out 'CAN error frames' are a already defined
>> term for the CAN protocol violation indication on the wire.
>>
>> To avoid confusion with the error messages created by CAN drivers available
>> via CAN RAW sockets update the documentation and change the naming from
>> 'error frames' to 'error messages' or 'error message frames'.
>>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Sounds reasonable. Heinz-Jürgen, can I add your Acked-by: to this patch?
> It means that you've read the patch and think this is a good change.
>
> Marc
>
> P.S.: Oliver, try to use: "git send-email", it much easier for you to
> send patches than to copy/paste it to thunderbird.
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
^ permalink raw reply [flat|nested] 24+ messages in thread