On Sun, 17 Mar 2013 06:19:33 -0700, Guenter Roeck wrote:
> On Sun, Mar 17, 2013 at 01:39:20PM +0100, Jean Delvare wrote:
> > I'd like to add something at this point.
> >
> > We have historically created the hwmon attributes in the hardware (i2c,
> > platform...) d
Massimo Dal Zotto stopped maintaining the i8k driver several years
ago, so move his name from MAINTAINERS to CREDITS.
Signed-off-by: Jean Delvare
---
CREDITS |4
MAINTAINERS |4 +---
2 files changed, 5 insertions(+), 3 deletions(-)
--- linux-3.9-rc3.orig/CREDITS 2013-03-20 11
igned-off-by: Jean Delvare
Cc: "Mark M. Hoffman"
Cc: Guenter Roeck
Cc: Wolfram Sang
---
Mark, if you have any objection, it's now or never.
MAINTAINERS | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
--- linux-3.8-rc6.orig/MAINTAINERS 2013-02-0
On Fri, 8 Feb 2013 06:56:41 -0800, Guenter Roeck wrote:
> On Fri, Feb 08, 2013 at 10:54:37AM +0100, Jean Delvare wrote:
> > Mark M. Hoffman stopped working on the Linux kernel several years
> > ago, so he should no longer be listed as a driver maintainer. I'm not
> &g
0x3b30
> #define PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS 0x8c22
> +#define PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS 0x8d22
> #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS 0x9c22
Please keep sorted by ID.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscri
now other contact points? If so, please
> ping him about it.
See the updated Cc list :)
--
Jean Delvare
--
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/
Le lundi 01 avril 2013 à 16:32 +0100, Mark Brown a écrit :
> On Mon, Apr 01, 2013 at 01:06:43PM +0200, Jean Delvare wrote:
>
> > My point was, the upstream gpio-ucb1400 driver in its current form is
> > unusable (on top of being ugly.) I have no doubt that someone us
I2C_BOARD_INFO("adt75", 0x9),
Unrelated to this patch, but this is very odd, as the ADT75 can't have
slave address 0x09. This address is almost exclusively used by battery
chargers AFAIK.
> .irq = IRQ_PG5,
The patch itself looks good.
Reviewed-by: Je
On Fri, 05 Apr 2013 11:20:46 +0200, Paul Bolle wrote:
> 1) Added Jean and Guenter because they seem to take in interest in
> Blackfin's stamp files.
Doh, no, I only express my disgust and I'd rather stay away from them
as much as I can ;)
--
Jean Delvare
--
To unsubscribe from
NTEL,
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_SMBUS) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS)
> },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_AV
dapter.class.) I2C system
bus drivers for OF-based platforms would simply not set any class flag,
so detection won't be triggered on them.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
M
On Fri, 25 Jan 2013 12:11:01 -0800, Seth Heasley wrote:
> This patch adds the PCU SMBus DeviceID for the Intel Avoton SOC.
>
> Signed-off-by: Seth Heasley
Reviewed-by: Jean Delvare
> ---
> Documentation/i2c/busses/i2c-i801 |1 +
> drivers/i2c/busses/Kconfig|
must fix a real bug that bothers people"?
Thanks,
--
Jean Delvare
--
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/
Hi Alan,
On Tue, 26 Feb 2013 13:21:30 -0500 (EST), Alan Stern wrote:
> On Tue, 26 Feb 2013, Jean Delvare wrote:
> > Since kernel 3.7.7, my Hauppauge Nova-T 500 Dual DVB-T TV card stopped
> > working reliably. Half of the boots it will work, the other half it
> > won&#x
-off-by: Jean Delvare
---
Patch already sent by Shubhrajyoti Datta on 2012-10-10.
drivers/video/matrox/matroxfb_maven.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- linux-3.9-rc0.orig/drivers/video/matrox/matroxfb_maven.c2013-02-28
09:30:13.134091106 +0100
-by: Peter Huewe
Signed-off-by: Jean Delvare
---
v2: removed zero initialization of flags.
Patch already sent by Shubhrajyoti Datta on 2012-10-10.
drivers/char/tpm/tpm_i2c_infineon.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
--- linux-3.9-rc0.orig/drivers/char
On Thu, 28 Feb 2013 23:12:51 +0100, Peter Hüwe wrote:
> thanks for resending.
You're welcome.
> Am Donnerstag, 28. Februar 2013, 11:06:11 schrieb Jean Delvare:
> > From: Shubhrajyoti Datta
> >
> > Convert the struct i2c_msg initialization to C99 format. This make
attr_fan2_input.dev_attr.attr,
> &sensor_dev_attr_fan3_input.dev_attr.attr,
> + NULL
> };
>
> static const struct attribute_group pem_fan_group = {
Good catch.
Acked-by: Jean Delvare
I'll let Guenter pick the fix as this is his driver. This should go to
stable too.
--
On Thu, 14 Mar 2013 06:33:04 -0700, Guenter Roeck wrote:
> On Thu, Mar 14, 2013 at 11:23:54AM +0100, Jean Delvare wrote:
> > Hi Axel,
> >
> > On Thu, 14 Mar 2013 16:27:18 +0800, Axel Lin wrote:
> > > Signed-off-by: Axel Lin
> > > ---
> > > dri
is solve the userspace timing issue?
Also note that libsensors is really old fashioned when it comes to
device discovery. It doesn't support hot-plug nor hot-remove. So some
work would be needed in this area anyway if we want libsensors-based
applications to properly cope with device addition and
sed on integers which can be negative (such as
> temperatures). Introduce new macro IDIV_ROUND_CLOSEST which also supports
> negative dividends.
Good catch. It's been broken for years and I never noticed :(
Acked-by: Jean Delvare
>
> Signed-off-by: Guenter Roeck
> ---
> I can
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_SMBUS) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS)
> },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS) },
> { 0, }
> };
>
--
Jea
form data (often the platform device ID but it could be anything
else), it's not hard-coded in the driver. It may be a little more
difficult to get right for a PCI driver like i2c-eg20t, but you'll have
to find a way. Relying on boot parameters to get things to work is just
too fragile.
--
Jean Delvare
--
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/
Any ideas? Why is it not a separate module for example?
It should be. Axel Lin has posted a patch which does that and it should
fix your problem:
https://lkml.org/lkml/2012/6/13/233
Please test and confirm it does the right thing. I'll push the patch
upstream if it does.
--
Jean Delvare
--
T
es, and now I see this was finally introduced over 3 years ago.
Cool! And spi has it too now, wonderful world :)
--
Jean Delvare
--
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://
gt;= 0 || (__x) >= 0) ? \
> > + (((__x) + ((__d) / 2)) / (__d)) : \
> > + (((__x) - ((__d) / 2)) / (__d));\
> > } \
>
> Looks good to me.
My testing looks good too.
Acked-by: Jean Delvare
> The patch causes no change in te
Hi Sam,
On Wed, 1 Aug 2012 12:16:46 +0200, Samuel Ortiz wrote:
> Hi Jean,
>
> On Wed, Aug 01, 2012 at 11:13:59AM +0200, Jean Delvare wrote:
> > On Mon, 23 Jul 2012 17:34:15 +0200, Jean Delvare wrote:
> > > The ICH chips have their GPIO pins organized in 2 or 3 independent
.486234] [] sysfs_read_file+0x1cd/0x320
I can't reproduce this, sorry, so I can't look into it. If it takes
special steps to reproduce, please tell me, as I wasn't part of the
original discussion.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsub
On Tue, 11 Sep 2012 12:41:16 +0200, Samuel Ortiz wrote:
> Hi Jean,
>
> On Mon, Jul 23, 2012 at 05:34:15PM +0200, Jean Delvare wrote:
> > The ICH chips have their GPIO pins organized in 2 or 3 independent
> > groups of 32 GPIO pins. It can happen that the ACPI BIOS wants to ma
ernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> -T: git git://git.fluff.org/bjdooks/linux.git
> +T: git git://git.pengutronix.de/git/wsa/linux.git
> S: Maintained
> F: Documentation/i2c/
> F: drivers/i2c/
Acked-by: Jean Delvare
--
Jean Delvare
--
To unsubscribe from thi
s good, but I don't see any "code clean-up". Either it was
intended but forgotten, or the patch description claims too much.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
eout, uint, 0);
> +module_param(write_timeout, uint, S_IRUGO | S_IWUSR);
This one is OK.
> MODULE_PARM_DESC(write_timeout, "Time (in ms) to try writes (default 25)");
>
> #define AT24_SIZE_BYTELEN 5
--
Jean Delvare
--
To unsubscribe from this list: send the line "u
ybody know of a generic bit-banging implementation in the
> kernel which could be used here?
>
> Jean: I'd appreciate your general opinion here, too.
Out of time at the moment :(
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
if it has the correct
> path (or some symlink thereof):
>
> GOOD: /sys/class/firmware/dell_rbu/
> BAD : /sys/class/firmware/firmware-dell_rbu/loading
This doesn't actually work for me. Loading the dell_rbu driver on a
non-Dell system doesn't create anything under /sys/class/
On Mon, 28 Jan 2008 09:20:13 -0500, Jon Smirl wrote:
> On 1/28/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > The status is that I want to give people some time to comment on my
> > modalias patches before I merge them. I also didn't have the time to
> > look into
On Mon, 4 Feb 2008 09:58:35 -0600, Michael E Brown wrote:
> On Sun, Feb 03, 2008 at 03:02:38PM +0100, Jean Delvare wrote:
> > Hi Michael,
> >
> > On Tue, 29 Jan 2008 13:09:25 -0600, Michael E Brown wrote:
> > > On Tue, Jan 29, 2008 at 08:04:17PM +0100, Sytse Wielin
ce prevents icecream from
recognizing compilation tasks it can't handle, leading to silent kernel
miscompilations.
Besides me, credits go to Michael Matz and Dirk Mueller for
investigating the miscompilation issue and tracking it down to this
incorrect -x parameter syntax.
Signed-off-by: Jean
o be set, otherwise only devices forced
> * with module parameters will be created. The detect function must
> * fill at least the name field of the i2c_board_info structure it is
Good catch! Applied, thanks.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linu
4.c b/drivers/i2c/busses/i2c-piix4.c
> index ef511df..8bbd6ec 100644
> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
Good ca
olutely no interest in saving empty OEM
strings anyway, I propose the simple and efficient fix below: we
discard the empty OEM strings altogether.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Cc: Parag Warudkar <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thoma
-October/021563.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-October/021564.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-October/021565.html
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-October/021566.html
--
Jean Delvare
--
To unsubscribe from this list: send th
Hi Yinghai,
On Mon, 11 Feb 2008 15:39:39 -0800, Yinghai Lu wrote:
> On Feb 10, 2008 10:01 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > Yeah, I am an idiot. In 5b34dbcd88251508d02e48ad9b0f9b8232a13ee0 I
> > introduced two new sysfs file groups but forgot to NULL-terminate
2 0x3a18
> +#define PCI_DEVICE_ID_INTEL_ICH10_3 0x3a1a
> +#define PCI_DEVICE_ID_INTEL_ICH10_4 0x3a30
> +#define PCI_DEVICE_ID_INTEL_ICH10_5 0x3a60
> #define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
> #define PCI_DEVICE_ID_INTEL_IOAT_SCNB0x65ff
> #define PCI_DEVICE_ID_INTEL
0x3a60
> #define PCI_DEVICE_ID_INTEL_IOAT_SNB 0x402f
> #define PCI_DEVICE_ID_INTEL_IOAT_SCNB0x65ff
> #define PCI_DEVICE_ID_INTEL_TOLAPAI_00x5031
Greg, please pick this patch quickly so that it makes it to -mm and the
other patches that depend on it can be pushed there as well.
Thanks,
--
Jean
On Tue, 12 Feb 2008 07:27:15 -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 09:27:22AM +0100, Jean Delvare wrote:
> > Hi Yinghai,
> >
> > On Mon, 11 Feb 2008 15:39:39 -0800, Yinghai Lu wrote:
> > > On Feb 10, 2008 10:01 AM, Jean Delvare <[EMAIL PROTECTED]> wr
: Jean Delvare <[EMAIL PROTECTED]>
Cc: Matt Domsch <[EMAIL PROTECTED]>
---
Only tested on i386 and x86-64, maybe Matt can test on ia64?
include/asm-ia64/dmi.h |5 +
include/asm-ia64/io.h |5 -
include/asm-x86/dmi.h |1 +
include/asm-x86/io_32.h |5 -
4 f
tree). Like this:
>
> # BASE
Done. Right now it says:
# BASE 2.6.25-rc1-git3
Is it OK with you?
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
up waiting for init of module usbcore'
FWIW: I have the exact same problem here, running 2.6.25-rc1-git3 on x86_64.
Distribution is openSuse 10.2, module-init-tools version 3.2.2, udev 103.
I can do any test you want me to.
--
Jean Delvare
--
To unsubscribe from this list: send the line "un
t; {
> + acpi_i2c_bus_unregister();
> +
> i2c_del_driver(&dummy_driver);
> #ifdef CONFIG_I2C_COMPAT
> class_compat_unregister(i2c_adapter_compat_class);
> diff --git a/include/linux/acpi_i2c.h b/include/linux/acpi_i2c.h
> new file mode 100644
> index 000..d4482df
> --- /dev/null
> +++ b/include/linux/acpi_i2c.h
> @@ -0,0 +1,29 @@
> +/*
> + * ACPI I2C enumeration support
> + *
> + * Copyright (C) 2012, Intel Corporation
> + * Author: Mika Westerberg
> + *
> + * 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.
> + */
> +
> +#ifndef LINUX_ACPI_I2C_H
> +#define LINUX_ACPI_I2C_H
> +
> +#include
What for?
> +struct i2c_adapter;
> +
> +#if defined(CONFIG_ACPI_I2C) || defined(CONFIG_ACPI_I2C_MODULE)
> +extern void acpi_i2c_register_devices(struct i2c_adapter *adap);
> +extern void acpi_i2c_bus_register(void);
> +extern void acpi_i2c_bus_unregister(void);
> +#else
> +static inline void acpi_i2c_register_devices(struct i2c_adapter *adap) {}
> +static inline void acpi_i2c_bus_register(void) {}
> +static inline void acpi_i2c_bus_unregister(void) {}
> +#endif /* CONFIG_ACPI_I2C */
> +
> +#endif /* LINUX_ACPI_I2C_H */
--
Jean Delvare
--
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 Sun, 4 Nov 2012 09:23:17 +0200, Mika Westerberg wrote:
> On Sat, Nov 03, 2012 at 10:52:46PM +0100, Jean Delvare wrote:
> > On Sat, 3 Nov 2012 09:46:33 +0200, Mika Westerberg wrote:
> > > --- /dev/null
> > > +++ b/drivers/acpi/acpi_i2c.c
> > > @@ -0,0 +1
actually has two I2CSerialBus connectors (and those are to the
> same controller). What I'm not sure is that is it used to select between
> two different addresses or doest the device really have two physical I2C
> connections.
Neither would make sense from a hardware perspective.
Hi Linus,
On Mon, 5 Nov 2012 14:20:52 +0100, Linus Walleij wrote:
> On Mon, Nov 5, 2012 at 2:15 PM, Mika Westerberg
> wrote:
> > On Mon, Nov 05, 2012 at 01:59:23PM +0100, Rafael J. Wysocki wrote:
> >> On Monday, November 05, 2012 01:23:50 PM Jean Delvare wrote:
> >>
ly append the base I/O address at the end of the name to guarantee
that. ACPI will have to come up with something similar.
--
Jean Delvare
--
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/
subsystem maintainer. This will allow for a
smooth and fast transition.
Note that I will keep maintaining all I2C/SMBus controller drivers for
PC systems as well as a few others. I am hereby updating MAINTAINERS
accordingly. I'll also keep maintaining user-space i2c-tools.
Signed-off-by: Jean De
On Mon, 5 Nov 2012 19:12:48 +0200, Mika Westerberg wrote:
> On Mon, Nov 05, 2012 at 04:19:20PM +0100, Jean Delvare wrote:
> > I2C core fears that you're mixing up everything ;) I2C adapter devices
> > are struct i2c_adapter aka i2c-0, i2c-1 etc. i2c_client is for slave
> >
when
> you entrusted me to do maintainer work in i2c.
You're welcome. It is a true relief to know that my baby is in good
hands :)
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
hey want. So if there is a need to do so in the
kernel itself, a proper interface at the generic thermal framework
level seems appropriate.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
are stored internally as negative numbers, starting with -4.
This is required so that the IDs can be freed later. Externally the
positive value is used.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
---
If anyone has a problem with the -4 or using negative device IDs
internally, it would be p
rdware, just try to fix the build error I found.
Good catch. I can't test it either but your patch looks sane. Wolfram,
I think these drivers are mostly used on embedded platforms so it would
make more sense that you (or Ben) pick it. Please let me know if you
want _me_ to take it for whatever reason.
I also think this patch should go to stable kernel trees 3.2 and later,
as it fixes a build bug.
--
Jean Delvare
--
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/
Hi Greg,
On Fri, 27 Jul 2012 11:21:55 -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 27, 2012 at 01:46:25PM +0200, Jean Delvare wrote:
> > Right now we have support for explicit platform device IDs, as well as
> > ID-less platform devices when a given device type can only have o
the
ID was automatically allocated so that it can be freed later.
Note that we also restore the ID to PLATFORM_DEVID_AUTO on error and
device deletion, to avoid avoid unexpected behavior on retry. I don't
really expect retries on platform device addition, but better safe
than sorry.
Signed-off-by: J
On Fri, 27 Jul 2012 22:14:59 +0200, Jean Delvare wrote:
> Code not tested yet, my test machine is currently used for a different
> task that cannot be interrupted.
Tested now, works fine.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
as been
> FORCEFULLY ENABLED!\n");
> } else {
> dev_err(&PIIX4_dev->dev,
> "Host SMBus controller not enabled!\n");
Applied, thanks.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
--- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1047,7 +1047,7 @@ sym_re_search_free:
> * When we check for recursive dependencies we use a stack to save
> * current state so we can print out relevant info to user.
> * The entries are located on the call stack
;Selected by" line.
>
> Furthermore, the help texts now should fit in 80 columns again when viewed
> in mconf.
>
> Signed-off-by: Martin Walch
Looks good to me.
Reviewed-by: Jean Delvare
--
Jean Delvare
Suse L3
--
To unsubscribe from this list: send the line "unsubscri
th the right i2c_device_id->driver_data.
>
> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
> we doesn't need to change the lm90.c.
There's no problem with changing the lm90 driver, if this is the right
thing to do.
--
Jean Del
ng heuristic in the documentation.
It's more of a rule than a heuristic.
> Reported-by: Jean Delvare
> Signed-off-by: "Yann E. MORIN"
> Cc: Jean Delvare
> Cc: Michal Marek
> Cc: Roland Eggner
> Cc: Wang YanQing
I tested it and it works fine, thanks!
Tested-
Hi Yann,
Le Monday 24 June 2013 à 20:11 +0200, Yann E. MORIN a écrit :
> From: "Yann E. MORIN"
>
> Reported-by: Jean Delvare
> Signed-off-by: "Yann E. MORIN"
> Cc: Jean Delvare
> Cc: Michal Marek
> ---
> scripts/kconfig/mconf.c | 2 +-
> scrip
er are already hopelessly broken.)
All I can say is that these dmi_scan patches should never have made it
to stable kernels in the first place, as they infringed several rules
stable patches are supposed to comply with.
--
Jean Delvare
Suse L3
--
To unsubscribe from this list: send the line
nmapped area
but I'm reasonably certain this is bad and shouldn't be attempted.
Also, the code only looks for the DMI entry point in the second half of
the buffer, so it would also miss a legacy DMI entry point at 0xF.
Thoughts?
--
Jean Delvare
Suse L3
--
To unsubscribe from this li
sors.org/pipermail/lm-sensors/2013-February/038100.html
> which git repository and branch should I use ?
It is supposed to just work. What doesn't work for you exactly?
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Hi Ben,
Le Monday 08 July 2013 à 17:33 +0100, Ben Hutchings a écrit :
> On Mon, Jul 08, 2013 at 05:49:14PM +0200, Jean Delvare wrote:
> > I am looking at this commit of yours:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/f
[PATCH 1/3] firmware/dmi_scan: Drop obsolete comment
[PATCH 2/3] firmware/dmi_scan: Fix most checkpatch errors and warnings
[PATCH 3/3] firmware/dmi_scan: Constify strings
--
Jean Delvare
Suse L3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Fix all errors and trivial warnings reported by checkpatch for file
drivers/firmware/dmi_scan.c.
Signed-off-by: Jean Delvare
---
drivers/firmware/dmi_scan.c | 47 ++--
1 file changed, 24 insertions(+), 23 deletions(-)
--- linux-3.11-rc0.orig/drivers
misleading comment.
Signed-off-by: Jean Delvare
Cc: Ingo Molnar
Cc: Yinghai Lu
---
drivers/firmware/dmi_scan.c |5 -
1 file changed, 5 deletions(-)
--- linux-3.10-rc0.orig/drivers/firmware/dmi_scan.c 2013-05-04
11:16:44.229314442 +0200
+++ linux-3.10-rc0/drivers/firmware
Add const to all DMI string pointers where this is possible. This
fixes a checkpatch warning.
Signed-off-by: Jean Delvare
---
drivers/firmware/dmi_scan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-3.10-rc0.orig/drivers/firmware/dmi_scan.c 2013-05-04
11:20
Hi Joe,
Le Tuesday 09 July 2013 à 08:58 -0700, Joe Perches a écrit :
> On Tue, 2013-07-09 at 17:43 +0200, Jean Delvare wrote:
> > Add const to all DMI string pointers where this is possible. This
> > fixes a checkpatch warning.
>
> That's a nice little improvement.
T
Hi Joe,
Le Tuesday 09 July 2013 à 09:19 -0700, Joe Perches a écrit :
> On Tue, 2013-07-09 at 17:42 +0200, Jean Delvare wrote:
> > Fix all errors and trivial warnings reported by checkpatch for file
> > drivers/firmware/dmi_scan.c.
>
> trivia:
>
> > +++ linux-3.11-r
Hi Joe,
Le Wednesday 10 July 2013 à 07:51 -0700, Joe Perches a écrit :
> even more trivial...
>
> On Wed, 2013-07-10 at 14:47 +0200, Jean Delvare wrote:
> > +++ linux-3.11-rc0/drivers/firmware/dmi_scan.c 2013-07-10
> > 14:11:56.544792703 +0200
> > @@ -62,8
memset(buf, 0, 16);
> for (q = p; q < p + 0x1; q += 16) {
> memcpy_fromio(buf + 16, q, 16);
>
Yes, I like it, good idea.
Reviewed-by: Jean Delvare
--
Jean Delvare
Suse L3
--
To unsubscribe from this list: send the line "unsubscribe
.
This is how things have happened, and I just can't see anything wrong.
If you do, please explain what you thing shouldn't have happened, and
let me know what I should have done instead.
Thanks,
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linu
On Thu, 11 Jul 2013 16:53:43 +1000, Stephen Rothwell wrote:
> On Thu, 11 Jul 2013 07:57:00 +0200 Jean Delvare wrote:
> > On Thu, 11 Jul 2013 10:27:24 +1000, Stephen Rothwell wrote:
> > > Why have you just rebased the jdelvare-hwmon series
> > > (http://khali.linux-fr
SRA so you can reuse this part of the X9SRA configuration file.
Hope that helps,
--
Jean Delvare
--
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/
Hi Yann,
Sorry again for the late reply, busy...
Le Monday 08 July 2013 à 19:35 +0200, Yann E. MORIN a écrit :
> On 2013-07-08 13:19 +0200, Jean Delvare spake thusly:
> > This is more concise and easier to grasp, methinks. I don't think the
> > reference to the user&#x
Yann, Michal,
Le Wednesday 10 July 2013 à 22:46 +0200, Yann E. MORIN a écrit :
> Michal, All,
>
> On 2013-07-08 19:35 +0200, Yann E. MORIN spake thusly:
> > On 2013-07-08 13:19 +0200, Jean Delvare spake thusly:
> > > Le Monday 24 June 2013 à 20:11 +0200, Yann E. MORI
return err;
>
> /* +16 degrees offset for temp2 for the LM99 */
> if (data->kind == lm99 && index <= 2)
> @@ -839,6 +848,23 @@ static ssize_t set_temp11(struct device *dev, struct
> device_attribute *devattr,
> lm90_select_remote_channe
Hi Guenter,
On Fri, 12 Jul 2013 06:50:00 -0700, Guenter Roeck wrote:
> On Fri, Jul 12, 2013 at 03:26:15PM +0200, Jean Delvare wrote:
> > One thing I am a little worried about (but maybe I'm wrong) is that I
> > seem to understand you want to register every LM90-like chip
7 of
> the series)
> into 3.12, and keep the rest for 3.13.
I'm afraid I won't have the time to review all these patches. The
concept looks good to me and I trust that you implemented things right
so feel free to push the patches upstream even without my review.
--
Jean Delvare
--
Hi Wei,
Sorry for the late reply, catching up with the discussions from before
my vacation...
On Tue, 30 Jul 2013 16:18:35 +0800, Wei Ni wrote:
> On 07/29/2013 11:58 PM, Jean Delvare wrote:
> > On Mon, 29 Jul 2013 18:14:56 +0800, Wei Ni wrote:
> >> Yes, we had met this pro
+ err |= i2c_smbus_write_byte_data(client, reg[nr].high,
> data->temp11[index] >> 8);
> if (data->flags & LM90_HAVE_REM_LIMIT_EXT)
> - i2c_smbus_write_byte_data(client, reg[nr].low,
> -
pment and rebase at some point in time anyway. If you propose a
complete workflow which is better than what I do today, I'll be happy
to consider switching to it. But just telling me to skip one mandatory
step in my current workflow is simply not helping, sorry.
--
Jean Delvare
--
To uns
Hi Wei,
I am sorry, I see there have been many discussions about the lm90
driver while I was on vacation and these are threads I did not have the
time to catch up with yet. I'll read it all as soon as possible by my
current schedule is tight so please be patient!
Jean
On Mon, 9 Sep 2013 14:16:18
cgi?id=61811.
It seems this is hurting more users than I would have expected, and
people are spending significant amounts of time to figure out what the
root cause to their problem is. May I suggest that my fix should find
its way to Linus' tree rather sooner than later?
Thanks,
--
Jean Del
I was checking why this spinlock was never initialized, but it turns
out it's not used anywhere, so we can drop it.
Signed-off-by: Jean Delvare
Cc: Vinod Koul
Cc: Dan Williams
---
I can't even build-test this.
drivers/dma/ipu/ipu_irq.c |1 -
1 file changed, 1 deletion(-)
---
As reported by CONFIG_DEBUG_SPINLOCK=y.
Signed-off-by: Jean Delvare
Cc: Peter Tyser
Cc: Grant Likely
Cc: Linus Walleij
Cc: sta...@vger.kernel.org [v3.5+]
---
drivers/gpio/gpio-ich.c |1 +
1 file changed, 1 insertion(+)
--- linux-3.6-rc4.orig/drivers/gpio/gpio-ich.c 2012-09-04 13:34
It doesn't seem this spinlock was properly initialized.
Signed-off-by: Jean Delvare
Cc: Finn Thain
Cc: Geert Uytterhoeven
---
I can't even build-test this.
drivers/block/swim.c |1 +
1 file changed, 1 insertion(+)
--- linux-3.6-rc4.orig/drivers/block/swim.c 2012-0
Hi Alexander,
Sorry for the late reply again.
On Thu, 30 Aug 2012 09:49:52 +0200, Alexander Stein wrote:
> On Wednesday 29 August 2012 20:40:31, Jean Delvare wrote:
> > Note that there was an assumption at the time the code was written,
> > that there was no need or reason to r
ebug? I know dev_dbg is
> compiled out if !DEBUG, but there must be a better way. Maybe define
> i2c_hid_dbg() via dev_printk() and also check debug condition there?
dev_dbg() is compiled out if !DEBUG only if CONFIG_DYNAMIC_DEBUG isn't
set. These days I think every developer want to enable this
tried to build
i2c-hid as a module.BTW I see that these functions are part of the
usbhid driver, which looks seriously wrong. If these functions are
transport layer-independent, they should be moved to the hid-code or
some sub-module. One should be able to enable HID-over-I2C without
HID-over-USB.
--
On Sat, 6 Oct 2012 22:30:00 +0200, Stéphane Chatty wrote:
> Le 6 oct. 2012 à 22:04, Jean Delvare a écrit :
> > Looks like the wrong place for this driver. HID-over-USB support lives
> > under drivers/hid, so your driver should go there as well. Not only
> > this will be mo
1 - 100 of 1633 matches
Mail list logo
