On Thu, Oct 25, 2018 at 4:52 AM Z.q. Hou wrote:
The correct prefix for arm dts patches should be: "ARM: dts: ls1021a:
...", and it should be better to mention the string removed in the
title too.
>
> From: Hou Zhiqiang
>
> Removed the wrong compatible string "snps,dw-pcie", in case
> match
On Thu, Oct 25, 2018 at 4:52 AM Z.q. Hou wrote:
The correct prefix for arm dts patches should be: "ARM: dts: ls1021a:
...", and it should be better to mention the string removed in the
title too.
>
> From: Hou Zhiqiang
>
> Removed the wrong compatible string "snps,dw-pcie", in case
> match
Hi Linus,
Here is the pull-request for the RTC subsystem for 4.20.
This cycle, there were mostly non urgent fixes in drivers. I also
finally unexported the non managed registration.
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26
Hi Linus,
Here is the pull-request for the RTC subsystem for 4.20.
This cycle, there were mostly non urgent fixes in drivers. I also
finally unexported the non managed registration.
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26
[Adding Joe Perches]
On Fri, 26 Oct 2018, Sasha Levin wrote:
> On Fri, Oct 26, 2018 at 04:04:45PM -0300, Shayenne da Luz Moura wrote:
> > This change was suggested by checkpath.pl. Use unsigned int with bitfield
> > allocate only one bit to the boolean variable.
> >
> > CHECK: Avoid using bool
[Adding Joe Perches]
On Fri, 26 Oct 2018, Sasha Levin wrote:
> On Fri, Oct 26, 2018 at 04:04:45PM -0300, Shayenne da Luz Moura wrote:
> > This change was suggested by checkpath.pl. Use unsigned int with bitfield
> > allocate only one bit to the boolean variable.
> >
> > CHECK: Avoid using bool
Hi,
OCTEON (MIPS64) MMC driver probe fails with v4.19, because with
commit 6c2fb2ea76361da9b420a8e23a2a19e7842cbdda
Author: Robin Murphy
Date: Mon Jul 23 23:16:09 2018 +0100
of/device: Set bus DMA mask as appropriate
we now get a default 32-bit bus DMA mask, and the device itself has
Hi,
OCTEON (MIPS64) MMC driver probe fails with v4.19, because with
commit 6c2fb2ea76361da9b420a8e23a2a19e7842cbdda
Author: Robin Murphy
Date: Mon Jul 23 23:16:09 2018 +0100
of/device: Set bus DMA mask as appropriate
we now get a default 32-bit bus DMA mask, and the device itself has
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
>
>
> On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
> > >
> > >
> > > On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Oct 26, 2018
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
>
>
> On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
> > >
> > >
> > > On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Oct 26, 2018
On Fri, Oct 26, 2018 at 04:04:45PM -0300, Shayenne da Luz Moura wrote:
This change was suggested by checkpath.pl. Use unsigned int with bitfield
allocate only one bit to the boolean variable.
CHECK: Avoid using bool structure members because of possible alignment
issues
Signed-off-by: Shayenne
On Fri, Oct 26, 2018 at 04:04:45PM -0300, Shayenne da Luz Moura wrote:
This change was suggested by checkpath.pl. Use unsigned int with bitfield
allocate only one bit to the boolean variable.
CHECK: Avoid using bool structure members because of possible alignment
issues
Signed-off-by: Shayenne
On Fri, Oct 26, 2018 at 9:35 PM, Joel Fernandes wrote:
> But I have the index variable, so it would be cleaner to just return that? I
> believe I can just drop the cast and do that.
Yeah, that should be fine.
--
Kees Cook
On Fri, Oct 26, 2018 at 9:35 PM, Joel Fernandes wrote:
> But I have the index variable, so it would be cleaner to just return that? I
> believe I can just drop the cast and do that.
Yeah, that should be fine.
--
Kees Cook
On Fri, Oct 26, 2018 at 11:21 AM Jens Axboe wrote:
>
> On 10/26/18 7:45 AM, Diego Viola wrote:
> > med_power_with_dipm causes my T450 to freeze with a SAMSUNG
> > MZ7TD256HAFV-000L9 SSD (firmware DXT02L5Q).
> >
> > Switching the LPM to max_performance fixes this issue.
>
> Applied, thanks.
>
> --
On Fri, Oct 26, 2018 at 11:21 AM Jens Axboe wrote:
>
> On 10/26/18 7:45 AM, Diego Viola wrote:
> > med_power_with_dipm causes my T450 to freeze with a SAMSUNG
> > MZ7TD256HAFV-000L9 SSD (firmware DXT02L5Q).
> >
> > Switching the LPM to max_performance fixes this issue.
>
> Applied, thanks.
>
> --
On Fri, Oct 26, 2018 at 08:04:24PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> wrote:
> > In later patches we will need to map types to names, so create a table
> > for that which can also be used and reused in different parts of old and
> > new code. Also
On Fri, Oct 26, 2018 at 08:04:24PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> wrote:
> > In later patches we will need to map types to names, so create a table
> > for that which can also be used and reused in different parts of old and
> > new code. Also
On Thu, Oct 25, 2018 at 01:23:08PM +, Pascal PAILLET-LME wrote:
> I have reworked the code so that we don't touch any more to the init_data.
> the new loop to register the regulators is below:
>
> for (i = 0; i < ARRAY_SIZE(stpmic1_regulator_cfgs); i++) {
> ret =
On Thu, Oct 25, 2018 at 01:23:08PM +, Pascal PAILLET-LME wrote:
> I have reworked the code so that we don't touch any more to the init_data.
> the new loop to register the regulators is below:
>
> for (i = 0; i < ARRAY_SIZE(stpmic1_regulator_cfgs); i++) {
> ret =
On Fri, Oct 26, 2018 at 09:00:51AM +0100, Lee Jones wrote:
> On Thu, 25 Oct 2018, Richard Fitzgerald wrote:
> > Largely the point. How long do you think it would take to populate the
> > cache if you had to read thousands of registers over I2C? Boot time matters.
> > Deferring it until it's
On Fri, Oct 26, 2018 at 09:00:51AM +0100, Lee Jones wrote:
> On Thu, 25 Oct 2018, Richard Fitzgerald wrote:
> > Largely the point. How long do you think it would take to populate the
> > cache if you had to read thousands of registers over I2C? Boot time matters.
> > Deferring it until it's
On Fri, Oct 26, 2018 at 1:21 PM Trond Myklebust wrote:
>
> We agreed about a year or so ago to take turns maintaining the linux-
> next branches.
Heh. That was a simpler pattern than I thought. It was just hidden by
the fact that there are sometimes more than one pull request during
the merge
On Fri, Oct 26, 2018 at 1:21 PM Trond Myklebust wrote:
>
> We agreed about a year or so ago to take turns maintaining the linux-
> next branches.
Heh. That was a simpler pattern than I thought. It was just hidden by
the fact that there are sometimes more than one pull request during
the merge
On Fri, Oct 26, 2018 at 08:39:13PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> wrote:
> > pstore currently calls persistent_ram_save_old even if a buffer is
> > empty. While this appears to work, it is simply not the right thing to
> > do and could lead to
On Fri, Oct 26, 2018 at 08:39:13PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> wrote:
> > pstore currently calls persistent_ram_save_old even if a buffer is
> > empty. While this appears to work, it is simply not the right thing to
> > do and could lead to
On Fri, 2018-10-26 at 13:10 -0700, Linus Torvalds wrote:
> On Fri, Oct 26, 2018 at 8:45 AM Trond Myklebust <
> tron...@hammerspace.com> wrote:
> >
> > NFS client updates for Linux 4.20
>
> Pulled.
Thank you!
> Btw, just out of curiosity - is there some pattern to when I get the
> pull requests
On Fri, 2018-10-26 at 13:10 -0700, Linus Torvalds wrote:
> On Fri, Oct 26, 2018 at 8:45 AM Trond Myklebust <
> tron...@hammerspace.com> wrote:
> >
> > NFS client updates for Linux 4.20
>
> Pulled.
Thank you!
> Btw, just out of curiosity - is there some pattern to when I get the
> pull requests
Hi,
what is the best strategy to support the above mentioned
bluetooth (+ wlan combo) chip by a serdev driver?
We have the chip up and running for long time with using
hciattach on the serial port (and no vendor specific
functions like firmware download). And our own out-of-tree
driver to control
Hi,
what is the best strategy to support the above mentioned
bluetooth (+ wlan combo) chip by a serdev driver?
We have the chip up and running for long time with using
hciattach on the serial port (and no vendor specific
functions like firmware download). And our own out-of-tree
driver to control
Hi Marc,
[..snip..]
[...]
+/**
+ * ti_sci_inta_register_event() - Register a event to an interrupt aggregator
+ * @dev: Device pointer to source generating the event
+ * @src_id:TISCI device ID of the event source
+ * @src_index: Event source index within the device.
+ * @virq:
Hi Marc,
[..snip..]
[...]
+/**
+ * ti_sci_inta_register_event() - Register a event to an interrupt aggregator
+ * @dev: Device pointer to source generating the event
+ * @src_id:TISCI device ID of the event source
+ * @src_index: Event source index within the device.
+ * @virq:
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo
On Fri, Oct 26, 2018 at 8:45 AM Trond Myklebust wrote:
>
> NFS client updates for Linux 4.20
Pulled.
Btw, just out of curiosity - is there some pattern to when I get the
pull requests from you vs Anna? Or is it just "whoever happens to have
the baton"? Not that it matters, but I was wondering
On Fri, Oct 26, 2018 at 8:45 AM Trond Myklebust wrote:
>
> NFS client updates for Linux 4.20
Pulled.
Btw, just out of curiosity - is there some pattern to when I get the
pull requests from you vs Anna? Or is it just "whoever happens to have
the baton"? Not that it matters, but I was wondering
On Fri, Oct 26, 2018 at 08:42:12PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:22 PM, Joel Fernandes
> wrote:
> > On Fri, Oct 26, 2018 at 07:16:28PM +0100, Kees Cook wrote:
> >> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> >> wrote:
> >> > This reverts commit
On Fri, Oct 26, 2018 at 08:42:12PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:22 PM, Joel Fernandes
> wrote:
> > On Fri, Oct 26, 2018 at 07:16:28PM +0100, Kees Cook wrote:
> >> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> >> wrote:
> >> > This reverts commit
On 10/26/18 12:51 PM, Dave Hansen wrote:
...
> The result is that, after a fork(), the child's pkey state ends up
> looking like it does after an execve(), which is totally wrong. pkeys
> that are already allocated can be allocated again, for instance.
One thing I omitted. This was very nicely
On 10/26/18 12:51 PM, Dave Hansen wrote:
...
> The result is that, after a fork(), the child's pkey state ends up
> looking like it does after an execve(), which is totally wrong. pkeys
> that are already allocated can be allocated again, for instance.
One thing I omitted. This was very nicely
From: Dave Hansen
Our creation of new mm's is a bit convoluted. At fork(), the code
does:
1. memcpy() the parent mm to initialize child
2. mm_init() to initalize some select stuff stuff
3. dup_mmap() to create true copies that memcpy()
did not do right.
From: Dave Hansen
There was a bug where the per-mm pkey state was not being preserved
across fork() in the child. fork() is performed in the pkey
selftests, but all of our pkey activity is performed in the parent.
The child does not perform any actions sensitive to pkey state.
To make the
From: Dave Hansen
Our creation of new mm's is a bit convoluted. At fork(), the code
does:
1. memcpy() the parent mm to initialize child
2. mm_init() to initalize some select stuff stuff
3. dup_mmap() to create true copies that memcpy()
did not do right.
From: Dave Hansen
There was a bug where the per-mm pkey state was not being preserved
across fork() in the child. fork() is performed in the pkey
selftests, but all of our pkey activity is performed in the parent.
The child does not perform any actions sensitive to pkey state.
To make the
On 10/25/2018 11:24 PM, Pavel Machek wrote:
>
> We don't want brightness < 0, but this may not be best way to do
> this. We also don't want brightness > max_brightness, but I'm not sure
> this check is effective.
>
> We probably also don't want pattern where all the delta_t s are zero.
>
> I
On 10/25/2018 11:24 PM, Pavel Machek wrote:
>
> We don't want brightness < 0, but this may not be best way to do
> this. We also don't want brightness > max_brightness, but I'm not sure
> this check is effective.
>
> We probably also don't want pattern where all the delta_t s are zero.
>
> I
On Fri, Oct 26, 2018 at 7:22 PM, Joel Fernandes wrote:
> On Fri, Oct 26, 2018 at 07:16:28PM +0100, Kees Cook wrote:
>> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
>> wrote:
>> > This reverts commit 25b63da64708212985c06c7f8b089d356efdd9cf.
>> >
>> > Due to the commit which is being
On Fri, Oct 26, 2018 at 7:22 PM, Joel Fernandes wrote:
> On Fri, Oct 26, 2018 at 07:16:28PM +0100, Kees Cook wrote:
>> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
>> wrote:
>> > This reverts commit 25b63da64708212985c06c7f8b089d356efdd9cf.
>> >
>> > Due to the commit which is being
On Fri, Oct 26, 2018 at 08:27:49PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 8:22 PM, Joel Fernandes
> wrote:
> > On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
> >> From the code flow, the 'max' checks are already being done on the prz
> >> passed to
On Fri, Oct 26, 2018 at 08:27:49PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 8:22 PM, Joel Fernandes
> wrote:
> > On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
> >> From the code flow, the 'max' checks are already being done on the prz
> >> passed to
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> pstore currently calls persistent_ram_save_old even if a buffer is
> empty. While this appears to work, it is simply not the right thing to
> do and could lead to bugs so lets avoid that. It also prevent misleading
> prints in the
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> pstore currently calls persistent_ram_save_old even if a buffer is
> empty. While this appears to work, it is simply not the right thing to
> do and could lead to bugs so lets avoid that. It also prevent misleading
> prints in the
On Fri, Oct 26, 2018 at 08:32:16PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> wrote:
> > Both the id and type fields of a pstore_record are set by
> > ramoops_get_next_prz. So we can just pass a pointer to the pstore_record
> > instead of passing
The function 'wait_event_freezable' calls '__wait_event_freezable' that
uses 'try_to_freeze', which is defined in freezer.h.
This causes a compilation error for callers of 'wait_event_freezables',
forcing them to include also freezer.h.
Signed-off-by: Carmeli Tamir
---
include/linux/wait.h | 1
On Fri, Oct 26, 2018 at 08:32:16PM +0100, Kees Cook wrote:
> On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
> wrote:
> > Both the id and type fields of a pstore_record are set by
> > ramoops_get_next_prz. So we can just pass a pointer to the pstore_record
> > instead of passing
The function 'wait_event_freezable' calls '__wait_event_freezable' that
uses 'try_to_freeze', which is defined in freezer.h.
This causes a compilation error for callers of 'wait_event_freezables',
forcing them to include also freezer.h.
Signed-off-by: Carmeli Tamir
---
include/linux/wait.h | 1
Hi Linus,
Please pull one LED fix for 4.20-rc1.
The patch fixes regression introduced by the commit
45d4c6de4e49 ("leds: gpio: Try to lookup gpiod from device").
The following changes since commit 8dbac65f5c181e4723586ab738b703bb23bc3f2a:
leds: sc27xx: Add pattern_set/clear interfaces for
Hi Linus,
Please pull one LED fix for 4.20-rc1.
The patch fixes regression introduced by the commit
45d4c6de4e49 ("leds: gpio: Try to lookup gpiod from device").
The following changes since commit 8dbac65f5c181e4723586ab738b703bb23bc3f2a:
leds: sc27xx: Add pattern_set/clear interfaces for
On Fri 26-10-18 21:25:51, Michal Hocko wrote:
> On Fri 26-10-18 10:25:31, Johannes Weiner wrote:
[...]
> > There is of course the scenario brought forward in this thread, where
> > multiple threads of a process race and the second one enters oom even
> > though it doesn't need to anymore. What the
On Fri 26-10-18 21:25:51, Michal Hocko wrote:
> On Fri 26-10-18 10:25:31, Johannes Weiner wrote:
[...]
> > There is of course the scenario brought forward in this thread, where
> > multiple threads of a process race and the second one enters oom even
> > though it doesn't need to anymore. What the
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> Both the id and type fields of a pstore_record are set by
> ramoops_get_next_prz. So we can just pass a pointer to the pstore_record
> instead of passing individual elements. This results in cleaner more
> readable code and fewer
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> Both the id and type fields of a pstore_record are set by
> ramoops_get_next_prz. So we can just pass a pointer to the pstore_record
> instead of passing individual elements. This results in cleaner more
> readable code and fewer
On Fri, Oct 26, 2018 at 8:22 PM, Joel Fernandes wrote:
> On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
>> From the code flow, the 'max' checks are already being done on the prz
>> passed to ramoops_get_next_prz. Lets remove it to simplify this function
>> and reduce its
On Fri, Oct 26, 2018 at 8:22 PM, Joel Fernandes wrote:
> On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
>> From the code flow, the 'max' checks are already being done on the prz
>> passed to ramoops_get_next_prz. Lets remove it to simplify this function
>> and reduce its
On Fri 26-10-18 10:25:31, Johannes Weiner wrote:
> On Mon, Oct 22, 2018 at 09:13:23AM +0200, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Tetsuo has reported [1] that a single process group memcg might easily
> > swamp the log with no-eligible oom victim reports due to race between
> > the
On Fri 26-10-18 10:25:31, Johannes Weiner wrote:
> On Mon, Oct 22, 2018 at 09:13:23AM +0200, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Tetsuo has reported [1] that a single process group memcg might easily
> > swamp the log with no-eligible oom victim reports due to race between
> > the
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
>
>
> On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
> > > On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
> > > > So, I'm adding the following to my
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
>
>
> On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
> > > On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
> > > > So, I'm adding the following to my
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> From the code flow, the 'max' checks are already being done on the prz
> passed to ramoops_get_next_prz. Lets remove it to simplify this function
> and reduce its arguments.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
>
Add whiteline after variable declarations to remove the checkpath.pl
warning:
WARNING: Missing a blank line after declarations
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_cmd.c | 4
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
drivers/gpu/drm/qxl/qxl_draw.c| 2 ++
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> From the code flow, the 'max' checks are already being done on the prz
> passed to ramoops_get_next_prz. Lets remove it to simplify this function
> and reduce its arguments.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
>
Add whiteline after variable declarations to remove the checkpath.pl
warning:
WARNING: Missing a blank line after declarations
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_cmd.c | 4
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
drivers/gpu/drm/qxl/qxl_draw.c| 2 ++
On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
> From the code flow, the 'max' checks are already being done on the prz
> passed to ramoops_get_next_prz. Lets remove it to simplify this function
> and reduce its arguments.
>
> Signed-off-by: Joel Fernandes (Google)
>
On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
> From the code flow, the 'max' checks are already being done on the prz
> passed to ramoops_get_next_prz. Lets remove it to simplify this function
> and reduce its arguments.
>
> Signed-off-by: Joel Fernandes (Google)
>
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
Actually, you can
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
Actually, you can
On Fri, Oct 26, 2018 at 9:07 AM Rob Herring wrote:
>
> Please pull DT updates for 4.20.
Pulled,
Linus
On Fri, Oct 26, 2018 at 9:07 AM Rob Herring wrote:
>
> Please pull DT updates for 4.20.
Pulled,
Linus
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
> On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
> > So, I'm adding the following to my tree to help in diagnosing problems
> > with this overwrite mode:
> Actually, you can use per-event overwrite term to disable overwrite
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
> On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
> > So, I'm adding the following to my tree to help in diagnosing problems
> > with this overwrite mode:
> Actually, you can use per-event overwrite term to disable overwrite
On Fri, Oct 26, 2018 at 8:39 AM Eduardo Valentin wrote:
>
> Thermal-SoC Management updates for v4.20-rc1
Pulled,
Linus
On Fri, Oct 26, 2018 at 8:39 AM Eduardo Valentin wrote:
>
> Thermal-SoC Management updates for v4.20-rc1
Pulled,
Linus
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
Actually, you can use per-event overwrite term to disable overwrite mode
for perf top.
/*
* Check per-event overwrite term.
* perf
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
Actually, you can use per-event overwrite term to disable overwrite mode
for perf top.
/*
* Check per-event overwrite term.
* perf
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> Since we store the type of the prz when we initialize it, we no longer
> need to pass it again in ramoops_get_next_prz since we can just use that
> to setup the pstore record. So lets remove it from the argument list.
>
>
On 10/26/18 4:07 AM, Mike Rapoport wrote:
> On Thu, Oct 25, 2018 at 04:07:13PM -0700, Florian Fainelli wrote:
>> On 10/25/18 2:13 PM, Rob Herring wrote:
>>> On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport wrote:
On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> +Ard
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> Since we store the type of the prz when we initialize it, we no longer
> need to pass it again in ramoops_get_next_prz since we can just use that
> to setup the pstore record. So lets remove it from the argument list.
>
>
On 10/26/18 4:07 AM, Mike Rapoport wrote:
> On Thu, Oct 25, 2018 at 04:07:13PM -0700, Florian Fainelli wrote:
>> On 10/25/18 2:13 PM, Rob Herring wrote:
>>> On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport wrote:
On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> +Ard
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> In later patches we will need to map types to names, so create a table
> for that which can also be used and reused in different parts of old and
> new code. Also use it to save the type in the PRZ which will be useful
> in later
On Fri, Oct 26, 2018 at 7:00 PM, Joel Fernandes (Google)
wrote:
> In later patches we will need to map types to names, so create a table
> for that which can also be used and reused in different parts of old and
> new code. Also use it to save the type in the PRZ which will be useful
> in later
This change was suggested by checkpath.pl. Use unsigned int with bitfield
allocate only one bit to the boolean variable.
CHECK: Avoid using bool structure members because of possible alignment
issues
Signed-off-by: Shayenne da Luz Moura
---
drivers/staging/vboxvideo/vbox_drv.h| 14
This change was suggested by checkpath.pl. Use unsigned int with bitfield
allocate only one bit to the boolean variable.
CHECK: Avoid using bool structure members because of possible alignment
issues
Signed-off-by: Shayenne da Luz Moura
---
drivers/staging/vboxvideo/vbox_drv.h| 14
This change was suggested by checkpath.pl.
CHECK: Prefer kernel type 'u32' over 'uint32_t'
Signed-off-by: Shayenne da Luz Moura
---
drivers/staging/vboxvideo/vbox_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
This change was suggested by checkpath.pl.
CHECK: Prefer kernel type 'u32' over 'uint32_t'
Signed-off-by: Shayenne da Luz Moura
---
drivers/staging/vboxvideo/vbox_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
This series cleans the following checkpatch.pl issues:
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Avoid using bool structure members because of possible alignment issues
Shayenne da Luz Moura (2):
staging: vboxvideo: Change uint32_t to u32
staging: vboxvideo: Use unsigned int
This series cleans the following checkpatch.pl issues:
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Avoid using bool structure members because of possible alignment issues
Shayenne da Luz Moura (2):
staging: vboxvideo: Change uint32_t to u32
staging: vboxvideo: Use unsigned int
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
>From 40feb09001c7cc2ba8aeaa0a8f03b6d28fa4ca95 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo
Date: Fri, 26 Oct 2018 15:55:23 -0300
Subject: [PATCH 1/1] perf top: Allow disabling the
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
>From 40feb09001c7cc2ba8aeaa0a8f03b6d28fa4ca95 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo
Date: Fri, 26 Oct 2018 15:55:23 -0300
Subject: [PATCH 1/1] perf top: Allow disabling the
On Fri, Oct 26, 2018 at 7:04 AM Dan Carpenter wrote:
>
> On Thu, Oct 25, 2018 at 09:45:11PM -0300, Matheus Tavares wrote:
> > From: Victor Colombo
> >
> > This patch adds the IIO_CHAN_INFO_SCALE mask to ad2s90_chan and
> > implements the relative read behavior at ad2s90_read_raw.
> >
> >
On Fri, Oct 26, 2018 at 7:04 AM Dan Carpenter wrote:
>
> On Thu, Oct 25, 2018 at 09:45:11PM -0300, Matheus Tavares wrote:
> > From: Victor Colombo
> >
> > This patch adds the IIO_CHAN_INFO_SCALE mask to ad2s90_chan and
> > implements the relative read behavior at ad2s90_read_raw.
> >
> >
101 - 200 of 840 matches
Mail list logo
