IIO drivers left in drivers/staging/
Hi Jonathan,
I'd really like to figure out what is left to do with all of the remaining IIO staging drivers, and see if we can get them all moved out soon.
As part of the OPW intern program, Kristina has agreed to help out with staging kernel drivers and I thought that doing this type of work would be a great task. There seems to be a number of different types of IIO drivers here, so that should keep her from being bored with just one specific type of sensor. There are also some "dummy" IIO drivers, which I don't really understand what they are for (as well as why they remain in staging.)
The drivers/staging/TODO file seems pretty old, being dated back in 2009 and not really done much with the exception of adding one entry.
So, any thoughts about what to do here? Any pointers to devices that she can aquire if that needs to happen, or APIs that need to be standardized across types?
thanks,
greg k-h
Jonathan Cameron
maintainerQuoted 1 line · Greg KH
Hi Jonathan,
Hi Kristina/Greg.
Quoted 4 lines
I'd really like to figure out what is left to do with all of the remaining IIO staging drivers, and see if we can get them all moved out soon.
There is a lot of each driver having its own peculiar set of little and sometimes big
issues! We have also kind of gotten into the habbit of treating staging graduations as if they were initial driver submissions so proposed moves get quite a bit of review and that often extends the list of things to fix or improve rather a lot. Of course any help is welcome.
I'll reply in more detail about this later.
For now I have cc'd Lars as he has inherited
responsibility for a lot of AD drivers that have been around from the early days when things were a little loose.
If Christina is raring to get started, my notes say the lpc32xx_ADC driver needs some
prefixes on #define constants and that is all I picked up for that driver when reviewing it for a staging graduation.
If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
If I recall they are pretty clean and straight forward. Probably some ABI in need of documentation (sysfs attribute naming). If not do you have any short term suggestions?
Quoted 10 lines
As part of the OPW intern program, Kristina has agreed to help out with staging kernel drivers and I thought that doing this type of work would be a great task. There seems to be a number of different types of IIO drivers here, so that should keep her from being bored with just one
specific type of sensor. There are also some "dummy" IIO drivers, which
I don't really understand what they are for (as well as why they remain in staging.)
Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
hardware threshold interrupts etc.
This device is basically a fake. The intent was to allow those with no hardware to hand
to work at or understand the core of iio.
It has come in very handy as a test tool!
The other intended purpose is to act as an example of best practice and provide
documentation of a sort.
As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
Quoted 4 lines
The
drivers/staging/TODOfile seems pretty old, being dated back in 2009
and not really done much with the exception of adding one entry.
Oops
Quoted 4 lines
So, any thoughts about what to do here? Any pointers to devices that she can aquire if that needs to happen, or APIs that need to be standardized across types?
Most ABI bits are now to do with new stuff.
Having said that the resolver and CDC
drivers use some ABI that is probably documented but that documentation is also a candidate for cleaning up and moving out of staging.
Busy day (pesky customer demo) so will get back with more concrete stuff later.
Quoted 8 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 3 lines
Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Quoted 3 lines · Jonathan Cameron
Quoted 1 line · Greg KH
Hi Jonathan,
Hi Kristina/Greg.
Hi Jonathan!
Quoted 8 lines
Quoted 3 lines
I'd really like to figure out what is left to do with all of the remaining IIO staging drivers, and see if we can get them all moved out soon.
There is a lot of each driver having its own peculiar set of little and sometimes big
issues! We have also kind of gotten into the habbit of treating staging graduations as if they were initial driver submissions so proposed moves get quite a bit of review and that often extends the list of things to fix or improve rather a lot. Of course any help is welcome.
Sounds good, I'm glad to help out however I can.
Quoted 45 lines
I'll reply in more detail about this later.
For now I have cc'd Lars as he has inherited
responsibility for a lot of AD drivers that have been around from the early days when things were a little loose.If Christina is raring to get started, my notes say the
lpc32xx_ADCdriver needs some
prefixes on #define constants and that is all I picked up for that driver when reviewing it for a staging graduation.If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
If I recall they are pretty clean and straight forward. Probably some ABI in need of documentation (sysfs attribute naming). If not do you have any short term suggestions?Quoted 10 lines
As part of the OPW intern program, Kristina has agreed to help out with staging kernel drivers and I thought that doing this type of work would be a great task. There seems to be a number of different types of IIO drivers here, so that should keep her from being bored with just one
specific type of sensor. There are also some "dummy" IIO drivers, which
I don't really understand what they are for (as well as why they remain in staging.)Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
hardware threshold interrupts etc.This device is basically a fake. The intent was to allow those with no hardware to hand
to work at or understand the core of iio.
It has come in very handy as a test tool!The other intended purpose is to act as an example of best practice and provide
documentation of a sort.As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
Quoted 4 lines
The
drivers/staging/TODOfile seems pretty old, being dated back in 2009
and not really done much with the exception of adding one entry.Oops
Quoted 4 lines
So, any thoughts about what to do here? Any pointers to devices that she can aquire if that needs to happen, or APIs that need to be standardized across types?
Quoted 6 lines
Most ABI bits are now to do with new stuff.
Having said that the resolver and CDC
drivers use some ABI that is probably documented but that documentation is also a candidate for cleaning up and moving out of staging.Busy day (pesky customer demo) so will get back with more concrete stuff later.
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for lpc32xx_ADC (then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?
The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Kristina
Hi Jonathan,
Quoted 72 lines · Kristina Martšenko
Quoted 3 lines · Jonathan Cameron
Quoted 1 line · Greg KH
Hi Jonathan,
Hi Kristina/Greg.
Hi Jonathan!
Quoted 8 lines
Quoted 3 lines
I'd really like to figure out what is left to do with all of the remaining IIO staging drivers, and see if we can get them all moved out soon.
There is a lot of each driver having its own peculiar set of little and sometimes big
issues! We have also kind of gotten into the habbit of treating staging graduations as if they were initial driver submissions so proposed moves get quite a bit of review and that often extends the list of things to fix or improve rather a lot. Of course any help is welcome.Sounds good, I'm glad to help out however I can.
Quoted 45 lines
I'll reply in more detail about this later.
For now I have cc'd Lars as he has inherited
responsibility for a lot of AD drivers that have been around from the early days when things were a little loose.If Christina is raring to get started, my notes say the
lpc32xx_ADCdriver needs some
prefixes on #define constants and that is all I picked up for that driver when reviewing it for a staging graduation.If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
If I recall they are pretty clean and straight forward. Probably some ABI in need of documentation (sysfs attribute naming). If not do you have any short term suggestions?Quoted 10 lines
As part of the OPW intern program, Kristina has agreed to help out with staging kernel drivers and I thought that doing this type of work would be a great task. There seems to be a number of different types of IIO drivers here, so that should keep her from being bored with just one
specific type of sensor. There are also some "dummy" IIO drivers, which
I don't really understand what they are for (as well as why they remain in staging.)Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
hardware threshold interrupts etc.This device is basically a fake. The intent was to allow those with no hardware to hand
to work at or understand the core of iio.
It has come in very handy as a test tool!The other intended purpose is to act as an example of best practice and provide
documentation of a sort.As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
Quoted 4 lines
The
drivers/staging/TODOfile seems pretty old, being dated back in 2009
and not really done much with the exception of adding one entry.Oops
Quoted 4 lines
So, any thoughts about what to do here? Any pointers to devices that she can aquire if that needs to happen, or APIs that need to be standardized across types?
Quoted 6 lines
Most ABI bits are now to do with new stuff.
Having said that the resolver and CDC
drivers use some ABI that is probably documented but that documentation is also a candidate for cleaning up and moving out of staging.Busy day (pesky customer demo) so will get back with more concrete stuff later.
Okay so right now I'm getting the following things I could work on:
Quoted 8 lines
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
Thanks,
Kristina
Hello Kristina,
Quoted 8 lines
Quoted 8 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?
Quoted 5 lines
Quoted 2 lines
The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
IIO is a bit problematic since testing usually requires possessing the sensor chip
regarding staging/iio/magnetometer/hmc5843:
the driver has one specific DEVICE_ATTR left (meas_conf), otherwise clean I think; so we could (a) document it as special ABI or (b) drop it
regarding staging/iio/light/isl*:
drivers have plenty of custom ATTRs and do not follow style (function name prefixes, #define PREFIXes)
some of the special ATTRs could converted to using SAMPL_FREQ, INT_TIME, SCALE
regards, p.
Signature · 2 lines
Peter Meerwald +43-664-2444418 (mobile)
Jonathan Cameron
maintainerQuoted 11 lines · Peter Meerwald
Hello Kristina,
Quoted 3 lines
Quoted 3 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying tomove it
Quoted 5 lines
Quoted 5 lines
out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?
Quoted 7 lines
Quoted 1 line
Quoted 1 line
The plan is for me to start working on this stuff full time next
week,
Quoted 4 lines
Quoted 1 line
so if you think of anything more, please let me know!
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be
moved out?
Sorry, got caught up and failed to get back to you with more stuff.
Quoted 3 lines
IIO is a bit problematic since testing usually requires possessing the sensor chip
Whilst true, one can normally assume code as present works. Hence a lot can be done
without hardware. Just a good idea to keep changes small and make it clear when they are untested.
Quoted 6 lines
regarding staging/iio/magnetometer/hmc5843:
the driver has one specificDEVICE_ATTRleft (meas_conf), otherwise clean
I think; so we could (a) document it as special ABI or (b) drop it
Quoted 6 lines
regarding staging/iio/light/isl*:
drivers have plenty of custom ATTRs and do not follow style (function name prefixes, #define PREFIXes)
some of the special ATTRs could converted to usingSAMPL_FREQ,INT_TIME,
SCALE
Good points.
A useful if perhaps dull task is to look at interfaces that are not in the ABI and figure out which ones need fixing and which, like those Peter highlights need new interfaces or should not be exposed to userspace at all. Killing off remaining bits that are now possible through info_mask_* is also helpful.
I have some patches for this outside staging but plenty to do in the drivers still there.
Quoted 2 lines
regards, p.
Looking forward to patches!
J
Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Quoted 10 lines · Peter Meerwald
Hello Kristina,
Quoted 8 lines
Quoted 8 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
IIO is a bit problematic since testing usually requires possessing the sensor chip
Any specific chips / devices we should look into buying for these drivers to help make it easier to do development?
Quoted 3 lines
regarding staging/iio/magnetometer/hmc5843:
the driver has one specificDEVICE_ATTRleft (meas_conf), otherwise clean I think; so we could (a) document it as special ABI or (b) drop it
Which is it? It should be easy to delete a driver :)
thanks,
greg k-h
Jonathan Cameron
maintainerQuoted 20 lines · Greg KH
Quoted 10 lines · Peter Meerwald
Hello Kristina,
Quoted 8 lines
Quoted 8 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
IIO is a bit problematic since testing usually requires possessing the sensor chip
Quoted 8 lines
Any specific chips / devices we should look into buying for these drivers to help make it easier to do development?
Quoted 3 lines
regarding staging/iio/magnetometer/hmc5843:
the driver has one specificDEVICE_ATTRleft (meas_conf), otherwise clean I think; so we could (a) document it as special ABI or (b) drop itWhich is it? It should be easy to delete a driver :)
Drop the attribute, not the driver!
Quoted 9 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jonathan Cameron
maintainerQuoted 15 lines · Jonathan Cameron
Quoted 14 lines · Greg KH
Quoted 13 lines · Peter Meerwald
Hello Kristina,
Quoted 11 lines
Quoted 10 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
IIO is a bit problematic since testing usually requires possessing the sensor chip
Any specific chips / devices we should look into buying for these drivers to help make it easier to do development?
On that note, perhaps ask for people to shout what they have access to and we'll see what is left.
Of stuff still in staging I have:
* lis3l02dq (it's there because we probably want to add this part to the much more general st-sensors driver rather than moving it out as is).
* sca3000 (still there because we now have a better idea of how to handle chips with hardware buffers - route them through a software buffer, dropping the explicit trigger as done in the am35x driver last summer).
J
Quoted 21 lines
Quoted 6 lines
Quoted 4 lines
regarding staging/iio/magnetometer/hmc5843:
the driver has one specificDEVICE_ATTRleft (meas_conf), otherwise clean I think; so we could (a) document it as special ABI or (b) drop itWhich is it? It should be easy to delete a driver :)
Drop the attribute, not the driver!
Quoted 9 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 14 lines · Greg KH
Quoted 13 lines · Peter Meerwald
Hello Kristina,
Quoted 11 lines
Quoted 10 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
IIO is a bit problematic since testing usually requires possessing the sensor chip
Any specific chips / devices we should look into buying for these drivers to help make it easier to do development?
I would say that the latest addition to the TODO file is quite valid ;) We have been looking at moving the mxs-lradc out of staging for a while now. It still has a few contributions coming from time to time and can definitely be improved. The main thing to do would be to create an MFD.
I understand this may be a considerable amount of work but it has the advantage of allowing to have a look at at least 3 different subsystems.
I am willing to review and test patches.
I would suggest that board:
http://www.crystalfontz.com/product/CFA921TS
It may not be the cheapeast one but it has good mainline support and I know it well.
Crystalfontz provided me some of their boards so that I could give them out at ELC. If you are interested in the topic, it may be worth asking whether they are willing to sponsor you ;)
Signature · 3 lines
Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Quoted 35 lines · Alexandre Belloni
Hi,
Quoted 14 lines · Greg KH
Quoted 13 lines · Peter Meerwald
Hello Kristina,
Quoted 11 lines
Quoted 10 lines
Okay so right now I'm getting the following things I could work on:
1) prefixes on define constants for
lpc32xx_ADC(then trying to move it out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?The plan is for me to start working on this stuff full time next week, so if you think of anything more, please let me know!
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
Haven't heard back from you about this. Have you found anything else that needs to be done with staging IIO drivers before they can be moved out?
IIO is a bit problematic since testing usually requires possessing the sensor chip
Any specific chips / devices we should look into buying for these drivers to help make it easier to do development?
I would say that the latest addition to the TODO file is quite valid ;) We have been looking at moving the mxs-lradc out of staging for a while now. It still has a few contributions coming from time to time and can definitely be improved. The main thing to do would be to create an MFD.
I understand this may be a considerable amount of work but it has the advantage of allowing to have a look at at least 3 different subsystems.
Quoted 7 lines
I am willing to review and test patches.
I would suggest that board:
http://www.crystalfontz.com/product/CFA921TSIt may not be the cheapeast one but it has good mainline support and I know it well.
What sensors does it have on it that are iio drivers that need fixing up?
It's not that expensive, my budget for Linux devices can cover it...
thanks,
greg k-h
Quoted 11 lines · Greg KH
Quoted 11 lines
I would say that the latest addition to the TODO file is quite valid ;) We have been looking at moving the mxs-lradc out of staging for a while now. It still has a few contributions coming from time to time and can definitely be improved. The main thing to do would be to create an MFD.
I understand this may be a considerable amount of work but it has the advantage of allowing to have a look at at least 3 different subsystems.
I am willing to review and test patches.
Quoted 9 lines
Quoted 5 lines
I would suggest that board:
http://www.crystalfontz.com/product/CFA921TSIt may not be the cheapeast one but it has good mainline support and I know it well.
What sensors does it have on it that are iio drivers that need fixing up?
It is i.mx28 based so it has the mxs LRADC which is currently supported through drivers/staging/iio/adc/mxs-lradc.c.
It is also a touchscreen controller, a temperature sensor and a battery voltage monitor so it would make sense to create an mfd and move the touchscreen part in the input subsystem and add a driver for the voltage monitor in the power subsystem.
You can also have a look at that thread:
http://www.spinics.net/lists/linux-iio/msg11004.html
Quoted 2 lines
It's not that expensive, my budget for Linux devices can cover it...
Signature · 3 lines
Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Quoted 29 lines · Alexandre Belloni
Quoted 11 lines · Greg KH
Quoted 11 lines
I would say that the latest addition to the TODO file is quite valid ;) We have been looking at moving the mxs-lradc out of staging for a while now. It still has a few contributions coming from time to time and can definitely be improved. The main thing to do would be to create an MFD.
I understand this may be a considerable amount of work but it has the advantage of allowing to have a look at at least 3 different subsystems.
I am willing to review and test patches.
Quoted 9 lines
Quoted 5 lines
I would suggest that board:
http://www.crystalfontz.com/product/CFA921TSIt may not be the cheapeast one but it has good mainline support and I know it well.
What sensors does it have on it that are iio drivers that need fixing up?
It is i.mx28 based so it has the mxs LRADC which is currently supported through
drivers/staging/iio/adc/mxs-lradc.c.
It is also a touchscreen controller, a temperature sensor and a battery voltage monitor so it would make sense to create an mfd and move the touchscreen part in the input subsystem and add a driver for the voltage monitor in the power subsystem.
Quoted 2 lines
You can also have a look at that thread:
http://www.spinics.net/lists/linux-iio/msg11004.html
That sounds promising, I'll look it over.
thanks,
greg k-h
Jonathan Cameron
maintainerQuoted 1 line · Greg KH
Hi Jonathan,
Hi Kristina/Greg.
Quoted 4 lines
I'd really like to figure out what is left to do with all of the remaining IIO staging drivers, and see if we can get them all moved out soon.
There is a lot of each driver having its own peculiar set of little and sometimes big
issues! We have also kind of gotten into the habbit of treating staging graduations as if they were initial driver submissions so proposed moves get quite a bit of review and that often extends the list of things to fix or improve rather a lot. Of course any help is welcome.
I'll reply in more detail about this later.
For now I have cc'd Lars as he has inherited
responsibility for a lot of AD drivers that have been around from the early days when things were a little loose.
If Christina is raring to get started, my notes say the lpc32xx_ADC driver needs some
prefixes on #define constants and that is all I picked up for that driver when reviewing it for a staging graduation.
If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
If I recall they are pretty clean and straight forward. Probably some ABI in need of documentation (sysfs attribute naming). If not do you have any short term suggestions?
Quoted 10 lines
As part of the OPW intern program, Kristina has agreed to help out with staging kernel drivers and I thought that doing this type of work would be a great task. There seems to be a number of different types of IIO drivers here, so that should keep her from being bored with just one
specific type of sensor. There are also some "dummy" IIO drivers, which
I don't really understand what they are for (as well as why they remain in staging.)
Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
hardware threshold interrupts etc.
This device is basically a fake. The intent was to allow those with no hardware to hand
to work at or understand the core of iio.
It has come in very handy as a test tool!
The other intended purpose is to act as an example of best practice and provide
documentation of a sort.
As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
Quoted 4 lines
The
drivers/staging/TODOfile seems pretty old, being dated back in 2009
and not really done much with the exception of adding one entry.
Oops
Quoted 4 lines
So, any thoughts about what to do here? Any pointers to devices that she can aquire if that needs to happen, or APIs that need to be standardized across types?
Most ABI bits are now to do with new stuff.
Having said that the resolver and CDC
drivers use some ABI that is probably documented but that documentation is also a candidate for cleaning up and moving out of staging.
Busy day (pesky customer demo) so will get back with more concrete stuff later.
Quoted 8 lines
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.