Commit-ID: 58394271c610e9c65dd0165a1c1f6dec75dc5f3e
Gitweb: http://git.kernel.org/tip/58394271c610e9c65dd0165a1c1f6dec75dc5f3e
Author: Jean Delvare
AuthorDate: Mon, 16 Jun 2014 11:48:45 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 21 Jun 2014 22:32:42 +0200
clocksource: Add a
I seem to understand that the sdhci-pxav3 and sdhci-pxav2 drivers are
only needed on the MMP architecture. So add a hardware dependency on
ARCH_MMP, so that other users don't get to build useless drivers.
Signed-off-by: Jean Delvare
Cc: Chris Ball
Cc: Ulf Hansson
Cc: Eric Miao
Cc: Ha
As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.
Signed-off-by: Jean Delvare
Cc: Samuel Ortiz
Cc: Lee Jones
---
Patch already sent on: 2014-04-03
drivers/mfd/Kconfig |2 +-
1 file
As far as I know, the CS5535 and CS5536 chipsets are companions of the
Geode series of processors, which are 32-bit only. So the CS5535
drivers are not needed on x86-64, except for build testing purpose.
This aligns the dependencies to what FB_GEODE already uses.
Signed-off-by: Jean Delvare
Cc
Move the clocksource Kconfig entries into their own menu, so that they
don't pollute the main device driver menu.
Signed-off-by: Jean Delvare
Cc: Daniel Lezcano
Cc: Thomas Gleixner
---
Patch already sent on 2014-04-24. Changes since v1:
* Rebased on kernel 3.16-rc1
drivers/clocks
gt; .interrupt = taos_interrupt,
> };
>
> -static int __init taos_init(void)
> -{
> - return serio_register_driver(&taos_drv);
> -}
> -
> -static void __exit taos_exit(void)
> -{
> - serio_unregister_driver(&taos_drv);
> -}
> +module_seri
it/drivers/phy/phy-exynos5250-sata.c?id=fe04e4297e6eab014a2cf152319b9f361df07faf
>
> Ok. It is in mainline but not in 3.15.
And as it stands, it won't be, because sta...@vger.kernel.org was not
Cc'd. "Typo" in the subject makes it sound like a trivial and minor
change. &qu
Pinchart
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> (...)
Acked-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
s better than hope :-)
Oops, that would be my fault, sorry. I did grep for such cases but my
grep command must have been poor, I only caught 2 of the 3 cases in the
kernel tree. And make allmodconfig didn't help as the driver is
ppc64-specific.
I'll send a fix-up patch immediately, sorr
On Tue, 27 May 2014 13:50:36 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 12:48:02PM +0200, Jean Delvare wrote:
> > This patch set is a proposal to revert most of commit b4028437. This
> > would solve a memory leak and also allow to simplify and ultimately
> > i
0
> #define PCH_EDGE_RISING BIT(0)
>
Good catch, thanks Arnd.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
left side, but shows up as
> > RigthFan. Wouldn't it be better to simply number the fans and let the
> > "real" labeling be done via sensors.conf ?
> >
> I agree. Jean, any comments ? Is it ok to drop the fan labels ?
Yes it is, I had that it mind already, just
it after a few
releases if nobody steps up.
An alternative would be to contact the maintainer (or short of that,
the original contributor) of the driver for an update. Again, with a
deadline.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe l
t;
> But there is nothing about fan control or temperature.
>
>
> Also I found smbios specification:
>
> http://www.dmtf.org/standards/smbios
>
> There is something written about fan and temp, but no idea if it
> is usefull for something...
No, it's not usefu
On Sat, 17 May 2014 08:25:38 -0700, Guenter Roeck wrote:
> On 05/16/2014 12:11 PM, Jean Delvare wrote:
> > Load the i8k driver with fan_mult=1.
>
> Would it make sense to change the default multiplier to 1 ?
> Lots of people have problems with it, and trying to figure out
>
> /sys/class/hwmon/hwmon1/temp4_input:127000
The drivers sets default labels in sysfs, the libsensors configuration
files lets you override these defaults with your own labels.
--
Jean Delvare
SUSE L3 Support
--
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/
book, not right as reported by driver.
>
> It is possible to fix these problems?
Load the i8k driver with fan_mult=1.
Add the following to /etc/sensors.d/i8k.conf:
chip "i8k-virtual-0"
label fan2 "Left Fan"
ignore temp4
--
Jean Delvare
SUSE L3 Support
--
From: Jean Delvare
Subject: misc: pch_phub: Fix Kconfig dependencies
The pch_phub driver is for a companion chip to the Intel Atom E600
series processors. These are 32-bit x86 processors so the driver is
only needed on X86_32. Add COMPILE_TEST as an alternative, so that the
driver can still be
Hi Mike,
Le Wednesday 14 May 2014 à 15:51 -0700, Mike Waychison a écrit :
> On Wed, May 14, 2014 at 12:23 PM, Jean Delvare wrote:
> > Thanks for the explanation. But if access to /dev/mem was your only
> > concern, your solution seems somewhat overkill. You could have just
>
Hi Mike,
On Wed, 14 May 2014 08:52:36 -0700, Mike Waychison wrote:
> On Wed, May 14, 2014 at 2:23 AM, Jean Delvare wrote:
> > Sorry for joining the party a little late but I am just discovering the
> > dmi-sysfs kernel module. I have to admit that I am very curious about
> &
g/dmidecode/
[2] http://lwn.net/Articles/429427/
Thanks,
--
Jean Delvare
SUSE L3 Support
--
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
Ple
ead of +/- 2°C.) The +/- 1°C
accuracy for the external channels is also guaranteed over a wider
temperature range. Just from a quick look at the product features,
there may be more.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
},
> > + { "emc1424", emc1404 },
>
> Wonder if we should list the emc141x chips here. Jean, any thoughts ?
Yes we should, so that people can declare the right chip in platform
files, device tree etc. We can map the additional names to existing
types if the chips are fully
Do you have any
> concerns with that ?
I know nothing about regmap, so no objection, I simply don't care ;-)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
goto fail;
>
> - hyst = val - retval * 1000;
> + hyst = retval * 1000 - val;
> hyst = DIV_ROUND_CLOSEST(hyst, 1000);
> if (hyst < 0 || hyst > 255) {
> retval = -ERANGE;
Anyway, fix is correct, good catch.
Reviewed-by: Jean Delvar
convention in order.
> Jean, any addresses which should not be scanned ?
0x3c and 0x6c should indeed not be scanned, sensors-detect does not
scan them as they aren't typically used by hwmon devices. 0x5c is
questionable (currently scanned, but used only by a limited number of
chips, we may
ned-off-by: Josef Gajdusek
> +MODULE_ALIAS("i2c:emc1403");
Why add an alias which is already present?
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
Hi Guenter,
On Wed, 07 May 2014 05:10:58 -0700, Guenter Roeck wrote:
> On 05/07/2014 12:13 AM, Jean Delvare wrote:
> > On Tue, 06 May 2014 06:32:15 -0700, Guenter Roeck wrote:
> >> Can we implement a similar approach to network devices and make hwmon
> >> path names (
e's really no excuse for
not using it if your daemon is written in C or C++.
--
Jean Delvare
SUSE L3 Support
--
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.kern
by libsensors-like name (and the
other way around too.) Scripts could use it to benefit from libsensors
persistent names.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
* it doesn't help with shell or perl
scripts such as pwmconfig and fancontrol.
--
Jean Delvare
SUSE L3 Support
--
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 initialization failure, an error message is already printed with
level KERN_ERR, no need to print another one with level KERN_INFO.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
drivers/tty/n_hdlc.c |4
1 file changed, 4 deletions(-)
--- linux-3.15-rc2
Move the clocksource Kconfig entries into their own menu, so that they
don't pollute the main device driver menu.
Signed-off-by: Jean Delvare
Cc: Daniel Lezcano
Cc: Thomas Gleixner
---
drivers/clocksource/Kconfig |4
1 file changed, 4 insertions(+)
--- linux-3.15-rc2.orig/dr
According to the driver descriptions, the atmel_pwm and atmel-ssc
drivers are only useful on Atmel AT32 and AT91 systems. So add
hardware dependencies to these drivers to hide them on other systems.
Signed-off-by: Jean Delvare
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/Kconfig
The machine is otherwise idle. While this isn't
exactly brand new hardware, it is still reasonably powerful, and 38
minutes is time, especially when you're waiting for the build to
complete before you can resume working on something.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe f
Hi Greg,
On Mon, 14 Apr 2014 21:52:14 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
> > In the case above, yes. But I don't quite see how that makes a
> > difference. x86 has platform drivers too, they are the essence of the
> > m
ributions have already moved to the new kernel so they have already
answered the n/m/y question for all new entries.
--
Jean Delvare
SUSE L3 Support
--
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 Mon, 14 Apr 2014 12:11:43 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote:
> > Configuring kernels from scratch has become an incredibly long and
> > tedious task. The reason is that the number of drivers and options has
> >
Enabling SYNCLINK_CS as a module builds synclink_cs, not synclinkmp.
Signed-off-by: Jean Delvare
---
Who wants to pick this?
drivers/char/pcmcia/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-3.15-rc1.orig/drivers/char/pcmcia/Kconfig 2014-03-31
05:40
ists if we set too strict dependencies.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
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/
dev_set_drvdata and dev_get_drvdata are now simple enough again that
we can inline them as they used to be before commit b40284378.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
---
drivers/base/dd.c | 16
include/linux/device.h | 12 ++--
2 files changed
anyway, so that was only delaying the crash if the caller
is not paying attention.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
---
drivers/base/dd.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- linux-3.15-rc0.orig/drivers/base/dd.c 2014-04-09 16:16:01.631698736
dev_set_drvdata can no longer fail, so it could return void.
All callers have hopefully been updated to no longer check for the
return value.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
---
drivers/base/dd.c |3 +--
include/linux/device.h |2 +-
2 files changed, 2
So there is no point in checking its return value, which will soon
disappear.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
---
drivers/iommu/exynos-iommu.c |7 +--
drivers/vfio/vfio.c |8 +---
2 files changed, 2 insertions(+), 13 deletions(-)
--- linux-3.15-rc0
Having to allocate memory as part of dev_set_drvdata() is a problem
because that memory may never get freed if the device itself is not
created. So move driver_data back to struct device.
This is a partial revert of commit b4028437.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
struct device
[PATCH 2/5] driver core: dev_set_drvdata can no longer fail
[PATCH 3/5] driver core: dev_set_drvdata returns void
[PATCH 4/5] driver core: dev_get_drvdata: Don't check for NULL dev
[PATCH 5/5] driver core: Inline dev_set/get_drvdata
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe
On Fri, 11 Apr 2014 13:44:44 +0200, Richard Leitner wrote:
> Fixed most checkpatch.pl issues
>
> Signed-off-by: Richard Leitner
> Reviewed-by: Jean Delvare
> ---
> v2: applied changes recommended by Jean Delvare
> ---
> drivers/i2c/b
ase before. Anyway
it is not recommended to run "real code" during variable declaration.
With these changes applied, feel free to add:
Reviewed-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
Hi Greg,
On Mon, 7 Apr 2014 13:58:15 -0700, Greg Kroah-Hartman wrote:
> On Mon, Apr 07, 2014 at 10:53:22AM +0200, Jean Delvare wrote:
> > Having to allocate memory as part of dev_set_drvdata() is a problem
> > because that memory may never get freed if the device itself is not
drivers which didn't have it yet, for consistency.
Signed-off-by: Jean Delvare
Cc: Nicolas Ferre
Cc: Matt Mackall
Cc: Herbert Xu
Cc: Kukjin Kim
---
Note: untested, as I don't have any of the hardware in question.
drivers/char/hw_random/Kconfig | 12 +---
1 file changed, 9
This makes configuration more convenient IMHO, and avoids having to
repeat the dependency on HW_RANDOM for every single driver.
Signed-off-by: Jean Delvare
Cc: Matt Mackall
Cc: Herbert Xu
---
drivers/char/hw_random/Kconfig | 56 +
1 file changed, 30
UML_RANDOM is the only hardware random number generator option which
does not depend on HW_RANDOM. Having it in the middle of the other
options breaks the alignment in "make menuconfig". Move it at the last
position to avoid that.
Signed-off-by: Jean Delvare
Cc: Matt Mackall
Cc:
When OMAP_CONTROL_USB was renamed to OMAP_CONTROL_PHY (commit
14da699b), its dependencies were lost in the process. Nothing in the
commit message indicates that this removal was intentional, so I think
it was by accident and the dependencies should be restored.
Signed-off-by: Jean Delvare
Cc
Having to allocate memory as part of dev_set_drvdata() is a problem
because that memory may never get freed if the device itself is not
created. So move driver_data back to struct device.
This is a partial revert of commit b4028437.
Signed-off-by: Jean Delvare
Cc: Greg Kroah-Hartman
---
Greg
As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.
Signed-off-by: Jean Delvare
Cc: Samuel Ortiz
Cc: Lee Jones
---
drivers/mfd/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion
ntk_driver);
> + put_tty_driver(ttyprintk_driver);
> + tty_port_destroy(&tpk_port.port);
> +}
> +
> device_initcall(ttyprintk_init);
> +module_exit(ttyprintk_exit);
> +
> +MODULE_LICENSE("GPL");
Other than this, this looks good, thanks for doing that.
R
Le Wednesday 02 April 2014 à 12:29 +0200, Takashi Iwai a écrit :
> ttyprintk driver calls tty_unregister_driver() wrongly in the error
> path of tty_register_driver(). Also, setting ttyprintk_driver to NULL
> is utterly superfluous, so let's get rid of it, too.
>
> Repor
)
> (...)
You are sending this patch to the wrong list. The ds1682 driver has
nothing to do with lm-sensors. Please use ./scripts/get_maintainer.pl
to figure out who this patch should be sent to.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe li
These serial drivers were removed in kernel v3.1, so we can drop their
documentation files and references to their magic numbers and
parameters.
There are still references to these old drivers in
Documentation/devices.txt but I'm afraid they can't be removed.
Signed-off-by: Jean D
y asks for these to
be reported. Which is what I'm doing. Better tools make future
contributions better and easier.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
f this could be fixed, either by really limiting the
warning to Kconfig entries being added (if you can) or by dropping the
check altogether (if you can't.)
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
y -staging branch for now and pull in the other
> patch as well to make sure it compiles.
I've updated the wiki accordingly, as well as sensors-detect.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Le Monday 10 March 2014 à 16:56 +0100, Jean Delvare a écrit :
> Le Friday 07 March 2014 à 21:25 +, One Thousand Gnomes a écrit :
> > On Fri, 7 Mar 2014 22:00:51 +0100
> > Jean Delvare wrote:
> >
> > > As far as I know, the CS5535 and CS5536 chipsets are compan
Le Friday 07 March 2014 à 21:25 +, One Thousand Gnomes a écrit :
> On Fri, 7 Mar 2014 22:00:51 +0100
> Jean Delvare wrote:
>
> > As far as I know, the CS5535 and CS5536 chipsets are companions of the
> > Geode series of processors, which are 32-bit only. So the CS553
/scsi/ibmvscsi/ibmvstgt.c
>
> IBM ServeRAID RAID DRIVER
> -P: Jack Hammer
> -M: Dave Jeffery
> -W: http://www.developer.ibm.com/welcome/netfinity/serveraid.html
> -S: Supported
> +S: Orphan
> F: drivers/scsi/ips.*
>
> ICH LPC AND GPIO DRIVER
Revi
quite useful (this field is obsolete.)
> -M: Dave Jeffery
> W: http://www.developer.ibm.com/welcome/netfinity/serveraid.html
This URL doesn't work for me.
> S: Supported
Which makes the validity of this claim rather dubious. I'd suggest you
remove the P and W fields cha
two components which I think can reach such high temperatures
in a laptop are the CPU and the GPU. I suppose that the "94 °C vs.
74°C" refers to acpitz's temp1? If the the temperatures reported by
coretemp remain the same, then I can only suppose that temp1 is the GPU
temperature.
The bus and architecture dependencies are already on MFD_CS5535, so
there is no need to repeat them here.
Signed-off-by: Jean Delvare
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-3.14-rc5.orig/drivers
As far as I know, the CS5535 and CS5536 chipsets are companions of the
Geode series of processors, which are 32-bit only. So the CS5535
drivers are not needed on x86-64, except for build testing purpose.
This aligns the dependencies to what FB_GEODE already uses.
Signed-off-by: Jean Delvare
Cc
On Fri, 7 Mar 2014 15:31:44 +, Laszlo Papp wrote:
> On Fri, Mar 7, 2014 at 3:25 PM, Jean Delvare wrote:
> > Hi Laszlo,
> >
> > On Fri, 7 Mar 2014 14:48:01 +, Laszlo Papp wrote:
> >> In medias res, I find this interface cumbersome:
> >> http://lxr.
fan speed? Does
the max6650 driver not return correct fan speeds for you?
--
Jean Delvare
SUSE L3 Support
--
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/
drivers/i2c/busses/Kconfig|1 +
> drivers/i2c/busses/i2c-i801.c |3 +++
> 3 files changed, 5 insertions(+), 0 deletions(-)
> (...)
Looks alright.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscri
and
review your code, Guenter wrote a more complete, better patch set. So I
thought I'd just review that one. And it was good, and it took me less
time to review and test it than to (attempt to) teach you how to behave.
Working with Guenter is a pleasure. Working with you is a pain, really.
And gu
Hi Lee,
On Thu, 13 Feb 2014 11:16:07 +, Lee Jones wrote:
> On Thu, 13 Feb 2014, Jean Delvare wrote:
> > Guenter just did:
> >
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2014-February/041224.html
>
> Nice, FWIW:
> Acked-by: Lee Jones
>
>
Hi Laszlo,
Le Thursday 13 February 2014 à 10:46 +, Laszlo Papp a écrit :
> On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp wrote:
> > On Thu, Feb 13, 2014 at 10:15 AM, Jean Delvare wrote:
> >> Any change to the max6650 driver should go on top of his patch series
>
ce *dev);
>
> It would be good to remove these forward declarations in the future.
>
> If no one volunteers I'll happily do it.
Guenter just did:
http://lists.lm-sensors.org/pipermail/lm-sensors/2014-February/041224.html
Any change to the max6650 driver should go on top of his
Le Tuesday 11 February 2014 à 08:28 +, 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 Mon, Feb 10, 2014 at 4:38 PM, Jean Delvare 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 wrote:
> > Additionally, dashes are explicitly forbidden in hwmon
> > device names.
>
> Also, where is that documented?
In Documentation/
On Mon, 10 Feb 2014 18:27:07 +, Laszlo Papp wrote:
> On Mon, Feb 10, 2014 at 5:43 PM, Jean Delvare wrote:
> > On Mon, 10 Feb 2014 16:58:53 +, Lee Jones wrote:
> >> > > Might be worth taking the opportunity to swap out these magic numbers
> >> > > n
the .data element for very simple information such as device IDs
> we do so with a #define.
Right, you have a point here.
I suppose it was deemed unneeded for a ~750 lines driver nobody really
cared about. But if the driver is becoming more complex and popular
then indeed it makes sense to clean
were device
> IDs. They should be clearly defined.
They could have been device IDs, some drivers do that, and that would
have been equally fine. driver_data can be anything. Best thing to do
is to document it right above the device id array if you really find it
confusing (I don't.) I don't know what else exactly you had in mind,
but #defining FOUR_FANS as 4 and ONE_FAN as 1 and using that doesn't
strike me as the best coding practice.
--
Jean Delvare
Suse L3 Support
--
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/
interface would seem sufficient to me. But I
think Guenter already discussed this in the past so I'll let him
continue and decide.
> Might be worth taking the opportunity to swap out these magic numbers
> now.
There's nothing magic about them, they tell the driver how many fans
Hi Mark,
On Mon, 3 Feb 2014 11:02:49 +, Mark Brown wrote:
> On Mon, Feb 03, 2014 at 10:41:41AM +0100, Jean Delvare wrote:
>
> > Can you please review / apply this patch? It fixes a real bug. I also
> > think it should go to the 3.13-stable tree.
>
> Uh, it is a
dev)
> devname = dev_name(dev);
>
> + if (have_full_constraints())
> + ret = -ENODEV;
> + else
> + ret = -EPROBE_DEFER;
> +
> mutex_lock(®ulator_list_mutex);
>
> rdev = regulator_dev_lookup(dev, id, &ret);
--
s
going in the direction. I don't know a thing about regulators, OF, DT
etc. so I am really not the right person to make a decision about this.
All I can say is: either someone comes up with a patch set which
properly fixes the regression for all lm90 drivers users, or I will have
to revert c
Hi Mark,
On Sun, 26 Jan 2014 21:22:56 +, Mark Brown wrote:
> On Sun, Jan 26, 2014 at 09:49:36PM +0100, Jean Delvare wrote:
> > On Sun, 26 Jan 2014 12:44:38 -0800, Guenter Roeck wrote:
>
> > > Maybe there is some configuration option, or maybe something needs to be
>
On Sun, 26 Jan 2014 12:44:38 -0800, Guenter Roeck wrote:
> On 01/26/2014 12:13 PM, Jean Delvare wrote:
> The regulator code changed with 3.13; the dummy regulator no longer exists,
> and the functionality it provided is supposed to be handled automatically.
> But that only rea
s patch set on
an emulated ADM1032 chip and it was working fine. So maybe it depends
on the kernel configuration, or something changed on the regulator side
meanwhile.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
rom one driver to the next.
>
> Cc: Wolfram Sang
> Cc: Jean Delvare
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Paul Gortmaker
> ---
> drivers/i2c/algos/i2c-algo-bit.c | 1 -
> drivers/i2c/algos/i2c-algo-pca.c | 1 -
> drivers/i2c/algos/i2c-algo
rom one driver to the next.
>
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: lm-sens...@lm-sensors.org
> Signed-off-by: Paul Gortmaker
> ---
> (...)
Looks good to me, and thanks for doing that.
Acked-by: Jean Delvare
--
Jean Delvare
--
To unsubscribe from this list: send
Hi Greg,
On Fri, 10 Jan 2014 07:24:02 -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 10, 2014 at 03:39:07PM +0100, Jean Delvare wrote:
> > (...)
> > Then I suppose we could inline both functions
> > again, for performance. Well, put in s
Hi Greg,
On Fri, 10 Jan 2014 07:24:02 -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 10, 2014 at 03:39:07PM +0100, Jean Delvare wrote:
> > + * @driver_data: Private pointer for driver specific info. Will turn into
> > a
> > + * list soon.
>
> Ah, this
Hi Greg,
On Thu, 9 Jan 2014 20:18:53 -0800, Greg Kroah-Hartman wrote:
> On Wed, Jan 08, 2014 at 09:33:30PM +0100, Jean Delvare wrote:
> > I consider allocating memory in dev_set_drvdata() very misleading, I
> > don't think we should keep doing that.
>
> I had to add
hromeos_laptop.c
>
> Is there some way of getting the "probe" behavior while using
> i2c_register_board_info?
No, i2c_register_board_info works only for devices which are always
present at a known address.
--
Jean Delvare
--
To unsubscribe from this list: send the line "u
On Wed, 8 Jan 2014 08:56:28 -0800, Greg Kroah-Hartman wrote:
> On Wed, Jan 08, 2014 at 04:40:58PM +0100, Jean Delvare wrote:
> > Hi Greg, hi all,
> >
> > A memory leak has been reported to me:
> > http://marc.info/?l=linux-i2c&m=138779165123331&w=2
> >
&g
ld never be used for class devices?
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/
ointer is needed by code
which runs as part of i2c_add_adapter().
We could move it right before the call to i2c_add_adapter(), to make
the problem window smaller, but this wouldn't solve the problem
completely, as i2c_add_adapter() itself can fail before
device_register() is called.
The o
dapter device-specific data. Some drivers are doing exactly that,
for example i2c-nforce2. I suspect this legacy field is now somewhat
redundant with i2c_set_adapdata() as I couldn't find any i2c bus
driver using both.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsub
ean
options which might easily be tristates.
--
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/
y, this means that you can have all pieces enabled in your
kernel but the code will be silently stubbed out because the
combinations of Y and M happens to be unsupported but this is nowhere
documented. This is wrong.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscrib
601 - 700 of 1633 matches
Mail list logo
