o dell-laptop and have it skip the rfkill code on Windows 8 and later
systems. I never trusted that code, but Dell insisted that it would
always wor on Latitudes and Precisions…
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe platform
Works for me.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
think merging them is
probably the last bad answer.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
a generic
interface for it. In this case, I suspect not and that this is fine.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
Huh. Yeah, I actually see the same behaviour on my Thinkpad. Let me play
with this a little.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
to the irst driver to handle that case, but that would involve it being
rather more friendly with the system clock than we want. I think the
right fix is probably to have the rtc driver reset the alarm on resume.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
);
}
+
+ if (cmos-valid_alarm)
+ cmos_set_alarm(dev, cmos-alm);
+
spin_unlock_irq(rtc_lock);
dev_dbg(dev, resume, ctrl %02x\n, tmp);
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body
On Mon, Dec 22, 2014 at 04:50:37PM +0100, Gabriele Mazzotta wrote:
On Monday 22 December 2014 14:59:49 Matthew Garrett wrote:
Can you try this diff?
Unfortunately it doesn't work (I made a change, see here below).
Ok. Can you hack the resume path to dump the RTC registers on resume? I
hardware can't support UIE mode */
int uie_unsupported;
+#ifdef CONFIG_PM_SLEEP
+ struct rtc_wkalrm alarm;
+ bool valid_alarm;
+#endif
#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
struct work_struct uie_task;
struct timer_list uie_timer;
--
Matthew Garrett | mj
will notify userspace. Consume the
event in the filter and don't pass it through.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
multiple
rfkill devices.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
devices is likely to confuse
userspace - it would probably be better to avoid registering the rfkill
interface at all in that case.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord
then you should just drop them once you've done the state update.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
duplication in splitting it.
There is no ACPI backlight driver on these systems? We need a platform driver?
ACPI doesn't specify keyboard backlight control, so this ends up being
very vendor specific.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
On Mon, Nov 10, 2014 at 10:12:42PM -0800, Darren Hart wrote:
As this is ACPI enumerated, does it belong in drivers/platform and not in
drivers/acpi?
Yeah, it's still a platform driver rather than a core ACPI driver.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list
from the
resume was this ACPI call).
I am really surprised some toshiba laptops do not need this, so I'd prefer
that
an ACPI expert (Matthew???) gives its wisdom regarding that.
Looks good to me. I'd be surprised if this breaks anything.
Acked-by: Matthew Garrett matthew.garr...@nebula.com
to Darren today and he's agreed to take this over. Poor
guy.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
/platform-drivers-x86.git for_linus
for you to fetch changes up to 8039aabb6c9f802bca04cc77ca210060a5b53916:
Revert platform/x86/toshiba-apci.c possible bad if test? (2014-08-20
08:18:18 -0700)
Matthew Garrett (1):
Revert
/toshiba_haps.txt
create mode 100644 drivers/platform/x86/toshiba_haps.c
--
Matthew Garrett | mj...@srcf.ucam.org
signature.asc
Description: Digital signature
== 0, but we want / need bl_power ?) .
I'd be... surprised if anyone's using the interface that way. Let's give
it a go and see?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord
On Wed, 2014-06-11 at 15:57 +0200, Hans de Goede wrote:
Hi,
On 06/10/2014 06:16 PM, Matthew Garrett wrote:
On Thu, 2014-05-15 at 11:39 +0200, Hans de Goede wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
I'm not especially keen on this - if this seems like a general problem
actually do?
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+�_+ޯ :�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
On Tue, 2014-06-10 at 16:16 +, Matthew Garrett wrote:
On Thu, 2014-05-15 at 11:39 +0200, Hans de Goede wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
I'm not especially keen on this - if this seems like a general problem,
adding boards piecemeal to a DMI table will never
+-
drivers/platform/x86/toshiba_acpi.c | 30 +++-
15 files changed, 485 insertions(+), 65 deletions(-)
create mode 100644 Documentation/platform/x86-laptop-drivers.txt
create mode 100644 drivers/platform/x86/dell-smo8800.c
--
Matthew Garrett | mj...@srcf.ucam.org
signature.asc
Description
Hm. Sorry, I thought I'd picked that one up. I'll send it in a couple of
days.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
to
GMUX in order to fix things up. This won't actually *work* in its current
form - it needs additional patches to the GPU drivers, which are currently
in a somewhat hacky state.
--
Matthew Garrett | matthew.garr...@nebula.com
--
To unsubscribe from this list: send the line unsubscribe platform
We can switch DDC pins in a way that ought (with luck) to work for LVDS.
This isn't sufficient for eDP, which is addressed in later patches.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/platform/x86/apple-gmux.c | 11 +++
1 file changed, 11 insertions(+)
diff
to
retrigger the driver's output probing.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/gpu/vga/vga_switcheroo.c | 10 ++
include/linux/vga_switcheroo.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga
Most switcheroo setups attach power management to one of the GPUs. This is
not always the case, so provide a mechanism for handlers to declare that
they can change the power state of GPUs and permit drivers to obtain this
information.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
From: Seth Forshee seth.fors...@canonical.com
During graphics driver initialization its useful to be able to mux only
the DDC to the inactive client in order to read the EDID. Add a
switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to
We may not know whether the platform supports dynamic PM of GPUs until the
switcheroo handler is registered. Add an enable() callback for clients and
another entry point to switcheroo in order to permit them to set dynamic PM
appropriately.
Signed-off-by: Matthew Garrett matthew.garr
Add a command line option in order to allow the user to provide a perferred
GPU at boot time.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
Documentation/kernel-parameters.txt | 5 +
drivers/gpu/vga/vga_switcheroo.c| 29 +
2 files changed, 34
Registering the handler after both GPUs will trigger a DDC switch for
connector reprobing. This will oops if apple_gmux_data hasn't already been
assigned. Reorder the code to do that.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/platform/x86/apple-gmux.c | 10
that
data in vga_switcheroo where it can be retrieved by the other driver later.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/gpu/vga/vga_switcheroo.c | 59
include/linux/vga_switcheroo.h | 12
2 files changed, 71 insertions
We need to force the previously active device to reprobe its connectors
when we switch in order to allow it to give up connectors that are no
longer in use.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/gpu/vga/vga_switcheroo.c | 3 +++
1 file changed, 3 insertions
The Apple GMUX can cut power to the discrete GPU, so should declare this
to the vga_switcheroo core.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/platform/x86/apple-gmux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers
The GMUX doesn't appear to switch instantly, which can trigger problems in
panel detection and setup. Wait for an interrupt or 200msec, whichever comes
first.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/platform/x86/apple-gmux.c | 12
1 file changed, 12
The information we had from Dell is that the rfkill functionality isn't
validated on Inspiron devices. How do we know this works under all
circumstances?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body
That's not being merged without a Signed-off-by:.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
Could you include a description in the patch for why this is necessary?
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
Thanks, if there are no objections I'll apply that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
the actual difference in state before and after suspend?
--
Matthew Garrett matthew.garr...@nebula.com
, somewhere
else under /lib/udev on older ones.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
Oh, I'm sorry - I misread. That will fix number 3. As for 1 and 2 - do
they both report e0f0, or do they produce different messages in dmesg?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message
On Tue, Apr 15, 2014 at 01:03:44AM +0300, Oleksandr Natalenko wrote:
They both report e0f0.
Well bother. In that case there must be some other way to distinguish
them. I'll look into it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe
products
alienware-wmi: cover some scenarios where memory allocations would fail
Matthew Garrett (1):
toshiba_acpi: Fix whitespace
Mattia Dongili (1):
sony-laptop: remove useless sony-laptop versioning
Scott K Logan (1):
fujitsu-tablet: add support for Lifebook T901 and T902
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
of unrelated things.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+�_+ޯ :�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
On Fri, Mar 28, 2014 at 01:52:07AM -0700, Dmitry Torokhov wrote:
Are we even certain that they will be consistent in use of these special
PNP ID's? Maybe you should really do DMI match...
The Windows drivers bind on PNP IDs, not DMI.
--
Matthew Garrett | mj...@srcf.ucam.org
that until there's an actual example.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
to be packed into that node when setting it, but how it's
done is well commented.
Hm. I'm not a huge fan of this approach - do any other drivers do it the
same way? It seems like this forces userspace code to special-case this
system.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X
supported platforms not yet locked.
Could you clarify what the HDMI mux is for? Is there any method in the
HDMI WMI call to determine whether it's supported rather than relying on
DMI? (I appreciate that in this kind of case there may not be)
--
Matthew Garrett matthew.garr...@nebula.com
On Wed, 2014-02-12 at 16:32 +0100, Takashi Iwai wrote:
The mute LED states have to be restored after resume.
Oh, never mind, we're not doing this through the LED class, are we?
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+�_+ޯ :�{ay� ʇڙ�,j��f���h���z
of sysfs
nodes
to represent the different colors in the different zones.
Have you discussed the best way to represent this with the LED class
maintainer?
--
Matthew Garrett matthew.garr...@nebula.com
On Wed, Jan 22, 2014 at 04:33:06PM +0800, AceLan Kao wrote:
Hi Mathew,
It's been over 3 months since the 2 patches were submitted.
Could you please review them or should I re-submit them?
I've merged these, thanks!
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list
of acpidump for this system?
Thanks,
--
Matthew Garrett matthew.garr...@nebula.com
--
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
if there are any cases that would be broken by this?
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
Actually, just found an example - looks like I'm wrong and it's purely
used for sending this event. In that case, don't bother with the keymap
at all and just hardcode KEY_RFKILL.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+�_+ޯ :�{ay� ʇڙ�,j��f���h���z
extent, but often you'll just find (at best) a reference to
a superIO chip and no child devices. Do we have an example DSDT for a
device with this part?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body
a chance to review it yet. I'll take a look in the
next couple of days. Thanks for your patience!
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
need some quirks to disable acpi_video0 by the
mean while before use_native_backlight is default true.
Sorry, I'm not adding any machine-specific quirks to fix generic
problems.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver
it need to be added here?
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
only intended for ACPI systems then why not just be an ACPI device?
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
On Tue, Dec 03, 2013 at 06:44:52PM -0800, David E. Box wrote:
On Wed, Dec 04, 2013 at 02:21:30AM +, Matthew Garrett wrote:
Well sure, but why do you need to be a platform device at all? This
functionality was intended for cases where we already have a driver for
the part
On Mon, Dec 02, 2013 at 01:11:05PM +0100, Stanislaw Gruszka wrote:
This is basically a revert of:
commit a6c2390cd6d2083d27a2359658e08f2d3df375ac
Author: Matthew Garrett m...@redhat.com
Date: Fri Jun 1 12:46:56 2012 -0400
dell-laptop: Remove rfkill code
Except that patch add
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
interface, so any system that calls _OSI(Windows 2012)
should use the Intel interface instead. It needs to be fixed in general,
not in the platform drivers.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body
set when they need to supress change events?
It looks like this is just to force synchronisation to sysfs when using
the /proc interface? In which case we should probably just kill
the /proc interface.
--
Matthew Garrett matthew.garr...@nebula.com
--
To unsubscribe from this list: send the line
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
--
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
Applied the set, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
--
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
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
--
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
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
--
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
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
--
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
Applied the pair, sorry about the delay.
--
Matthew Garrett matthew.garr...@nebula.com
--
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
I've applied the set. Let's see how this goes.
--
Matthew Garrett matthew.garr...@nebula.com
--
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, 2013-11-20 at 17:45 -0800, Kuppuswamy Sathyanarayanan wrote:
- Changed INIT_COMPLETION to reinit_completion.
Thanks, I've already folded that fix into the patch and re-pushed.
--
Matthew Garrett matthew.garr...@nebula.com
the registration of the acpi backlight that long, since the
time you'd have to wait is basically unbounded...
See the intel_opregion_present() code in drivers/acpi/video.c. The ACPI
driver won't bind to Intel hardware until i915 indicates that it should
do so.
--
Matthew Garrett matthew.garr...@nebula.com
On Sun, Oct 13, 2013 at 09:31:25PM -0500, Felipe Contreras wrote:
On Sun, Oct 13, 2013 at 10:17 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
The spec doesn't seem to constrain it to physical addresses (it just
refers to Control Methods read and write data to locations in address
spaces
.
--
Matthew Garrett matthew.garr...@nebula.com
On Mon, Oct 14, 2013 at 06:18:36PM -0500, Felipe Contreras wrote:
On Mon, Oct 14, 2013 at 10:52 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
It wouldn't be appropriate to alter the firmware behaviour by default,
but yeah, that's the kind of thing that the thermal framework exists to
do
On Mon, Oct 14, 2013 at 06:27:33PM -0500, Felipe Contreras wrote:
On Mon, Oct 14, 2013 at 6:22 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
The easiest is to just do it from userspace. I think Intel have some
code for doing this, but I haven't looked at the thermal code for years
to locations in address
spaces (for example, System memory and System I/O), so I'd lean towards
changing the behaviour of acpica rather than adding virt_to_phys().
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body
GUID as asus-wmi - implementing it here seems appropriate. I am
concerned about the phys/virt thing, though. The ACPI interpreter is
running in the kernel, not the hardware - are we artificially limiting
SystemMemory opregions to physical addresses?
--
Matthew Garrett matthew.garr...@nebula.com
N
/x86/panasonic-laptop.c | 25 +---
drivers/platform/x86/samsung-q10.c| 65 ++-
drivers/platform/x86/thinkpad_acpi.c | 23 ---
drivers/platform/x86/wmi.c| 4 +-
13 files changed, 66 insertions(+), 114 deletions(-)
--
Matthew
Can you document this in the help text? It's unclear whether people
should enable this option or not.
--
Matthew Garrett matthew.garr...@nebula.com
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
--
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, 2013-08-28 at 14:48 +0300, Andy Shevchenko wrote:
+module_acpi_driver(acpi_pcc_driver);
module_acpi_driver(acpi_pcc_driver), right? I've fixed that and applied.
--
Matthew Garrett matthew.garr...@nebula.com
On Mon, 2013-08-19 at 17:15 +0200, Jerome Meinke wrote:
This change extends the amilo_rfkill_id_table[] with the
DMI_BOARD_NAME information of the Amilo L1310, so that the wifi device
can be switched on.
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
.
--
Matthew Garrett matthew.garr...@nebula.com
bluetiith
wifi
But currently gps and wwan are swapped. Fix that.
Also fix goto links.
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
On Wed, 2013-07-17 at 09:55 +0800, Wei Yongjun wrote:
module_acpi_driver() makes the code simpler by eliminating
boilerplate code.
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
On Fri, 2013-07-19 at 16:18 +0900, Jingoo Han wrote:
The usage of strict_strtoul() and strict_strtol() is not preferred,
because strict_strtoul() and strict_strtol() are obsolete. Thus,
kstrtoul() and kstrtol() should be used.
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
On Wed, 2013-07-17 at 09:52 +0800, Wei Yongjun wrote:
module_acpi_driver() makes the code simpler by eliminating
boilerplate code.
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
On Thu, 2013-08-22 at 11:04 +0900, Jingoo Han wrote:
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Applied, thanks.
--
Matthew Garrett matthew.garr...@nebula.com
-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/platform/x86/Kconfig | 20 +
drivers/platform/x86/Makefile| 1 +
drivers/platform/x86/hpilo_support.c | 890 +++
drivers/watchdog/Kconfig | 18 -
drivers/watchdog/Makefile
-hp_bios_config
@@ -0,0 +1,27 @@
+What: /sys/firmware/hpilo_bios_config
+Date: July 2013
+Contact: Matthew Garrett matthew.garr...@nebula.com
+Description:
+ This directory exposes the HP iLO interface for manipulating
+ firmware configuration options
related and there's no real internal bus
architecture on the device.
--
Matthew Garrett matthew.garr...@nebula.com
On Thu, Aug 22, 2013 at 01:04:55PM -0700, Linus Torvalds wrote:
On Tue, Aug 20, 2013 at 5:45 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
ssh://cavan.codon.org.uk/srv/git/platform-drivers-x86.git linux-next
That is not a valid address. At least not unless you also post your
ssh
hotkeys on some systems (2013-08-18 13:23:31 -0400)
Daniel Serpell (1):
sony-laptop: Fix reporting of gfx_switch_status
Matthew Garrett (1):
Revert hp-wmi: Enable hotkeys on some systems
Wei Yongjun (1):
sony-laptop
1 - 100 of 371 matches
Mail list logo
