Re: [GIT PULL] Immutable branch between MFD and X86 due for the v4.13 merge window
On Mon, Jun 19, 2017 at 06:08:27PM +0300, Andy Shevchenko wrote: > On Mon, Jun 19, 2017 at 5:48 PM, Lee Jones wrote: > > Enjoy! > > Thanks! > > I suppose this one kbuild bot doesn't complain about :-) > > Darren, do we need it or we can survive until v4.13-rc1? I suggest merging it to a local branch for safe keeping and if we see conflicts in subsequent patches, we can apply it. I doubt it will be a problem. -- Darren Hart VMware Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
...
> drivers/platform/x86/wmi.c | 2 +-
...
> static void link_event_work(struct work_struct *work)
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 04791ea5d97b..e4d0697e07d6 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -886,7 +886,7 @@ static const struct file_operations wmi_fops = {
> .read = wmi_char_read,
> .open = wmi_char_open,
> .unlocked_ioctl = wmi_ioctl,
> - .compat_ioctl = wmi_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
For platform/drivers/x86:
Acked-by: Darren Hart (VMware)
As for a longer term solution, would it be possible to init fops in such
a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
so we don't have to duplicate this boilerplate for every ioctl fops
structure?
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > Acked-by: Darren Hart (VMware) > > > > As for a longer term solution, would it be possible to init fops in such > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > > so we don't have to duplicate this boilerplate for every ioctl fops > > structure? > > Bad idea, that... Because several years down the road somebody will add > an ioctl that takes an unsigned int for argument. Without so much as looking > at your magical mystery macro being used to initialize file_operations. Fair, being explicit in the declaration as it is currently may be preferable then. -- Darren Hart VMware Open Source Technology Center
Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Sat, Oct 18, 2014 at 12:13:23AM +0300, Jani Nikula wrote: > Documentation/kbuild/kconfig-language.txt warns to use select with care, > and in general use select only for non-visible symbols and for symbols > with no dependencies, because select will force a symbol to a value > without visiting the dependencies. > > Select has become particularly problematic, interdependently, with the > BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example: > > scripts/kconfig/conf --randconfig Kconfig > KCONFIG_SEED=0x48312B00 > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > > With tristates it's possible to end up selecting FOO=y depending on > BAR=m in the config, which gets discovered at build time, not config > time, like reported in the thread referenced below. > > Do the following to fix the dependencies: > > * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop > select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of > BACKLIGHT_CLASS_DEVICE. > > * Remove config FB_BACKLIGHT altogether, and replace it with a > dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting > FB_BACKLIGHT select or depend on FB anyway, so we can simplify. > > * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of > selecting ACPI_VIDEO and a number of its dependencies if ACPI is > enabled. This is tied to backlight, as ACPI_VIDEO depends on > BACKLIGHT_CLASS_DEVICE. > > * Replace a couple of select INPUT/VT with depends as it seemed to be > necessary. > > Reference: > http://lkml.kernel.org/r/ca+r1zhhmt4drwtf6mbrqo5eqxwx+lxcqh15vsu_d9wpftlh...@mail.gmail.com > Reported-by: Jim Davis > Cc: Randy Dunlap > Cc: David Airlie > Cc: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Darren Hart > Cc: Laurent Pinchart > Cc: Benjamin Herrenschmidt > Cc: Jens Frederich > Cc: Daniel Drake > Cc: Jon Nettleton > Cc: Jean-Christophe Plagniol-Villard > Cc: Tomi Valkeinen > Signed-off-by: Jani Nikula As for the drivers/platform/x86/Kconfig: Acked-by: Darren Hart Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] toshiba_acpi: Add support for USB Sleep functions
On Wed, Jan 21, 2015 at 11:21:06AM -0700, Azael Avalos wrote: > Hi there, > > Sorry for the late reply. > > 2015-01-20 4:15 GMT-07:00 Oliver Neukum : > > On Sun, 2015-01-18 at 18:30 -0700, Azael Avalos wrote: > >> The following patches add support to several USB Sleep functions > >> found on newer Toshiba laptops, allowing to use the USB ports while > >> the laptop is asleep or turned off. > > > > Hi, > > > > this is most interesting. But the interface is terrible. If > > Well, I'm just providing the on/off switch on Toshiba specific hardware, > but I'm unaware/unfamiliar with how other vendors implement this > feature. > > > possible we would like to have a generic interface for this, > > which should not depend on the specific platform in use and would > > have to be per bus or even per port (for example the ports on a > > Thunderbolt dock would not work with your module). > > Sounds good, as not all ports carry such functionality, on my > current laptop only two ports provide this, the other two are just > normal USB 2/3 ports (configurable ;-) ). > > > Do you think we could provide a hook from generic code into > > platform code to detect the capability for power control? > > If there's an existing API already, I'll be glad to modify the code to > use it, if it doesn't exist yet, I'll simply adapt the code to the chosen > standard whenever becomes available. Given the ACPI calls which are platform specific, a general purpose driver doesn't seem likely. I'm keeping this queued as is unless you ask me to drop it Azael. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
