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
_entry(child, >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
(child, >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
> + strlcpy(prod_name, str, sizeof(prod_name));
> + dmi_ident[DMI_PRODUCT_NAME] = prod_name;
> +
> + return 0;
> +}
> +early_param("dmi_product_name", dmi_parse_dmi_product_name);
--
Jean Delvare
SUSE L3 Support
vice)
> }
> }
> 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, str, sizeof(prod_n
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 <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
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
; -#define SMBIOSIZE8
> +#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 <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
> +#define SMBIOSIZE9
>
> /* PCI Address Constants */
> #define SMBBA0x090
I checked all the datasheets I have access to, and it should be good.
Signed-off-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
ame attribute\n",
> + name);
May I suggest adding ", please fix"?
>
> id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> if (id < 0)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
Do I understand correctly that in the long run we will make it a fatal
error again?
--
Jean Delvare
SUSE L3 Support
ot;,
> + name);
May I suggest adding ", please fix"?
>
> id = ida_simple_get(_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
>
> 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
egion */
> -#define SMBIOSIZE8
> +#define SMBIOSIZE9
>
Are you certain that all supported devices have this extra register?
>
> /* PCI Address Constants */
> #define SMBBA0x090
--
Jean Delvare
SUSE L3 Support
IZE8
> +#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'
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'
re 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
re 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 Delvar
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 <jdelv...@suse.de>
Cc: Mika Westerberg <mika.westerb...@linux.intel.com>
Cc: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Cc: Linus Walleij <lin
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 built
List soft dependencies of cifs so that mkinitrd and dracut can include
the required helper modules.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Steve French <sfre...@samba.org>
---
fs/cifs/cifsfs.c | 12
1 file changed, 12 insertions(+)
--- linux-4.10-rc5.
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 <jdelv...@suse.de>
Cc: Steve French <sfre...@samba.org>
---
fs/cifs/Kconfig |5 +++--
1 fil
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 <jd
* 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: Steve
reply, so I am trying again.
Thanks,
--
Jean Delvare
SUSE L3 Support
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 other arc
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 other arc
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: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 <jdelv...@suse.de>
&
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: 8f1498
With a name like that, I assume that the ARM SCPI protocol is only
useful on the ARM architectures.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Fixes: 8f1498c03d15 ("firmware: arm_scpi: make it depend on MAILBOX instead of")
Cc: Sudeep Holla <sudeep.ho...@arm.com>
Cc:
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
nt first, 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 <jdelv...@suse.de>
---
* Note 1: I can't test the 64-bit ("_SM3_") entry point case. I
would appreciate if someone with a
nt first, 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 machine sup
or 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
or 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 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 <jdelv...@suse.de> wrote:
> > Dell-smbios is a helper module, it serves no purpose on its own, so
> > do not present it as an option
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.
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...
--
Je
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...
--
Je
* 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>
---
This patch was already sent on 2016-08-05.
scripts/Lindent | 14 +-
1 file changed, 9 insertions
* 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(-)
--- linux
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 <jdelv...@suse.de>
Cc: Michał Kępień <ker...@kempniu.pl>
Cc
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
el qualified to give advice
on the proper way. I trust you to make the right decision :-)
--
Jean Delvare
SUSE L3 Support
el 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
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
: 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 <jdelv...@suse.de>
Fixes: 93c2e105f6bc ("module: Optimize __module_address() using a latched
RB-tree")
Cc: Peter Zijlstra (Intel) <pet...@infradead.org
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 the EFI
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 the EFI
_get_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
gt; {
> +#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
efi.smbios, 32);
> + 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
_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
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
316 #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
lly 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
ABLE(i2c, ar1021_i2c_id);
For 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
nsistency 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_debug("DMI: %s\n", dmi_ids_string);
> + pr_info("DMI: %s\n", dmi_ids_string);
> return 0;
> }
> }
I agree. Applied, thanks.
--
Jean Delvare
SUSE L3 Support
t; + 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 <jdelv...@suse.de> 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
> &
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 drivers sup
t;using your real name (sorry, no pseudonyms or anonymous
contributions.)"
> Signed-off-by: David Howells <dhowe...@redhat.com>
> cc: Wolfram Sang <w...@the-dreams.de>
> cc: Jean Delvare <jdelv...@suse.com>
> cc: linux-...@vger.kernel.org
> ---
>
> driver
yms 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 |4 ++--
> dr
+++ b/Documentation/process/coding-style.rst
> @@ -475,7 +475,7 @@ The rationale for using gotos is:
> ...
> }
> result = 1;
> - goto out_buffer;
> + goto out_free_buffer;
> }
> ...
> out_free_buffer
; ...
> }
> 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 <jdelv...@suse.de>
Cc: Inha Song <ideal.s...@samsung.com>
Cc: Beomho Seo <beomho@samsung.com>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com&g
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
an register multiple i2c_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
i2c_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
So, when you resubmit, please do so as a
single patch.
Thanks,
--
Jean Delvare
SUSE L3 Support
So, when you resubmit, please do so as a
single patch.
Thanks,
--
Jean Delvare
SUSE L3 Support
"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
"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 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.
> >
>
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.
> >
>
will not be readable.
> + * Parameters are:
> + * @dev: Pointer to hardware monitoring device
> + * @type: Sensor type
> + * @attr: Sensor attribute
> + * @channel:
> + * Channel number
> + * @val: Pointer to returned value
> + * The function returns 0 on success or a negative error number.
> + * @write: Write callback. Optional. If not provided, attributes
> + * will not be writable.
> + * Parameters are:
> + * @dev: Pointer to hardware monitoring device
> + * @type: Sensor type
> + * @attr: Sensor attribute
> + * @channel:
> + * Channel number
> + * @val: Value to write
> + * The function returns 0 on success or a negative error number.
> + */
> +struct hwmon_ops {
> + umode_t (*is_visible)(const void *drvdata, enum hwmon_sensor_types type,
> + u32 attr, int channel);
> + int (*read)(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val);
> + int (*write)(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long val);
> +};
> +
> +/**
> + * Channel information
> + * @type:Channel type.
> + * @config: Pointer to NULL-terminated list of channel parameters.
> + * Use for per-channel attributes.
> + */
> +struct hwmon_channel_info {
> + enum hwmon_sensor_types type;
> + const u32 *config;
> +};
> +
> +/**
> + * Chip configuration
> + * @ops: Pointer to hwmon operations.
> + * @info:Null-terminated list of channel information.
> + */
> +struct hwmon_chip_info {
> + const struct hwmon_ops *ops;
> + const struct hwmon_channel_info **info;
> +};
> +
> struct device *hwmon_device_register(struct device *dev);
> struct device *
> hwmon_device_register_with_groups(struct device *dev, const char *name,
> @@ -26,6 +164,16 @@ struct device *
> devm_hwmon_device_register_with_groups(struct device *dev, const char *name,
> void *drvdata,
> const struct attribute_group **groups);
> +struct device *
> +hwmon_device_register_with_info(struct device *dev,
> + const char *name, void *drvdata,
> + const struct hwmon_chip_info *info,
> + const struct attribute_group **groups);
> +struct device *
> +devm_hwmon_device_register_with_info(struct device *dev,
> + const char *name, void *drvdata,
> + const struct hwmon_chip_info *info,
> + const struct attribute_group **groups);
>
> void hwmon_device_unregister(struct device *dev);
> void devm_hwmon_device_unregister(struct device *dev);
This is adding a 4th and 5th way to register a hwmon device. Starts
being a bit messy... Do you have any plans to get rid of some of the
other functions to make things more consistent and efficient?
--
Jean Delvare
SUSE L3 Support
Pointer to hardware monitoring device
> + * @type: Sensor type
> + * @attr: Sensor attribute
> + * @channel:
> + * Channel number
> + * @val: Pointer to returned value
> + * The function returns 0 on success or a negative error number.
> + * @write: Write callback. Optional. If not provided, attributes
> + * will not be writable.
> + * Parameters are:
> + * @dev: Pointer to hardware monitoring device
> + * @type: Sensor type
> + * @attr: Sensor attribute
> + * @channel:
> + * Channel number
> + * @val: Value to write
> + * The function returns 0 on success or a negative error number.
> + */
> +struct hwmon_ops {
> + umode_t (*is_visible)(const void *drvdata, enum hwmon_sensor_types type,
> + u32 attr, int channel);
> + int (*read)(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val);
> + int (*write)(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long val);
> +};
> +
> +/**
> + * Channel information
> + * @type:Channel type.
> + * @config: Pointer to NULL-terminated list of channel parameters.
> + * Use for per-channel attributes.
> + */
> +struct hwmon_channel_info {
> + enum hwmon_sensor_types type;
> + const u32 *config;
> +};
> +
> +/**
> + * Chip configuration
> + * @ops: Pointer to hwmon operations.
> + * @info:Null-terminated list of channel information.
> + */
> +struct hwmon_chip_info {
> + const struct hwmon_ops *ops;
> + const struct hwmon_channel_info **info;
> +};
> +
> struct device *hwmon_device_register(struct device *dev);
> struct device *
> hwmon_device_register_with_groups(struct device *dev, const char *name,
> @@ -26,6 +164,16 @@ struct device *
> devm_hwmon_device_register_with_groups(struct device *dev, const char *name,
> void *drvdata,
> const struct attribute_group **groups);
> +struct device *
> +hwmon_device_register_with_info(struct device *dev,
> + const char *name, void *drvdata,
> + const struct hwmon_chip_info *info,
> + const struct attribute_group **groups);
> +struct device *
> +devm_hwmon_device_register_with_info(struct device *dev,
> + const char *name, void *drvdata,
> + const struct hwmon_chip_info *info,
> + const struct attribute_group **groups);
>
> void hwmon_device_unregister(struct device *dev);
> void devm_hwmon_device_unregister(struct device *dev);
This is adding a 4th and 5th way to register a hwmon device. Starts
being a bit messy... Do you have any plans to get rid of some of the
other functions to make things more consistent and efficient?
--
Jean Delvare
SUSE L3 Support
ed-off-by: Guenter Roeck <li...@roeck-us.net>
> ---
> v3: No change
> v2: Added patch
>
> drivers/hwmon/hwmon.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
Roeck
> ---
> 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
t 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
t 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
> > label
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
> > label
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
401 - 500 of 3166 matches
Mail list logo
