This patch introduces a new interface to allow irq domain
initialization regardless of order dependencies. This is done by
requesting a domain and registering a callback function that is called
as soon as a domain becomes available.
A typical irq domain initialization code is the following:
Use new irq_domain_request_host_*() interface which allows independent
parent and child initialization using an irq domain request handler.
This makes it possible to move its initialization to a later point
during boot. All domains can be initialized in the same initcall level
then.
The PDC map should use the GIC SPI port and not the vector. GIC
internally adds 32 to SPI hwirq numbers.
Fixes: 1ae8862e27e ("dt-bindings/interrupt-controller: pdc: Describe PDC device
binding")
Reviewed-by: Rob Herring
Signed-off-by: Lina Iyer
---
The PDC map should use the GIC SPI port and not the vector. GIC
internally adds 32 to SPI hwirq numbers.
Fixes: 1ae8862e27e ("dt-bindings/interrupt-controller: pdc: Describe PDC device
binding")
Reviewed-by: Rob Herring
Signed-off-by: Lina Iyer
---
On Wed, Nov 7, 2018 at 9:39 PM Marc Gonzalez wrote:
>
> Arnd, Olof,
>
> The following patch series was sent to a...@kernel.org
> but the messages bounced because the SMTP server is
> currently blacklisted. Can you get the patches through
> the LAKML mailing list?
Yes, that worked fine, and they
Add PDC interrupt controller device bindings for SDM845.
Signed-off-by: Lina Iyer
---
Changes in v3:
- Fix PDC map, use GIC SPI port number for hwirq
Changes in v2:
- Order by address
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
1 file changed, 9 insertions(+)
diff
On Wed, Nov 7, 2018 at 9:39 PM Marc Gonzalez wrote:
>
> Arnd, Olof,
>
> The following patch series was sent to a...@kernel.org
> but the messages bounced because the SMTP server is
> currently blacklisted. Can you get the patches through
> the LAKML mailing list?
Yes, that worked fine, and they
Add PDC interrupt controller device bindings for SDM845.
Signed-off-by: Lina Iyer
---
Changes in v3:
- Fix PDC map, use GIC SPI port number for hwirq
Changes in v2:
- Order by address
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
1 file changed, 9 insertions(+)
diff
On November 7, 2018 1:43:39 PM PST, Logan Gunthorpe wrote:
>
>
>On 2018-11-07 11:56 a.m., Nadav Amit wrote:
>> HPA indicated more than once that this is wrong (and that was indeed
>my
>> initial solution), since it is not guaranteed that the compiler would
>put
>> the macro assembly before its
On November 7, 2018 1:43:39 PM PST, Logan Gunthorpe wrote:
>
>
>On 2018-11-07 11:56 a.m., Nadav Amit wrote:
>> HPA indicated more than once that this is wrong (and that was indeed
>my
>> initial solution), since it is not guaranteed that the compiler would
>put
>> the macro assembly before its
Because find_symbol_by_name() traverses the same lists as read_symbols()
changing sym->name in place without copying it affects the result of
find_symbol_by_name() and, in case when ".cold" function precedes it's
parent in sec->symbol_list, can result in function being considered a
parent of
Because find_symbol_by_name() traverses the same lists as read_symbols()
changing sym->name in place without copying it affects the result of
find_symbol_by_name() and, in case when ".cold" function precedes it's
parent in sec->symbol_list, can result in function being considered a
parent of
On Wed, Nov 7, 2018 at 9:55 PM Andrew Morton wrote:
>
> On Wed, 7 Nov 2018 17:45:16 +0300 Andrey Ryabinin
> wrote:
>
> > From: Arnd Bergmann
> > --- a/lib/ubsan.c
> > +++ b/lib/ubsan.c
> > @@ -427,8 +427,7 @@ void __ubsan_handle_shift_out_of_bounds(struct
> > shift_out_of_bounds_data *data,
On Wed, Nov 7, 2018 at 9:55 PM Andrew Morton wrote:
>
> On Wed, 7 Nov 2018 17:45:16 +0300 Andrey Ryabinin
> wrote:
>
> > From: Arnd Bergmann
> > --- a/lib/ubsan.c
> > +++ b/lib/ubsan.c
> > @@ -427,8 +427,7 @@ void __ubsan_handle_shift_out_of_bounds(struct
> > shift_out_of_bounds_data *data,
On 2018-11-07 11:56 a.m., Nadav Amit wrote:
> HPA indicated more than once that this is wrong (and that was indeed my
> initial solution), since it is not guaranteed that the compiler would put
> the macro assembly before its use.
Hmm, that's very unfortunate. I don't really understand why the
On 2018-11-07 11:56 a.m., Nadav Amit wrote:
> HPA indicated more than once that this is wrong (and that was indeed my
> initial solution), since it is not guaranteed that the compiler would put
> the macro assembly before its use.
Hmm, that's very unfortunate. I don't really understand why the
On Wed, Nov 07, 2018 at 04:27:58PM -0500, Rich Felker wrote:
> On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote:
> > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote:
> > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote:
> > > > On Tue, Nov 6, 2018 at
On Wed, Nov 07, 2018 at 04:27:58PM -0500, Rich Felker wrote:
> On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote:
> > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote:
> > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote:
> > > > On Tue, Nov 6, 2018 at
On 11/7/18 4:03 AM, Jiri Slaby wrote:
> On 05. 11. 18, 2:45, Dusty Mabe wrote:
>> If a patch were submitted to enable this type of behavior would such a
>> patch be acceptable? Maybe it could be a compile time option and also
>> have a kernel arg option to enable/disable it.
>
> Hi,
>
> it
On 11/7/18 4:03 AM, Jiri Slaby wrote:
> On 05. 11. 18, 2:45, Dusty Mabe wrote:
>> If a patch were submitted to enable this type of behavior would such a
>> patch be acceptable? Maybe it could be a compile time option and also
>> have a kernel arg option to enable/disable it.
>
> Hi,
>
> it
On Wed, Nov 7, 2018 at 1:28 PM Rich Felker wrote:
>
> On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote:
> > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote:
> > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote:
> > > > On Tue, Nov 6, 2018 at 10:41
On Wed, Nov 7, 2018 at 1:28 PM Rich Felker wrote:
>
> On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote:
> > On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote:
> > > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote:
> > > > On Tue, Nov 6, 2018 at 10:41
Hi Arun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc1 next-20181107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Arun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc1 next-20181107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
While playing with initialization order of modem device, it has been
discovered that under some circumstances (early console init, I
believe) its .pm() callback may be called before the
uart_port->private_data pointer is initialized from
plat_serial8250_port->private_data, resulting in NULL
While playing with initialization order of modem device, it has been
discovered that under some circumstances (early console init, I
believe) its .pm() callback may be called before the
uart_port->private_data pointer is initialized from
plat_serial8250_port->private_data, resulting in NULL
On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote:
> On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote:
> > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote:
> > > On Tue, Nov 6, 2018 at 10:41 AM Dave Hansen wrote:
> > > >
> > > > On 11/6/18 10:20 AM,
On Tue, Nov 06, 2018 at 03:26:16PM -0800, Sean Christopherson wrote:
> On Tue, Nov 06, 2018 at 06:17:30PM -0500, Rich Felker wrote:
> > On Tue, Nov 06, 2018 at 11:02:11AM -0800, Andy Lutomirski wrote:
> > > On Tue, Nov 6, 2018 at 10:41 AM Dave Hansen wrote:
> > > >
> > > > On 11/6/18 10:20 AM,
Commit-ID: 08e823c2c5899ef2de3aa1727233f1f19e8c1cc1
Gitweb: https://git.kernel.org/tip/08e823c2c5899ef2de3aa1727233f1f19e8c1cc1
Author: Janakarajan Natarajan
AuthorDate: Wed, 7 Nov 2018 20:59:07 +
Committer: Borislav Petkov
CommitDate: Wed, 7 Nov 2018 22:21:03 +0100
Commit-ID: 08e823c2c5899ef2de3aa1727233f1f19e8c1cc1
Gitweb: https://git.kernel.org/tip/08e823c2c5899ef2de3aa1727233f1f19e8c1cc1
Author: Janakarajan Natarajan
AuthorDate: Wed, 7 Nov 2018 20:59:07 +
Committer: Borislav Petkov
CommitDate: Wed, 7 Nov 2018 22:21:03 +0100
On Wed, 7 Nov 2018 13:18:19 -0800, Doug Anderson wrote:
> From reading the thread it sounds like Guenter was not even super
> happy with that based on the principal that you wouldn't expect a
> kernel build to be doing write operations in your .git directory even
> if $objtree == $srctree
I see,
On Wed, 2018-11-07 at 11:34 -0800, Dan Williams wrote:
> On Wed, Nov 7, 2018 at 10:52 AM Toshi Kani wrote:
> >
> > ndctl zero-labels completes with a large number of zeroed nmems when
> > it fails to do zeroing on a protected NVDIMM.
> >
> > # ndctl zero-labels nmem1
> > zeroed 65504 nmems
On Wed, 7 Nov 2018 13:18:19 -0800, Doug Anderson wrote:
> From reading the thread it sounds like Guenter was not even super
> happy with that based on the principal that you wouldn't expect a
> kernel build to be doing write operations in your .git directory even
> if $objtree == $srctree
I see,
On Wed, 2018-11-07 at 11:34 -0800, Dan Williams wrote:
> On Wed, Nov 7, 2018 at 10:52 AM Toshi Kani wrote:
> >
> > ndctl zero-labels completes with a large number of zeroed nmems when
> > it fails to do zeroing on a protected NVDIMM.
> >
> > # ndctl zero-labels nmem1
> > zeroed 65504 nmems
On Wed, Nov 7, 2018 at 9:07 AM Sascha Hauer wrote:
>
> On Mon, Nov 05, 2018 at 09:25:40AM +0100, Geert Uytterhoeven wrote:
> > Instead of adding yet another dependency on UBIFS_FS, wrap the whole
> > block of ubifs config options in a single "if UBIFS_FS".
> >
> > Fixes: d8a22773a12c6d78 ("ubifs:
On Wed, Nov 7, 2018 at 9:07 AM Sascha Hauer wrote:
>
> On Mon, Nov 05, 2018 at 09:25:40AM +0100, Geert Uytterhoeven wrote:
> > Instead of adding yet another dependency on UBIFS_FS, wrap the whole
> > block of ubifs config options in a single "if UBIFS_FS".
> >
> > Fixes: d8a22773a12c6d78 ("ubifs:
On Wed, Nov 07, 2018 at 11:35:54AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 06, 2018 at 12:34:11PM -0800, Daniel Jordan wrote:
> > On Tue, Nov 06, 2018 at 09:49:11AM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 05, 2018 at 11:55:46AM -0500, Daniel Jordan wrote:
> > > > +Concept
> > > >
On Wed, Nov 07, 2018 at 11:35:54AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 06, 2018 at 12:34:11PM -0800, Daniel Jordan wrote:
> > On Tue, Nov 06, 2018 at 09:49:11AM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 05, 2018 at 11:55:46AM -0500, Daniel Jordan wrote:
> > > > +Concept
> > > >
Hi,
On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
>
> On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> > I do not think it is a good idea to create a random file in the .git
> > directory
> > under any circumstance, and much less so if an output directory was
> > specified,
> > no
Hi,
On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote:
>
> On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> > I do not think it is a good idea to create a random file in the .git
> > directory
> > under any circumstance, and much less so if an output directory was
> > specified,
> > no
On Wed, Nov 7, 2018 at 7:30 PM David Abdurachmanov
wrote:
> On Wed, Nov 7, 2018 at 1:08 AM Palmer Dabbelt wrote:
> > On Mon, 05 Nov 2018 12:56:15 PST (-0800), Arnd Bergmann wrote:
> > The target is still the next glibc release (Feb 1st) for a stable RV32I ABI.
> > That's progressing well, with
On Wed, Nov 7, 2018 at 7:30 PM David Abdurachmanov
wrote:
> On Wed, Nov 7, 2018 at 1:08 AM Palmer Dabbelt wrote:
> > On Mon, 05 Nov 2018 12:56:15 PST (-0800), Arnd Bergmann wrote:
> > The target is still the next glibc release (Feb 1st) for a stable RV32I ABI.
> > That's progressing well, with
On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> I do not think it is a good idea to create a random file in the .git directory
> under any circumstance, and much less so if an output directory was specified,
> no matter if the path is read-only or not. I also still think that it is a
>
On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote:
> I do not think it is a good idea to create a random file in the .git directory
> under any circumstance, and much less so if an output directory was specified,
> no matter if the path is read-only or not. I also still think that it is a
>
On 10:10-20181005, Vutla, Lokesh wrote:
>
>
> On Thursday 27 September 2018 10:31 AM, Vignesh R wrote:
> > cbass_wakeup interconnect which is the parent of wakeup_uart node
> > defines address-cells=1 and size-cells=1, therefore fix up reg property
> > of wakeup_uart node accordingly. Otherwise,
On 10:10-20181005, Vutla, Lokesh wrote:
>
>
> On Thursday 27 September 2018 10:31 AM, Vignesh R wrote:
> > cbass_wakeup interconnect which is the parent of wakeup_uart node
> > defines address-cells=1 and size-cells=1, therefore fix up reg property
> > of wakeup_uart node accordingly. Otherwise,
Add a new cpufeature definition for the WBNOINVD instruction.
The WBNOINVD instruction writes all modified line in all levels of
cache associated with a processor to main memory while retaining the
cached values.
Both AMD and Intel support this instruction.
Signed-off-by: Janakarajan Natarajan
Add a new cpufeature definition for the WBNOINVD instruction.
The WBNOINVD instruction writes all modified line in all levels of
cache associated with a processor to main memory while retaining the
cached values.
Both AMD and Intel support this instruction.
Signed-off-by: Janakarajan Natarajan
[ Add interested parties ]
On 07/11/2018 21:15, Marc Gonzalez wrote:
> Commit a930d8bd94d8 ("usb: chipidea: Always build ULPI code")
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/configs/defconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/configs/defconfig
[ Add interested parties ]
On 07/11/2018 21:15, Marc Gonzalez wrote:
> Commit a930d8bd94d8 ("usb: chipidea: Always build ULPI code")
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/configs/defconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/configs/defconfig
On 11/7/18 11:01 AM, Sean Christopherson wrote:
> Going off comments in similar code related to UMIP, we'd need to figure
> out how to handle protection keys.
There are two options:
1. Don't depend on the userspace mapping. Do get_user_pages() to find
the instruction in the kernel direct map,
On 11/7/18 11:01 AM, Sean Christopherson wrote:
> Going off comments in similar code related to UMIP, we'd need to figure
> out how to handle protection keys.
There are two options:
1. Don't depend on the userspace mapping. Do get_user_pages() to find
the instruction in the kernel direct map,
On Wed, 7 Nov 2018, Andrew Morton wrote:
> On Wed, 7 Nov 2018 13:36:34 -0700 Logan Gunthorpe wrote:
>
> > > Actually if both names suck, then there also is the option to rename both
> > > instead of adding a comment to explain the suckage.
> >
> > Ok, well, I wasn't expecting to take on a big
On Wed, 7 Nov 2018, Andrew Morton wrote:
> On Wed, 7 Nov 2018 13:36:34 -0700 Logan Gunthorpe wrote:
>
> > > Actually if both names suck, then there also is the option to rename both
> > > instead of adding a comment to explain the suckage.
> >
> > Ok, well, I wasn't expecting to take on a big
On Wed, Nov 7, 2018 at 11:45 AM Rob Herring wrote:
>
> On Tue, Nov 6, 2018 at 4:17 PM Olof Johansson wrote:
> >
> > Hi KS organizers (and others),
> >
> > This is a late topic proposal, hopefully there is still time on the agenda.
> >
> > We’ve recently been discussing some maintainer model
On Wed, Nov 7, 2018 at 11:45 AM Rob Herring wrote:
>
> On Tue, Nov 6, 2018 at 4:17 PM Olof Johansson wrote:
> >
> > Hi KS organizers (and others),
> >
> > This is a late topic proposal, hopefully there is still time on the agenda.
> >
> > We’ve recently been discussing some maintainer model
On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
> wrote:
> > On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > > On a different tangent: how about the --no-optional-locks (see
> > > git(1))? Will this get you your
On Wed, 7 Nov 2018 17:45:16 +0300 Andrey Ryabinin
wrote:
> From: Arnd Bergmann
>
> gcc-8 complains about the prototype for this function:
>
> lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a
> built-in function '__ubsan_handle_builtin_unreachable' because it
Presently the arches arm64, arm and sh have a function which loops through
each memblock and calls memory present. riscv will require a similar
function.
Introduce a common memblocks_present() function that can be used by
all the arches. Subsequent patches will cleanup the arches that
make use of
On Wed, Nov 07, 2018 at 12:43:58PM -0800, Genki Sky wrote:
> On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
> wrote:
> > On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > > On a different tangent: how about the --no-optional-locks (see
> > > git(1))? Will this get you your
On Wed, 7 Nov 2018 17:45:16 +0300 Andrey Ryabinin
wrote:
> From: Arnd Bergmann
>
> gcc-8 complains about the prototype for this function:
>
> lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a
> built-in function '__ubsan_handle_builtin_unreachable' because it
Presently the arches arm64, arm and sh have a function which loops through
each memblock and calls memory present. riscv will require a similar
function.
Introduce a common memblocks_present() function that can be used by
all the arches. Subsequent patches will cleanup the arches that
make use of
These are the first two common patches in my series to introduce
sparsemem support to RISC-V. The full series was posted last cycle
here [1] and the latest version can be found here [2].
As recommended by Palmer, I'd like to get the changes to common code
merged and then I will pursue the
These are the first two common patches in my series to introduce
sparsemem support to RISC-V. The full series was posted last cycle
here [1] and the latest version can be found here [2].
As recommended by Palmer, I'd like to get the changes to common code
merged and then I will pursue the
[ Add interested parties ]
On 07/11/2018 21:14, Marc Gonzalez wrote:
> Commit a7314405d83c ("drop ARM_BIG_LITTLE_CPUFREQ support for ARM64")
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/configs/defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
This define is used by arm64 to calculate the size of the vmemmap
region. It is defined as the log2 of the upper bound on the size
of a struct page.
We move it into mm_types.h so it can be defined properly instead of
set and checked with a build bug. This also allows us to use the same
define for
[ Add interested parties ]
On 07/11/2018 21:14, Marc Gonzalez wrote:
> Commit a7314405d83c ("drop ARM_BIG_LITTLE_CPUFREQ support for ARM64")
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/configs/defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
This define is used by arm64 to calculate the size of the vmemmap
region. It is defined as the log2 of the upper bound on the size
of a struct page.
We move it into mm_types.h so it can be defined properly instead of
set and checked with a build bug. This also allows us to use the same
define for
[ Add interested parties ]
On 07/11/2018 21:16, Marc Gonzalez wrote:
> Commit e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that implements
> the generic pinctrl dt-bindings")
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/configs/defconfig | 2 +-
> 1 file changed, 1 insertion(+),
[ Add interested parties ]
On 07/11/2018 21:16, Marc Gonzalez wrote:
> Commit e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that implements
> the generic pinctrl dt-bindings")
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/configs/defconfig | 2 +-
> 1 file changed, 1 insertion(+),
Dan,
On Wed, 7 Nov 2018, Dan Williams wrote:
> On Wed, Nov 7, 2018 at 11:49 AM Jonathan Corbet wrote:
> > The stuff that is truly specific to tip seems fairly minimal:
> >
> > - what goes into tip
> > - the reverse fir tree thing
> > - tail comments, or the distaste thereabouts
> > -
Hi Baolin,
Thanks for the review. Will address the remarks in a v2.
On 11/07/2018 07:55 AM, Baolin Wang wrote:
> Hi Jacek,
>
> On 7 November 2018 at 06:07, Jacek Anaszewski
[...]
>
> It can work well for SC27XX LED, FWIW you can add my tested tag.
> Tested-by: Baolin Wang
>
--
Best
Dan,
On Wed, 7 Nov 2018, Dan Williams wrote:
> On Wed, Nov 7, 2018 at 11:49 AM Jonathan Corbet wrote:
> > The stuff that is truly specific to tip seems fairly minimal:
> >
> > - what goes into tip
> > - the reverse fir tree thing
> > - tail comments, or the distaste thereabouts
> > -
Hi Baolin,
Thanks for the review. Will address the remarks in a v2.
On 11/07/2018 07:55 AM, Baolin Wang wrote:
> Hi Jacek,
>
> On 7 November 2018 at 06:07, Jacek Anaszewski
[...]
>
> It can work well for SC27XX LED, FWIW you can add my tested tag.
> Tested-by: Baolin Wang
>
--
Best
[ Add interested parties ]
On 07/11/2018 21:18, Marc Gonzalez wrote:
> Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
> enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
> which is not set.
>
> Signed-off-by: Marc Gonzalez
> ---
>
[ Add interested parties ]
On 07/11/2018 21:18, Marc Gonzalez wrote:
> Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
> enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
> which is not set.
>
> Signed-off-by: Marc Gonzalez
> ---
>
Hi Geert,
On 11/07/2018 02:45 PM, Geert Uytterhoeven wrote:
> - Spelling s/brigntess/brightness/,
> - Double "use".
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documentation/ABI/testing/sysfs-class-led-trigger-pattern | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
Hi Geert,
On 11/07/2018 02:45 PM, Geert Uytterhoeven wrote:
> - Spelling s/brigntess/brightness/,
> - Double "use".
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documentation/ABI/testing/sysfs-class-led-trigger-pattern | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
Hi Baolin and Geert,
Geert - thanks for the heads-up.
Baolin - thanks for the quick fix.
Applied to the fixes-for-4.20-rc2 branch of linux-leds.git
Best regards,
Jacek Anaszewski
On 11/07/2018 08:59 AM, Geert Uytterhoeven wrote:
> Hi Baolin,
>
> On Wed, Nov 7, 2018 at 6:43 AM Baolin Wang
Hi Baolin and Geert,
Geert - thanks for the heads-up.
Baolin - thanks for the quick fix.
Applied to the fixes-for-4.20-rc2 branch of linux-leds.git
Best regards,
Jacek Anaszewski
On 11/07/2018 08:59 AM, Geert Uytterhoeven wrote:
> Hi Baolin,
>
> On Wed, Nov 7, 2018 at 6:43 AM Baolin Wang
> On Nov 6, 2018, at 7:27 PM, Elvira Khabirova wrote:
>
> PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> the tracee is blocked in. The request returns meaningful data only
> when the tracee is in a syscall-enter-stop or a syscall-exit-stop.
>
> There are two reasons for a
> On Nov 6, 2018, at 7:27 PM, Elvira Khabirova wrote:
>
> PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> the tracee is blocked in. The request returns meaningful data only
> when the tracee is in a syscall-enter-stop or a syscall-exit-stop.
>
> There are two reasons for a
Since in nbu2ss_drv_probe() p_regs is assigned from mmio_base, which is
marked as __iomem, p_regs also should be market with __iomem.
Signed-off-by: Carmeli Tamir
---
drivers/staging/emxx_udc/emxx_udc.c | 44 ++---
drivers/staging/emxx_udc/emxx_udc.h | 2 +-
2
Fixed sparse tool warnings due to missing convesion from
le16 to cpu endienness.
Signed-off-by: Carmeli Tamir
---
drivers/staging/emxx_udc/emxx_udc.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
Since in nbu2ss_drv_probe() p_regs is assigned from mmio_base, which is
marked as __iomem, p_regs also should be market with __iomem.
Signed-off-by: Carmeli Tamir
---
drivers/staging/emxx_udc/emxx_udc.c | 44 ++---
drivers/staging/emxx_udc/emxx_udc.h | 2 +-
2
Fixed sparse tool warnings due to missing convesion from
le16 to cpu endienness.
Signed-off-by: Carmeli Tamir
---
drivers/staging/emxx_udc/emxx_udc.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
This series fixes all meaningful sparse (running make C=2... ) warnings.
The number of warnings is reduced from ~280 to 12 (only warnings of type
'expression using sizeof(void)' are left). Resent the series to Greg's request.
Carmeli Tamir (3):
staging: emxx_udc: Added static modifier to
Added static modifier to the udc_controller, since it's only
required within emxx_udc.c.
Signed-off-by: Carmeli Tamir
---
drivers/staging/emxx_udc/emxx_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
This series fixes all meaningful sparse (running make C=2... ) warnings.
The number of warnings is reduced from ~280 to 12 (only warnings of type
'expression using sizeof(void)' are left). Resent the series to Greg's request.
Carmeli Tamir (3):
staging: emxx_udc: Added static modifier to
Added static modifier to the udc_controller, since it's only
required within emxx_udc.c.
Signed-off-by: Carmeli Tamir
---
drivers/staging/emxx_udc/emxx_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
wrote:
> On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > On a different tangent: how about the --no-optional-locks (see
> > git(1))? Will this get you your "up-to-date" result without writing to
> > the .git directory? I've only
On Wed, 7 Nov 2018 10:44:37 -0800, Brian Norris
wrote:
> On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote:
> > On a different tangent: how about the --no-optional-locks (see
> > git(1))? Will this get you your "up-to-date" result without writing to
> > the .git directory? I've only
From: Colin Ian King
Currently max_read_ds is being updated twice, which is incorrect.
The second assignment should be to max_write_ds instead. Fix this.
Detected by CoverityScan, CID#1475379 ("Unused value")
Fixes: 50cacdabeae1 ("i3c: Add core I3C infrastructure")
Signed-off-by: Colin Ian
From: Colin Ian King
Currently max_read_ds is being updated twice, which is incorrect.
The second assignment should be to max_write_ds instead. Fix this.
Detected by CoverityScan, CID#1475379 ("Unused value")
Fixes: 50cacdabeae1 ("i3c: Add core I3C infrastructure")
Signed-off-by: Colin Ian
Arnd, Olof,
The following patch series was sent to a...@kernel.org
but the messages bounced because the SMTP server is
currently blacklisted. Can you get the patches through
the LAKML mailing list?
Regards.
On 07/11/2018 21:12, Marc Gonzalez wrote:
> Hello ARM maintainers,
>
> The set of
Arnd, Olof,
The following patch series was sent to a...@kernel.org
but the messages bounced because the SMTP server is
currently blacklisted. Can you get the patches through
the LAKML mailing list?
Regards.
On 07/11/2018 21:12, Marc Gonzalez wrote:
> Hello ARM maintainers,
>
> The set of
On Wed, 7 Nov 2018 13:36:34 -0700 Logan Gunthorpe wrote:
> > Actually if both names suck, then there also is the option to rename both
> > instead of adding a comment to explain the suckage.
>
> Ok, well, I wasn't expecting to take on a big rename like that as it
> would create a patch touching
On Wed, 7 Nov 2018 13:36:34 -0700 Logan Gunthorpe wrote:
> > Actually if both names suck, then there also is the option to rename both
> > instead of adding a comment to explain the suckage.
>
> Ok, well, I wasn't expecting to take on a big rename like that as it
> would create a patch touching
On 2018-11-07 1:26 p.m., Thomas Gleixner wrote:
> Logan,
>
> On Wed, 7 Nov 2018, Logan Gunthorpe wrote:
>> On 2018-11-07 1:12 p.m., Andrew Morton wrote:
+void __init memblocks_present(void)
+{
+ struct memblock_region *reg;
+
+ for_each_memblock(memory, reg) {
+
On 2018-11-07 1:26 p.m., Thomas Gleixner wrote:
> Logan,
>
> On Wed, 7 Nov 2018, Logan Gunthorpe wrote:
>> On 2018-11-07 1:12 p.m., Andrew Morton wrote:
+void __init memblocks_present(void)
+{
+ struct memblock_region *reg;
+
+ for_each_memblock(memory, reg) {
+
401 - 500 of 1460 matches
Mail list logo
