Re: [PATCH] SPI

[David Brownell <david-b@pacbell.net>]

> >>>It'd be fine if for example your PNX controller driver worked that way
> >>>internally.  But other drivers shouldn't be forced to allocate kernel
> >>>threads when they don't need them.
> ...
> FYI in brief: for PREEMPT_RT case all the interrupt handlers are working 
> in a separate thread each unless explicitly specified otherwise.

I'm fully aware of that; not that it matters much for folk who aren't
building and deploying systems with PREEMPT_RT.


> We will definitely have less SPI busses => less kernel threads, so I 
> doubt there's a rationale in your opinion.

The rationale is simple:  you're trying to force one implementation
strategy.  Needlessly forcing one strategy, even when others may be
better (I already gave three examples), is a bad idea.  QED.  :)


> >Well "prevent" may be a bit strong, if you like hopping levels in
> >the software stack.  I don't; without such hopping (or without a
> >separate out-of-band mechanism like device tables), I don't see
> >a way to solve that problem.
>
> Aren't the tables you're suggesting also kinda out-of-band stuff?

I just described them that way; yes.  They're not layer hopping though;
they preserve the distinctions in roles and responsibilities which help
keep components from interfering with each other.

One general point is that when hardware doesn't support autoconfiguration,
something out-of-band is required to plug that hole.  In this case,
those tables can be segmented to handle SPI devices on both mainboards
and add-on boards.  Ditto for SPI controllers, but that mostly matters
for developer tools like parport adapters.

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/