,
> const char *flavour)
> if (card->long_name)
> return 0; /* long name already set by driver or from DMI */
>
> - if (!is_acpi_device_node(card->dev->fwnode))
> + if (!dmi_available)
> return 0;
>
> /* make up dmi long name as: vendor-product-version-board */
Fine with me.
Acked-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
ed-off-by: Andy Shevchenko
> ---
> drivers/pci/probe.c | 12 +++-
> include/linux/pci.h | 9 +
> 2 files changed, 12 insertions(+), 9 deletions(-)
> (...)
Nice.
Reviewed-by: Jean Delvare
(If you introduced a _debug flavor of that, it could probably be used in
dr
CI_DEVFN(31, 1)),
> + X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE,PCI_DEVFN(31, 1)),
> + X86_MATCH_INTEL_FAM6_MODEL(KABYLAKE_L, PCI_DEVFN(31, 1)),
> + X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE, PCI_DEVFN(31, 1)),
> + X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_L, PCI_DEVFN(31, 1)),
> {}
> };
>
Any reason why this is added in this patch instead of [3/7] (PCI: New
Primary to Sideband (P2SB) bridge support library)?
--
Jean Delvare
SUSE L3 Support
the SIS630. DANGEROUS!");
>
> -/* SMBus base adress */
> +/* SMBus base address */
> static unsigned short smbus_base;
>
> /* supported chips */
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
enable the SIS630. DANGEROUS!");
>
> -/* SMBus base adress */
> +/* SMBus base address */
> static unsigned short smbus_base;
>
> /* supported chips */
I pointed out 4 issues in your original patch, you fixed only one and
resubmitted with 3 issues remaining. I give up. Pa
+97,7 @@
> module_param(force, bool, 0);
> MODULE_PARM_DESC(force, "Forcibly enable the SIS630. DANGEROUS!");
>
> -/* SMBus base adress */
> +/* SMBus base address */
> static unsigned short smbus_base;
>
> /* supported chips */
Other than that, the change looks OK, thanks.
--
Jean Delvare
SUSE L3 Support
for printk.
> >
> > Signed-off-by: Tom Rix
>
> Adding Jean to CC. Jean, I'd think %02x would be better, what do you
> think?
Agreed, 0x%02x would be better.
If this is done then you can add:
Reviewed-by: Jean Delvare
> > ---
> > drivers/i2c/i2c-sm
On Thu, 29 Oct 2020 07:55:25 -0700, Joe Perches wrote:
> On Thu, 2020-10-29 at 14:32 +0100, Jean Delvare wrote:
> > WARNING: Possible repeated word: 'git'
> > #20: FILE: MAINTAINERS:5289:
> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.
way to list a git tree in that file. Could you please add an exception
for that case?
Thanks,
--
Jean Delvare
SUSE L3 Support
tches.rst
Specifically, when submitting a new version of a patch, please:
* Replace [PATCH] with [PATCH v2] in the subject.
* Do not reply to the previous version of the patch, instead start a
new thread.
* Ideally, include a list of changes from previous version, between the
"---" marker and the diffstat.
Thanks,
--
Jean Delvare
SUSE L3 Support
I switched from quilt to git as requested by Stephen Rothwell. Update
the link to the new place.
Signed-off-by: Jean Delvare
Cc: Stephen Rothwell
---
MAINTAINERS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-5.10-rc1.orig/MAINTAINERS 2020-10-25 23:14:11.0
h would make the patch more readable too.
So please go with either "sku" (my preference) or "psk".
Thanks,
--
Jean Delvare
SUSE L3 Support
better utilization.
Do you have an actual use case for this already, or is it a theoretical
concern?
--
Jean Delvare
SUSE L3 Support
HTTP links with HTTPS ones: DMI/SMBIOS SUPPORT
Thanks,
--
Jean Delvare
SUSE L3 Support
gt; * Additional individual entries were added after verification.
> > */
> > + { "Latitude 5480", 0x29 },
> > { "Vostro V131",0x1d },
> > };
> >
No actual code change and not something I can test, so pretty much any
kernel develop
roject/linux-i2c/patch/a2fc5a6d-a3bf-eaf0-bb75-1521be346...@googlemail.com/
should fix it. I was supposed to review it but did not, shame on me.
I'll do it today.
--
Jean Delvare
SUSE L3 Support
On Wed, 5 Aug 2020 16:36:55 +0200, Jean Delvare wrote:
> 1* Do we actually need to use a struct resource? With the current
>requirements, that looks overkill to me. We really only need the
>start and end offsets of the masked area (or start and length). Or
>do you plan to
On Wed, 5 Aug 2020 20:14:28 +0200, Bartosz Golaszewski wrote:
> On Wed, Aug 5, 2020 at 4:36 PM Jean Delvare wrote:
> > I finally found the time to give it a try. Here's what my (tested)
> > prototype looks like:
>
> Hi Jean,
>
> this looks good at first glance.
>
Hi Bartosz,
On Tue, 17 Mar 2020 15:32:56 +0100, Bartosz Golaszewski wrote:
> wt., 17 mar 2020 o 15:14 Jean Delvare napisał(a):
> > Before I start implementing the idea above, I would like to know if
> > anyone objects to it, or has a better idea?
>
> Sounds good to me
everybody agrees that's the way to go. I'm not deeply familiar with the
at24 driver so I'm not sure how to do it, but hopefully it will get
clearer as I progress.
--
Jean Delvare
SUSE L3 Support
I understand this is beyond the scope of your current project. Do you
want me to take care of that?
--
Jean Delvare
SUSE L3 Support
s32 vt596_access(struct i2c_adapter *adap, u16
> addr,
> goto exit_unsupported;
> if (read_write == I2C_SMBUS_READ)
> outb_p(data->block[0], SMBHSTDAT0);
> - /* Fall through */
> + fallthrough;
> case I2C
0)
> + if (pci_write_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, val
> | 0x80))
> goto error;
> - if (pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, )
> - != 0)
> + if (pci_read_config_byte(SIS5595_dev, SIS5595_ENABLE_R
error;
> if ((val & 0x80) == 0) {
> dev_info(_dev->dev, "enabling ACPI\n");
> if (pci_write_config_byte(SIS5595_dev, SIS5595_ENABLE_REG, val
> | 0x80)
> - != PCIBIOS_SUCCESSFUL)
> + != 0)
>
Hi Stephen,
On Wed, 15 Jul 2020 11:37:43 +0200, Jean Delvare wrote:
> On Mon, 13 Jul 2020 09:11:02 +1000, Stephen Rothwell wrote:
> > Jean, I don't suppose you would like to produce a git tree for me to
> > fetch instead, as yours is the last quilt series I fetch (apart from
>
yours is the last quilt series I fetch (apart from
> Andrew's which is special).
Actually, feel free to suppose. While a quilt tree fits my current
workflow better, I don't want to be the guy who makes your life more
difficult. Let me give it a try.
--
Jean Delvare
SUSE L3 Support
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov
> ---
> (...)
> If you apply the patch, please let me know.
>
>
> drivers/firmware/dmi_scan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> (...)
Applied, thanks.
--
Jean Delvare
SUSE L3 Support
Kconfig claims that the ixp4xx-qmgr and ixp4xx-npe helper drivers
are selected automatically as needed. However this is not what the
Kconfig entries are doing. Convert depends to select to match the
help texts.
Signed-off-by: Jean Delvare
Cc: Krzysztof Halasa
---
drivers/crypto/Kconfig
-by: Jean Delvare
Cc: Krzysztof Halasa
---
MAINTAINERS |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- linux-5.7.orig/MAINTAINERS 2020-06-23 13:03:34.728650310 +0200
+++ linux-5.7/MAINTAINERS 2020-06-23 13:04:14.045055597 +0200
@@ -8654,10 +8654,8 @@ M: Krzysztof Halasa
| 2 ++
scripts/mod/file2alias.c| 2 ++
4 files changed, 40 insertions(+)
---
Erwan Velu (1):
firmware/dmi: Report DMI Bios & EC firmware release
Thanks,
--
Jean Delvare
SUSE L3 Support
te, so it was not
accepted. Your patch is still in my pending queue:
http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/
and therefore included in every linux-next snapshot, but it won't be
merged in v5.7, you'll have to wait for v5.8.
This is entirely my fault and I am sorry about that.
--
Jean Delvare
S
l on your patch before you
resubmit, and address all the problems reported.
Thanks,
--
Jean Delvare
SUSE L3 Support
nt from each other anyway. I'd rather have one
field with the values combined:
[root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release
65.27
[root@t1700 ~]#
This would also be in line with how it was implemented in dmidecode. Is
there any reason to NOT go that route?
--
Jean Delvare
SUSE L3 Support
eturn;
> +
> + sprintf(s, "%u", d[0]);
> +
> + dmi_ident[slot] = s;
> +}
> +
> static void __init dmi_save_uuid(const struct dmi_header *dm, int slot,
> int index)
> {
--
Jean Delvare
SUSE L3 Support
Hi Linus,
Please pull dmi subsystem fixes for Linux v5.4 from:
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git dmi-for-linus
drivers/firmware/dmi_scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
Jean Delvare (1):
firmware: dmi: Fix
rop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Jean-Delvare/Instantiate-SPD-EEPROMs-at-boo
rop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Jean-Delvare/Instantiate-SPD-EEPROMs-
Call the function to instantiate SPD EEPROMs automatically on the
main SMBus controller.
Multiplexed SMBus systems are excluded for now as they are more
complex to handle.
Signed-off-by: Jean Delvare
---
drivers/i2c/busses/i2c-i801.c |4
1 file changed, 4 insertions(+)
--- linux-5.3
In simple cases we can instantiate SPD EEPROMs on the SMBus
automatically. Start with just DDR2, DDR3 and DDR4 on x86 for now,
and only for systems with no more than 4 memory slots. These
limitations may be lifted later.
Signed-off-by: Jean Delvare
---
drivers/i2c/i2c-smbus.c | 104
Add a utility function dmi_memdev_handle() which returns the DMI
handle associated with a given memory slot. This will allow kernel
drivers to iterate over the memory slots.
Signed-off-by: Jean Delvare
---
drivers/firmware/dmi_scan.c | 16
include/linux/dmi.h |2
Store the memory type while walking the memory slots, and provide a
way to retrieve it later.
Signed-off-by: Jean Delvare
---
drivers/firmware/dmi_scan.c | 25 -
include/linux/dmi.h |2 ++
2 files changed, 26 insertions(+), 1 deletion(-)
--- linux-5.3.orig
: Instantiate SPD EEPROMs automatically
--
Jean Delvare
SUSE L3 Support
Before reading the Extended Size field, we should ensure it fits in
the DMI record. There is already a record length check but it does
not cover that field.
It would take a seriously corrupted DMI table to hit that bug, so no
need to worry, but we should still fix it.
Signed-off-by: Jean Delvare
Deprecating the driver in Kconfig is one thing, but we also need to
let the users themselves know. Log a warning each time a device is
bound to the deprecated eeprom driver.
Signed-off-by: Jean Delvare
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/eeprom/eeprom.c |4
1
Hi Greg,
On Fri, 6 Sep 2019 14:15:10 +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2019 at 01:02:21PM +0200, Jean Delvare wrote:
> > I've been bitten recently by mcelog not working on machines started in
> > secure boot mode. mcelog tries to read DMI information from /dev/me
D'oh, I hit reply while still editing... Sorry for the noise, a better
answer will come later when ready.
--
Jean Delvare
SUSE L3 Support
On Fri, 6 Sep 2019 14:15:10 +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2019 at 01:02:21PM +0200, Jean Delvare wrote:
> > I've been bitten recently by mcelog not working on machines started in
> > secure boot mode. mcelog tries to read DMI information from /dev/mem
> &
Hi Greg,
On Wed, 4 Sep 2019 09:57:29 +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 02, 2019 at 10:48:38AM +0200, Jean Delvare wrote:
> > Time has come to get rid of the old eeprom driver. The at24 driver
> > should be used instead. So mark the eeprom driver as deprecated and
>
creating these device nodes at all in the first place? Can't we detect
that we are in secure boot mode and skip that step, and reap the rewards
(faster boot, lower memory footprint and less confusion)?
Thanks,
--
Jean Delvare
SUSE L3 Support
write_config_byte(dev, SMBHSTCFG, priv->original_hstcfg);
@@ -1916,7 +1977,7 @@ static void i801_shutdown(struct pci_dev
struct i801_priv *priv = pci_get_drvdata(dev);
/* Restore config registers to avoid hard hang on some systems */
- i801_disable_host_notify(priv);
+ i801_restore_slvcmd(priv);
pci_write_config_byte(dev, SMBHSTCFG, priv->original_hstcfg);
}
--
Jean Delvare
SUSE L3 Support
Time has come to get rid of the old eeprom driver. The at24 driver
should be used instead. So mark the eeprom driver as deprecated and
give users some time to migrate. Then we can remove the legacy
eeprom driver completely.
Signed-off-by: Jean Delvare
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
eady there as we added support in a
few I2C bus drivers already. So maybe instead of silencing the
interrupts, we could add proper SMBus Alert support to the i2c-i801
driver?
Did you figure out which device is raising the SMBus Alert and why?
--
Jean Delvare
SUSE L3 Support
Hi Enrico,
On Thu, 8 Aug 2019 11:17:53 +0200, Enrico Weigelt, metux IT consult wrote:
> On 02.08.19 14:51, Jean Delvare wrote:
> > These patches fix a couple of issues with the i2c-piix4 driver on
> > AMD Family 16h Model 30h SoCs and add ACPI-based enumeration to the
>
-3Fh
Based on earlier work by Andrew Cooks.
Reported-by: Andrew Cooks
Signed-off-by: Jean Delvare
---
Changes since v4:
* Fix subject line
* Drop local variable port_count, use piix4_adapter_count
everywhere to represent the maximum number of main SMBus ports
* Exclude early Hudson2
ve to
pass an extra parameter to piix4_add_adapter().
[1] 52740 BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h
Models 30h-3Fh Processors
Based on earlier work by Andrew Cooks.
Reported-by: Andrew Cooks
Signed-off-by: Jean Delvare
---
Changes since v4:
* Fix code alignment (reported
ly 15h Model 10h-1Fh doesn't mention any
49125 - Family 15h Model 30h-3Fh doesn't mention any
48751 - Family 16h Model 00h-0Fh uses the previously supported
index register SB800_PIIX4_PORT_IDX_ALT at 0x2e
Signed-off-by: Andrew Cooks
Signed-off-by: Jean Delvare
Cc: sta...@vger.kernel.org
determining port selection register
v2:
count the adapters, instead of misusing port numbers
--
Jean Delvare
SUSE L3 Support
but was just a performance optimization.
I am available to do any amount of tests or debugging, given the
guidance.
Thanks,
--
Jean Delvare
SUSE L3 Support
The compatibility "eeprom" attribute is currently root-only no
matter what the configuration says. The "nvmem" attribute does
respect the setting of the root_only configuration bit, so do the
same for "eeprom".
Signed-off-by: Jean Delvare
Fixes: b6c217ab9be6 ("
The integration of the at24 driver into the nvmem framework broke the
world-readability of spd EEPROMs. Fix it.
Signed-off-by: Jean Delvare
Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM
framework")
Cc: Andrew Lunn
Cc: Srinivas Kandagatla
Cc: Greg Kroah-H
that ACPI
developers will use the AMD documentation ordering, so we have to
pass an extra parameter to piix4_add_adapter().
[1] 52740 BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h
Models 30h-3Fh Processors
Signed-off-by: Jean Delvare
---
drivers/i2c/busses/i2c-piix
if nothing else. This
probably means passing one more parameter to piix4_add_adapter() and/or
some more code to figure out the bus number to pass to
acpi_preset_companion(), but I don't think we can avoid that, so let's
just do it.
> + }
> +
> snprintf(adap->name, sizeof(adap->name),
> "SMBus PIIX4 adapter%s at %04x", name, smba);
>
--
Jean Delvare
SUSE L3 Support
e:
if (PIIX4_dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS ||
(PIIX4_dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS &&
PIIX4_dev->revision >= 0x1F)) {
piix4_adapter_count = HUDSON2_MAIN_PORTS;
} else {
(...)
i.e. the same as in previous patch.
By the way, I don't own compatible hardware. I will see if I can gain
access to a SUSE Labs machine for testing purposes, but it would be a
lot easier if someone with the hardware could test the patch series
once it is rebased. Volunteers?
Thanks,
--
Jean Delvare
SUSE L3 Support
On Wed, 24 Jul 2019 10:37:48 +0200, Jean Delvare wrote:
> Hi Andrew,
>
> Sorry for the delay... What can I say :(
Unfortunately by now Andrew is gone. So I will be the one rebasing and
resubmitting this series.
--
Jean Delvare
SUSE L3 Support
++---
> 1 file changed, 5 insertions(+), 7 deletions(-)
> (...)
Looks good to me. Unfortunately the patch no longer applies (my fault
obviously), it needs to be rebased on top of commit
24beb83ad289c68bce7c01351cb90465bbb1940a ("i2c-piix4: Add Hygon Dhyana
SMBus support").
I als
01.c | 3 +--
> 2 files changed, 3 insertions(+), 6 deletions(-)
> (...)
Looks good to me, thanks.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
config IXP4XX_NPE
- tristate "IXP4xx Network Processor Engine support"
+ tristate
select FW_LOADER
help
This driver supports IXP4xx built-in network coprocessors
and is automatically selected by Ethernet and HSS drivers.
endmenu
+endif
--
Jean Delvare
SUSE L3 Support
Kconfig claims that the ixp4xx-qmgr and ixp4xx-npe helper drivers
are selected automatically as needed. However this is not what the
Kconfig entries are doing. Convert depends to select to match the
help texts.
Signed-off-by: Jean Delvare
Cc: Krzysztof Halasa
---
Sorry about the weird patch
-by: Jean Delvare
Cc: Krzysztof Halasa
---
MAINTAINERS |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- linux-5.2.orig/MAINTAINERS 2019-07-12 15:33:28.106852821 +0200
+++ linux-5.2/MAINTAINERS 2019-07-12 15:35:54.309067537 +0200
@@ -8023,10 +8023,8 @@ F: Documentation
The i2c-dev module is for access to I2C buses from user-space.
Kernel drivers do not care about its presence.
Signed-off-by: Jean Delvare
Cc: Matt Sickler
Cc: Greg Kroah-Hartman
---
drivers/staging/kpc2000/kpc_i2c/i2c_driver.c |1 -
1 file changed, 1 deletion(-)
--- linux-5.2-rc7.orig
gt;
> Signed-off-by: Pali Rohár
>
> ---
> Changes since v4:
> * Remove usage of redundant acpi_bus_get_status_handle()
> * Update comment about acpi_get_devices()
> (...)
Looks all good now.
Reviewed-by: Jean Delvare
Thanks!
--
Jean Delvare
SUSE L3 Support
On Thu, 6 Jun 2019 17:48:00 +0200, Pali Rohár wrote:
> On Thursday 06 June 2019 16:53:09 Jean Delvare wrote:
> > This is testing that *either* bit is set. Is it what you intend to
> > achieve, or would you rather want to ensure that *all* these bits are
> > set?
>
e;
> +
> + /*
> + * Check that ACPI device SMO88xx exists and is enabled. That ACPI
> + * device represent our ST microelectronics lis3lv02d accelerometer but
> + * unfortunately without any other information (like I2C address).
> + */
> + found = false;
> + acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> + (void **));
Alignment is incorrect now - but don't resend just for this.
> +
> + return found;
> +}
> (...)
Everything else looks good to me now. Has the latest version of your
patch been tested on real hardware?
--
Jean Delvare
SUSE L3 Support
t; +{
> + struct i2c_board_info info;
> + const char *dmi_product_name;
> + int i;
> +
> + dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> + for (i = 0; i < ARRAY_SIZE(dell_lis3lv02d_devices); ++i) {
> + if (strcmp(dmi_product_name,
On Tue, 28 May 2019 11:54:02 +0200, Pali Rohár wrote:
> On Tuesday 28 May 2019 11:50:15 Jean Delvare wrote:
> > OK, thanks for the explanation. But assuming that we now instantiate
> > the lis2lv02d device from i2c-i801 for exactly all the same machines,
> > can't we just
nes,
can't we just *enable* the freefall misc device feature of lis2lv02d
and kill the dell-smo8800 driver completely? Seems more simple to
maintain going forward.
--
Jean Delvare
SUSE L3 Support
On Mon, 26 Feb 2018 21:32:55 +0100, Wolfram Sang wrote:
> > I'm not maintainer of i2c-i801.ko, Jean Delvare & Wolfram Sang are.
> > Therefore instructing future contributors would be up to them.
>
> This is really Jean's realm.
Sorry for the delay. As a general
On Fri, 10 May 2019 17:35:46 +0800, Kefeng Wang wrote:
> On 2019/5/10 16:09, Jean Delvare wrote:
> > We don't need this anyway. The comment says it can't fail, so why
> > bother checking for a condition which will never happen?
>
> The ioremap could fails due to no memory,
Hi Kefeng,
On Fri, 10 May 2019 11:03:20 +0800, Kefeng Wang wrote:
> If ioremap fails, NULL pointer dereference will happen and
> leading to a kernel panic when access the virtual address
> in check_signature().
>
> Fix it by check the return value of ioremap.
>
> Cc: Jean D
config
> @@ -435,7 +435,7 @@ config I2C_AXXIA
>
> config I2C_BCM2835
> tristate "Broadcom BCM2835 I2C controller"
> - depends on ARCH_BCM2835
> + depends on ARCH_BCM2835 || ARCH_BRCMSTB
> help
> If you say yes to this option, support will b
On Mon, 6 May 2019 17:03:20 +0300, Jarkko Nikula wrote:
> On 5/6/19 4:16 PM, Jean Delvare wrote:
> > Some EE1004 implementations will not properly ack page selection
> > commands. They still set the page correctly, so there is no actual
> > error. Deal with this case g
-by: Jean Delvare
Tested-by: Jarkko Nikula
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/eeprom/ee1004.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- linux-5.0.orig/drivers/misc/eeprom/ee1004.c 2019-05-06 11:57:14.333572368
+0200
+++ linux-5.0/drivers/misc
No functional change, this is in preparation for future needs.
Signed-off-by: Jean Delvare
Tested-by: Jarkko Nikula
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/eeprom/ee1004.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
--- linux
2c/busses/i2c-piix4 | 2 ++
> drivers/i2c/busses/Kconfig | 1 +
> drivers/i2c/busses/i2c-piix4.c | 15 +++
> 3 files changed, 14 insertions(+), 4 deletions(-)
> (...)
Looks good to me now, thanks.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
e we do
> for others where the IRQ controller is still ready.
>
> So yes, that could work from me. Not sure what Wolfram and Jean would
> say though.
I would say OK with me, this looks like the cleanest solution to me, so
if testing is positive, let's go with it.
--
Jean Delvare
SUSE L3 Support
On Fri, 2019-04-26 at 22:23 +0800, Pu Wen wrote:
> On 2019/4/26 17:38, Jean Delvare wrote:
> > I would like you to also document the new supported chipset in
> > drivers/i2c/busses/Kconfig and Documentation/i2c/busses/i2c-piix4 as
> > well as in the header comment of i2c-p
_ID_AMD ||
> + dev->vendor == PCI_VENDOR_ID_HYGON) &&
> dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) {
> u8 imc;
>
Patch looks good. I assume you have tested it on real hardware?
I would like you to also document the new supported chipset in
drivers/i2c/busses/Kconfig and Documentation/i2c/busses/i2c-piix4 as
well as in the header comment of i2c-piix4.c itself. I know it seems
redundant but it helps the user know which driver they need.
Thanks,
--
Jean Delvare
SUSE L3 Support
ested-by: Jani Nikula
The line above appears to be truncated.
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/hwmon/index.rst | 316 +-
> 1 file changed, 158 insertions(+), 158 deletions(-)
--
Jean Delvare
SUSE L3 Support
orn Helgaas
>
> Added
>
> Fixes: fd46a0064af1 ("i2c: convert i2c-isch to platform_device")
> Reviewed-by: Jean Delvare
> Reviewed-by: Mukesh Ojha
>
> on my local branch.
>
> Jean, would you like me to repost this with the updates? I assume you
> w
rivers/i2c/busses/i2c-isch.c b/drivers/i2c/busses/i2c-isch.c
> index 5c754bf659e2..f64c1d72f73f 100644
> --- a/drivers/i2c/busses/i2c-isch.c
> +++ b/drivers/i2c/busses/i2c-isch.c
> @@ -30,7 +30,6 @@
> #include
> #include
> #include
> -#include
>
> /* SCH SMB
it is deemed not worth the maintenance effort then it should be
deleted. I don't care either way.
--
Jean Delvare
SUSE L3 Support
-EBUSY;
> @@ -528,7 +528,7 @@ static int sis630_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> sis630_adapter.dev.parent = >dev;
>
> snprintf(sis630_adapter.name, sizeof(sis630_adapter.name),
> - "SMBus SIS630 adapter at %04hx&
a different
pair of kernel versions. You cannot at the same time argue that the
change should not have been done back then, and ask for same change to
be done again now.
--
Jean Delvare
SUSE L3 Support
On Thu, 2018-12-06 at 10:22 +0100, Peter Korsgaard wrote:
> > > > > > "Jean" == Jean Delvare writes:
>
> > On Wed, 2018-12-05 at 22:13 +0100, Peter Korsgaard wrote:
> >> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7.
> >>
On Thu, 2018-12-06 at 10:22 +0100, Peter Korsgaard wrote:
> > > > > > "Jean" == Jean Delvare writes:
>
> > On Wed, 2018-12-05 at 22:13 +0100, Peter Korsgaard wrote:
> >> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7.
> >>
sprintf(s, "%pUl", d);
> + sprintf(s, "%pUL", d);
> else
> - sprintf(s, "%pUb", d);
> + sprintf(s, "%pUB", d);
>
> dmi_ident[slot] = s;
> }
Nak. This is too late. Changing it again would just add confusion.
--
Jean Delvare
SUSE L3 Support
sprintf(s, "%pUl", d);
> + sprintf(s, "%pUL", d);
> else
> - sprintf(s, "%pUb", d);
> + sprintf(s, "%pUB", d);
>
> dmi_ident[slot] = s;
> }
Nak. This is too late. Changing it again would just add confusion.
--
Jean Delvare
SUSE L3 Support
ed my lesson and I'll
> > put the
> > correct tags from now on :-)
>
> Ok, now dropped from 4.14, thanks.
Should be dropped from 4.9 and 4.4 too... if it was not clear.
Thanks,
--
Jean Delvare
SUSE L3 Support
ed my lesson and I'll
> > put the
> > correct tags from now on :-)
>
> Ok, now dropped from 4.14, thanks.
Should be dropped from 4.9 and 4.4 too... if it was not clear.
Thanks,
--
Jean Delvare
SUSE L3 Support
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
1 - 100 of 3166 matches
Mail list logo
