linux-
> d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> Maintainer; Greg KH; Jes Sorensen
> Subject: RE: new driver for drivers/virt/?
>
> > -Original Message-
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Wednesd
com; linux-kernel@vger.kernel.org; linux-
> d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> Maintainer; Jes Sorensen
> Subject: Re: new driver for drivers/virt/?
>
> On Thu, May 19, 2016 at 12:11:46AM +0200, Thomas Gleixner wrote:
> > On Wed, 18 May 2
ernel@vger.kernel.org; linux-
> d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> Maintainer; Greg KH; Jes Sorensen
> Subject: Re: new driver for drivers/virt/?
>
> On Wed, 18 May 2016, Sell, Timothy C wrote:
> > We have a bus driver currently in drivers/staging
On Thu, May 19, 2016 at 12:11:46AM +0200, Thomas Gleixner wrote:
> On Wed, 18 May 2016, Sell, Timothy C wrote:
> > We have a bus driver currently in drivers/staging/unisys/visorbus/ that
> > we are trying to get out of staging and into the kernel proper. Since
> > "visorbus" is a driver to host a
On Wed, 18 May 2016, Sell, Timothy C wrote:
> We have a bus driver currently in drivers/staging/unisys/visorbus/ that
> we are trying to get out of staging and into the kernel proper. Since
> "visorbus" is a driver to host a virtual bus presented to a Linux guest
> in a hypervisor environment (ref
Hi,
On 23/03/2016 at 17:47:38 +, Opensource [Steve Twiss] wrote :
> > On 23 March 2016, Alexandre Belloni wrote:
> > > Subject: Re: [NEW DRIVER V6 0/7] DA9058 PMIC - please comment on this new
> > > driver
> > >
> > > Hi Anthony, Steve,
> > &g
> On 23 March 2016, Alexandre Belloni wrote:
> > Subject: Re: [NEW DRIVER V6 0/7] DA9058 PMIC - please comment on this new
> > driver
> >
> > Hi Anthony, Steve,
> >
> > This driver has been submitted a while ago and reached v6 but still had
> > a few
On 23 March 2016, Alexandre Belloni wrote:
> To: Opensource [Anthony Olech]; Opensource [Steve Twiss]
> Subject: Re: [NEW DRIVER V6 0/7] DA9058 PMIC - please comment on this new
> driver
>
> Hi Anthony, Steve,
>
> This driver has been submitted a while ago and reached v6
Hi Anthony, Steve,
This driver has been submitted a while ago and reached v6 but still had
a few comments. Do you still have some interest in seeing it being
accepted?
On 19/04/2013 at 17:56:29 +0100, Anthony Olech wrote :
> This is submission attempt number 6 to have this driver included in
> th
On Fri, Jun 06, 2014 at 10:35:29PM +0400, Evgeniy Polyakov wrote:
> Hi everyone
>
> Greg, please pull this patch into the tree
Will do after 3.16-rc1 is out, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
Hi everyone
Greg, please pull this patch into the tree
06.06.2014, 21:47, "Scott Alfter" :
> On Thu, June 5, 2014 10:44, Evgeniy Polyakov wrote:
>> 04.06.2014, 08:25, "Scott Alfter" :
>>> I have a project for which I needed support for the DS2406 addressable
>>> switch, so I started with an ex
On Thu, June 5, 2014 10:44, Evgeniy Polyakov wrote:
> 04.06.2014, 08:25, "Scott Alfter" :
>> I have a project for which I needed support for the DS2406 addressable
>> switch, so I started with an existing driver and modified it as needed.
>> It allows the switch outputs to be controlled over the bu
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: 03 May 2013 12:59
> To: Opensource [Anthony Olech]
> Cc: Grant Likely; Linus Walleij; Mark Brown; LKML; Lee Jones
> Subject: Re: [NEW DRIVER V6 5/7] drivers/gpio: DA9058 GPIO driver
&
On Tue, Apr 30, 2013 at 6:17 PM, Opensource [Anthony Olech]
wrote:
> [Me]
>> > +struct da9058_gpio {
>> > + struct da9058 *da9058;
>> > + struct platform_device *pdev;
>> > + struct gpio_chip gp;
>> > + struct mutex lock;
>> > + int irq_0;
>> > + int irq_1;
>>
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: 24 April 2013 14:15
> To: Opensource [Anthony Olech]
> Cc: Grant Likely; Linus Walleij; Mark Brown; LKML; David Dajun Chen; Lee Jones
> Subject: Re: [NEW DRIVER V6 5/7] drivers/gpio:
On Fri, Apr 19, 2013 at 6:56 PM, Anthony Olech
wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the GPIO component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA90
On Tue, Apr 23, 2013 at 05:08:12AM +, Opensource [Anthony Olech] wrote:
> > No, you're totally missing the point here. Your regulator driver needs
> > to be generic and work on any machine using the device. This means you
> > can't specify any constraints, the constraints need to come from t
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: 22 April 2013 14:34
> To: Opensource [Anthony Olech]
> Cc: Samuel Ortiz; Arnd Bergmann; Mauro Carvalho Chehab; Steven Toth;
> Michael Krufky; LKML; David Dajun Chen
> Subject: Re: [NEW DRIVE
rk Brown; Randy Dunlap;
> > lm-sens...@lm-sensors.org; LKML; David Dajun Chen
> > Subject: Re: [NEW DRIVER V6 6/7] drivers/hwmon: DA9058 HWMON driver
> > On Fri, Apr 19, 2013 at 08:25:02PM +0200, Lars-Peter Clausen wrote:
> > > Same comment as before, I'd like to s
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 20 April 2013 18:35
> To: Lars-Peter Clausen
> Cc: Opensource [Anthony Olech]; Jean Delvare; Mark Brown; Randy Dunlap;
> lm-sens...@lm-sensors.org; LKML; David Dajun Chen
> Subject: R
On Fri, Apr 19, 2013 at 08:25:02PM +0200, Lars-Peter Clausen wrote:
> Same comment as before, I'd like to see this using the generic IIO to HWMON
> bridge instead of recreating it.
>
... and I agree. Seems we are getting more and more of those, and at some point
it makes really sense to find a gen
Same comment as before, I'd like to see this using the generic IIO to HWMON
bridge instead of recreating it.
On 04/19/2013 06:56 PM, Anthony Olech wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the HWMON component driver of the Dialog DA9058 PMIC.
> This driver is just
Same issues as in v5 plus one more ...
On 04/19/2013 06:56 PM, Anthony Olech wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the ADC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC
> driver. It depends on the DA9
Hi,
Looks almost good.
The patch subject prefix should be 'iio:adc:'. Different subsystems use
different styles for the subject prefix, so it's always to run a short git
log on the subsystems folder and take a look at what was used in the past.
On 04/17/2013 06:33 PM, Anthony Olech wrote:
> This
On Wed, Apr 17, 2013 at 05:33:36PM +0100, Anthony Olech wrote:
> This patch is relative to linux next-20130417
>
> This is the HWMON component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE and ADC component drivers o
On Wed, Apr 17, 2013 at 05:33:37PM +0100, Anthony Olech wrote:
> + reg->init.constraints.name = rpdata->regulator_name;
> + reg->init.constraints.min_uv = rpdata->min_uv;
> + reg->init.constraints.max_uv = rpdata->max_uv;
> + reg->init.constraints.valid_ops_mask = rpdata->valid_ops
On Wed, Apr 17, 2013 at 05:33:33PM +0100, Anthony Olech wrote:
> +static struct regulator_consumer_supply platform_vddarm_consumers[] = {
> + {.supply = "vcc",}
> +};
> +
This looks very system specific and should be done by the system
integration for the board not the MFD.
> +static struct
On Wed, 17 Apr 2013 17:33:35 +0100 Anthony Olech
wrote:
> This patch is relative to linux next-20130417
>
> This is the RTC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA9058 MF
On 04/16/2013 04:22 PM, Opensource [Anthony Olech] wrote:
>> [...]
>> please always test your drivers against the latest upstream version before
>> submitting them.
>> [...]
>
> Hi Lars,
>
> The driver was tested against linux mainline tag v3.9-rc6, because that was
> the most recent
> tagged c
ric
>> Andersson; Andrew Jones; linux-in...@vger.kernel.org; LKML; David Dajun Chen
>> Subject: Re: [NEW DRIVER V4 3/7] DA9058 ONKEY driver
>>
>> On 04/12/13 06:05, Anthony Olech wrote:
>>> This is the ONKEY component driver of the Dialog DA9058 PMIC.
>>> T
> [...]
> please always test your drivers against the latest upstream version before
> submitting them.
> [...]
Hi Lars,
The driver was tested against linux mainline tag v3.9-rc6, because that was the
most recent
tagged commit in
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 16 April 2013 14:36
> To: Opensource [Anthony Olech]
> Cc: LKML
> Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
>
> On Tue, Apr 16, 2013 at 09:17:27AM +, Opensource
On Tue, Apr 16, 2013 at 09:17:27AM +, Opensource [Anthony Olech] wrote:
> > -Original Message-
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Sent: 15 April 2013 18:46
> > To: Opensource [Anthony Olech]
> > Cc: LKML
> > Subject: Re: [NEW DR
; David Dajun Chen
> Subject: Re: [NEW DRIVER V4 3/7] DA9058 ONKEY driver
>
> On 04/12/13 06:05, Anthony Olech wrote:
> > This is the ONKEY component driver of the Dialog DA9058 PMIC.
> > This driver is just one component of the whole DA9058 PMIC driver.
> > It depends o
On Tue, Apr 16, 2013 at 09:18:41AM +, Opensource [Anthony Olech] wrote:
> The reason why they are separate is that they are probed with different data
> structures and they use a different wrapper to access the "regmap" API.
> However, that is not a blocking issue, but it would mean re-writing
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: 12 April 2013 14:27
> To: Opensource [Anthony Olech]
> Cc: Liam Girdwood; Guenter Roeck; Jean Delvare; Randy Dunlap; LKML; David
> Dajun Chen
> Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 12 April 2013 19:07
> To: Opensource [Anthony Olech]
> Cc: LKML; Alessandro Zummo
> Subject: Re: [NEW DRIVER V4 0/7] DA9058 PMIC - please comment on this new
> driver
> On Frid
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 15 April 2013 18:46
> To: Opensource [Anthony Olech]
> Cc: LKML
> Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
>
> On Mon, Apr 15, 2013 at 05:29:13PM +, Opensource
On Mon, Apr 15, 2013 at 05:29:13PM +, Opensource [Anthony Olech] wrote:
> > -Original Message-
> > From: Guenter Roeck [mailto:li...@roeck-us.net]
> > Sent: 15 April 2013 17:36
> > To: Opensource [Anthony Olech]
> > Cc: LKML
> > Subject: Re: [NEW DR
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 15 April 2013 17:36
> To: Opensource [Anthony Olech]
> Cc: LKML
> Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
>
> On Mon, Apr 15, 2013 at 03:00:58PM +, Opensource
od; Jean Delvare; Randy Dunlap; LKML; David
> > Dajun Chen
> > Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULATOR driver
> >
> > On Fri, Apr 12, 2013 at 02:05:28PM +0100, Anthony Olech wrote:
> > > This is the REGULATOR component driver of the Dialog DA9058 PMIC.
&g
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 12 April 2013 14:32
> To: Opensource [Anthony Olech]
> Cc: Mark Brown; Liam Girdwood; Jean Delvare; Randy Dunlap; LKML; David
> Dajun Chen
> Subject: Re: [NEW DRIVER V4 7/7] DA9058 REGULAT
On Fri, Apr 12, 2013 at 05:53:48PM +0200, Lars-Peter Clausen wrote:
> On 04/12/2013 03:05 PM, Anthony Olech wrote:
> > This is the HWMON component driver of the Dialog DA9058 PMIC.
> > This driver is just one component of the whole DA9058 PMIC driver.
> > It depends on the CORE and ADC component dr
On Fri, Apr 12, 2013 at 3:05 PM, Anthony Olech
wrote:
> This is the GPIO component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA9058 MFD.
> The meaning of the PMIC register 21 bits 1 and 5
On 04/12/13 06:05, Anthony Olech wrote:
> This is the ONKEY component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA9058 MFD.
>
> Signed-off-by: Anthony Olech
> Signed-off-by: David Dajun C
On Friday, April 12, 2013 02:05:29 PM Anthony Olech wrote:
> This is submission attempt number 4 to have this driver included in
> the linux kernel source tree. This is the driver for the Dialog DA9058.
>
> The DA9058 is a low power Power Management Integrated Circuit with extra
> functionality. I
On 04/12/2013 03:05 PM, Anthony Olech wrote:
> This is the ADC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC
> driver. It depends on the DA9058 CORE component driver.
> The HWMON component driver depends on this ADC component driver.
>
> T
On 04/12/2013 03:05 PM, Anthony Olech wrote:
> This is the HWMON component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE and ADC component drivers of the DA9058 MFD.
>
> Signed-off-by: Anthony Olech
> Signed-off-by:
On Fri, Apr 12, 2013 at 02:05:28PM +0100, Anthony Olech wrote:
> This is the HWMON component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE and ADC component drivers of the DA9058 MFD.
>
> Signed-off-by: Anthony Olech
On Fri, Apr 12, 2013 at 02:05:28PM +0100, Anthony Olech wrote:
> This is the REGULATOR component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA9058 MFD.
>
> There are 6 warnings from scripts
On Fri, Apr 12, 2013 at 02:05:28PM +0100, Anthony Olech wrote:
This looks good, I assume there's some dependencies on the MFD or other
earlier patches so I won't apply it, let me know if there aren't any and
I will:
Acked-by: Mark Brown
Please use subject lines reflecting the subsystem.
> +sta
On Mon, Sep 17, 2012 at 12:07:11PM +, Opensource [Anthony Olech] wrote:
> > > Can you suggest a future proofed way of using the new regulator API
> > > that would solve my problem?
> > As I said you should set the voltage as part of the set voltage operation.
> So I will have to write my own
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 17 September 2012 12:33
> To: Opensource [Anthony Olech]
> Cc: Liam Girdwood; Guenter Roeck; Jean Delvare; Randy Dunlap; LKML; David
> Dajun Chen
> Subject: Re: [NEW DRIVER V3
On Mon, Sep 17, 2012 at 11:23:54AM +, Opensource [Anthony Olech] wrote:
> Can you suggest a future proofed way of using the new regulator API that
> would solve my problem?
As I said you should set the voltage as part of the set voltage
operation.
--
To unsubscribe from this list: send the li
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 17 September 2012 12:16
> To: Opensource [Anthony Olech]
> Cc: Liam Girdwood; Guenter Roeck; Jean Delvare; Randy Dunlap; LKML; David
> Dajun Chen
> Subject: Re: [NEW DRIVER V3
On Mon, Sep 17, 2012 at 10:49:22AM +, Opensource [Anthony Olech] wrote:
> I thought that the set_voltage_sel = regulator_set_voltage_sel_regmap
> callback first
> set the target voltage, and that the set_voltage_time_sel =
> da9058_buck_ramp_voltage
> callback was called afterwards?
> was I
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 17 September 2012 11:40
> To: Opensource [Anthony Olech]
> Cc: Liam Girdwood; Guenter Roeck; Jean Delvare; Randy Dunlap; LKML; David
> Dajun Chen
> Subject: Re: [NEW DRIVER V3
On Mon, Sep 17, 2012 at 10:29:43AM +, Opensource [Anthony Olech] wrote:
> > Why is this function writing to the hardware, especially writing the same
> > value
> > every time?
> the ramp_register is DA9058_SUPPLY_REG and it is marked as volitile.
> Writing to the ramp enable bit starts the v
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 27 August 2012 17:51
> To: Opensource [Anthony Olech]
> Cc: Liam Girdwood; Guenter Roeck; Jean Delvare; Randy Dunlap; LKML; David
> Dajun Chen
> Subject: Re: [NEW DRIVER V3
On Wed, Aug 15, 2012 at 04:05:25PM +0100, Anthony Olech wrote:
> +static int da9058_buck_ramp_voltage(struct regulator_dev *rdev,
> + unsigned int old_selector,
> + unsigned int new_selector)
> +{
> + ret = da9058_set_bit
On Wed, Aug 15, 2012 at 04:05:22PM +0100, Anthony Olech wrote:
> This is the ONKEY component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA9058 MFD.
>
> Signed-off-by: Anthony Olech
> Signe
On Thu, Aug 16, 2012 at 11:34:56AM +, Opensource [Anthony Olech] wrote:
Fix your mail configuration to word wrap at something less than 80
columns within paragraphs, your mails are currently extremely hard to
read.
> The only other interpretation of your comment is that the h/w IRQ line setup
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 15 August 2012 19:53
> To: Opensource [Anthony Olech]
> Cc: Samuel Ortiz; Arnd Bergmann; Mauro Carvalho Chehab; Steven Toth;
> Michael Krufky; LKML; David Dajun Chen
> Subject:
On Wed, Aug 15, 2012 at 04:05:24PM +0100, Anthony Olech wrote:
> This is the HWMON component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE and ADC component drivers of the DA9058 MFD.
>
If so, please state as depende
On Wed, Aug 15, 2012 at 04:05:21PM +0100, Anthony Olech wrote:
>
> if HAS_IOMEM
> +
> menu "Multifunction device drivers"
This random change is still present from the first version
> + /*
> + * the init_board_irq() call-back function should be defined in
> + * the machine d
On 08/15/2012 05:05 PM, Anthony Olech wrote:
> This is the RTC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE component driver of the DA9058 MFD.
How much is this one actually different from the da9052 rtc c
On 08/15/2012 05:05 PM, Anthony Olech wrote:
> This is the ADC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC
> driver. It depends on the DA9058 CORE component driver.
> The HWMON and BATTERY component drivers depend on this ADC
> component
On Wed, Aug 15, 2012 at 12:08 PM, Opensource [Anthony Olech]
wrote:
> [Me]
>> > + if (offset > 1)
>> > + return -EINVAL;
>> So there are two GPIO pins, 0 and 1? That seems odd, but OK.
>
> That is a feature of the hardware. I believe that calling them "0" and
> "1" is the corr
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: 13 August 2012 14:10
> To: Opensource [Anthony Olech]
> Cc: Grant Likely; Linus Walleij; Mark Brown; LKML; David Dajun Chen; Samuel
> Ortiz; Lee Jones
> Subject: Re: [NEW DRIVER V2 5/
On Mon, Aug 13, 2012 at 03:09:31PM +0200, Linus Walleij wrote:
> On Sun, Aug 5, 2012 at 10:43 PM, Anthony Olech
> > +#include
> If you're using regmap you better select it in Kconfig
> too, but it appears you don't. You should be using regmap in the
> main MFD driver in this case (I haven't look
Hi Anthony, sorry for delayed reply...
On Sun, Aug 5, 2012 at 10:43 PM, Anthony Olech
wrote:
> This is the GPIO component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the core DA9058 MFD driver.
OK
> +config GPIO_DA9058
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 07 August 2012 18:15
> To: Opensource [Anthony Olech]
> Cc: LKML
> Subject: Re: [NEW DRIVER V1 5/7] DA9058 GPIO driver
> On Mon, Aug 06, 2012 at 03:15:17PM +, Opensource [A
On Mon, Aug 06, 2012 at 03:15:17PM +, Opensource [Anthony Olech] wrote:
> I do realize that REGMAP does locking on individual register accesses,
> however, the each GPIO line is controlled by 4-bits in a register, with
> the meaning of the most significant bit depending on the GPIO direction,
al Message-
From: Venu Byravarasu [mailto:vbyravar...@nvidia.com]
Sent: 06 August 2012 09:38
To: Opensource [Anthony Olech]; Samuel Ortiz
Cc: Mark Brown; Arnd Bergmann; Mauro Carvalho Chehab; Steven Toth; Michael
Krufky; LKML; David Dajun Chen
Subject: RE: [NEW DRIVER V2 1/7] DA9058 MFD core and
why a driver mutex is required
in addition to the regmap's register access mutex
Tony Olech
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: 02 August 2012 11:20
To: Opensource [Anthony Olech]
Cc: LKML
Subject: Re: [NEW DRIVER V1 5/7] DA9058 GPIO d
On Sun, Aug 05, 2012 at 09:43:44PM +0100, Anthony Olech wrote:
> This is the REGULATOR component driver of the Dialog DA9058 PMIC.
Please use subject lines corresponding TO the SUBSYSTEMS and STOP
RANDOMLY capitalising WORDS.
> +static int da9058_buck_ramp_voltage(struct regulator_dev *rdev,
> +
On Sun, Aug 05, 2012 at 09:43:42PM +0100, Anthony Olech wrote:
> @@ -3,6 +3,7 @@
> #
>
> if HAS_IOMEM
> +
> menu "Multifunction device drivers"
Hrm?
> +static int da9058_automatic_adc_conversion(struct da9058 *da9058,
> + const int channel, int *value)
> +{
I se
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Anthony Olech
> Sent: Monday, August 06, 2012 2:14 AM
> To: Andrew Morton
> Cc: Mark Brown; Paul Gortmaker; Samuel Ortiz; Alessandro Zummo; rtc-
> li...@googlegroups.
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Anthony Olech
> Sent: Monday, August 06, 2012 2:14 AM
> To: Samuel Ortiz
> Cc: Mark Brown; Arnd Bergmann; Mauro Carvalho Chehab; Steven Toth;
> Michael Krufky; LKML; D
Hi Tony,
> for your very helpful comments on all on the patches in this first submission
> attempt, I will digest and regurgitate a second attempt as soon as I can.
once you have digested and regurgitated :), you could also split
the patchset in smaller patches, I would say at least one patch
pe
On Thu, Aug 02, 2012 at 09:48:56AM +0100, Anthony Olech wrote:
> -comment "I2C RTC drivers"
> - depends on I2C
> -
> -if I2C
> -
> config RTC_DRV_88PM860X
> tristate "Marvell 88PM860x"
> depends on RTC_CLASS && I2C && MFD_88PM860X
> @@ -135,6 +130,21 @@ config RTC_DRV_88PM860X
>
August 2012 11:17
To: Opensource [Anthony Olech]
Cc: LKML
Subject: Re: [NEW DRIVER V1 0/7] please comment on this new PMIC driver
On Thu, Aug 02, 2012 at 09:48:58AM +0100, Anthony Olech wrote:
> This is submission attempt number 1 to have this driver included in
> the linux kernel source tree. T
On Thu, Aug 02, 2012 at 09:48:58AM +0100, Anthony Olech wrote:
Overall the big issue here is that the driver isn't making much use of
framework features, there should be a *lot* less code here.
> +static unsigned int da9058_regulator_val_to_mvolts(unsigned int val,
> +
On Thu, Aug 02, 2012 at 09:48:57AM +0100, Anthony Olech wrote:
> + mutex_lock(&gpio->lock);
> + ret = da9058_reg_read(da9058, DA9058_STATUSC_REG, &gpio_level);
> + mutex_unlock(&gpio->lock);
regmap already does locking for you.
> + ret = da9058_reg_read(da9058, DA9058_GPIO0001_RE
On Thu, Aug 02, 2012 at 09:48:58AM +0100, Anthony Olech wrote:
> This is submission attempt number 1 to have this driver included in
> the linux kernel source tree. This is the driver for the Dialog DA9058.
I just noticed that you haven't CCed the maintainers for most of this
stuff on your patches
On Thu, Aug 02, 2012 at 09:48:55AM +0100, Anthony Olech wrote:
> +#if 0
> + return regmap_bulk_read(da9058->regmap, reg, val, val_count);
> +#else
> + int ret = regmap_bulk_read(da9058->regmap, reg, val, val_count);
> + return ret;
> +#endif
This shouldn't be going into mainline...
>
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I've just completed the first draft of a new device driver for the FarSite
> Communications, FarSync T2P and T4P cards. These cards are intelligent
> synchronous serial cards supporting 2 or 4 ports running at up to 8Mbps with
> X.21, V.35 or V.24 signalling
>
> On Thu, 28 Dec 2000 22:19:37 +0100 (CET),
> [EMAIL PROTECTED] wrote:
> >I wanted to share what I've done but since I'm very new to kernel hacking
> >I don't know what to do with my patch. Could you give me some hints?
>
> linux/Documentation/SubmittingPatches
>
Ok. Since it's a new catego
On Thu, 28 Dec 2000 22:19:37 +0100 (CET),
[EMAIL PROTECTED] wrote:
>I wanted to share what I've done but since I'm very new to kernel hacking
>I don't know what to do with my patch. Could you give me some hints?
linux/Documentation/SubmittingPatches
-
To unsubscribe from this list: send the lin
Bartlomiej Zolnierkiewicz wrote:
> You may also consider processing firestream.[ch] through indent because
> spacing is inconsistent - sometimes tabs, sometimes 8*space (it would
> be nice too have tabs everywhere).
As far as I know the tabs/spaces are exactly the way I want them.
There are tab
Hi!
Just a few hints on __init/__exit stuff...
On Wed, 22 Nov 2000, Patrick van de Lageweg wrote:
> +struct reginit_item PHY_NTC_INIT[] = {
Can be marked __initdata
> +void undocumented_pci_fix (struct pci_dev *pdev)
Can be marked __init
> +void write_phy (struct fs_dev *dev, int regnum, i
Peter Samuelson wrote:
>
> [Rogier Wolff]
> > > > +MODULE_PARM(fs_debug, "i");
> > >
> > > There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
> > anymore in 2.4
>^^^2.2
>
> Verified in 2.2.0 (the oldest tree I hav
[Rogier Wolff]
> > > +MODULE_PARM(fs_debug, "i");
> >
> > There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
> anymore in 2.4
^^^2.2
Verified in 2.2.0 (the oldest tree I have).
Peter
-
To unsubscribe from this lis
Mitchell Blank Jr wrote:
> * I don't like header files that define the registers of the chip - since
> the header file is only included in the driver's .c
For a non-hypothetical case why it makes sense to have such things in
their own header file: if you dig out some older versions of the A
Mitchell Blank Jr wrote:
> > +MODULE_PARM(fs_debug, "i");
>
> There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
anymore in 2.4
OK.
> > +#define MIN(a,b) (((a)<(b))?(a):(b))
>
> You don't seem to ever use this definition.
H. Used to though..
On Thu, Nov 23, 2000 at 09:22:09AM +0100, Rogier Wolff wrote:
> Peter Samuelson wrote:
>
> > > +int loopback = 0;
> > > +int fs_debug = 0;
> > > +struct fs_dev *fs_boards = NULL;
>
> > Aside from the 'static' issue already mentioned, these should be left
> > uninitialized. ('gcc -fassume-bss-z
[Rogier Wolff <[EMAIL PROTECTED]>]
> However, if my code assumes that the compiler needs to initialize the
kernel
> variable one way or another, I want to put in the initialization,
> even if that means an "= 0;" which is already the default.
Well,
Peter Samuelson wrote:
> > +int loopback = 0;
> > +int fs_debug = 0;
> > +struct fs_dev *fs_boards = NULL;
> Aside from the 'static' issue already mentioned, these should be left
> uninitialized. ('gcc -fassume-bss-zero' would be nice, but then again
> in userspace it rarely matters.)
Hi Pete
[Patrick van de Lageweg]
> diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c
>linux-2.4.0-test11.fs50+atmrefcount/drivers/atm/firestream.c
Since you are submitting in the form of a source patch, you ought to
include the relevent bits of
drivers/atm/Makefile
drivers/at
Jes Sorensen wrote:
> I think the most important issue is when doing header files to make
> sure they go with the driver code and not in include/linux unless
> there really is a reason to expose them to user space. No reason to
> export register definitions for Ethernet cards down there.
Agreed,
1 - 100 of 103 matches
Mail list logo
