for correct
> purposes.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> drivers/firmware/dmi_scan.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> (...)
Yes, as discussed before, good idea.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To
. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from
SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor d
:February 2011
Contact: Mike Waychison mi...@google.com
Description:
Thanks for doing this.
Reviewed-by: Jean Delvare jdelv...@suse.de
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Khoronzhuk ivan.khoronz...@globallogic.com
---
drivers/firmware/dmi_scan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
(...)
Yes, as discussed before, good idea.
Reviewed-by: Jean Delvare jdelv...@suse.de
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send
. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare jdelv...@suse.de
Fixes: 9f9c9cbb6057 (drivers/firmware/dmi_scan.c: fetch dmi version from
SMBIOS if it exists)
Fixes: 79bae42d51a5 (dmi_scan: refactor
;
>
> @@ -913,7 +914,7 @@ int dmi_walk(void (*decode)(const struct dmi_header *,
> void *),
> if (buf == NULL)
> return -1;
>
> - dmi_table(buf, dmi_len, dmi_num, decode, private_data);
> + dmi_table(buf, decode, private_data);
>
> dmi_unmap(buf);
> return 0;
--
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/
@@ static int __init dmi_smbios3_present(const u8 *buf)
> dmi_num = dmi_len / 4;
>
> if (dmi_walk_early(dmi_decode) == 0) {
> - pr_info("SMBIOS %d.%d present.\n",
> - dmi_ver >> 8, dmi_
*,
void *),
if (buf == NULL)
return -1;
- dmi_table(buf, dmi_len, dmi_num, decode, private_data);
+ dmi_table(buf, decode, private_data);
dmi_unmap(buf);
return 0;
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line
: %s\n, dmi_ids_string);
return 0;
--
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
> can leave that for someone who is acutally using the driver. However, I
> wonder if ENODEV is a proper catch-all case because the driver core will
> not report failures.
It doesn't really matter that the error codes are different, it matters
that they are meaningful. As much as possible yo
() and
i2c_bit_add_bus() return proper error codes so you should record and
transmit them. Only parport_register_device() does not, so you have to
craft one and -ENODEV seems appropriate to me.
Note: I can test this driver.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send
hael S. Tsirkin
>
> Acked-by: Wolfram Sang
>
> I don't know if I should take it. If so, let me know.
Don't, the series was nacked meanwhile.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Acked-by: Wolfram Sang w...@the-dreams.de
I don't know if I should take it. If so, let me know.
Don't, the series was nacked meanwhile.
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
numerated values, or both)?
Having a real-world example would make testing much easier.
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://
Le Thursday 02 April 2015 à 14:05 +0200, Michael S. Tsirkin a écrit :
> On Thu, Apr 02, 2015 at 01:15:30PM +0200, Jean Delvare wrote:
> > Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit :
> > > On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote:
>
Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit :
> On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote:
> > Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit :
> > > The class ids are a hardware defintion, not a ker
nes would better come from
pciutils-devel, not the kernel.
--
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
guarantees. But I don't know if
the user-space projects you quoted actually use that, so even that may
not be worth it.
--
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
Mo
come from
pciutils-devel, not the kernel.
--
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
use that, so even that may
not be worth it.
--
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
Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit :
On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote:
Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit :
The class ids are a hardware defintion, not a kernel API. Just use the
definitions from
a real-world example would make testing much easier.
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
Le Thursday 02 April 2015 à 14:05 +0200, Michael S. Tsirkin a écrit :
On Thu, Apr 02, 2015 at 01:15:30PM +0200, Jean Delvare wrote:
Le Thursday 02 April 2015 à 12:09 +0200, Michael S. Tsirkin a écrit :
On Thu, Apr 02, 2015 at 11:04:16AM +0200, Jean Delvare wrote:
Le Thursday 02 April
hat, ACPI should provide a clean and safe way to
access the chip's registers (read: some mutex to avoid concurrent
access to the registers by the BIOS and the OS.)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
0x0f12
> #define PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS 0x2292
> #define PCI_DEVICE_ID_INTEL_COUGARPOINT_SMBUS 0x1c22
No objection from me.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscr
.h,
> +names for the bridge ID and the subvendor ID in include/uapi/linux/pci_ids.h,
> and then add a case for your subdevice ID at the right place in
> drivers/pci/quirks.c. Then please give it very good testing, to make sure
> that the unhidden SMBus doesn't conflict with e.g. ACP
and safe way to
access the chip's registers (read: some mutex to avoid concurrent
access to the registers by the BIOS and the OS.)
--
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
/pci_ids.h,
and then add a case for your subdevice ID at the right place in
drivers/pci/quirks.c. Then please give it very good testing, to make sure
that the unhidden SMBus doesn't conflict with e.g. ACPI.
No objection from me.
Reviewed-by: Jean Delvare jdelv...@suse.de
--
Jean Delvare
SUSE L3
PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS 0x2292
#define PCI_DEVICE_ID_INTEL_COUGARPOINT_SMBUS0x1c22
No objection from me.
Reviewed-by: Jean Delvare jdelv...@suse.de
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Matt,
Le Friday 27 March 2015 à 12:12 +, Matt Fleming a écrit :
> On Thu, 26 Mar, at 04:21:53PM, Jean Delvare wrote:
> > Le Thursday 26 March 2015 à 14:47 +, Matt Fleming a écrit :
> > > On Thu, 26 Mar, at 02:15:05PM, Jean Delvare wrote:
> > > >
> &
Hi Matt,
Le Friday 27 March 2015 à 12:12 +, Matt Fleming a écrit :
On Thu, 26 Mar, at 04:21:53PM, Jean Delvare wrote:
Le Thursday 26 March 2015 à 14:47 +, Matt Fleming a écrit :
On Thu, 26 Mar, at 02:15:05PM, Jean Delvare wrote:
I don't actually have a tree, so feel free
Le Thursday 26 March 2015 à 14:47 +, Matt Fleming a écrit :
> On Thu, 26 Mar, at 02:15:05PM, Jean Delvare wrote:
> >
> > I don't actually have a tree, so feel free to pick it.
>
> OK will do, but this is a regression fix for a potential bug introduced
> in commit
; >59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
> >d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3
> >
> > Am I still sending those for v4.1?
FWIW I have still not reviewed these, I would like to, but my current
health condition make my
Hi Matt,
Le Thursday 26 March 2015 à 13:06 +, Matt Fleming a écrit :
> On Fri, 20 Mar, at 09:59:47AM, Jean Delvare wrote:
> > dmi_num is a u16, dmi_len is a u32, so this construct:
> >
> > dmi_num = dmi_len / 4;
> >
> > would result in an integer ove
Hi Matt,
Le Thursday 26 March 2015 à 13:06 +, Matt Fleming a écrit :
On Fri, 20 Mar, at 09:59:47AM, Jean Delvare wrote:
dmi_num is a u16, dmi_len is a u32, so this construct:
dmi_num = dmi_len / 4;
would result in an integer overflow for a DMI table larger than
256 kB. I've
Le Thursday 26 March 2015 à 14:47 +, Matt Fleming a écrit :
On Thu, 26 Mar, at 02:15:05PM, Jean Delvare wrote:
I don't actually have a tree, so feel free to pick it.
OK will do, but this is a regression fix for a potential bug introduced
in commit 6d9ff4733172 (firmware: dmi_scan
version for SMBIOS3
Am I still sending those for v4.1?
FWIW I have still not reviewed these, I would like to, but my current
health condition make my progress slower than usual :/
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
I am familiar with these drivers and I care about them so let me add
myself as their maintainer.
Signed-off-by: Jean Delvare
Cc: Matt Fleming
---
MAINTAINERS |7 +++
1 file changed, 7 insertions(+)
--- linux-4.0-rc4.orig/MAINTAINERS 2015-03-19 14:19:56.179421725 +0100
+++ linux
I am familiar with these drivers and I care about them so let me add
myself as their maintainer.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Matt Fleming matt.flem...@intel.com
---
MAINTAINERS |7 +++
1 file changed, 7 insertions(+)
--- linux-4.0-rc4.orig/MAINTAINERS 2015-03
On Fri, 20 Mar 2015 12:00:34 +, Matt Fleming wrote:
> On Fri, 2015-03-20 at 09:16 +0100, Jean Delvare wrote:
> >
> > OK, I understand. Now I see the two patches I was missing, I'll pick
> > them so that I can apply your patch cleanly on top of my tree.
> >
&
of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.
Signed-off-by: Jean Delvare
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: Ivan Khoronzhuk
---
drivers/firmware/dmi_scan.c | 22
Hi Ivan,
On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:
> On 19.03.15 17:30, Jean Delvare wrote:
> > Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :
> >> Some utils, like dmidecode and smbios, need to access SMBIOS entry
> >> table area
Hi Ivan,
On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:
On 19.03.15 17:30, Jean Delvare wrote:
Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS
of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Matt Fleming matt.flem...@intel.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Cc
On Fri, 20 Mar 2015 12:00:34 +, Matt Fleming wrote:
On Fri, 2015-03-20 at 09:16 +0100, Jean Delvare wrote:
OK, I understand. Now I see the two patches I was missing, I'll pick
them so that I can apply your patch cleanly on top of my tree.
I would have appreciated to be Cc'd
ctly without /dev/mem. Also patch adds
> raw dmi table to simplify dmi table processing in user space, as were
> proposed by Jean Delvare.
"as was proposed" or even "as proposed" sounds more correct.
BTW, which tree is your patch based on? I can't get it to apply cle
adds
raw dmi table to simplify dmi table processing in user space, as were
proposed by Jean Delvare.
as was proposed or even as proposed sounds more correct.
BTW, which tree is your patch based on? I can't get it to apply cleanly
on top of any kernel version I tried. I adjusted the patch to my tree
Le Monday 16 March 2015 à 16:03 +0100, Jiri Kosina a écrit :
> On Fri, 20 Feb 2015, Jean Delvare wrote:
>
> > Many HID driver options are hidden unless EXPERT is set. While I
> > understand the idea of simplifying the kernel configuration for most
> > users, in practic
Le Monday 16 March 2015 à 16:03 +0100, Jiri Kosina a écrit :
On Fri, 20 Feb 2015, Jean Delvare wrote:
Many HID driver options are hidden unless EXPERT is set. While I
understand the idea of simplifying the kernel configuration for most
users, in practice I believe it adds more confusion
Hi Ivan,
Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.
Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :
> On 02/26/2015 11:36 AM, Jean Delvare wrote:
> > On Wed, 4 Feb 2015
Hi Ivan,
Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.
Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :
On 02/26/2015 11:36 AM, Jean Delvare wrote:
On Wed, 4 Feb 2015 19:06:03 +0200
lease tell me what way you prefer.
>
> I like the idea of removing the depends on ARCH completely. Jean, what
> do you think?
Removing the dependency completely will let the option be displayed on
systems where the driver is useless. I am in favor of having hardware
dependencies on
.) Dropping it completely only makes sense if the part
is used on so many systems that the dependency becomes too long or is a
pain to maintain.
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
On Sun, 8 Mar 2015 18:38:57 +0100, Ard Biesheuvel wrote:
> On 8 March 2015 at 18:11, Jean Delvare wrote:
> > On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
> >> And the 32-bit entry point could well be 3.0 anyway, if
> >> it uses any of the new enum values f
On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
> On 8 March 2015 at 12:31, Jean Delvare wrote:
> > On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
> >> The specification doesn't oblige firmware to provide two entry points.
> >> An implementation ma
Hi Ivan,
On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
> On 03/05/2015 09:46 AM, Jean Delvare wrote:
> > It's not just two tables (I don't expect a lot of BIOSes to provide two
> > tables in practice, and they would have essentially the same format
> > anyway)
The bh1780gli driver does not create an i2c module alias for the
device it supports, preventing the driver from being loaded
automatically when needed on non-OF/DT systems. Add it.
Signed-off-by: Jean Delvare
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/bh1780gli.c |2 ++
1
On Sun, 8 Mar 2015 18:38:57 +0100, Ard Biesheuvel wrote:
On 8 March 2015 at 18:11, Jean Delvare jdelv...@suse.de wrote:
On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
And the 32-bit entry point could well be 3.0 anyway, if
it uses any of the new enum values for the data items
The bh1780gli driver does not create an i2c module alias for the
device it supports, preventing the driver from being loaded
automatically when needed on non-OF/DT systems. Add it.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg Kroah-Hartman gre
Hi Ivan,
On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
On 03/05/2015 09:46 AM, Jean Delvare wrote:
It's not just two tables (I don't expect a lot of BIOSes to provide two
tables in practice, and they would have essentially the same format
anyway) but more importantly two entry
On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
On 8 March 2015 at 12:31, Jean Delvare jdelv...@suse.de wrote:
On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
The specification doesn't oblige firmware to provide two entry points.
An implementation may provide either
Hi Ivan,
On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:
> On 02/26/2015 11:41 AM, Jean Delvare wrote:
> > On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
> >> Please also note that the recently released version 3.0.0 of the SMBIOS
> >> specifica
Hi Ivan,
On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:
On 02/26/2015 11:41 AM, Jean Delvare wrote:
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format
, it's about time.
Signed-off-by: Jean Delvare
Cc: Andrew Morton
---
kernel/fork.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-4.0-rc1.orig/kernel/fork.c2015-02-23 03:21:14.0 +0100
+++ linux-4.0-rc1/kernel/fork.c 2015-03-02 10:48:45.407215590 +0100
@@ -270,8
, it's about time.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Andrew Morton a...@linux-foundation.org
---
kernel/fork.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-4.0-rc1.orig/kernel/fork.c2015-02-23 03:21:14.0 +0100
+++ linux-4.0-rc1/kernel/fork.c 2015
Replying to myself...
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
> Please also note that the recently released version 3.0.0 of the SMBIOS
> specification introduces a new entry point format, and the firmware is
> allowed to implement both the old and the new forma
}
> static inline const struct dmi_system_id *
> dmi_first_match(const struct dmi_system_id *list) { return NULL; }
> +static inline const u8 *dmi_get_smbios_entry_area(int *size)
> + { return NULL; }
>
> #endif
>
There's one thing I do not understand. I seem
d, but we consider
> >> the top entry type is only 8 bits */
> >>
> >> +static const u8 *smbios_raw_header;
It's called an entry point in the specification and every document out
there (including your own text above), why do you want to suddenly call
it a "header"? The term "header" is used to designate something
completely different in the context of DMI/SMBIOS data so I find it
quite confusing.
Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may be
desirable to expose both to user-space under different names.
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/
and the new format. It may be
desirable to expose both to user-space under different names.
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
Replying to myself...
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may
anything, does it?
If we expose the raw DMI/SMBIOS entry point through sysfs, I believe we
want to expose the DMI table there too.
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
ny arbitrary
string to MODULE_ALIAS(). This would still break insmod but pretty much
everyone is calling modprobe to load kernel modules anyway.
--
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.k
(). This would still break insmod but pretty much
everyone is calling modprobe to load kernel modules anyway.
--
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
The asm9260_timer driver is useless if not building a MACH_ASM9260
kernel, so add the proper dependency to hide it for all other users
by default.
Signed-off-by: Jean Delvare
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: Oleksij Rempel
---
drivers/clocksource/Kconfig |1 +
1 file changed, 1
ly voids the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare
Cc: Jiri Kosina
---
No change since last
the original point.
For this reason, I would like all HID device tristate options to be
displayed regardless of EXPERT being set or not. We can let the
default settings still depend on EXPERT, that's not intrusive.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Jiri Kosina jkos...@suse.cz
The asm9260_timer driver is useless if not building a MACH_ASM9260
kernel, so add the proper dependency to hide it for all other users
by default.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Oleksij Rempel li
a7fc02b0f29f627f628309
Author: Andy Shevchenko
Date: Fri Jan 2 16:17:24 2015 +0200
dmaengine: dw: provide DMA capabilities
Brian, can you please try the latest Linus or linux-next kernel (or
backport the above commit to your current kernel) and confirm that the
backtraces
the latest Linus or linux-next kernel (or
backport the above commit to your current kernel) and confirm that the
backtraces are no longer printed?
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
SMBus
> access functions.
>
> Use regmap_smbus_read_word_swapped and regmap_smbus_write_word_swapped
> for 16 bit SMBus accesses unless a chip is registered with val_format_endian
> set to REGMAP_ENDIAN_LITTLE. In the latter case, keep using
> regmap_smbus_write_word_data and regmap_smbus_read_word_data.
and regmap_smbus_write_word_swapped
for 16 bit SMBus accesses unless a chip is registered with val_format_endian
set to REGMAP_ENDIAN_LITTLE. In the latter case, keep using
regmap_smbus_write_word_data and regmap_smbus_read_word_data.
Cc: Jean Delvare jdelv...@suse.de
Signed-off-by: Guenter Roeck li
n.
>
> Applied for next. Thanks!
Great, thank you very much!
--
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/majordom
Hi Ulf,
On Thu, 29 Jan 2015 16:01:48 +0100, Ulf Hansson wrote:
> On 29 January 2015 at 15:17, Jean Delvare wrote:
> > On Wed, 28 Jan 2015 15:04:24 +0100, Ulf Hansson wrote:
> >> For those SOC that want these drivers, they should be able to select
> >> the
Hi Ulf,
On Thu, 29 Jan 2015 16:01:48 +0100, Ulf Hansson wrote:
On 29 January 2015 at 15:17, Jean Delvare jdelv...@suse.de wrote:
On Wed, 28 Jan 2015 15:04:24 +0100, Ulf Hansson wrote:
For those SOC that want these drivers, they should be able to select
them from their defconfigs. So
. Thanks!
Great, thank you very much!
--
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
Hi Ulf,
On Wed, 28 Jan 2015 15:04:24 +0100, Ulf Hansson wrote:
> On 27 January 2015 at 15:34, Jean Delvare wrote:
> > Hi Ulf,
> >
> > Le Tuesday 27 January 2015 à 15:06 +0100, Ulf Hansson a écrit :
> >> On 26 January 2015 at 11:23, Jean Delvare wrote:
> >>
Hi Ulf,
On Wed, 28 Jan 2015 15:04:24 +0100, Ulf Hansson wrote:
On 27 January 2015 at 15:34, Jean Delvare jdelv...@suse.de wrote:
Hi Ulf,
Le Tuesday 27 January 2015 à 15:06 +0100, Ulf Hansson a écrit :
On 26 January 2015 at 11:23, Jean Delvare jdelv...@suse.de wrote:
I seem
t treats i2c word read operations. I'll have to look into it
> some more.
Remember that SMBus specifies that the LSB comes first (and i2c-core
implement things that way) while real I2C devices typically send the MSB
first. This has always caused confusion. This is why a lot of drivers
need
Hi Ulf,
Le Tuesday 27 January 2015 à 15:06 +0100, Ulf Hansson a écrit :
> On 26 January 2015 at 11:23, Jean Delvare wrote:
> > 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
&
arlier, might it
> be some specific configuration I miss?
How are you testing/reading exactly?
--
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:/
Hi Ulf,
Le Tuesday 27 January 2015 à 15:06 +0100, Ulf Hansson a écrit :
On 26 January 2015 at 11:23, Jean Delvare jdelv...@suse.de wrote:
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 the LSB comes first (and i2c-core
implement things that way) while real I2C devices typically send the MSB
first. This has always caused confusion. This is why a lot of drivers
need byte-swapping.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
testing/reading exactly?
--
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
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
Acked
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 jdelv...@suse.de
Cc: Chris Ball ch...@printf.net
Cc: Ulf Hansson
r a chip named TMP435. Looks like TI forgot to
update the value when copying the datasheet from TMP431 to TMP435.
Thanks for the dump, by the way :)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
r need it. Old tricks are hard to forget.
The only way to make sure is to find current users of i8kutils and see
what they (think they would) lose if i8kutils goes away.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
tricks are hard to forget.
The only way to make sure is to find current users of i8kutils and see
what they (think they would) lose if i8kutils goes away.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
for the dump, by the way :)
--
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/
com/support/home/us/en/19/product-support/product/inspiron-8000/manuals
--
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/major
901 - 1000 of 3166 matches
Mail list logo
