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 reas
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 30
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 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 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 think
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 fan1_t
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 r
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
desig
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 10:19 AM, Lee Jones 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 this
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
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*
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 wi
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 dri
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.
>> &
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 i2c_client
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
>>> > be a
&g
age 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 with
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, &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 dr
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
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
--- a
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
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 hav
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 as
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 th
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 Documentation/hwmon/sysfs
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.
>
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
"to support for" is incorrect English in here, hence the change to "to add
support".
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49b
"to support for" is incorrect English in here, hence the change to "to add
support".
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
in
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 3:23 AM, Laszlo Papp wrote:
> On Mon, Feb 10, 2014 at 11:10 PM, Guenter Roeck wrote:
>> On Mon, Feb 10, 2014 at 06:59:55PM +0000, Laszlo Papp wrote:
>> I think I'll let Jean handle this one.
>
> Guys, please be a bit more definite.
>
> W
On Mon, Feb 10, 2014 at 11:10 PM, Guenter Roeck wrote:
> On Mon, Feb 10, 2014 at 06:59:55PM +0000, Laszlo Papp wrote:
> I think I'll let Jean handle this one.
Guys, please be a bit more definite.
We should get over this long ping-pong game. It has been clearly
stated that either
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?
I do not think you can make such a decision, and you will realize that
once you begin to think a bit out of the box and look around. See h
On Mon, Feb 10, 2014 at 4:53 PM, wrote:
> Quoting Jean Delvare :
>
>>
>> That being said, going with MFD in this case seems quite overkill to
>> me. MFD makes a lot of sense when each function has its own resources.
>> As this isn't the case here, a single driver registering both an hwmon
>> inte
On Mon, Feb 10, 2014 at 3:20 PM, Sachin Kamat wrote:
> On 10 February 2014 17:51, Lee Jones wrote:
>>> > +#include
>>> > +#include
>>> > +#include
>>> > +#include
>>>
>>> Please arrange these alphabetically.
>>
>> Why?
>
> 1. It makes it easier to avoid adding duplicate includes.
> 2. Code lo
On Mon, Feb 10, 2014 at 5:43 PM, Jean Delvare wrote:
> Hi Lee,
>
> On Mon, 10 Feb 2014 16:58:53 +, Lee Jones wrote:
>> > > > static const struct i2c_device_id max6650_id[] = {
>> > > > - { "max6650", 1 },
>> > > > - { "max6651", 4 },
>> > > > + { "max6650-hwmon", 1 },
>> > >
On Mon, Feb 10, 2014 at 5:06 PM, Laszlo Papp wrote:
> On Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare wrote:
>> Hi Lee, Laszlo,
>>
>> On Mon, 10 Feb 2014 16:08:42 +, Lee Jones wrote:
>>> > In the preparation of creating an mfd driver and then refactor this
ne driver later.
>> >
>> > This was a request from Lee Jones, the MFD subsystem maintainer.
>> >
>> > Signed-off-by: Laszlo Papp
>> > ---
>> > drivers/hwmon/max6650.c | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
changes in more than
one driver later.
This was a request from Lee Jones, the MFD subsystem maintainer.
Signed-off-by: Laszlo Papp
---
drivers/hwmon/max6650.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/max6650.c b/drivers/hwmon/max6650.c
index 0cafc39
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, max665x_id);
>>> +
>>> +static struct i2c_driver max665x_driver = {
>>> + .driver = {
>>> + .name = "max665x",
>>> + .owner = THIS_MODULE,
>>
>> All new drivers are required to support Device Tree.
>
> Do you have some recommendation
>> +static struct mfd_cell max665x_devs[] = {
>> + { .name = "max6651-gpio", },
>> + { .name = "max6650", }, /* hwmon driver */
>
> What happened to renaming the hwmon driver, so we can have
> "max6650-hwmon" here?
I will add the alias in the next patch (e.g. hwmon change). I can come
back
gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 88 +
include/linux/mfd/max665x-private.h | 42 ++
4 files
>> + help
>> + Say yes here to support for Maxim Semiconductor MAX6650/MAX6651.
>> This is
>> + a fan speed regulator and monitor IC. This driver provies common
>> support
>
> s/provies/provides/
Good catch!
(Note to myself: I should have run my vim spellchecker... )
>> + m
> + * Author: Milo Kim
s/Milo Kim/Laszlo Papp/
I just copied and pasted some existing copyrights, and I, apparently,
have not changed it properly to my name; apologies for that. I will
fix this in the next batch after getting some review from others.
--
To unsubscribe from this list: send
gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 88 +
include/linux/mfd/max665x-private.h | 42 ++
4 files
Signed-off-by: Laszlo Papp
---
Documentation/devicetree/usage-model.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/usage-model.txt
b/Documentation/devicetree/usage-model.txt
index 2b6b3d3..cd2eae5 100644
--- a/Documentation/devicetree/usage
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
--- a
On Fri, Jan 24, 2014 at 7:27 PM, Curt Brune wrote:
> On Fri Jan 24 18:42, Laszlo Papp wrote:
>> > Note: The class cannot be called 'eeprom' as that is the name of the
>> > I/O file created by the driver. The class name appears as a
>> > sub-directory with
> Note: The class cannot be called 'eeprom' as that is the name of the
> I/O file created by the driver. The class name appears as a
> sub-directory within the main device directory. Hence the class name
> 'eeprom_dev'.
I am not sure I follow the reasoning here, but it is possibly because
I lack
On Thu, Jan 23, 2014 at 5:25 PM, Wolfram Sang wrote:
> Hi,
>
> No need to quote the whole message if you reply only to a bit of it.
>
>> > module_init(at24_init);
>> >
>> > static void __exit at24_exit(void)
>> > {
>> > i2c_del_driver(&at24_driver);
>> > }
>> > module_exit(at24_exit);
On Thu, Jan 23, 2014 at 3:05 PM, Curt Brune wrote:
> On Thu Jan 23 07:44, Laszlo Papp wrote:
>> On Wed, Jan 22, 2014 at 5:23 PM, Curt Brune wrote:
>> > During device instantiation have the at24 driver add the new device to
>> > the eeprom_dev hardware class. The
On Wed, Jan 22, 2014 at 5:23 PM, Curt Brune wrote:
> During device instantiation have the at24 driver add the new device to
> the eeprom_dev hardware class. The functionality is enabled by
> CONFIG_EEPROM_CLASS.
>
> Signed-off-by: Curt Brune
> ---
> drivers/misc/eeprom/at24.c | 20 +++
> On Sun, Jan 20, 2013 at 07:08:28PM +0100, Thomas De Schampheleire wrote:
>> [plaintext and fixed address of David Brownell]
>
> David passed away a year or so ago, so that's really not going to help :(
>
>> Hi,
>>
>> Several of the eeprom drivers that live in drivers/misc/eeprom export
>> a binar
On Wed, Jan 15, 2014 at 10:05 AM, Linus Walleij
wrote:
> On Tue, Jan 14, 2014 at 6:17 PM, Laszlo Papp wrote:
>
> [CC:ing Jon Corbet on this as he's better at the consensus process
> and may correct me here.]
>
>> I have just had a quick look and I am now worried It
> Even the gpio functionality itself? So, to clarify my question above,
> I thought it would be something like this:
>
> - gpio
> \
>---
> \
> - alarm - pinctrol
> /
>
> - etc /
>
> So, pinctrl on top of them, and only this high la
I had been trying to learn a bit more about the pinctrl subsystem, and I
realized several typos and grammar issues while going through the documentation.
I have probably not caught all the possible issues, but this change is
addressing several places for improvement.
Signed-off-by: Laszlo Papp
I had been trying to learn a bit more about the pinctrl subsystem, and I
realized several typos and grammar issues while going through the documentation.
I have probably not caught all the possible issues, but this change is
addressing several places for improvement.
Signed-off-by: Laszlo Papp
On Mon, Jan 13, 2014 at 9:48 AM, Linus Walleij wrote:
> On Mon, Jan 13, 2014 at 10:22 AM, Laszlo Papp wrote:
>
>> I was giving a second thought to this. Would it be acceptable to add
>> the gpio driver now, and once the need arises, add the pinctrl thin
>> layer on t
On Mon, Jan 13, 2014 at 9:43 AM, Linus Walleij wrote:
> On Wed, Jan 8, 2014 at 3:59 PM, Laszlo Papp wrote:
>> On Tue, Jan 7, 2014 at 2:33 PM, Linus Walleij
>> wrote:
>
>>> As I can see this is really a GPIO+pin control driver it shall be
>>> moved to drive
>>> +#define PIN_NUMBER 5
>>
>> As I can see this is really a GPIO+pin control driver it shall be
>> moved to drivers/pinctrl.
>
> Hmm, but then I am not sure why the gpio-max*.c are similar in the
> drivers/gpio area. Could you please elaborate? They are somewhat
> similar to my understanding, but
>> +int max6651_read_reg(struct i2c_client *i2c, u8 reg, u8 *dest)
>> +{
>
> Probably best to use Regmap instead.
>
> regmap_i2c_read()
>> +int max6651_write_reg(struct i2c_client *i2c, u8 reg, u8 value)
>> +{
>> +struct max6651_dev *max6651 = i2c_get_clientdata(i2c);
>> +int ret;
>
> Same
These sentences are not proper English due to the typos. I had initially caught
one of them while trying to understand the regmap feature, and then I just ran
the vim spell checker, and went through all the items that would need to be
fixed for this header file.
Signed-off-by: Laszlo Papp
On Thu, Jan 9, 2014 at 11:06 AM, Lee Jones wrote:
>> > Styling i.e nice, neat, easily readable/maintainable code should be
>> > your bread and butter. If styling tires you, perhaps a new career
>> > might be in order. ;)
>>
>> or a new tool to be more professional ...
>
> Patches accepted.
>
>> >>
On Thu, Jan 9, 2014 at 9:41 AM, Lee Jones wrote:
>> >> +config MFD_MAX6651
>> >> + bool "Maxim Semiconductor MAX6651 Support"
>> >> + depends on I2C=y
>> >> + select MFD_CORE
>> >> + select IRQ_DOMAIN
>> >
>> > Why have you selected IRQ_DOMAIN?
>>
>> Initial consistency with other
On Thu, Jan 9, 2014 at 2:43 AM, Randy Dunlap wrote:
> On 01/08/14 17:46, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 9:49 PM, Mark Brown wrote:
>>> On Wed, Jan 08, 2014 at 09:08:44PM +, Laszlo Papp wrote:
>>>> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp wrote
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, Jan 8, 2014 at 9:49 PM, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 09:08:44PM +0000, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp wrote:
>
>> > That being said, I will not have time, nor the motivation to argue
>> > over such a nuan
On Wed, Jan 8, 2014 at 9:44 PM, Randy Dunlap wrote:
> On 01/08/14 13:11, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 6:54 PM, Randy Dunlap wrote:
>>> On 01/08/2014 08:31 AM, Laszlo Papp wrote:
>>>>
>>>> Hi,
>>>>
>>>> whic
On Wed, Jan 8, 2014 at 6:54 PM, Randy Dunlap wrote:
> On 01/08/2014 08:31 AM, Laszlo Papp wrote:
>>
>> Hi,
>>
>> which spelling is preferred for the documentation when sending patches?
>>
>> I see the UK'ish "initialise" as well as the US
On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp wrote:
> On Wed, Jan 8, 2014 at 7:07 PM, Mark Brown wrote:
>> On Wed, Jan 08, 2014 at 06:59:57PM +0000, Laszlo Papp wrote:
>>> On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown wrote:
>>> > On Wed, Jan 08, 2014 at 05:22
On Wed, Jan 8, 2014 at 7:07 PM, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 06:59:57PM +0000, Laszlo Papp wrote:
>> On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown wrote:
>> > On Wed, Jan 08, 2014 at 05:22:18PM +, Laszlo Papp wrote:
>
>> >> - * (eg,
On Wed, Jan 8, 2014 at 6:07 PM, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 05:22:18PM +0000, Laszlo Papp wrote:
>
>> - * (eg, a clear on read interrupt status register). If this
>> + * (e.g. a clear on read interrupt status register). If this
>
> T
o more typos in this file.
Signed-off-by: Laszlo Papp
---
drivers/mfd/stw481x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/stw481x.c b/drivers/mfd/stw481x.c
index 1243d5c..24b8a12 100644
--- a/drivers/mfd/stw481x.c
+++ b/drivers/mfd/stw481x.c
@@ -36,7 +36,
1 - 100 of 149 matches
Mail list logo
