AVOID_BUG
are passed with a variable level, causing the parser to miss them
too.
So modify the regex to also catch these special cases.
Signed-off-by: Jean Delvare
Fixes: 3beb42eced39 ("checkpatch: add --list-types to show message types to
show or ignore")
Cc: Andy Whitcroft
Cc: J
The variable name "$msg_type" is sometimes used to set the message
type, and sometimes used to set the message level. This works but is
kind of confusing. Use "$msg_level" in the latter case instead, to
make the code clearer.
Signed-off-by: Jean Delvare
Cc: Andy Whitcr
Signed-off-by: Jean Delvare
Cc: Andy Whitcroft
Cc: Joe Perches
---
scripts/checkpatch.pl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.13-rc7.orig/scripts/checkpatch.pl 2017-07-30 21:40:36.0
+0200
+++ linux-4.13-rc7/scripts/checkpatch.pl2017-09-01 15
[PATCH 1/3] checkpatch: fix typo in comment
[PATCH 2/3] checkpatch: rename variables to avoid confusion
[PATCH 3/3] checkpatch: add 6 missing types to --list-types
---
scripts/checkpatch.pl | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
--
Jean
linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
--
Jean Delvare
SUSE L3 Support
On mer., 2017-08-09 at 09:18 -0700, Matt Roper wrote:
> On Mon, Jul 31, 2017 at 10:36:05AM +0200, Jean Delvare wrote:
> >
> > Hi Matt, Mauro,
> >
> > On Thu, 17 Mar 2016 15:18:20 +0100, Jean Delvare wrote:
> > >
> > > On Tue, 8 Mar 2016 10:32:3
const struct attribute_group vid_attr_group = { .attrs = vid_attrs };
>
> static int adt7475_detect(struct i2c_client *client,
> struct i2c_board_info *info)
Looks good to me.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
> drivers/misc/ds1682.c | 2 +-
> drivers/misc/eeprom/eeprom.c | 2 +-
> drivers/misc/eeprom/max6875.c | 2 +-
> drivers/misc/pch_phub.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
> (...)
Reviewed-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
NFIG_CPU_IDLE isn't set. Not my area, but after
a quick look at the code I strongly suspect this is not the case.
> > Fixes: ea8b1c4a6019 ("drivers: psci: PSCI checker module")
> > Signed-off-by: Arnd Bergmann
>
> Acked-by: Kevin Brodsky
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
Hi Matt, Mauro,
On Thu, 17 Mar 2016 15:18:20 +0100, Jean Delvare wrote:
> On Tue, 8 Mar 2016 10:32:37 -0800, Matt Roper wrote:
> > A couple of the EDAC drivers have a nice memdev_dmi_entry structure for
> > decoding DMI memory device entries. Move the structure definition to
&g
uchscreen/htcpen.c, I'll take care of that.
Lastly checkpatch complains about the position of __initconst on 18
instances, I'll fix that as well.
Thanks,
--
Jean Delvare
SUSE L3 Support
fed33 ("DMI: Introduce dmi_first_match to make the interface
more flexible").
* Don't check for the exact_match flag again when we already know its
value.
Signed-off-by: Jean Delvare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rafael J. Wysocki
Cc: Jeff Garzik
---
Regarding dmi_
with operating-points-v2
> bindings. Also, this driver actually supports all MediaTek SoCs, the
> Kconfig menu entry and file name itself should be updated with more
> generic name to drop "MT8173"
>
> Signed-off-by: Sean Wang
> Acked-by: Viresh Kumar
> Reviewed-
eneral opinion on
the topic. I'm not going to send any patch to rename any of these
drivers, as I have many tasks of higher priority on my own plate. And I
agree that renaming existing drivers does have a cost as well. So
whatever is decided is fine with me, really.
--
Jean Delvare
SUSE L3 Support
mt8173_cpufreq_machines[] __initconst = {
> + { .compatible = "mediatek,mt2701", },
> + { .compatible = "mediatek,mt7623", },
> { .compatible = "mediatek,mt817x", },
> { .compatible = "mediatek,mt8173", },
> { .compatible = "mediatek,mt8176", },
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
sensors does. If you just do what libsensors does, you'll be
on the safe side.
--
Jean Delvare
SUSE L3 Support
| 2 +-
3 files changed, 40 insertions(+), 15 deletions(-)
---
Andy Lutomirski (1):
firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error
codes
Jean Delvare (3):
firmware: dmi_scan: Look for SMBIOS 3 entry point first
firmware: dmi: Fix permissions
s a base for today (the patches applied cleanly).
Oops, sorry about that. Fixed.
--
Jean Delvare
SUSE L3 Support
On Sat, 3 Jun 2017 11:05:00 -0700, Andy Lutomirski wrote:
> Currently they return -1 on error, which will confuse callers if
> they try to interpret it as a normal negative error code.
>
> Signed-off-by: Andy Lutomirski
> Cc: Jean Delvare
> Signed-off-by: Darren Hart (VMware)
On Fri, 2 Jun 2017 21:45:37 +0300, Andy Shevchenko wrote:
> On Fri, Jun 2, 2017 at 9:40 PM, Jean Delvare wrote:
> > On Thu, 1 Jun 2017 19:06:36 +0300, Andy Shevchenko wrote:
> >> Your commit message should answer to the question why and what.
> >> You didn't
On Thu, 1 Jun 2017 19:06:36 +0300, Andy Shevchenko wrote:
> On Thu, Jun 1, 2017 at 5:40 PM, Jean Delvare wrote:
> > On Thu, 1 Jun 2017 16:16:05 +0300, Andy Shevchenko wrote:
> >> On Thu, Jun 1, 2017 at 4:08 PM, Jean Delvare wrote:
>
> >> > -
Hi Andy,
Thanks for the review.
On Thu, 1 Jun 2017 16:16:05 +0300, Andy Shevchenko wrote:
> On Thu, Jun 1, 2017 at 4:08 PM, Jean Delvare wrote:
> > Before accessing DMI data to record it for later, we should ensure
> > that the DMI structures are large enough to contain the data
This is not sensitive information like serial numbers, we can allow
all users to read it.
Fix odd alignment while we're here.
Signed-off-by: Jean Delvare
Fixes: c61872c9833d ("firmware: dmi: Add DMI_PRODUCT_FAMILY identification
string")
Cc: Dmitry Torokhov
Cc: Mika Weste
Before accessing DMI data to record it for later, we should ensure
that the DMI structures are large enough to contain the data in
question.
Signed-off-by: Jean Delvare
Cc: Dmitry Torokhov
Cc: Mika Westerberg
Cc: Andy Shevchenko
Cc: Linus Walleij
---
drivers/firmware/dmi_scan.c | 23
rom users. Permissions 0444 would
seem more appropriate. I'll include that change in my patch if there
are no objections.
--
Jean Delvare
SUSE L3 Support
On Thu, 1 Jun 2017 13:09:40 +0300, Mika Westerberg wrote:
> On Thu, Jun 01, 2017 at 11:29:26AM +0200, Jean Delvare wrote:
> > Hi all,
> >
> > Sorry for the late reply.
> >
> > On Wed, 17 May 2017 13:25:12 +0300, Mika Westerberg wrote:
> > > Sometimes i
"Edgar"),
> DMI_MATCH(DMI_BIOS_DATE, "05/21/2016"),
> },
> - }
> + },
> + {}
> };
>
> static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
Reviewed-by: Jean Delvare
This should go to stable trees IMHO.
--
Jean Delvare
SUSE L3 Support
x 566fda587fcf..3f74ef2281e8 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -467,6 +467,7 @@ enum dmi_field {
> DMI_PRODUCT_VERSION,
> DMI_PRODUCT_SERIAL,
> DMI_PRODUCT_UUID,
> + DMI_PRODUCT_FAMILY,
> DMI_BOARD_VENDOR,
> DMI_BOARD_NAME,
> DMI_BOARD_VERSION,
--
Jean Delvare
SUSE L3 Support
> Signed-off-by: Andy Lutomirski
> Cc: Jean Delvare
> Signed-off-by: Darren Hart (VMware)
> ---
> drivers/firmware/dmi_scan.c | 9 +
> include/linux/dmi.h | 2 +-
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/d
can't we
just add:
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Magicfoo"),
DMI_MATCH(DMI_CHASSIS_TYPE, "9"), /*Laptop*/
},
},
to drivers/platform/x86/dell-laptop.c and be done with it? The driver
can simply bail out if loaded on a system where it isn't actually
needed. Isn't it good enough?
--
Jean Delvare
SUSE L3 Support
ver */
> static const struct of_device_id mt8173_cpufreq_machines[] __initconst = {
> + { .compatible = "mediatek,mt2701", },
> + { .compatible = "mediatek,mt7623", },
> { .compatible = "mediatek,mt817x", },
> { .compatible = "mediatek,mt8173", },
> { .compatible = "mediatek,mt8176", },
--
Jean Delvare
SUSE L3 Support
ACPI && DMI && I2C=y && INPUT && TOUCHSCREEN_SILEAD
> ---help---
> Certain ACPI based tablets with Silead touchscreens do not have
> enough data in ACPI tables for the touchscreen driver to handle
Reviewed-by: Jean Delvare
Thanks Darren,
--
Jean Delvare
SUSE L3 Support
Hi Mario, Allen,
Sorry for taking so long to get back to you. No excuses really :-(
On Thu, 1 Sep 2016 19:14:54 +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent: Thursday, September 1, 2
h from you. You are
an annoyance we don't need. Do not waste our time. Go away.
--
Jean Delvare
SUSE L3 Support
Signed-off-by: Jean Delvare
Fixes: 97b50a654d5d ("virtio_blk: make SCSI passthrough support configurable")
Cc: Christoph Hellwig
Cc: Jens Axboe
---
drivers/block/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.11-rc8.orig/drivers/block/Kconfig 2017-0
Signed-off-by: Jean Delvare
Fixes: c61f13eaa1ee ("gcc-plugins: Add structleak for more stack
initialization")
Cc: Kees Cook
---
arch/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.11-rc8.orig/arch/Kconfig2017-04-03 02:23:54.0 +0200
+++ linu
r_xfer() for
validity, this should be done in __i2c_transfer(). But then again, I
find it hard to justify the run-time overhead for working drivers, so
maybe it should only be done if CONFIG_I2C_DEBUG_BUS is enabled.
--
Jean Delvare
SUSE L3 Support
--
Jean Delvare
SUSE L3 Support
--
Jean Delvare
SUSE L3 Support
vers/i2c/.
>
> Suggested-by: Alan Cox
> Signed-off-by: David Howells
> cc: Wolfram Sang
> cc: Jean Delvare
> cc: linux-...@vger.kernel.org
> (...)
Acked-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
c", ar1021);
> if (error) {
> dev_err(&client->dev,
Acked-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
ouchscreen")
> Signed-off-by: Dmitry Torokhov
> ---
>
> V2: Changed MICROCHIP_AR1021 -> ar1021 as Jean suggested.
>
> drivers/input/touchscreen/ar1021_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> (...)
Reviewed-by: Jean Delvare
> diff --git a
M_SMD is optional (if not, I would suggest to drop all the
stubs and simply depend on RPMSG_QCOM_SMD || QCOM_SMD, for the sake of
simplicity.)
Don't get me wrong, I am a big fan of COMPILE_TEST, but only when we
can use it to get build testing coverage for free. If you have to change
the code itself in order to be able to get the extra build testing
coverage, I don't think it is a good idea. The kernel and the Kconfig
dependencies can be complex enough as is.
--
Jean Delvare
SUSE L3 Support
ever add another type to the bus,
> > so let's export i2c_client_type as well.
> >
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > Wolfram, this is the patch I was talking about in the other mail.
>
> I see. From a glimpse, I am fine with the pat
Hi Hans,
On ven., 2017-03-03 at 15:27 +0100, Hans de Goede wrote:
> On 03-03-17 10:24, Jean Delvare wrote:
> > On Sat, 25 Feb 2017 18:23:55 +0100, Hans de Goede wrote:
> > > 1) Rather then add cmdline options for all things which can be DMI quirked
> > > and thus may
anks Jean, that was easy.
You're welcome, glad I could help :-)
> Looking forward to see it in some future kernel.
--
Jean Delvare
SUSE L3 Support
n into the final buffer.
>
> The idea was that the called code would return a pointer to a constant string,
> ie one that isn't changing from call to call.
In that case, what about the following change?
Subject: hwmon: Constify str parameter of hwmon_ops->read_string
The read_str
could give a try to this
standalone driver:
http://jdelvare.nerim.net/devel/lm-sensors/drivers/dell-smm-hwmon/
Instructions are at:
http://jdelvare.nerim.net/devel/lm-sensors/drivers/INSTALL
--
Jean Delvare
SUSE L3 Support
Hi Peter,
On Fri, 3 Mar 2017 01:33:01 +0100, Peter Hüwe wrote:
> is anybody else working on the conversion of the w83627ehf to the new
> hwmon_device_register_with_info interface?
Not me.
--
Jean Delvare
SUSE L3 Support
y(child, &device->children, node)
> if (child->status.present && child->status.enabled)
> acpi_device_fix_up_power(child);
>
> - if (acpi_bus_get_status(device) || !device->status.present)
> - return -ENODEV;
> -
> if (sdhci_acpi_byt_defer(dev))
> return -EPROBE_DEFER;
>
--
Jean Delvare
SUSE L3 Support
> const char **device)
> }
> }
> EXPORT_SYMBOL_GPL(dmi_memdev_name);
> +
> +static int __init dmi_parse_dmi_product_name(char *str)
> +{
> + static char prod_name[32];
> +
> + if (!str)
> + return -EINVAL;
> +
> + strlcpy(prod_name
I have vague memories that I tried to do the same long ago and it
didn't work back then. But I can't no longer remember the details, and
today it seems just fine to do it.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
SIZE8
> +#define SMBIOSIZE9
>
> /* PCI Address Constants */
> #define SMBBA 0x090
I checked all the datasheets I have access to, and it should be good.
Signed-off-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
n",
> + name);
May I suggest adding ", please fix"?
>
> id = ida_simple_get(&hwmon_ida, 0, 0, GFP_KERNEL);
> if (id < 0)
Reviewed-by: Jean Delvare
Do I understand correctly that in the long run we will make it a fatal
error again?
--
Jean Delvare
SUSE L3 Support
>
> Isn't it better to have a potentially unused register mapped than a
> potentially used register unmapped?
My concern is that the region request could fail due to a conflict with
another device, if the physical I/O region is only 8 and we try to
request 9.
--
Jean Delvare
SUSE L3 Support
MBIOSIZE8
> +#define SMBIOSIZE9
>
Are you certain that all supported devices have this extra register?
>
> /* PCI Address Constants */
> #define SMBBA0x090
--
Jean Delvare
SUSE L3 Support
On Thu, 26 Jan 2017 11:29:11 +0200, Mika Westerberg wrote:
> On Thu, Jan 26, 2017 at 10:05:06AM +0100, Jean Delvare wrote:
> > I have not, as I do not have access to any Baytrail hardware. This is
> > the very reason why I'd like this code to be buildable as a module: I&#x
It's not fixing a build breakage, if that's what you were worried
about. I agree it's not stable material and I did not Cc stable. For
me, Cc: stable@ and Fixes: are not correlated.
> You can drop the fixes tag and add my ack. Please post it to
> a...@kernel.org, so that ARM SoC team can pick this up directly.
I can't see this address in MAINTAINERS.
--
Jean Delvare
SUSE L3 Support
Hi Mika and all,
On Wed, 25 Jan 2017 18:16:51 +0200, Mika Westerberg wrote:
> On Wed, Jan 25, 2017 at 04:26:08PM +0100, Jean Delvare wrote:
> > The pinctrl-baytrail driver builds just fine as a module so give
> > users this option.
> >
> > Signed-off-by: Jean Delva
The pinctrl-baytrail driver builds just fine as a module so give
users this option.
Signed-off-by: Jean Delvare
Cc: Mika Westerberg
Cc: Heikki Krogerus
Cc: Linus Walleij
---
This was discussed almost one year ago, with no clear conclusion, but
also no evidence that the driver can't be
List soft dependencies of cifs so that mkinitrd and dracut can include
the required helper modules.
Signed-off-by: Jean Delvare
Cc: Steve French
---
fs/cifs/cifsfs.c | 12
1 file changed, 12 insertions(+)
--- linux-4.10-rc5.orig/fs/cifs/cifsfs.c2017-01-16 11:13
The sha256 and cmac crypto modules are only needed for SMB2+, so move
the select statements to config CIFS_SMB2. Also select CRYPTO_AES
there as SMB2+ needs it.
Signed-off-by: Jean Delvare
Cc: Steve French
---
fs/cifs/Kconfig |5 +++--
1 file changed, 3 insertions(+), 2 deletions
* CIFS_SMB2 depends on CIFS, which depends on INET and selects NLS. So
these dependencies do not need to be repeated for CIFS_SMB2.
* CIFS_SMB311 depends on CIFS_SMB2, which depends on INET. So this
dependency doesn't need to be repeated for CIFS_SMB311.
Signed-off-by: Jean Delvare
Cc:
reply, so I am trying again.
Thanks,
--
Jean Delvare
SUSE L3 Support
On Wed, 25 Jan 2017 14:20:53 +, Sudeep Holla wrote:
> On 25/01/17 14:14, Jean Delvare wrote:
> > On Wed, 25 Jan 2017 13:56:23 +, Sudeep Holla wrote:
> >> None, hence I didn't say you are wrong ;). I am fine having the check if
> >> it breaks for any othe
On Wed, 25 Jan 2017 13:56:23 +, Sudeep Holla wrote:
> On 25/01/17 13:50, Jean Delvare wrote:
> > On Wed, 25 Jan 2017 13:38:47 +, Sudeep Holla wrote:
> >> On 25/01/17 13:32, Jean Delvare wrote:
> >>> With a name like that, I assume that the ARM SCPI protocol i
On Wed, 25 Jan 2017 13:38:47 +, Sudeep Holla wrote:
> On 25/01/17 13:32, Jean Delvare wrote:
> > With a name like that, I assume that the ARM SCPI protocol is only
> > useful on the ARM architectures.
> >
> > Signed-off-by: Jean Delvare
> > Fixes: 8f1498c03
With a name like that, I assume that the ARM SCPI protocol is only
useful on the ARM architectures.
Signed-off-by: Jean Delvare
Fixes: 8f1498c03d15 ("firmware: arm_scpi: make it depend on MAILBOX instead of")
Cc: Sudeep Holla
Cc: Jon Medhurst (Tixy)
---
Please correct me if
irst, and if we can't find any, look for a 32-bit
("_SM_" or "_DMI_") entry point. Modify the code to do that.
Signed-off-by: Jean Delvare
---
* Note 1: I can't test the 64-bit ("_SM3_") entry point case. I
would appreciate if someone with access to a m
s sense (for human readers or for
stack size optimization - unless gcc does it for us?), rather than
always adding at the same place. Is there a rationale for doing that? I
don't think shrinking the patch size is good enough a reason.
--
Jean Delvare
SUSE L3 Support
Hi Pali,
On Thu, 5 Jan 2017 09:59:39 +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 13:59:17 Jean Delvare wrote:
> > Dell-smbios is a helper module, it serves no purpose on its own, so
> > do not present it as an option to the user. Instead, select it
> > automatica
Hi Andy,
Thanks for the review.
On Wed, 4 Jan 2017 15:14:10 +0200, Andy Shevchenko wrote:
> On Wed, Jan 4, 2017 at 2:59 PM, Jean Delvare wrote:
> > Dell-smbios is a helper module, it serves no purpose on its own, so
> > do not present it as an option to the user. Ins
n a few
systems. They decided that blacklisting the driver for everybody was
the easiest way to fix the problem. Of course this doesn't make any
sense and should be reverted. The root cause of the problem should have
been investigated back then. Maybe it's fixed by now and they will
never now.
* Add a few blank lines to improve readability.
* Don't call cut 3 times when once is enough.
* Drop a useless semicolon.
Signed-off-by: Jean Delvare
---
This patch was already sent on 2016-08-05.
scripts/Lindent | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
---
Dell-smbios is a helper module, it serves no purpose on its own, so
do not present it as an option to the user. Instead, select it
automatically whenever a driver which needs it is selected.
Signed-off-by: Jean Delvare
Cc: Michał Kępień
Cc: Pali Rohár
Cc: Darren Hart
---
Changes since v1
do not feel qualified to give advice
on the proper way. I trust you to make the right decision :-)
--
Jean Delvare
SUSE L3 Support
IFY_BOUND_DRIVER. I used exactly that, too, somewhen
> somewhere. Haven't checked if that helps here, too. And since we have
> a
> precedence (Fujitsu case), I'll leave it to Jean who is the maintainer
> of this driver.
I don't have a strong opinion on the matter, whatever works is fine
with me.
--
Jean Delvare
SUSE L3 Support
: Always show system identification string
Thanks,
--
Jean Delvare
SUSE L3 Support
Struct module is already declared at the beginning of the file, no
need to declare it again.
Signed-off-by: Jean Delvare
Fixes: 93c2e105f6bc ("module: Optimize __module_address() using a latched
RB-tree")
Cc: Peter Zijlstra (Intel)
Cc: Jessica Yu
Cc: Rusty Russell
---
include/linu
On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote:
> On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > I am no kexec expert but this confuses me. Shouldn't the second
> > > kernel have access to th
entry_point(void)
> {
> +#ifdef CONFIG_KEXEC
> + if (dmi_entry_point)
> + return dmi_entry_point;
> +#endif
> +
> if (efi_enabled(EFI_CONFIG_TABLES)) {
> /*
>* According to the DMTF SMBIOS reference spec v3.0.0, it is
--
Jean Delvare
SUSE L3 Support
p = dmi_early_remap(ep, 32);
> if (p == NULL)
> goto error;
> memcpy_fromio(buf, p, 32);
> dmi_early_unmap(p, 32);
>
> - if (!dmi_present(buf)) {
> + if (!dmi_smbios3_present(buf) || !dmi_present(buf)) {
> dmi_available = 1;
> goto out;
> }
--
Jean Delvare
SUSE L3 Support
#endif
Which basically means that pr_debug() has no effect unless debugging is
actually enabled, while printk(KERN_DEBUG ...) is always printed by the
kernel (with a log level which may or may not make it to a specific
output.)
--
Jean Delvare
SUSE L3 Support
consistency with the rest of the universe, the name should simply be
"ar1021". No other driver uses capitals, and the manufacturer name is
normally not included, except in very rare cases of incompatible name
collisions.
Thanks,
--
Jean Delvare
SUSE L3 Support
);
> + pr_info("DMI: %s\n", dmi_ids_string);
> return 0;
> }
> }
I agree. Applied, thanks.
--
Jean Delvare
SUSE L3 Support
On jeu., 2016-12-01 at 14:12 +, David Howells wrote:
> Jean Delvare wrote:
>
> > > Note that we do still need to do the module initialisation because some
> > > drivers have viable defaults set in case parameters aren't specified and
> > > some driver
rry, no pseudonyms or anonymous
contributions.)"
> Signed-off-by: David Howells
> cc: Wolfram Sang
> cc: Jean Delvare
> cc: linux-...@vger.kernel.org
> ---
>
> drivers/i2c/busses/i2c-elektor.c |6 +++---
> drivers/i2c/busses/i2c-parport-light.c |
; ...
> }
> result = 1;
> - goto out_buffer;
> + goto out_free_buffer;
> }
> ...
> out_free_buffer:
Oops, my bad. Good catch.
This driver is meant for Exynos systems so do not offer the option
elsewhere unless build-testing.
Signed-off-by: Jean Delvare
Cc: Inha Song
Cc: Beomho Seo
Cc: Sylwester Nawrocki
Cc: Lee Jones
---
drivers/mfd/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-4.9-rc0.orig/drivers
adapters (up to PIIX4_MAX_ADAPTERS).
> + * For devices supporting multiple ports the i2c_adapter should provide
> + * an i2c_algorithm to access them.
> + */
--
Jean Delvare
SUSE L3 Support
ingle patch. So, when you resubmit, please do so as a
single patch.
Thanks,
--
Jean Delvare
SUSE L3 Support
dev_err(&PIIX4_dev->dev,
> > + "Illegal Interrupt configuration "
> > "(or code out of date)!\n");
>
> typically, this format would be coalesced into a single line.
Especially when the patch claims to "fix quoted string split across
lines" :-D
--
Jean Delvare
SUSE L3 Support
Hi Guenter,
On Mon, 10 Oct 2016 16:48:22 -0700, Guenter Roeck wrote:
> On Fri, Oct 07, 2016 at 02:32:13PM +0200, Jean Delvare wrote:
> > On Tue, 4 Oct 2016 12:37:13 -0700, Guenter Roeck wrote:
> > > On Tue, Oct 04, 2016 at 10:45:59AM +0200, Jean Delvare wrote:
> > &g
Hi Guenter,
On Tue, 4 Oct 2016 12:37:13 -0700, Guenter Roeck wrote:
> On Tue, Oct 04, 2016 at 10:45:59AM +0200, Jean Delvare wrote:
> > I see this patch is upstream now, but I had started reviewing it and
> > maybe some of my comments are still relevant.
> >
> As
rmissions.
> + * If the return value is 0, no attribute will be created.
> + * @read: Read callback. Optional. If not provided, attributes
> + * will not be readable.
> + * Parameters are:
> + * @dev: Pointer to hardware monitoring device
> + *
ck
> ---
> v3: No change
> v2: Added patch
>
> drivers/hwmon/hwmon.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
OWLAN to make sure it was 92.
Would it make sense to explicitly set the enum values, or add them as
comments, to make such look-ups easier?
--
Jean Delvare
SUSE L3 Support
On Thu, 22 Sep 2016 10:49:47 -0700, Joe Perches wrote:
> On Thu, 2016-09-22 at 13:57 +0200, Jean Delvare wrote:
> > Sure. But I'm afraid you keep changing topics and I have no idea where
> > you are going. We started with "should there be a space before jump
> >
On Thu, 22 Sep 2016 14:11:03 +0100, Al Viro wrote:
> On Thu, Sep 22, 2016 at 01:57:58PM +0200, Jean Delvare wrote:
> > >
> > > MUST is much stronger language than I would prefer.
> >
> > That's what error means, really. When your compiler fails with an
&g
Hi Jani,
On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote:
> On Thu, 22 Sep 2016, Jean Delvare wrote:
> > You need to think in terms of actual use cases. Who uses checkpatch and
> > why? I think there are 3 groups of users:
> > * Beginners. They won't run the scr
On Thu, 22 Sep 2016 03:42:10 -0700, Joe Perches wrote:
> On Thu, 2016-09-22 at 11:24 +0200, Jean Delvare wrote:
> > I would rather suggest:
> >
> > ERROR -> MUST_FIX
> > WARNING -> SHOULD_FIX
> > CHECK -> MAY_FIX
>
> MUST is much stronger langua
kfree(foo);
> return ret;
There are 2 more occurrences after this point, which you probably want
to change too.
--
Jean Delvare
SUSE L3 Support
201 - 300 of 1633 matches
Mail list logo
