ita
> Reported-by: Tasev Nikola
Queued to testing, thanks.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
{
> Notify (ASHS, 0x88) // Device-Specific
> }
> Else
> {
> (...)
> }
> }
> }
>
> Signed-off-by: Joã
; separate series, so this part can be merged without waiting for feedback on
> > the
> > new airplane mode RFKill LED trigger.
>
> Reviewed-by: Andy Shevchenko
>
> (I'm fine with current version but please take into consideration
> comments to the first patch, most imp
On Mon, Jan 04, 2016 at 09:51:23PM +0100, Pali Rohár wrote:
> On Monday 04 January 2016 21:40:20 Darren Hart wrote:
> > On Mon, Jan 04, 2016 at 09:26:19PM +0100, Pali Rohár wrote:
> > > On Monday 04 January 2016 21:04:25 Darren Hart wrote:
> > > > On Wed, Dec 30,
On Thu, Dec 24, 2015 at 10:18:44PM +0100, Pali Rohár wrote:
> This patch series adds check if Dell WMI descriptor structure is valid and
> fixes processing WMI events on devices with WMI interface version 0.
Given the discussion here, I'm dropping this one and waiting for v2.
--
On Mon, Jan 04, 2016 at 09:26:19PM +0100, Pali Rohár wrote:
> On Monday 04 January 2016 21:04:25 Darren Hart wrote:
> > On Wed, Dec 30, 2015 at 11:27:41PM +0100, Pali Rohár wrote:
> > > This patch adds support for controlling keyboard backlight via
> > > standar
,7 +55,8 @@ MODULE_LICENSE("GPL v2");
> > * acpi_driver.
> > */
> > static const struct acpi_device_id surface_button_device_ids[] = {
> > - {SURFACE_BUTTON_HID,0},
> > + {SURFACE_PRO3_BUTTON_HID,0},
> > + {SURFACE_PRO4_BUTTON_HID,0},
>
tml
>
> If you prefer perusing the patch in a browser:
> https://github.com/l1k/linux/commit/68eb066089346b4ba9aefdcbc69e66524427515e
>
> @Darren Hart:
> Barring any objections, please kindly provide an ack for merging via
> drm-next or drm-intel as I will post a new iteration o
a_switcheroo_handler gmux_handler
> = {
> .get_client_id = gmux_get_client_id,
> };
>
> +/**
> + * DOC: Interrupt
> + *
> + * gmux is also connected to a GPIO pin of the southbridge and thereby is
> able
> + * to trigger an ACPI GPE. On the MBP5 2008/09 it'
pports v3 and later.
Chen, any concerns?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
enrique, I'm holding off a bit more to give you time to respond given the
holiday season.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel
ig
> > @@ -747,6 +747,7 @@ config INTEL_HID_EVENT
> > tristate "INTEL HID Event Filter"
> > depends on ACPI
> > depends on INPUT
> > + select INPUT_SPARSEKMAP
> > help
> > This driver provides supports for Intel HID
On Wed, Dec 30, 2015 at 02:59:09AM +0100, Rafael Wysocki wrote:
> On Tuesday, December 29, 2015 04:59:10 PM Darren Hart wrote:
> > On Wed, Dec 23, 2015 at 04:14:41PM +0530, Souvik Kumar Chakravarty wrote:
> > > Makefile, Kconfig & MAINTAINERS changes for compiling Telemetr
On Wed, Dec 30, 2015 at 04:48:42AM +, Chakravarty, Souvik K wrote:
>
>
> > -Original Message-
> > From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-
> > x86-ow...@vger.kernel.org] On Behalf Of Darren Hart
> > Sent: Wednesday, De
On Wed, Dec 30, 2015 at 03:12:09AM +0100, Rafael Wysocki wrote:
> On Tuesday, December 29, 2015 04:50:05 PM Darren Hart wrote:
> > On Wed, Dec 23, 2015 at 04:14:16PM +0530, Souvik Kumar Chakravarty wrote:
> > > This implements debugfs interfaces for reading the telemetry
> &
ters
> + directly via debugfs files. Various tools may use
If tools are going to be relying on it, debugfs doesn't seem like the right
place for it to me. Would /sys/power be more apt?
Rafael?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this lis
t_unlock: as it is part of the successful path and not
specifically an error patth.
> +
> +static int telemetry_pltdrv_probe(struct platform_device *pdev)
> +{
> + struct resource *res0 = NULL, *res1 = NULL;
> + const struct x86_cpu_id *id;
> + int size, ret
---
...
> +static inline int telemetry_get_pssevtname(enum telemetry_unit telem_unit,
> +const char **name, int len)
> +{
> + struct telemetry_unit_config psscfg;
> + int i = 0;
It's a minor nit, but i doesn't need to be initialized
p;
> + TELEM_MASK_BIT;
By the time you have indented 4, and really should be 5, the preference is to
determine if this can be refactored into a shallower nesting structure.
Perhaps a macro of some sort as these all seem fairly repetitive.
...
This needs more time
ying similarly broken paltforms to the Vostro V131, and
provide users with a temporary solution until the DMI match can be added. Very
practical.
I have no objection to the changes in platform-drivers-x86.
Reviewed-by: Darren Hart
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscri
On Tue, Dec 22, 2015 at 10:16:13PM +0800, Geliang Tang wrote:
> to_platform_driver has been defined in platform_device.h, so drop
> this repetitive macro in asus-wmi.c.
>
> Signed-off-by: Geliang Tang
Thanks, applied.
--
Darren Hart
Intel Open Source Technology Center
--
To unsu
,7 +2087,8 @@ bool acpi_video_handles_brightness_key_presses(void)
> have_video_busses = !list_empty(&video_bus_head);
> mutex_unlock(&video_list_lock);
>
> - return have_video_busses;
> + return have_video_busses &&
> +(report_key_e
_keymap_report_entry(dell_wmi_input_dev, key, 1, true);
> @@ -398,7 +397,6 @@ static int __init dell_wmi_init(void)
> }
>
> dmi_walk(find_hk_type, NULL);
> - acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor;
>
> err = dell_wmi_input_se
cause this is a separate entry in
> the DSDT, and checkpatch told me to add an entry in MAINTAINERS in this case.
> Please let me know if any of this should have been done differently.
>
Are you willing to be the maintainer for this driver? A response to patches to
this list within a week
s like overkill for a driver with a single key.
+ set_bit(EV_KEY, switch_dev->evbit);
+ set_bit(KEY_RFKILL, switch_dev->keybit);
Mousou's driver results in about 30 less lines as well. Please compare and see
if we might be able to merge the best of each version.
--
Darren
{"ATK4001", 0},
> {"ATK4002", 0},
> {"", 0},
> };
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> platform-driver-x86" in
> the body of a message to majord...@vger.kernel.org
>
ulo Rechi Vita
Hi Joao,
Nice work!
In the future, [please be sure to include all the maintainers listed by
get_maintainer.pl when submitting patches for review.
No concerns from me on this portion of the series.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this l
es and David per get_maintainer.pl before
we can use it in platform drivers.
+Johannes
+David
+wireless
+netdev
--
Darren Hart
Intel Open Source Technology Center
>
> Signed-off-by: João Paulo Rechi Vita
> ---
> net/rfkill/core.c | 30 ++
> 1 fil
ce is suspended?
> >
> > I was surprised this worked, I was assuming that nothing could run
> > before the resume callback, but I was wrong. I think it makes sense to
> > treat ACPI devices in a special way, but I really don't know, we need
> > someone more knowledgeable to answer these questions. However, while I
> > was trying to figure things out, I stumbled upon the following:
> > e71eeb2a6bcc ("ACPI / button: Do not propagate wakeup-from-suspend events").
>
> Gabriele, are you going to send this patch?
>
> I think that patch should be OK as it drop events when device is in
> suspend state (when it should not receive events)...
>
> Darren, what do you think about it?
>
Sorry, this one has been difficult for me to track, but it's clearly an issue,
and new systems are experiencing it as well.
I'd like to get Rafael's opinion on disabling .notify ACPI function while
suspended.
+Rafael
Has Dell been involved here?
+Jared
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nd so is
> really going to be a performance problem (not).
>
> We cannot cache the return value as was being done before because it
> can change during startup depending in module loading order (the old
> code actually got this somewhat wrong), and taking a mutex in a code-path
>
if (hw_blocked)
> + hw_unblock_once = 1;
> hw_blocked = !hw_blocked;
> + if (!hw_unblock_once)
> + hw_blocked = 0;
> }
>
> for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
> --
> 1
On Fri, Dec 18, 2015 at 11:31:10PM +0800, Alex Hung wrote:
> This driver supports various HID events including hotkeys.
> Dell XPS 13 9350 requires it for the wireless hotkey.
>
> Signed-off-by: Alex Hung
Queued to testing.
--
Darren Hart
Intel Open Source Technology Center
--
To
provides support for the Intel HID Event hotkey
> > interface.
> > + Some aptops require this driver for hotkey support.
>
> laptops
Thanks,
I'll correct.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "
On Thu, Dec 17, 2015 at 02:50:39PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 17, 2015 at 2:15 PM, Darren Hart wrote:
> > On Thu, Dec 17, 2015 at 03:30:02PM +0800, Alex Hung wrote:
> >> This driver supports various hid events including hotkeys.
> >> Dell XPS 13 93
return 0;
> +}
> +
> +static int intel_hid_pl_resume_handler(struct device *device)
> +{
> + intel_hid_set_enable(device, 1);
> + return 0;
> +}
Why not propagate the intel_hid_set_enable() return code? Is it because it just
doesn't really impact suspend/resume, even if we d
handles are not used for
> - * keyboard backlight only
> + /* verify the kbd backlight presence, some of these handles are not used
> + * for keyboard backlight only
>*/
Comment blocks should start with a blank line:
/*
* This is the first line.
* This is the seco
d a patch which I have now merged to my testing and for-next
branches.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RFKill is not selected.
>
> This patch adds the RFKILL dependency to the KConfig entry, fixing
> the build issue.
>
> Signed-off-by: Azael Avalos
Queued, thanks!
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platfor
t; Right, my tag for both patches:
>
> Reviewed-by: Andy Shevchenko
Thank you for all your time helping to improve this series Andriy, very much
appreciated.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-dri
-off-by: Qipeng Zha
Thank you for the quick turn-around Qipeng. I've pushed these to the testing
branch for another round of 0day automated testing. If that comes back clean,
usually in a few hours, I'll push it on to the next branch, and you should see
this in linux-next soon.
--
Darr
is model to the DMI list.
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1286293
> Cc: sta...@vger.kernel.org
> Signed-off-by: Josh Boyer
Queued, thanks Josh.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscr
000..e6354a7
> > --- /dev/null
> > +++ b/drivers/platform/x86/intel_punit_ipc.c
> > @@ -0,0 +1,336 @@
> > +/*
> > + * Driver for the Intel P-Unit Mailbox IPC mechanism
> > + *
> > + * (C) Copyright 2015 Intel Corporation
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * The heart of the P-Unit is the Foxton microcontroller and its
> > firmware,
> > + * which provide mailbox interface for power management usage.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* IPC Mailbox registers */
> > +#define OFFSET_DATA_LOW0x0
> > +#define OFFSET_DATA_HIGH 0x4
> > +/* bit field of interface register */
> > +#defineCMD_RUN (1 << 31)
> > +#defineCMD_ERRCODE_MASK0xFF
>
> #include
>
> …BIT(31)
> …GENMASK(7,0)
>
> > +#defineCMD_PARA1_SHIFT 8
> > +#defineCMD_PARA2_SHIFT 16
> > +
> > +#define CMD_TIMEOUT_SECONDS1
> > +
> > +enum {
> > + DATA = 0,
> > + INTERFACE,
>
> BASE_DATA
> BASE_IFACE (or BASE_INTERFACE if you prefer, though better to be in
> align across those two drivers)
> BASE_MAX
>
>
> > +};
> > +
> > +typedef struct {
> > + struct device *dev;
> > + struct mutex lock;
> > + int irq;
> > + struct completion cmd_complete;
> > + /* base of interface and data registers */
> > + void __iomem *base[RESERVED_IPC][INTERFACE + 1];
>
> …[][BASE_MAX];
>
These are solid improvements. Qipeng, one more spin please and we can have this
in next by the weekend. I'm personally much more confident in this driver.
Thanks to Andriy for his careful review, and thank you for sticking with it.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dev_info(&pdev->dev, "punit BIOS interface res: %llx %x\n",
> > + (long long)res->start, (int)resource_size(res));
>
> There is a specifier to print struct resource, please use it instead.
> %pR IIRC.
>
Yes, %pR, see Documentation/printk-formats.txt
> Same for all similar cases below.
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 09, 2015 at 01:09:51PM +0200, Andy Shevchenko wrote:
> On Tue, 2015-12-08 at 16:21 -0800, Darren Hart wrote:
> > On Tue, Dec 08, 2015 at 02:57:18PM +0200, Andy Shevchenko wrote:
> > > On Mon, 2015-12-07 at 15:45 -0800, Darren Hart wrote:
> > > > On Tue, De
On Fri, Dec 04, 2015 at 08:15:04AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 4, 2015 at 12:39 AM, Pali Rohár wrote:
> > On Thursday 03 December 2015 15:38:56 Darren Hart wrote:
> >> Pali, this appears to have the one change you asked for (0x%x instead of
> >> %d).
&
On Tue, Dec 08, 2015 at 02:57:18PM +0200, Andy Shevchenko wrote:
> On Mon, 2015-12-07 at 15:45 -0800, Darren Hart wrote:
> > On Tue, Dec 08, 2015 at 12:55:04AM +0800, Qipeng Zha wrote:
> > > BIOS restructure exported memory resources for Punit
> > > in acpi table, So
On Tue, Dec 08, 2015 at 03:19:17PM +0200, Andy Shevchenko wrote:
> On Mon, 2015-12-07 at 15:45 -0800, Darren Hart wrote:
> > On Tue, Dec 08, 2015 at 12:55:04AM +0800, Qipeng Zha wrote:
> > > BIOS restructure exported memory resources for Punit
> > > in acpi table, So
On Tue, Dec 08, 2015 at 03:19:17PM +0200, Andy Shevchenko wrote:
> On Mon, 2015-12-07 at 15:45 -0800, Darren Hart wrote:
> > On Tue, Dec 08, 2015 at 12:55:04AM +0800, Qipeng Zha wrote:
> > > BIOS restructure exported memory resources for Punit
> > > in acpi table, So
On Tue, Dec 08, 2015 at 02:57:18PM +0200, Andy Shevchenko wrote:
> On Mon, 2015-12-07 at 15:45 -0800, Darren Hart wrote:
> > On Tue, Dec 08, 2015 at 12:55:04AM +0800, Qipeng Zha wrote:
...
>
> > >
> > > res = platform_get
RESOURCE_GCR_SIZE;
> + ipcdev.gcr_size = PLAT_RES_GCR_SIZE;
> dev_info(&pdev->dev, "ipc res: %llx %x\n",
>(long long)res->start, (int)resource_size(res));
>
> @@ -714,9 +764,9 @@ err_irq:
> err_device:
> iounmap(ipcdev.ipc_b
ndy to decide.
This looks fine to me, and if Pali will ack it, I'll move it from for-review to
testing and Andy will need to update patch 14/14 to accomodate - unless you guys
decide to include this in his.
For now, this is queued to for-review.
Thanks!
--
Darren Hart
Intel Open Sour
On Thu, Dec 03, 2015 at 04:10:49PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 3, 2015 at 4:07 PM, Darren Hart wrote:
> > On Thu, Dec 03, 2015 at 03:45:11PM -0800, Andy Lutomirski wrote:
> >> On Thu, Dec 3, 2015 at 3:38 PM, Darren Hart wrote:
> >> > On Mon, Nov 30,
On Thu, Dec 03, 2015 at 03:45:36PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 3, 2015 at 3:32 PM, Darren Hart wrote:
> > On Mon, Nov 30, 2015 at 05:01:59PM -0800, Andy Lutomirski wrote:
> >> It's currently hard to follow what maps to what, and it's hard to edit
>
On Thu, Dec 03, 2015 at 03:45:11PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 3, 2015 at 3:38 PM, Darren Hart wrote:
> > On Mon, Nov 30, 2015 at 05:02:01PM -0800, Andy Lutomirski wrote:
> >> If DMI lists a hotkey that we don't recognize, log and ignore it
> >>
takes
> + * quadratic time, but it doesn't matter unless the list
> + * of extra keys gets very long.
> + */
> + for (j = 0; j < num_bios_keys; j++)
> + if (keymap[j].code == dell_wmi_extra_keymap[i].code
pr_info("firmware scancode 0x%x maps to unrecognized
> keycode 0x%x\n",
> + bios_entry->scancode, bios_entry->keycode);
> + continue;
> + }
>
> if (keycode == KEY_KBDILLUMTOGGLE)
>
s didn't change the table.
>
> Acked-by: Pali Rohár
> Signed-off-by: Andy Lutomirski
I already have this one in next and I don't see a per-patch changelog for this
one - has it changed?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the li
pecially for things
like this which set precedent and don't scale well. If we cannot detect which
machines use the EC and which only use WMI, then we can fall back to checking
DMI for specific models.
Per the above, and Pali's feedback. I'll be dropping this one in anticipation of
a V
is is a common approach among platform drivers since we try to support
multiple products with a single driver.
Ideally, we could detect if this was necessary by the response of some ACPI call
or another, but failing that, DMI matching is our fallback.
--
Darren Hart
Intel Open Source Tec
On Wed, Nov 25, 2015 at 05:28:54PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
> > On Mon, Nov 23, 2015 at 11:25:30AM -0800, Andy Lutomirski wrote:
> >> Without this patch, wmi devices are in /sys/virtual/wmi. They're
> >>
On Thu, Nov 26, 2015 at 03:09:29PM +0100, Rafael Wysocki wrote:
> On Wednesday, November 25, 2015 05:28:54 PM Andy Lutomirski wrote:
> > On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
> > > On Mon, Nov 23, 2015 at 11:25:30AM -0800, Andy Lutomirski wrote:
> > &g
w info message could be more confused if
> it has decimal codes...
>
> With that fix, you can add my:
> Reviewed-by: Pali Rohár
Andy, will you be resending with this change?
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsub
On Mon, Nov 23, 2015 at 11:35:55PM +0100, Rafael Wysocki wrote:
> On Monday, November 23, 2015 11:04:13 AM Darren Hart wrote:
> > On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote:
> > > Use shiny new acpi_dev_present and remove all the boilerplate to search
> >
On Mon, Nov 23, 2015 at 08:55:27PM +0100, Lukas Wunner wrote:
> Hi Darren,
>
> On Mon, Nov 23, 2015 at 11:04:13AM -0800, Darren Hart wrote:
> > On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote:
> > > Use shiny new acpi_dev_present and remove all the boilerpla
);
> + retval = wmi_create_device(&gblock[i], wblock, device);
> if (retval) {
> wmi_free_devices();
> goto out_free_pointer;
> @@ -884,7 +886,7 @@ static int acpi_wmi_add(struct acpi_device *
> delivers KEY_RFKILL event to input susbsystem. IOW dell-rbtn looks
> completely redundant in this configuration.
>
> Can we detect that rfkill toggle is already avaiable via normal keyboard and
> not activate dell-rbtn in this case?
Also dropping this one until we can arrive at a complete solution.
Pali, Gabriele, this one is in your hands. I will review and provide feedback
where I can - I confess I'm finding it difficult to keep all the pieces straight
in my head, and without any hardware, I have to rely entirely on what I can
piece together (a situation we are all in as this differs across many systems,
nobody has all the necessary bits).
It may be helpful for someone to put together a current status, known issues,
plan of attack to get this moving forward again.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(CCed) tested this patch and patch does not fix bug.
> Probably there is race condition and ACPI event is sent *after* function
> rbtn_resume is called.
I'm dropping this one until we can sort out a proper fix.
Is direction still needed from the ACPI side?
+Rafael
--
Darren Hart
Intel
ank you for the testing data and submitting.
I have queued this to testing. Pending success on 0-day, it will land in
linux-next shortly (tomorrow most likely) where I hope it will receive
additional testing.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: se
this one up as well?
For platform-drivers-x86:
Acked-by: Darren Hart
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
I have no objection for platform-drivers-x86, but please include all maintainers
listed by get_maintainer.pl for the fastest response.
+Rafael
Rafael, I assume you will pick this up along with the acpi_dev_present ACPI
change if you take that. Pleaes let me know if not.
Otherwise,
Acked-by: Darre
that do not generate the event, the workquee is
> used to update the sysfs entries and also to emulate the event via
> netlink, to make userspace aware of such change.
>
> Signed-off-by: Azael Avalos
Queued to testing, thanks!
--
Darren Hart
Intel Open Source Technology Center
t; drivers/platform/x86/toshiba_acpi.c | 188
> +++-
> 1 file changed, 185 insertions(+), 3 deletions(-)
Queued to testing, thanks Azael.
In particular, thank you for the comments in the ACPI calls which document the
expected firmware interface.
--
Darren Hart
Intel O
x_keycode[bios_entry->keycode] :
> > > + KEY_RESERVED;
> >
> > Oops. BUILD_BUG_ON should be below u16 keycode = ... to avoid a
> > warning. Feel free to fix it up. I can also send a v3.
>
> KEY_RESERVED is zero by definition and exported to u
On Fri, Nov 20, 2015 at 05:05:37PM -0700, Azael Avalos wrote:
> Hi Darren,
>
> 2015-11-20 16:19 GMT-07:00 Darren Hart :
> > On Sun, Nov 15, 2015 at 08:33:46PM -0700, Azael Avalos wrote:
> >> The driver uses genetlink to inform userspace of events generated by
> >>
On Fri, Nov 20, 2015 at 04:46:07PM -0700, Azael Avalos wrote:
> Hi Darren,
>
> 2015-11-20 16:16 GMT-07:00 Darren Hart :
> > On Sun, Nov 15, 2015 at 08:32:47PM -0700, Azael Avalos wrote:
> >> If transflective backlight is supported and the brightness is zero
> >&g
On Fri, Nov 20, 2015 at 04:55:06PM -0700, Azael Avalos wrote:
> Hi Darren,
>
> 2015-11-20 16:39 GMT-07:00 Darren Hart :
> > On Mon, Nov 16, 2015 at 12:59:31PM -0700, Azael Avalos wrote:
> >> Certain Toshiba models with the second generation keyboard backlight
> >
he quoted string) is still a bit
> above 80, but that's better than splitting the string itself and
> breaking grep.
So I've taken care of this in my branch (and the one above too).
>
> >
> > Anyway, have you already found some missing mapping which comes from
>
On Sat, Nov 21, 2015 at 01:20:19AM +0100, Pali Rohár wrote:
> On Saturday 21 November 2015 01:09:39 Darren Hart wrote:
> > Pali or Matthew, do either of you care to comment?
>
> Already commented, email is in archive, see:
>
> http://thread.gmane.org/gmane.linux.drivers.pl
KEY_RESERVED;
>
> + if (keycode == 0) {
> + pr_info("firmware scancode %d maps to unrecognized
> keycode %d\n", bios_entry->keycode, bios_entry->scancode);
We don't split up strings for line length, but th
NOWN,
> + [35]= KEY_UNKNOWN,
> + [36]= KEY_UNKNOWN,
> + [37]= KEY_UNKNOWN,
> + [38]= KEY_MICMUTE,
> + [255] = KEY_PROG3,
> };
>
> /* These are applied if the hk table is present and doesn't override them. */
> --
> 2.5.
>
> - keymap[hotkey_num].type = KE_END;
> + keymap[pos].type = KE_END;
>
> return keymap;
> }
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> platform-driver-x86" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
eyboard backlight mode changed */
> + toshiba_acpi->kbd_event_generated = true;
> /* Update sysfs entries */
> - ret = sysfs_update_group(&acpi_dev->dev.kobj,
> - &toshiba_attr_group);
> - if
Thanks, applied.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dev_name(&acpi_dev->dev),
> - event, 0);
> + event, (event == 0x80) ?
> + dev->last_key_event : 0);
> }
>
> #ifdef CONFIG_PM_SLEEP
> --
> 2.6.2
>
f (dev->tr_backlight_supported && brightness == 0)
> + brightness++;
> ret = set_lcd_brightness(dev, brightness);
> if (ret) {
> pr_debug("Backlight method is read-only, disabling backlight
> support\n");
> --
> 2.6.2
t; pr_info("Unable to re-enable hotkeys\n");
> }
>
> + if (dev->wwan_rfk) {
> + int error = toshiba_wireless_status(dev);
> +
> + if (error)
> + return error;
For consistency, please use ret. Yo
rted_features(struct
> toshiba_acpi_dev *dev)
> pr_cont(" panel-power-on");
> if (dev->usb_three_supported)
> pr_cont(" usb3");
> + if (dev->wwan_supported)
> + pr_cont(" wwan");
>
> pr_cont("\n");
> }
> @@ -2736,6 +2826,8 @@ static int toshiba_acpi_add(struct acpi_device
> *acpi_dev)
> ret = get_fan_status(dev, &dummy);
> dev->fan_supported = !ret;
>
> + toshiba_wwan_available(dev);
> +
> print_supported_features(dev);
>
> ret = sysfs_create_group(&dev->acpi_dev->dev.kobj,
> --
> 2.6.2
>
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t;
> Signed-off-by: Dan Carpenter
Thank you Dan, queued to testing.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
order, and I'm
> moving the Yoga 3 1470 entry down while making the change, so they
> are sorted more logically.
>
> Signed-off-by: Arnd Bergmann
Queued to testing, thank you.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line &quo
losed in #ifdef.
I'm not thrilled with the ifdefs, but whether that's worse than the CONFIG_WMI
dependency or not... I'm not prepared to argue, so I'm siding with you :-)
>
> Signed-off-by: Arnd Bergmann
>
> [1]
> https://forums.lenovo.com/t5/Lenovo-Yoga
gt; This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing
> the wifi breakage.
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490
> Cc: sta...@vger.kernel.org
> Reported-and-tested-by: Kevin Fenzi
> Signed-off-by: Hans de Goede
Queued to testing,
On Fri, Nov 06, 2015 at 03:19:43PM +0100, David Herrmann wrote:
> Hi Darren!
>
> On Wed, Oct 21, 2015 at 4:44 PM, Darren Hart wrote:
> > On Wed, Oct 21, 2015 at 12:33:52PM -0200, Henrique de Moraes Holschuh wrote:
> >> On Wed, Oct 21, 2015, at 08:46, David He
ommit ID (as opposed to one from your development tree) when referring to a
commit. I've corrected this it the version I'll submit to Linus.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
> hotkey_event_type variable, and thus, it can lead to potential
> unwanted effects as the variable is being checked.
>
> This patch initializes such variable to avoid such unwanted effects.
>
> Cc: # 4.1+
> Signed-off-by: Azael Avalos
Applied, thanks Azael.
--
Darren Hart
I
i_device
> *acpi_dev)
> ret = toshiba_function_keys_get(dev, &dev->special_functions);
> dev->kbd_function_keys_supported = !ret;
>
> + dev->hotkey_event_type = 0;
> if (toshiba_acpi_setup_keyboard(dev))
> pr_info("Unable to activate hotkeys\n");
>
> --
&g
this:
punit_ipcdev->base[BIOS_IPC] = addr;
addr += MAILBOX_REGISTER_SPACE;
punit_ipcdev->base[GTDRIVER_IPC] = addr;
addr += MAILBOX_REGISTER_SPACE;
punit_ipcdev->base[ISPDRIVER_IPC] = addr;
MAILBOX_REGISTER_SPACE is 0x10, but I don't kno
lly don't know, we need
> someone more knowledgeable to answer these questions. However, while I
> was trying to figure things out, I stumbled upon the following:
> e71eeb2a6bcc ("ACPI / button: Do not propagate wakeup-from-suspend events").
>
My understanding here t
this device in DSDT.dsl and paste it here please.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 (switch is enabled, but toggle key disabled wifi)
c 1 0 N/A (invalid state)
d 1 1 1
State "a" is where we are failing currently I believe?
Do we know if DELRBTN and DELLABCE are always a TOGGLE or a SLIDER respectively?
I'm wondering if these should be separate drivers.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
>
> 2) If you use a Intel card (swiched with gpu-switch) the OSD (activated with
> functions keys) is so slow and chromium have the same problem (temporary fix
> is
> deactivate chromium hw acceleration) is this a intel driver bug?
>
> --
> You are receiving this mail
1 - 100 of 559 matches
Mail list logo
