On 04/12/2018 01:24 PM, Jonathan Cameron wrote: > On Wed, 11 Apr 2018 20:41:30 -0700 > Matt Ranostay <matt.ranostay@xxxxxxxxxxxx> wrote: > >> On Wed, Apr 11, 2018 at 1:36 AM, Gaëtan Carlier <gcembed@xxxxxxxxx> wrote: >>> On 04/11/2018 05:37 AM, Matt Ranostay wrote: >>>> On Tue, Apr 10, 2018 at 1:57 AM, Gaëtan Carlier <gcembed@xxxxxxxxx> wrote: >>>>> Hello, >>>>> Thank you for your reply. >>>>> >>>>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>>>> On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@xxxxxxxxx> wrote: >>>>>>> Hello, >>>>>>> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >>>>>> >>>>>> Question here is why is this ideal for iio versus using the input subsystem? >>>>> What can I send to userspace from a bitstream using Input subsystem ? >>>>> Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... >>>>> My idea is to send a structure with >>>>> * number of bits read >>>>> * if two parity bits are valid >>>>> * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. >>>>> >>>>> I already start writting driver based on humidity/dht11.c that uses similar timings. >>>> >>>> Another question is what would your struct iio_chan_spec definition >>>> look like? Namely the .type assignments >>>> >>> For now, I did not have define any channels and num_channels in struct iio_dev in probe function. >>> That is what I have to investigate today : study how buffers work for IIO subsystem. >>> The idea is to have a blocking call from the userspace and every time a card is read, the buffer is filled and pushed to userspace. Userspace application will be unblocked and the buffer will be read. >>> >> >> Yeah buffers need to work independent of userspace and can't be blocking at all. >> >>> Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? >>> >> >> Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI >> unit or similar. Maybe Jonathan has some thoughts on this > > I'll confess I'm not sure this is really a good fit for IIO. It's kind > of similar to some of the things like fingerprint readers that generate > a block of data in some cryptic format that needs a userspace library to > interpret it. It looks like we are removing the frame from framework ;) -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
