From: David Howells
If the kernel is locked down, require that all modules have valid
signatures that we can verify.
I have adjusted the errors generated:
(1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
ENOKEY), then:
(a) If signatures are enforced then EKEYREJEC
From: Matthew Garrett
Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked
The Wilco Embedded Controller can create custom events that
are not handled as standard ACPI objects. These events can
contain information about changes in EC controlled features,
such as errors and events in the dock or display. For example,
an event is triggered if the dock is plugged into a disp
On Wed, Apr 03, 2019 at 04:12:12PM -0500, Corey Minyard wrote:
> On Wed, Apr 03, 2019 at 03:27:29PM -0500, Corey Minyard wrote:
> > On Wed, Apr 03, 2019 at 02:33:23PM +1100, Stephen Rothwell wrote:
> > > Hi Corey,
> > >
> > > After merging the ipmi tree, today's linux-next build (x86_64
> > > allm
On Wed, Apr 3, 2019 at 7:41 PM Kees Cook wrote:
>
> On Thu, Mar 28, 2019 at 6:03 AM Matteo Croce wrote:
> >
> > fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> > accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> > ("sysctl: handle overflow for file
* Dan Murphy [190321 14:29]:
> Introduce the Texas Instruments LM3532 White LED driver.
> The driver supports ALS configurability or manual brightness
> control.
>
> The driver also supports associating LED strings with specific
> control banks in a group or as individually controlled strings.
I
* Dan Murphy [190321 14:29]:
> Remove the LM3532 backlight driver references from the ti-lmu
> code as dedicated driver support is available.
Acked-by: Tony Lindgren
* Dan Murphy [190321 14:29]:
> Add the lm3532 device tree documentation.
> Remove lm3532 device tree reference from the ti_lmu devicetree
> documentation.
>
> With the addition of the dedicated lm3532 documentation the device
> can be removed from the ti_lmu.txt.
>
> The reason for this is that
On Wed, Apr 3, 2019 at 12:42 PM Thomas Gleixner wrote:
>
> On Wed, 3 Apr 2019, Thomas Gleixner wrote:
> > On Tue, 2 Apr 2019, Andy Lutomirski wrote:
> > > > On Apr 2, 2019, at 1:29 PM, Thomas Gleixner wrote:
> > > >>> How about a much better fix: make the DB stack be the same size as all
> > > >>
Hi,
* Dan Murphy [190321 14:29]:
> Update the properties for the lm3532 device node for droid4.
> With this change the backlight LED string and the keypad
> LED strings will be controlled separately.
We also need the following incremental change to prevent
panel-dsi-cm trying to use of_find_back
> -Original Message-
> From: Alex Williamson
> Sent: Wednesday, April 3, 2019 4:27 PM
> To: Parav Pandit
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
> kwankh...@nvidia.com; c...@nvidia.com
> Subject: Re: [PATCHv1 7/7] vfio/mdev: Fix race conditions with mdev device
> life
> On Apr 2, 2019, at 2:03 PM, Daniel Bristot de Oliveira
> wrote:
>
> Note: do not take it too seriously, it is just a proof of concept.
>
> Some time ago, while using perf to check the automaton model, I noticed
> that perf was losing events. The same was reproducible with ftrace.
>
> See: https
On Wed, Apr 03, 2019 at 11:09:09AM -0700, Moritz Fischer wrote:
> Hi Hao,
>
> On Thu, Apr 04, 2019 at 12:31:47AM +0800, Wu Hao wrote:
> > On Tue, Apr 02, 2019 at 07:59:25AM -0700, Moritz Fischer wrote:
> > > Hi Wu,
> > >
> > > On Mon, Mar 25, 2019 at 11:07:41AM +0800, Wu Hao wrote:
> > > > This p
* Tony Lindgren [190403 13:06]:
> * Sebastian Reichel [190329 05:36]:
> > Hi,
> >
> > On Mon, Mar 25, 2019 at 11:01:18AM -0500, Dan Murphy wrote:
> > > On 3/25/19 9:54 AM, Tony Lindgren wrote:
> > > > * Dan Murphy [190325 12:36]:
> > > >> On 3/22/19 5:16 PM, Tony Lindgren wrote:
> > > >>> I can
Commit a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer
in use") changed the behavior of lockdep_free_key_range() from
unconditionally zapping lock classes into only zapping lock classes if
debug_lock == true. Not zapping lock classes if debug_lock == false leaves
dangling point
Hi Horatiu,
On Wed, Apr 03, 2019 at 05:27:36PM +0200, Horatiu Vultur wrote:
> diff --git a/arch/mips/configs/generic/board-ocelot.config
> b/arch/mips/configs/generic/board-ocelot.config
> index f607888..3215741 100644
> --- a/arch/mips/configs/generic/board-ocelot.config
> +++ b/arch/mips/config
Hi Jagan,
On Thu, Mar 21, 2019 at 01:51:02PM +0530, Jagan Teki wrote:
> Goodix CTP controllers require AVDD28, VDDIO regulators for power-on
> sequence.
>
> The delay between these regualtor operations as per Power-on Timing
> from datasheet[1] is 0 (T1 >= 0 usec).
>
> So, enable and disable the
On Thu, Mar 21, 2019 at 01:51:04PM +0530, Jagan Teki wrote:
> GT5663 is capacitive touch controller with customized smart
> wakeup gestures.
>
> Add support for it by adding compatible and supported chip data.
>
> The chip data on GT5663 is similar to GT1151, like
> - config data register has 0x8
The callers of cgroup_migrate_prepare_dst() correctly call
cgroup_migrate_finish() for success and failure cases both. No need to
call it in cgroup_migrate_prepare_dst() in failure case.
Signed-off-by: Shakeel Butt
---
kernel/cgroup/cgroup.c | 5 +
1 file changed, 1 insertion(+), 4 deletions
On Thu, Mar 28, 2019 at 12:18:40PM -0700, Andy Lutomirski wrote:
> Finally, why does the vDSO code bother checking whether the leaf is valid?
To sanity check the input to ensure the caller is attempting to enter an
enclave, i.e. the function is named __vdso_sgx_enter_enclave(), not
__vsgx_enclu().
Hi Andrey,
This looks good. Only some minor comments:
On Wed, Mar 27, 2019 at 3:41 AM Andrey Smirnov wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx7d-zii-rpu2.dts
> @@ -0,0 +1,936 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +
Shawn mentioned on a prior submission of mine that thi
Hi Daniel,
On Tue, Apr 02, 2019 at 06:12:44PM +0200, Daniel Lezcano wrote:
> The module support for the thermal subsystem makes little sense:
> - some subsystems relying on it are not modules, thus forcing the
>framework to be compiled in
> - it is compiled in for almost every configs, the r
On Wed, Apr 03, 2019 at 07:21:45PM +0300, Dan Carpenter wrote:
> On Wed, Apr 03, 2019 at 07:18:03PM +0300, Dan Carpenter wrote:
> > data_bit = (data & BIT(i)) ? 1 : 0;
>
> I quite like the !! idiom also...
>
> data_bit = !!(data & BIT(i));
Thanks for reviewing it.
>
From: Enrico Granata
As new transfer mechanisms are added to the EC codebase, they may
not support v2 of the EC protocol.
If the v3 initial handshake transfer fails, the kernel will try
and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
will be NULL, and the code will end up causi
Remove unwanted parentheses and use !! idiom in place of ternary
operator to make code simple and more understandable.
Signed-off-by: Madhumitha Prabakaran
---
Changes in v2:
- Changed commit log
- Replaced ternary operator with !! idiom
- Modified a BIT operator
---
drivers/staging/rtlwifi/cor
On 03/04/2019 23:26, Darren Hart wrote:
> On Wed, Apr 03, 2019 at 11:05:12PM +0100, Colin Ian King wrote:
>> On 03/04/2019 23:02, Darren Hart wrote:
>>> On Sat, Mar 30, 2019 at 12:17:12AM +, Colin King wrote:
From: Colin Ian King
Currently the kfree of output.pointer can be pote
On Wed, Apr 3, 2019 at 3:57 PM Wolfram Sang wrote:
>
> On Mon, Apr 01, 2019 at 02:37:19PM -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 1, 2019 at 9:08 AM Wolfram Sang wrote:
> > >
> > >
> > > > > From: Bjorn Helgaas
> > > > >
> > > > > 54fb4a05af0a ("i2c: Check for ACPI resource conflicts") inclu
On Wed, Apr 03, 2019 at 11:05:12PM +0100, Colin Ian King wrote:
> On 03/04/2019 23:02, Darren Hart wrote:
> > On Sat, Mar 30, 2019 at 12:17:12AM +, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> Currently the kfree of output.pointer can be potentially freeing
> >> an uninitalized pointe
On 4/3/19 1:44 PM, Wolfram Sang wrote:
> On Tue, Apr 02, 2019 at 06:18:21PM -0700, Ray Jui wrote:
>> This patch series adds the following support to the iProc I2C driver:
>> - Increase maximum read transfer size to 255 bytes
>> - I2C slave mode
>> - Polling mode
>> - NIC I2C mode
>>
>> This patch s
On Wed, Mar 27, 2019 at 06:08:05AM +, Anson Huang wrote:
> With calling dev_pm_set_wake_irq() to set SNVS ON/OFF button
> as wakeup source for suspend, generic wake irq mechanism
> will automatically enable it as wakeup source when suspend,
> then the enable_irq_wake()/disable_irq_wake() can be
On Wed, Mar 27, 2019 at 06:07:06AM +, Anson Huang wrote:
> SNVS IRQ is requested before necessary driver data initialized,
> if there is a pending IRQ during driver probe phase, kernel
> NULL pointer panic will occur in IRQ handler. To avoid such
> scenario, just initialize necessary driver dat
On Wed, Apr 03, 2019 at 09:23:28PM +, Roman Gushchin wrote:
> On Thu, Apr 04, 2019 at 08:03:27AM +1100, Tobin C. Harding wrote:
> > On Wed, Apr 03, 2019 at 06:00:30PM +, Roman Gushchin wrote:
> > > On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> > > > Currently we reach
On 03/04/2019 23:02, Darren Hart wrote:
> On Sat, Mar 30, 2019 at 12:17:12AM +, Colin King wrote:
>> From: Colin Ian King
>>
>> Currently the kfree of output.pointer can be potentially freeing
>> an uninitalized pointer in the case where out_data is NULL. Fix this
>> by reworking the case wher
On Wed, Apr 03, 2019 at 09:54:27PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart
> > Sent: Wednesday, April 3, 2019 3:24 PM
> > To: Limonciello, Mario
> > Cc: Andy Shevchenko; LKML; platform-driver-...@vger.kernel.org
> > Subject: Re: [PATCH] platfor
On Wed, Apr 03, 2019 at 10:54:02PM +0200, Wolfram Sang wrote:
>Hi,
>
>On Thu, Mar 28, 2019 at 11:19:45AM +, Adamski, Krzysztof (Nokia -
>PL/Wroclaw) wrote:
>> Some recent commits to this driver were trying to make sure the TSS
>> interrupt is not generated on busy system due to 25ms timer expi
> -Original Message-
> From: Vabhav Sharma
> Sent: Wednesday, April 3, 2019 3:28 AM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: Leo Li ; Meenakshi Aggarwal
> ; Andy Tang ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH v1 1/4] dt-bindings: arm64
On Sat, Mar 30, 2019 at 12:17:12AM +, Colin King wrote:
> From: Colin Ian King
>
> Currently the kfree of output.pointer can be potentially freeing
> an uninitalized pointer in the case where out_data is NULL. Fix this
> by reworking the case where out_data is not-null to perform the
> ACPI s
From: Rafael J. Wysocki
In sufficiently complicated GPE configurations it is hard to
determine which GPE could be the source of system wakeup from a sleep
state, so make __acpi_device_wakeup_enable() print that information
to the kernel log if debugging is enabled.
Signed-off-by: Rafael J. Wysoc
On Wed, Apr 3, 2019 at 3:08 PM Moritz Fischer wrote:
>
> On Wed, Apr 03, 2019 at 01:37:51PM -0500, Alan Tull wrote:
> > >
> > > it's state, not status for most fpga manager drivers. It should
> > > return 'operating' if everything went well.
>
> Yeah, sorry :)
>
> > > It seems like there's a poss
> -Original Message-
> From: Darren Hart
> Sent: Wednesday, April 3, 2019 3:24 PM
> To: Limonciello, Mario
> Cc: Andy Shevchenko; LKML; platform-driver-...@vger.kernel.org
> Subject: Re: [PATCH] platform/x86: dell-laptop: fix rfkill functionality
>
>
> [EXTERNAL EMAIL]
>
> On Wed, Mar 2
On Thu, Apr 04, 2019 at 08:03:27AM +1100, Tobin C. Harding wrote:
> On Wed, Apr 03, 2019 at 06:00:30PM +, Roman Gushchin wrote:
> > On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> > > Currently we reach inside the list_head. This is a violation of the
> > > layer of abstrac
> On Apr 3, 2019, at 11:59 AM, Song Liu wrote:
>
>
>
>> On Apr 3, 2019, at 11:55 AM, Song Liu wrote:
>>
>>
>>
>>> On Apr 3, 2019, at 11:50 AM, Arnaldo Carvalho de Melo
>>> wrote:
>>>
>>> Em Wed, Apr 03, 2019 at 04:27:56PM +, Song Liu escreveu:
> On Apr 3, 2019, at
Hi Anson,
On Fri, Mar 29, 2019 at 07:00:43AM +, Anson Huang wrote:
> There is no need to enable release interrupt and disable depress
> interrupt in event check, as a timer is setup for checking these
> events rather than interrupts.
But won't using release interrupt allow signalling key rele
Introduce the command and response structures for the second revision
of the host sleep event. These structures are part of a new EC change
that enables detection of failure to enter S0ix. The EC waits a
kernel-specified timeout (or a default amount of time) for the S0_SLP
pin to change, and wakes
Add support in code for the new forms of the host sleep event.
Detects the presence of this version of the command at runtime,
and use whichever form the EC supports. At this time, always
request the default timeout, and only report the failing response
via a WARN_ONCE(). Future versions could acce
The Chrome OS EC has an updated set of parameters for the host
sleep event command. With the new parameters, the host can indicate
a timeout along with suspend messages. Specifically S0ix suspend
messages are supported now, though the host command format isn't
specific to S0ix. When the EC sees an
> On Apr 3, 2019, at 12:44 PM, Thadeu Lima de Souza Cascardo
> wrote:
>
> Commit 6987561c9e86 ("perf annotate: Enable annotation of BPF programs") adds
> support for BPF programs annotations but the new code does not build on
> 32-bit.
>
> Fixes: 6987561c9e86 ("perf annotate: Enable annotat
The interface /sys/device/system/cpu/split_lock_detect is added
to allow user to control split lock detection and show current split
lock detection setting.
Writing 1 to the file enables split lock detection and writing 0
disables split lock detection. Split lock detection is enabled or
disabled o
On Mon, Apr 1, 2019 at 11:02 PM Mark Brown wrote:
> regmap-irq should support active high/low, and if it doesn't it can't be
> a unique thing that only this device wants to implement so the common
> code should be improved.
The rt5677 driver needs its own irq regardless for hotword detection.
If
Currently only one kernel option "clearcpuid=" can be picked up by
kernel during boot time.
In some cases, user may want to clear a few cpu caps. This may be
useful to replace endless (new) kernel options like nosmep, nosmap,
etc.
Add support of multiple clearcpuid options to allow user to clear
The kernel option clearcpuid currently only takes feature bit which
can be changed from kernel to kernel.
Extend clearcpuid to use cap flag string, which is defined in
x86_cap_flags[] and won't be changed from kernel to kernel.
And user can easily get the cap flag string from /proc/cpuinfo.
Signe
Oops, I missed a piece of Guenter's feedback. Will post a v3 momentarily.
Apologies for the spam.
-Evan
The EC is in charge of controlling the keyboard backlight on
the Wilco platform. We expose a standard LED class device at
/sys/class/leds/chromeos::kbd_backlight. This driver is modeled
after the standard Chrome OS keyboard backlight driver at
drivers/platform/chrome/cros_kbd_led_backlight.c
Some
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw de
On Tue, 26 Mar 2019 22:45:45 -0500
Parav Pandit wrote:
> Below race condition and call trace exist with current device life cycle
> sequence.
>
> 1. In following sequence, child devices created while removing mdev parent
> device can be left out, or it may lead to race of removing half
> initial
On Wed, Apr 03, 2019 at 10:23:26AM -0700, Matthew Wilcox wrote:
> On Wed, Apr 03, 2019 at 03:21:22PM +1100, Tobin C. Harding wrote:
> > +void xa_object_migrate(struct xa_node *node, int numa_node)
> > +{
> > + struct xarray *xa = READ_ONCE(node->array);
> > + void __rcu **slot;
> > + struct x
On Wed, Apr 03, 2019 at 02:08:40PM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 3, 2019 at 2:04 PM Matthias Kaehlcke wrote:
> > > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> >
> > nit: the fact that a high priority workqueue is used is an
> > implementation detail, sin
On 2019-04-03, Sebastian Andrzej Siewior wrote:
> John identified three files which claim that RT task priorities start at
> zero. As far as I understand, 0 is used for DL and has nothing to do
> wihich RT priorities as identified by the RT policy.
>
> Correct the comment, valid RT priorities are
On Tue, Apr 02, 2019 at 06:25:30PM +0200, Uladzislau Rezki (Sony) wrote:
> This macro adds some debug code to check that the augment tree
> is maintained correctly, meaning that every node contains valid
> subtree_max_size value.
>
> By default this option is set to 0 and not active. It requires
>
On Wed, 2019-04-03 at 13:44 +0100, Will Deacon wrote:
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -4689,8 +4689,7 @@ static void free_zapped_rcu(struct rcu_head *ch)
> > return;
> >
> > raw_local_irq_save(flags);
> > - if (!graph_lock())
> > -
On Wed, Apr 03, 2019 at 06:00:30PM +, Roman Gushchin wrote:
> On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> > Currently we reach inside the list_head. This is a violation of the
> > layer of abstraction provided by the list_head. It makes the code
> > fragile. More impo
On Tue, Apr 02, 2019 at 06:25:31PM +0200, Uladzislau Rezki (Sony) wrote:
> This macro adds some debug code to check that vmap allocations
> are happened in ascending order.
>
> By default this option is set to 0 and not active. It requires
> recompilation of the kernel to activate it. Set to 1, co
On Wed, Apr 03, 2019 at 03:27:29PM -0500, Corey Minyard wrote:
> On Wed, Apr 03, 2019 at 02:33:23PM +1100, Stephen Rothwell wrote:
> > Hi Corey,
> >
> > After merging the ipmi tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
>
> Paul, any opinions on this? Is just runni
Hi, Uladzislau!
The patch looks really good to me! I've tried hard, but didn't find
any serious issues/bugs. Some small nits below.
Thank you for working on it!
BTW, when sending a new iteration, please use "[PATCH vX]" subject prefix,
e.g. [PATCH v3 1/3] mm/vmap: keep track of free blocks for v
Hi,
On Wed, Apr 3, 2019 at 2:04 PM Matthias Kaehlcke wrote:
> > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
>
> nit: the fact that a high priority workqueue is used is an
> implementation detail, since the driver has no function to perform a
> transfer with 'normal'/low prior
John identified three files which claim that RT task priorities start at
zero. As far as I understand, 0 is used for DL and has nothing to do
wihich RT priorities as identified by the RT policy.
Correct the comment, valid RT priorities are in the range from 1 to 99.
Reported-by: John Ogness
Sign
Change the iProc I2C driver to use the 'BIT' macro from all '1 << XXX'
bit operations to get rid of compiler warning and improve readability of
the code
Signed-off-by: Ray Jui
---
drivers/i2c/busses/i2c-bcm-iproc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
On Wed, Apr 03, 2019 at 01:31:37PM -0700, Douglas Anderson wrote:
> The software running on the Chrome OS Embedded Controller (cros_ec)
> handles SPI transfers in a bit of a wonky way. Specifically if the EC
> sees too long of a delay in a SPI transfer it will give up and the
> transfer will be co
On Wed, Apr 03, 2019 at 06:00:30PM +, Roman Gushchin wrote:
> On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> > Currently we reach inside the list_head. This is a violation of the
> > layer of abstraction provided by the list_head. It makes the code
> > fragile. More impo
Introduce the command and response structures for the second revision
of the host sleep event. These structures are part of a new EC change
that enables detection of failure to enter S0ix. The EC waits a
kernel-specified timeout (or a default amount of time) for the S0_SLP
pin to change, and wakes
Add support in code for the new forms of the host sleep event.
Detects the presence of this version of the command at runtime,
and use whichever form the EC supports. At this time, always
request the default timeout, and only report the failing response
via a WARN_ONCE(). Future versions could acce
The Chrome OS EC has an updated set of parameters for the host
sleep event command. With the new parameters, the host can indicate
a timeout along with suspend messages. Specifically S0ix suspend
messages are supported now, though the host command format isn't
specific to S0ix. When the EC sees an
On Thu, Apr 04, 2019 at 01:43:05AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core/objtool
> head: 64604d54d3115fee89598bfb6d8d2252f8a2d114
> commit: 37686b1353cfc30e127cef811959cdbcd0495d98 [2/25] tracing: Improve "if"
> macro code g
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, replace code of the following form:
sizeof(*resp) + props_count * sizeof(struct gb_power_supply_props_desc)
with
On Mon, Apr 01, 2019 at 02:37:19PM -0500, Bjorn Helgaas wrote:
> On Mon, Apr 1, 2019 at 9:08 AM Wolfram Sang wrote:
> >
> >
> > > > From: Bjorn Helgaas
> > > >
> > > > 54fb4a05af0a ("i2c: Check for ACPI resource conflicts") included
> > > > so we could use acpi_check_region(). fd46a0064af1 ("i2
Hi Wolfram,
On 4/3/2019 1:44 PM, Wolfram Sang wrote:
> On Tue, Apr 02, 2019 at 06:18:21PM -0700, Ray Jui wrote:
>> This patch series adds the following support to the iProc I2C driver:
>> - Increase maximum read transfer size to 255 bytes
>> - I2C slave mode
>> - Polling mode
>> - NIC I2C mode
>>
On Wed, Apr 3, 2019 at 1:29 PM Andy Shevchenko
wrote:
>
> On Tue, Apr 02, 2019 at 06:02:40PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Apr 2, 2019 at 5:59 PM Andy Shevchenko
> > wrote:
> > >
> > > Since insert_resource() might return an error we don't need
> > > to shadow its error code and wou
Hi,
On Thu, Mar 28, 2019 at 11:19:45AM +, Adamski, Krzysztof (Nokia -
PL/Wroclaw) wrote:
> Some recent commits to this driver were trying to make sure the TSS
> interrupt is not generated on busy system due to 25ms timer expiring
> between commands. It can still happen, however if STOP comman
On Wed, Apr 03, 2019 at 08:02:43AM -0700, Randy Dunlap wrote:
> On 4/3/19 1:24 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190402:
> >
>
> on x86_64:
>
> arch/x86/entry/entry_64.o: warning: objtool: .entry.text+0x909: unreachable
> instruction
Your .o file looks odd. I ca
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/d
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
On Mon, Apr 01, 2019 at 01:14:37PM +0300, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> Make sure to free the i2c adapter on the error exit path.
>
> Signed-off-by: Laurentiu Tudor
> Reviewed-by: Mukesh Ojha
> Reviewed-by: Uwe Kleine-Konig
> Fixes: e1ab9a468e3b ("i2c: imx: improv
Replace bitshifts on lines 54, 56 and 78 of ad7746.c.
Signed-off-by: Lucas Oshiro
---
drivers/staging/iio/cdc/ad7746.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 0eb28fea876e..ea48b14cee72 10
On Tue, Apr 02, 2019 at 06:18:21PM -0700, Ray Jui wrote:
> This patch series adds the following support to the iProc I2C driver:
> - Increase maximum read transfer size to 255 bytes
> - I2C slave mode
> - Polling mode
> - NIC I2C mode
>
> This patch series is based on kernel v5.1-rc3 and available
The software running on the Chrome OS Embedded Controller (cros_ec)
handles SPI transfers in a bit of a wonky way. Specifically if the EC
sees too long of a delay in a SPI transfer it will give up and the
transfer will be counted as failed. Unfortunately the timeout is
fairly short, though the ac
On Wed, Apr 03, 2019 at 10:19:44PM +0300, Cyrill Gorcunov wrote:
>
> You know, seems I got what happened -- p4_general_events do
> not cover all general events, they stop at PERF_COUNT_HW_BUS_CYCLES,
> while more 3 general event left. This is 'cause I've not been following
> pmu evolution in code.
On Wed, Apr 03, 2019 at 02:33:23PM +1100, Stephen Rothwell wrote:
> Hi Corey,
>
> After merging the ipmi tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
Paul, any opinions on this? Is just running this in a workqueue
the best idea?
-corey
>
> drivers/char/ipmi/ipmi_ms
Jacek
On 4/3/19 3:10 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> Thank you for the patch.
>
> You need Lee Jones on CC for this series.
>
Yes I saw I missed Lee.
> One more comment below.
>
> On 3/25/19 3:24 PM, Dan Murphy wrote:
>> The LM3697 is a single function LED driver. The single functi
On Wed, Mar 27, 2019 at 09:25:34AM -0500, Mario Limonciello wrote:
> When converting the driver two arguments were transposed leading
> to rfkill not working.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201427
> Reported-by: Pepijn de Vos
> Fixes: 549b49 ("platform/x86: dell-smbios:
Hi Beatriz,
Thank you for the patch, just some small comments.
Regarding the patch title, if you run
git log drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
You will see that commits starts with the following tags "staging:
rtl8723bs: "
Also, try to add a bit more information to the title,
Hi Dan,
Thank you for the patch.
On 4/3/19 8:19 PM, Dan Murphy wrote:
Fix misspelling and capitalization of LED in the Kconfig.
Reported-by: Randy Dunlap
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/leds
> >>>Is the core wide lock primarily responsible for the regression? I ran
> >>>upto patch
> >>>12 which also has the core wide lock for tagged cgroups and also calls
> >>>newidle_balance() from pick_next_task(). I don't see any regression.
> >>>Of
> >>>course
> >>>the core sched version of pick_n
On Wed, Apr 03, 2019 at 03:20:18PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> If da_tokens are allocated, but dell_smbios_init() eventually fails, it will
> free the da_tokens but it does not reset the da_num_tokens number. This
> leads to the possibility of a use after fr
Hi Dan,
On 4/3/19 2:02 PM, Dan Murphy wrote:
Hello
On 3/25/19 9:23 AM, Dan Murphy wrote:
All
I know that it has been a long time but I put some additional effort into this
code. The TI LMU common code right now handles brightness and ramp up/down
setting for the LM3697. This so far are the
Hi Dan,
Thank you for the patch.
You need Lee Jones on CC for this series.
One more comment below.
On 3/25/19 3:24 PM, Dan Murphy wrote:
The LM3697 is a single function LED driver. The single function LED
driver needs to reside in the LED directory as a dedicated LED driver
and not as a MFD d
On Wed, Apr 03, 2019 at 01:37:51PM -0500, Alan Tull wrote:
> >
> > it's state, not status for most fpga manager drivers. It should
> > return 'operating' if everything went well.
Yeah, sorry :)
> > It seems like there's a possible scenario where the FPGA starts up
> > with the FPGA in 'operating
Currently there is no easy way to get the number of CPUs on the system.
Applications are divided into 2 groups:
One group allocates buffer and call sched_getaffinity(2) once. It works
but either underallocate or overallocates and in the future such application
will become buggy as Linux will start
201 - 300 of 957 matches
Mail list logo
