Re: [alsa-devel] [RFC] ucb1400 touchscreen, irq auto probing and ac97 with its private field

[Sebastian Siewior <al+sa@ml.breakpoint.cc>]

* Takashi Iwai | 2008-04-25 13:10:31 [+0200]:

>> Why is it a problem to keep an anonymous struct?
>
>You describe in your text below :)
Right :D

>> If some one uses a
>> wrong struct than it crashes immediatelly or bails out because
>> 0x20495251 is way too large be an IRQ. Putting that magic and casting
>> for every single possible data blows code for no good reason. Don't
>> recover from errors which should not have happen, solve them at root
>> level not where the leaves are.
>
>The root level of the problem is that you pass the anonymous data.
>It _IS_ unsafe and wrong unless handled properly.
Yes and this should not happen in my perfect world :)

>
>> What I intended in first place is to allocate a private field in the bus
>> struct so can pass informations to the lower driver.
>
>As mentioned in my earlier mail, I'm fine with your first patch.  The
>problem occurs when we generalize it.
Generalize? You mean once you need an array of multiple parameters like
struct ressource where the controler driver and device driver are
independent and don't know each other? In this case I understand why you
prefered the int irq over the void pointer.

>> If you need
>> multiple arguments, create your own struct put it in the void * slot,
>> your driver knows what to do.
>
>Your driver does _not_ know what type it is because the data isn't
>created by your driver but the controller driver.  And, it's free to
>attach your driver to any controller.
Sure. But why should the controller attach data that is not desired for
the driver chip? So if the ucb1400 gets probed with private data that is
desired for another driver it will bail out after checking the device
id and nothing happens. In my case the controller knows that there is
ucb1400 touchscreen attached and I can't imagine why the controller
shouldn't know.

>thanks,
>
>Takashi

Sebastian