On Mon, 3 Aug 2020 at 10:57, Mika Westerberg
wrote:
> I think instead of this we should simply make it so that the driver
> never tries to make the chip writable.
I think this is a good idea, but I wasn't sure if it was an acceptable
behaviour change. Should the driver still try to set BCR_WPD wh
On Tue, 30 Jun 2020 at 09:56, Greg Kroah-Hartman
wrote:
> Again, which makes it seem like securityfs is not the thing for this, as
> it describes the hardware, not a security model which is what securityfs
> has been for in the past, right?
It describes the hardware platform. From a fwupd perspec
On Fri, 19 Jun 2020 at 20:41, Andy Lutomirski wrote:
> I don't object in principle to Linux giving userspace more visibility
> into what's going on, but I'm not convinced that adding a new
> must-support-for-a-long-time interface that only solves 5% of your
> problem is worth it.
At the moment th
On Fri, 19 Jun 2020 at 17:41, Greg Kroah-Hartman
wrote:
> > Yes. I want to show the user *why* TME is not available.
> So even if it is "available" that's fine, even if it is not being used?
No, it's just one more thing we can check and report. For instance,
"Full memory encryption: NO [firmware-
On Fri, 19 Jun 2020 at 17:10, Borislav Petkov wrote:
> - do you just want to display feature support?
Yes. I want to show the user *why* TME is not available.
Richard.
On Fri, 19 Jun 2020 at 17:17, Borislav Petkov wrote:
> Well, I believe all the kernel can do is supply bits of information -
> just like MSRs - and depending on the settings of those bits, userspace
> can decide what the situation is. For example:
> bit 0 - CPUID support
> bit 1 - BIOS enabled
Ye
On Fri, 19 Jun 2020 at 15:48, Dave Hansen wrote:
> You cut out the important part. The "pretty sure" involves a bunch of
> preconditions and knowing what your hardware configuration is in the
> first place.
Totally agree.
> Let's take a step back. We add read-only ABIs so that decisions can be
On Fri, 19 Jun 2020 at 15:23, Dave Hansen wrote:
> Last night, I asked my kids if they brushed their teeth. They said:
> "Dad, my toothbrush was available." They argued that mere availability
> was a better situation than not *having* a toothbrush. They were
> logically right, of course, but th
On Fri, 19 Jun 2020 at 14:58, Dave Hansen wrote:
> > Right, but for the most part you'd agree that a machine with
> > functioning TME and encrypted swap partition is more secure than a
> > machine without TME?
>
> Nope. There might be zero memory connected to the memory controller
> that supports
On Fri, 19 Jun 2020 at 14:44, Borislav Petkov wrote:
> Yes, this is what I'm proposing with clearing the flag in /proc/cpuinfo.
> The needed information is there:
> 1. TME in CPUID
> 2. TME *not* in /proc/cpuinfo
No, it's not a boolean at all. If the platform disable is a BIOS
configuration we do
On Fri, 19 Jun 2020 at 14:33, Dave Hansen wrote:
> On top of that, the kernel can just swap data out to unencrypted storage.
Right, but for the most part you'd agree that a machine with
functioning TME and encrypted swap partition is more secure than a
machine without TME?
> So, I really wonder
On Fri, 19 Jun 2020 at 14:22, Borislav Petkov wrote:
> And how is the user going to know from your "module"? AFAICT, your
> module loads on any system - not only on ones which have MKTME in CPUID.
I maintain fwupd, which would be one consumer of this information. At
the moment we already look at
On Fri, 19 Jun 2020 at 00:52, Dave Hansen wrote:
> It doesn't tell you if your data is encrypted.
Sorry for the perhaps naive question, but I thought MKTME was
essentially full physical memory encryption?
Richard
On Thu, 14 May 2020 at 13:15, Mika Westerberg
wrote:
> > +What:/sys/kernel/security/firmware/bioswe
> Should this still be "firmware_protections" or similar. Plain "firmware"
> sounds again too generic. Maybe its just me..
It's not always going to be protections provided by the fi
to indeed start using git-send-email. :(
Thanks,
Richard.
>From 0b395efde8da7d5099c87945def473ff164d1c4c Mon Sep 17 00:00:00 2001
From: Richard Hughes
Date: Mon, 11 May 2020 14:19:27 +0100
Subject: [PATCH] mfd: Export LPC attributes for the system SPI chip
Export standard SPI-specific config values from vario
On Wed, 13 May 2020 at 10:11, Mika Westerberg
wrote:
> > I can fix up all those, but out of interest how did you "know" the
> > right three digit identifier to use?
> I work for Intel ;-)
Hah, okay, thanks :)
> > I'm really wondering if drivers/mfd/lpc_ich.c is the right place for
> > this kind
On Wed, 13 May 2020 at 08:08, Mika Westerberg
wrote:
> I think this one should contain KernelVersion as well, see
> Documentation/ABI/README.
Thanks, I'll fix that up.
> I think you can always include this header without #ifs
Thanks.
> > static struct resource wdt_ich_res[] = {
> > @@ -221,6
report the security
level of the platform without rebooting and running an EFI binary like
chipsec.
Signed-off-by: Richard Hughes
---
Documentation/ABI/testing/sysfs-security-spi | 17 ++
drivers/mfd/lpc_ich.c| 225 ++-
include/linux/platform_data/intel-spi.h
On Sun, 2007-07-29 at 23:36 +0200, Rafael J. Wysocki wrote:
> On Sunday, 29 July 2007 23:18, Adrian Bunk wrote:
> > On Sun, Jul 29, 2007 at 11:17:20PM +0200, Rafael J. Wysocki wrote:
> > > On Sunday, 29 July 2007 22:40, Adrian Bunk wrote:
> > > > On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J.
On Thu, 2007-07-12 at 17:46 +0800, Zhang, Rui wrote:
>
> I'm not sure if the button sysfs I/F is already finished.
> We'd better make a double check. :)
We need a button sysfs interface? What's wrong with just using input?
Richard.
-
To unsubscribe from this list: send the line "unsubscribe li
On Thu, 2007-07-12 at 09:32 +0400, Alexey Starikovskiy wrote:
> >> [*] Does someone have an alternative for
> >> /proc/acpi/battery/BAT1/{state,info}?
> I'm working on it. Should have proto by the end of week.
If you are using the power_supply class (i hope you are ;-) then a HAL
from freedesktop
t is the event will
not be sent.
Signed-off-by: Richard Hughes <[EMAIL PROTECTED]>
--- Begin Message ---
On resume we need to refresh the lid status as we will not get an event if
the lid opening was what triggered the suspend.
This manifests itself in users never getting a "lid open
On Tue, 2007-06-26 at 11:02 +0100, Richard Purdie wrote:
> There were some other opinions voiced including one from the person
> who started this discussion.
>
> So no, the people who write the tools that parse sysfs (like HAL.)
> don't appreciate this.
>
> People who write tools that parse sysfs
On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote:
> Richard Hughes wrote:
> > On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
> > > None of the above keys generated a key event. Neither does
> "Brightness
> > > down", but it still works
On Mon, 2007-06-25 at 22:49 +0200, Bartók Albert wrote:
> GMail On 16/06/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > On Saturday 16 June 2007 13:11, Richard Hughes wrote:
> > > On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> > > > On Fr
On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
> None of the above keys generated a key event. Neither does "Brightness down",
> but it still works. "Brightness up" generates an event and works. Kpowersave
> tells me it can't do brightness switching in software (which works in
> WinXtr
On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > On 6/15/07, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > > in respons
On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> On 6/15/07, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > in response to an event, but I'm thinking in a resume hook we should
> > > pr
On Thu, 2007-06-14 at 19:56 +, Pavel Machek wrote:
>
> noapic/nolapic will not help with video issue. try s2ram from
> suspend.sf.net.
Also there is (unashamed plug)
http://people.freedesktop.org/~hughsient/quirk/
Richard.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Sun, 2007-06-10 at 12:11 +0200, Pavel Machek wrote:
> Can we keep the original naming? spitz:disk is as unique as led02, and
> it is _way_ easier to use.
> Come on, I want to use the led subsystem from the scripts...
I don't see a problem with spitz_disk, which is just as easy to use in
script
On Fri, 2007-06-08 at 10:23 -0400, Dmitry Torokhov wrote:
> On 6/7/07, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
> > >
> > >
> > > It looks like KEY_COFFE comes from 0x0c/0x19e - AL Ter
On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
>
>
> It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
> Lock/Screensaver
> so your interpretation is indeed correct. I guess I better add an
> alias to
> input.h
What's the status of this patch? Good for merging? Do you want m
d to input.h.
>
> Iam still struggling with the purpose of the key. What would you
> extect to happen when youser presses this key? Screen gets locked?
> KEY_SCREENLOCK? KEY_SCREENSAVER?
Either of these keys would be good to add.
So yes, patch looks good, cheers for the improvements.
S
On Fri, 2007-06-01 at 16:43 +0100, Richard Purdie wrote:
> On Fri, 2007-06-01 at 16:04 +0100, Richard Hughes wrote:
> > Patch attached corrects all the brokenness with the led class (encoding
> > some attributes in the device handle).
>
> For the benefit of LKML, there has be
On Thu, 2007-05-31 at 00:24 -0700, Greg KH wrote:
> On Wed, May 30, 2007 at 05:19:31PM +0100, Richard Purdie wrote:
> > On Wed, 2007-05-30 at 16:34 +0100, Richard Hughes wrote:
> > > I've talked with other kernel guys here at red hat and they don't think
> > >
_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
* engineering the Windows drivers
* Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
* Rob Miller - TV out and hotkeys help
- *
+ * Richard Hughes - emit INPUT events for hotkeys
*
* TODO
*
*/
-#define TOSHIBA_ACPI_VERSIO
On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
> Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
> toshiba supplied daemon that polls, so I think we have to just bite the
> bullet.
... adding in reply in different thread...
On Thu, 2007-05-31 at 10
On Thu, 2007-05-31 at 13:53 +0100, Bastien Nocera wrote:
> On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
> > Attached patch adds a kernel thread to do polling on Toshiba hardware.
> >
> > Toshiba hardware is a little oddball, and does not provide ACPI events
&g
ch involve switching to a workqueue for the
polling, not breaking the spaces in "hotkeys_via_input" and also masking
out the fn key button up.
toshiba_acpi.c | 228 +++--
1 file changed, 206 insertions(+), 22 deletions(-)
Signed-
On Thu, 2007-01-04 at 13:28 -0800, Andrew Morton wrote:
> On Thu, 4 Jan 2007 22:18:30 +0100
> Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > > The place to start (please) is the patches in -mm:
> > >
> > > 2.6-sony_acpi4.patch
> > > sony_apci-resume.patch
> > > sony_apci-resume-fix.patch
> > > a
development branch, but ov511 is from the
stable branch. Not sure about that. Best bet is contact Mark McClelland
(maintainer) here:
mmcclell calpoly.edu
or mark alpha.dyndns.org
Richard Hughes
--
http://www.hughsie.com/PUBLIC-KEY
-
To unsubscribe from this list: send the line "unsubscr
Con Kolivas kolivas.org> writes:
> >>I'm not sure how the list of intefaces is probed on this machine, that's
> >>probably where the problem is.
>
> I've read that people have had this problem go away if they disable this
> option:
>
> < > generic/default IDE chipset support
Okay I'll try
led low so
> that BUSY appears not set in absence of a drive.
Right. How do I find the value of D7?
> I'm not sure how the list of intefaces is probed on this machine, that's
> probably where the problem is.
Thanks, Richard Hughes
-
To unsubscribe from this list: send the lin
>
> I found additional lines in the log just before the line above:
Same here on 2.6.11-rc2-bk3 using a *Toshiba* Satellite Pro A10.
messages can be found here:
http://hughsie.no-ip.com/write/kernel/messages
please ask if you need any more info.
Richard Hughes
-
To unsubscribe from
On Sat, 29 Jan 2005 12:49:16 +, Richard Hughes wrote:
> Note, that strace glxgears gives exactly the same output, going from 0 to
> 14 and then seg-faulting, so it's *not just a oo problem*.
I know it's bad to answer your own post, but here goes.
I changed my /etc/udev/
d argument)
munmap(0x9d55248, 3219928560) = -1 EINVAL (Invalid argument)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
from 0 to 14 until it found a card that it could use. The root cause
has to be that it can't use dri/card* because of access permissi
/dri/card* everything is okay until I reboot,
and it defaults back to crw-rw
What is at fault? Certainly oo shouldn't just seg-fault, but should the
permissions on /dev/dri/card* be crw-rw or crw-rw-rw-?
Richard Hughes
--
http://www.hughsie.com/PUBLIC-KEY
-
To unsubscribe from t
47 matches
Mail list logo
