Re: [RFCv1 4/4] mfd: twl4030-madc: Move driver to drivers/iio/adc

From: Jonathan Cameron
Date: Sun Feb 23 2014 - 06:02:31 EST

On 23/02/14 00:35, Sebastian Reichel wrote:
On Sat, Feb 22, 2014 at 12:47:03PM +0000, Jonathan Cameron wrote:
On 14/02/14 18:46, Sebastian Reichel wrote:
This is a driver for an A/D converter, which belongs into
drivers/iio/adc.

Signed-off-by: Sebastian Reichel <sre@xxxxxxxxxx>

Being inherently lazy I'm going to review this patch as it gives the complete
driver rather than taking on the conversion patch directly!

OK.

It's a long shot, but are there any docs freely available for this part?

There is documentation on Texas Instrument's website for TPS65950,
which is supposed to be very similar to the TWL4030 and contains a
section about the MADC module:

http://www.ti.com/lit/gpn/tps65950
I had a look at that and to put it lightly the docs aren't particularly
informative. Ah well, such is life.

Obviously that may well mean that some of my comments apply to the driver
in general rather than the changes you've made. Please feel free to
pick and choose!

Having skipped over your comments I guess 70% are about the driver
in general, but I can add another patch to the patchset, which fixes
the driver style.
That would be great thanks!

I'd like ideally to see a little more generic tidying up in this driver.
As you'll notice inline I get irritated at having lots and lots of error
messages. Still that's personal preference but I felt a lot more justified
in moaning after finding one that was incorrect ;)

There is also a bit of functionality in here that I'm not sure is ever
used (the request callback functions). It complicates the code so if no
using it I'd be tempted to drop it.

I think the optimal workflow is:

1. convert madc driver to IIO
2. convert twl4030-madc-battery driver to IIO API
3. convert rx51-battery to IIO API
4. convert twl4030-madc-hwmon to IIO API / deprecate it
5. remove old in-kernel ABI from madc
6. cleanup/simplify madc

I guess its much simpler to do the driver cleanup/simplification
once we can get rid of the old API.

Perhaps. I guess it depends on your planned schedule. If you are intending
to plough through the above in the near future then fair enough. If the
chances are it'll take a while, I'd be inclined to fix some of the more
glarringly hideous bits now (such as error code reporting) and then
visit your list above over time.

Note that to my mind it is converted drivers like this that sneak some
nasty code into an a subsystem I look after. We have a lot of 'interesting'
code out in staging still, but for new submissions we are being increasingly
fussy about little bits. So I hope I don't come across as being too mean
about this driver. I'm glad you are putting in the work to convert
it over. There are a quite a few similar drivers sculking through the tree
so it's nice that someone has gotten started on bringing one over to IIO.



It's nice in a way that the driver before your conversion provided only
a very limited and in kernel interface given we don't have to hang on to
any old ABI elements.

---
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/twl4030-madc.c | 922 +++++++++++++++++++++++++++++++++++++++++
drivers/mfd/Kconfig | 10 -
drivers/mfd/Makefile | 1 -
drivers/mfd/twl4030-madc.c | 922 -----------------------------------------
6 files changed, 933 insertions(+), 933 deletions(-)
create mode 100644 drivers/iio/adc/twl4030-madc.c
delete mode 100644 drivers/mfd/twl4030-madc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 2209f28..427f75c 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -183,6 +183,16 @@ config TI_AM335X_ADC
Say yes here to build support for Texas Instruments ADC
driver which is also a MFD client.

+config TWL4030_MADC
+ tristate "TWL4030 MADC (Monitoring A/D Converter)"
+ depends on TWL4030_CORE
+ help
+ This driver provides support for Triton TWL4030-MADC. The
+ driver supports both RT and SW conversion methods.
+
+ This driver can also be built as a module. If so, the module will be
+ called twl4030-madc.
+
config TWL6030_GPADC
tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
depends on TWL4030_CORE
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index ba9a10a..9acf2df 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -20,5 +20,6 @@ obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_NAU7802) += nau7802.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
new file mode 100644
index 0000000..4da61c4
--- /dev/null
+++ b/drivers/iio/adc/twl4030-madc.c
@@ -0,0 +1,922 @@
+/*
+ *
+ * TWL4030 MADC module driver-This driver monitors the real time
+ * conversion of analog signals like battery temperature,
+ * battery type, battery level etc.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy <j-keerthy@xxxxxx>
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen@xxxxxxxxx>
+ *
+ * Amit Kucheria <amit.kucheria@xxxxxxxxxxxxx>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/i2c/twl.h>
+#include <linux/i2c/twl4030-madc.h>
+#include <linux/module.h>
+#include <linux/stddef.h>
+#include <linux/mutex.h>
+#include <linux/bitops.h>
+#include <linux/jiffies.h>
+#include <linux/types.h>
+#include <linux/gfp.h>
+#include <linux/err.h>
+
+#include <linux/iio/iio.h>
Why include machine.h or driver.h. You aren't currently using the
mapping coding anyway that these provide.

My bad. I copied that over from another driver without checking if
it is actually needed.

+#include <linux/iio/machine.h>
+#include <linux/iio/driver.h>
+
+/*
+ * struct twl4030_madc_data - a container for madc info
+ * @dev - pointer to device structure for madc
+ * @lock - mutex protecting this data structure
+ * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @imr - Interrupt mask register of MADC
+ * @isr - Interrupt status register of MADC
+ */
+struct twl4030_madc_data {
+ struct device *dev;
+ struct mutex lock; /* mutex protecting this data structure */
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ bool use_second_irq;

These are 32 bit signed values?

These were already defined as int in the original driver. I will
change these to u8 in an additional patch.

+ int imr;
+ int isr;
+};
+
+static int twl4030_madc_read(struct iio_dev *iio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct twl4030_madc_data *madc = iio_priv(iio_dev);
+ struct twl4030_madc_request req;
+ int channel = chan->channel;
+ int ret;
+
+ req.method = madc->use_second_irq ? TWL4030_MADC_SW2 : TWL4030_MADC_SW1;
+
+ req.channels = BIT(channel);
+ req.active = 0;
+ req.func_cb = NULL;
req.raw = !(mask & IIO_CHAN_INFO_PROCESSED);
req.do_avg = !!(mask & IIO_CHAN_INFO_AVERAGE_RAW);

Right.

+ req.raw = (mask & IIO_CHAN_INFO_PROCESSED) ? false : true;
+ req.do_avg = (mask & IIO_CHAN_INFO_AVERAGE_RAW) ? true : false;
+
+ ret = twl4030_madc_conversion(&req);
+ if (ret < 0)
+ return ret;
+
+ *val = req.rbuf[channel];
+
+ return IIO_VAL_INT;
+}
+
+static const struct iio_info twl4030_madc_iio_info = {
+ .read_raw = &twl4030_madc_read,
+ .driver_module = THIS_MODULE,
+};
+
Please give this a prefixed name. Chances of ADC_CHANNEL
turning up in an IIO header is a little too high to do this
without! e.g. #define TWL4030_ADC_CHANNEL

Probably drivers/iio/adc/exynos_adc.c should also be fixed.
Sounds like it. Patches always welcome ;) Like any other reviewer
I'm not known for absolute consistency.

+#define ADC_CHANNEL(_channel, _type, _name, _mask) { \
+ .type = _type, \
I don't think you use scan_type anywhere so don't bother specifying it.
here.

ok.

+ .scan_type = IIO_ST('u', 10, 16, 0), \
+ .channel = _channel, \
+ .info_mask_separate = _mask, \
+ .datasheet_name = _name, \
+ .indexed = 1, \
+}
+

Is the average have an adjustable number of samples?

The TWL supports reading a value directly (1 sample) or reading
the average of 4 samples.

If not I'd be tempted to use the more common option of IIO_CHAN_INFO_RAW
rather than the average version (tends only to be used in fairly obscure
cases where both a raw access and an averaged one are available).

currently some drivers use the averaged read and some use the direct
read.


In that case I'd expose both the 1 sample and averaged versions via the
IIO interfaces. If you want to pick 1 then do IIO_CHAN_INFO_RAW not the
averaged version.
+static const struct iio_chan_spec twl4030_madc_iio_channels[] = {
+ ADC_CHANNEL(0, IIO_VOLTAGE, "ADCIN0", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(1, IIO_TEMP, "ADCIN1", BIT(IIO_CHAN_INFO_PROCESSED) |
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(2, IIO_VOLTAGE, "ADCIN2", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(3, IIO_VOLTAGE, "ADCIN3", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(4, IIO_VOLTAGE, "ADCIN4", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(5, IIO_VOLTAGE, "ADCIN5", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(6, IIO_VOLTAGE, "ADCIN6", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(7, IIO_VOLTAGE, "ADCIN7", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(8, IIO_VOLTAGE, "ADCIN8", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(9, IIO_VOLTAGE, "ADCIN9", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(10, IIO_CURRENT, "ADCIN10", BIT(IIO_CHAN_INFO_PROCESSED) |
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(11, IIO_VOLTAGE, "ADCIN11", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(12, IIO_VOLTAGE, "ADCIN12", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(13, IIO_VOLTAGE, "ADCIN13", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(14, IIO_VOLTAGE, "ADCIN14", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+ ADC_CHANNEL(15, IIO_VOLTAGE, "ADCIN15", BIT(IIO_CHAN_INFO_AVERAGE_RAW)),
+};
+
Why the artificial limitation of one of these devices? I guess this is to
allow the exported function to work without needing to be associated with
any particular device... Hmm.

Artificial limitation? The madc is a ADC, which has some special
functions defined for some pins in the datasheet:

ADC0 = Battery Voltage
ADC1 = Battery Temperature
ADC10 = Battery Current

Nokia misused some of those pins on the Nokia N900, though. For
example they have their own conversion tables for the temperature,
which is not compatible with the generic one for the madc module.

*laughs*. If someone documents a pin as having a particular purpose
but it isn't wired inside a package. Someone will always think they know
better. Basic principal is to never limit ourselves to one instance of
a chip because the chances of someone deciding to do something interesting
with multiple chips is way to high.


I planned to convert the rx51-battery driver to simply read the raw
values. All other users can use the processed information.
Makes sense.

+static struct twl4030_madc_data *twl4030_madc;
+
+struct twl4030_prescale_divider_ratios {
+ s16 numerator;
+ s16 denominator;
+};
+
+static const struct twl4030_prescale_divider_ratios
+twl4030_divider_ratios[16] = {
+ {1, 1}, /* CHANNEL 0 No Prescaler */
+ {1, 1}, /* CHANNEL 1 No Prescaler */
+ {6, 10}, /* CHANNEL 2 */
+ {6, 10}, /* CHANNEL 3 */
+ {6, 10}, /* CHANNEL 4 */
+ {6, 10}, /* CHANNEL 5 */
+ {6, 10}, /* CHANNEL 6 */
+ {6, 10}, /* CHANNEL 7 */
+ {3, 14}, /* CHANNEL 8 */
+ {1, 3}, /* CHANNEL 9 */
+ {1, 1}, /* CHANNEL 10 No Prescaler */
+ {15, 100}, /* CHANNEL 11 */
+ {1, 4}, /* CHANNEL 12 */
+ {1, 1}, /* CHANNEL 13 Reserved channels */
+ {1, 1}, /* CHANNEL 14 Reseved channels */
+ {5, 11}, /* CHANNEL 15 */
+};
+
+
+/*
+ * Conversion table from -3 to 55 degree Celcius
+ */
+static int therm_tbl[] = {
+30800, 29500, 28300, 27100,
+26000, 24900, 23900, 22900, 22000, 21100, 20300, 19400, 18700, 17900,
+17200, 16500, 15900, 15300, 14700, 14100, 13600, 13100, 12600, 12100,
+11600, 11200, 10800, 10400, 10000, 9630, 9280, 8950, 8620, 8310,
+8020, 7730, 7460, 7200, 6950, 6710, 6470, 6250, 6040, 5830,
+5640, 5450, 5260, 5090, 4920, 4760, 4600, 4450, 4310, 4170,
+4040, 3910, 3790, 3670, 3550
+};
+
+/*
+ * Structure containing the registers
+ * of different conversion methods supported by MADC.
+ * Hardware or RT real time conversion request initiated by external host
+ * processor for RT Signal conversions.
+ * External host processors can also request for non RT conversions
+ * SW1 and SW2 software conversions also called asynchronous or GPC request.
+ */
+static
+const struct twl4030_madc_conversion_method twl4030_conversion_methods[] = {
+ [TWL4030_MADC_RT] = {
+ .sel = TWL4030_MADC_RTSELECT_LSB,
+ .avg = TWL4030_MADC_RTAVERAGE_LSB,
+ .rbase = TWL4030_MADC_RTCH0_LSB,
+ },
+ [TWL4030_MADC_SW1] = {
+ .sel = TWL4030_MADC_SW1SELECT_LSB,
+ .avg = TWL4030_MADC_SW1AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW1,
+ },
+ [TWL4030_MADC_SW2] = {
+ .sel = TWL4030_MADC_SW2SELECT_LSB,
+ .avg = TWL4030_MADC_SW2AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW2,
+ },
+};
+
+/*
+ * Function to read a particular channel value.
+ * @madc - pointer to struct twl4030_madc_data
+ * @reg - lsb of ADC Channel
+ * If the i2c read fails it returns an error else returns 0.
+ */
+static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 reg)
+{
+ u8 msb, lsb;
+ int ret;
+ /*
+ * For each ADC channel, we have MSB and LSB register pair. MSB address
+ * is always LSB address+1. reg parameter is the address of LSB register
+ */
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &msb, reg + 1);
+ if (ret) {
+ dev_err(madc->dev, "unable to read MSB register 0x%X\n",
+ reg + 1);
+ return ret;
+ }
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &lsb, reg);
+ if (ret) {
+ dev_err(madc->dev, "unable to read LSB register 0x%X\n", reg);
+ return ret;
+ }
+
+ return (int)(((msb << 8) | lsb) >> 6);
+}
+
+/*
+ * Return battery temperature
+ * Or < 0 on failure.
+ */
+static int twl4030battery_temperature(int raw_volt)
+{
+ u8 val;
+ int temp, curr, volt, res, ret;
+
+ volt = (raw_volt * TEMP_STEP_SIZE) / TEMP_PSR_R;
+ /* Getting and calculating the supply current in micro ampers */
+ ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, &val,
+ REG_BCICTL2);
+ if (ret < 0)
+ return ret;
blank line here and after similar error cases makes it a little easier to
read.

+ curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10;
+ /* Getting and calculating the thermistor resistance in ohms */
+ res = volt * 1000 / curr;
+ /* calculating temperature */
+ for (temp = 58; temp >= 0; temp--) {
+ int actual = therm_tbl[temp];
+
No blank line here.

I added the newline to the style fix patch, since these lines were
not touched by me before.

+ if ((actual - res) >= 0)
+ break;
+ }
+
+ return temp + 1;
+}
+
+static int twl4030battery_current(int raw_volt)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, &val,
+ TWL4030_BCI_BCICTL1);
+ if (ret)
+ return ret;
+ if (val & TWL4030_BCI_CGAIN) /* slope of 0.44 mV/mA */
+ return (raw_volt * CURR_STEP_SIZE) / CURR_PSR_R1;
+ else /* slope of 0.88 mV/mA */
+ return (raw_volt * CURR_STEP_SIZE) / CURR_PSR_R2;
+}
blank line here please.

Also added to the style fix patch.

Various comments on this in the next function:
This would be much simpler if any error immediately resulted in an
exit with error code. If it's gone wrong enough to issue a dev_err
then don't try to muddle through. Given there is nothing to clear
up in here, just error out directly on the first problem.

I guess this should be fixed once the old API is removed.

+/*
+ * Function to read channel values
+ * @madc - pointer to twl4030_madc_data struct
+ * @reg_base - Base address of the first channel
+ * @Channels - 16 bit bitmap. If the bit is set, channel value is read
+ * @buf - The channel values are stored here. if read fails error
+ * @raw - Return raw values without conversion
+ * value is stored
+ * Returns the number of successfully read channels.
+ */
+static int twl4030_madc_read_channels(struct twl4030_madc_data *madc,
+ u8 reg_base, unsigned
+ long channels, int *buf,
+ bool raw)
+{
+ int count = 0, count_req = 0, i;
+ u8 reg;
+
+ for_each_set_bit(i, &channels, TWL4030_MADC_MAX_CHANNELS) {
Skip the temporary for reg. Yes, it gets used twice, but easier to read
inline.

Also fixed in the style patch.

+ reg = reg_base + 2 * i;
+ buf[i] = twl4030_madc_channel_raw_read(madc, reg);
+ if (buf[i] < 0) {
+ dev_err(madc->dev,
+ "Unable to read register 0x%X\n", reg);
+ count_req++;
+ continue;
+ }
I'd prefer this as
if (raw) {
count ++;
} else {
switch (i) {
..
}

That increases the code indention by another level. I don't think
that's a good idea.
For clarity I'd do it anyway, but if the count is brought out of the
statements then the flow will be more obvious anyway.

Also near as I can tell count gets incremented unless there is an error
anyway. So just increment it outside and allow this function to return the
error code.
Returning error codes would change the existing API. I would prefer
to do this change after the old API is removed.
This function isn't exported directly and I suspect a quick look would show
no one relying on the successfully reading some subset of drivers. It might
make sense to eat the error at the exported interface and return a length
of 0.


+ if (raw) {
+ count++;
+ continue;
+ }
+ switch (i) {
These cases could do with a suitable #define to give them a name.

TWL4030_MADC_ADCIN10 is already in use for (1 << 10). I guess this
can be simplified more easily once the old API is removed.

+ case 10:
+ buf[i] = twl4030battery_current(buf[i]);
+ if (buf[i] < 0) {
+ dev_err(madc->dev, "err reading current\n");
+ count_req++;
+ } else {
+ count++;
+ buf[i] = buf[i] - 750;
+ }
+ break;
+ case 1:
+ buf[i] = twl4030battery_temperature(buf[i]);
+ if (buf[i] < 0) {
+ dev_err(madc->dev, "err reading temperature\n");
+ count_req++;
+ } else {
+ buf[i] -= 3;
+ count++;
+ }
+ break;
+ default:
+ count++;
+ /* Analog Input (V) = conv_result * step_size / R
+ * conv_result = decimal value of 10-bit conversion
+ * result
+ * step size = 1.5 / (2 ^ 10 -1)
+ * R = Prescaler ratio for input channels.
+ * Result given in mV hence multiplied by 1000.
+ */
+ buf[i] = (buf[i] * 3 * 1000 *
+ twl4030_divider_ratios[i].denominator)
+ / (2 * 1023 *
+ twl4030_divider_ratios[i].numerator);
+ }
+ }
This is already apparant from the errors emmited earlier. I'd drop this
and the count_req counter in general.
Personally I'd error out in those cases anyway rather than carrying on
with the rest of the channels. If it's worth of a dev_err it's worthy
of getting out as fast as possible rather than trying to muddle on.

I also think this should be postponed until the old API is removed.
I'd prefer to see standalone cleanups and fixes integrated first as I suspect
it may be a little while before we manage to fully drop the old API.

+ if (count_req)
+ dev_err(madc->dev, "%d channel conversion failed\n", count_req);
+
+ return count;
+}
+
+/*
+ * Enables irq.
+ * @madc - pointer to twl4030_madc_data struct
+ * @id - irq number to be enabled
+ * can take one of TWL4030_MADC_RT, TWL4030_MADC_SW1, TWL4030_MADC_SW2
+ * corresponding to RT, SW1, SW2 conversion requests.
+ * If the i2c read fails it returns an error else returns 0.
+ */
+static int twl4030_madc_enable_irq(struct twl4030_madc_data *madc, u8 id)
+{
+ u8 val;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &val, madc->imr);
+ if (ret) {
+ dev_err(madc->dev, "unable to read imr register 0x%X\n",
+ madc->imr);
+ return ret;
+ }
A blank line here and in similar cases would slight aid readability.



+ val &= ~(1 << id);
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, val, madc->imr);
+ if (ret) {
+ dev_err(madc->dev,
+ "unable to write imr register 0x%X\n", madc->imr);
+ return ret;
+
Loose blank line here.

both fixed in the style patch.

+ }
+
+ return 0;
+}
+
+/*
+ * Disables irq.
+ * @madc - pointer to twl4030_madc_data struct
+ * @id - irq number to be disabled
+ * can take one of TWL4030_MADC_RT, TWL4030_MADC_SW1, TWL4030_MADC_SW2
+ * corresponding to RT, SW1, SW2 conversion requests.
+ * Returns error if i2c read/write fails.
+ */
+static int twl4030_madc_disable_irq(struct twl4030_madc_data *madc, u8 id)
+{
+ u8 val;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &val, madc->imr);
+ if (ret) {
+ dev_err(madc->dev, "unable to read imr register 0x%X\n",
+ madc->imr);
+ return ret;
+ }
+ val |= (1 << id);
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, val, madc->imr);
+ if (ret) {
+ dev_err(madc->dev,
+ "unable to write imr register 0x%X\n", madc->imr);
+ return ret;
+ }
+
+ return 0;
+}
+
+static irqreturn_t twl4030_madc_threaded_irq_handler(int irq, void *_madc)
+{
+ struct twl4030_madc_data *madc = _madc;
+ const struct twl4030_madc_conversion_method *method;
+ u8 isr_val, imr_val;
+ int i, len, ret;
+ struct twl4030_madc_request *r;
+
+ mutex_lock(&madc->lock);
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &isr_val, madc->isr);
+ if (ret) {
+ dev_err(madc->dev, "unable to read isr register 0x%X\n",
+ madc->isr);
+ goto err_i2c;
+ }
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &imr_val, madc->imr);
+ if (ret) {
+ dev_err(madc->dev, "unable to read imr register 0x%X\n",
+ madc->imr);
+ goto err_i2c;
+ }
+ isr_val &= ~imr_val;
+ for (i = 0; i < TWL4030_MADC_NUM_METHODS; i++) {
+ if (!(isr_val & (1 << i)))
+ continue;
+ ret = twl4030_madc_disable_irq(madc, i);
+ if (ret < 0)
+ dev_dbg(madc->dev, "Disable interrupt failed%d\n", i);
+ madc->requests[i].result_pending = 1;
+ }
Can this and the previous loop not be combined thus simplifying some tests?

It probably can be, but I think this can wait until the old API is
removed.
Hmm. As I state below, if this is moving over to IIO (which is sensible) it
becomes my problem so I reserve the right to be fussy about less than optimal
code. If it was coming in clean as a new driver I'd push back hard on a lot
of this stuff before merging it. I have plenty of slightly uggly drivers
in staging to look after as it is!

+ for (i = 0; i < TWL4030_MADC_NUM_METHODS; i++) {
+ r = &madc->requests[i];
+ /* No pending results for this method, move to next one */
+ if (!r->result_pending)
+ continue;
+ method = &twl4030_conversion_methods[r->method];
+ /* Read results */
+ len = twl4030_madc_read_channels(madc, method->rbase,
+ r->channels, r->rbuf, r->raw);
+ /* Return results to caller */
+ if (r->func_cb != NULL) {
+ r->func_cb(len, r->channels, r->rbuf);
+ r->func_cb = NULL;
+ }
+ /* Free request */
+ r->result_pending = 0;
+ r->active = 0;
+ }
+ mutex_unlock(&madc->lock);
+
+ return IRQ_HANDLED;
+
+err_i2c:
+ /*
+ * In case of error check whichever request is active
+ * and service the same.
+ */
+ for (i = 0; i < TWL4030_MADC_NUM_METHODS; i++) {
+ r = &madc->requests[i];
+ if (r->active == 0)
+ continue;
+ method = &twl4030_conversion_methods[r->method];
+ /* Read results */
+ len = twl4030_madc_read_channels(madc, method->rbase,
+ r->channels, r->rbuf, r->raw);
+ /* Return results to caller */
+ if (r->func_cb != NULL) {
+ r->func_cb(len, r->channels, r->rbuf);
+ r->func_cb = NULL;
+ }
+ /* Free request */
+ r->result_pending = 0;
+ r->active = 0;
+ }
+ mutex_unlock(&madc->lock);
+
+ return IRQ_HANDLED;
+}
+
This structure does seem a little complex. I'd have been more tempted
by using a completion and having the calling function wait on it. How
often does an actual callback make sense?

This is part of the old API, so let's convert all consumers to the
IIO API and deprecate the callback stuff.

+static int twl4030_madc_set_irq(struct twl4030_madc_data *madc,
+ struct twl4030_madc_request *req)
+{
+ struct twl4030_madc_request *p;
+ int ret;
+
+ p = &madc->requests[req->method];
+ memcpy(p, req, sizeof(*req));
+ ret = twl4030_madc_enable_irq(madc, req->method);
+ if (ret < 0) {
+ dev_err(madc->dev, "enable irq failed!!\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Function which enables the madc conversion
+ * by writing to the control register.
+ * @madc - pointer to twl4030_madc_data struct
+ * @conv_method - can be TWL4030_MADC_RT, TWL4030_MADC_SW2, TWL4030_MADC_SW1
+ * corresponding to RT SW1 or SW2 conversion methods.
+ * Returns 0 if succeeds else a negative error value
+ */
+static int twl4030_madc_start_conversion(struct twl4030_madc_data *madc,
+ int conv_method)
+{
+ const struct twl4030_madc_conversion_method *method;
+ int ret = 0;
+ method = &twl4030_conversion_methods[conv_method];
+ switch (conv_method) {
Can we get here via any paths where these aren't the methods set?

conv_method is set from outside of the driver, so it's probably
safer to check. This can be simplified once the old API is removed.
Then we should be returning an error if it's not one of these.

+ case TWL4030_MADC_SW1:
+ case TWL4030_MADC_SW2:
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
+ TWL4030_MADC_SW_START, method->ctrl);
+ if (ret) {
+ dev_err(madc->dev,
+ "unable to write ctrl register 0x%X\n",
+ method->ctrl);
+ return ret;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
Could we fix up the kernel doc in this file in general. It's so nearly
there but not quite!

I assume, that the driver will get a huge cleanup once all consumers
of the old API are converted. Maybe a deprecation flag should be
added together with this patchset?
Probably not worth bothering for an inkernel interface that seems to have
relatively few users. How many out of tree users will be moving to
new kernels and using this device?

+/*
+ * Function that waits for conversion to be ready
+ * @madc - pointer to twl4030_madc_data struct
+ * @timeout_ms - timeout value in milliseconds
+ * @status_reg - ctrl register
+ * returns 0 if succeeds else a negative error value
+ */
+static int twl4030_madc_wait_conversion_ready(struct twl4030_madc_data *madc,
+ unsigned int timeout_ms,
+ u8 status_reg)
+{
+ unsigned long timeout;
+ int ret;
+
+ timeout = jiffies + msecs_to_jiffies(timeout_ms);
+ do {
+ u8 reg;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, &reg, status_reg);
+ if (ret) {
+ dev_err(madc->dev,
+ "unable to read status register 0x%X\n",
+ status_reg);
+ return ret;
+ }
+ if (!(reg & TWL4030_MADC_BUSY) && (reg & TWL4030_MADC_EOC_SW))
+ return 0;
+ usleep_range(500, 2000);
+ } while (!time_after(jiffies, timeout));
+ dev_err(madc->dev, "conversion timeout!\n");
+
+ return -EAGAIN;
+}
+

+/*
+ * An exported function which can be called from other kernel drivers.
What uses this currently? Ideally we'd do this through the standard IIO paths
for in kernel users. Right now the device tree mappings for that are less
than ideal (ask Mark Rutland if you want some choice comments ;) Perhaps
we take the view this can be cleaned up later. There are some elements in here
we haven't yet looked at supporting for client drivers. Will have to think
about that.

It would be particularly nice if possible to use a generic battery driver
for the two cases that seem to be using this functionality at the moment.

Currently there are 3 consumer drivers using this:

* twl4030-madc-battery
* rx51-battery
* twl4030-madc-hwmon

I guess the first two can be updated to use the IIO API and the last
one can be replaced by the IIO hwmon driver. Since it's an
in-kernel-api there should be no problems to simply remove the API
afterwards.
Yes that sounds like a good paln.

+ * @req twl4030_madc_request structure
+ * req->rbuf will be filled with read values of channels based on the
+ * channel index. If a particular channel reading fails there will
+ * be a negative error value in the corresponding array element.
+ * returns 0 if succeeds else error value
+ */
+int twl4030_madc_conversion(struct twl4030_madc_request *req)
+{
+ const struct twl4030_madc_conversion_method *method;
+ u8 ch_msb, ch_lsb;
+ int ret;
+
+ if (!req || !twl4030_madc)
+ return -EINVAL;
+
+ mutex_lock(&twl4030_madc->lock);
+ if (req->method < TWL4030_MADC_RT || req->method > TWL4030_MADC_SW2) {
+ ret = -EINVAL;
+ goto out;
+ }
+ /* Do we have a conversion request ongoing */
+ if (twl4030_madc->requests[req->method].active) {
+ ret = -EBUSY;
+ goto out;
+ }
+ ch_msb = (req->channels >> 8) & 0xff;
+ ch_lsb = req->channels & 0xff;
+ method = &twl4030_conversion_methods[req->method];
+ /* Select channels to be converted */
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, ch_msb, method->sel + 1);
+ if (ret) {
+ dev_err(twl4030_madc->dev,
+ "unable to write sel register 0x%X\n", method->sel + 1);
+ goto out;
+ }
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, ch_lsb, method->sel);
+ if (ret) {
+ dev_err(twl4030_madc->dev,
+ "unable to write sel register 0x%X\n", method->sel + 1);
+ goto out;
+ }
+ /* Select averaging for all channels if do_avg is set */
+ if (req->do_avg) {
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
+ ch_msb, method->avg + 1);
+ if (ret) {
+ dev_err(twl4030_madc->dev,
+ "unable to write avg register 0x%X\n",
+ method->avg + 1);
+ goto out;
+ }
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
+ ch_lsb, method->avg);
+ if (ret) {
+ dev_err(twl4030_madc->dev,
Excesive error messages are sometimes irritating as they break up code
flow. They are really irritating when incorrect ;)

Added to the fixes patch.

+ "unable to write sel reg 0x%X\n",
+ method->sel + 1);
+ goto out;
+ }
+ }
+ if (req->type == TWL4030_MADC_IRQ_ONESHOT && req->func_cb != NULL) {
+ ret = twl4030_madc_set_irq(twl4030_madc, req);
+ if (ret < 0)
+ goto out;
+ ret = twl4030_madc_start_conversion(twl4030_madc, req->method);
+ if (ret < 0)
+ goto out;
+ twl4030_madc->requests[req->method].active = 1;
+ ret = 0;
+ goto out;
+ }
Is it possible to get here? This comment suggests not. If so, why have
the test?

I guess it's an additional safety check. This function can be
simplified a lot once the old API is removed, so I guess this
can also be postponed.

+ /* With RT method we should not be here anymore */
+ if (req->method == TWL4030_MADC_RT) {
+ ret = -EINVAL;
+ goto out;
+ }
+ ret = twl4030_madc_start_conversion(twl4030_madc, req->method);
+ if (ret < 0)
+ goto out;
+ twl4030_madc->requests[req->method].active = 1;
+ /* Wait until conversion is ready (ctrl register returns EOC) */
So no interrupts in this case?
+ ret = twl4030_madc_wait_conversion_ready(twl4030_madc, 5, method->ctrl);
+ if (ret) {
+ twl4030_madc->requests[req->method].active = 0;
+ goto out;
+ }
+ ret = twl4030_madc_read_channels(twl4030_madc, method->rbase,
+ req->channels, req->rbuf, req->raw);
+ twl4030_madc->requests[req->method].active = 0;
+
+out:
+ mutex_unlock(&twl4030_madc->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(twl4030_madc_conversion);
+
+/*
Proper kerneldoc would be nice here. Otherwise the comment doesn't
really add anything so I'd be tempted to drop it ;)

removed in fixes patch.

+ * Return channel value
+ * Or < 0 on failure.
+ */
+int twl4030_get_madc_conversion(int channel_no)
+{
+ struct twl4030_madc_request req;
+ int temp = 0;
+ int ret;
+
+ req.channels = (1 << channel_no);
+ req.method = TWL4030_MADC_SW2;
+ req.active = 0;
+ req.func_cb = NULL;
+ ret = twl4030_madc_conversion(&req);
+ if (ret < 0)
+ return ret;
+ if (req.rbuf[channel_no] > 0)
+ temp = req.rbuf[channel_no];
+
+ return temp;
+}
+EXPORT_SYMBOL_GPL(twl4030_get_madc_conversion);
+
+/*
+ * Function to enable or disable bias current for
+ * main battery type reading or temperature sensing
+ * @madc - pointer to twl4030_madc_data struct
+ * @chan - can be one of the two values
What is a battery type reading? Voltage? Current? Charge?

It's used for battery type identification.
Ah the comment really did mean what it said!

+ * TWL4030_BCI_ITHEN - Enables bias current for main battery type reading
+ * TWL4030_BCI_TYPEN - Enables bias current for main battery temperature
These constants have rather incomprehensible names. Whilst I gues they
are straight off the data sheet, seems to me that we could make them a little
longer and easier to follow! The comment here helps, but sensible names
would be better!

The names come from the datasheet. I think we should fix this after
the old API is removed, since the constants are exposed for the API.
Fair enough.

+ * sensing
+ * @on - enable or disable chan.
+ */
+static int twl4030_madc_set_current_generator(struct twl4030_madc_data *madc,
+ int chan, int on)
+{
+ int ret;
+ u8 regval;
+
+ ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE,
+ &regval, TWL4030_BCI_BCICTL1);
+ if (ret) {
+ dev_err(madc->dev, "unable to read BCICTL1 reg 0x%X",
+ TWL4030_BCI_BCICTL1);
+ return ret;
+ }
Introduce an intermediate variable and this could be nice and easy to read
Say

int regmask;
if (chan == 0)
regmask = TWL4030_BCI_TYPEN;
else
regmask = TWL4030_BFI_ITHEN;

if (on)
regval |= regmask;
else
regval &= ~regmask;

It's longer but doesn't give me a headache.

I added this to the fixes patch:

int regmask;
regmask = (chan == 0) ? TWL4030_BCI_TYPEN : TWL4030_BFI_ITHEN;
if (on)
regval |= regmask;
else
regval &= ~regmask;

+ if (on)
+ regval |= chan ? TWL4030_BCI_ITHEN : TWL4030_BCI_TYPEN;
+ else
+ regval &= chan ? ~TWL4030_BCI_ITHEN : ~TWL4030_BCI_TYPEN;
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE,
+ regval, TWL4030_BCI_BCICTL1);
+ if (ret) {
+ dev_err(madc->dev, "unable to write BCICTL1 reg 0x%X\n",
+ TWL4030_BCI_BCICTL1);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Function that sets MADC software power on bit to enable MADC
+ * @madc - pointer to twl4030_madc_data struct
+ * @on - Enable or disable MADC software powen on bit.
+ * returns error if i2c read/write fails else 0
+ */
+static int twl4030_madc_set_power(struct twl4030_madc_data *madc, int on)
+{
+ u8 regval;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE,
+ &regval, TWL4030_MADC_CTRL1);
+ if (ret) {
+ dev_err(madc->dev, "unable to read madc ctrl1 reg 0x%X\n",
+ TWL4030_MADC_CTRL1);
+ return ret;
+ }
+ if (on)
+ regval |= TWL4030_MADC_MADCON;
+ else
+ regval &= ~TWL4030_MADC_MADCON;
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, regval, TWL4030_MADC_CTRL1);
+ if (ret) {
+ dev_err(madc->dev, "unable to write madc ctrl1 reg 0x%X\n",
+ TWL4030_MADC_CTRL1);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Initialize MADC and request for threaded irq
+ */
+static int twl4030_madc_probe(struct platform_device *pdev)
+{
+ struct twl4030_madc_data *madc;
+ struct twl4030_madc_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct device_node *np = pdev->dev.of_node;
+ int irq, ret;
+ u8 regval;
+ struct iio_dev *iio_dev = NULL;
+
+ if (!pdata && !np) {
+ dev_err(&pdev->dev, "platform_data not available\n");
+ return -EINVAL;
+ }
+
+ iio_dev = devm_iio_device_alloc(&pdev->dev,
+ sizeof(struct twl4030_madc_data));
+ if (!iio_dev) {
+ dev_err(&pdev->dev, "failed allocating iio device\n");
+ return -ENOMEM;
+ }
+
+ madc = iio_priv(iio_dev);
+ madc->dev = &pdev->dev;
+
+ iio_dev->name = dev_name(&pdev->dev);
+ iio_dev->dev.parent = &pdev->dev;
+ iio_dev->dev.of_node = pdev->dev.of_node;
+ iio_dev->info = &twl4030_madc_iio_info;
+ iio_dev->modes = INDIO_DIRECT_MODE;
+ iio_dev->channels = twl4030_madc_iio_channels;
+ iio_dev->num_channels = 16;
+
+ /*
+ * Phoenix provides 2 interrupt lines. The first one is connected to
+ * the OMAP. The other one can be connected to the other processor such
+ * as modem. Hence two separate ISR and IMR registers.
+ */
+ if (pdata)
+ madc->use_second_irq = pdata->irq_line != 1;
+ else
+ madc->use_second_irq = false;
+
+ madc->imr = (madc->use_second_irq == 1) ?
+ TWL4030_MADC_IMR1 : TWL4030_MADC_IMR2;
+ madc->isr = (madc->use_second_irq == 1) ?
+ TWL4030_MADC_ISR1 : TWL4030_MADC_ISR2;
+
+ ret = twl4030_madc_set_power(madc, 1);
+ if (ret < 0)
+ return ret;
+ ret = twl4030_madc_set_current_generator(madc, 0, 1);
+ if (ret < 0)
+ goto err_current_generator;
+
+ ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE,
+ &regval, TWL4030_BCI_BCICTL1);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to read reg BCI CTL1 0x%X\n",
+ TWL4030_BCI_BCICTL1);
+ goto err_i2c;
+ }
+ regval |= TWL4030_BCI_MESBAT;
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE,
+ regval, TWL4030_BCI_BCICTL1);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to write reg BCI Ctl1 0x%X\n",
+ TWL4030_BCI_BCICTL1);
+ goto err_i2c;
+ }
+
+ /* Check that MADC clock is on */
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, &regval, TWL4030_REG_GPBR1);
+ if (ret) {
Personally I'd rank the driver as rather to vebose on read error messages
given they are pretty unusual. Ah well I guess each to their own.

All of this is not written by me.
Sure. Doesn't stop me moaning :) At the end of the day you are proposing moving
this driver into a place where it becomes at least partly my problem. As such
I'm keen on any tidying / cleaning occuring ASAP.

+ dev_err(&pdev->dev, "unable to read reg GPBR1 0x%X\n",
+ TWL4030_REG_GPBR1);
+ goto err_i2c;
+ }
+
+ /* If MADC clk is not on, turn it on */
+ if (!(regval & TWL4030_GPBR1_MADC_HFCLK_EN)) {
+ dev_info(&pdev->dev, "clk disabled, enabling\n");
+ regval |= TWL4030_GPBR1_MADC_HFCLK_EN;
+ ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, regval,
+ TWL4030_REG_GPBR1);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to write reg GPBR1 0x%X\n",
+ TWL4030_REG_GPBR1);
+ goto err_i2c;
+ }
+ }
+
+ platform_set_drvdata(pdev, iio_dev);
+ mutex_init(&madc->lock);
+
+ irq = platform_get_irq(pdev, 0);

As ever using devm for a irq request makes for a bit of a review
nightmare as we have to be very careful that nothing has been removed
that this might use before the devm cleanup occurs (at end of remove).
In this case the fact that the current generator is off and the adc unit
is disabled sounds to me like it might cause interesting results in the
interrupt handler?

It's one of those things that will probably never happen but I find it
hard to convince myself 'can't happen'

+ ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+ twl4030_madc_threaded_irq_handler,
+ IRQF_TRIGGER_RISING, "twl4030_madc", madc);
+ if (ret) {
+ dev_dbg(&pdev->dev, "could not request irq\n");
+ goto err_i2c;
+ }

Err, where is this defined? Ah, found it above. I'm not keen on
preventing multiple instances of a device like this. It is so easy
to not do this I'd prefer to see the driver fixed to remove this.

This concept has also not introduced by me of course. I think we
should fix this after removal of the old API, since the old API does
not have an device parameter.
Fair enough.

+ twl4030_madc = madc;
+
+ ret = iio_device_register(iio_dev);
+ if (ret) {
+ dev_dbg(&pdev->dev, "could not register iio device\n");
+ goto err_i2c;
+ }
+
+ return 0;
+
+err_i2c:
+ twl4030_madc_set_current_generator(madc, 0, 0);
+err_current_generator:
+ twl4030_madc_set_power(madc, 0);
+ return ret;
+}
+
+static int twl4030_madc_remove(struct platform_device *pdev)
+{
+ struct iio_dev *iio_dev = platform_get_drvdata(pdev);
+ struct twl4030_madc_data *madc = iio_priv(iio_dev);
+
+ twl4030_madc_set_current_generator(madc, 0, 0);
+ twl4030_madc_set_power(madc, 0);
+
+ iio_device_unregister(iio_dev);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id twl_madc_of_match[] = {
+ {.compatible = "ti,twl4030-madc", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_madc_of_match);
+#endif
+
+static struct platform_driver twl4030_madc_driver = {
+ .probe = twl4030_madc_probe,
+ .remove = twl4030_madc_remove,
+ .driver = {
+ .name = "twl4030_madc",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl_madc_of_match),
+ },
+};
+
+module_platform_driver(twl4030_madc_driver);
+
+MODULE_DESCRIPTION("TWL4030 ADC driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("J Keerthy");
+MODULE_ALIAS("platform:twl4030_madc");

Rest of patch was removal of code so no comments!

FYI: For me it was a bit odd to see inline comments about code lines
coming after the inline comment. Normally I receive patch reviews
with comments after the referenced code, which makes more sense imho.
I never claimed to be consistent ;) Tend to review backwards that means
that sometimes comments end up in fairly random places.

-- Sebastian


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