IRQ handling

There are 2 common principles how to get known about new data in card.
1) asynchronous – whenever the devices get data, it will interrupt line and will get know it in your ISR. Smarter devices support irq mitigation, which more or less means deferred interrupts unless there are more data or timeout elapsed – this is especially common in network devices, where interrupt overhead would be large on high speeds.
2) "synchronously" by timer – you setup a timer and "poll" the device even in the case, there are no data (you simply reschedule the timer). This is mostly useful for devices which generates interrupts at high rates, but do not support irq mitigation. Beside this, you may use this approach in the case you don't want (or must not – e.g. netconsole with data in opposite way) enable interrupts.

But when you enable interrupts, you must handle them, even if you don't want to do anything but returning IRQ_HANDLED in ISR (interrupt servicing routine – the function you register in request_irq).

Note that if you request shared interrupt, you also need to check, if the device really raised the interrupt you are handling.

Comments are mostly a bad idea

As I was saying ever before, comments are unneeded unless you write something not obvious, for example resetting a device in a place, where nobody would expect it. Then yes, comment is necessary to disallow everybody removing the code that is requisite.

The other case of using comments is documenting API. Everybody wants to know, what the function does without reading whole body and studying the code.

But for God's sake, don't try to comment each line of code explaining what it does if it's obvious or even worse how it does. If it seems to you, that the code is pretty unclear in the meaning what it does, do it better and don't vindicate it by long comments. This is often a very bad idea and makes the code totally unreadable and ugly. Beginners often do this, I saw a code that seemed something like this:

function min(a, b)
{
  /* compute minimum by comparing both values and */
  /* store the one, which is less than the other into */
  /* result variable, which will be finally returned */ 
  if (a < b)
    result = a
  else
    result = b
  
  /* and now, return the computed value */
  return result
}

Please, don't do that ;), at least don't do that where you are working in team, when other people will work on the same code either in parallel with you or after you leave the project.

Final quotation of Martin Fowler about Refactoring:

Comments are often a sign of unclear code... consider refactoring