xilinx_vdma_start_transfer() is used only for VDMA IP, still it contains
conditional code on has_sg variable. has_sg is set only whenever the HW
does support SG mode, that is never true for VDMA IP.
This patch drops the never-taken branches.
Signed-off-by: Andrea Merello
Reviewed-by: Radhey
xilinx_vdma_start_transfer() is used only for VDMA IP, still it contains
conditional code on has_sg variable. has_sg is set only whenever the HW
does support SG mode, that is never true for VDMA IP.
This patch drops the never-taken branches.
Signed-off-by: Andrea Merello
Reviewed-by: Radhey
On 11/20/2018 4:11 AM, Sudeep Holla wrote:
On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote:
[...]
I was interested in testing these on QDF2400, an ARM64 platform, since this
series touches core ARM64 code and I'd hate to see a regression. However, I
can't figure out what
On 11/20/2018 4:11 AM, Sudeep Holla wrote:
On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote:
[...]
I was interested in testing these on QDF2400, an ARM64 platform, since this
series touches core ARM64 code and I'd hate to see a regression. However, I
can't figure out what
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
> In the documentation, AMD officially recommends against this by default,
> and I can speak for Intel that our position is that as well: this really
> must not be on by default.
Thanks for pointing to the AMD doc, it's indeed clearly stated there.
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
> In the documentation, AMD officially recommends against this by default,
> and I can speak for Intel that our position is that as well: this really
> must not be on by default.
Thanks for pointing to the AMD doc, it's indeed clearly stated there.
On Tue, Nov 20, 2018 at 10:16:02AM +0530, Viresh Kumar wrote:
> On 19-11-18, 14:18, Quentin Perret wrote:
> > @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu
> > *sg_cpu)
>
> > - if ((util + cpu_util_dl(rq)) >= max)
> > - return max;
> > + if (type ==
On Tue, Nov 20, 2018 at 10:16:02AM +0530, Viresh Kumar wrote:
> On 19-11-18, 14:18, Quentin Perret wrote:
> > @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu
> > *sg_cpu)
>
> > - if ((util + cpu_util_dl(rq)) >= max)
> > - return max;
> > + if (type ==
On Tue, Nov 20, 2018 at 2:00 PM Yangtao Li wrote:
>
> use of_node_put() to release the refcount.
I gather that the of_node_put() is missing?
If so, that should be stated in the changelog too.
> Signed-off-by: Yangtao Li
> ---
> drivers/cpuidle/cpuidle-big_little.c | 8 ++--
> 1 file
On Tue, Nov 20, 2018 at 2:00 PM Yangtao Li wrote:
>
> use of_node_put() to release the refcount.
I gather that the of_node_put() is missing?
If so, that should be stated in the changelog too.
> Signed-off-by: Yangtao Li
> ---
> drivers/cpuidle/cpuidle-big_little.c | 8 ++--
> 1 file
On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > 5. Adjust the scripts so that we only have to wire up new syscalls
> > once. They'll have a nr above 1024, and they'll have the same nr on
> > all x86 variants.
>
> Is there a sufficiently sized gap on all other
On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > 5. Adjust the scripts so that we only have to wire up new syscalls
> > once. They'll have a nr above 1024, and they'll have the same nr on
> > all x86 variants.
>
> Is there a sufficiently sized gap on all other
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
>
> When performance goes down by 50% on some loads, people need to start
> asking themselves whether
On Sun, 18 Nov 2018, Linus Torvalds wrote:
> This was marked for stable, and honestly, nowhere in the discussion
> did I see any mention of just *how* bad the performance impact of this
> was.
>
> When performance goes down by 50% on some loads, people need to start
> asking themselves whether
On Tue, Nov 20, 2018 at 2:11 AM Jarkko Sakkinen
wrote:
>
> On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen
> > wrote:
> > >
> > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote:
> > > > 1. The kernel needs some
On Tue, Nov 20, 2018 at 2:11 AM Jarkko Sakkinen
wrote:
>
> On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen
> > wrote:
> > >
> > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote:
> > > > 1. The kernel needs some
On Tue 20-11-18 16:13:35, Oscar Salvador wrote:
>
> > Signed-off-by: Michal Hocko
> [...]
> > + do {
> > + for (pfn = start_pfn; pfn;)
> > + {
> > + /* start memory hot removal */
>
> Should we change thAT comment? I mean, this is not really the hot-
>
On Tue 20-11-18 16:13:35, Oscar Salvador wrote:
>
> > Signed-off-by: Michal Hocko
> [...]
> > + do {
> > + for (pfn = start_pfn; pfn;)
> > + {
> > + /* start memory hot removal */
>
> Should we change thAT comment? I mean, this is not really the hot-
>
On Tue, Nov 20, 2018 at 02:27:03PM +0100, Stefan Agner wrote:
> Add length to the struct dw_pcie and check that the accessors
> dw_pcie_(rd|wr)_own_conf() do not read/write beyond that point.
>
> Signed-off-by: Stefan Agner
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 4
>
On Tue, Nov 20, 2018 at 02:27:03PM +0100, Stefan Agner wrote:
> Add length to the struct dw_pcie and check that the accessors
> dw_pcie_(rd|wr)_own_conf() do not read/write beyond that point.
>
> Signed-off-by: Stefan Agner
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 4
>
On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google)
wrote:
>
> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> where we don't need to modify core VFS structures to get the same
> behavior of the seal. This solves several side-effects pointed out by
> Andy [2].
>
>
On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google)
wrote:
>
> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
> where we don't need to modify core VFS structures to get the same
> behavior of the seal. This solves several side-effects pointed out by
> Andy [2].
>
>
> On Nov 20, 2018, at 8:50 AM, Waiman Long wrote:
>
> On 11/20/2018 01:42 AM, Qian Cai wrote:
>> The current value of the early boot static pool size is not big enough
>> for systems with large number of CPUs with timer or/and workqueue
>> objects selected. As the results, systems have 60+
> On Nov 20, 2018, at 8:50 AM, Waiman Long wrote:
>
> On 11/20/2018 01:42 AM, Qian Cai wrote:
>> The current value of the early boot static pool size is not big enough
>> for systems with large number of CPUs with timer or/and workqueue
>> objects selected. As the results, systems have 60+
On 18-11-20 14:55:23, Marc Zyngier wrote:
> > Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
> > this minimum is defined in aarch64 specs. I will change it to 56.
>
> See D10.1.2 (The system counter) in the ARM ARM[1], which says:
>
>
> The Generic Timer provides a
On 18-11-20 14:55:23, Marc Zyngier wrote:
> > Yeah, I saw 56 is used in arm_arch_timer.c, but I could not find where
> > this minimum is defined in aarch64 specs. I will change it to 56.
>
> See D10.1.2 (The system counter) in the ARM ARM[1], which says:
>
>
> The Generic Timer provides a
On 11/20/18 6:54 AM, Yangtao Li wrote:
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
Reviewed-by: Guenter Roeck
---
Changes in v2:
-do that right after its last use to also cover
error handling.
---
drivers/watchdog/cpwd.c | 2 ++
1 file changed, 2
On Tue 20-11-18 15:51:32, Oscar Salvador wrote:
> On Tue, 2018-11-20 at 14:43 +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > do_migrate_range has been limiting the number of pages to migrate to
> > 256
> > for some reason which is not documented.
>
> When looking back at old
On 11/20/18 6:54 AM, Yangtao Li wrote:
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
Reviewed-by: Guenter Roeck
---
Changes in v2:
-do that right after its last use to also cover
error handling.
---
drivers/watchdog/cpwd.c | 2 ++
1 file changed, 2
On Tue 20-11-18 15:51:32, Oscar Salvador wrote:
> On Tue, 2018-11-20 at 14:43 +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > do_migrate_range has been limiting the number of pages to migrate to
> > 256
> > for some reason which is not documented.
>
> When looking back at old
Hi Charles,
On 2018-11-20 15:47, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
>> On 2018-05-17 18:41, Mark Brown wrote:
>>> Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
>> This patch causes following kernel warning on
Hi Charles,
On 2018-11-20 15:47, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
>> On 2018-05-17 18:41, Mark Brown wrote:
>>> Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
>> This patch causes following kernel warning on
Hi All,
This series was written in parallel with reading and understanding the
vchiq code. So excuse me for the lack of logic in the sequence of
patches.
The main focus was to delete as much code as possible, I've counted
around 550 lines, which is not bad. Apart from that there are some
patches
The resulting code is way more readeable and intuitive compared to plain
list_for_each.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 52 ++-
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git
Hi All,
This series was written in parallel with reading and understanding the
vchiq code. So excuse me for the lack of logic in the sequence of
patches.
The main focus was to delete as much code as possible, I've counted
around 550 lines, which is not bad. Apart from that there are some
patches
The resulting code is way more readeable and intuitive compared to plain
list_for_each.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 52 ++-
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git
On 20/11/2018 14:40, Pavel Tatashin wrote:
>>> +static __init void sched_clock_early_init(void)
>>> +{
>>> + u64 freq = arch_timer_get_cntfrq();
>>> + u64 (*read_time)(void) = arch_counter_get_cntvct;
>>
>> We already have arch_timer_read_counter which is exposed from
>> arm_arch_timer.h.
On 20/11/2018 14:40, Pavel Tatashin wrote:
>>> +static __init void sched_clock_early_init(void)
>>> +{
>>> + u64 freq = arch_timer_get_cntfrq();
>>> + u64 (*read_time)(void) = arch_counter_get_cntvct;
>>
>> We already have arch_timer_read_counter which is exposed from
>> arm_arch_timer.h.
On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote:
> On 20 November 2018 at 15:00, Sjoerd Simons
> wrote:
> > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote:
> > > + Hal Emmerich
> > >
> > > On 20 November 2018 at 12:38, Sjoerd Simons
> > > wrote:
> > > > On Tue, 2018-11-20 at 11:23
On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote:
> On 20 November 2018 at 15:00, Sjoerd Simons
> wrote:
> > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote:
> > > + Hal Emmerich
> > >
> > > On 20 November 2018 at 12:38, Sjoerd Simons
> > > wrote:
> > > > On Tue, 2018-11-20 at 11:23
The function is overly complicated for what it's ultimately achieving.
It's simply filling up a structure.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 12
.../interface/vchiq_arm/vchiq_core.c | 30 +--
The function is overly complicated for what it's ultimately achieving.
It's simply filling up a structure.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 12
.../interface/vchiq_arm/vchiq_core.c | 30 +--
The function is passed to vchiq_core.c for it to go trough all the
transfer elements (an array of pointers to data) and copy them into the
actual transfer memory (contiguous memory).
The logic in the function was "copy an element and return, except when
the element is empty, in which case look
The function is passed to vchiq_core.c for it to go trough all the
transfer elements (an array of pointers to data) and copy them into the
actual transfer memory (contiguous memory).
The logic in the function was "copy an element and return, except when
the element is empty, in which case look
vchiq_init_state() initialises a series of semaphores to then call
remote_event_create() on the same semaphores, which initializes them
again. We get rid of the second initialization.
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchiq_arm/vchiq_core.c| 11
vchiq_init_state() initialises a series of semaphores to then call
remote_event_create() on the same semaphores, which initializes them
again. We get rid of the second initialization.
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchiq_arm/vchiq_core.c| 11
VCHIQ bulk transfers are what most people call DMA transfers. The CPU
sends a list of physical addresses to the VideoCore which then access
the memory directly without the need for CPU interaction. With this
setup we call the CPU the "slave" and the VideoCore the "master".
There seems to be an
VCHIQ bulk transfers are what most people call DMA transfers. The CPU
sends a list of physical addresses to the VideoCore which then access
the memory directly without the need for CPU interaction. With this
setup we call the CPU the "slave" and the VideoCore the "master".
There seems to be an
The concept of VCHI_MEM_HANDLE_T is introduced by this header file and
was meant to be used with bulk transfers. After a quick look in
vchiq_core.c it is pretty clear that it actually accomplishes nothing
nor alters the bulk transfers in any way.
Signed-off-by: Nicolas Saenz Julienne
---
It's the first thing remote_event_signal() does.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_core.c| 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
The concept of VCHI_MEM_HANDLE_T is introduced by this header file and
was meant to be used with bulk transfers. After a quick look in
vchiq_core.c it is pretty clear that it actually accomplishes nothing
nor alters the bulk transfers in any way.
Signed-off-by: Nicolas Saenz Julienne
---
It's the first thing remote_event_signal() does.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_core.c| 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
---
Changes in v2:
-do that right after its last use to also cover
error handling.
---
drivers/watchdog/cpwd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c
index
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
---
Changes in v2:
-do that right after its last use to also cover
error handling.
---
drivers/watchdog/cpwd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c
index
We update sync to reflect that the firmware version is compatible with
that option. We don't need to check both of them again further down the
code.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_core.c| 4 +---
1 file changed, 1 insertion(+),
We update sync to reflect that the firmware version is compatible with
that option. We don't need to check both of them again further down the
code.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchiq_arm/vchiq_core.c| 4 +---
1 file changed, 1 insertion(+),
vchiq_init_state() checks the initial contents of slot_zero are correct.
These are set in vchiq_init_slots(), using the same hard-coded defaults
as the checks. Both functions are called sequentially and Video Core
isn't yet aware of the slot's address. There is no way the contents of
slot_zero
vchiq_init_state() checks the initial contents of slot_zero are correct.
These are set in vchiq_init_slots(), using the same hard-coded defaults
as the checks. Both functions are called sequentially and Video Core
isn't yet aware of the slot's address. There is no way the contents of
slot_zero
All the memory operations featured in this file modify/access memory
that is only accessed by the CPU. So we can assume that all the memory
barrier handling done by the completion routines is good enough for us.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_util.c
All the memory operations featured in this file modify/access memory
that is only accessed by the CPU. So we can assume that all the memory
barrier handling done by the completion routines is good enough for us.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_util.c
It is preferred in the kernel to avoid using semaphores to wait for
events, as they are optimised for the opposite situation; where the
common case is that they are available and may block only occasionally.
FYI see this thread: https://lkml.org/lkml/2008/4/11/323.
Also completions are
It is preferred in the kernel to avoid using semaphores to wait for
events, as they are optimised for the opposite situation; where the
common case is that they are available and may block only occasionally.
FYI see this thread: https://lkml.org/lkml/2008/4/11/323.
Also completions are
The TODO list was missing some tasks needed before upstreaming the
device.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchi/TODO | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchi/TODO
The TODO list was missing some tasks needed before upstreaming the
device.
Signed-off-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/interface/vchi/TODO | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchi/TODO
No one is using the API neither in the actual staging tree nor in the
downstream tree (https://github.com/raspberrypi/linux).
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchi/vchi.h | 5 ---
.../interface/vchiq_arm/vchiq_shim.c | 32 ---
Moves the allocation of a chardev region and class creation to the init
function of the driver since those functions are meant to be run on a
per driver basis, as opposed to the code run in the probe function which
is run in a per device basis.
Signed-off-by: Nicolas Saenz Julienne
---
No one is using the API neither in the actual staging tree nor in the
downstream tree (https://github.com/raspberrypi/linux).
Signed-off-by: Nicolas Saenz Julienne
---
.../vc04_services/interface/vchi/vchi.h | 5 ---
.../interface/vchiq_arm/vchiq_shim.c | 32 ---
Moves the allocation of a chardev region and class creation to the init
function of the driver since those functions are meant to be run on a
per driver basis, as opposed to the code run in the probe function which
is run in a per device basis.
Signed-off-by: Nicolas Saenz Julienne
---
The implementation of both IOCTLS was the same except for one function
call. This joins both implementations and updates the code to avoid
unneeded indentations.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 66 +++
1 file changed, 24
Both functions checked the minor number of the cdev prior running the
code. This was useless since the number of devices is already limited by
alloc_chrdev_region.
This removes the check and reindents the code where relevant.
Signed-off-by: Nicolas Saenz Julienne
---
The implementation of both IOCTLS was the same except for one function
call. This joins both implementations and updates the code to avoid
unneeded indentations.
Signed-off-by: Nicolas Saenz Julienne
---
.../interface/vchiq_arm/vchiq_arm.c | 66 +++
1 file changed, 24
Both functions checked the minor number of the cdev prior running the
code. This was useless since the number of devices is already limited by
alloc_chrdev_region.
This removes the check and reindents the code where relevant.
Signed-off-by: Nicolas Saenz Julienne
---
On Tue, Nov 20, 2018 at 09:40:10AM -0500, Pavel Tatashin wrote:
> > > +static __init void sched_clock_early_init(void)
> > > +{
> > > + u64 freq = arch_timer_get_cntfrq();
> > > + u64 (*read_time)(void) = arch_counter_get_cntvct;
> >
> > We already have arch_timer_read_counter which is
On Tue, Nov 20, 2018 at 09:40:10AM -0500, Pavel Tatashin wrote:
> > > +static __init void sched_clock_early_init(void)
> > > +{
> > > + u64 freq = arch_timer_get_cntfrq();
> > > + u64 (*read_time)(void) = arch_counter_get_cntvct;
> >
> > We already have arch_timer_read_counter which is
On Tue, 2018-11-20 at 14:43 +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> do_migrate_range has been limiting the number of pages to migrate to
> 256
> for some reason which is not documented.
When looking back at old memory-hotplug commits one feels pretty sad
about the brevity of the
On Tue, 2018-11-20 at 14:43 +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> do_migrate_range has been limiting the number of pages to migrate to
> 256
> for some reason which is not documented.
When looking back at old memory-hotplug commits one feels pretty sad
about the brevity of the
On Tue, Nov 20, 2018 at 1:32 PM Li, Aubrey wrote:
> Thanks for your program, Samuel, it's very helpful. But I saw a different
> output on my side, May I have your glibc version?
>
This system is running glibc 2.27, and kernel 4.18.7. The Xeon Gold
5120 also happens to be one of the Skylake-SP
On Tue, Nov 20, 2018 at 1:32 PM Li, Aubrey wrote:
> Thanks for your program, Samuel, it's very helpful. But I saw a different
> output on my side, May I have your glibc version?
>
This system is running glibc 2.27, and kernel 4.18.7. The Xeon Gold
5120 also happens to be one of the Skylake-SP
On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> On 2018-05-17 18:41, Mark Brown wrote:
> > Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
>
> This patch causes following kernel warning on Samsung Exynos4412 based
> Trats2 board:
>
> wm8994 4-001a:
On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> On 2018-05-17 18:41, Mark Brown wrote:
> > Subject: [PATCH] regulator: wm8994: Pass descriptor instead of GPIO number
>
> This patch causes following kernel warning on Samsung Exynos4412 based
> Trats2 board:
>
> wm8994 4-001a:
On Tue, Nov 20, 2018 at 10:34 PM Guenter Roeck wrote:
>
> On 11/20/18 5:23 AM, Yangtao Li wrote:
> > use of_node_put() to release the refcount.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/watchdog/cpwd.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
On Tue, Nov 20, 2018 at 10:34 PM Guenter Roeck wrote:
>
> On 11/20/18 5:23 AM, Yangtao Li wrote:
> > use of_node_put() to release the refcount.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/watchdog/cpwd.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed,
Allow printk time stamps/sched_clock() to be available from the early
boot.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/setup.c| 25 +
drivers/clocksource/arm_arch_timer.c | 8
include/clocksource/arm_arch_timer.h | 3 +++
3 files changed,
Changelog:
v1 - v2
Addressed comments from Marc Zyngier
I made early boot time stamps available for SPARC and X86.
x86:
https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com
sparc:
https://www.spinics.net/lists/sparclinux/msg18063.html
As discussed at plumbers,
Changelog:
v1 - v2
Addressed comments from Marc Zyngier
I made early boot time stamps available for SPARC and X86.
x86:
https://lore.kernel.org/lkml/20180719205545.16512-1-pasha.tatas...@oracle.com
sparc:
https://www.spinics.net/lists/sparclinux/msg18063.html
As discussed at plumbers,
> > +static __init void sched_clock_early_init(void)
> > +{
> > + u64 freq = arch_timer_get_cntfrq();
> > + u64 (*read_time)(void) = arch_counter_get_cntvct;
>
> We already have arch_timer_read_counter which is exposed from
> arm_arch_timer.h.
OK
>
> > +
> > + /* Early clock is
> > +static __init void sched_clock_early_init(void)
> > +{
> > + u64 freq = arch_timer_get_cntfrq();
> > + u64 (*read_time)(void) = arch_counter_get_cntvct;
>
> We already have arch_timer_read_counter which is exposed from
> arm_arch_timer.h.
OK
>
> > +
> > + /* Early clock is
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Define the length of the DBI registers. This makes sure that
> the kernel does not access registers beyond that point, avoiding
> the following abort on a i.MX 6Quad:
> # cat
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Define the length of the DBI registers. This makes sure that
> the kernel does not access registers beyond that point, avoiding
> the following abort on a i.MX 6Quad:
> # cat
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Introduce driver data struct. This will simplify handling of device
> specific differences.
>
> Signed-off-by: Stefan Agner
Reviewed-by: Lucas Stach
> ---
> Changes in v2:
> - Split drvdata introduction in a separate patch
> -
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Add length to the struct dw_pcie and check that the accessors
> dw_pcie_(rd|wr)_own_conf() do not read/write beyond that point.
>
> Signed-off-by: Stefan Agner
FWIW:
Reviewed-by: Lucas Stach
> ---
>
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Introduce driver data struct. This will simplify handling of device
> specific differences.
>
> Signed-off-by: Stefan Agner
Reviewed-by: Lucas Stach
> ---
> Changes in v2:
> - Split drvdata introduction in a separate patch
> -
Am Dienstag, den 20.11.2018, 14:27 +0100 schrieb Stefan Agner:
> Add length to the struct dw_pcie and check that the accessors
> dw_pcie_(rd|wr)_own_conf() do not read/write beyond that point.
>
> Signed-off-by: Stefan Agner
FWIW:
Reviewed-by: Lucas Stach
> ---
>
On 20.11.18 15:34, Michal Hocko wrote:
> On Tue 20-11-18 15:26:43, David Hildenbrand wrote:
> [...]
>>> + do {
>>> + for (pfn = start_pfn; pfn;)
>>> + {
>>
>> { on a new line looks weird.
>>
>>> + /* start memory hot removal */
>>> + ret =
On 20.11.18 15:34, Michal Hocko wrote:
> On Tue 20-11-18 15:26:43, David Hildenbrand wrote:
> [...]
>>> + do {
>>> + for (pfn = start_pfn; pfn;)
>>> + {
>>
>> { on a new line looks weird.
>>
>>> + /* start memory hot removal */
>>> + ret =
On 11/20/18 5:23 AM, Yangtao Li wrote:
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
---
drivers/watchdog/cpwd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c
index aee0b25cf10d..d3a81642ada5 100644
---
The hub sends hot-plug events to the host trough it's interrupt URB. The
driver takes care of completing the URB and re-submitting it. Completion
errors are handled in the hub_event() work, yet submission errors are
ignored, rendering the device unresponsive. All further events are lost.
It is
On 11/20/18 5:23 AM, Yangtao Li wrote:
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
---
drivers/watchdog/cpwd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/watchdog/cpwd.c b/drivers/watchdog/cpwd.c
index aee0b25cf10d..d3a81642ada5 100644
---
The hub sends hot-plug events to the host trough it's interrupt URB. The
driver takes care of completing the URB and re-submitting it. Completion
errors are handled in the hub_event() work, yet submission errors are
ignored, rendering the device unresponsive. All further events are lost.
It is
901 - 1000 of 1736 matches
Mail list logo
