> Zeroing can be found easily - the whole structure is NULL pointer, 
> and will always panic if accessed(from running superio code), 
> but redzoning is only happen on borders,
> and can catch writes over the boards, which is rarely in this case.

As I mentioned the redzoning was a brainfar on my side.  Slab debug
code memsets all code with an easily recognizable pattern (which 0 is _NOT_).

So this is totally useless, please don't do it - as all major subsystems
don't do it either.

> Each superio chip is registered with superio core without any devices.
> Each logical device is registered with superio core without any superio
> chip.
> 
> Then core checks if some chip is found in some superio device, and
> links 
> it to appropriate device.
> So if board has several superio chips(like soekris board) and several
> logical devices in it, then we only have 2 superio small drivers, and
> several 
> logical device drivers, but not
> number_of_superio_chips*number_of_logical_devices drivers.

That's how just about any bus driver works so far.

Now somewhere else in the thread I read the a single logical device
might belong to multiple superio devices.  Which is kinda odd, but in
that case it's indeed needed.

So please add a big comment explaining that properperty because it
is extemly uncommon, and make 'ptr' in the chain structure typed
instead of void *

> Yes, and it is better than removing module whose structures are in use.
> SuperIO core is asynchronous in it's nature, one can use logical device 
> through superio core and remove it's module on other CPU, above loop
> will
> wait untill all reference counters are dropped.

General rule is: increment module reference count while the hardware
is actually in use, and let device structures be allocated by the
bus core so drivers can be freed with them still allocated.  That's
how the driver model and thus about every other subsystem works.

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

Reply via email to