Re: [PATCH 4.14 044/100] ACPICA: AML interpreter: add region addresses in global list during initialization

2018-11-29 Thread Jean Delvare
So how can the fix be needed in any kernel older than v4.17? Erik, did I understand you incorrectly? -- Jean Delvare SUSE L3 Support

Re: Backed up kernels

2018-11-21 Thread Jean Delvare
Hi Masahiro, On Wed, 21 Nov 2018 15:59:49 +0900, Masahiro Yamada wrote: > On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare wrote: > > Therefore I am asking, can we change "make install" so that it does NOT > > create a backup copy of an existing kernel? > > I th

Re: Backed up kernels

2018-11-21 Thread Jean Delvare
Hi Masahiro, On Wed, 21 Nov 2018 15:59:49 +0900, Masahiro Yamada wrote: > On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare wrote: > > Therefore I am asking, can we change "make install" so that it does NOT > > create a backup copy of an existing kernel? > > I th

Backed up kernels

2018-11-20 Thread Jean Delvare
"make install" so that it does NOT create a backup copy of an existing kernel? Thanks, -- Jean Delvare SUSE L3 Support

Backed up kernels

2018-11-20 Thread Jean Delvare
"make install" so that it does NOT create a backup copy of an existing kernel? Thanks, -- Jean Delvare SUSE L3 Support

[PATCH] mfd: at91-usart: Add platform dependency

2018-11-12 Thread Jean Delvare
It doesn't make sense to present option MFD_AT91_USART by default if not building an AT91 kernel, as the drivers which depend on it are not available. Signed-off-by: Jean Delvare Fixes: 7d3aa342cef7 ("mfd: at91-usart: Add MFD driver for USART") Cc: Radu Pirea Cc: Lee Jones --- As a

[PATCH] mfd: at91-usart: Add platform dependency

2018-11-12 Thread Jean Delvare
It doesn't make sense to present option MFD_AT91_USART by default if not building an AT91 kernel, as the drivers which depend on it are not available. Signed-off-by: Jean Delvare Fixes: 7d3aa342cef7 ("mfd: at91-usart: Add MFD driver for USART") Cc: Radu Pirea Cc: Lee Jones --- As a

[PATCH RESEND] eeprom: New ee1004 driver for DDR4 memory

2018-10-07 Thread Jean Delvare
-by: Jean Delvare --- It was suggested that this driver could maybe use regmap, however I'm not familiar with that and do not have the time to look into it. The driver is functional, so please include it as is, and whoever cares and has the knowledge can convert it to use regmap later. Thanks

[PATCH RESEND] eeprom: New ee1004 driver for DDR4 memory

2018-10-07 Thread Jean Delvare
-by: Jean Delvare --- It was suggested that this driver could maybe use regmap, however I'm not familiar with that and do not have the time to look into it. The driver is functional, so please include it as is, and whoever cares and has the knowledge can convert it to use regmap later. Thanks

Re: [PATCH] eeprom: New ee1004 driver for DDR4 memory

2018-10-02 Thread Jean Delvare
On Mon, 26 Feb 2018 14:40:42 +0100, Bartosz Golaszewski wrote: > 2018-02-26 10:20 GMT+01:00 Jean Delvare : > > The EEPROMs which hold the SPD data on DDR4 memory modules are no > > longer standard AT24C02-compatible EEPROMs. They are 512-byte EEPROMs > > which use only 1

Re: [PATCH] eeprom: New ee1004 driver for DDR4 memory

2018-10-02 Thread Jean Delvare
On Mon, 26 Feb 2018 14:40:42 +0100, Bartosz Golaszewski wrote: > 2018-02-26 10:20 GMT+01:00 Jean Delvare : > > The EEPROMs which hold the SPD data on DDR4 memory modules are no > > longer standard AT24C02-compatible EEPROMs. They are 512-byte EEPROMs > > which use only 1

Re: [PATCH] i2c: i2c-isch: fix spelling mistake "unitialized" -> "uninitialized"

2018-09-24 Thread Jean Delvare
defaults\n"); > outw(backbone_speed / (4 * 100), SMBHSTCLK); > } > Reviewed-by: Jean Delvare Thanks, -- Jean Delvare SUSE L3 Support

Re: [PATCH] i2c: i2c-isch: fix spelling mistake "unitialized" -> "uninitialized"

2018-09-24 Thread Jean Delvare
defaults\n"); > outw(backbone_speed / (4 * 100), SMBHSTCLK); > } > Reviewed-by: Jean Delvare Thanks, -- Jean Delvare SUSE L3 Support

Re: [PATCH 2/2] s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its function

2018-09-08 Thread Jean Delvare
sizeof(struct ipa_cmd_names)-1].cmd = cmd; > + qeth_ipa_cmd_names[ARRAY_SIZE(qeth_ipa_cmd_names) - 1].cmd = cmd; > while (qeth_ipa_cmd_names[x].cmd != cmd) > x++; > return qeth_ipa_cmd_names[x].name; Reviewed-by: Jean Delvare BTW, t

Re: [PATCH 2/2] s390: qeth_core_mpc: Use ARRAY_SIZE instead of reimplementing its function

2018-09-08 Thread Jean Delvare
sizeof(struct ipa_cmd_names)-1].cmd = cmd; > + qeth_ipa_cmd_names[ARRAY_SIZE(qeth_ipa_cmd_names) - 1].cmd = cmd; > while (qeth_ipa_cmd_names[x].cmd != cmd) > x++; > return qeth_ipa_cmd_names[x].name; Reviewed-by: Jean Delvare BTW, t

Re: [PATCH 1/2] s390: vmlogrdr: Use ARRAY_SIZE instead of reimplementing its function

2018-09-08 Thread Jean Delvare
*, > } > }; > > -#define MAXMINOR (sizeof(sys_ser)/sizeof(struct vmlogrdr_priv_t)) > +#define MAXMINOR ARRAY_SIZE(sys_ser) > > static char FENCE[] = {"EOR"}; > static int vmlogrdr_major = 0; Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH 1/2] s390: vmlogrdr: Use ARRAY_SIZE instead of reimplementing its function

2018-09-08 Thread Jean Delvare
*, > } > }; > > -#define MAXMINOR (sizeof(sys_ser)/sizeof(struct vmlogrdr_priv_t)) > +#define MAXMINOR ARRAY_SIZE(sys_ser) > > static char FENCE[] = {"EOR"}; > static int vmlogrdr_major = 0; Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

[PATCH v2] ACPI / bus: Only call dmi_check_system on X86

2018-09-04 Thread Jean Delvare
also result in warnings. Best is to not call the function when it can't work and isn't needed. Additionally, if anyone ever needs to add non-x86 quirks, it would surprisingly not work, so document the limitation to avoid confusion. Signed-off-by: Jean Delvare Fixes: cce4f632db20 ("ACPI: fix

[PATCH v2] ACPI / bus: Only call dmi_check_system on X86

2018-09-04 Thread Jean Delvare
also result in warnings. Best is to not call the function when it can't work and isn't needed. Additionally, if anyone ever needs to add non-x86 quirks, it would surprisingly not work, so document the limitation to avoid confusion. Signed-off-by: Jean Delvare Fixes: cce4f632db20 ("ACPI: fix

Re: linux-next: manual merge of the dmi tree with Linus' tree

2018-09-04 Thread Jean Delvare
cts. Thanks for the heads up. I have rebased my dmi tree on top of 4.19-rc2, and this solves the conflict. -- Jean Delvare SUSE L3 Support

Re: linux-next: manual merge of the dmi tree with Linus' tree

2018-09-04 Thread Jean Delvare
cts. Thanks for the heads up. I have rebased my dmi tree on top of 4.19-rc2, and this solves the conflict. -- Jean Delvare SUSE L3 Support

[PATCH RESEND] firmware: google: make structure gsmi_dev static

2018-09-03 Thread Jean Delvare
King Signed-off-by: Jean Delvare --- Colin submitted this trivial patch twice already (2017-10-03, 2018-06-01) but nobody picked it. Greg, can you take this in one of your trees? Or should it go through Andrew? Thanks. drivers/firmware/google/gsmi.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH RESEND] firmware: google: make structure gsmi_dev static

2018-09-03 Thread Jean Delvare
King Signed-off-by: Jean Delvare --- Colin submitted this trivial patch twice already (2017-10-03, 2018-06-01) but nobody picked it. Greg, can you take this in one of your trees? Or should it go through Andrew? Thanks. drivers/firmware/google/gsmi.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] ACPI / bus: Only call dmi_check_system on X86

2018-08-29 Thread Jean Delvare
also result in warnings. Best is to not call the function when it can't work and isn't needed. Additionally, if anyone ever needs to add non-x86 quirks, it would surprisingly not work, so document the limitation to avoid confusion. Signed-off-by: Jean Delvare Fixes: cce4f632db20 ("ACPI: fix

[PATCH] ACPI / bus: Only call dmi_check_system on X86

2018-08-29 Thread Jean Delvare
also result in warnings. Best is to not call the function when it can't work and isn't needed. Additionally, if anyone ever needs to add non-x86 quirks, it would surprisingly not work, so document the limitation to avoid confusion. Signed-off-by: Jean Delvare Fixes: cce4f632db20 ("ACPI: fix

Re: [PULL REQUEST] i2c for 4.19

2018-08-27 Thread Jean Delvare
update > * some SPDX conversion > > CCing Jean on this one, he will probably be happy to finally see > attach_adapter be gone for good as well :) You have no idea :-) Huge thanks to everyone who made it happen! -- Jean Delvare SUSE L3 Support

Re: [PULL REQUEST] i2c for 4.19

2018-08-27 Thread Jean Delvare
update > * some SPDX conversion > > CCing Jean on this one, he will probably be happy to finally see > attach_adapter be gone for good as well :) You have no idea :-) Huge thanks to everyone who made it happen! -- Jean Delvare SUSE L3 Support

native_save_fl() causes a warning

2018-08-03 Thread Jean Delvare
native_restore_fl(), native_irq_disable() and native_irq_enable() are equally referenced by address in arch/x86/kernel/paravirt.c and thus should suffer from the same problem. Can you explain? Thanks, -- Jean Delvare SUSE L3 Support

native_save_fl() causes a warning

2018-08-03 Thread Jean Delvare
native_restore_fl(), native_irq_disable() and native_irq_enable() are equally referenced by address in arch/x86/kernel/paravirt.c and thus should suffer from the same problem. Can you explain? Thanks, -- Jean Delvare SUSE L3 Support

Re: [PATCH] misc: eeprom: assignment outside the if statement

2018-08-03 Thread Jean Delvare
n -ENOMEM; > > /* A fake client is created on the odd address */ Reviewed-by: Jean Delvare Thanks, -- Jean Delvare SUSE L3 Support

Re: [PATCH] misc: eeprom: assignment outside the if statement

2018-08-03 Thread Jean Delvare
n -ENOMEM; > > /* A fake client is created on the odd address */ Reviewed-by: Jean Delvare Thanks, -- Jean Delvare SUSE L3 Support

[GIT PULL] dmi update for v4.18

2018-06-17 Thread Jean Delvare
files changed, 4 insertions(+) --- Simon Glass (1): firmware: dmi: Add access to the SKU ID string Thanks, -- Jean Delvare SUSE L3 Support

[GIT PULL] dmi update for v4.18

2018-06-17 Thread Jean Delvare
files changed, 4 insertions(+) --- Simon Glass (1): firmware: dmi: Add access to the SKU ID string Thanks, -- Jean Delvare SUSE L3 Support

Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)

2018-06-13 Thread Jean Delvare
uble. So feel free to go ahead and remove it if you think this is the best thing to do. If some users complain about the change, I'll let you deal with them ;-) -- Jean Delvare SUSE L3 Support

Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)

2018-06-13 Thread Jean Delvare
uble. So feel free to go ahead and remove it if you think this is the best thing to do. If some users complain about the change, I'll let you deal with them ;-) -- Jean Delvare SUSE L3 Support

Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)

2018-06-13 Thread Jean Delvare
which parts should not, and not about presentation issues. Considering that "inline" is the default for a non-multi-part message, any MUA which changes its behavior in the presence of "Content-Disposition: inline" is bugged in my opinion. -- Jean Delvare SUSE L3 Support

Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)

2018-06-13 Thread Jean Delvare
which parts should not, and not about presentation issues. Considering that "inline" is the default for a non-multi-part message, any MUA which changes its behavior in the presence of "Content-Disposition: inline" is bugged in my opinion. -- Jean Delvare SUSE L3 Support

Re: [PATCH] firmware-gsmi: make structure gsmi_dev static

2018-06-04 Thread Jean Delvare
gsmi_device { > struct platform_device *pdev; /* platform device */ > struct gsmi_buf *name_buf; /* variable name buffer */ > struct gsmi_buf *data_buf; /* generic data buffer */ Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH] firmware-gsmi: make structure gsmi_dev static

2018-06-04 Thread Jean Delvare
gsmi_device { > struct platform_device *pdev; /* platform device */ > struct gsmi_buf *name_buf; /* variable name buffer */ > struct gsmi_buf *data_buf; /* generic data buffer */ Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: fix unused-function warning

2018-05-15 Thread Jean Delvare
sed, instead of crippling the code with yet another annotation. I can't see how building unused code only to discard it later can be better than a proper #ifdef which will only build the code when we actually need it. Maybe there are cases where __maybe_unused is actually needed, but in my opinion that should be the last resort option. That's not the case here. -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: fix unused-function warning

2018-05-15 Thread Jean Delvare
ith yet another annotation. I can't see how building unused code only to discard it later can be better than a proper #ifdef which will only build the code when we actually need it. Maybe there are cases where __maybe_unused is actually needed, but in my opinion that should be the last resort option. That's not the case here. -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: fix unused-function warning

2018-05-14 Thread Jean Delvare
i2c/busses/i2c-i801.c > @@ -1710,7 +1710,7 @@ static void i801_shutdown(struct pci_dev *dev) > pci_write_config_byte(dev, SMBHSTCFG, priv->original_hstcfg); > } > > -#ifdef CONFIG_PM > +#ifdef CONFIG_PM_SLEEP > static int i801_suspend(struct device *dev) > { > struct pci_dev *pci_dev = to_pci_dev(dev); Reviewed-by: Jean Delvare <jdelv...@suse.de> Thanks, -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: fix unused-function warning

2018-05-14 Thread Jean Delvare
10,7 @@ static void i801_shutdown(struct pci_dev *dev) > pci_write_config_byte(dev, SMBHSTCFG, priv->original_hstcfg); > } > > -#ifdef CONFIG_PM > +#ifdef CONFIG_PM_SLEEP > static int i801_suspend(struct device *dev) > { > struct pci_dev *pci_dev = to_pci_dev(dev); Reviewed-by: Jean Delvare Thanks, -- Jean Delvare SUSE L3 Support

Re: drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

2018-05-14 Thread Jean Delvare
On Mon, 14 May 2018 10:12:00 +0200, Borislav Petkov wrote: > On Mon, May 14, 2018 at 10:05:30AM +0200, Jean Delvare wrote: > > I'll send a candidate fix shortly. > > https://lkml.kernel.org/r/3af91354-8e19-d2af-1bba-ced8dce05...@infradead.org Thanks for the link, appa

Re: drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

2018-05-14 Thread Jean Delvare
On Mon, 14 May 2018 10:12:00 +0200, Borislav Petkov wrote: > On Mon, May 14, 2018 at 10:05:30AM +0200, Jean Delvare wrote: > > I'll send a candidate fix shortly. > > https://lkml.kernel.org/r/3af91354-8e19-d2af-1bba-ced8dce05...@infradead.org Thanks for the link, appa

Re: drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

2018-05-14 Thread Jean Delvare
G_ACPI_NFIT=m CONFIG_EDAC_SKX=y Built-in code (skx_edac) can't reference a function from a module (nfit). I'll send a candidate fix shortly. -- Jean Delvare SUSE L3 Support

Re: drivers/edac/skx_edac.c:399: undefined reference to `nfit_get_smbios_id'

2018-05-14 Thread Jean Delvare
G_ACPI_NFIT=m CONFIG_EDAC_SKX=y Built-in code (skx_edac) can't reference a function from a module (nfit). I'll send a candidate fix shortly. -- Jean Delvare SUSE L3 Support

Re: [PATCH] swiotlb: Silent unwanted warning "buffer is full"

2018-05-13 Thread Jean Delvare
what caused the problem on your end. You would think our tools are able to deal with accentuated characters properly in 2018 but apparently not :-( -- Jean Delvare SUSE L3 Support

Re: [PATCH] swiotlb: Silent unwanted warning "buffer is full"

2018-05-13 Thread Jean Delvare
what caused the problem on your end. You would think our tools are able to deal with accentuated characters properly in 2018 but apparently not :-( -- Jean Delvare SUSE L3 Support

Re: [PATCH] i2c: i801: mark PM functions as __maybe_unused

2018-05-10 Thread Jean Delvare
On Wed, 9 May 2018 19:00:55 +0200, Jean Delvare wrote: > If SIMPLE_DEV_PM_OPS causes it but UNIVERSAL_DEV_PM_OPS did not, I > suppose that what matters is CONFIG_PM_SLEEP. > > So maybe we can just replace "#ifdef CONFIG_PM" with "ifdef > CONFIG_PM_SLEEP" in the

Re: [PATCH] i2c: i801: mark PM functions as __maybe_unused

2018-05-10 Thread Jean Delvare
On Wed, 9 May 2018 19:00:55 +0200, Jean Delvare wrote: > If SIMPLE_DEV_PM_OPS causes it but UNIVERSAL_DEV_PM_OPS did not, I > suppose that what matters is CONFIG_PM_SLEEP. > > So maybe we can just replace "#ifdef CONFIG_PM" with "ifdef > CONFIG_PM_SLEEP" in the

Re: [PATCH] i2c: i801: mark PM functions as __maybe_unused

2018-05-09 Thread Jean Delvare
et_drvdata(pci_dev); > @@ -1720,7 +1720,7 @@ static int i801_suspend(struct device *dev) > return 0; > } > > -static int i801_resume(struct device *dev) > +static int __maybe_unused i801_resume(struct device *dev) > { > struct pci_dev *pci_dev = to_pci_dev(dev); > struct i801_priv *priv = pci_get_drvdata(pci_dev); -- Jean Delvare SUSE L3 Support

Re: [PATCH] i2c: i801: mark PM functions as __maybe_unused

2018-05-09 Thread Jean Delvare
20,7 +1720,7 @@ static int i801_suspend(struct device *dev) > return 0; > } > > -static int i801_resume(struct device *dev) > +static int __maybe_unused i801_resume(struct device *dev) > { > struct pci_dev *pci_dev = to_pci_dev(dev); > struct i801_priv *priv = pci_get_drvdata(pci_dev); -- Jean Delvare SUSE L3 Support

[PATCH] swiotlb: Silent unwanted warning "buffer is full"

2018-05-03 Thread Jean Delvare
/show_bug.cgi?id=104082 Signed-off-by: Jean Delvare <jdelv...@suse.de> Fixes: 0176adb00406 ("swiotlb: refactor coherent buffer allocation") Cc: Christoph Hellwig <h...@lst.de> Cc: Christian König <christian.koe...@amd.com> Cc: Michel Dänzer <mic...@daenzer.net> Cc: Ta

[PATCH] swiotlb: Silent unwanted warning "buffer is full"

2018-05-03 Thread Jean Delvare
/show_bug.cgi?id=104082 Signed-off-by: Jean Delvare Fixes: 0176adb00406 ("swiotlb: refactor coherent buffer allocation") Cc: Christoph Hellwig Cc: Christian König Cc: Michel Dänzer Cc: Takashi Iwai Cc: sta...@vger.kernel.org # v4.16 --- lib/swiotlb.c |2 +- 1 file changed, 1 inser

Re: [PATCH] firmware: dmi: Add access to the SKU ID string

2018-04-27 Thread Jean Delvare
y I have moved product SKU before product family in all files, same order as in the DMI entry itself. -- Jean Delvare SUSE L3 Support

Re: [PATCH] firmware: dmi: Add access to the SKU ID string

2018-04-27 Thread Jean Delvare
U before product family in all files, same order as in the DMI entry itself. -- Jean Delvare SUSE L3 Support

Re: [PATCH] firmware: dmi: Add access to the SKU ID string

2018-04-26 Thread Jean Delvare
r DMI, quick grep told me you should add to > Documentation/ABI/testing/sysfs-firmware-dmi-tables No. This is a different interface to user-space (binary tables, instead of already decoded, selected attributes.) There is currently no formal documentation of the /sys/devices/virtual/dmi/id contents, so there's no file Simon can modify to mention product_sku. Instead, documentation of the whole directory should be added in a separate patch. -- Jean Delvare SUSE L3 Support

Re: [PATCH] firmware: dmi: Add access to the SKU ID string

2018-04-26 Thread Jean Delvare
u should add to > Documentation/ABI/testing/sysfs-firmware-dmi-tables No. This is a different interface to user-space (binary tables, instead of already decoded, selected attributes.) There is currently no formal documentation of the /sys/devices/virtual/dmi/id contents, so there's no file Simon can modify to mention product_sku. Instead, documentation of the whole directory should be added in a separate patch. -- Jean Delvare SUSE L3 Support

Re: [PATCH] Documentation/i2c: direct users to i2c-tools regarding i2c/smbus.h

2018-04-25 Thread Jean Delvare
age (libi2c or similar), and the header file in yet another package (libi2c-devel or similar.) Although the exact package names are distribution specific, it would be convenient to hint the reader at which packages he is supposed to install. You could also mention that the C program must be compiled with -li2c. > > Implementation details > == -- Jean Delvare SUSE L3 Support

Re: [PATCH] Documentation/i2c: direct users to i2c-tools regarding i2c/smbus.h

2018-04-25 Thread Jean Delvare
or similar), and the header file in yet another package (libi2c-devel or similar.) Although the exact package names are distribution specific, it would be convenient to hint the reader at which packages he is supposed to install. You could also mention that the C program must be compiled with -li2c. > > Implementation details > == -- Jean Delvare SUSE L3 Support

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

2018-04-13 Thread Jean Delvare
On Fri, 13 Apr 2018 09:02:03 -0700, Sam Hansen wrote: > On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare <jdelv...@suse.de> wrote: > > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: > >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: > >

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

2018-04-13 Thread Jean Delvare
On Fri, 13 Apr 2018 09:02:03 -0700, Sam Hansen wrote: > On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: > > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: > >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: > >> > - Not meant to be

[GIT PULL] dmi fixes for v4.17

2018-04-13 Thread Jean Delvare
(-) --- Alex Hung (1): firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matches Jean Delvare (2): firmware: dmi_scan: Fix UUID length safety check firmware: dmi_scan: Use lowercase letters for UUID Thanks, -- Jean Delvare SUSE L3 Support

[GIT PULL] dmi fixes for v4.17

2018-04-13 Thread Jean Delvare
(-) --- Alex Hung (1): firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matches Jean Delvare (2): firmware: dmi_scan: Fix UUID length safety check firmware: dmi_scan: Use lowercase letters for UUID Thanks, -- Jean Delvare SUSE L3 Support

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

2018-04-13 Thread Jean Delvare
a comment on this? Fixing the documentation is always welcome, thanks Sam for stepping in. However we really want separate patches for whitespace fixes and actual contents change, as Wolfram already mentioned above. -- Jean Delvare SUSE L3 Support

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

2018-04-13 Thread Jean Delvare
a comment on this? Fixing the documentation is always welcome, thanks Sam for stepping in. However we really want separate patches for whitespace fixes and actual contents change, as Wolfram already mentioned above. -- Jean Delvare SUSE L3 Support

Re: [PATCH v3] i2c: i801: blacklist Host Notify on HP EliteBook G3 850

2018-04-10 Thread Jean Delvare
so based on DMI information. > > More information can be found here: > https://www.spinics.net/lists/linux-i2c/msg33938.html > > Signed-off-by: Jason Andryuk <jandr...@gmail.com> > Reviewed-by: Jean Delvare <jdelv...@suse.de> > Cc: sta...@vger.kernel.org > ---

Re: [PATCH v3] i2c: i801: blacklist Host Notify on HP EliteBook G3 850

2018-04-10 Thread Jean Delvare
so based on DMI information. > > More information can be found here: > https://www.spinics.net/lists/linux-i2c/msg33938.html > > Signed-off-by: Jason Andryuk > Reviewed-by: Jean Delvare > Cc: sta...@vger.kernel.org > --- > v3: Switch to DMI_EXACT_MATCH and add empty ele

[PATCH] firmware: dmi_scan: Fix UUID length safety check

2018-04-09 Thread Jean Delvare
length 8, 25 or 27 bytes, in line with the SMBIOS specifications. But let's fix it still. Signed-off-by: Jean Delvare <jdelv...@suse.de> Fixes: a814c3597a6b ("firmware: dmi_scan: Check DMI structure length") Cc: Mika Westerberg <mika.westerb...@linux.intel.com> --- drive

[PATCH] firmware: dmi_scan: Fix UUID length safety check

2018-04-09 Thread Jean Delvare
length 8, 25 or 27 bytes, in line with the SMBIOS specifications. But let's fix it still. Signed-off-by: Jean Delvare Fixes: a814c3597a6b ("firmware: dmi_scan: Check DMI structure length") Cc: Mika Westerberg --- drivers/firmware/dmi_scan.c |2 +- 1 file changed, 1 insertion(+),

Re: [PATCH AUTOSEL for 4.15 142/189] firmware: dmi_scan: Fix handling of empty DMI strings

2018-04-09 Thread Jean Delvare
Hi Parag, On Sun, 8 Apr 2018 21:21:19 -0400, Parag Warudkar wrote: > On Sun, Apr 8, 2018 at 8:18 PM, Sasha Levin <alexander.le...@microsoft.com> > wrote: > > > From: Jean Delvare <jdelv...@suse.de> > > > > [ Upstream commit a7770ae194569e96a

Re: [PATCH AUTOSEL for 4.15 142/189] firmware: dmi_scan: Fix handling of empty DMI strings

2018-04-09 Thread Jean Delvare
Hi Parag, On Sun, 8 Apr 2018 21:21:19 -0400, Parag Warudkar wrote: > On Sun, Apr 8, 2018 at 8:18 PM, Sasha Levin > wrote: > > > From: Jean Delvare > > > > [ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ] > > > > [snip] > > >

Re: [PATCH AUTOSEL for 4.9 078/293] firmware: dmi_scan: Check DMI structure length

2018-04-09 Thread Jean Delvare
On Mon, 9 Apr 2018 00:23:55 +, Sasha Levin wrote: > From: Jean Delvare <jdelv...@suse.de> > > [ Upstream commit a814c3597a6b6040e2ef9459748081a6d5b7312d ] > > Before accessing DMI data to record it for later, we should ensure > that the DMI structures are large en

Re: [PATCH AUTOSEL for 4.9 078/293] firmware: dmi_scan: Check DMI structure length

2018-04-09 Thread Jean Delvare
On Mon, 9 Apr 2018 00:23:55 +, Sasha Levin wrote: > From: Jean Delvare > > [ Upstream commit a814c3597a6b6040e2ef9459748081a6d5b7312d ] > > Before accessing DMI data to record it for later, we should ensure > that the DMI structures are large enough to contain the

[PATCH] firmware: dmi_scan: Use lowercase letters for UUID

2018-04-08 Thread Jean Delvare
RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this recommendation. Suggested by Paul Dagnelie at: https://savannah.nongnu.org/bugs/index.php?53569 Signed-off-by: Jean Delvare <jdelv...@suse.de> --- drivers/firmware/dmi_scan.c |4 ++-- 1 file changed, 2 insertions

[PATCH] firmware: dmi_scan: Use lowercase letters for UUID

2018-04-08 Thread Jean Delvare
RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this recommendation. Suggested by Paul Dagnelie at: https://savannah.nongnu.org/bugs/index.php?53569 Signed-off-by: Jean Delvare --- drivers/firmware/dmi_scan.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux

Re: [PATCH v2] i2c: i801: blacklist Host Notify on HP EliteBook G3 850

2018-04-04 Thread Jean Delvare
atic int i801_probe(struct pci_dev *dev, const struct > pci_device_id *id) > i801_feature_names[i]); > } > priv->features &= ~disable_features; > + blacklist_features(priv); > > err = pcim_enable_device(dev); > if (err) { Other than that, it looks good to me. Reviewed-by: Jean Delvare <jdelv...@suse.de> -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: blacklist Host Notify on HP EliteBook G3 850

2018-04-04 Thread Jean Delvare
truct pci_dev *dev, const struct > pci_device_id *id) > i801_feature_names[i]); > } > priv->features &= ~disable_features; > + blacklist_features(priv); > > err = pcim_enable_device(dev); > if (err) { Other than that, it looks good to me. Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: blacklist Host Notify on HP EliteBook G3 850

2018-04-04 Thread Jean Delvare
> > Otherwise, unfortunately, it might just be a different issue. I recall reports about hangs when we first added support for interrupts. I think we addressed all the bugs in this area since then but maybe not. So you may want to try disable_features=0x30 to disable both interrupts and SMBus Host Notify. -- Jean Delvare SUSE L3 Support

Re: [PATCH v2] i2c: i801: blacklist Host Notify on HP EliteBook G3 850

2018-04-04 Thread Jean Delvare
unately, it might just be a different issue. I recall reports about hangs when we first added support for interrupts. I think we addressed all the bugs in this area since then but maybe not. So you may want to try disable_features=0x30 to disable both interrupts and SMBus Host Notify. -- Jean Delvare SUSE L3 Support

Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

2018-03-10 Thread Jean Delvare
On Fri, 9 Mar 2018 10:56:07 -0800, Alex Hung wrote: > On Fri, Mar 9, 2018 at 5:33 AM, Jean Delvare <jdelv...@suse.de> wrote: > > However it doesn't make sense to commit this change unless there will > > be at least one user of it. What is the status of the piece of code &

Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

2018-03-10 Thread Jean Delvare
On Fri, 9 Mar 2018 10:56:07 -0800, Alex Hung wrote: > On Fri, Mar 9, 2018 at 5:33 AM, Jean Delvare wrote: > > However it doesn't make sense to commit this change unless there will > > be at least one user of it. What is the status of the piece of code > > which was sup

Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

2018-03-09 Thread Jean Delvare
de/linux/mod_devicetable.h > @@ -502,6 +502,7 @@ enum dmi_field { > DMI_CHASSIS_SERIAL, > DMI_CHASSIS_ASSET_TAG, > DMI_STRING_MAX, > + DMI_OEM_STRING, /* special case - will not be in dmi_ident */ > }; > > struct dmi_strmatch { Other than this, I'm happy with this

Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

2018-03-09 Thread Jean Delvare
7 @@ enum dmi_field { > DMI_CHASSIS_SERIAL, > DMI_CHASSIS_ASSET_TAG, > DMI_STRING_MAX, > + DMI_OEM_STRING, /* special case - will not be in dmi_ident */ > }; > > struct dmi_strmatch { Other than this, I'm happy with this version, so with the b

Re: [PATCH v2 1/2] i2c: piix4: Use usleep_range()

2018-03-01 Thread Jean Delvare
se > - msleep(1); > + usleep_range(250, 500); > > while ((++timeout < MAX_TIMEOUT) && > ((temp = inb_p(SMBHSTSTS)) & 0x01)) > - msleep(1); > + usleep_range(250, 500); > > /* If the SMB

Re: [PATCH v2 1/2] i2c: piix4: Use usleep_range()

2018-03-01 Thread Jean Delvare
msleep(1); > + usleep_range(250, 500); > > while ((++timeout < MAX_TIMEOUT) && > ((temp = inb_p(SMBHSTSTS)) & 0x01)) > - msleep(1); > + usleep_range(250, 500); > > /* If the SMBus is still busy, we give up */ > if (timeout == MAX_TIMEOUT) { Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

2018-03-01 Thread Jean Delvare
if (retval < 0) > @@ -983,11 +981,8 @@ static void piix4_adap_remove(struct i2c_adapter *adap) > > if (adapdata->smba) { > i2c_del_adapter(adap); > - if (adapdata->port == (0 << piix4_port_shift_sb800)) { > + if (adapdata->port == (0 << piix4_port_shift_sb800)) > release_region(adapdata->smba, SMBIOSIZE); > - if (adapdata->sb800_main) > - release_region(SB800_PIIX4_SMB_IDX, 2); > - } > kfree(adapdata); > kfree(adap); > } Reviewed-by: Jean Delvare <jdelv...@suse.de> -- Jean Delvare SUSE L3 Support

Re: [PATCH v2 2/2] i2c: piix4: Use request_muxed_region

2018-03-01 Thread Jean Delvare
t; - if (retval < 0) { > - release_region(SB800_PIIX4_SMB_IDX, 2); > + if (retval < 0) > return retval; > - } > } else { > retval = piix4_setup(dev, id); > if (retval < 0) >

Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper

2018-02-28 Thread Jean Delvare
t the driver level shouldn't be based on what older systems are most likely to enjoy. The default behavior must be the safest option, regardless of the age of the system. -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper

2018-02-28 Thread Jean Delvare
t older systems are most likely to enjoy. The default behavior must be the safest option, regardless of the age of the system. -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 1/4] dmi: Introduce dmi_get_bios_year() helper

2018-02-27 Thread Jean Delvare
gree. Just because it is an inline function in a header file doesn't mean we don't stick to the usual coding style policy. > + > #endif /* __DMI_H__ */ -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 1/4] dmi: Introduce dmi_get_bios_year() helper

2018-02-27 Thread Jean Delvare
n a header file doesn't mean we don't stick to the usual coding style policy. > + > #endif /* __DMI_H__ */ -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 4/4] pci: Re-use new dmi_get_bios_year() helper

2018-02-26 Thread Jean Delvare
* to D3. >*/ > - if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && > - year >= 2015) { > + if (dmi_get_bios_year() >= 2015) > return true; > - } > break; > } > Reviewed-by: Jean Delvare <jdelv...@suse.de> -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 4/4] pci: Re-use new dmi_get_bios_year() helper

2018-02-26 Thread Jean Delvare
*/ > - if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && > - year >= 2015) { > + if (dmi_get_bios_year() >= 2015) > return true; > - } > break; > } > Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 3/4] ACPI / sleep: Re-use new dmi_get_bios_year() helper

2018-02-26 Thread Jean Delvare
acpi_sleep_dmi_check(void) > { > - int year; > - > if (ignore_blacklist) > return; > > - if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && year >= 2012) > + if (dmi_get_bios_year() >= 2012) > acpi_nvs_nosave_s3(); > > dmi_che

Re: [PATCH v1 3/4] ACPI / sleep: Re-use new dmi_get_bios_year() helper

2018-02-26 Thread Jean Delvare
gt; if (ignore_blacklist) > return; > > - if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && year >= 2012) > + if (dmi_get_bios_year() >= 2012) > acpi_nvs_nosave_s3(); > > dmi_check_system(acpisleep_dmi_table); Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support

Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper

2018-02-26 Thread Jean Delvare
; > > if (!strncmp(mcfg->header.oem_id, "SGI", 3)) > return 0; > > - if (mcfg->header.revision >= 1) { > - if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && > - year >= 2010) > -

Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper

2018-02-26 Thread Jean Delvare
fg->header.oem_id, "SGI", 3)) > return 0; > > - if (mcfg->header.revision >= 1) { > - if (dmi_get_date(DMI_BIOS_DATE, , NULL, NULL) && > - year >= 2010) > - return 0; > - } > + if ((mcfg->header.revision >= 1) && (dmi_get_bios_year() >= 2010)) > + return 0; Here too some parentheses are not needed. > > pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx " > "is above 4GB, ignored\n", cfg->pci_segment, -- Jean Delvare SUSE L3 Support

Re: [PATCH] eeprom: New ee1004 driver for DDR4 memory

2018-02-26 Thread Jean Delvare
Hi Bartosz, On Mon, 26 Feb 2018 14:40:42 +0100, Bartosz Golaszewski wrote: > 2018-02-26 10:20 GMT+01:00 Jean Delvare <jdelv...@suse.de>: > > The EEPROMs which hold the SPD data on DDR4 memory modules are no > > longer standard AT24C02-compatible EEPROMs. They are 512-byte

<    1   2   3   4   5   6   7   8   9   10   >