-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. T
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
ing defaults\n");
> outw(backbone_speed / (4 * 100), SMBHSTCLK);
> }
>
Reviewed-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
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, this c
*,
> }
> };
>
> -#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
could
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 (&
conflicts.
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
Colin Ian 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 inser
could
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 (&
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_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
return -ENOMEM;
>
> /* A fake client is created on the odd address */
Reviewed-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
files changed, 4 insertions(+)
---
Simon Glass (1):
firmware: dmi: Add access to the SKU ID string
Thanks,
--
Jean Delvare
SUSE L3 Support
not going to cause
too much trouble. 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
displayed immediately and 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
ic 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 */
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
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
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
Thanks,
--
Jean Delvare
SUSE L3 Support
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, appare
ns:
CONFIG_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
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
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
v);
> @@ -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
/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
ct
SKU before product family in all files, same order as in the DMI entry
itself.
--
Jean Delvare
SUSE L3 Support
d 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
rate
package (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
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
(-)
---
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
Jean has 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
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
e seen had 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
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]
> >
>
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
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
t 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
--
Jean Delvare
SUSE L3 Support
t; 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
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 wa
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 bla
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
else {
> retval = piix4_setup(dev, id);
> 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
--
Jean Delvare
SUSE L3 Support
n 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
would tend to agree. 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
*/
> - if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
> - year >= 2015) {
> + if (dmi_get_bios_year() >= 2015)
> return true;
> - }
> break;
> }
>
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
gt; if (ignore_blacklist)
> return;
>
> - if (dmi_get_date(DMI_BIOS_DATE, &year, 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
; if (!strncmp(mcfg->header.oem_id, "SGI", 3))
> return 0;
>
> - if (mcfg->header.revision >= 1) {
> - if (dmi_get_date(DMI_BIOS_DATE, &year, 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
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
---
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 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
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.
>
> /* If
ove(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);
> }
Everything else looks good to me, thanks.
I assume you have tested this patch on real hardware?
--
Jean Delvare
SUSE L3 Support
with
EEPROMs 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
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
ave 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
clude "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
s/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"
> -
> 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
58b..3bfc55c08bef 100644
> --- a/fs/cifs/Kconfig
> +++ 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=
"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
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
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
--
Jean Delvare
SUSE L3 Support
lso reported 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
---
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
e Coccinelle software.
>
> Signed-off-by: Markus Elfring
I'm no longer taking patches from you.
--
Jean Delvare
SUSE L3 Support
i_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
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
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
> ---
> 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 wrote:
> > Unfortunately I no longer have any system with a compatible chipset so
> > I can't test.
>
> If you have some specific test t
_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->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
d *id)
> return retval;
>
> /* 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, "",
> &piix4_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 : "",
> &piix4_aux_adapter);
> }
--
Jean Delvare
SUSE L3 Support
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
t 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
Thanks,
--
Jean Delvare
SUSE L3 Support
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
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 De
[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
tents to
the buffer originally. This is safe, and also 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 par
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_
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 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 firs
tents to
the buffer originally. This is safe, and also 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
other 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(+
vers/soc/mediatek/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
>
ATEK || 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 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
> > > > initia
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
urn count;
}
The only case where it makes a difference is for empty string
parameters. They are rare but they 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
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
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
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
d-off-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-
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 did n
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
Cc: Andy Whitcroft
Cc: Joe Perches
---
scripts/checkpat
On Sat, 02 Sep 2017 15:58:05 -0700, Joe Perches wrote:
> On Sat, 2017-09-02 at 23:03 +0200, Jean Delvare wrote:
> > Oh, btw, is there any purpose in listing a number in front of each
> > type?
>
> Not really. I did that because I wanted a header
> and because I had n
n't we simplify the output and simply print the list of type names?
Thanks,
--
Jean Delvare
SUSE L3 Support
Hi Joe,
On Sat, 02 Sep 2017 09:25:29 -0700, Joe Perches wrote:
> On Sat, 2017-09-02 at 17:51 +0200, Jean Delvare wrote:
> > [PATCH 1/3] checkpatch: fix typo in comment
> > [PATCH 2/3] checkpatch: rename variables to avoid confusion
> > [PATCH 3/3] checkpatch: add 6 missing
101 - 200 of 1616 matches
Mail list logo
