Writing driver for a net device which does not support interrupt

[freeman.zhang1992@gmail.com (Freeman Zhang)]

Hi Valdis,

Thanks for your warning. I feel like I believe in my group and those
engineers. In fact, implementing interrupts is part of the plan, but,
yes, the prototype is really buggy.... However they are trying hard to
fix it, and I should not stand by just to watch, waiting for the
deadline, should I?

Anyway, this is a serious project. This work need to be done. And I just
figured out something that might solve the current problem and might be
easily modifid when hardware interrupt is available. I think I could use
soft interrupt to active NAPI polling, so that I can use existing
infrastructure, as what 'snull' does. What do you think?


Thanks again!
Freeman

-------- Original Message --------
> On Mon, 23 Mar 2015 18:51:51 +0800, Freeman Zhang said:
>> I'm writing a net device driver for my final project in college. But the
>> half-finished device doesn't support interrupt yet(those hardware guys...)
>>
>> So I'm wondering if there is some way to poll the device for its status
>> and events.
> 
> As a realistic datapoint - if it still doesn't support interrupts, the *rest*
> of it is probably still so buggy that trying to write a driver isn't worth
> the effort.
> 
> It's doable if you are working with a group of talented and experienced
> engineers - but if the hardware is also being done as a final project,
> you're in for naught but misery.
> 
> You *could* do something like this:
> 
>       while (waiting) {
>           status = read_status_bits(your_device);
>           if (status & DATA_AVAIL_MASK) break;
>           msleep(100);
>       }
> 
> But having seen enough student hardware design projects in my life, I estimate
> that if it still can't signal interrupts, the status bits probably aren't valid
> either. (Think about it - a bog-simple implementation of interrupts would be
> to just feed a transition-high on the appropriate status bit to the interrupt
> pin, and use a read from the chip to clear the pin).
> 
> Good luck - I suspect you're going to need it....
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150324/db9d6838/attachment.bin