On Mon, Mar 10, 2014 at 3:11 PM, Guenter Roeck wrote:
> On Mon, Mar 10, 2014 at 01:50:01PM +0000, Laszlo Papp wrote:
>> On Mon, Mar 10, 2014 at 1:26 PM, Guenter Roeck wrote:
>> > On 03/10/2014 02:59 AM, Laszlo Papp wrote:
>> >>>
>> >>> The
On Mon, Mar 10, 2014 at 1:26 PM, Guenter Roeck wrote:
> On 03/10/2014 02:59 AM, Laszlo Papp wrote:
>>>
>>> The reason is (most likely) that your fan input does not have a pull-up
>>> resistor. Per datasheet, the fan inputs need a 10kOhm pull-up resistor. I
>>
> The reason is (most likely) that your fan input does not have a pull-up
> resistor. Per datasheet, the fan inputs need a 10kOhm pull-up resistor. I
> confirmed this with my test board - with the pull-up resistor, inputs read 0,
> Without pull-up, the reported value is 1, which translates to
The reason is (most likely) that your fan input does not have a pull-up
resistor. Per datasheet, the fan inputs need a 10kOhm pull-up resistor. I
confirmed this with my test board - with the pull-up resistor, inputs read 0,
Without pull-up, the reported value is 1, which translates to 30
On Mon, Mar 10, 2014 at 1:26 PM, Guenter Roeck li...@roeck-us.net wrote:
On 03/10/2014 02:59 AM, Laszlo Papp wrote:
The reason is (most likely) that your fan input does not have a pull-up
resistor. Per datasheet, the fan inputs need a 10kOhm pull-up resistor. I
confirmed this with my test
On Mon, Mar 10, 2014 at 3:11 PM, Guenter Roeck li...@roeck-us.net wrote:
On Mon, Mar 10, 2014 at 01:50:01PM +, Laszlo Papp wrote:
On Mon, Mar 10, 2014 at 1:26 PM, Guenter Roeck li...@roeck-us.net wrote:
On 03/10/2014 02:59 AM, Laszlo Papp wrote:
The reason is (most likely) that your
On Sun, Mar 9, 2014 at 8:04 AM, Guenter Roeck wrote:
> On 03/08/2014 10:36 PM, Laszlo Papp wrote:
>>
>> On Sat, Mar 8, 2014 at 11:50 PM, Guenter Roeck wrote:
>>>
>>> On 03/07/2014 10:17 AM, Guenter Roeck wrote:
>>>>
>>>>
>>
On Sun, Mar 9, 2014 at 8:04 AM, Guenter Roeck li...@roeck-us.net wrote:
On 03/08/2014 10:36 PM, Laszlo Papp wrote:
On Sat, Mar 8, 2014 at 11:50 PM, Guenter Roeck li...@roeck-us.net wrote:
On 03/07/2014 10:17 AM, Guenter Roeck wrote:
On Fri, Mar 07, 2014 at 03:47:08PM +, Laszlo Papp
On Sat, Mar 8, 2014 at 11:50 PM, Guenter Roeck wrote:
> On 03/07/2014 10:17 AM, Guenter Roeck wrote:
>>
>> On Fri, Mar 07, 2014 at 03:47:08PM +0000, Laszlo Papp wrote:
>>>
>>> On Fri, Mar 7, 2014 at 3:37 PM, Jean Delvare wrote:
>>>>>>
>
On Sat, Mar 8, 2014 at 11:50 PM, Guenter Roeck li...@roeck-us.net wrote:
On 03/07/2014 10:17 AM, Guenter Roeck wrote:
On Fri, Mar 07, 2014 at 03:47:08PM +, Laszlo Papp wrote:
On Fri, Mar 7, 2014 at 3:37 PM, Jean Delvare jdelv...@suse.de wrote:
I'm quite confused. While I admit
On Fri, Mar 7, 2014 at 3:37 PM, Jean Delvare wrote:
>> > I'm quite confused. While I admit that the term "tachometer speed" is
>> > awkward, the max6650 driver is reporting fan speeds in RPM as every
>> > other hwmon driver. So I really have no idea what you think is wrong.
>> > What did you
Ping?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, Mar 7, 2014 at 3:25 PM, Jean Delvare wrote:
> Hi Laszlo,
>
> On Fri, 7 Mar 2014 14:48:01 +0000, Laszlo Papp wrote:
>> In medias res, I find this interface cumbersome:
>> http://lxr.free-electrons.com/source/Documentation/hwmon/max6650#L31
>>
>> It ret
On Fri, Mar 7, 2014 at 2:48 PM, Laszlo Papp wrote:
> Hi,
>
> In medias res, I find this interface cumbersome:
> http://lxr.free-electrons.com/source/Documentation/hwmon/max6650#L31
>
> It returns tachometer speed rather than actual fan speed when you deal
> with the
Hi,
In medias res, I find this interface cumbersome:
http://lxr.free-electrons.com/source/Documentation/hwmon/max6650#L31
It returns tachometer speed rather than actual fan speed when you deal
with the fan1_target interface. That would be way more convenient for
end users like me.
Is there any
Hi,
In medias res, I find this interface cumbersome:
http://lxr.free-electrons.com/source/Documentation/hwmon/max6650#L31
It returns tachometer speed rather than actual fan speed when you deal
with the fan1_target interface. That would be way more convenient for
end users like me.
Is there any
On Fri, Mar 7, 2014 at 2:48 PM, Laszlo Papp lp...@kde.org wrote:
Hi,
In medias res, I find this interface cumbersome:
http://lxr.free-electrons.com/source/Documentation/hwmon/max6650#L31
It returns tachometer speed rather than actual fan speed when you deal
with the fan1_target interface
On Fri, Mar 7, 2014 at 3:25 PM, Jean Delvare jdelv...@suse.de wrote:
Hi Laszlo,
On Fri, 7 Mar 2014 14:48:01 +, Laszlo Papp wrote:
In medias res, I find this interface cumbersome:
http://lxr.free-electrons.com/source/Documentation/hwmon/max6650#L31
It returns tachometer speed rather than
Ping?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, Mar 7, 2014 at 3:37 PM, Jean Delvare jdelv...@suse.de wrote:
I'm quite confused. While I admit that the term tachometer speed is
awkward, the max6650 driver is reporting fan speeds in RPM as every
other hwmon driver. So I really have no idea what you think is wrong.
What did you
On Fri, Feb 21, 2014 at 6:43 AM, Laszlo Papp wrote:
> Hi,
>
> we are currently having some implementation of it for an older kernel,
> and I was just wondering if it is worth upstreaming, or the latest
> linux kernel already has support for it, and we can drop our code
> respec
Hi,
we are currently having some implementation of it for an older kernel,
and I was just wondering if it is worth upstreaming, or the latest
linux kernel already has support for it, and we can drop our code
respectively?
I have seen the "./drivers/pwm/pwm-tiecap.c" file, but it seems to be
Hi,
we are currently having some implementation of it for an older kernel,
and I was just wondering if it is worth upstreaming, or the latest
linux kernel already has support for it, and we can drop our code
respectively?
I have seen the ./drivers/pwm/pwm-tiecap.c file, but it seems to be
On Fri, Feb 21, 2014 at 6:43 AM, Laszlo Papp lp...@kde.org wrote:
Hi,
we are currently having some implementation of it for an older kernel,
and I was just wondering if it is worth upstreaming, or the latest
linux kernel already has support for it, and we can drop our code
respectively?
I
On Fri, Feb 14, 2014 at 8:57 PM, Mark Brown wrote:
> On Fri, Feb 14, 2014 at 09:02:20AM +0000, Laszlo Papp wrote:
>> On Wed, Feb 12, 2014 at 5:50 PM, Mark Brown wrote:
>> > On Wed, Feb 12, 2014 at 04:02:40AM +, Laszlo Papp wrote:
>
>> >> +const struct re
On Fri, Feb 14, 2014 at 8:57 PM, Mark Brown broo...@kernel.org wrote:
On Fri, Feb 14, 2014 at 09:02:20AM +, Laszlo Papp wrote:
On Wed, Feb 12, 2014 at 5:50 PM, Mark Brown broo...@kernel.org wrote:
On Wed, Feb 12, 2014 at 04:02:40AM +, Laszlo Papp wrote:
+const struct regmap_config
On Fri, Feb 14, 2014 at 10:19 AM, Lee Jones wrote:
>> >> + mutex_init(>iolock);
>> >
>> > What is this needed for?
>>
>> It was done for consistency with the other mfd drivers (maxim), e.g.
>> 8997 or 8998 as the closest resemblence in this family. Would you
>> prefer me removing this mutex
On Fri, Feb 14, 2014 at 9:02 AM, Lee Jones wrote:
>> >> http://comments.gmane.org/gmane.linux.kernel/1645251
>> >>
>> >> Step 2 did not happen. I did not get any review for my change. I
>> >> literally submitted that within a couple of hours after the request.
>> >>
>> >> Could you please tell me
The MFD driver has now been added, so this driver is now being adopted to be a
subdevice driver on top of it. This means, the i2c driver usage is being
converted to platform driver usage all around.
Signed-off-by: Laszlo Papp
---
drivers/hwmon/Kconfig | 2 +-
drivers/hwmon/max6650.c | 125
, and then the gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 94 +
include/linux/mfd/max665x-private.h | 34 ++
4 files changed
Yet to be run-time tested, but early reviews are welcome to catch any obvious
mistakes that are potentially hard and time-consuming to debug.
Laszlo Papp (2):
mfd: MAX6650/6651 support
hwmon: (max6650) Convert to be a platform driver
drivers/hwmon/Kconfig | 2 +-
drivers
On Wed, Feb 12, 2014 at 5:50 PM, Mark Brown wrote:
> On Wed, Feb 12, 2014 at 04:02:40AM +0000, Laszlo Papp wrote:
>
>> +const struct regmap_config max665x_regmap_config = {
>> + .reg_bits = 5,
>> +};
>
> This would normally be static too, and I'd *really* expec
On Wed, Feb 12, 2014 at 5:50 PM, Mark Brown broo...@kernel.org wrote:
On Wed, Feb 12, 2014 at 04:02:40AM +, Laszlo Papp wrote:
+const struct regmap_config max665x_regmap_config = {
+ .reg_bits = 5,
+};
This would normally be static too, and I'd *really* expect to see a
val_bits set
Yet to be run-time tested, but early reviews are welcome to catch any obvious
mistakes that are potentially hard and time-consuming to debug.
Laszlo Papp (2):
mfd: MAX6650/6651 support
hwmon: (max6650) Convert to be a platform driver
drivers/hwmon/Kconfig | 2 +-
drivers
, and then the gpio devices for now.
Signed-off-by: Laszlo Papp lp...@kde.org
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 94 +
include/linux/mfd/max665x-private.h | 34 ++
4
The MFD driver has now been added, so this driver is now being adopted to be a
subdevice driver on top of it. This means, the i2c driver usage is being
converted to platform driver usage all around.
Signed-off-by: Laszlo Papp lp...@kde.org
---
drivers/hwmon/Kconfig | 2 +-
drivers/hwmon
On Fri, Feb 14, 2014 at 9:02 AM, Lee Jones lee.jo...@linaro.org wrote:
http://comments.gmane.org/gmane.linux.kernel/1645251
Step 2 did not happen. I did not get any review for my change. I
literally submitted that within a couple of hours after the request.
Could you please tell me
On Fri, Feb 14, 2014 at 10:19 AM, Lee Jones lee.jo...@linaro.org wrote:
+ mutex_init(max665x-iolock);
What is this needed for?
It was done for consistency with the other mfd drivers (maxim), e.g.
8997 or 8998 as the closest resemblence in this family. Would you
prefer me removing
On Thu, Feb 13, 2014 at 12:40 PM, Lee Jones wrote:
>> http://comments.gmane.org/gmane.linux.kernel/1645251
>>
>> Step 2 did not happen. I did not get any review for my change. I
>> literally submitted that within a couple of hours after the request.
>>
>> Could you please tell me what was wrong
Ping? Fwiw, this change has been submitted a bit less two months ago,
and it has not still received any feedback from the hwmon maintainers.
On Mon, Dec 23, 2013 at 4:08 PM, Laszlo Papp wrote:
> The MFD driver has now been added, so this driver is now being adopted to be a
> subdevice
On Thu, Feb 13, 2014 at 4:16 PM, Guenter Roeck wrote:
> On 02/13/2014 04:27 AM, Laszlo Papp wrote:
>>
>> On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones wrote:
>>>>>>>>
>>>>>>>> -static int max6650_probe(struct i2c_client *clien
On Thu, Feb 13, 2014 at 12:57 PM, Jean Delvare wrote:
> Hi Laszlo,
>
> On Thu, 13 Feb 2014 12:27:28 +0000, Laszlo Papp wrote:
>> On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones wrote:
>> > Right, I've had enough. I'm removing your patch from the MFD tree.
>> >
>&g
On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones wrote:
>> >>> > -static int max6650_probe(struct i2c_client *client,
>> >>> > -const struct i2c_device_id *id);
>> >>> > -static int max6650_init_client(struct i2c_client *client);
>> >>> > -static int max6650_remove(struct
I will try hard to concentrate on the technical and fruitful stuff in
the reply...
On Thu, Feb 13, 2014 at 11:07 AM, Jean Delvare wrote:
> Hi Laszlo,
>
> Le Thursday 13 February 2014 à 10:46 +0000, Laszlo Papp a écrit :
>> On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp wrote:
>
On Thu, Feb 13, 2014 at 9:58 AM, Lee Jones wrote:
>> The MFD driver has now been added, so this driver is now being adopted to be
>> a
>> subdevice driver on top of it. This means, the i2c driver usage is being
>> converted to platform driver usage all around.
>>
On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp wrote:
> On Thu, Feb 13, 2014 at 10:15 AM, Jean Delvare wrote:
>> On Thu, 13 Feb 2014 09:58:17 +, Lee Jones wrote:
>>> > The MFD driver has now been added, so this driver is now being adopted to
>>> > b
usage is being
>> > converted to platform driver usage all around.
>> >
>> > Signed-off-by: Laszlo Papp
>> > ---
>> > This patch has been compile tested only and will be tested with real
>> > hardware,
>> > but early reviews to catch an
On Thu, Feb 13, 2014 at 9:14 AM, Laszlo Papp wrote:
> On Thu, Feb 13, 2014 at 8:23 AM, Lee Jones wrote:
>> Laszlo,
>>
>>> > +const struct regmap_config max665x_regmap_config = {
>>> > + .reg_bits = 5,
>>> > +};
>>>
>>&
On Thu, Feb 13, 2014 at 8:23 AM, Lee Jones wrote:
> Laszlo,
>
>> > +const struct regmap_config max665x_regmap_config = {
>> > + .reg_bits = 5,
>> > +};
>>
>> This would normally be static too, and I'd *really* expect to see a
>> val_bits set here. I'm a bit surprised this works without one.
>
The MFD driver has now been added, so this driver is now being adopted to be a
subdevice driver on top of it. This means, the i2c driver usage is being
converted to platform driver usage all around.
Signed-off-by: Laszlo Papp
---
This patch has been compile tested only and will be tested
The MFD driver has now been added, so this driver is now being adopted to be a
subdevice driver on top of it. This means, the i2c driver usage is being
converted to platform driver usage all around.
Signed-off-by: Laszlo Papp lp...@kde.org
---
This patch has been compile tested only
On Thu, Feb 13, 2014 at 8:23 AM, Lee Jones lee.jo...@linaro.org wrote:
Laszlo,
+const struct regmap_config max665x_regmap_config = {
+ .reg_bits = 5,
+};
This would normally be static too, and I'd *really* expect to see a
val_bits set here. I'm a bit surprised this works without one.
On Thu, Feb 13, 2014 at 9:14 AM, Laszlo Papp lp...@kde.org wrote:
On Thu, Feb 13, 2014 at 8:23 AM, Lee Jones lee.jo...@linaro.org wrote:
Laszlo,
+const struct regmap_config max665x_regmap_config = {
+ .reg_bits = 5,
+};
This would normally be static too, and I'd *really* expect to see
to platform driver usage all around.
Signed-off-by: Laszlo Papp lp...@kde.org
---
This patch has been compile tested only and will be tested with real
hardware,
but early reviews to catch any trivial issues would be welcome.
drivers/hwmon/Kconfig | 2 +-
drivers/hwmon/max6650.c
On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp lp...@kde.org wrote:
On Thu, Feb 13, 2014 at 10:15 AM, Jean Delvare jdelv...@suse.de wrote:
On Thu, 13 Feb 2014 09:58:17 +, Lee Jones wrote:
The MFD driver has now been added, so this driver is now being adopted to
be a
subdevice driver
On Thu, Feb 13, 2014 at 9:58 AM, Lee Jones lee.jo...@linaro.org wrote:
The MFD driver has now been added, so this driver is now being adopted to be
a
subdevice driver on top of it. This means, the i2c driver usage is being
converted to platform driver usage all around.
Signed-off-by: Laszlo
I will try hard to concentrate on the technical and fruitful stuff in
the reply...
On Thu, Feb 13, 2014 at 11:07 AM, Jean Delvare jdelv...@suse.de wrote:
Hi Laszlo,
Le Thursday 13 February 2014 à 10:46 +, Laszlo Papp a écrit :
On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp lp...@kde.org
On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones lee.jo...@linaro.org wrote:
-static int max6650_probe(struct i2c_client *client,
-const struct i2c_device_id *id);
-static int max6650_init_client(struct i2c_client *client);
-static int max6650_remove(struct i2c_client
On Thu, Feb 13, 2014 at 12:57 PM, Jean Delvare jdelv...@suse.de wrote:
Hi Laszlo,
On Thu, 13 Feb 2014 12:27:28 +, Laszlo Papp wrote:
On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones lee.jo...@linaro.org wrote:
Right, I've had enough. I'm removing your patch from the MFD tree.
I've asked
On Thu, Feb 13, 2014 at 4:16 PM, Guenter Roeck li...@roeck-us.net wrote:
On 02/13/2014 04:27 AM, Laszlo Papp wrote:
On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones lee.jo...@linaro.org wrote:
-static int max6650_probe(struct i2c_client *client,
-const struct i2c_device_id *id
Ping? Fwiw, this change has been submitted a bit less two months ago,
and it has not still received any feedback from the hwmon maintainers.
On Mon, Dec 23, 2013 at 4:08 PM, Laszlo Papp lp...@kde.org wrote:
The MFD driver has now been added, so this driver is now being adopted to be a
subdevice
On Thu, Feb 13, 2014 at 12:40 PM, Lee Jones lee.jo...@linaro.org wrote:
http://comments.gmane.org/gmane.linux.kernel/1645251
Step 2 did not happen. I did not get any review for my change. I
literally submitted that within a couple of hours after the request.
Could you please tell me what was
On Wed, Feb 12, 2014 at 9:23 AM, Lee Jones wrote:
>> "to support for" is incorrect English in here, hence the change to "to add
>> support".
>>
>> Signed-off-by: Laszlo Papp
>> ---
>> drivers/mfd/Kconfig | 16
>>
On Wed, Feb 12, 2014 at 8:32 AM, Lee Jones wrote:
>> >> + max665x->map = devm_regmap_init_i2c(i2c, _regmap_config);
>> >
>> > Don't you need to check the return value of devm_regmap_init_i2c?
>>
>> I personally think I should. I strived for consistency though with
>> other similar drivers.
t; supports to enable the chip with its primary I2C bus that will connect
>> the hwmon, and then the gpio devices for now.
>>
>> Signed-off-by: Laszlo Papp
>> ---
>> drivers/mfd/Kconfig | 11 +
>> drivers/mfd/Makefile
On Wed, Feb 12, 2014 at 8:32 AM, Lee Jones lee.jo...@linaro.org wrote:
+ max665x-map = devm_regmap_init_i2c(i2c, max665x_regmap_config);
Don't you need to check the return value of devm_regmap_init_i2c?
I personally think I should. I strived for consistency though with
other similar
the chip with its primary I2C bus that will connect
the hwmon, and then the gpio devices for now.
Signed-off-by: Laszlo Papp lp...@kde.org
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 93
On Wed, Feb 12, 2014 at 9:23 AM, Lee Jones lee.jo...@linaro.org wrote:
to support for is incorrect English in here, hence the change to to add
support.
Signed-off-by: Laszlo Papp lp...@kde.org
---
drivers/mfd/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions
Signed-off-by: Laszlo Papp
---
Documentation/devicetree/bindings/leds/leds-gpio.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index df1b308..00e94fe 100644
, and then the gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 93 +
include/linux/mfd/max665x-private.h | 34 ++
4 files changed
On Wed, Feb 12, 2014 at 4:42 AM, Sachin Kamat wrote:
> Hi Laszlo,
>
> Sorry for missing out on a couple of points during my earlier review.
> Please see inline.
Np.
> On 12 February 2014 09:32, Laszlo Papp wrote:
>> MAX6650/MAX6651 chip is a multi-function device with I2
, and then the gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 87 +
include/linux/mfd/max665x-private.h | 34 +++
4 files
On Tue, Feb 11, 2014 at 9:57 AM, Lee Jones wrote:
>> >> Time to revisit this decision
>> >>
>> >> So, based on the fact that children device names usually contain
>> >> dashes, I do not understand why hwmon would be any special in this
>> >> regard. It is possible that the hwmon developers
On Sat, Jan 25, 2014 at 12:23 AM, Andy Lutomirski wrote:
> On 01/23/2014 11:16 AM, Curt Brune wrote:
>> Create a new hardware class under /sys/class/eeprom_dev
>>
>> EEPROM drivers can register their devices with the eeprom_dev class
>> during instantiation.
>>
>> The registered devices show up
On Tue, Feb 11, 2014 at 11:42 AM, Sachin Kamat wrote:
> On 11 February 2014 17:09, Laszlo Papp wrote:
>> On Tue, Feb 11, 2014 at 11:14 AM, Sachin Kamat
>> wrote:
>>> On 11 February 2014 15:40, Laszlo Papp wrote:
>>>>>>> [snip]
>>>>>
On Tue, Feb 11, 2014 at 11:14 AM, Sachin Kamat wrote:
> On 11 February 2014 15:40, Laszlo Papp wrote:
>>>>> [snip]
>>>>>> +
>>>>>> +struct max665x_dev {
>>>>>> + struct device *dev;
>>>>>> +
On Tue, Feb 11, 2014 at 10:22 AM, Laszlo Papp wrote:
> On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones wrote:
>>> >> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>>> >> > Additionally, dashes are explicitly forbidden in hwmon
>>>
This is a necessary step to revamp the existing design of the driver for the
overall functionality the chip can provide. This will create a clean name-space
for each function.
Signed-off-by: Laszlo Papp
---
drivers/hwmon/max6650.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions
This is a necessary step to revamp the existing design of the driver for the
overall functionality the chip can provide. This will create a clean name-space
for each function.
Signed-off-by: Laszlo Papp
---
drivers/hwmon/max6650.c | 10 --
1 file changed, 8 insertions(+), 2 deletions
On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones wrote:
>> >> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>> >> > Additionally, dashes are explicitly forbidden in hwmon
>> >> > device names.
>> >>
>> >> Also, where is that documented?
>> >
>> > In Documentation/hwmon/sysfs-interface:
>> >
>>
>>> [snip]
+
+struct max665x_dev {
+ struct device *dev;
+ struct mutex iolock;
+
+ struct i2c_client *i2c;
+ struct regmap *map;
+
+ int type;
>>>
>>> Unnecessary extra lines above could be removed.
>>
>> I prefer it
On Tue, Feb 11, 2014 at 9:47 AM, Lee Jones wrote:
>> >> >> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>> >> >> > Additionally, dashes are explicitly forbidden in hwmon
>> >> >> > device names.
>> >> >>
>> >> >> Also, where is that documented?
>> >> >
>> >> > In
On Tue, Feb 11, 2014 at 8:58 AM, Laszlo Papp wrote:
> On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones wrote:
>>> >> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>>> >> > Additionally, dashes are explicitly forbidden in hwmon
>>> >> > devi
On Tue, Feb 11, 2014 at 8:49 AM, Jean Delvare wrote:
> Le Tuesday 11 February 2014 à 08:28 +0000, Laszlo Papp a écrit :
>> On Tue, Feb 11, 2014 at 7:50 AM, Jean Delvare wrote:
>> > Hi Laszlo,
>> >
>> > On Tue, 11 Feb 2014 03:13:37 +, Laszlo Papp wrote:
&
On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones wrote:
>> >> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>> >> > Additionally, dashes are explicitly forbidden in hwmon
>> >> > device names.
>> >>
>> >> Also, where is that documented?
>> >
>> > In Documentation/hwmon/sysfs-interface:
>> >
>>
On Tue, Feb 11, 2014 at 7:50 AM, Jean Delvare wrote:
> Hi Laszlo,
>
> On Tue, 11 Feb 2014 03:13:37 +0000, Laszlo Papp wrote:
>> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>> > Additionally, dashes are explicitly forbidden in hwmon
>> > device names.
>
On Tue, Feb 11, 2014 at 7:50 AM, Jean Delvare wrote:
> Hi Laszlo,
>
> On Tue, 11 Feb 2014 03:13:37 +0000, Laszlo Papp wrote:
>> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>> > Additionally, dashes are explicitly forbidden in hwmon
>> > device names.
>
On Tue, Feb 11, 2014 at 7:50 AM, Jean Delvare jdelv...@suse.de wrote:
Hi Laszlo,
On Tue, 11 Feb 2014 03:13:37 +, Laszlo Papp wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also, where
On Tue, Feb 11, 2014 at 7:50 AM, Jean Delvare jdelv...@suse.de wrote:
Hi Laszlo,
On Tue, 11 Feb 2014 03:13:37 +, Laszlo Papp wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also, where
On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also, where is that documented?
In Documentation/hwmon/sysfs-interface:
On Tue, Feb 11, 2014 at 8:49 AM, Jean Delvare jdelv...@suse.de wrote:
Le Tuesday 11 February 2014 à 08:28 +, Laszlo Papp a écrit :
On Tue, Feb 11, 2014 at 7:50 AM, Jean Delvare jdelv...@suse.de wrote:
Hi Laszlo,
On Tue, 11 Feb 2014 03:13:37 +, Laszlo Papp wrote:
On Mon, Feb 10
On Tue, Feb 11, 2014 at 8:58 AM, Laszlo Papp lp...@kde.org wrote:
On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also
On Tue, Feb 11, 2014 at 9:47 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also, where is that documented?
In
[snip]
+
+struct max665x_dev {
+ struct device *dev;
+ struct mutex iolock;
+
+ struct i2c_client *i2c;
+ struct regmap *map;
+
+ int type;
Unnecessary extra lines above could be removed.
I prefer it that way, but I will remove the two extra lines as
On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also, where is that documented?
In Documentation/hwmon/sysfs-interface:
This is a necessary step to revamp the existing design of the driver for the
overall functionality the chip can provide. This will create a clean name-space
for each function.
Signed-off-by: Laszlo Papp lp...@kde.org
---
drivers/hwmon/max6650.c | 10 --
1 file changed, 8 insertions(+), 2
This is a necessary step to revamp the existing design of the driver for the
overall functionality the chip can provide. This will create a clean name-space
for each function.
Signed-off-by: Laszlo Papp lp...@kde.org
---
drivers/hwmon/max6650.c | 7 +--
1 file changed, 5 insertions(+), 2
On Tue, Feb 11, 2014 at 10:22 AM, Laszlo Papp lp...@kde.org wrote:
On Tue, Feb 11, 2014 at 8:50 AM, Lee Jones lee.jo...@linaro.org wrote:
On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare jdelv...@suse.de wrote:
Additionally, dashes are explicitly forbidden in hwmon
device names.
Also
On Tue, Feb 11, 2014 at 11:14 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
On 11 February 2014 15:40, Laszlo Papp lp...@kde.org wrote:
[snip]
+
+struct max665x_dev {
+ struct device *dev;
+ struct mutex iolock;
+
+ struct i2c_client *i2c;
+ struct regmap
On Tue, Feb 11, 2014 at 11:42 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
On 11 February 2014 17:09, Laszlo Papp lp...@kde.org wrote:
On Tue, Feb 11, 2014 at 11:14 AM, Sachin Kamat sachin.ka...@linaro.org
wrote:
On 11 February 2014 15:40, Laszlo Papp lp...@kde.org wrote:
[snip
1 - 100 of 298 matches
Mail list logo
