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 <jdelv...@suse.de> 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
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 script b
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
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
kfree(foo);
> return ret;
There are 2 more occurrences after this point, which you probably want
to change too.
--
Jean Delvare
SUSE L3 Support
ce. This SHOULD
be fixed before the patch is submitted upstream, unless the maintainer
agreed otherwise."
Not sure if we need something for CHECK, as these messages are not
printed by default so I'd assume people who get them know what they
asked for. But apparently these confused Julia so maybe a similar
explanation would be needed for them too.
--
Jean Delvare
SUSE L3 Support
ce. This SHOULD
be fixed before the patch is submitted upstream, unless the maintainer
agreed otherwise."
Not sure if we need something for CHECK, as these messages are not
printed by default so I'd assume people who get them know what they
asked for. But apparently these confused Julia so maybe a similar
explanation would be needed for them too.
--
Jean Delvare
SUSE L3 Support
ell Linus suggested to improve the default, he was not opposed to the
change per se I think. But it was 5 years ago and nothing happened
since then, so I'd rather go with what is available today. Which means
either one space before labels, or drivers in .gitattributes. Choose
your poison ;-)
Thanks,
--
Jean Delvare
SUSE L3 Support
ell Linus suggested to improve the default, he was not opposed to the
change per se I think. But it was 5 years ago and nothing happened
since then, so I'd rather go with what is available today. Which means
either one space before labels, or drivers in .gitattributes. Choose
your poison ;-)
Thanks,
--
Jean Delvare
SUSE L3 Support
hecklist =>
> development-process/SubmitChecklist.rst} (98%)
> (...)
For the hwmon part:
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
gt;
> development-process/SubmitChecklist.rst} (98%)
> (...)
For the hwmon part:
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
On Tue, 13 Sep 2016 17:30:33 +0200, Ilya Dryomov wrote:
> On Tue, Sep 13, 2016 at 4:36 PM, Jean Delvare <jdelv...@suse.de> wrote:
> > On Tue, 13 Sep 2016 11:16:13 +0200, Ilya Dryomov wrote:
> >> Jon, could you please yank 865a1caa4b6b ("CodingStyle: Clarify and
> &
On Tue, 13 Sep 2016 17:30:33 +0200, Ilya Dryomov wrote:
> On Tue, Sep 13, 2016 at 4:36 PM, Jean Delvare wrote:
> > On Tue, 13 Sep 2016 11:16:13 +0200, Ilya Dryomov wrote:
> >> Jon, could you please yank 865a1caa4b6b ("CodingStyle: Clarify and
> >> complete chapter
abels (i.e. it doesn't handle
them properly.)
However, since then the issue was discussed somewhere else:
https://lkml.org/lkml/2016/9/5/214
As you can see, alternatives to indenting labels with one space were
found. Therefore you will soon be correct saying "the diff -p argument
is pretty moot." As soon as my patch hits mainline, actually. Which
shouldn't take too long as Andrew Morton picked it 4 days ago.
Once this happens, I'm fine with CodingStyle being updated again to
reflect the current situation.
Hope it clarifies,
--
Jean Delvare
SUSE L3 Support
properly.)
However, since then the issue was discussed somewhere else:
https://lkml.org/lkml/2016/9/5/214
As you can see, alternatives to indenting labels with one space were
found. Therefore you will soon be correct saying "the diff -p argument
is pretty moot." As soon as my patch hits mainline, actually. Which
shouldn't take too long as Andrew Morton picked it 4 days ago.
Once this happens, I'm fine with CodingStyle being updated again to
reflect the current situation.
Hope it clarifies,
--
Jean Delvare
SUSE L3 Support
structure after calling device_register
Thanks,
--
Jean Delvare
SUSE L3 Support
structure after calling device_register
Thanks,
--
Jean Delvare
SUSE L3 Support
The Zynq FPGA manager driver serves no purpose on other architectures
so hide it unless build-testing.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Acked-by: Moritz Fischer <moritz.fisc...@ettus.com>
Acked-by: Alan Tull <at...@opensource.altera.com>
Acked-by: Micha
The Zynq FPGA manager driver serves no purpose on other architectures
so hide it unless build-testing.
Signed-off-by: Jean Delvare
Acked-by: Moritz Fischer
Acked-by: Alan Tull
Acked-by: Michal Simek
Cc: "Sören Brinkmann"
---
Changes since v1:
* Rebased on top of v4.8-rc5.
I ha
x-4.7/.gitattributes2016-09-07 14:07:23.042138220 +0200
@@ -0,0 +1,2 @@
+*.c diff=cpp
+*.h diff=cpp
--
Jean Delvare
SUSE L3 Support
diff=cpp
--
Jean Delvare
SUSE L3 Support
Hi Peter,
On Tue, 6 Sep 2016 16:47:56 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > > xfuncname = "^[[:alpha:]$_].*[^:]$"
> >
> > OK, I see. As mentioned somewh
Hi Peter,
On Tue, 6 Sep 2016 16:47:56 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > > xfuncname = "^[[:alpha:]$_].*[^:]$"
> >
> > OK, I see. As mentioned somewh
Hi Peter,
On Mon, 5 Sep 2016 13:58:38 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> > On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > > I have it in my local .gitconfig, and recommend it to people who sen
Hi Peter,
On Mon, 5 Sep 2016 13:58:38 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> > On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > > I have it in my local .gitconfig, and recommend it to people who sen
On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> > Zijlstra reportedly changed the behavior of "diff -p" so that it
> > han
On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote:
> > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter
> > Zijlstra reportedly changed the behavior of "diff -p" so that it
> > han
And until this happens, my
preference for one-space-indented labels will remain.
Also git has its own implementation of "diff", so any change in the
behavior of GNU diff's -p and/or --show-c-function options should be
reflected there as well for consistency.
--
Jean Delvare
SUSE L3 Support
And until this happens, my
preference for one-space-indented labels will remain.
Also git has its own implementation of "diff", so any change in the
behavior of GNU diff's -p and/or --show-c-function options should be
reflected there as well for consistency.
--
Jean Delvare
SUSE L3 Support
" but it is arbitrary and
internal only at this point.
Maybe it's me getting old, but I tend to prefer using long options in
scripts now. I find it easier to read later, no need to remember what
the short options do nor look it up in the manual page.
--
Jean Delvare
SUSE L3 Support
" but it is arbitrary and
internal only at this point.
Maybe it's me getting old, but I tend to prefer using long options in
scripts now. I find it easier to read later, no need to remember what
the short options do nor look it up in the manual page.
--
Jean Delvare
SUSE L3 Support
Hi all,
On Wed, 31 Aug 2016 16:43:26 +0200, Greg KH wrote:
> On Wed, Aug 31, 2016 at 02:01:23PM +, mario_limoncie...@dell.com wrote:
> > Jean Delvare would rather see this implemented in userspace dmidecode.
> > Jean raised a concern in an earlier submission that thi
Hi all,
On Wed, 31 Aug 2016 16:43:26 +0200, Greg KH wrote:
> On Wed, Aug 31, 2016 at 02:01:23PM +, mario_limoncie...@dell.com wrote:
> > Jean Delvare would rather see this implemented in userspace dmidecode.
> > Jean raised a concern in an earlier submission that thi
On Mon, 29 Aug 2016 07:46:36 -0700, Guenter Roeck wrote:
> On 08/29/2016 03:11 AM, Jean Delvare wrote:
> > On Mon, 29 Aug 2016 12:06:34 +0200, Jean Delvare wrote:
> >> I'm trying to find when the bug was introduced. I have a hard time
> >> believing it went unnoticed
On Mon, 29 Aug 2016 07:46:36 -0700, Guenter Roeck wrote:
> On 08/29/2016 03:11 AM, Jean Delvare wrote:
> > On Mon, 29 Aug 2016 12:06:34 +0200, Jean Delvare wrote:
> >> I'm trying to find when the bug was introduced. I have a hard time
> >> believing it went unnoticed
On Mon, 29 Aug 2016 12:06:34 +0200, Jean Delvare wrote:
> I'm trying to find when the bug was introduced. I have a hard time
> believing it went unnoticed for long. If it fixes your problem I'll
> send a clean patch.
Broken by:
commit 52929715634ad36782bd7018ab0bf59a6619c393
Author
On Mon, 29 Aug 2016 12:06:34 +0200, Jean Delvare wrote:
> I'm trying to find when the bug was introduced. I have a hard time
> believing it went unnoticed for long. If it fixes your problem I'll
> send a clean patch.
Broken by:
commit 52929715634ad36782bd7018ab0bf59a6619c393
Author
ced for long. If it fixes your problem I'll
send a clean patch.
--
Jean Delvare
SUSE L3 Support
ced for long. If it fixes your problem I'll
send a clean patch.
--
Jean Delvare
SUSE L3 Support
Hi Joe,
On Fri, 05 Aug 2016 10:53:19 -0700, Joe Perches wrote:
> On Fri, 2016-08-05 at 11:26 +0200, Jean Delvare wrote:
> > * Add a few blank lines to improve readability.
> > * Don't call cut 3 times when once is enough.
> > * Drop a useless semicolon.
>
> As it c
Hi Joe,
On Fri, 05 Aug 2016 10:53:19 -0700, Joe Perches wrote:
> On Fri, 2016-08-05 at 11:26 +0200, Jean Delvare wrote:
> > * Add a few blank lines to improve readability.
> > * Don't call cut 3 times when once is enough.
> > * Drop a useless semicolon.
>
> As it c
* 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 <jdelv...@suse.de>
---
scripts/Lindent | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--- linux-4.7.orig/scripts/L
* 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
---
scripts/Lindent | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--- linux-4.7.orig/scripts/Lindent 2016-07-04 08
; <darrick.w...@oracle.com>");
> MODULE_DESCRIPTION("ACPI 4.0 power meter driver");
> MODULE_LICENSE("GPL");
>
> -module_param(force_cap_on, bool, 0644);
> +module_param(force_cap_on, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> MODULE_PARM_D
driver");
> MODULE_LICENSE("GPL");
>
> -module_param(force_cap_on, bool, 0644);
> +module_param(force_cap_on, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> MODULE_PARM_DESC(force_cap_on, "Enable power cap even it is unsafe to do
> so.");
>
> module_init(acpi_power_meter_init);
--
Jean Delvare
SUSE L3 Support
Hi Mario, Allen,
On Tue, 19 Jul 2016 14:47:57 +, mario_limoncie...@dell.com wrote:
> Hi Jean,
>
> I worked with Allen on this concept, so I've got some comments below.
>
> > -Original Message-----
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent:
Hi Mario, Allen,
On Tue, 19 Jul 2016 14:47:57 +, mario_limoncie...@dell.com wrote:
> Hi Jean,
>
> I worked with Allen on this concept, so I've got some comments below.
>
> > -Original Message-----
> > From: Jean Delvare [mailto:jdelv...@suse.de]
> > Sent:
"Host Notify handling failed: %d\n", ret);
>
> +out:
> /* clear Host Notify bit and return */
> outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
> return IRQ_HANDLED;
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
g failed: %d\n", ret);
>
> +out:
> /* clear Host Notify bit and return */
> outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
> return IRQ_HANDLED;
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
; https://github.com/lmajewski/linux-samsung-thermal.git
> F: drivers/thermal/samsung/
>
> SAMSUNG USB2 PHY DRIVER
> -M: Kamil Debski <k.deb...@samsung.com>
> +M: Kamil Debski <ka...@wypas.org>
> +M: Sylwester Nawrocki <s.nawro...@samsung.com>
> L: linux-kernel@vger.kernel.org
> S: Supported
> F: Documentation/devicetree/bindings/phy/samsung-phy.txt
Thank you.
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
tps://github.com/lmajewski/linux-samsung-thermal.git
> F: drivers/thermal/samsung/
>
> SAMSUNG USB2 PHY DRIVER
> -M: Kamil Debski
> +M: Kamil Debski
> +M: Sylwester Nawrocki
> L: linux-kernel@vger.kernel.org
> S: Supported
> F: Documentation/devicetree/bindings/phy/samsung-phy.txt
Thank you.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
On Thu, 28 Jul 2016 11:44:57 +0200, Benjamin Tissoires wrote:
> On Jul 18 2016 or thereabouts, Jean Delvare wrote:
> > On Fri, 24 Jun 2016 16:39:49 +0200, Benjamin Tissoires wrote:
> > > The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
> > > in
On Thu, 28 Jul 2016 11:44:57 +0200, Benjamin Tissoires wrote:
> On Jul 18 2016 or thereabouts, Jean Delvare wrote:
> > On Fri, 24 Jun 2016 16:39:49 +0200, Benjamin Tissoires wrote:
> > > The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
> > > in
Hi Benjamin,
On Fri, 29 Jul 2016 11:12:12 +0200, Jean Delvare wrote:
> On Thu, 28 Jul 2016 11:50:39 +0200, Benjamin Tissoires wrote:
> > +static void i801_disable_host_notify(struct i2c_adapter *adapter)
> > +{
> > + struct i801_priv *priv = i2c_get_adapdata(adapter);
>
Hi Benjamin,
On Fri, 29 Jul 2016 11:12:12 +0200, Jean Delvare wrote:
> On Thu, 28 Jul 2016 11:50:39 +0200, Benjamin Tissoires wrote:
> > +static void i801_disable_host_notify(struct i2c_adapter *adapter)
> > +{
> > + struct i801_priv *priv = i2c_get_adapdata(adapter);
>
jamin Tissoires <benjamin.tissoi...@redhat.com>
> ---
> drivers/i2c/busses/i2c-i801.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
Thanks,
--
Jean Delvare
SUSE L3 Support
jamin Tissoires
> ---
> drivers/i2c/busses/i2c-i801.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
l changes, cleanup only.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> ---
> drivers/i2c/busses/i2c-i801.c | 50
> +--
> 1 file changed, 25 insertions(+), 25 deletions(-)
> (...)
Reviewed-by: Jean Delvare
l changes, cleanup only.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/i2c/busses/i2c-i801.c | 50
> +--
> 1 file changed, 25 insertions(+), 25 deletions(-)
> (...)
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
E_SMBUS_PEC(1 << 0)
> #define FEATURE_BLOCK_BUFFER (1 << 1)
> #define FEATURE_BLOCK_PROC (1 << 2)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
TREN0x01
>
> #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
> @@ -269,8 +269,6 @@ struct i801_priv {
> struct smbus_host_notify *host_notify;
> };
>
> -#define SMBHSTNTFY_SIZE 8
> -
> #define FEATURE_SMBUS_PEC(1 << 0)
> #de
adapter
> diff --git a/include/linux/i2c-smbus.h b/include/linux/i2c-smbus.h
> index c2e3324..ac02827 100644
> --- a/include/linux/i2c-smbus.h
> +++ b/include/linux/i2c-smbus.h
> @@ -76,5 +76,6 @@ struct smbus_host_notify {
> struct smbus_host_notify *i2c_setup_smbus_host_notify(struct i2c_adapter
> *adap);
> int i2c_handle_smbus_host_notify(struct smbus_host_notify *host_notify,
>unsigned short addr, unsigned int data);
> +void i2c_cancel_smbus_host_notify(struct smbus_host_notify *host_notify);
>
> #endif /* _LINUX_I2C_SMBUS_H */
--
Jean Delvare
SUSE L3 Support
e/linux/i2c-smbus.h
> index c2e3324..ac02827 100644
> --- a/include/linux/i2c-smbus.h
> +++ b/include/linux/i2c-smbus.h
> @@ -76,5 +76,6 @@ struct smbus_host_notify {
> struct smbus_host_notify *i2c_setup_smbus_host_notify(struct i2c_adapter
> *adap);
> int i2c_handle_smbus_host_notify(struct smbus_host_notify *host_notify,
>unsigned short addr, unsigned int data);
> +void i2c_cancel_smbus_host_notify(struct smbus_host_notify *host_notify);
>
> #endif /* _LINUX_I2C_SMBUS_H */
--
Jean Delvare
SUSE L3 Support
Hi Viresh,
On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote:
> On 25-07-16, 11:39, Jean Delvare wrote:
> > The problem is that the patch proposed by Viresh has nothing to do with
> > this. It's not adding notifications, just changing the time frame during
> > w
Hi Viresh,
On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote:
> On 25-07-16, 11:39, Jean Delvare wrote:
> > The problem is that the patch proposed by Viresh has nothing to do with
> > this. It's not adding notifications, just changing the time frame during
> > w
1 file changed, 18 insertions(+), 2 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
I leave the final ack to Guenter.
--
Jean Delvare
SUSE L3 Support
this command.
> For this reason, the status register check is disabled for these controllers.
>
> Signed-off-by: Vadim Pasternak
> Reviewed-by: Jiri Pirko
> ---
> drivers/hwmon/pmbus/pmbus.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
> (...)
ed, or they are correct and you should not touch them.
>
> Do you find such changes worthwhile (without touching also any surrounding
> source code)?
You keep asking more and more from me. May I remind you this is your
"project" in the first place, not mine? If you have no idea what
ed, or they are correct and you should not touch them.
>
> Do you find such changes worthwhile (without touching also any surrounding
> source code)?
You keep asking more and more from me. May I remind you this is your
"project" in the first place, not mine? If you have no idea what
ernel/2106190
Personally I see no value in such statistics. Either labels are wrong
(either wrong indentation or wrong name) and should be fixed, or they
are correct and you should not touch them. Whether the same label name
is used somewhere else is irrelevant. Labels are local by nature, so
uniqueness isn't a goal at all, only correctness.
--
Jean Delvare
SUSE L3 Support
ernel/2106190
Personally I see no value in such statistics. Either labels are wrong
(either wrong indentation or wrong name) and should be fixed, or they
are correct and you should not touch them. Whether the same label name
is used somewhere else is irrelevant. Labels are local by nature, so
uniqueness isn't a goal at all, only correctness.
--
Jean Delvare
SUSE L3 Support
label position in osc_get_info()
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c71d264543f759fea147734cb63de36397817534
> https://lkml.org/lkml/2015/12/21/401
Intending labels with a tab is wrong, so fixing it is welcome. I'd turn
the tab into a space instead, for reasons explained before, but no
indentation at all is still better than a tab.
--
Jean Delvare
SUSE L3 Support
label position in osc_get_info()
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c71d264543f759fea147734cb63de36397817534
> https://lkml.org/lkml/2015/12/21/401
Intending labels with a tab is wrong, so fixing it is welcome. I'd turn
the tab into a space instead, for reasons explained before, but no
indentation at all is still better than a tab.
--
Jean Delvare
SUSE L3 Support
Chapter 7 (Centralized exiting of functions) of the coding style
documentation is unclear at times, and lacks some information (such
as the possibility to indent labels with a single space.) Clarify and
complete it.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Markus Elfring
Chapter 7 (Centralized exiting of functions) of the coding style
documentation is unclear at times, and lacks some information (such
as the possibility to indent labels with a single space.) Clarify and
complete it.
Signed-off-by: Jean Delvare
Cc: Markus Elfring
Cc: Jonathan Corbet
Hi Greg, Viresh,
On Mon, 11 Jul 2016 14:50:58 -0700, Greg KH wrote:
> On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> > So you are basically building a test case to cause the problem. It's
> > artificial. The adapter reference being held while the device node is
Hi Greg, Viresh,
On Mon, 11 Jul 2016 14:50:58 -0700, Greg KH wrote:
> On Mon, Jul 11, 2016 at 02:22:09PM +0200, Jean Delvare wrote:
> > So you are basically building a test case to cause the problem. It's
> > artificial. The adapter reference being held while the device node is
},
> {"bmr453", 1},
> {"bmr454", 1},
> + {"dps460", 1},
> + {"dps800", 1},
> {"mdt040", 1},
> {"ncp4200", 1},
> {"ncp4208", 1},
> @@ -193,6 +209,7 @@ static const struct i2c_device_id pmbus_id[] = {
> {"pdt006", 1},
> {"pdt012", 1},
> {"pmbus", 0},
> + {"sgd009", 1},
> {"tps40400", 1},
> {"tps544b20", 1},
> {"tps544b25", 1},
(non-authoritative)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
bmr454", 1},
> + {"dps460", 1},
> + {"dps800", 1},
> {"mdt040", 1},
> {"ncp4200", 1},
> {"ncp4208", 1},
> @@ -193,6 +209,7 @@ static const struct i2c_device_id pmbus_id[] = {
> {"pdt006", 1},
> {"pdt012", 1},
> {"pmbus", 0},
> + {"sgd009", 1},
> {"tps40400", 1},
> {"tps544b20", 1},
> {"tps544b25", 1},
(non-authoritative)
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
t; - defined CONFIG_DMI
> +#if IS_ENABLED(CONFIG_I2C_MUX_GPIO) && defined CONFIG_DMI
> static struct i801_mux_config i801_mux_config_asus_z8_d12 = {
> .gpio_chip = "gpio_ich",
> .values = { 0x02, 0x03 },
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
efined CONFIG_DMI
> +#if IS_ENABLED(CONFIG_I2C_MUX_GPIO) && defined CONFIG_DMI
> static struct i801_mux_config i801_mux_config_asus_z8_d12 = {
> .gpio_chip = "gpio_ich",
> .values = { 0x02, 0x03 },
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
Hi Greg,
On Thu, 14 Jul 2016 15:47:35 +0900, Greg KH wrote:
> On Wed, Jul 13, 2016 at 03:46:14PM +0200, Jean Delvare wrote:
> > Hi all,
> >
> > I am currently working on the i2c-dev driver, which has just been
> > converted to the non-ancestral cdev API. As I am cl
Hi Greg,
On Thu, 14 Jul 2016 15:47:35 +0900, Greg KH wrote:
> On Wed, Jul 13, 2016 at 03:46:14PM +0200, Jean Delvare wrote:
> > Hi all,
> >
> > I am currently working on the i2c-dev driver, which has just been
> > converted to the non-ancestral cdev API. As I am cl
abel renaming?
Renaming from "out0:", "out1:" etc to something meaningful, yes. Did
you have anything else in mind?
--
Jean Delvare
SUSE L3 Support
abel renaming?
Renaming from "out0:", "out1:" etc to something meaningful, yes. Did
you have anything else in mind?
--
Jean Delvare
SUSE L3 Support
Hi Paul,
On Tue, 19 Jul 2016 09:44:40 -0400, Paul Gortmaker wrote:
> [Re: [PATCH] Revert "pinctrl: amd: make it explicitly non-modular"] On
> 19/07/2016 (Tue 10:46) Jean Delvare wrote:
> > On Mon, 18 Jul 2016 20:30:30 -0400, Paul Gortmaker wrote:
>
Hi Paul,
On Tue, 19 Jul 2016 09:44:40 -0400, Paul Gortmaker wrote:
> [Re: [PATCH] Revert "pinctrl: amd: make it explicitly non-modular"] On
> 19/07/2016 (Tue 10:46) Jean Delvare wrote:
> > On Mon, 18 Jul 2016 20:30:30 -0400, Paul Gortmaker wrote:
>
on, which should be fixed. One space before label is the way
to go.
> > Quoting Jean Delvare:
I'm honored :)
> > "> It is generally accepted to indent labels with a single space. This
> > > avoids breaking the -p option of diff."
>
> Would you like to tak
on, which should be fixed. One space before label is the way
to go.
> > Quoting Jean Delvare:
I'm honored :)
> > "> It is generally accepted to indent labels with a single space. This
> > > avoids breaking the -p option of diff."
>
> Would you like to tak
vice_attribute dev_attr_tmpl =
> + __ATTR(, 0444, sys_dmi_oem_show, NULL);
I'd be very careful about permissions. OEM strings could contain pretty
much everything, including serial numbers or passwords. Making these
files world-readable doesn't strike me as the best of the ideas.
--
Jean Delvare
SUSE L3 Support
=
> + __ATTR(, 0444, sys_dmi_oem_show, NULL);
I'd be very careful about permissions. OEM strings could contain pretty
much everything, including serial numbers or passwords. Making these
files world-readable doesn't strike me as the best of the ideas.
--
Jean Delvare
SUSE L3 Support
> That is commit 337ea0fb1535 ("pinctrl: Turn AMD support to tristate")
I can't find this commit anywhere, but I would certainly prefer this to
making the driver non-modular. So I vote in favor of this revert.
Acked-by: Jean Delvare <jdelv...@suse.de>
Thanks,
--
Jean Delvare
SUSE L3 Support
> That is commit 337ea0fb1535 ("pinctrl: Turn AMD support to tristate")
I can't find this commit anywhere, but I would certainly prefer this to
making the driver non-modular. So I vote in favor of this revert.
Acked-by: Jean Delvare
Thanks,
--
Jean Delvare
SUSE L3 Support
On Mon, 18 Jul 2016 18:35:19 +0200, Benjamin Tissoires wrote:
> On Jul 18 2016 or thereabouts, Jean Delvare wrote:
> > But what happens on i2c_adapter removal? What prevents the following
> > sequence from happening?
> >
> > 1* A Host Notify event happens.
> > 2
On Mon, 18 Jul 2016 18:35:19 +0200, Benjamin Tissoires wrote:
> On Jul 18 2016 or thereabouts, Jean Delvare wrote:
> > But what happens on i2c_adapter removal? What prevents the following
> > sequence from happening?
> >
> > 1* A Host Notify event happens.
> > 2
;
> return 0;
>
> -fail_free_dmi_dev:
> - kfree(dmi_dev);
> -fail_class_unregister:
> +fail_put_dmi_dev:
> + put_device(dmi_dev);
>
> +fail_class_unregister:
> class_unregister(_class);
>
> return ret;
Good catch. Applied, thanks.
--
Jean Delvare
SUSE L3 Support
gt; -fail_free_dmi_dev:
> - kfree(dmi_dev);
> -fail_class_unregister:
> +fail_put_dmi_dev:
> + put_device(dmi_dev);
>
> +fail_class_unregister:
> class_unregister(_class);
>
> return ret;
Good catch. Applied, thanks.
--
Jean Delvare
SUSE L3 Support
On Mon, 18 Jul 2016 17:59:02 +0200, Benjamin Tissoires wrote:
> On Jul 18 2016 or thereabouts, Jean Delvare wrote:
> > You provide stubs for SMBus Host Notify support if CONFIG_I2C_SMBUS is
> > not selected. There are no such stubs for SMBus Alert support, for which
> > I
501 - 600 of 3166 matches
Mail list logo
