On Wed, Jun 20, 2018 at 04:43:14PM -0700, Kees Cook wrote:
> On Wed, Jun 20, 2018 at 4:37 PM, Darren Hart wrote:
> > On Wed, Jun 20, 2018 at 02:31:41PM -0700, Kees Cook wrote:
> >> The probe handler_data was being allocated with __get_free_pages()
> >> for no reason I
ree_pages((unsigned long)wblock->handler_data,
> -get_order(wblock->req_buf_size));
> + kfree(wblock->handler_data);
> }
>
> if (wdriver->remove)
> --
> 2.17.1
>
>
> --
> Kees Cook
> Pixel Security
>
--
Darren Hart
VMware Open Source Technology Center
ree_pages((unsigned long)wblock->handler_data,
> -get_order(wblock->req_buf_size));
> + kfree(wblock->handler_data);
> }
>
> if (wdriver->remove)
> --
> 2.17.1
>
>
> --
> Kees Cook
> Pixel Security
>
--
Darren Hart
VMware Open Source Technology Center
ng
queue. Once the builds complete, I'll move these to for-next.
Vadim, I see you've already updated the kernel version in the sys documentation
to 4.19, so I won't attempt to push these into the 4.18 RC cycle.
--
Darren Hart
VMware Open Source Technology Center
ng
queue. Once the builds complete, I'll move these to for-next.
Vadim, I see you've already updated the kernel version in the sys documentation
to 4.19, so I won't attempt to push these into the 4.18 RC cycle.
--
Darren Hart
VMware Open Source Technology Center
to 26ed9d1c07efa5c3a3810dbb7c668e132e91d426:
platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen
(2018-06-08 14:22:15 +0300)
Thanks,
Darren Hart
VMware Open Source Technology Center
platform-drivers-x86 for v4.18
to 26ed9d1c07efa5c3a3810dbb7c668e132e91d426:
platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen
(2018-06-08 14:22:15 +0300)
Thanks,
Darren Hart
VMware Open Source Technology Center
platform-drivers-x86 for v4.18
Thank you Stephen. We caught this earlier, but failed to remove it from for-next
while repairing the series. Our apologies. I have removed this series back to
the known good patch in for-next:
26ed9d1 platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen
Andy has this reworked already and is working on completing
testing before pushing the update to for-next.
--
Darren Hart
VMware Open Source Technology Center
Thank you Stephen. We caught this earlier, but failed to remove it from for-next
while repairing the series. Our apologies. I have removed this series back to
the known good patch in for-next:
26ed9d1 platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen
Andy has this reworked already and is working on completing
testing before pushing the update to for-next.
--
Darren Hart
VMware Open Source Technology Center
+ smi_data_buf_size = (unsigned long) min(eps->num_of_4k_pages * 4096
> > - 8,
> > + (u64) ULONG_MAX);
>
> This is too twisted code. First, it needs explanation.
> Second, it might need some refactoring.
>
> (Yes, I got the idea, but would it be better implementation?)
>
> > + max_smi_data_buf_size = smi_data_buf_size;
> > + wsmt_enabled = true;
> > + dev_info(_pdev->dev,
> > +"WSMT found, using firmware-provided SMI buffer.\n");
> > + return 1;
> > +}
>
> > #define SMI_CMD_MAGIC (0x534D4931)
> >
> > +#define SMM_EPS_SIG"$SCB"
>
> Just integer like above and put the sting as a comment.
> (Side note: above magic also looks like string)
Given the above, I think we can use the more recognizable string - since
that is clearly how they think of this label.
Otherwise, agree with a follow-up to all of Andy's feedback.
--
Darren Hart
VMware Open Source Technology Center
+ smi_data_buf_size = (unsigned long) min(eps->num_of_4k_pages * 4096
> > - 8,
> > + (u64) ULONG_MAX);
>
> This is too twisted code. First, it needs explanation.
> Second, it might need some refactoring.
>
> (Yes, I got the idea, but would it be better implementation?)
>
> > + max_smi_data_buf_size = smi_data_buf_size;
> > + wsmt_enabled = true;
> > + dev_info(_pdev->dev,
> > +"WSMT found, using firmware-provided SMI buffer.\n");
> > + return 1;
> > +}
>
> > #define SMI_CMD_MAGIC (0x534D4931)
> >
> > +#define SMM_EPS_SIG"$SCB"
>
> Just integer like above and put the sting as a comment.
> (Side note: above magic also looks like string)
Given the above, I think we can use the more recognizable string - since
that is clearly how they think of this label.
Otherwise, agree with a follow-up to all of Andy's feedback.
--
Darren Hart
VMware Open Source Technology Center
cycle being handled in the kernel.
2) Why is a module option preferable to a compile time option? It seems
to me the policy will be largely distro dependent, and the same kernel
needing to support both modes seems likely to be pretty rare.
--
Darren Hart
VMware Open Source Technology Center
cycle being handled in the kernel.
2) Why is a module option preferable to a compile time option? It seems
to me the policy will be largely distro dependent, and the same kernel
needing to support both modes seems likely to be pretty rare.
--
Darren Hart
VMware Open Source Technology Center
> Signed-off-by: Vadim Pasternak
No further comments on patch 7 or 8. Thanks for the updates.
--
Darren Hart
VMware Open Source Technology Center
> Signed-off-by: Vadim Pasternak
No further comments on patch 7 or 8. Thanks for the updates.
--
Darren Hart
VMware Open Source Technology Center
r = mlxreg_io_attr_init(priv);
> + if (err) {
> + dev_err(>pdev->dev, "Failed to allocate attributes: %d\n",
> + err);
> + return err;
> + }
> +
> + priv->hwmon = devm_hwmon_device_register_with_groups(>dev,
> + "mlxreg_io",
> + priv,
> + priv->groups);
> + if (IS_ERR(priv->hwmon)) {
> + dev_err(>dev, "Failed to register hwmon device %ld\n",
> + PTR_ERR(priv->hwmon));
> + return PTR_ERR(priv->hwmon);
> + }
> +
> + dev_set_drvdata(>dev, priv);
> +
> + return 0;
> +}
> +
> +static struct platform_driver mlxreg_io_driver = {
> + .driver = {
> + .name = "mlxreg-io",
> + },
> + .probe = mlxreg_io_probe,
> +};
> +
> +module_platform_driver(mlxreg_io_driver);
> +
> +MODULE_AUTHOR("Vadim Pasternak ");
> +MODULE_DESCRIPTION("Mellanox regmap I/O access driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:mlxreg-io");
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
r = mlxreg_io_attr_init(priv);
> + if (err) {
> + dev_err(>pdev->dev, "Failed to allocate attributes: %d\n",
> + err);
> + return err;
> + }
> +
> + priv->hwmon = devm_hwmon_device_register_with_groups(>dev,
> + "mlxreg_io",
> + priv,
> + priv->groups);
> + if (IS_ERR(priv->hwmon)) {
> + dev_err(>dev, "Failed to register hwmon device %ld\n",
> + PTR_ERR(priv->hwmon));
> + return PTR_ERR(priv->hwmon);
> + }
> +
> + dev_set_drvdata(>dev, priv);
> +
> + return 0;
> +}
> +
> +static struct platform_driver mlxreg_io_driver = {
> + .driver = {
> + .name = "mlxreg-io",
> + },
> + .probe = mlxreg_io_probe,
> +};
> +
> +module_platform_driver(mlxreg_io_driver);
> +
> +MODULE_AUTHOR("Vadim Pasternak ");
> +MODULE_DESCRIPTION("Mellanox regmap I/O access driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:mlxreg-io");
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
ister(_driver);
> > }
> > diff --git a/drivers/firmware/dcdbas.h b/drivers/firmware/dcdbas.h
> > index ca3cb0a54ab6..7ea5b3e070b9 100644
> > --- a/drivers/firmware/dcdbas.h
> > +++ b/drivers/firmware/dcdbas.h
> > @@ -54,6 +54,8 @@
> >
> > #define SMI_CMD_MAGIC (0x534D4931)
> >
> > +#define SMM_EPS_SIG"$SCB"
> > +
> > #define DCDBAS_DEV_ATTR_RW(_name) \
> > DEVICE_ATTR(_name,0600,_name##_show,_name##_store);
> >
> > @@ -103,5 +105,14 @@ struct apm_cmd {
> >
> > int dcdbas_smi_request(struct smi_cmd *smi_cmd);
> >
> > +struct smm_eps_table {
> > + char smm_comm_buff_anchor[4];
> > + u8 length;
> > + u8 checksum;
> > + u8 version;
> > + u64 smm_comm_buff_addr;
> > + u64 num_of_4k_pages;
> > +} __packed;
> > +
> > #endif /* _DCDBAS_H_ */
> >
> > --
> > 2.14.2
>
> Darren, Andy,
>
> Stuart and I were hoping you guys could bring this through the
> platform-driver-x86 tree.
> The logic behind this is that the only consumer for dcdbas in kernel is
> dell-smbios.
>
> There isn't a subsystem maintainer for someone to pull in dcdbas even though
> the
> current maintainer (Doug W) has acked it.
Apologies for the delay. I'm OK bringing it in in general. I'm reviewing patches
today and tomorrow to try and close out the backlog. Should have a review by EOD
tomorrow.
I've been wondering about drivers/firmware anyway - that is almost by definition
platform specific and might make more sense as part of the platform drivers,
especially if it is currently without a maintainer (although akpm will often
take such things).
--
Darren Hart
VMware Open Source Technology Center
ister(_driver);
> > }
> > diff --git a/drivers/firmware/dcdbas.h b/drivers/firmware/dcdbas.h
> > index ca3cb0a54ab6..7ea5b3e070b9 100644
> > --- a/drivers/firmware/dcdbas.h
> > +++ b/drivers/firmware/dcdbas.h
> > @@ -54,6 +54,8 @@
> >
> > #define SMI_CMD_MAGIC (0x534D4931)
> >
> > +#define SMM_EPS_SIG"$SCB"
> > +
> > #define DCDBAS_DEV_ATTR_RW(_name) \
> > DEVICE_ATTR(_name,0600,_name##_show,_name##_store);
> >
> > @@ -103,5 +105,14 @@ struct apm_cmd {
> >
> > int dcdbas_smi_request(struct smi_cmd *smi_cmd);
> >
> > +struct smm_eps_table {
> > + char smm_comm_buff_anchor[4];
> > + u8 length;
> > + u8 checksum;
> > + u8 version;
> > + u64 smm_comm_buff_addr;
> > + u64 num_of_4k_pages;
> > +} __packed;
> > +
> > #endif /* _DCDBAS_H_ */
> >
> > --
> > 2.14.2
>
> Darren, Andy,
>
> Stuart and I were hoping you guys could bring this through the
> platform-driver-x86 tree.
> The logic behind this is that the only consumer for dcdbas in kernel is
> dell-smbios.
>
> There isn't a subsystem maintainer for someone to pull in dcdbas even though
> the
> current maintainer (Doug W) has acked it.
Apologies for the delay. I'm OK bringing it in in general. I'm reviewing patches
today and tomorrow to try and close out the backlog. Should have a review by EOD
tomorrow.
I've been wondering about drivers/firmware anyway - that is almost by definition
platform specific and might make more sense as part of the platform drivers,
especially if it is currently without a maintainer (although akpm will often
take such things).
--
Darren Hart
VMware Open Source Technology Center
gt; dimming / auto-off of the kbd backlight when the no keys are
> touched for x seconds. This would seriously get in the way of that.
>
> So sorry, but NACK to this series.
So if instead of modifying the LED value, the kernel platform drivers
converted the TOGGLE into a cycle even by conve
gt; dimming / auto-off of the kbd backlight when the no keys are
> touched for x seconds. This would seriously get in the way of that.
>
> So sorry, but NACK to this series.
So if instead of modifying the LED value, the kernel platform drivers
converted the TOGGLE into a cycle even by conve
(code == NOTIFY_KBD_BRTDWN) {
kbd_led_set(>kbd_led, asus->kbd_led_wk - 1);
goto exit;
}
if (code == NOTIFY_KBD_BRTUP) {
kbd_led_set(>kbd_led, asus->kbd_led_wk + 1);
goto exit;
}
> if (is_display_toggle(code) &&
> asus->driver->quirks->no_display_toggle)
> goto exit;
> --
> 2.11.0
>
>
--
Darren Hart
VMware Open Source Technology Center
(code == NOTIFY_KBD_BRTDWN) {
kbd_led_set(>kbd_led, asus->kbd_led_wk - 1);
goto exit;
}
if (code == NOTIFY_KBD_BRTUP) {
kbd_led_set(>kbd_led, asus->kbd_led_wk + 1);
goto exit;
}
> if (is_display_toggle(code) &&
> asus->driver->quirks->no_display_toggle)
> goto exit;
> --
> 2.11.0
>
>
--
Darren Hart
VMware Open Source Technology Center
rectly show the OSD when this is done.
This makes sense. Userspace can't be aware of every platforms sys files,
so there needs to be a common mechanism. LED_BRIGHT_HW_CHANGED makes
sense.
--
Darren Hart
VMware Open Source Technology Center
rectly show the OSD when this is done.
This makes sense. Userspace can't be aware of every platforms sys files,
so there needs to be a common mechanism. LED_BRIGHT_HW_CHANGED makes
sense.
--
Darren Hart
VMware Open Source Technology Center
:May 2018
> +KernelVersion: 4.18
> +Contact: Vadim Pasternak
> +Description: These files allow assert system's power cycling and PS units
> + on/off switching.
This Description is awkward. Consider:
These files allow asserting system power cycling and switching power
supply units on and off.
> + The files are write only.
Please provide usage and resulting behavior.
--
Darren Hart
VMware Open Source Technology Center
:May 2018
> +KernelVersion: 4.18
> +Contact: Vadim Pasternak
> +Description: These files allow assert system's power cycling and PS units
> + on/off switching.
This Description is awkward. Consider:
These files allow asserting system power cycling and switching power
supply units on and off.
> + The files are write only.
Please provide usage and resulting behavior.
--
Darren Hart
VMware Open Source Technology Center
iv)
...
> + for (i = 0; i < priv->pdata->counter; i++) {
> + priv->mlxreg_io_attr[i] =
> + >mlxreg_io_dev_attr[i].dev_attr.attr;
> + memcpy(>mlxreg_io_dev_attr[i].dev_attr,
> +_io_devattr_rw, sizeof(struct device_attribute));
> +
> + /* Set attribute name as a label. */
:-) OK, so this comment is rather obvious from the code but where
things are really opaque in the processing above, there are no comments.
Let's focus the comments where the code is non-obvious.
--
Darren Hart
VMware Open Source Technology Center
iv)
...
> + for (i = 0; i < priv->pdata->counter; i++) {
> + priv->mlxreg_io_attr[i] =
> + >mlxreg_io_dev_attr[i].dev_attr.attr;
> + memcpy(>mlxreg_io_dev_attr[i].dev_attr,
> +_io_devattr_rw, sizeof(struct device_attribute));
> +
> + /* Set attribute name as a label. */
:-) OK, so this comment is rather obvious from the code but where
things are really opaque in the processing above, there are no comments.
Let's focus the comments where the code is non-obvious.
--
Darren Hart
VMware Open Source Technology Center
are defined per system type bases and includes the registers
> > > > related
> > > > + to system resets operation, system reset causes monitoring
> > > > and some
> > > > + kinds of mux selection.
> > >
> > > No Documentation/ABI/ entries for these new sysfs files? Not good :(
> > >
> >
> > Thanks Greg for your comment.
> >
> > Should I call doc file like:
> > Documentation/ABI/stable/sysfs-driver-mlxreg-io
> > ?
>
> What ever matches the naming scheme for the driver, yes.
Vadim, I'm happy to help out with the docs if you like.
Will you be able to document this in a static way, or is this likely to change
significantly from platform to platform? I ask because of the automated
attribute creation in the code.
--
Darren Hart
VMware Open Source Technology Center
are defined per system type bases and includes the registers
> > > > related
> > > > + to system resets operation, system reset causes monitoring
> > > > and some
> > > > + kinds of mux selection.
> > >
> > > No Documentation/ABI/ entries for these new sysfs files? Not good :(
> > >
> >
> > Thanks Greg for your comment.
> >
> > Should I call doc file like:
> > Documentation/ABI/stable/sysfs-driver-mlxreg-io
> > ?
>
> What ever matches the naming scheme for the driver, yes.
Vadim, I'm happy to help out with the docs if you like.
Will you be able to document this in a static way, or is this likely to change
significantly from platform to platform? I ask because of the automated
attribute creation in the code.
--
Darren Hart
VMware Open Source Technology Center
r Darren's queue, but for some reason
> didn't processed yet.
Thanks for getting this one Andy. I'm traveling, but am working through these
currently. I'll assume you are handling this one.
--
Darren Hart
VMware Open Source Technology Center
r Darren's queue, but for some reason
> didn't processed yet.
Thanks for getting this one Andy. I'm traveling, but am working through these
currently. I'll assume you are handling this one.
--
Darren Hart
VMware Open Source Technology Center
ant the
> "gitk" invocation if you are doing this automatically, of course. The
> script just takes a commit range.
Thanks for sharing Stephen.
--
Darren Hart
VMware Open Source Technology Center
ant the
> "gitk" invocation if you are doing this automatically, of course. The
> script just takes a commit range.
Thanks for sharing Stephen.
--
Darren Hart
VMware Open Source Technology Center
On Sat, May 26, 2018 at 11:15:35AM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, May 25, 2018 3:31 AM
> > To: Vadim Pasternak <vad...@mellanox.com>
&g
On Sat, May 26, 2018 at 11:15:35AM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, May 25, 2018 3:31 AM
> > To: Vadim Pasternak
> > Cc: andy.shevche...@gmail.com; gre...
).
Took a looking at linux-next today, I didn't see it. Anything else needed to get
this queued up? We'd love to get this in the 4.18 merge window, and stable if
possible.
--
Darren Hart
VMware Open Source Technology Center
ial media who has also confirmed this
to solve
her camera issue with her Dell XPS 13 (I didn't get the specific model).
Took a looking at linux-next today, I didn't see it. Anything else needed to get
this queued up? We'd love to get this in the 4.18 merge window, and stable if
possible.
--
Darren Hart
VMware Open Source Technology Center
mlxreg_io_attr_show;
> + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> + mlxreg_io_attr_store;
> + break;
If this is necessary, we can simplify this by checking for the read mask and the
write mask and setting each once - rather than duplicating this for r, w, and
rw. As it is a 0400 would not assign the show function, even though it is
readable by somebody.
--
Darren Hart
VMware Open Source Technology Center
mlxreg_io_attr_show;
> + priv->mlxreg_io_dev_attr[i].dev_attr.store =
> + mlxreg_io_attr_store;
> + break;
If this is necessary, we can simplify this by checking for the read mask and the
write mask and setting each once - rather than duplicating this for r, w, and
rw. As it is a 0400 would not assign the show function, even though it is
readable by somebody.
--
Darren Hart
VMware Open Source Technology Center
unctions from mlxreg.h file;
Please remember to put the patch changelog below the --- line below.
> ---
Here
Queued up for testing, thanks.
--
Darren Hart
VMware Open Source Technology Center
file;
Please remember to put the patch changelog below the --- line below.
> ---
Here
Queued up for testing, thanks.
--
Darren Hart
VMware Open Source Technology Center
sider dependencies.
I've fixed the sha in the commit message, and queued for testing.
Thanks,
--
Darren Hart
VMware Open Source Technology Center
sider dependencies.
I've fixed the sha in the commit message, and queued for testing.
Thanks,
--
Darren Hart
VMware Open Source Technology Center
ing for this Kconfig to try and catch
more of this - and of course I've learned a few things to look out for
as well.
Thanks,
Darren Hart
VMware Open Source Technology Center
The following changes since commit 7fe3fa3b5ec8e75389cce4bf5d052a52e6198d59:
platform/x86: Kconfig: Fix dell-laptop dependenc
ing for this Kconfig to try and catch
more of this - and of course I've learned a few things to look out for
as well.
Thanks,
Darren Hart
VMware Open Source Technology Center
The following changes since commit 7fe3fa3b5ec8e75389cce4bf5d052a52e6198d59:
platform/x86: Kconfig: Fix dell-laptop dependenc
On Sat, May 12, 2018 at 11:51:02AM -0700, Randy Dunlap wrote:
> On 05/12/2018 11:32 AM, Darren Hart wrote:
> > On Sat, May 12, 2018 at 05:28:05PM +0800, kbuild test robot wrote:
> >> Hi Mario,
> >>
> >> FYI, the error/warning still remains.
> >>
>
On Sat, May 12, 2018 at 11:51:02AM -0700, Randy Dunlap wrote:
> On 05/12/2018 11:32 AM, Darren Hart wrote:
> > On Sat, May 12, 2018 at 05:28:05PM +0800, kbuild test robot wrote:
> >> Hi Mario,
> >>
> >> FYI, the error/warning still remains.
> >>
>
tristate "Dell SMBIOS driver"
+ depends on DCDBAS || DCDBAS=n
--
Darren Hart
VMware Open Source Technology Center
tristate "Dell SMBIOS driver"
+ depends on DCDBAS || DCDBAS=n
--
Darren Hart
VMware Open Source Technology Center
Activation of Mellanox LED driver from mlx-platform.
>
> Introduction of new mlxreg-io driver.
>
> Activation of mlxreg-io driver from mlx-platform.
Patches 1,2 are queued up. Dropping 3-7 and reviewing them now from v2.
--
Darren Hart
VMware Open Source Technology Center
Activation of Mellanox LED driver from mlx-platform.
>
> Introduction of new mlxreg-io driver.
>
> Activation of mlxreg-io driver from mlx-platform.
Patches 1,2 are queued up. Dropping 3-7 and reviewing them now from v2.
--
Darren Hart
VMware Open Source Technology Center
t;sh...@kernel.org>
I was concerned because this override was a deliberate decision made in:
9705315b7562 selftests/futex: Update Makefile to use lib.mk
But reviewing lib.mk today, the RUN_TESTS and EMIT_TESTS perform the same
function running TEST_PROGS.
Reviewed-by: Darren Hart (VMware)
I was concerned because this override was a deliberate decision made in:
9705315b7562 selftests/futex: Update Makefile to use lib.mk
But reviewing lib.mk today, the RUN_TESTS and EMIT_TESTS perform the same
function running TEST_PROGS.
Reviewed-by: Darren Hart (VMware)
--
Darren Hart
VMw
On Fri, May 04, 2018 at 06:27:00PM +, mario.limoncie...@dell.com wrote:
> Darren,
>
> Is this with that fix of mine merged?
FYI: This fix has now been merged to linus/master.
--
Darren Hart
VMware Open Source Technology Center
On Fri, May 04, 2018 at 06:27:00PM +, mario.limoncie...@dell.com wrote:
> Darren,
>
> Is this with that fix of mine merged?
FYI: This fix has now been merged to linus/master.
--
Darren Hart
VMware Open Source Technology Center
figuration for
4.17 and 4.16 via stable.
Thanks,
Darren Hart
VMware Open Source Technology Center
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.infradead.org/linux-platfo
figuration for
4.17 and 4.16 via stable.
Thanks,
Darren Hart
VMware Open Source Technology Center
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.infradead.org/linux-platfo
--
Darren
>
> > -Original Message-
> > From: kbuild test robot [mailto:l...@intel.com]
> > Sent: Friday, May 4, 2018 1:24 PM
> > To: Limonciello, Mario
> > Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart (VMware)
> > Subject: drivers/platfo
--
Darren
>
> > -Original Message-
> > From: kbuild test robot [mailto:l...@intel.com]
> > Sent: Friday, May 4, 2018 1:24 PM
> > To: Limonciello, Mario
> > Cc: kbuild-...@01.org; linux-kernel@vger.kernel.org; Darren Hart (VMware)
> > Subject: drivers/platfo
gt; DELL_LAPTOP=y,
> its select DELL_SMBIOS incorrectly makes DELL_SMBIOS=y.
>
>
> so if we can get your patch merged, we can see if any more breakage
> happens... :)
Sorry, comms fail on my part. This will be merged to for-next by tomorrow.
--
Darren Hart
VMware Open Source Technology Center
gt; DELL_LAPTOP=y,
> its select DELL_SMBIOS incorrectly makes DELL_SMBIOS=y.
>
>
> so if we can get your patch merged, we can see if any more breakage
> happens... :)
Sorry, comms fail on my part. This will be merged to for-next by tomorrow.
--
Darren Hart
VMware Open Source Technology Center
ile in but this
> > > causes dell-smbios to compile in which breaks if dcdbas is a module.
> > >
> > > Dell laptop shouldn't select dell-smbios anymore, but depend on it.
> > >
> > > Fixes: 32d7b19 (platform/x86: dell-smbios: Resolve dependency error on
> >
ile in but this
> > > causes dell-smbios to compile in which breaks if dcdbas is a module.
> > >
> > > Dell laptop shouldn't select dell-smbios anymore, but depend on it.
> > >
> > > Fixes: 32d7b19 (platform/x86: dell-smbios: Resolve dependency error on
> >
uot; avoids the
dependency check causing this failure (I'm surprised and dismayed this
made it through all the config permutation testing this saw).
I'll apply this patch, and I guess it should go to stable, and for the
next version I think it's time for a new "CONFIG DELL_EXTRAS" which will
allow us to default DELL_SMBIOS to y and make the menu more consistent.
Thank you for the catch. Grr :-(
--
Darren Hart
VMware Open Source Technology Center
uot; avoids the
dependency check causing this failure (I'm surprised and dismayed this
made it through all the config permutation testing this saw).
I'll apply this patch, and I guess it should go to stable, and for the
next version I think it's time for a new "CONFIG DELL_EXTRAS" which will
allow us to default DELL_SMBIOS to y and make the menu more consistent.
Thank you for the catch. Grr :-(
--
Darren Hart
VMware Open Source Technology Center
one
>
> Taking above into attention, and assuming it will go via some other tree,
> Acked-by: Andy Shevchenko <andy.shevche...@gmail.com>
This driver is all kinds of a special case, so no objection here either. :-)
--
Darren Hart
VMware Open Source Technology Center
o attention, and assuming it will go via some other tree,
> Acked-by: Andy Shevchenko
This driver is all kinds of a special case, so no objection here either. :-)
--
Darren Hart
VMware Open Source Technology Center
---
>
> Build tested only. buildbot is happy. Please apply individually.
Queued up for testing.
(I'm not sure what you mean by "Please apply individually")
--
Darren Hart
VMware Open Source Technology Center
dbot is happy. Please apply individually.
Queued up for testing.
(I'm not sure what you mean by "Please apply individually")
--
Darren Hart
VMware Open Source Technology Center
On Thu, Apr 19, 2018 at 07:04:34AM -0700, João Paulo Rechi Vita wrote:
> When the module is removed the led workqueue is destroyed in the remove
> callback, before the led device is unregistered from the led subsystem.
Queued up, thanks.
--
Darren Hart
VMware Open Source Technology Center
On Thu, Apr 19, 2018 at 07:04:34AM -0700, João Paulo Rechi Vita wrote:
> When the module is removed the led workqueue is destroyed in the remove
> callback, before the led device is unregistered from the led subsystem.
Queued up, thanks.
--
Darren Hart
VMware Open Source Technology Center
t instead supported www.dell.com
in OEM strings.
Match both of these to indicate that this driver is running on
a Dell system.
Reported-by: Sergey Kubushyn <k...@koi8.net>
Tested-by: Sergey Kubushyn <k...@koi8.net>
Signed-off-by: Mario Limonciello <mario.limoncie...@dell.com>
[dvhar
RING, "Dell System", NULL) &&
+ !dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "www.dell.com", NULL)) {
pr_err("Unable to run on non-Dell system\n");
return -ENODEV;
}
--
2.14.3
--
Darren Hart
VMware Open Source Technology Center
ompanies can't change DMI_BOARD_NAME". Is that an
assumption, or is that how ODMs work with Mellanox?
--
Darren Hart
VMware Open Source Technology Center
ompanies can't change DMI_BOARD_NAME". Is that an
assumption, or is that how ODMs work with Mellanox?
--
Darren Hart
VMware Open Source Technology Center
}
> + if (!aggr_asserted)
We seem to check aggr_asserted in several places in this routine now.
Looks like something we could simplify. If you check it here, can you
drop the check lower in the routine? Can you remove it from the for loop
if conditional entirely? Please consider how to simplify.
--
Darren Hart
VMware Open Source Technology Center
}
> + if (!aggr_asserted)
We seem to check aggr_asserted in several places in this routine now.
Looks like something we could simplify. If you check it here, can you
drop the check lower in the routine? Can you remove it from the for loop
if conditional entirely? Please consider how to simplify.
--
Darren Hart
VMware Open Source Technology Center
struct regmap *regmap;
> struct delayed_work dwork_irq;
> - struct delayed_work dwork;
> spinlock_t lock; /* sync with interrupt */
> struct device *hwmon;
> struct attribute *mlxreg_hotplug_attr[MLXREG_HOTPLUG_ATTRS_MAX + 1];
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
struct delayed_work dwork_irq;
> - struct delayed_work dwork;
> spinlock_t lock; /* sync with interrupt */
> struct device *hwmon;
> struct attribute *mlxreg_hotplug_attr[MLXREG_HOTPLUG_ATTRS_MAX + 1];
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
ccess mask;
> - * @mode: access mode;
> * @bit: attribute effective bit;
> + * @mode: access mode;
> * @np - pointer to node platform associated with attribute;
> * @hpdev - hotplug device data;
> * @health_cntr: dynamic device health indication counter;
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
ode: access mode;
> * @bit: attribute effective bit;
> + * @mode: access mode;
> * @np - pointer to node platform associated with attribute;
> * @hpdev - hotplug device data;
> * @health_cntr: dynamic device health indication counter;
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
| 66 -
> 6 files changed, 765 insertions(+), 4 deletions(-)
> create mode 100644 drivers/platform/mellanox/mlxreg-io.c
>
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
| 66 -
> 6 files changed, 765 insertions(+), 4 deletions(-)
> create mode 100644 drivers/platform/mellanox/mlxreg-io.c
>
> --
> 2.1.4
>
>
--
Darren Hart
VMware Open Source Technology Center
any kind of indicator for a PCI device if it is a removable
device? Only disabling those PCI devices which are wholly integrated
with the platform would be ideal.
Failing that, is there an indicator in the PCI configuration which will
distinguish such devices? Are the integrated devices using specific
lanes, are the external devices behind a switch? etc. And can we do this
in a generic way for all relevant platforms.
--
Darren Hart
VMware Open Source Technology Center
a PCI device if it is a removable
device? Only disabling those PCI devices which are wholly integrated
with the platform would be ideal.
Failing that, is there an indicator in the PCI configuration which will
distinguish such devices? Are the integrated devices using specific
lanes, are the external devices behind a switch? etc. And can we do this
in a generic way for all relevant platforms.
--
Darren Hart
VMware Open Source Technology Center
reasonable.
So I'm waiting for v3 from Kai-Heng - unless I've misunderstood the
conclusion of this thread.
--
Darren Hart
VMware Open Source Technology Center
from Kai-Heng - unless I've misunderstood the
conclusion of this thread.
--
Darren Hart
VMware Open Source Technology Center
iff the workqueue is
successfully created. It seems like it would make sense to move the
devm_led_classdev_unregister() call within the 'if (data->wq)' condition block.
This should also cc stable.
Thanks,
--
Darren Hart
VMware Open Source Technology Center
uld make sense to move the
devm_led_classdev_unregister() call within the 'if (data->wq)' condition block.
This should also cc stable.
Thanks,
--
Darren Hart
VMware Open Source Technology Center
On Fri, Mar 23, 2018 at 03:59:22PM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, March 23, 2018 1:56 AM
> > To: Vadim Pasternak <vad...@mellanox.com>
&g
On Fri, Mar 23, 2018 at 03:59:22PM +, Vadim Pasternak wrote:
>
>
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, March 23, 2018 1:56 AM
> > To: Vadim Pasternak
> > Cc: andy.shevche...@gmail.com;
Glogowski <glo...@fbihome.de>
Cc: Michał Kępień <ker...@kempniu.pl>
Cc: Jonathan Woithe <jwoi...@just42.net>
Signed-off-by: Darren Hart (VMware) <dvh...@infradead.org>
---
Note: this applies on top of Jan-Marek's recent RFKILL and MICMUTE hotkey patch.
I'd really appreci
Glogowski
Cc: Michał Kępień
Cc: Jonathan Woithe
Signed-off-by: Darren Hart (VMware)
---
Note: this applies on top of Jan-Marek's recent RFKILL and MICMUTE hotkey patch.
I'd really appreciate a Tested-by from Jan-Marek in particular. You can get the
entire series ready for testing here:
http
ommit messages for the top 4 commits:
http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/review-dvhart-mellanox
Does this still match your intent?
--
Darren Hart
VMware Open Source Technology Center
ommit messages for the top 4 commits:
http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/review-dvhart-mellanox
Does this still match your intent?
--
Darren Hart
VMware Open Source Technology Center
On Thu, Mar 22, 2018 at 10:04:51AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 21, 2018 at 03:58:18PM -0700, Darren Hart wrote:
> > On Tue, Feb 13, 2018 at 10:09:34PM +, Vadim Pasternak wrote:
> > > Add deferred bus functionality in order to enforce probing flow exe
On Thu, Mar 22, 2018 at 10:04:51AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 21, 2018 at 03:58:18PM -0700, Darren Hart wrote:
> > On Tue, Feb 13, 2018 at 10:09:34PM +, Vadim Pasternak wrote:
> > > Add deferred bus functionality in order to enforce probing flow exe
> drivers/platform/x86/fujitsu-laptop.c:816 acpi_fujitsu_laptop_add() warn:
> > impossible condition '(priv->flags_supported == (1 << (31))) =>
> > (0-2147483647,18446744071562067968-u64max == 2147483648)'
> >
> > Fixes: 819cddae7cfa ("platform/x86: fujits
101 - 200 of 3303 matches
Mail list logo
