Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote: > From: "Du, Changbin" > > On most platforms, there is only one device controller available. > In this case, we desn't care the UDC's name. So let's ignore the > name by setting 'UDC' to 'any'. And also we can change

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote: > On 13 June 2016 at 17:01, Pavel Machek <pa...@ucw.cz> wrote: > > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote: > >> On 13 June 2016 at 15:00, Pavel Machek <pa...@ucw.cz> wrote: > >> >

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

Hi! > > João, that means you should send a patch to add the ::rfkill suffix. > > > > IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it > reflects the label on the machine's chassis. I'll name it > "asus-wireless::airplane" and send this through platform-drivers-x86, > as this

Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)

On Wed 2016-02-24 12:01:37, Johannes Berg wrote: > On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote: > > > If you want different trigger, implement different trigger. If you > > want to indicate all but wifi, implement all but wifi, and then > > userspace can sele

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode

On Tue 2016-02-23 21:55:14, Johannes Berg wrote: > On Tue, 2016-02-23 at 21:45 +0100, Pavel Machek wrote: > > > So... you add LED trigger to display the state of the airplane > > mode. Ok, why not. > > Yes. However, consider that "the airplane mode" isn't a we

Re: [PATCH] Prefer kASLR over Hibernation

Hi! > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, > one or the other must be chosen at boot-time. Until now, hibernation > was selected when no choice was made on the command line. > > To make the security benefits of kASLR more widely available to end > users (since

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote: > > But... that will mean that my ssh will need to be SGX-aware, and that > > I will not be able to switch to AMD machine in future. ... or to other > > Intel machine for that matter, right? > > I'm not privy to AMD's CPU design plans. > >

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On Wed 2016-04-27 17:41:40, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote: > > Doing it early will break bisect, right? > > How exactly? Please do tell. Hey look, SME slowed down 30% since being initially mer

Re: [PATCH 0/6] Intel Secure Guard Extensions

Hi! > > > Preventing cold boot attacks is really just icing on the cake. The > > > real point of this is to allow you to run an "enclave". An SGX > > > enclave has unencrypted code but gets access to a key that only it can > > > access. It could use that key to unwrap your ssh private key and

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

Hi! > This RFC patch series provides support for AMD's new Secure Memory > Encryption (SME) feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be automatically > decrypted when read from DRAM and

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

On Tue 2016-04-26 17:56:14, Tom Lendacky wrote: > Provide the Kconfig support to build the SME support in the kernel. Probably should go last in the series? > Signed-off-by: Tom Lendacky > --- > arch/x86/Kconfig |9 + > 1 file changed, 9 insertions(+) > >

Re: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

On Tue 2016-04-26 17:56:26, Tom Lendacky wrote: > Provide support for Secure Memory Encryption (SME). This initial support > defines the memory encryption mask as a variable for quick access and an > accessor for retrieving the number of physical addressing bits lost if > SME is enabled. > >

Re: [PATCH 0/6] Intel Secure Guard Extensions

Hi! > Good morning, I hope everyone's day is starting out well. :-). Rainy day here. > > > In the TL;DR department I would highly recommend that anyone > > > interested in all of this read MIT's 170+ page review of the > > > technology before jumping to any conclusions :-) > > > Would you

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote: > On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote: > > On 2016-04-29 16:17, Jarkko Sakkinen wrote: > > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote: > > >>On Mon 2016-04-25 2

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

Hi! > This creates a new LED trigger to be used by platform drivers as a > default trigger for airplane-mode indicator LEDs. > > By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called > for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL > when the changing the

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

Hi! > Since kASLR and Hibernation can not currently coexist at runtime > on x86, the default behavior was to disable kASLR by default when > CONFIG_HIBERNATION was present (to retain original behavior). > > The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by > default when

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

On Thu 2016-04-14 13:14:07, Kees Cook wrote: > On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek <pa...@denx.de> wrote: > > Hi! > > > >> Since kASLR and Hibernation can not currently coexist at runtime > >> on x86, the default behavior was to disable kASLR

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

On Wed 2016-04-27 16:05:20, Borislav Petkov wrote: > On Tue, Mar 22, 2016 at 02:00:58PM +0100, Pavel Machek wrote: > > Why would I want SME on my system? My system seems to work without it. > > Your system doesn't have it and SME is default off. That does not answer the questio

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

On Mon 2016-07-18 08:55:52, Rafał Miłecki wrote: > On 18 July 2016 at 07:53, Peter Chen wrote: > > On Mon, Jul 18, 2016 at 07:57:34AM +0200, Rafał Miłecki wrote: > >> On 18 July 2016 at 07:40, Peter Chen wrote: > >> > On Mon, Jul 18, 2016 at

Re: [PATCH V2] leds: trigger: Introduce an USB port trigger

Hi! > > @@ -0,0 +1,206 @@ > > +/* > > + * USB port LED trigger > > + * > > + * Copyright (C) 2016 Rafał Miłecki > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published

Re: [PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

On Mon 2017-02-06 10:47:45, Laura Abbott wrote: > On 02/03/2017 01:08 PM, Kees Cook wrote: > > On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux > > wrote: > >> On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote: > >>> On Fri, Feb 3, 2017 at 9:52 AM, Laura

Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA

On Wed 2017-01-25 12:21:05, Laura Abbott wrote: > On 01/19/2017 08:53 AM, Pavel Machek wrote: > >On Wed 2017-01-18 17:29:05, Laura Abbott wrote: > >> > >>Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option > >>provides key security features

Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

Hi! > > -config DEBUG_RODATA > +config STRICT_KERNEL_RWX > bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX > depends on ARCH_HAS_STRICT_KERNEL_RWX > default !ARCH_OPTIONAL_KERNEL_RWX || Debug features are expected to have runtime cost, so kconfig help

Re: [PATCH 1/2] security: Change name of CONFIG_DEBUG_RODATA

On Wed 2017-01-18 17:29:05, Laura Abbott wrote: > > Despite the word 'debug' in CONFIG_DEBUG_RODATA, this kernel option > provides key security features that are to be expected on a modern > system. Change the name to CONFIG_HARDENED_PAGE_MAPPINGS which more > accurately describes what this

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On Thu 2016-08-25 11:04:38, Jacek Anaszewski wrote: > On 08/25/2016 10:29 AM, Rafał Miłecki wrote: > >On 25 August 2016 at 10:03, Jacek Anaszewski > >wrote: > >>On 08/24/2016 07:52 PM, Rafał Miłecki wrote: > >>> > >>>From: Rafał Miłecki > >>> >

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On Thu 2016-08-25 20:48:04, Jacek Anaszewski wrote: > On 08/25/2016 04:30 PM, Alan Stern wrote: > >On Thu, 25 Aug 2016, Jacek Anaszewski wrote: > > > >>I'd see it as follows: > >> > >>#cat available_ports > >>#1-1 1-2 2-1 > >> > >>#echo "1-1" > new_port > >> > >>#cat observed_ports > >>#1-1 > >> >

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

Hi! > >2) Having "ports" subdir with RW files, one per each existing physical port > >In this situation we don't need "new_port" or "remove_port". If we > >want port to be observable we just do: > >echo 1 > 1-1 > >Implementing this solution needs reading more details from USB subsystem. > > The

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote: > On 29 August 2016 at 10:05, Pavel Machek <pa...@ucw.cz> wrote: > >> >2) Having "ports" subdir with RW files, one per each existing physical > >> >port > >> >In this situation we don't

[PATCH] regulator/overview.txt: Use ".." for ranges, instead of "->"

Using "->" to indicate range is not too common, switch to ".." Signed-off-by: Pavel Machek <pa...@ucw.cz> --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -90,7 +90,7 @@ Some terms used in this document:-

[PATCH] regulator/overview.txt: Use ".." for ranges, instead of "->"

Using "->" to indicate range is not too common, switch to ".." Signed-off-by: Pavel Machek <pa...@ucw.cz> --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -90,7 +90,7 @@ Some terms used in this document:-

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On Wed 2016-08-31 14:23:13, Alan Stern wrote: > On Tue, 30 Aug 2016, Rafał Miłecki wrote: > > > >> As you quite often need more complex LED management, there are > > >> triggers that were introduced in 2006 by c3bc9956ec52f ("[PATCH] LED: > > >> add LED trigger tupport"). Some triggers are

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

Hi! > This commit adds a new trigger responsible for turning on LED when USB > device gets connected to the specified USB port. This can can useful for > various home routers that have USB port(s) and a proper LED telling user > a device is connected. > > The trigger gets its documentation file

Re: [PATCH] doc: add note on usleep_range range

Hi! > > "to have zero jitter" at least. I believe it is "does not". > > > > I don't see how atomic vs. non-atomic context makes difference. There > > are sources of jitter that affect atomic context... > > The relevance is that while there is jitter in atomic context it can > be quite small

Re: [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

On Tue 2017-03-14 10:05:08, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64-bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction always writes to the GDT

Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer

On Sun 2017-04-30 14:36:58, David Lin wrote: > Hi, > > These patch series add the LED_BRIGHTNESS_FAST flag support for > ledtrig-transient to use hrtimer so that platforms with high-resolution timer > support can have better accuracy in the trigger duration timing. The need for > this support is

[PATCH] Documentation: fix ascii art in networking docs

Fix ascii-art. Signed-off-by: Pavel Machek <pa...@ucw.cz> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt index 5e40e1f..6309e90 100644 --- a/Documentation/networking/switchdev.txt +++ b/Documentation/networking/switchdev.txt @@ -29,7

[PATCH] Documentation: link in networking docs

Fix link in filter.txt. Acked-by: Pavel Machek <pa...@ucw.cz> diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index e5e33ba..789b74d 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -45,7 +45,7 @@ in man

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi! > >> If we want to have discussion "how to make vibrations in input > >> easier to use", well that's fair. But I don't think it is particulary hard. > >> > > > > I would like to know more about why you find the FF interface hard, > > led-transient trigger can be activated using only

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi! > These patch series add the LED_BRIGHTNESS_FAST flag support for > ledtrig-transient to use hrtimer so that platforms with high-resolution > timer > support can have better accuracy in the trigger duration timing. The > need for ... > > If we want to say "lets move

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi! > These patch series add the LED_BRIGHTNESS_FAST flag support for > ledtrig-transient to use hrtimer so that platforms with high-resolution timer > support can have better accuracy in the trigger duration timing. The need for > this support is driven by the fact that Android has removed the

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Wed 2017-09-13 14:20:58, David Lin wrote: > On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pa...@ucw.cz> wrote: > > > > Hi! > > > > > These patch series add the LED_BRIGHTNESS_FAST flag support for > > > ledtrig-transient to use hrtimer so tha

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi! > >> Do you think such an improvement could be harmful in some way, > >> even if it was made optional? > > > > Of course, we can make LED timing accurate down to microseconds. It will > > mean increased overhead -- for "improvement" human can not perceive. > > > > If someone has problems

Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote: > Hi David and Pavel, > > On 09/13/2017 10:20 PM, Pavel Machek wrote: > > Hi! > > > >> These patch series add the LED_BRIGHTNESS_FAST flag support for > >> ledtrig-transient to use hrtimer so that pla

Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi! > > > > NAK. > > > > > > > > LEDs do not need extra overhead, and vibrator control should not go > > > > through LED subsystem. > > > > > > > > Input subsystem includes support for vibrations and force > > > > feedback. Please use that instead. > > > > > > I thought we are already over this

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi! > >> However only if following conditions are met: > >> - force feedback driver supports gpio driven devices > >> - there is sample application in tools/input showing how to > >> setup gpio driven vibrate device with use of ff interface > >> - it will be possible to setup vibrate interval

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Mon 2017-09-18 22:43:40, Jacek Anaszewski wrote: > Hi, > > On 09/17/2017 07:50 PM, Pavel Machek wrote: > > Hi! > > > >>>> Do you think such an improvement could be harmful in some way, > >>>> even if it was made optional? > >

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

> >>> I'd leave the decision to the user. We could add a note to the > >>> Documentation/leds/ledtrig-transient.txt that force feedback interface > >>> should be preferable choice for driving vibrate devices. > >>> However only if following conditions are met: > >> > >> What I meant is that it is

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote: > On 09/20/2017 01:29 PM, Pavel Machek wrote: > >>>>> I'd leave the decision to the user. We could add a note to the > >>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface > >

Re: [PATCH] Documentation: fix little inconsistencies

On Tue 2017-08-29 13:09:45, Jonathan Corbet wrote: > On Tue, 29 Aug 2017 09:50:57 -0700 > "Darrick J. Wong" wrote: > > > > Anything wrong here? It is fixing extra '+' in the ascii art... > > > > There's nothing incorrect here, I merely thought it odd to send a fix > >

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

Hi! > > -As a specific example of this use-case, let's look at vibrate feature on > > -phones. Vibrate function on phones is implemented using PWM pins on SoC or > > -PMIC. There is a need to activate one shot timer to control the vibrate > > -feature, to prevent user space crashes leaving the

Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

On Tue 2017-09-05 14:44:56, David Miller wrote: > From: Pavel Machek <pa...@ucw.cz> > Date: Mon, 4 Sep 2017 18:25:30 +0200 > > > Will gcc be able to compile code that uses these automatically? That > > does not sound easy to me. Can libc automatically use this in malloc

Re: [PATCH 3/3 v12] printk: Add monotonic, boottime, and realtime timestamps

Hi! > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index b19c491cbc4e..e21b0c002d0f 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -8,12 +8,58 @@ config PRINTK_TIME > messages to be added to the output of the syslog() system > call and at the console. >

[PATCH] Documentation: fix little inconsistencies

Fix little inconsistencies in Documentation: make case and spacing match surrounding text, fix ascii-art. Signed-off-by: Pavel Machek <pa...@ucw.cz> diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 5a8f7f4..75236c0 100644 --- a/Documentation/files

[PATCH] Documentation: small fixes for LEDs, hide notes about vibration

Spell "LED" consistently with uppercase. We do not want people to use LED subsystem for vibrations; there's already support for that in input subsystem. Remove notes about vibrations not to confuse people. Signed-off-by: Pavel Machek <pa...@ucw.cz> diff --git a/Documentat

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

Hi! > >> > -As a specific example of this use-case, let's look at vibrate feature on > >> > -phones. Vibrate function on phones is implemented using PWM pins on SoC > >> > or > >> > -PMIC. There is a need to activate one shot timer to control the vibrate > >> > -feature, to prevent user space

Re: [PATCH 04/24] media: v4l2-mediabus: convert flags to enums and document them

On Mon 2017-10-09 07:19:10, Mauro Carvalho Chehab wrote: > There is a mess with media bus flags: there are two sets of > flags, one used by parallel and ITU-R BT.656 outputs, > and another one for CSI2. > > Depending on the type, the same bit has different meanings. > > @@ -86,11 +125,22 @@

Re: [PATCH v2] thinkpad_acpi: Support the battery wear control

On Sat 2017-12-09 11:29:51, Ognjen Galić wrote: > On 09/12/2017, Pavel Machek <pa...@ucw.cz> wrote: > > In newer series (I can't find it at the moment, sorry) > > The new series is a 3-patch patchset that obsoletes this > patch. It is in the testing stage and will be pushe

Re: [PATCH v6 00/11] Intel SGX Driver

On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote: > Intel(R) SGX is a set of CPU instructions that can be used by applications to > set aside private regions of code and data. The code outside the enclave is > disallowed to access the memory inside the enclave by the CPU access control. > In a

Re: [PATCH v2] thinkpad_acpi: Support the battery wear control

Hi! In newer series (I can't find it at the moment, sorry) you return "NOT_CHARGING" status when not charging because of wear control. Maybe we should have separate status "not charging due to wear control"? Thanks, Pavel

Re: [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

On Wed 2018-05-16 11:18:52, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov So Andrew's signoff should be here? > --- > Documentation/arm64/ilp32.txt | 45 +++ > 1 file changed, 45

Re: [PATCH v6 00/11] Intel SGX Driver

On Tue 2018-01-09 16:27:30, Jarkko Sakkinen wrote: > On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote: > > So how does this protect against the MELTDOWN attack (CVE-2017-5754) > > and the MELTATOMBOMBA4 worm which uses this exploit? > > > > Ced > > Everything going out of L1 gets

Re: [PATCH v6 00/11] Intel SGX Driver

Hi! > Good evening Pavel et.al., I hope the New Year has started well for > everyone. :-). Stuff proceeds as usual. Too bad it is raining outside, instead of snowing. > > > > Would you list guarantees provided by SGX? > > > > > > Obviously, confidentiality and integrity. SGX was designed to

Re: [PATCH v6 00/11] Intel SGX Driver

Hi! > > Would you list guarantees provided by SGX? > > Obviously, confidentiality and integrity. SGX was designed to address > an Iago threat model, a very difficult challenge to address in > reality. Do you have link on "Iago threat model"? > I don't have the citation immediately available,

Re: [PATCH V2 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation

Hi! > --- /dev/null > +++ b/Documentation/thermal/cpu-idle-cooling.txt > @@ -0,0 +1,165 @@ > + > +Situation: > +-- > + Can we have some real header here? Also if this is .rst, maybe it should be marked so? > +Under certain circumstances, the SoC reaches a temperature exceeding > +the

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

Hi! > >Are these SoCs x86-based? > > Yes, these are ARM SoCs. Please see Andrew's answer as well. Understood, thanks. > >>+ Read sampling point selection. The whole period of a bit time will be > >>+ divided into 16 time frames. This value will determine which time frame > >>+ this

Re: [PATCH V2 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation

Hi! > >> +Under certain circumstances, the SoC reaches a temperature exceeding > >> +the allocated power budget or the maximum temperature limit. The > > > > I don't understand. Power budget is in W, temperature is in > > kelvin. Temperature can't exceed power budget AFAICT. > > Yes, it is

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

Hi! On Fri 2018-03-09 13:15:31, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox wrote: > > > > If you want to be taken seriously then I think minimum you also need to > > - Give a GPG key for messages to the list > > Oh, I don't want to be taken

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

Hi! > Signed-off-by: Jae Hyun Yoo > --- > .../devicetree/bindings/peci/peci-aspeed.txt | 73 > ++ > 1 file changed, 73 insertions(+) > create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt > > diff --git

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

On Tue 2018-03-06 13:54:16, Andrew Lunn wrote: > On Tue, Mar 06, 2018 at 01:40:02PM +0100, Pavel Machek wrote: > > Hi! > > > > > Signed-off-by: Jae Hyun Yoo <jae.hyun@linux.intel.com> > > > --- > > > .../dev