On 2018.03.10 01:00 Rafael J. Wysocki wrote:
> On Saturday, March 10, 2018 8:41:39 AM CET Doug Smythies wrote:
>>
>> With apologies to those that do not like the term "PowerNightmares",
>
> OK, and what exactly do you count as "PowerNightmares"?
I'll snip some below and then explain:
On 2018.03.10 01:00 Rafael J. Wysocki wrote:
> On Saturday, March 10, 2018 8:41:39 AM CET Doug Smythies wrote:
>>
>> With apologies to those that do not like the term "PowerNightmares",
>
> OK, and what exactly do you count as "PowerNightmares"?
I'll snip some below and then explain:
On Fri, Mar 09, 2018 at 05:48:55PM +0800, Lai Jiangshan wrote:
> On Tue, Mar 6, 2018 at 12:14 AM, Paul E. McKenney
> wrote:
> > On Mon, Mar 05, 2018 at 08:33:20AM -0600, Eric W. Biederman wrote:
> >>
> >> Moving this discussion to a public list as discussing how to
On Fri, Mar 09, 2018 at 05:48:55PM +0800, Lai Jiangshan wrote:
> On Tue, Mar 6, 2018 at 12:14 AM, Paul E. McKenney
> wrote:
> > On Mon, Mar 05, 2018 at 08:33:20AM -0600, Eric W. Biederman wrote:
> >>
> >> Moving this discussion to a public list as discussing how to reduce the
> >> number of rcu
On Fri, Mar 9, 2018 at 11:03 PM, Miguel Ojeda
wrote:
>
> Just compiled 4.9.0 and it seems to work -- so that would be the
> minimum required.
>
> Sigh...
>
> Some enterprise distros are either already shipping gcc >= 5 or will
> probably be shipping it soon (e.g.
On Fri, Mar 9, 2018 at 11:03 PM, Miguel Ojeda
wrote:
>
> Just compiled 4.9.0 and it seems to work -- so that would be the
> minimum required.
>
> Sigh...
>
> Some enterprise distros are either already shipping gcc >= 5 or will
> probably be shipping it soon (e.g. RHEL 8), so how much does it hurt
On Tue, 2018-03-06 at 11:34 +0200, Tomas Winkler wrote:
> use __le64 annotated variable for response buffer address as this is
> read in little endian format form the register.
>
> This suppresses sparse warning
> drivers/char/tpm/tpm_crb.c:558:18: warning: cast to restricted __le64
>
>
On Tue, 2018-03-06 at 11:34 +0200, Tomas Winkler wrote:
> use __le64 annotated variable for response buffer address as this is
> read in little endian format form the register.
>
> This suppresses sparse warning
> drivers/char/tpm/tpm_crb.c:558:18: warning: cast to restricted __le64
>
>
On Sat, 10 Mar 2018 15:50:23 +0530
Shreeya Patel wrote:
> Move the adis16209 driver out of staging directory and merge to the
> mainline IIO subsystem.
>
> Signed-off-by: Shreeya Patel
As this has a clear dependency on the previous
On Sat, 10 Mar 2018 15:50:23 +0530
Shreeya Patel wrote:
> Move the adis16209 driver out of staging directory and merge to the
> mainline IIO subsystem.
>
> Signed-off-by: Shreeya Patel
As this has a clear dependency on the previous patch, please put them
in the same series for the next
Hello, Ingo!
This pull request contains the following changes:
1. Miscellaneous fixes, perhaps most notably removing obsolete
code whose only purpose in life was to gather information for
the now-removed RCU debugfs facility. Other notable changes
include removing
Hello, Ingo!
This pull request contains the following changes:
1. Miscellaneous fixes, perhaps most notably removing obsolete
code whose only purpose in life was to gather information for
the now-removed RCU debugfs facility. Other notable changes
include removing
Currently, the unmet dependency warnings end up with endlessly long
expressions, most of which are false positives.
Here is test code to demonstrate how it currently works.
[Test Case]
config DEP1
def_bool y
config DEP2
bool "DEP2"
config A
bool "A"
Currently, the unmet dependency warnings end up with endlessly long
expressions, most of which are false positives.
Here is test code to demonstrate how it currently works.
[Test Case]
config DEP1
def_bool y
config DEP2
bool "DEP2"
config A
bool "A"
On 03/09/2018 04:19 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.15.9 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 03/09/2018 04:19 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.15.9 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 03/09/2018 04:18 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.87 release.
There are 65 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 03/09/2018 04:18 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.87 release.
There are 65 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
Petr, Eugeniu,
2018-03-10 9:07 GMT+09:00 Eugeniu Rosca :
>
> It looks like expr_get_leftmost_symbol() has no more callers left and
> could be removed with this patch?
Thanks, I will send v3
with fixes pointed out.
--
Best Regards
Masahiro Yamada
Petr, Eugeniu,
2018-03-10 9:07 GMT+09:00 Eugeniu Rosca :
>
> It looks like expr_get_leftmost_symbol() has no more callers left and
> could be removed with this patch?
Thanks, I will send v3
with fixes pointed out.
--
Best Regards
Masahiro Yamada
On 03/09/2018 04:19 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.26 release.
There are 9 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 03/09/2018 04:19 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.26 release.
There are 9 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Fri, Mar 09, 2018 at 02:49:00PM -0800, Saravana Kannan wrote:
> > > > Looking at the code, I didn't see any specific handling of cluster
> > > > power collapse. AFAIK, the HW counters do not retain config (what event
> > > > they are counting) or value (the current count) across power collapse.
On 03/09/2018 04:18 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.99 release.
There are 21 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 03/09/2018 04:18 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.99 release.
There are 21 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Fri, Mar 09, 2018 at 02:49:00PM -0800, Saravana Kannan wrote:
> > > > Looking at the code, I didn't see any specific handling of cluster
> > > > power collapse. AFAIK, the HW counters do not retain config (what event
> > > > they are counting) or value (the current count) across power collapse.
On Sat, 10 Mar 2018 15:40:14 +0530
Shreeya Patel wrote:
> Make some of the macro names according to the names
> given in the datasheet of the adis16209 driver and
> have slight indentation in field definitions to make
> them clearly different from the register
On Sat, 10 Mar 2018 15:40:14 +0530
Shreeya Patel wrote:
> Make some of the macro names according to the names
> given in the datasheet of the adis16209 driver and
> have slight indentation in field definitions to make
> them clearly different from the register addresses.
>
> Signed-off-by:
On 03/09/2018 04:18 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.121 release.
There are 36 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 03/09/2018 04:18 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.121 release.
There are 36 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On Fri, Mar 9, 2018 at 10:10 PM, Miguel Ojeda
wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>>
On Fri, Mar 9, 2018 at 10:10 PM, Miguel Ojeda
wrote:
> On Sat, Mar 10, 2018 at 4:11 AM, Randy Dunlap wrote:
>> On 03/09/2018 04:07 PM, Andrew Morton wrote:
>>> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook wrote:
>>>
When max() is used in stack array size calculations from literal values
On Fri, Mar 9, 2018 at 10:40 PM, Joao Moreira wrote:
> It is possible to indirectly invoke functions with prototypes that do not
> match those of the respectively used function pointers by using void types.
> Despite widely used as a feature for relaxing function invocation,
On Fri, Mar 9, 2018 at 10:40 PM, Joao Moreira wrote:
> It is possible to indirectly invoke functions with prototypes that do not
> match those of the respectively used function pointers by using void types.
> Despite widely used as a feature for relaxing function invocation, this
> should be
On Fri, Mar 9, 2018 at 9:14 PM, Kyle Spiers wrote:
> From 4198ebe2e8058ff676d8e2f993d8806d6ca29c11 Mon Sep 17 00:00:00 2001
> From: Kyle Spiers
> Date: Fri, 9 Mar 2018 12:34:15 -0800
> Subject: [PATCH] rbd: Remove VLA usage
>
> As part of the effort to remove VLAs
On Fri, Mar 9, 2018 at 9:14 PM, Kyle Spiers wrote:
> From 4198ebe2e8058ff676d8e2f993d8806d6ca29c11 Mon Sep 17 00:00:00 2001
> From: Kyle Spiers
> Date: Fri, 9 Mar 2018 12:34:15 -0800
> Subject: [PATCH] rbd: Remove VLA usage
>
> As part of the effort to remove VLAs from the kernel[1], this moves
TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve generation
of crypto keys which can be a computationally intensive task.
The timeout is set to 3min.
Rather than increasing default timeout a new constant is
added, to not stall for too long on regular commands failures.
TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve generation
of crypto keys which can be a computationally intensive task.
The timeout is set to 3min.
Rather than increasing default timeout a new constant is
added, to not stall for too long on regular commands failures.
On Thu, 8 Mar 2018 21:37:33 -0300
Rodrigo Siqueira wrote:
> On 03/07, Jonathan Cameron wrote:
> > On Tue, 6 Mar 2018 21:43:47 -0300
> > Rodrigo Siqueira wrote:
> >
> > > The macro IIO_DEV_ATTR_CH_OFF is a wrapper for
On Thu, 8 Mar 2018 21:37:33 -0300
Rodrigo Siqueira wrote:
> On 03/07, Jonathan Cameron wrote:
> > On Tue, 6 Mar 2018 21:43:47 -0300
> > Rodrigo Siqueira wrote:
> >
> > > The macro IIO_DEV_ATTR_CH_OFF is a wrapper for IIO_DEVICE_ATTR, with a
> > > tiny change in the name definition. This
On Thu, 8 Mar 2018 12:58:19 +0530
Himanshu Jha wrote:
> On Wed, Mar 07, 2018 at 08:50:30PM +, Jonathan Cameron wrote:
> > On Mon, 5 Mar 2018 13:19:29 +0530
> > Himanshu Jha wrote:
> >
> > > Clarify the conversion and formation of
On Thu, 8 Mar 2018 12:58:19 +0530
Himanshu Jha wrote:
> On Wed, Mar 07, 2018 at 08:50:30PM +, Jonathan Cameron wrote:
> > On Mon, 5 Mar 2018 13:19:29 +0530
> > Himanshu Jha wrote:
> >
> > > Clarify the conversion and formation of resultant data in the
> > > adis16201_read_raw() with
On Fri, 9 Mar 2018 16:35:10 +0530
Himanshu Jha wrote:
> On Thu, Mar 08, 2018 at 11:39:15AM -0800, Kees Cook wrote:
> > On Thu, Mar 8, 2018 at 10:45 AM, Himanshu Jha
> > wrote:
> > > In preparation to enabling -Wvla, remove VLA usage
On Fri, 9 Mar 2018 16:35:10 +0530
Himanshu Jha wrote:
> On Thu, Mar 08, 2018 at 11:39:15AM -0800, Kees Cook wrote:
> > On Thu, Mar 8, 2018 at 10:45 AM, Himanshu Jha
> > wrote:
> > > In preparation to enabling -Wvla, remove VLA usage and replace it
> > > with fixed a fixed length array and
On 2 March 2018 at 08:31, Ard Biesheuvel wrote:
> Add a binding and a driver for the I2C IP found in the Socionext SynQuacer
> SoC, which is essentially a rebranded version of the Fujitsu F_I2C controller.
>
> I think this is good to go now. Wolfram?
>
Ping?
> v5:
> -
On 2 March 2018 at 08:31, Ard Biesheuvel wrote:
> Add a binding and a driver for the I2C IP found in the Socionext SynQuacer
> SoC, which is essentially a rebranded version of the Fujitsu F_I2C controller.
>
> I think this is good to go now. Wolfram?
>
Ping?
> v5:
> - add Rob's ack to #1
> -
On Sat, 3 Mar 2018 20:49:42 -0500
Brian Masney wrote:
> The bits for setting up the proximity diode were not setup correctly and
> this was causing the proximity sensor to not function correctly. This
> patch sets up the correct bit mask in tsl2x7x_chip_on() based on what
On Sat, 3 Mar 2018 20:49:42 -0500
Brian Masney wrote:
> The bits for setting up the proximity diode were not setup correctly and
> this was causing the proximity sensor to not function correctly. This
> patch sets up the correct bit mask in tsl2x7x_chip_on() based on what
> the data sheet
On Fri, Mar 09, 2018 at 10:10:02PM -0700, Shuah Khan wrote:
> On 03/09/2018 05:19 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.15.9 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Fri, Mar 09, 2018 at 10:10:02PM -0700, Shuah Khan wrote:
> On 03/09/2018 05:19 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.15.9 release.
> > There are 11 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Sat, 3 Mar 2018 20:49:41 -0500
Brian Masney wrote:
> The tsl2771 and tmd2771 devices create the
> in_proximity0_calibscale_available sysfs attribute. These two particular
> devices do not support changing the proximity gain value on the
> chip so this patch removes
On Sat, 3 Mar 2018 20:49:41 -0500
Brian Masney wrote:
> The tsl2771 and tmd2771 devices create the
> in_proximity0_calibscale_available sysfs attribute. These two particular
> devices do not support changing the proximity gain value on the
> chip so this patch removes that sysfs attribute. As
On Sat, Mar 10, 2018 at 08:27:54AM +0100, christophe leroy wrote:
>
>
> Le 10/03/2018 à 01:10, Greg Kroah-Hartman a écrit :
> > On Fri, Mar 09, 2018 at 04:48:59PM +0100, Christophe Leroy wrote:
> > > Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d
> >
> > There is no such git commit id in
On Sat, 3 Mar 2018 20:49:40 -0500
Brian Masney wrote:
> This patch updates all of the logging commands so that they are
> consistent with the other messages, includes __func__ in the message,
> and all of the messages include newlines.
>
> This patch also removes some
On Sat, Mar 10, 2018 at 08:27:54AM +0100, christophe leroy wrote:
>
>
> Le 10/03/2018 à 01:10, Greg Kroah-Hartman a écrit :
> > On Fri, Mar 09, 2018 at 04:48:59PM +0100, Christophe Leroy wrote:
> > > Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d
> >
> > There is no such git commit id in
On Sat, 3 Mar 2018 20:49:40 -0500
Brian Masney wrote:
> This patch updates all of the logging commands so that they are
> consistent with the other messages, includes __func__ in the message,
> and all of the messages include newlines.
>
> This patch also removes some debug log messages from
On Fri, Mar 09, 2018 at 01:58:32PM -0800, Andrew Morton wrote:
> >
> > When a page is freed back to the global pool, its buddy will be checked
> > to see if it's possible to do a merge. This requires accessing buddy's
> > page structure and that access could take a long time if it's cache cold.
>
On Fri, Mar 09, 2018 at 01:58:32PM -0800, Andrew Morton wrote:
> >
> > When a page is freed back to the global pool, its buddy will be checked
> > to see if it's possible to do a merge. This requires accessing buddy's
> > page structure and that access could take a long time if it's cache cold.
>
On Sat, 3 Mar 2018 20:49:39 -0500
Brian Masney wrote:
> The functions in_illuminance0_calibrate_store() and
> in_illuminance0_lux_table_store() did not have complete error handling
> in place. This patch adds the missing error handling.
>
> Signed-off-by: Brian Masney
On Sat, 3 Mar 2018 20:49:39 -0500
Brian Masney wrote:
> The functions in_illuminance0_calibrate_store() and
> in_illuminance0_lux_table_store() did not have complete error handling
> in place. This patch adds the missing error handling.
>
> Signed-off-by: Brian Masney
Applied.
Thanks,
> ---
On Sat, 3 Mar 2018 20:49:38 -0500
Brian Masney wrote:
> tsl2x7x_prox_cal() did not have any error checks. This patch adds
> the missing error handling and ensures that any errors are reported to
> user space via in_proximity0_calibrate_store().
>
> Signed-off-by: Brian
On Sat, 3 Mar 2018 20:49:38 -0500
Brian Masney wrote:
> tsl2x7x_prox_cal() did not have any error checks. This patch adds
> the missing error handling and ensures that any errors are reported to
> user space via in_proximity0_calibrate_store().
>
> Signed-off-by: Brian Masney
applied.
On Sat, 3 Mar 2018 20:49:36 -0500
Brian Masney wrote:
> Not all errors that occurred in tsl2x7x_get_prox() were correctly
> reported in the return value. This patch changes the error handling
> so that errors are now returned properly.
>
> Note that the ret variable is
On Sat, 3 Mar 2018 20:49:37 -0500
Brian Masney wrote:
> The statP and calP variables triggered an 'Avoid CamelCase' warning
> from checkpatch.pl. This patch renames these variables to stat and cal
> to fix this warning.
>
> Signed-off-by: Brian Masney
On Sat, 3 Mar 2018 20:49:36 -0500
Brian Masney wrote:
> Not all errors that occurred in tsl2x7x_get_prox() were correctly
> reported in the return value. This patch changes the error handling
> so that errors are now returned properly.
>
> Note that the ret variable is from the call to
On Sat, 3 Mar 2018 20:49:37 -0500
Brian Masney wrote:
> The statP and calP variables triggered an 'Avoid CamelCase' warning
> from checkpatch.pl. This patch renames these variables to stat and cal
> to fix this warning.
>
> Signed-off-by: Brian Masney
Applied.
> ---
>
On Sat, Mar 10, 2018 at 6:35 AM, Luis R. Rodriguez wrote:
> You also I take it have users in
> mind? I'd like to see at least one user of the API or this fixing a
> reported issue. Ie, if users have reported this as issues incorrectly,
> referring to those incorrect posts as
On Sat, Mar 10, 2018 at 6:35 AM, Luis R. Rodriguez wrote:
> You also I take it have users in
> mind? I'd like to see at least one user of the API or this fixing a
> reported issue. Ie, if users have reported this as issues incorrectly,
> referring to those incorrect posts as issues and how this
On Sat, 3 Mar 2018 20:49:35 -0500
Brian Masney wrote:
> The driver uses mutex_lock() and mutex_trylock() in several places.
> Convert the mutex_trylock() to mutex_lock() for consistency with other
> IIO light drivers in mainline.
>
> Signed-off-by: Brian Masney
On Sat, 3 Mar 2018 20:49:35 -0500
Brian Masney wrote:
> The driver uses mutex_lock() and mutex_trylock() in several places.
> Convert the mutex_trylock() to mutex_lock() for consistency with other
> IIO light drivers in mainline.
>
> Signed-off-by: Brian Masney
This was a little odd given we
This patch adds the correct platform data information for the Caroline
Chromebook, so that the mouse button does not get stuck in pressed state
after the first click.
The Samus button keymap and platform data definition are the correct
ones for Caroline, so they have been reused here.
This patch adds the correct platform data information for the Caroline
Chromebook, so that the mouse button does not get stuck in pressed state
after the first click.
The Samus button keymap and platform data definition are the correct
ones for Caroline, so they have been reused here.
On Sat, 3 Mar 2018 20:49:34 -0500
Brian Masney wrote:
> There were four places where the same chunk of code was used to write
> to the control register. This patch creates a common function
> tsl2x7x_write_control_reg() to reduce duplicate code.
>
> The function
On Sat, 3 Mar 2018 20:49:34 -0500
Brian Masney wrote:
> There were four places where the same chunk of code was used to write
> to the control register. This patch creates a common function
> tsl2x7x_write_control_reg() to reduce duplicate code.
>
> The function tsl2x7x_chip_off() did not
First, thanks for your patch!
On Fri, Mar 9, 2018 at 3:09 PM, Andres Rodriguez wrote:
> Currently the firmware loader only exposes one silent path for querying
> optional firmware, and that is request_firmware_direct(). This function
> also disables the usermodehelper
First, thanks for your patch!
On Fri, Mar 9, 2018 at 3:09 PM, Andres Rodriguez wrote:
> Currently the firmware loader only exposes one silent path for querying
> optional firmware, and that is request_firmware_direct(). This function
> also disables the usermodehelper fallback which might not
On Sat, 3 Mar 2018 20:49:33 -0500
Brian Masney wrote:
> There were three places where the same chunk of code was used to read
> the chip status. This patch creates a common function
> tsl2x7x_read_status() to reduce duplicate code. This patch also corrects
>
On Sat, 3 Mar 2018 20:49:33 -0500
Brian Masney wrote:
> There were three places where the same chunk of code was used to read
> the chip status. This patch creates a common function
> tsl2x7x_read_status() to reduce duplicate code. This patch also corrects
> tsl2x7x_event_handler() to properly
On Sat, 3 Mar 2018 20:49:32 -0500
Brian Masney wrote:
> There were three places where the same chunk of code was used to clear
> interrupts. This patch creates a common function
> tsl2x7x_clear_interrupts() to reduce duplicate code.
>
> Signed-off-by: Brian Masney
On Sat, 3 Mar 2018 20:49:32 -0500
Brian Masney wrote:
> There were three places where the same chunk of code was used to clear
> interrupts. This patch creates a common function
> tsl2x7x_clear_interrupts() to reduce duplicate code.
>
> Signed-off-by: Brian Masney
Hmm. This one wasn't
Now that we have a kconfig checker just use that instead of relying
on testing a sysfs directory being present, since our requirements
are spelled out.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
Now that we have a kconfig checker just use that instead of relying
on testing a sysfs directory being present, since our requirements
are spelled out.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 5 +
1 file changed, 1
When a kernel is not built with:
CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y
We don't currently enable testing fw_fallback.sh. For kernels that
still enable the fallback mechanism, its possible to use the async
request firmware API call request_firmware_nowait() using the custom
interface to use
When a kernel is not built with:
CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y
We don't currently enable testing fw_fallback.sh. For kernels that
still enable the fallback mechanism, its possible to use the async
request firmware API call request_firmware_nowait() using the custom
interface to use
On Sat, 3 Mar 2018 20:49:31 -0500
Brian Masney wrote:
> The tsl2X7X_platform_data structure contains the platform_power,
> power_on, and power_off function pointers. These power management
> functions should not be in the platform data. These functions were
> likely used
On Sat, 3 Mar 2018 20:49:31 -0500
Brian Masney wrote:
> The tsl2X7X_platform_data structure contains the platform_power,
> power_on, and power_off function pointers. These power management
> functions should not be in the platform data. These functions were
> likely used before the regulator
The firmware loader code has grown quite a bit over the years.
The practice of stuffing everything we need into one file makes
the code hard to follow.
In order to split the firmware loader code into different components
we must pick a module name and a first object target file. We must
keep the
The firmware loader code has grown quite a bit over the years.
The practice of stuffing everything we need into one file makes
the code hard to follow.
In order to split the firmware loader code into different components
we must pick a module name and a first object target file. We must
keep the
The timeout is a fallback construct, so we can just stuff the
timeout configuration under struct firmware_fallback_config.
While at it, add a few helpers which vets the use of getting or
setting the timeout as an int. The main use of the timeout is
to set a timeout for completion, and that is
We'll expland on this later, for now just add basic module checker.
While at it, move this all to use /bin/bash as we'll have much more
flexibility with it.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 7 ++--
The timeout is a fallback construct, so we can just stuff the
timeout configuration under struct firmware_fallback_config.
While at it, add a few helpers which vets the use of getting or
setting the timeout as an int. The main use of the timeout is
to set a timeout for completion, and that is
We'll expland on this later, for now just add basic module checker.
While at it, move this all to use /bin/bash as we'll have much more
flexibility with it.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 7 ++--
We only use the timeout for the firmware fallback mechanism
except for trying to set the timeout during the cache setup
for resume/suspend. For those cases, setting the timeout should
be a no-op, so just reflect this in code by adding helpers for it.
This change introduces no functional changes.
We only use the timeout for the firmware fallback mechanism
except for trying to set the timeout during the cache setup
for resume/suspend. For those cases, setting the timeout should
be a no-op, so just reflect this in code by adding helpers for it.
This change introduces no functional changes.
The firmware fallback code is optional. Split that code out to help
distinguish the fallback functionlity from othere core firmware loader
features. This should make it easier to maintain and review code
changes.
The reason for keeping the configuration onto a table which is built-in
if you
The firmware fallback code is optional. Split that code out to help
distinguish the fallback functionlity from othere core firmware loader
features. This should make it easier to maintain and review code
changes.
The reason for keeping the configuration onto a table which is built-in
if you
All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool,
initailized at build time. Define it as such. This simplifies the
logic even further, removing now all explicit #ifdefs around the code.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
On Fri, Mar 9, 2018 at 2:12 PM, Andres Rodriguez wrote:
> Hi Everyone,
>
> Wanted to inquire your opinions about the following matter.
>
> We are experiencing some end user confusion regarding the following messages
> being printed to dmesg:
>
> [0.571324] amdgpu
On Fri, Mar 9, 2018 at 2:12 PM, Andres Rodriguez wrote:
> Hi Everyone,
>
> Wanted to inquire your opinions about the following matter.
>
> We are experiencing some end user confusion regarding the following messages
> being printed to dmesg:
>
> [0.571324] amdgpu :01:00.0: Direct firmware
All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool,
initailized at build time. Define it as such. This simplifies the
logic even further, removing now all explicit #ifdefs around the code.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c
401 - 500 of 686 matches
Mail list logo