於 二，2012-10-30 於 13:48 -0400，Josh Boyer 提到：
On Mon, Oct 29, 2012 at 05:00:06PM +0800, joeyli wrote:
Hi Josh,
Tahashi has a good idea for use strtobool to allow
'secureboot_enable=yes' works. Please consider the following change.
Thanks a lot!
Joey Lee
From
於 三，2012-10-31 於 19:53 +0100，Takashi Iwai 提到：
At Wed, 31 Oct 2012 17:37:28 +,
Matthew Garrett wrote:
On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote:
request_firmware() is used for microcode loading, too, so it's fairly
a core part to cover, I'm afraid.
I
於 四，2012-10-04 於 09:54 +0100，Matt Fleming 提到：
On Thu, 2012-10-04 at 10:24 +0800, Lee, Chun-Yi wrote:
UEFI variable filesystem need a new mount point, so this patch add
efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
folder.
Cc: Matt Fleming matt.flem...@intel.com
Hi Jeremy,
於 五，2012-10-05 於 13:54 +0800，Jeremy Kerr 提到：
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 4174f1b..e1253d6 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -1487,6 +1487,7 @@ void unregister_efivars(struct efivars
Hi Matt,
Sorry for bother you!
I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.
Thanks a lot!
Joey Lee
於 四，2012-09-20 於 10:40 -0400，Matthew Garrett 提到：
Secure boot adds certain policy
Hi Josh,
於 二，2012-09-25 於 09:08 -0400，Josh Boyer 提到：
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.
Hi Jiri,
於 日，2013-04-14 於 23:25 +0200，Jiri Slaby 提到：
Hi,
after update to 3.8, every update of the kernel ends up in an unbootable
machine. It is due to the following commit:
commit 68d929862e29a8b52a7f2f2f86a0600423b093cd
Author: Matthew Garrett matthew.garr...@nebula.com
Date: Sat Mar
於 二，2013-04-16 於 11:11 +0100，Matt Fleming 提到：
On 16/04/13 10:56, joeyli wrote:
I think I just got the same situation on my side with Acer machine. I am
trying Matthew's new patchset hope can avoid this situation:
https://lkml.org/lkml/2013/4/15/473
Please do let us know whether
於 三，2013-04-17 於 16:29 +0200，Jiri Slaby 提到：
On 04/16/2013 12:11 PM, Matt Fleming wrote:
On 16/04/13 10:56, joeyli wrote:
I think I just got the same situation on my side with Acer machine. I am
trying Matthew's new patchset hope can avoid this situation:
https://lkml.org/lkml/2013/4/15
於 三，2013-04-17 於 22:50 +0800，joeyli 提到：
於 三，2013-04-17 於 16:29 +0200，Jiri Slaby 提到：
On 04/16/2013 12:11 PM, Matt Fleming wrote:
On 16/04/13 10:56, joeyli wrote:
I think I just got the same situation on my side with Acer machine. I am
trying Matthew's new patchset hope can avoid
於 一，2013-04-22 於 11:37 +0930，Rusty Russell 提到：
Lee, Chun-Yi joeyli.ker...@gmail.com writes:
From: Chun-Yi Lee j...@suse.com
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier
Hi David,
Sorry for bother you!
Will you take this patch for merge to v3.10 kernel?
Thanks a lot!
Joey Lee
於 五，2013-03-29 於 16:52 +0800，Lee, Chun-Yi 提到：
From: Chun-Yi Lee j...@suse.com
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:
於 四，2013-03-14 於 15:34 +0800，Lee, Chun-Yi 提到：
From: Chun-Yi Lee j...@suse.com
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
Hi experts,
I didn't this patch merged to any git tree or maybe I missed.
Where is the right place for send X.509 patch?
Thanks a lot!
Joey Lee
於 四，2013-03-14 於 15:34 +0800，Lee, Chun-Yi 提到：
From: Chun-Yi Lee j...@suse.com
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
於 四，2013-03-07 於 11:39 +，Matt Fleming 提到：
This patch works on a normal UEFI machine, we will test it on HP
z220. I
will send out it formally after test success.
Has anyone tried contacting HP to tell them their firmware is doing
bizarre things?
We will try to contact with HP
Hi Matt,
於 四，2013-03-07 於 13:57 +，Matt Fleming 提到：
On Thu, 2013-03-07 at 11:39 +, Matt Fleming wrote:
On Thu, 2013-03-07 at 18:34 +0800, joeyli wrote:
The VariableNameSize is not reliable when EFI_SUCCESS is returned
because UEFI 2.3.1 spec only mention VariableNameSize should
Hi Matt,
Sorry for I didn't aware your 123abd76edf patch fixed issue.
Please ignore my patch.
Thanks a lot!
Joey Lee
於 二，2013-03-12 於 03:00 +0800，Lee, Chun-Yi 提到：
We mount efivarfs fail after pstore generated 'dump-type*' variables and
reboot.
This issue introduced by commit
Hi Matt,
於 六，2013-03-02 於 07:41 +0800，joeyli 提到：
於 五，2013-03-01 於 16:31 +，Matt Fleming 提到：
On Fri, 2013-03-01 at 15:17 +, Matt Fleming wrote:
On Fri, 2013-03-01 at 11:20 +0800, Lee, Chun-Yi wrote:
From: Michael Schroeder m...@suse.com
On HP z220 system (firmware
於 三，2013-03-06 於 15:34 +0800，joeyli 提到：
Hi Matt,
於 六，2013-03-02 於 07:41 +0800，joeyli 提到：
於 五，2013-03-01 於 16:31 +，Matt Fleming 提到：
On Fri, 2013-03-01 at 15:17 +, Matt Fleming wrote:
On Fri, 2013-03-01 at 11:20 +0800, Lee, Chun-Yi wrote:
From: Michael Schroeder m
於 三，2013-03-06 於 17:20 +0800，Lingzhu Xiang 提到：
On 03/06/2013 03:34 PM, joeyli wrote:
+static unsigned long variable_name_length(efi_char16_t *variable_name)
+{
+ unsigned long len;
+ efi_char16_t c;
+
+ len = 2;
+ do {
+ c = variable_name[len / sizeof(c) - 1
於 三，2013-03-06 於 11:19 +，Matt Fleming 提到：
On Wed, 2013-03-06 at 15:34 +0800, joeyli wrote:
...
+static unsigned long variable_name_length(efi_char16_t *variable_name)
+{
+ unsigned long len;
+ efi_char16_t c;
+
+ len = 2;
+ do {
+ c = variable_name[len
Hi Matt,
於 四，2013-03-07 於 13:57 +，Matt Fleming 提到：
On Thu, 2013-03-07 at 11:39 +, Matt Fleming wrote:
On Thu, 2013-03-07 at 18:34 +0800, joeyli wrote:
The VariableNameSize is not reliable when EFI_SUCCESS is returned
because UEFI 2.3.1 spec only mention VariableNameSize should
於 三，2013-02-06 於 13:08 +0800，Lee, Chun-Yi 提到：
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Exception is:
^^ Extension
Sorry for my typo, I will send patch again.
Thanks
Joey Lee
AuthorityKeyIdentifier ::= SEQUENCE {
於 三，2013-01-30 於 12:19 -0500，Youquan Song 提到：
There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d fix the 4
ports
IDE controller 32bit PIO mode.
Recently, the problem was showed at Haswell platform which includes 2 ports
IDE controller.
So introduce a qurik patch to disable
於 五，2013-03-01 於 17:31 +0800，Lingzhu Xiang 提到：
On 03/01/2013 11:20 AM, Lee, Chun-Yi wrote:
From: Michael Schroeder m...@suse.com
On HP z220 system (firmware version 1.54), some EFI variables are
incorrectly
named :
ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns
於 五，2013-03-01 於 16:31 +，Matt Fleming 提到：
On Fri, 2013-03-01 at 15:17 +, Matt Fleming wrote:
On Fri, 2013-03-01 at 11:20 +0800, Lee, Chun-Yi wrote:
From: Michael Schroeder m...@suse.com
On HP z220 system (firmware version 1.54), some EFI variables are
incorrectly
named
Hi David,
First, thanks for your review and comments!
於 三，2013-02-13 於 13:47 +，David Howells 提到：
Lee, Chun-Yi joeyli.ker...@gmail.com wrote:
Signed-off-by: Lee, Chun-Yi j...@suse.com
Without the comma, please.
+ /* Short Form length */
+ if (vlen = 127) {
Hi Paul,
Sorry for I am late to reply your patch.
於 四，2013-01-24 於 14:12 +0100，Paul Bolle 提到：
Commit f20aaba9819d0801fb1314363f97239da0100bac (acer-wmi: fix obj is
NULL but dereferenced) introduced a GCC warning:
drivers/platform/x86/acer-wmi.c: In function ‘acer_wmi_init’:
於 二，2013-02-19 於 09:07 +0100，Paul Bolle 提到：
Joey.
On Tue, 2013-02-19 at 10:38 +0800, joeyli wrote:
Zhang Rui sent similar patch for fix the warning:
http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg04016.html
I see. It didn't make it into the v3.8 release. Could
於 三，2013-02-20 於 12:49 +，David Howells 提到：
Chun-Yi Lee joeyli.ker...@gmail.com wrote:
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier
於 四，2013-02-21 於 15:35 +1030，Rusty Russell 提到：
joeyli j...@suse.com writes:
於 三，2013-02-20 於 12:49 +，David Howells 提到：
Acked-by: David Howells dhowe...@redhat.com
Thanks for David's review and confirm.
Should this be CC stable?
Thanks,
Rusty.
IMHO this patch need Cc
Hi David,
Thanks for your review and point out!
於 四，2013-02-21 於 14:16 +，David Howells 提到：
+ifneq ($(shell pwd), $(srctree))
How reliable is this, I wonder?
David
My current shell is bash, and I tried the '$(shell pwd)' in Makefile
works for grab the REAL path when the build path
於 四，2012-09-20 於 10:41 -0400，Matthew Garrett 提到：
From: Josh Boyer jwbo...@redhat.com
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the
On Thu, 2012-09-06 at 13:40 +0800, Jeremy Kerr wrote:
From: Matthew Garrett m...@redhat.com
The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI
specification,
but was removed before any full releases. Since
於 二，2012-09-11 於 15:23 +0800，lee joey 提到：
From: Matthew Garrett m...@redhat.com
The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI
specification,
but was removed before any full releases. Since variables can now be
Hi Peter,
於 四，2012-09-13 於 09:52 -0400，Peter Jones 提到：
On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
Do we have plan to create a new kobject add to /sys/firmware/efi for
provide a fixed mount point to efivars fs?
e.g. /sys/firmware/efi/efivars
Or we just direct reuse current
於 二，2012-09-11 於 15:23 +0800，lee joey 提到：
From: Matthew Garrett m...@redhat.com
The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI
specification,
but was removed before any full releases. Since variables can now be
於 四，2012-09-13 於 21:41 -0700，H. Peter Anvin 提到：
On 09/13/2012 08:45 PM, joeyli wrote:
Hi Peter,
於 四，2012-09-13 於 09:52 -0400，Peter Jones 提到：
On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
Do we have plan to create a new kobject add to /sys/firmware/efi for
provide a fixed mount
於 一，2012-08-20 於 23:01 +0200，Corentin Chary 提到：
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
drivers/platform/x86/acer-wmi.c |2 --
drivers/platform/x86/apple-gmux.c |4
drivers/platform/x86/asus-wmi.c |4
於 四，2012-11-08 於 18:35 +0100，Takashi Iwai 提到：
Add a new option -a to sign-file for specifying the hash algorithm
to sign a file, to make it working without .config file.
This will be useful signing external module or firmware files.
Signed-off-by: Takashi Iwai ti...@suse.de
Tested-by:
於 四，2012-11-08 於 18:35 +0100，Takashi Iwai 提到：
Add -f option to sign-file script for generating a firmware signature
file.
A firmware signature file contains a pretty similar structure like a
signed module but in a different order (because it's a separate file
while the module signature is
於 四，2012-11-08 於 18:35 +0100，Takashi Iwai 提到：
... when CONFIG_FIRMWARE_SIG is set.
Signed-off-by: Takashi Iwai ti...@suse.de
Tested-by: Chun-Yi Lee j...@suse.com
Joey Lee
---
Makefile| 6 ++
scripts/Makefile.fwinst | 18 --
2 files changed, 22
於 四，2012-11-08 於 18:35 +0100，Takashi Iwai 提到：
+#ifdef CONFIG_FIRMWARE_SIG
+static int verify_sig_file(struct firmware_buf *buf, const char
*path)
+{
+ const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) -
1;
+ struct file *file;
+ void *sig_data;
+ size_t
於 一，2012-11-26 於 21:35 +0300，Sergey Senozhatsky 提到：
Add Aspire 5741G KEY_TOUCHPAD_TOGGLE to wmi keymap, preventing
acer_wmi: Unknown key number - 0x85 error.
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Signed-off-by: Lee, Chun-Yi j...@suse.com
Thanks for you resend your
於 五，2012-12-28 於 17:43 +，Matthew Garrett 提到：
On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime()
are also
supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
This patch changed RTC_DRV_EFI
Hi hpa,
於 五，2012-12-28 於 15:44 -0800，H. Peter Anvin 提到：
On 12/28/2012 12:49 PM, Matthew Garrett wrote:
On Fri, 2012-12-28 at 12:40 -0800, H. Peter Anvin wrote:
I suspect that what we *should* do looks like:
1. If ACPI exports a Time and Alarm Device (ACPI000E) the use it;
2. If
Hi Fabio,
於 日，2013-01-13 於 23:11 +0100，Fabio Coatti 提到：
Hi all,
on my laptop (hp folio 9470m), the rfkill button works fine on 3.6.10
Does rfkill button means Fn+F12 key on your machine?
and 11 (don't know about older kernels), but is not working on 3.7.X
(latest tested is 3.7.2).
On non
-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Feng Tang feng.t...@intel.com
Signed-off-by: Len Brown len.br...@intel.com
I discovered that reverting this commit (or, as suggested by joeyli
j...@suse.com, booting with acpi_osi=!Windows 2012 ) also fixes
the brightness issue. So
於 五，2012-12-28 於 17:07 -0800，H. Peter Anvin 提到：
On 12/28/2012 05:00 PM, joeyli wrote:
於 五，2012-12-28 於 17:43 +，Matthew Garrett 提到：
On Sat, 2012-12-29 at 00:26 +0800, Lee, Chun-Yi wrote:
UEFI time services, GetTime(), SetTime(), GetWakeupTime(),
SetWakeupTime() are also
supported
Hi Pavel,
First, thanks for your review!
於 日，2013-08-25 於 17:53 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:41, Lee, Chun-Yi wrote:
Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
first step of signature generation operation
(RSASSA-PKCS1-v1_5-SIGN).
Is this
於 日，2013-08-25 於 18:01 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:42, Lee, Chun-Yi wrote:
Due to RSA_I2OSP is not only used by signature verification path but also
used
in signature generation path. So, separate the length checking of octet
string
because it's not for generate
Hi Pavel,
Thanks for your time to review my patches.
於 日，2013-08-25 於 18:36 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:51, Lee, Chun-Yi wrote:
This patch add the code for generate/verify signature of snapshot, it
put the signature to snapshot header. This approach can support both
on
於 日，2013-08-25 於 18:39 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:52, Lee, Chun-Yi wrote:
This patch add swsusp_page_is_sign_key() method to hibernate_key.c and
check the page is S4 sign key data when collect saveable page in
snapshot.c to avoid sign key data included in snapshot image.
Hi Pavel,
於 日，2013-08-25 於 18:25 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:50, Lee, Chun-Yi wrote:
Introduced a hibernate_key.c file to query the key pair from EFI variables
and maintain key pair for check signature of S4 snapshot image. We
loaded the private key when snapshot image
於 日，2013-08-25 於 18:42 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:54, Lee, Chun-Yi wrote:
In current solution, the snapshot signature check used the RSA key-pair
that are generated by bootloader(e.g. shim) and pass the key-pair to
kernel through EFI variables. I choice to binding the
於 日，2013-08-25 於 18:43 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote:
This patch introduced SNAPSHOT_SIG_HASH config for user to select which
hash algorithm will be used during signature generation of snapshot.
v2:
Add define check of
於 二，2013-08-27 於 13:30 +0200，Pavel Machek 提到：
On Tue 2013-08-27 18:22:17, joeyli wrote:
於 日，2013-08-25 於 18:43 +0200，Pavel Machek 提到：
On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote:
This patch introduced SNAPSHOT_SIG_HASH config for user to select which
hash algorithm will be used
於 二，2013-08-27 於 13:29 +0200，Pavel Machek 提到：
@@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle,
efi_system_table_t *_table,
setup_efi_pci(boot_params);
+#ifdef CONFIG_SNAPSHOT_VERIFICATION
+ setup_s4_keys(boot_params);
+#endif
Hi all experts,
Does there have any suggestions or comments for this patch to asymmetric
keys?
Thanks a lot!
Joey Lee
於 五，2013-07-12 於 11:11 +0800，Lee, Chun-Yi 提到：
From: Chun-Yi Lee j...@suse.com
Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in
its first 2
於 二，2013-09-10 於 18:26 +，Matthew Garrett 提到：
On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
That's why modern systems require signed firmware updates.
Linux doesn't. Is someone working on adding signature support to
Hi Dmitry,
First, thanks for your time to review my patches!
於 二，2013-09-17 於 16:51 -0500，Dmitry Kasatkin 提到：
Hello,
On Sat, Sep 14, 2013 at 7:56 PM, Lee, Chun-Yi joeyli.ker...@gmail.com wrote:
Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
first step of
於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
(2013/11/19 12:16), Madper Xie wrote:
isimatu.yasu...@jp.fujitsu.com writes:
Hi Matt,
Sorry for late the reply.
(2013/11/11 19:54), Matt Fleming wrote:
On Mon, 11 Nov, at 05:52:59PM, Yasuaki Ishimatsu wrote:
Hi Matt,
I
於 四，2013-11-21 於 18:13 +0900，Yasuaki Ishimatsu 提到：
(2013/11/20 17:08), joeyli wrote:
於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
(2013/11/19 12:16), Madper Xie wrote:
isimatu.yasu...@jp.fujitsu.com writes:
Hi Matt,
Sorry for late the reply.
(2013/11/11 19:54), Matt
於 四，2013-11-21 於 17:53 +0800，joeyli 提到：
於 四，2013-11-21 於 18:13 +0900，Yasuaki Ishimatsu 提到：
(2013/11/20 17:08), joeyli wrote:
於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到：
(2013/11/19 12:16), Madper Xie wrote:
isimatu.yasu...@jp.fujitsu.com writes:
Hi Matt,
Sorry
Hi Rafael,
於 三，2014-03-12 於 14:30 +0100，Rafael J. Wysocki 提到：
But I wonder: Can we simply enable SCI later? In other words, can
we
split acpi_early_init() so that the part before
acpi_enable_subsystem()
is done before timekeeping_init() and the part including and after
is done right
於 四，2014-03-13 於 01:54 +0100，Thomas Gleixner 提到：
On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
Thus follow the original idea to execute acpi_early_init() before
efi_enter_virtual_mode() to help the EFI people for now and we can
revisit the other problem that commit 73f7d1ca3263 attempted to
於 四，2014-03-13 於 00:49 +0100，Thomas Gleixner 提到：
On Thu, 13 Mar 2014, Rafael J. Wysocki wrote:
I agree, and we need to fix that for 3.14. Patch is appended.
You beat me by a few minutes. Was about to send out the same, just
with a more spicy changelog :)
---
From: Rafael J. Wysocki
於 三，2014-03-12 於 20:11 -0700，H. Peter Anvin 提到：
On 03/12/2014 07:38 PM, joeyli wrote:
I sent rtc-acpitad driver for RTC subsystem on last month, I will send
second version.
For using TAD to set wall clock is because in ACPI 5.0 spec, there have
a CMOS RTC Not Present flag in FADT
於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
On 03/12/2014 08:55 PM, joeyli wrote:
So do not care CMOS RTC Not Present, if TAD is present then we use it
instead of CMOS RTC in all kernel code? or we still can use CMOS RTC?
Why would we use *both*!? How would that possibly make
於 四，2014-03-13 於 09:12 +0100，Thomas Gleixner 提到：
On Thu, 13 Mar 2014, joeyli wrote:
於 三，2014-03-12 於 20:59 -0700，H. Peter Anvin 提到：
On 03/12/2014 08:55 PM, joeyli wrote:
So do not care CMOS RTC Not Present, if TAD is present then we use it
instead of CMOS RTC in all kernel code
Hi Herbert,
於 一，2014-03-10 於 19:57 +0800，Herbert Xu 提到：
On Mon, Mar 10, 2014 at 05:22:51PM +0800, Lee, Chun-Yi wrote:
When allocate crypto algorithms, e.g. crypto_alloc_shash(), using
template model will run into the path that call module_request().
But there have no any module alias that
Hi Julian,
於 二，2014-03-11 於 18:15 +0100，Julian Wollrath 提到：
Am Tue, 11 Mar 2014 14:56:41 +0100 (CET)
schrieb Thomas Gleixner t...@linutronix.de:
Ok, via bisecting I found commit
73f7d1ca32638028e3271f54616773727e2f9f26 (see below) to be the one
that introduced this regression.
於 三，2014-03-12 於 11:20 +0100，Julian Wollrath 提到：
This patch restricts the position to run acpi_early_init() before
timekeeping_init() when only CMOS RTC Not Present bit set in FADT.
Could you please help to test it on your machine?
That patch fixes the problem, thank you.
Cheers,
於 三，2014-03-12 於 12:20 +0100，Rafael J. Wysocki 提到：
On Wednesday, March 12, 2014 12:00:07 PM joeyli wrote:
Hi Julian,
[...]
From 8ef4fff76dd2f50bef1e8eb9c96f3b0228a38401 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi j...@suse.com
Date: Wed, 12 Mar 2014 11:36:32 +0800
Subject: [PATCH
於 日，2014-01-12 於 01:30 +0100，Rafael J. Wysocki 提到：
OK
I don't see any adverse effects of the patch below on a couple of my
test
boxes, but (a) they are Intel-based and (b) they are non-EFI, so it
would be
good to give it a go on as many machines as reasonably possible.
Thanks,
Rafael
於 日，2013-06-09 於 19:01 -0400，Matthew Garrett 提到：
Windows 8 leaves backlight control up to individual graphics drivers rather
than making ACPI calls itself. There's plenty of evidence to suggest that
the Intel driver for Windows doesn't use the ACPI interface, including the
fact that it's
Hi Zach,
於 二，2013-06-11 於 07:52 +0100，Matt Fleming 提到：
From: Zach Bobroff zacha...@ami.com
ExitBootServices is absolutely supposed to return a failure if any
ExitBootServices event handler changes the memory map. Basically the
get_map loop should run again if ExitBootServices returns an
於 一，2013-06-17 於 11:17 +0100，Matt Fleming 提到：
On Mon, 17 Jun, at 10:46:28AM, Jan Beulich wrote:
To me, all this looks like it is being done on phenomenological basis,
taking a particular build of a particular firmware implementation as
the reference. Imo we shouldn't change the code in this
Hi Zach,
於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
All,
Why a single retry is having reasonable guarantees to work when the
original one failed (nothing prevents an event handler to do another
allocation the next time through).
This patch is being submitted because of the
on any subsequent call to exitbootservices, so the map should
stay the same then.
Sent from my iPhone
On Jun 17, 2013, at 10:48 PM, joeyli j...@suse.com wrote:
Hi Zach,
於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
All,
Why a single retry is having reasonable guarantees
Hi Dmitry,
Thanks for your review and suggestions first!
於 一，2013-04-22 於 21:12 -0700，Dmitry Torokhov 提到：
On Mon, Apr 22, 2013 at 08:39:15PM +0800, Chun-Yi Lee wrote:
From: Lee, Chun-Yi j...@suse.com
+static acpi_status
+find_video_unregister_backlight(acpi_handle handle, u32 lvl, void
Hi Dmitry,
Thanks for your review and suggestion!
於 一，2013-04-22 於 21:04 -0700，Dmitry Torokhov 提到：
On Mon, Apr 22, 2013 at 08:39:14PM +0800, Chun-Yi Lee wrote:
From: Lee, Chun-Yi j...@suse.com
After Andrzej's testing, we found the acpi backlight methods broken on Acer
Aspire 5750G but
於 五，2013-04-26 於 13:24 +0800，Aaron Lu 提到：
On 04/22/2013 08:39 PM, Chun-Yi Lee wrote:
From: Lee, Chun-Yi j...@suse.com
There have situation we unregister whole acpi/video driver by downstream
driver
just want to remove backlight control interface of acpi/video. It caues we
lost
於 六，2013-04-27 於 01:19 +0800，Lee, Chun-Yi 提到：
That will be better initial the value of DataSize to zero for the input of
GetVariable(), otherwise we will feed a random value. The debug log of input
DataSize like this:
...
[ 195.915612] EFI Variables Facility v0.08 2004-May-17
[
於 一，2013-04-29 於 18:25 +0800，joeyli 提到：
於 六，2013-04-27 於 01:19 +0800，Lee, Chun-Yi 提到：
That will be better initial the value of DataSize to zero for the input of
GetVariable(), otherwise we will feed a random value. The debug log of input
DataSize like this:
...
[ 195.915612] EFI
於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
Oliver raised a question for if power fails between that succesful
attempt and the deletion?
It's a pretty tiny window, but sure. Making sure we delete it seems
sensible. In that case we
於 三，2013-06-05 於 16:08 +，Matthew Garrett 提到：
On Wed, 2013-06-05 at 16:59 +0100, Matt Fleming wrote:
+ /* clean DUMMY object */
+ efi.set_variable(efi_dummy_name, EFI_DUMMY_GUID, 0, 0, NULL);
Hm. Actually, is that going to work? From the spec:
The patch I tested on OVMF, it can
於 三，2013-06-05 於 16:59 +0100，Matt Fleming 提到：
On Wed, 05 Jun, at 02:53:27PM, Matthew Garrett wrote:
On Wed, 2013-06-05 at 15:49 +0100, Fleming, Matt wrote:
Folks, what do you want me to do with this? Merge it with Matthew's patch?
Do that and add Joey's signed-off-by?
Right, this
於 四，2013-06-06 於 13:05 +0800，joeyli 提到：
於 三，2013-06-05 於 16:59 +0100，Matt Fleming 提到：
On Wed, 05 Jun, at 02:53:27PM, Matthew Garrett wrote:
On Wed, 2013-06-05 at 15:49 +0100, Fleming, Matt wrote:
Folks, what do you want me to do with this? Merge it with Matthew's
patch
於 四，2013-06-06 於 05:42 +，Matthew Garrett 提到：
On Thu, 2013-06-06 at 13:05 +0800, joeyli wrote:
+ if (!(attributes EFI_VARIABLE_NON_VOLATILE))
+ return EFI_OUT_OF_RESOURCES;
I'd move this up to the top of the function, and just return 0 - there's
no risk
於 四，2013-05-30 於 00:53 +0200，Jiri Kosina 提到：
On Wed, 29 May 2013, Russ Anderson wrote:
Yes, but this call is clearly happening way before ExitBootServices() --
see the surrounding code, see for example this in efi_main():
[ ... snip ... ]
setup_efi_vars(boot_params);
於 三，2013-05-29 於 17:46 -0500，Russ Anderson 提到：
On Thu, May 30, 2013 at 12:22:13AM +0200, Jiri Kosina wrote:
On Wed, 29 May 2013, Russ Anderson wrote:
What appears to be happening is that your the EFI runtime services code
is calling into the EFI boot services code, which is
於 四，2013-05-30 於 21:17 -0500，Russ Anderson 提到：
On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
On Thu, 30 May 2013, Russ Anderson wrote:
That's a great idea. This patch moves the QueryVariableInfo()
call from bootime to runtime, in efi_late_init(). The attached
於 六，2013-06-01 於 16:06 -0400，Matthew Garrett 提到：
+ unsigned long dummy_size = remaining_size + 1024;
+ void *dummy = kmalloc(dummy_size, GFP_ATOMIC);
+ efi_char16_t efi_name[6] = { 'D', 'U', 'M', 'M', 'Y', 0 };
+ efi_guid_t guid =
於 一，2013-04-22 於 12:07 +0100，Matt Fleming 提到：
On 20/04/13 08:40, Jiri Slaby wrote:
On 04/18/2013 08:07 PM, Jiri Slaby wrote:
On 04/17/2013 04:51 PM, Matt Fleming wrote:
On 17/04/13 15:29, Jiri Slaby wrote:
On 04/16/2013 12:11 PM, Matt Fleming wrote:
On 16/04/13 10:56, joeyli wrote:
I
Hi all,
於 一，2013-04-15 於 13:09 -0700，Matthew Garrett 提到：
EFI implementations distinguish between space that is actively used by a
variable and space that merely hasn't been garbage collected yet. Space
that hasn't yet been garbage collected isn't available for use and so isn't
counted in the
於 三，2013-04-24 於 10:14 +，Matthew Garrett 提到：
On Wed, 2013-04-24 at 18:08 +0800, joeyli wrote:
It causes the garbage size increased and remaining_size decreased. But
we still can create new variable because active_size doesn't increase
due to we delete variable before create new. So
於 三，2013-04-24 於 11:57 +，Matthew Garrett 提到：
On Wed, 2013-04-24 at 18:59 +0800, joeyli wrote:
Then why we don't just remove the remaining_size condition but only
monitor the active_size should not larger then 1/2 storage_size?
If we calculate active_size as using more than 50
Hi Dave,
於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
Russ,
Can we open a bug for the BIOS folks and see if we can get this
addressed?
I already
於 一，2013-05-27 於 12:27 +0800，joeyli 提到：
Hi Dave,
於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
Russ,
Can we open a bug for the BIOS folks and see
1 - 100 of 706 matches
Mail list logo
