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 registe
Oh, ha, wonderful. I'll nail something together and send it upstream.
The RTC maintainers may have opinions on how to do this cleanly, so
we'll see how that goes.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
& RTC_AIE);
}
+
+ if (cmos->valid_alarm)
+ cmos_set_alarm(dev, >alm);
+
spin_unlock_irq(_lock);
dev_dbg(dev, "resume, ctrl %02x\n", tmp);
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe lin
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
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
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 linux-kernel in
the body of a message
Oh, ha, wonderful. I'll nail something together and send it upstream.
The RTC maintainers may have opinions on how to do this cleanly, so
we'll see how that goes.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel 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
and will
restore it on resume if the alarm has not yet fired - if it has, it will clear
the RTC alarm.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
Tested-by: Gabriele Mazzotta gabriele@gmail.com
---
drivers/rtc/class.c | 24
include/linux/rtc.h | 4
2
Ah, http://cgit.freedesktop.org/~jani/drm/log/?h=didl nominally has
support for doing the right thing here - any chance you can try that
tree?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Oh, I see - acpi_osi= disables _OSI entirely, so we end up going down a
different path that results in us claiming to be XP. That results in a
bunch of changes in exposed hardware, so this patch certainly isn't
acceptable.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
The actual fix is known - Intel need to fix their code to match their
specification. Applying this patch may break functionality that other
users are depending on.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
that change behaviour as a result.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
Ah, I see - can you try acpi_osi="!Windows 2013" ?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
On Thu, Dec 18, 2014 at 05:04:23PM +0300, Dmitry Tunin wrote:
> Sry, wrong url b4
>
> https://bugzilla.kernel.org/attachment.cgi?id=125091
Can you check whether acpi_osi="Windows 2012" also results in things
working?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubsc
Can you run acpidump and upload the ACPI tables somewhere?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
tainly shouldn't be done without checking the ACPI
tables, and it really shouldn't be done at all because this is Intel's
bug and they should just fix it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
be done without checking the ACPI
tables, and it really shouldn't be done at all because this is Intel's
bug and they should just fix it.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Can you run acpidump and upload the ACPI tables somewhere?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 18, 2014 at 05:04:23PM +0300, Dmitry Tunin wrote:
Sry, wrong url b4
https://bugzilla.kernel.org/attachment.cgi?id=125091
Can you check whether acpi_osi=Windows 2012 also results in things
working?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send
Ah, I see - can you try acpi_osi=!Windows 2013 ?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
that change behaviour as a result.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
The actual fix is known - Intel need to fix their code to match their
specification. Applying this patch may break functionality that other
users are depending on.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Oh, I see - acpi_osi= disables _OSI entirely, so we end up going down a
different path that results in us claiming to be XP. That results in a
bunch of changes in exposed hardware, so this patch certainly isn't
acceptable.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
Ah, http://cgit.freedesktop.org/~jani/drm/log/?h=didl nominally has
support for doing the right thing here - any chance you can try that
tree?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
rather than ACPI, but yeah. In theory this should work fine if
you're using the EFI entry point. I don't know whether the patches for
linuxefi were ever accepted by grub upstream - if not, pushing those
would make more sense.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from thi
, but yeah. In theory this should work fine if
you're using the EFI entry point. I don't know whether the patches for
linuxefi were ever accepted by grub upstream - if not, pushing those
would make more sense.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send
lso kills other 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 linux-kernel" in
the bo
iple radio types then you should register multiple
rfkill devices.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
multiple
rfkill devices.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
t of code 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: s
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 12:58:39PM -0800, H. Peter Anvin wrote:
> It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
We should be getting that information from ACPI - cmos_pnp_probe()
doesn't have hardcoded assumptions about registers.
--
Matthew Garrett |
boot windows with secure boot when the CSM is enabled.
CMOS RTC support doesn't depend on the CSM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
with secure boot when the CSM is enabled.
CMOS RTC support doesn't depend on the CSM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Mon, Nov 10, 2014 at 12:58:39PM -0800, H. Peter Anvin wrote:
It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
We should be getting that information from ACPI - cmos_pnp_probe()
doesn't have hardcoded assumptions about registers.
--
Matthew Garrett | mj
On Mon, Oct 06, 2014 at 08:00:42PM +, Gregory Smith wrote:
> Revenge is needed. Or atleast equality. Or mjg59 should just quit
> patch submission gatekeeping and run for the senate.
I look forward to receiving your vote!
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscrib
On Mon, Oct 06, 2014 at 08:44:35PM +0200, Arnd Bergmann wrote:
> On Monday 06 October 2014 19:21:53 Matthew Garrett wrote:
> > Unfortunately not. I'd assume that PM registers are expected to be
> > accessed via the _PS* methods instead. Does MSI make sense outside the
>
essed via the _PS* methods instead. Does MSI make sense outside the
context of PCI interrupts?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
avoid us having problems with people
doing similar things with USB hosts.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.k
having problems with people
doing similar things with USB hosts.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the _PS* methods instead. Does MSI make sense outside the
context of PCI interrupts?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Mon, Oct 06, 2014 at 08:44:35PM +0200, Arnd Bergmann wrote:
On Monday 06 October 2014 19:21:53 Matthew Garrett wrote:
Unfortunately not. I'd assume that PM registers are expected to be
accessed via the _PS* methods instead. Does MSI make sense outside the
context of PCI interrupts
On Mon, Oct 06, 2014 at 08:00:42PM +, Gregory Smith wrote:
Revenge is needed. Or atleast equality. Or mjg59 should just quit
patch submission gatekeeping and run for the senate.
I look forward to receiving your vote!
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
P servers, some of the USB-ACPI glue
(defined by a Microsoft spec), some of the ACPI/TPM integration (defined
by TCG), some hwmon code, probably a few other bits and pieces.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On Tue, Sep 23, 2014 at 06:34:42AM +0800, Hanjun Guo wrote:
> On Sep 23, 2014, 06:28AM, Matthew Garrett wrote:
> > On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
> >> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
> >>> Explicit
On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
> On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
> > Explicit Change Request. These can only be filed by paid-up members of
> > the UEFI Forum, so I suspect this requirement is going t
Spelling out wtf ECR is would be nice, too.
Explicit Change Request. These can only be filed by paid-up members of
the UEFI Forum, so I suspect this requirement is going to be unworkable
(there's plenty of ACPI support code for large x86 vendors which isn't
part of any ACPI spec)
--
Matthe
. These can only be filed by paid-up members of
the UEFI Forum, so I suspect this requirement is going to be unworkable
(there's plenty of ACPI support code for large x86 vendors which isn't
part of any ACPI spec)
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
Explicit Change Request. These can only be filed by paid-up members of
the UEFI Forum, so I suspect this requirement is going to be unworkable
(there's
On Tue, Sep 23, 2014 at 06:34:42AM +0800, Hanjun Guo wrote:
On Sep 23, 2014, 06:28AM, Matthew Garrett wrote:
On Tue, Sep 23, 2014 at 12:46:24AM +0200, Rafael J. Wysocki wrote:
On Monday, September 22, 2014 09:31:36 PM Matthew Garrett wrote:
Explicit Change Request. These can only be filed
by a Microsoft spec), some of the ACPI/TPM integration (defined
by TCG), some hwmon code, probably a few other bits and pieces.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Wed, Sep 17, 2014 at 10:11:13PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 17, 2014 08:22:59 PM Matthew Garrett wrote:
> > Using the information should be fine, but my understanding of the UEFI
> > forum rules is that any submissions to UEFI specs must be from
e UEFI
forum rules is that any submissions to UEFI specs must be from UEFI
forum members - there are concerns around accidentally including
patented material. The easy way around this is just for the bindings to
be managed outside UEFI.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscrib
forum rules is that any submissions to UEFI specs must be from UEFI
forum members - there are concerns around accidentally including
patented material. The easy way around this is just for the bindings to
be managed outside UEFI.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
On Wed, Sep 17, 2014 at 10:11:13PM +0200, Rafael J. Wysocki wrote:
On Wednesday, September 17, 2014 08:22:59 PM Matthew Garrett wrote:
Using the information should be fine, but my understanding of the UEFI
forum rules is that any submissions to UEFI specs must be from UEFI
forum members
const struct acpi_device_id ahci_acpi_match[] = {
> + { "AMDI0600", 0 }, /* AMD Seattle AHCI */
> + { },
> +};
utter sadness here. Really, please don't end up in a situation where we
need to add device-specific IDs to a generic driver.
--
Matthew Garrett | mj...@srcf.ucam.org
--
T
On Wed, Sep 17, 2014 at 02:44:10AM +0100, Matthew Garrett wrote:
> On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
> > +No code shall be accepted into the kernel unless it complies with the
> > released
> > +standards from UEFI ASWG. If there are features miss
tion on a platform, ECRs should be submitted to ASWG and go through the
> +approval process.
Similar question here. Is the expectation that all ARM vendors will
become UEFI contributors?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsub
LEEP case still uses the ACPI code for powering the system
down. I'd recommend adding a new CONFIG_ACPI_POWER_OFF option, wrapping
the remaining code in sleep.c and disabling that on ARM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscrib
uses the ACPI code for powering the system
down. I'd recommend adding a new CONFIG_ACPI_POWER_OFF option, wrapping
the remaining code in sleep.c and disabling that on ARM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
be submitted to ASWG and go through the
+approval process.
Similar question here. Is the expectation that all ARM vendors will
become UEFI contributors?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Wed, Sep 17, 2014 at 02:44:10AM +0100, Matthew Garrett wrote:
On Fri, Sep 12, 2014 at 10:00:16PM +0800, Hanjun Guo wrote:
+No code shall be accepted into the kernel unless it complies with the
released
+standards from UEFI ASWG. If there are features missing from ACPI to make
[] = {
+ { AMDI0600, 0 }, /* AMD Seattle AHCI */
+ { },
+};
utter sadness here. Really, please don't end up in a situation where we
need to add device-specific IDs to a generic driver.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe
make the same policy decision as we do right now, and
the kernel isn't really the right place to do that. It does have the
benefit of allowing that policy decision to be made at boot time and
then allow that to be consumed by all later userspace, so there is
*some* benefit, but I think the "
decision to be made at boot time and
then allow that to be consumed by all later userspace, so there is
*some* benefit, but I think the make unprivileged userspace possible
argument is much more compelling.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ
return an error in secure boot mode and otherwise
> taints the kernel with a raw I/O taint.
>
> What do people think?
Not a bad plan, but there's a couple of places where you'd want to
forbid stuff in Secure Boot without tainting the kernel in the generic
use-case, so there's still some prob
the kernel with a raw I/O taint.
What do people think?
Not a bad plan, but there's a couple of places where you'd want to
forbid stuff in Secure Boot without tainting the kernel in the generic
use-case, so there's still some problem to solve there.
--
Matthew Garrett | mj...@srcf.ucam.org
nd the only command which was different 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.
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
; fit.
I've chatted 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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vge
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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/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):
about two billion bad ways to implement most of these drivers,
along with a good way). Anybody willing to take it on?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
about two billion bad ways to implement most of these drivers,
along with a good way). Anybody willing to take it on?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
/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
ops/toshiba_haps.txt
create mode 100644 drivers/platform/x86/toshiba_haps.c
--
Matthew Garrett | mj...@srcf.ucam.org
signature.asc
Description: Digital signature
/toshiba_haps.txt
create mode 100644 drivers/platform/x86/toshiba_haps.c
--
Matthew Garrett | mj...@srcf.ucam.org
signature.asc
Description: Digital signature
able to split this
into multiple functions.
--
Matthew Garrett
is powered up but
ASPM isn't enabled? Maybe you could collect more details in a
http://bugzilla.kernel.org report?
I believe that's the case. The proposed change would fix it but isn't
really terribly clean - I think it would be more readable to split this
into multiple functions.
--
Matthew
ow can anyone be sure that Microsoft will not sue about this ?
We already build a kernel that's a valid PE executable for UEFI systems.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
that Microsoft will not sue about this ?
We already build a kernel that's a valid PE executable for UEFI systems.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Tue, Jun 17, 2014 at 03:46:15PM +0100, Matthew Garrett wrote:
> On Tue, Jun 17, 2014 at 02:11:36PM +0200, Rafael J. Wysocki wrote:
> > Does applying this patch without the rest of the series makes things worse
> > or better on the machines in question (or perhaps it doesn'
On Tue, Jun 17, 2014 at 02:11:36PM +0200, Rafael J. Wysocki wrote:
> On Sunday, June 01, 2014 12:33:53 PM Matthew Garrett wrote:
> > Apple hardware queries _OSI("Darwin") in order to determine whether the
> > system is running OS X, and changes firmware behaviour based on
On Tue, Jun 17, 2014 at 02:11:36PM +0200, Rafael J. Wysocki wrote:
On Sunday, June 01, 2014 12:33:53 PM Matthew Garrett wrote:
Apple hardware queries _OSI(Darwin) in order to determine whether the
system is running OS X, and changes firmware behaviour based on the answer.
The most obvious
On Tue, Jun 17, 2014 at 03:46:15PM +0100, Matthew Garrett wrote:
On Tue, Jun 17, 2014 at 02:11:36PM +0200, Rafael J. Wysocki wrote:
Does applying this patch without the rest of the series makes things worse
or better on the machines in question (or perhaps it doesn't matter at all
alone
l machine
> addresses. However, all artificial EFI structures created under Xen live
> in dom0 memory and should be mapped/unmapped using early_mem*() family
> calls which map domain memory.
Mapped EFI regions may include memory mapped flash, not merely true RAM.
--
Matthew Garrett | m
. However, all artificial EFI structures created under Xen live
in dom0 memory and should be mapped/unmapped using early_mem*() family
calls which map domain memory.
Mapped EFI regions may include memory mapped flash, not merely true RAM.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe
On Wed, Jun 11, 2014 at 08:30:20AM -0400, Mimi Zohar wrote:
> On Wed, 2014-06-11 at 04:23 +0100, Matthew Garrett wrote:
> > Yes. Wouldn't having a mechanism to allow userspace to drop keys that
> > have otherwise been imported be a generally useful solution to the issu
On Wed, Jun 11, 2014 at 08:30:20AM -0400, Mimi Zohar wrote:
On Wed, 2014-06-11 at 04:23 +0100, Matthew Garrett wrote:
Yes. Wouldn't having a mechanism to allow userspace to drop keys that
have otherwise been imported be a generally useful solution to the issue
you have
On Tue, Jun 10, 2014 at 11:08:15PM -0400, Mimi Zohar wrote:
> On Wed, 2014-06-11 at 03:22 +0100, Matthew Garrett wrote:
> > Providing a userspace mechanism for selectively dropping keys from the
> > kernel seems like a good thing?
>
> No, patch "KEYS: veri
On Tue, Jun 10, 2014 at 09:24:53PM -0400, Mimi Zohar wrote:
> On Tue, 2014-06-10 at 22:40 +0100, Matthew Garrett wrote:
> > The hole is that the system trusts keys that you don't trust. The
> > appropriate thing to do is to remove that trust from the entire system,
> &g
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
+-
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
dor
keys, they'll be upset to discover that it's easily circumvented.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/maj
during the boot process.
Just add a sysfs knob that lets you drop the db keys and incorporate
that into the TPM management code.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
801 - 900 of 3200 matches
Mail list logo
