Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527

[Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>]

Hi Wolfgang,

On 01/05/2012 04:29 AM, Wolfgang Zarre wrote:
> Hello Wolfgang,
> 
>> Hi Wolfgang,
...
>>> diff --git a/drivers/net/can/cc770/cc770_isa.c
>>> b/drivers/net/can/cc770/cc770_isa.c
>>> index 4be5fe2..48fc128 100644
>>> --- a/drivers/net/can/cc770/cc770_isa.c
>>> +++ b/drivers/net/can/cc770/cc770_isa.c
>>> @@ -148,8 +148,7 @@ static void cc770_isa_port_write_reg_indirect(const
>>> struct cc770_priv *priv,
>>>   {
>>>       unsigned long base = (unsigned long)priv->reg_base;
>>>
>>> -    outb(reg, base);
>>> -    outb(val, base + 1);
>>> +    outw( reg + ( val<<  8), base);
>>
>> That modification does fix your problem, right? The others above don't
>> help nor harm but we don't know if it's really realted to the same
>> problem. I wll dig a bit deeper.
> 
> Exactly. The others above I removed because facing the opposite, even
> missing interrupts but then just to avoid other possible side effects
> and then assuming that they might be related.

OK. My concern: Can we be sure that 16bit accesses are always supported
by the hardware? Does a spinlock_irqsave/spinlock_irqrestore around the
8bit accesses already help?

About the "HM:" fixes, I did not find any info in the svn log. Maybe
Oliver knows why they have been added.

>>
>>>   }
>>>
>>>   static int __devinit cc770_isa_probe(struct platform_device *pdev)
>>>
>>> ---------------------------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> Please let me know if this is OK for You, maybe You can do some tests as
>>> well.
>>
>> My board does not use indirect accesses.
>>
> 
> Ah Ok, I see, but let me know if I may help with additional tests You would
> like to have beside the other mentioned tests as long as I have the
> hardware.

I will do some test anyway.

>>> Would continue then with further tests regarding error conditions,
>>> however
>>> I realised another small issue with dropped packages at reception.
>>>
>>> As soon as You read the first time from the socket and then You stop
>>> reading
>>> the packages are not counted as 'dropped' any more which is IMHO not
>>> correct
>>> because as soon as You stop reading they should be counted as dropped
>>> again.
>>
>> Will have a closer look now...
> 
> Thanks a lot.
> Also I'll inform You as soon as I can continue with some further tests
> regarding bus states and error counters and maybe also with patches in
> case I have.

No hurry... I'm first awaiting some patches to go mainline.

Wolfgang.