Oliver Neukum <oliver@xxxxxxxxxx> writes:
> Am Montag, 27. Februar 2012, 14:58:59 schrieb Bjørn Mork:
>> Oliver Neukum <oliver@xxxxxxxxxx> writes:
>>
>> > strictly speaking atomic variables must be initialized. One cannot depend
>> > on a binary 0 meaning that an atomic ariable is 0 and ready to use.
>>
>> OK, so should I integrate something like this in the patch and resubmit,
>> this time including netdev in the discussions? :
>
> The absolutely correct way is to use ATOMIC_INIT as described in
> Documentation/atomic_ops.txt
Really? That is only suitable for a declaration, isn't it? Quoting
from Documentation/atomic_ops.txt:
"The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };
...
struct foo *k;
k = kmalloc(sizeof(*k), GFP_KERNEL);
if (!k)
return -ENOMEM;
atomic_set(&k->counter, 0);
"
> And yes, please repost to netdev
Yup, will do as soon as I have cleaned up and rebased the latest changes.
> [..]
>> Maybe also include all the known Gobi devices in the ID list? Or is that
>> too risky? People may be using the out-of-tree Gobi driver and this
>> will never be fully compatible with userspace for that one. They can of
>> course blacklist this driver if they want to, but still..
>
> Generally, if somebody maintains a driver out of the kernel tree, they
> are on their own. Including all IDs improves the kernel by supporting
> more devices, so go for it :-)
Good. Will do. This should broaden the driver scope enough to create a
demand for userspace applications. Which is necessary to make this fly
at all.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
