Skip to contentSkip to conversation

mfd: Add r_select to lm3533 platform data

PATCH Applied Johan Hovold 2 participants 8 messages May 18, 2012 – May 22, 2012 Multifunction devices (MFD)

lore
Share & tools
lore

Johan Hovold

author
#0 lore raw

PATCH 1/2 mfd: Add r_select to lm3533 platform data

Add resistor-select parameter to the platform data.

Signed-off-by Johan Hovold <[email protected]>

---

Hi Samuel,

I believe this one needs to go in through mfd as the iio driver destined for staging-next depends on it.

Thanks,
Johan

 include/linux/mfd/lm3533.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
include/linux/mfd/lm3533.h +1 -0
index 9660feb..594bc59 100644
@@ -43,6 +43,7 @@ struct lm3533_ctrlbank {
 
 struct lm3533_als_platform_data {
 	unsigned pwm_mode:1;		/* PWM input mode (default analog) */
+	u8 r_select;			/* 1 - 127 (ignored in PWM-mode) */
 };
 
 struct lm3533_bl_platform_data {
Signature · 1 line
1.7.8.5
author
#1 lore raw

PATCH 2/2 mfd: Mark two lm3533 zone registers as volatile

Mark the two currently unused zone registers as volatile in regmap for completeness.

Signed-off-by Johan Hovold <[email protected]>
---
 drivers/mfd/lm3533-core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/mfd/lm3533-core.c +1 -1
index 104faba..0b2879b 100644
@@ -567,7 +567,7 @@ static bool lm3533_readable_register(struct device *dev, unsigned int reg)
 static bool lm3533_volatile_register(struct device *dev, unsigned int reg)
 {
 	switch (reg) {
-	case 0x34:		/* zone */
+	case 0x34 ... 0x36:	/* zone */
 	case 0x37 ... 0x38:	/* adc */
 	case 0xb0 ... 0xb1:	/* fault */
 		return true;
Signature · 1 line
1.7.8.5
Applied
#2 lore raw

Re: [PATCH 2/2] mfd: Mark two lm3533 zone registers as volatile

Hi Johan,

Quoted 2 lines · Johan Hovold

Mark the two currently unused zone registers as volatile in regmap for completeness.

Applied, thanks.

Cheers,
Samuel.

Signature · 2 lines
Intel Open Source Technology Centre
http://oss.intel.com/
#3 lore raw
In reply to Johan Hovold

Hi Johan,

Quoted 9 lines · Johan Hovold

Add resistor-select parameter to the platform data.

Signed-off-by Johan Hovold <[email protected]>

---

Hi Samuel,

I believe this one needs to go in through mfd as the iio driver destined for staging-next depends on it.

It should go along with the iio driver if there is a build dependency. No doing so will prevent the tree from being bisectable.

Cheers,
Samuel.

Signature · 2 lines
Intel Open Source Technology Centre
http://oss.intel.com/
author
#4 lore raw
Quoted 8 lines · Samuel Ortiz

Hi Johan,

Quoted 5 lines · Johan Hovold

Add resistor-select parameter to the platform data.

Signed-off-by Johan Hovold <[email protected]>

---

Quoted 6 lines
Quoted 4 lines

Hi Samuel,

I believe this one needs to go in through mfd as the iio driver destined for staging-next depends on it.

It should go along with the iio driver if there is a build dependency. No doing so will prevent the tree from being bisectable.

The sub-drivers already depend on mfd to build as this is where the header file resides. I can't add another platform data parameter via staging-next simply because the header file isn't in that tree yet.

As long as mfd is merged first linus' tree will be bisectable.

Thanks,
Johan

#5 lore raw

Hi Johan,

Quoted 11 lines · Johan Hovold
Quoted 10 lines · Samuel Ortiz

Hi Johan,

Quoted 7 lines · Johan Hovold

Add resistor-select parameter to the platform data.

Signed-off-by Johan Hovold <[email protected]>

---

Hi Samuel,

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

I believe this one needs to go in through mfd as the iio driver destined for staging-next depends on it.

It should go along with the iio driver if there is a build dependency. No doing so will prevent the tree from being bisectable.

The sub-drivers already depend on mfd to build as this is where the header file resides.

I haven't looked at it, but if the iio driver Kconfig entry depends on MFD_LM3533, then I can take this change in as no one will be able to build your iio driver until the MFD driver is merged.
Is that the case ?

Cheers,
Samuel.

Signature · 2 lines
Intel Open Source Technology Centre
http://oss.intel.com/
author
#6 lore raw
Quoted 19 lines · Samuel Ortiz

Hi Johan,

Quoted 16 lines · Johan Hovold
Quoted 14 lines · Samuel Ortiz

Hi Johan,

Quoted 9 lines · Johan Hovold

Add resistor-select parameter to the platform data.

Signed-off-by Johan Hovold <[email protected]>

---

Hi Samuel,

I believe this one needs to go in through mfd as the iio driver destined for staging-next depends on it.

It should go along with the iio driver if there is a build dependency. No doing so will prevent the tree from being bisectable.

Quoted 6 lines
Quoted 2 lines

The sub-drivers already depend on mfd to build as this is where the header file resides.

I haven't looked at it, but if the iio driver Kconfig entry depends on MFD_LM3533, then I can take this change in as no one will be able to build your iio driver until the MFD driver is merged.
Is that the case ?

Yes, it is.

Thanks,
Johan

#7 lore raw

Hi Johan,

Quoted 20 lines · Johan Hovold
Quoted 19 lines · Samuel Ortiz

Hi Johan,

Quoted 16 lines · Johan Hovold
Quoted 14 lines · Samuel Ortiz

Hi Johan,

Quoted 9 lines · Johan Hovold

Add resistor-select parameter to the platform data.

Signed-off-by Johan Hovold <[email protected]>

---

Hi Samuel,

I believe this one needs to go in through mfd as the iio driver destined for staging-next depends on it.

It should go along with the iio driver if there is a build dependency. No doing so will prevent the tree from being bisectable.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

The sub-drivers already depend on mfd to build as this is where the header file resides.

I haven't looked at it, but if the iio driver Kconfig entry depends on MFD_LM3533, then I can take this change in as no one will be able to build your iio driver until the MFD driver is merged.
Is that the case ?

Yes, it is.

Applied then.

Cheers,
Samuel.

Signature · 2 lines
Intel Open Source Technology Centre
http://oss.intel.com/