Hi Alexandre,
On 05/16/2017 01:00 AM, Alexandre Belloni wrote:
Hi,
On 15/05/2017 at 20:51:30 -0700, Oliver Hartkopp wrote:
On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:
Looks good, added to linux-can-next.
Isn't this a fix for linux-can instead?
At least it would make no sense to me to
Hi,
On 15/05/2017 at 20:51:30 -0700, Oliver Hartkopp wrote:
> On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:
> > On 05/12/2017 08:37 AM, Quentin Schulz wrote:
> > > On 05/05/2017 15:50, Quentin Schulz wrote:
> > > > To avoid possible ECC/parity checksum errors when reading an
> > > > uninitializ
On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:
On 05/12/2017 08:37 AM, Quentin Schulz wrote:
Hi all,
On 05/05/2017 15:50, Quentin Schulz wrote:
To avoid possible ECC/parity checksum errors when reading an
uninitialized buffer, the entire Message RAM is initialized when probing
the driver.
On 05/12/2017 08:37 AM, Quentin Schulz wrote:
> Hi all,
>
> On 05/05/2017 15:50, Quentin Schulz wrote:
>> To avoid possible ECC/parity checksum errors when reading an
>> uninitialized buffer, the entire Message RAM is initialized when probing
>> the driver. This initialization is done in the same
Hi all,
On 05/05/2017 15:50, Quentin Schulz wrote:
> To avoid possible ECC/parity checksum errors when reading an
> uninitialized buffer, the entire Message RAM is initialized when probing
> the driver. This initialization is done in the same function reading the
> Device Tree properties.
>
> Thi
To avoid possible ECC/parity checksum errors when reading an
uninitialized buffer, the entire Message RAM is initialized when probing
the driver. This initialization is done in the same function reading the
Device Tree properties.
This patch moves the RAM initialization to a separate function so i
