Re: [PATCH 3/3] can: at91_can: make can_id of mailbox 0 configurable
From: Wolfgang Grandegger <hidden>
Date: 2011-01-11 12:27:45
On 01/11/2011 12:56 PM, Marc Kleine-Budde wrote:
On 01/11/2011 12:45 PM, Wolfgang Grandegger wrote:quoted
On 01/11/2011 11:28 AM, Marc Kleine-Budde wrote:quoted
Due to a chip bug (errata 50.2.6.3 & 50.3.5.3 in "AT91SAM9263 Preliminary 6249H-ATARM-27-Jul-09") the contents of mailbox 0 may be send under certain conditions (even if disabled or in rx mode). The workaround in the errata suggests not to use the mailbox and load it with a unused identifier. This patch implements the second part of the workaround. A sysfs entry "mb0_id" is introduced. While the interface is down it can be used to configure the can_id of mailbox 0. The default value id 0x7ff. In order to use an extended can_id add the CAN_EFF_FLAG (0x80000000U) to the can_id. Example: - standard id 0x7ff: echo 0x7ff > /sys/class/net/can0/mb0_id - extended if 0x1fffffff:^^ I've fixed the typo on my git repo. I'll send an updated series later.quoted
quoted
echo 0x9fffffff > /sys/class/net/can0/mb0_idAs this is a device specific property, I think it should go into /sys/class/net/can0/device/.The attribute goes autoamtically to /sys/class/net/can0 if you add it to the driver via: + dev->sysfs_groups[0] = &at91_sysfs_attr_group; I've copied this from the janz-ican3 driver[1].
Oh, I missed that. And also the Softing driver does it that way :-(. The member has the comment: /* space for optional device, statistics, and wireless sysfs groups */ const struct attribute_group *sysfs_groups[4]; Therefore it seems to be legal to use it for device specific properties. Wolfgang.