Hi Bartosz,
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 u
-by: Jean Delvare <jdelv...@suse.de>
---
drivers/misc/eeprom/Kconfig | 11 +
drivers/misc/eeprom/Makefile |1
drivers/misc/eeprom/ee1004.c | 281 +++
3 files changed, 293 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linu
-by: Jean Delvare
---
drivers/misc/eeprom/Kconfig | 11 +
drivers/misc/eeprom/Makefile |1
drivers/misc/eeprom/ee1004.c | 281 +++
3 files changed, 293 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-4.16-rc3/drivers/misc
On Mon, 12 Feb 2018 14:22:41 -0800, Guenter Roeck wrote:
> On Mon, Feb 12, 2018 at 11:53:36AM +0100, Jean Delvare wrote:
> > Were you able to test this on older hardware? Unfortunately, the
> > specification errata of the original Intel PIIX4 is quite vague on the
> > amount
On Mon, 12 Feb 2018 14:22:41 -0800, Guenter Roeck wrote:
> On Mon, Feb 12, 2018 at 11:53:36AM +0100, Jean Delvare wrote:
> > Were you able to test this on older hardware? Unfortunately, the
> > specification errata of the original Intel PIIX4 is quite vague on the
> > amount
On Mon, 12 Feb 2018 10:51:52 -0800, Guenter Roeck wrote:
> On Mon, Feb 12, 2018 at 11:10:41AM +0100, Jean Delvare wrote:
> > On Sat, 30 Dec 2017 08:50:57 -0800, Guenter Roeck wrote:
> > > @@ -298,12 +295,15 @@ static int piix4_setup_sb800(struct pci_dev
> > &g
On Mon, 12 Feb 2018 10:51:52 -0800, Guenter Roeck wrote:
> On Mon, Feb 12, 2018 at 11:10:41AM +0100, Jean Delvare wrote:
> > On Sat, 30 Dec 2017 08:50:57 -0800, Guenter Roeck wrote:
> > > @@ -298,12 +295,15 @@ static int piix4_setup_sb800(struct pci_dev
> > &g
ld wait for at least 501 ms for the transaction to complete. Now
this could be down to only 100 ms. That being said, if my math is
right, the longest supported transaction (Block Read) at the slowest
allowed SMBus clock speed (10 kHz) would be done in 33 ms, so we are
still good.
>
>
for the transaction to complete. Now
this could be down to only 100 ms. That being said, if my math is
right, the longest supported transaction (Block Read) at the slowest
allowed SMBus clock speed (10 kHz) would be done in 33 ms, so we are
still good.
>
> /* If the SMBus is st
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);
> }
Everything else looks good to me, thanks.
I assume you have tested this patch on real hardware?
--
Jean Delvare
SUSE L3 Support
; return retval;
> - }
> } else {
> retval = piix4_setup(dev, id);
> if (retval < 0)
> @@ -983,11 +978,8 @@ static void piix4_adap_remove(struct i2c_adapter *adap)
>
> if (adapdata->smba) {
> i2c_del_adapter(ad
EPROMs in mind and there is absolutely no guarantee that the
"emulation" will do the right thing. Before calling it, you must check
all the code paths in i2c_smbus_read_i2c_block_data_or_emulated() and
ensure that all will do the right thing for your device.
--
Jean Delvare
SUSE L3 Support
no guarantee that the
"emulation" will do the right thing. Before calling it, you must check
all the code paths in i2c_smbus_read_i2c_block_data_or_emulated() and
ensure that all will do the right thing for your device.
--
Jean Delvare
SUSE L3 Support
insertions(+), 37 deletions(-)
---
Ard Biesheuvel (1):
firmware: dmi: handle missing DMI data gracefully
Jean Delvare (3):
firmware: dmi: Optimize dmi_matches
firmware: dmi_scan: Drop dmi_initialized
firmware: dmi_scan: Fix handling of empty DMI strings
Thanks
insertions(+), 37 deletions(-)
---
Ard Biesheuvel (1):
firmware: dmi: handle missing DMI data gracefully
Jean Delvare (3):
firmware: dmi: Optimize dmi_matches
firmware: dmi_scan: Drop dmi_initialized
firmware: dmi_scan: Fix handling of empty DMI strings
Thanks
I already have a similar patch by Ard Biesheuvel in my dmi tree:
http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/firmware-dmi-handle-missing-dmi-data-gracefully.patch
Does it work for you?
I'll send a pull request to Linus later today.
Thanks,
--
Jean Delvare
SUSE L3 Support
similar patch by Ard Biesheuvel in my dmi tree:
http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/firmware-dmi-handle-missing-dmi-data-gracefully.patch
Does it work for you?
I'll send a pull request to Linus later today.
Thanks,
--
Jean Delvare
SUSE L3 Support
;clk-mtk.h" should be good to stay
> there because the declaration it needs is in the clk-mtk.h
Agreed.
--
Jean Delvare
SUSE L3 Support
;clk-mtk.h" should be good to stay
> there because the declaration it needs is in the clk-mtk.h
Agreed.
--
Jean Delvare
SUSE L3 Support
> diff --git a/drivers/clk/mediatek/reset.c b/drivers/clk/mediatek/reset.c
> index d3551d5..70ebb2e 100644
> --- a/drivers/clk/mediatek/reset.c
> +++ b/drivers/clk/mediatek/reset.c
> @@ -19,8 +19,6 @@
> #include
> #include
>
> -#include "clk-mtk.h"
> -
&
- a/drivers/clk/mediatek/reset.c
> +++ b/drivers/clk/mediatek/reset.c
> @@ -19,8 +19,6 @@
> #include
> #include
>
> -#include "clk-mtk.h"
> -
> struct mtk_reset {
> struct regmap *regmap;
> int regofs;
If the header file is indeed not needed then that's still a good
change, even if it doesn't fix the problem, so:
Reviewed-by: Jean Delvare
However the patch description should be adjusted accordingly.
--
Jean Delvare
SUSE L3 Support
b/fs/cifs/Kconfig
> @@ -199,6 +199,7 @@ config CIFS_SMB311
> config CIFS_SMB_DIRECT
> bool "SMB Direct support (Experimental)"
> depends on CIFS && INFINIBAND
> + depends on CIFS=m || INFINIBAND=y
> help
> Enables SMB Direct experimental
gt; @@ -199,6 +199,7 @@ config CIFS_SMB311
> config CIFS_SMB_DIRECT
> bool "SMB Direct support (Experimental)"
> depends on CIFS && INFINIBAND
> + depends on CIFS=m || INFINIBAND=y
> help
> Enables SMB Direct experimental support for SMB 3
"SMBus PIIX4 adapter%s at %04x", name, smba);
>
Looks good to me but I think you have the patches in the wrong order.
First we must get the port number right, and then you can instantiate
the devices from the ACPI data. If you do it the other way around then
you have a transient situation where you instantiate a device where it
does not exist.
--
Jean Delvare
SUSE L3 Support
t %04x", name, smba);
>
Looks good to me but I think you have the patches in the wrong order.
First we must get the port number right, and then you can instantiate
the devices from the ACPI data. If you do it the other way around then
you have a transient situation where you instantiate a device where it
does not exist.
--
Jean Delvare
SUSE L3 Support
pdata->port <= 1.
Please note that I just sent a fix for this specific function, so any
patch touching the same area should go on top of it. I'll bounce it to
you.
--
Jean Delvare
SUSE L3 Support
that I just sent a fix for this specific function, so any
patch touching the same area should go on top of it. I'll bounce it to
you.
--
Jean Delvare
SUSE L3 Support
sk))
> - return PTR_ERR(task);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(task);
> }
>
> /* Start the kernel thread later: */
Looks good to me.
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
urn PTR_ERR(task);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(task);
> }
>
> /* Start the kernel thread later: */
Looks good to me.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
ed in various places before, for instance, [1], but
> unfortunately, without any solution.
There are two patches waiting to be tested in
https://bugzilla.kernel.org/show_bug.cgi?id=195751
--
Jean Delvare
SUSE L3 Support
ed in various places before, for instance, [1], but
> unfortunately, without any solution.
There are two patches waiting to be tested in
https://bugzilla.kernel.org/show_bug.cgi?id=195751
--
Jean Delvare
SUSE L3 Support
-by: Jean Delvare <jdelv...@suse.de>
---
drivers/misc/eeprom/Kconfig | 11 +
drivers/misc/eeprom/Makefile |1
drivers/misc/eeprom/ee1004.c | 281 +++
3 files changed, 293 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linu
-by: Jean Delvare
---
drivers/misc/eeprom/Kconfig | 11 +
drivers/misc/eeprom/Makefile |1
drivers/misc/eeprom/ee1004.c | 281 +++
3 files changed, 293 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-4.14/drivers/misc
gt; This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
I'm no longer taking patches from you.
--
Jean Delvare
SUSE L3 Support
e Coccinelle software.
>
> Signed-off-by: Markus Elfring
I'm no longer taking patches from you.
--
Jean Delvare
SUSE L3 Support
@ static int __init dmi_init(void)
> u8 *dmi_table;
> int ret = -ENOMEM;
>
> - if (!dmi_available) {
> - ret = -ENODATA;
> - goto err;
> - }
> + if (!dmi_available)
> + return 0;
>
> /*
>* Set up dmi directory at /sys/firmware/dmi. This entry should stay
Looks good. Applied, thanks!
--
Jean Delvare
SUSE L3 Support
d)
> u8 *dmi_table;
> int ret = -ENOMEM;
>
> - if (!dmi_available) {
> - ret = -ENODATA;
> - goto err;
> - }
> + if (!dmi_available)
> + return 0;
>
> /*
>* Set up dmi directory at /sys/firmware/dmi. This entry should stay
Looks good. Applied, thanks!
--
Jean Delvare
SUSE L3 Support
> u8 *dmi_table;
> int ret = -ENOMEM;
>
> - if (!dmi_available) {
> - ret = -ENODATA;
> - goto err;
> - }
> + if (!dmi_available)
> + return 0;
>
> /*
>* Set up dmi directory at /sys/firmware/dmi. This entry should stay
--
Jean Delvare
SUSE L3 Support
= -ENOMEM;
>
> - if (!dmi_available) {
> - ret = -ENODATA;
> - goto err;
> - }
> + if (!dmi_available)
> + return 0;
>
> /*
>* Set up dmi directory at /sys/firmware/dmi. This entry should stay
--
Jean Delvare
SUSE L3 Support
-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> ---
> v3: Suggestions by Jean Delvare <jdelv...@suse.de>
> -Group booleans in struct i2c_piix4_adaptada
> (Sorry about that, I thought your concern was the space between the
> new field and the rest)
> -
ff-by: Ricardo Ribalda Delgado
> ---
> v3: Suggestions by Jean Delvare
> -Group booleans in struct i2c_piix4_adaptada
> (Sorry about that, I thought your concern was the space between the
> new field and the rest)
> -Rename port regions
> -Rename definitions
> -Unify c
gt; Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> ---
> v2: Suggestions by Jean Delvare <jdelv...@suse.de>
>
> -Fix function definitions (static)
> -Add register definition
> -Use muxed_io interface
> -Improve comments
gt; Signed-off-by: Ricardo Ribalda Delgado
> ---
> v2: Suggestions by Jean Delvare
>
> -Fix function definitions (static)
> -Add register definition
> -Use muxed_io interface
> -Improve comments
> -Keep old timeout
> -Rebase
>
>
> drivers/i2c/busses/i2c-pii
Hi Ricardo,
On Thu, 5 Oct 2017 16:53:28 +0200, Ricardo Ribalda Delgado wrote:
> On Thu, Oct 5, 2017 at 4:22 PM, Jean Delvare <jdelv...@suse.de> wrote:
> > Unfortunately I no longer have any system with a compatible chipset so
> > I can't test.
>
> If you have some
Hi Ricardo,
On Thu, 5 Oct 2017 16:53:28 +0200, Ricardo Ribalda Delgado wrote:
> On Thu, Oct 5, 2017 at 4:22 PM, Jean Delvare wrote:
> > Unfortunately I no longer have any system with a compatible chipset so
> > I can't test.
>
> If you have some specific test to run
ix4_port_mask_sb800) | port,
> >SB800_PIIX4_SMB_IDX + 1);
> >
> > retval = piix4_access(adap, addr, flags, read_write,
> > @@ -706,7 +728,7 @@ static int piix4_add_adapter(struct pci_dev *dev,
> > unsigned short smba,
> >
> > adapdata->smba = smba;
> > adapdata->sb800_main = sb800_main;
> > - adapdata->port = port << 1;
> > + adapdata->port = port << piix4_port_shift_sb800;
> >
> > /* set up the sysfs linkage to our parent device */
> > adap->dev.parent = >dev;
Sorry for the delay. Looks all good to me (as I'd expect from Gunter...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
,
> > SB800_PIIX4_SMB_IDX + 1);
> >
> > retval = piix4_access(adap, addr, flags, read_write,
> > @@ -706,7 +728,7 @@ static int piix4_add_adapter(struct pci_dev *dev,
> > unsigned short smba,
> >
> > adapdata->smba = smba;
> > adapdata->sb800_main = sb800_main;
> > - adapdata->port = port << 1;
> > + adapdata->port = port << piix4_port_shift_sb800;
> >
> > /* set up the sysfs linkage to our parent device */
> > adap->dev.parent = >dev;
Sorry for the delay. Looks all good to me (as I'd expect from Gunter...)
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
/* Try to register main SMBus adapter, give up if we can't */
> - retval = piix4_add_adapter(dev, retval, false, 0, "",
> + retval = piix4_add_adapter(dev, retval, false, 0, false, "",
> _main_adapters[0]);
> if (retval < 0)
> return retval;
> @@ -827,7 +902,7 @@ static int piix4_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> if (retval > 0) {
> /* Try to add the aux adapter if it exists,
>* piix4_add_adapter will clean up if this fails */
> - piix4_add_adapter(dev, retval, false, 0,
> + piix4_add_adapter(dev, retval, false, 0, false,
> is_sb800 ? piix4_aux_port_name_sb800 : "",
> _aux_adapter);
> }
--
Jean Delvare
SUSE L3 Support
to register main SMBus adapter, give up if we can't */
> - retval = piix4_add_adapter(dev, retval, false, 0, "",
> + retval = piix4_add_adapter(dev, retval, false, 0, false, "",
> _main_adapters[0]);
> if (retval < 0)
> return retval;
> @@ -827,7 +902,7 @@ static int piix4_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> if (retval > 0) {
> /* Try to add the aux adapter if it exists,
>* piix4_add_adapter will clean up if this fails */
> - piix4_add_adapter(dev, retval, false, 0,
> + piix4_add_adapter(dev, retval, false, 0, false,
> is_sb800 ? piix4_aux_port_name_sb800 : "",
> _aux_adapter);
> }
--
Jean Delvare
SUSE L3 Support
e
drivers reside and they aren't built.
If you really want your drivers to be test-compilable then you must
change the above to:
obj-y += mediatek/
I'll send a patch.
Your patch itself looks good to me.
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
est-compile
these drivers. The problem is in drivers/soc/Makefile:
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
So while Kconfig lets me select the drivers when COMPILE_TEST is
enabled, the build system itself ignores the directory in which these
drivers reside and they aren't built.
If you really want
+static struct gsmi_device {
> struct platform_device *pdev; /* platform device */
> struct gsmi_buf *name_buf; /* variable name buffer */
> struct gsmi_buf *data_buf; /* generic data buffer */
Acked-by: Jean Delvare <jdelv...@suse.de>
Thanks,
--
Jean Delvare
SUSE L3 Support
_device *pdev; /* platform device */
> struct gsmi_buf *name_buf; /* variable name buffer */
> struct gsmi_buf *data_buf; /* generic data buffer */
Acked-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
On Thu, 28 Sep 2017 10:38:27 +0200, Ingo Molnar wrote:
> * Jean Delvare <jdelv...@suse.de> wrote:
> > Or... I could append the \n inside the STANDARD_PARAM_DEF macro, so the
> > calls are unchanged. Makes my patch smaller, and addresses your concern
> > just as w
On Thu, 28 Sep 2017 10:38:27 +0200, Ingo Molnar wrote:
> * Jean Delvare wrote:
> > Or... I could append the \n inside the STANDARD_PARAM_DEF macro, so the
> > calls are unchanged. Makes my patch smaller, and addresses your concern
> > just as well, I suppose.
>
&g
Align the parameters passed to STANDARD_PARAM_DEF for clarity.
Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Jean Delvare <jdelv...@suse.de>
---
Changes since v1:
* Patch added
kernel/params.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--
Align the parameters passed to STANDARD_PARAM_DEF for clarity.
Suggested-by: Ingo Molnar
Signed-off-by: Jean Delvare
---
Changes since v1:
* Patch added
kernel/params.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- linux-4.13.orig/kernel/params.c 2017-09-28
The length parameter of strlcpy() is supposed to reflect the size of
the target buffer, not of the source string. Harmless in this case as
the buffer is PAGE_SIZE long and the source string is always much
shorter than this, but conceptually wrong, so let's fix it.
Signed-off-by: Jean Delvare
The length parameter of strlcpy() is supposed to reflect the size of
the target buffer, not of the source string. Harmless in this case as
the buffer is PAGE_SIZE long and the source string is always much
shorter than this, but conceptually wrong, so let's fix it.
Signed-off-by: Jean Delvare
[PATCH 1/3] params: Fix the maximum length in param_get_string
[PATCH 2/3] params: Fix an overflow in param_attr_show
[PATCH 3/3] params: Improve STANDARD_PARAM_DEF readability
--
Jean Delvare
SUSE L3 Support
[PATCH 1/3] params: Fix the maximum length in param_get_string
[PATCH 2/3] params: Fix an overflow in param_attr_show
[PATCH 3/3] params: Improve STANDARD_PARAM_DEF readability
--
Jean Delvare
SUSE L3 Support
so faster.
Credits to Teradata for discovering this issue.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
---
Changes since v1:
* Add the \n inside the STANDARD_PARAM_DEF macro instead of changing
all the callers.
* Handle boolean and string types too.
* Handle parameter arrays properly.
so faster.
Credits to Teradata for discovering this issue.
Signed-off-by: Jean Delvare
---
Changes since v1:
* Add the \n inside the STANDARD_PARAM_DEF macro instead of changing
all the callers.
* Handle boolean and string types too.
* Handle parameter arrays properly.
kernel/params.c | 17 ++
On Wed, 27 Sep 2017 10:10:31 +0200, Jean Delvare wrote:
> Function param_attr_show could overflow the buffer it is operating
> on. The buffer size is PAGE_SIZE, and the string returned by
> attribute->param->ops->get is generated by scnprintf(buffer,
> PAGE_SIZE, ...) so it c
On Wed, 27 Sep 2017 10:10:31 +0200, Jean Delvare wrote:
> Function param_attr_show could overflow the buffer it is operating
> on. The buffer size is PAGE_SIZE, and the string returned by
> attribute->param->ops->get is generated by scnprintf(buffer,
> PAGE_SIZE, ...) so it c
On Thu, 28 Sep 2017 10:02:23 +0200, Jean Delvare wrote:
> On Wed, 27 Sep 2017 15:31:04 +0200, Ingo Molnar wrote:
> > At minimum I'd suggest aligning the definitions vertically, to make sure
> > any missing \n stands out more, visually:
> >
> > STANDARD_PARAM
On Thu, 28 Sep 2017 10:02:23 +0200, Jean Delvare wrote:
> On Wed, 27 Sep 2017 15:31:04 +0200, Ingo Molnar wrote:
> > At minimum I'd suggest aligning the definitions vertically, to make sure
> > any missing \n stands out more, visually:
> >
> > STANDARD_PARAM
On Wed, 27 Sep 2017 15:31:04 +0200, Ingo Molnar wrote:
> * Jean Delvare <jdelv...@suse.de> wrote:
> > > So the \n additions to the STANDARD_PARAM_DEF() lines
> > >
> > > > +STANDARD_PARAM_DEF(byte, unsigned char, "%hhu\n", kstrtou8);
> > &
On Wed, 27 Sep 2017 15:31:04 +0200, Ingo Molnar wrote:
> * Jean Delvare wrote:
> > > So the \n additions to the STANDARD_PARAM_DEF() lines
> > >
> > > > +STANDARD_PARAM_DEF(byte, unsigned char, "%hhu\n", kstrtou8);
> > > &g
Hi Ingo,
On mer., 2017-09-27 at 10:26 +0200, Ingo Molnar wrote:
> * Jean Delvare <jdelv...@suse.de> wrote:
>
> > Function param_attr_show could overflow the buffer it is operating
> > on. The buffer size is PAGE_SIZE, and the string returned by
> > attribute
Hi Ingo,
On mer., 2017-09-27 at 10:26 +0200, Ingo Molnar wrote:
> * Jean Delvare wrote:
>
> > Function param_attr_show could overflow the buffer it is operating
> > on. The buffer size is PAGE_SIZE, and the string returned by
> > attribute->param->ops->get
Hi Peter,
On Mon, 25 Sep 2017 11:26:44 +0200, Peter Zijlstra wrote:
> On Mon, Sep 25, 2017 at 11:00:11AM +0200, Jean Delvare wrote:
> > Then we have that in common. While reading the code and its history, I
> > was worried that the justification to add this warning in the
Hi Peter,
On Mon, 25 Sep 2017 11:26:44 +0200, Peter Zijlstra wrote:
> On Mon, Sep 25, 2017 at 11:00:11AM +0200, Jean Delvare wrote:
> > Then we have that in common. While reading the code and its history, I
> > was worried that the justification to add this warning in the
so faster.
Credits to Teradata for discovering this issue.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
---
kernel/params.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
--- linux-4.13.orig/kernel/params.c 2017-09-19 16:07:18.794254776 +0200
+++ linux-4.13/ke
so faster.
Credits to Teradata for discovering this issue.
Signed-off-by: Jean Delvare
---
kernel/params.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
--- linux-4.13.orig/kernel/params.c 2017-09-19 16:07:18.794254776 +0200
+++ linux-4.13/kernel/params.
strings are
non-empty and should be allocated.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar <parag.warud...@gmail.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Thomas Gleixner <t...@linut
strings are
non-empty and should be allocated.
Signed-off-by: Jean Delvare
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar
Cc: Ingo Molnar
Cc: Thomas Gleixner
---
drivers/firmware/dmi_scan.c | 22 +-
1 file changed, 9 insertions(+), 13
RESET_CONTROLLER
> select REGMAP
> help
> Say yes here to add support for MediaTek PMIC Wrapper found
--
Jean Delvare
SUSE L3 Support
ediatek/Kconfig
> @@ -15,7 +15,7 @@ config MTK_INFRACFG
> config MTK_PMIC_WRAP
> tristate "MediaTek PMIC Wrapper Support"
> depends on ARCH_MEDIATEK
> - depends on RESET_CONTROLLER
> + select RESET_CONTROLLER
> select REGMAP
> help
>
INFRACFG Support"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> @@ -30,3 +32,5 @@ config MTK_SCPSYS
> help
> Say yes here to add support for the MediaTek SCPSYS power domain
> driver.
> +
> +endmenu
--
Jean Delvare
SUSE L3 Support
|| COMPILE_TEST
> @@ -30,3 +32,5 @@ config MTK_SCPSYS
> help
> Say yes here to add support for the MediaTek SCPSYS power domain
> driver.
> +
> +endmenu
--
Jean Delvare
SUSE L3 Support
On Sun, 24 Sep 2017 11:16:25 +0200, Ingo Molnar wrote:
> * Jean Delvare <jdelv...@suse.de> wrote:
> > On Sat, 23 Sep 2017 12:50:31 +0200, Ingo Molnar wrote:
> > > * Jean Delvare <jdelv...@suse.de> wrote:
> > > > I don't think it makes sense to check
On Sun, 24 Sep 2017 11:16:25 +0200, Ingo Molnar wrote:
> * Jean Delvare wrote:
> > On Sat, 23 Sep 2017 12:50:31 +0200, Ingo Molnar wrote:
> > > * Jean Delvare wrote:
> > > > I don't think it makes sense to check for a possible bad
> > > > initializat
Hi Ingo,
On Sat, 23 Sep 2017 12:50:31 +0200, Ingo Molnar wrote:
> * Jean Delvare <jdelv...@suse.de> wrote:
>
> > I don't think it makes sense to check for a possible bad
> > initialization order at run time on every system when it is all
> > decided at build time.
Hi Ingo,
On Sat, 23 Sep 2017 12:50:31 +0200, Ingo Molnar wrote:
> * Jean Delvare wrote:
>
> > I don't think it makes sense to check for a possible bad
> > initialization order at run time on every system when it is all
> > decided at build time.
> >
> &g
hey exist (for example parameter
edid_firmware of module drm_kms_helper is an empty string by default.)
Reading such parameters would now return a blank line, instead of
nothing at all. I think it is more consistent, more efficient and more
elegant, but I don't know if anyone is worried about potential side
effects? If so, this special case could also be handled directly in
function param_get_charp.
I would personally prefer the 3rd option, but I'm curious if other
developers have different opinions (and if so, why.)
Thanks,
--
Jean Delvare
SUSE L3 Support
hey exist (for example parameter
edid_firmware of module drm_kms_helper is an empty string by default.)
Reading such parameters would now return a blank line, instead of
nothing at all. I think it is more consistent, more efficient and more
elegant, but I don't know if anyone is worried about potential side
effects? If so, this special case could also be handled directly in
function param_get_charp.
I would personally prefer the 3rd option, but I'm curious if other
developers have different opinions (and if so, why.)
Thanks,
--
Jean Delvare
SUSE L3 Support
It's not obvious to everybody that BP stands for boot processor. At
least it was not for me.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Alok Kataria <akata...@vmware.com>
---
arch/x86/kernel/setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.14-r
It's not obvious to everybody that BP stands for boot processor. At
least it was not for me.
Signed-off-by: Jean Delvare
Cc: Alok Kataria
---
arch/x86/kernel/setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.14-rc1.orig/arch/x86/kernel/setup.c 2017-09-17 00:47
This parameter is named kp, so the documentation should use that.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Fixes: 9b473de87209 ("param: Fix duplicate module prefixes")
Cc: Rusty Russell <ru...@rustcorp.com.au>
---
kernel/params.c |2 +-
1 file changed, 1 in
This parameter is named kp, so the documentation should use that.
Signed-off-by: Jean Delvare
Fixes: 9b473de87209 ("param: Fix duplicate module prefixes")
Cc: Rusty Russell
---
kernel/params.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.14-rc1.orig/kerne
Function cdev_add does set cdev->dev, so there is no point in setting
it prior to calling this function.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
---
Untested. Changes
Function cdev_add does set cdev->dev, so there is no point in setting
it prior to calling this function.
Signed-off-by: Jean Delvare
Cc: Martin Schwidefsky
Cc: Heiko Carstens
---
Untested. Changes since v1 (2016-07-13):
* Improved description
* Added a few blank lines to make the code m
-by: Jean Delvare <jdelv...@suse.de>
Cc: Ingo Molnar <mi...@kernel.org>
---
drivers/firmware/dmi_scan.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
--- linux-4.14-rc0.orig/drivers/firmware/dmi_scan.c 2017-09-15
11:58:10.005977920 +0200
+++ li
-by: Jean Delvare
Cc: Ingo Molnar
---
drivers/firmware/dmi_scan.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
--- linux-4.14-rc0.orig/drivers/firmware/dmi_scan.c 2017-09-15
11:58:10.005977920 +0200
+++ linux-4.14-rc0/drivers/firmware/dmi_scan.c 2017-09-18
Thanks,
--
Jean Delvare
SUSE L3 Support
Thanks,
--
Jean Delvare
SUSE L3 Support
On Mon, 04 Sep 2017 08:48:36 -0700, Joe Perches wrote:
> On Mon, 2017-09-04 at 10:08 +0200, Jean Delvare wrote:
> > Drop the header and numbering of types. This format was confusing as
> > it suggested one could pass the number instead of the type name,
> > however it
On Mon, 04 Sep 2017 08:48:36 -0700, Joe Perches wrote:
> On Mon, 2017-09-04 at 10:08 +0200, Jean Delvare wrote:
> > Drop the header and numbering of types. This format was confusing as
> > it suggested one could pass the number instead of the type name,
> > however it
Drop the header and numbering of types. This format was confusing as
it suggested one could pass the number instead of the type name,
however it did not actually work, and numbering wasn't stable anyway.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Andy Whitcroft <a...@canonica
201 - 300 of 3166 matches
Mail list logo
