Add device tree entries for timer, ARM CCI-400 and its PMU.
Otherwise, we add a cortex-a53-pmu node to enable hw perfevents.
Signed-off-by: Ryder Lee
---
change since v1:
- add a pmu node.
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 55
1 file changed, 55
Add device tree entries for timer, ARM CCI-400 and its PMU.
Otherwise, we add a cortex-a53-pmu node to enable hw perfevents.
Signed-off-by: Ryder Lee
---
change since v1:
- add a pmu node.
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 55
1 file changed, 55
On Sat, Aug 18, 2018 at 05:57:58PM +0200, Greg KH wrote:
> The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
>
> Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
>
> are available in the Git repository at:
>
>
On Sat, Aug 18, 2018 at 05:57:58PM +0200, Greg KH wrote:
> The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
>
> Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
>
> are available in the Git repository at:
>
>
The following changes since commit 9d3cce1e8b8561fed5f383d22a4d6949db4eadbe:
Linux 4.18-rc5 (2018-07-15 12:49:31 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
tags/char-misc-4.19-rc1
for you to fetch changes up to
The following changes since commit 9d3cce1e8b8561fed5f383d22a4d6949db4eadbe:
Linux 4.18-rc5 (2018-07-15 12:49:31 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
tags/char-misc-4.19-rc1
for you to fetch changes up to
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-4.19-rc1
for you to fetch changes up to
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-4.19-rc1
for you to fetch changes up to
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
tags/driver-core-4.19-rc1
for you to fetch changes up to
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
tags/driver-core-4.19-rc1
for you to fetch changes up to
The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:
Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.19-rc1
for you to fetch changes up to
The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:
Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.19-rc1
for you to fetch changes up to
On 08/18/2018 09:16 AM, zhong jiang wrote:
> We should use NULL to compare with pointer-typed value rather than
> 0. The issue is detected with the help of Coccinelle.
Your description stopped to match the patch in v2.
Actually, this X == NULL to !x preference is largely spocific to
On 08/18/2018 09:16 AM, zhong jiang wrote:
> We should use NULL to compare with pointer-typed value rather than
> 0. The issue is detected with the help of Coccinelle.
Your description stopped to match the patch in v2.
Actually, this X == NULL to !x preference is largely spocific to
Hi Gutavo,
Sorry for the delay.
On Wed, Aug 15, 2018 at 12:50:10PM -0500, Gustavo A. R. Silva wrote:
> Hi Marcus,
>
> On 8/15/18 12:27 PM, Marcus Folkesson wrote:
> > Hi,
> >
> > On Wed, Aug 15, 2018 at 11:38:52AM -0500, Gustavo A. R. Silva wrote:
> >> In preparation to enabling
Hi Gutavo,
Sorry for the delay.
On Wed, Aug 15, 2018 at 12:50:10PM -0500, Gustavo A. R. Silva wrote:
> Hi Marcus,
>
> On 8/15/18 12:27 PM, Marcus Folkesson wrote:
> > Hi,
> >
> > On Wed, Aug 15, 2018 at 11:38:52AM -0500, Gustavo A. R. Silva wrote:
> >> In preparation to enabling
On Thu, Aug 16, 2018 at 08:41:47PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.149 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:47PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.149 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Sat, Aug 18, 2018 at 11:21:07AM -0300, Rafael David Tinoco wrote:
> On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.2 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this
On Sat, Aug 18, 2018 at 11:21:07AM -0300, Rafael David Tinoco wrote:
> On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.2 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this
On Thu, Aug 16, 2018 at 08:41:53PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.121 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:53PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.121 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Sat, 2018-08-18 at 20:28 +0530, Bhaskar Singh wrote:
> On Sat, Aug 18, 2018 at 10:33:31PM +0800, zhong jiang wrote:
> > On 2018/8/18 22:24, Bhaskar Singh wrote:
> > > This patch might suppress some warrning.
> > >
> > > The function prototype of rtw_malloc2d is
> > >
> > > void
On Sat, 2018-08-18 at 20:28 +0530, Bhaskar Singh wrote:
> On Sat, Aug 18, 2018 at 10:33:31PM +0800, zhong jiang wrote:
> > On 2018/8/18 22:24, Bhaskar Singh wrote:
> > > This patch might suppress some warrning.
> > >
> > > The function prototype of rtw_malloc2d is
> > >
> > > void
On Sat, Aug 18, 2018 at 10:33:31PM +0800, zhong jiang wrote:
> On 2018/8/18 22:24, Bhaskar Singh wrote:
> > This patch might suppress some warrning.
> >
> > The function prototype of rtw_malloc2d is
> >
> > void *rtw_malloc2d(int h, int w, int size)
> >
> > This patch also resolves the
On Sat, Aug 18, 2018 at 10:33:31PM +0800, zhong jiang wrote:
> On 2018/8/18 22:24, Bhaskar Singh wrote:
> > This patch might suppress some warrning.
> >
> > The function prototype of rtw_malloc2d is
> >
> > void *rtw_malloc2d(int h, int w, int size)
> >
> > This patch also resolves the
Hi Dear,
Sorry to invade your privacy, I am Mrs. Daniella Kyle the wife of Mr
Angelo Kyle,my husband worked with Central Bank Of Philippines for ten
years before he died in the year 2012. When my late husband was alive
he deposited sum amount of Money with a Bank in UK, Presently,this
money is
Hi Dear,
Sorry to invade your privacy, I am Mrs. Daniella Kyle the wife of Mr
Angelo Kyle,my husband worked with Central Bank Of Philippines for ten
years before he died in the year 2012. When my late husband was alive
he deposited sum amount of Money with a Bank in UK, Presently,this
money is
On Sat, Aug 18, 2018 at 10:10:26PM +0800, zhong jiang wrote:
> On 2018/8/18 22:01, Julia Lawall wrote:
> >
> > On Sat, 18 Aug 2018, zhong jiang wrote:
> >
> >> On 2018/8/18 20:52, Himanshu Jha wrote:
> >>> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> Because
On Sat, Aug 18, 2018 at 10:10:26PM +0800, zhong jiang wrote:
> On 2018/8/18 22:01, Julia Lawall wrote:
> >
> > On Sat, 18 Aug 2018, zhong jiang wrote:
> >
> >> On 2018/8/18 20:52, Himanshu Jha wrote:
> >>> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> Because
On Thu, Aug 16, 2018 at 08:45:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.64 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.64 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Hi all,
Commit
cda5915d15d3 ("platform/x86: touchscreen_dmi: Add info for the Cube KNote
i1101 tablet")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpo0vHZOCf_2.pgp
Description: OpenPGP digital signature
Hi all,
Commit
cda5915d15d3 ("platform/x86: touchscreen_dmi: Add info for the Cube KNote
i1101 tablet")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpo0vHZOCf_2.pgp
Description: OpenPGP digital signature
On 2018/8/18 22:24, Bhaskar Singh wrote:
> This patch might suppress some warrning.
>
> The function prototype of rtw_malloc2d is
>
> void *rtw_malloc2d(int h, int w, int size)
>
> This patch also resolves the checkpatch.pl warning
>
> WARNING: line over 80 characters
>
> Signed-off-by: Bhaskar
On 2018/8/18 22:24, Bhaskar Singh wrote:
> This patch might suppress some warrning.
>
> The function prototype of rtw_malloc2d is
>
> void *rtw_malloc2d(int h, int w, int size)
>
> This patch also resolves the checkpatch.pl warning
>
> WARNING: line over 80 characters
>
> Signed-off-by: Bhaskar
Hi Yoshinori,
Commits
785b0958b55d ("h8300: gcc-8.1 fix")
8eabc2d5fae0 ("h8300: Add missing output register.")
are missing a Signed-off-by from their authors and committers.
Commit
85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
is missing a Signed-off-by from its committer.
--
Cheers,
Hi Yoshinori,
Commits
785b0958b55d ("h8300: gcc-8.1 fix")
8eabc2d5fae0 ("h8300: Add missing output register.")
are missing a Signed-off-by from their authors and committers.
Commit
85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
is missing a Signed-off-by from its committer.
--
Cheers,
This patch might suppress some warrning.
The function prototype of rtw_malloc2d is
void *rtw_malloc2d(int h, int w, int size)
This patch also resolves the checkpatch.pl warning
WARNING: line over 80 characters
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/core/rtw_efuse.c | 3
This patch might suppress some warrning.
The function prototype of rtw_malloc2d is
void *rtw_malloc2d(int h, int w, int size)
This patch also resolves the checkpatch.pl warning
WARNING: line over 80 characters
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/core/rtw_efuse.c | 3
On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.2 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.2 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On 2018/8/18 22:01, Julia Lawall wrote:
>
> On Sat, 18 Aug 2018, zhong jiang wrote:
>
>> On 2018/8/18 20:52, Himanshu Jha wrote:
>>> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
Because pci_alloc_consistent has been deprecated. We prefer to use
dam_alloc_coherent
On 2018/8/18 22:01, Julia Lawall wrote:
>
> On Sat, 18 Aug 2018, zhong jiang wrote:
>
>> On 2018/8/18 20:52, Himanshu Jha wrote:
>>> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
Because pci_alloc_consistent has been deprecated. We prefer to use
dam_alloc_coherent
On Thu, Aug 16, 2018 at 08:45:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.16 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.16 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Because pci_alloc_consistent has been deprecated. We prefer to use
dma_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
to increase the confidence.
Acked-by: Julia Lawall
Acked-by: Himanshu Jha
Signed-off-by: zhong jiang
---
v1->v2:
- fix some spelling mistakes.
Because pci_alloc_consistent has been deprecated. We prefer to use
dma_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
to increase the confidence.
Acked-by: Julia Lawall
Acked-by: Himanshu Jha
Signed-off-by: zhong jiang
---
v1->v2:
- fix some spelling mistakes.
On Sat, 18 Aug 2018, zhong jiang wrote:
> On 2018/8/18 20:52, Himanshu Jha wrote:
> > On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> >> Because pci_alloc_consistent has been deprecated. We prefer to use
> >> dam_alloc_coherent directly. Therefore, we should remove
> >>
On Sat, 18 Aug 2018, zhong jiang wrote:
> On 2018/8/18 20:52, Himanshu Jha wrote:
> > On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> >> Because pci_alloc_consistent has been deprecated. We prefer to use
> >> dam_alloc_coherent directly. Therefore, we should remove
> >>
On 2018/8/18 20:52, Himanshu Jha wrote:
> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
>> Because pci_alloc_consistent has been deprecated. We prefer to use
>> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
> ^^^ typo "dma"
>
> Also, typo in the
On 2018/8/18 20:52, Himanshu Jha wrote:
> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
>> Because pci_alloc_consistent has been deprecated. We prefer to use
>> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
> ^^^ typo "dma"
>
> Also, typo in the
Lieber Freund
Mein Name ist Angela Sanderson, ich bin 78 Jahre Original aus Island,
aber ich lebe in Manchester City im Vereinigten Königreich. Ich verlor
meinen Mann seit 2016, ohne Kind. Bitte ich brauche Ihre Hilfe, ich
bin ein Krebspatient .on 17/7 / 2018 diagnostizierte der Arzt Dr.
Mervyn
Lieber Freund
Mein Name ist Angela Sanderson, ich bin 78 Jahre Original aus Island,
aber ich lebe in Manchester City im Vereinigten Königreich. Ich verlor
meinen Mann seit 2016, ohne Kind. Bitte ich brauche Ihre Hilfe, ich
bin ein Krebspatient .on 17/7 / 2018 diagnostizierte der Arzt Dr.
Mervyn
Hi Palmer,
On Fri, Aug 17, 2018 at 01:28:11PM -0700, Palmer Dabbelt wrote:
[ ... ]
>
> This tag boots a Fedora root filesystem on QEMU's master branch for me,
> and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
> the HiFive Unleashed.
>
Do you have vmlinux embedded in bbl
Hi Palmer,
On Fri, Aug 17, 2018 at 01:28:11PM -0700, Palmer Dabbelt wrote:
[ ... ]
>
> This tag boots a Fedora root filesystem on QEMU's master branch for me,
> and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
> the HiFive Unleashed.
>
Do you have vmlinux embedded in bbl
Avoid the somewhat hard to grok assignment by using the seq_open_data
helper.
Signed-off-by: Rasmus Villemoes
---
fs/seq_file.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index c8c86660f6db..518a72e444d9 100644
--- a/fs/seq_file.c
+++
Avoid the somewhat hard to grok assignment by using the seq_open_data
helper.
Signed-off-by: Rasmus Villemoes
---
fs/seq_file.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index c8c86660f6db..518a72e444d9 100644
--- a/fs/seq_file.c
+++
Signed-off-by: Rasmus Villemoes
---
fs/seq_file.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 518a72e444d9..5cc4670294e7 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -632,18 +632,15 @@ void *__seq_open_private(struct file *f,
Signed-off-by: Rasmus Villemoes
---
fs/seq_file.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 518a72e444d9..5cc4670294e7 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -632,18 +632,15 @@ void *__seq_open_private(struct file *f,
Simplify the code slightly by using the seq_open_data helper.
Signed-off-by: Rasmus Villemoes
---
Depends on 1/8 introducing seq_open_data.
fs/proc/base.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index
Simplify the code slightly by using the seq_open_data helper.
Signed-off-by: Rasmus Villemoes
---
Depends on 1/8 introducing seq_open_data.
fs/proc/base.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index
Using the seq_open_data() helper, exports_net_open() essentially becomes
a oneliner.
Signed-off-by: Rasmus Villemoes
---
Depends on 1/8 introducing seq_open_data.
fs/nfsd/nfsctl.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
Simplify the code slightly by having seq_open_data do the ->private
assignment.
Signed-off-by: Rasmus Villemoes
---
Depends on 1/8 introducing seq_open_data.
Not including Thierry's ack/reviewed-by since it's been half a year since v1.
drivers/pci/controller/pci-tegra.c | 11 +--
1
Using the seq_open_data() helper, exports_net_open() essentially becomes
a oneliner.
Signed-off-by: Rasmus Villemoes
---
Depends on 1/8 introducing seq_open_data.
fs/nfsd/nfsctl.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
Simplify the code slightly by having seq_open_data do the ->private
assignment.
Signed-off-by: Rasmus Villemoes
---
Depends on 1/8 introducing seq_open_data.
Not including Thierry's ack/reviewed-by since it's been half a year since v1.
drivers/pci/controller/pci-tegra.c | 11 +--
1
The static inlines in bitmap.h do not handle a compile-time constant
nbits==0 correctly (they dereference the passed src or dst pointers,
despite only 0 words being valid to access). I had the 0-day buildbot
chew on a patch [1] that would cause build failures for such cases
without complaining,
The static inlines in bitmap.h do not handle a compile-time constant
nbits==0 correctly (they dereference the passed src or dst pointers,
despite only 0 words being valid to access). I had the 0-day buildbot
chew on a patch [1] that would cause build failures for such cases
without complaining,
Most other bitmap API, including the OOL version __bitmap_shift_right,
take unsigned nbits. This was accidentally left out from 2fbad29917c98.
Fixes: 2fbad29917c98 (lib: bitmap: change bitmap_shift_right to take unsigned
parameters)
Reported-by: Yury Norov
Signed-off-by: Rasmus Villemoes
---
Most other bitmap API, including the OOL version __bitmap_shift_right,
take unsigned nbits. This was accidentally left out from 2fbad29917c98.
Fixes: 2fbad29917c98 (lib: bitmap: change bitmap_shift_right to take unsigned
parameters)
Reported-by: Yury Norov
Signed-off-by: Rasmus Villemoes
---
It's not clear what's so horrible about emitting a function call to
handle a run-time sized bitmap. Moreover, gcc also emits a function call
for a compile-time-constant-but-huge nbits, so the comment isn't even
accurate.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
1
In the _zero, _fill and _copy functions, the small_const_nbits
branch is redundant. If nbits is small and const, gcc knows full well
that BITS_TO_LONGS(nbits) is 1, so len is also a compile-time
constant (sizeof(long)), and calling memset or memcpy with a length
argument of sizeof(long) makes gcc
It's not clear what's so horrible about emitting a function call to
handle a run-time sized bitmap. Moreover, gcc also emits a function call
for a compile-time-constant-but-huge nbits, so the comment isn't even
accurate.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4 ++--
1
In the _zero, _fill and _copy functions, the small_const_nbits
branch is redundant. If nbits is small and const, gcc knows full well
that BITS_TO_LONGS(nbits) is 1, so len is also a compile-time
constant (sizeof(long)), and calling memset or memcpy with a length
argument of sizeof(long) makes gcc
len is guaranteed to lie in [1, PAGE_SIZE]. If scnprintf is called with
a buffer size of 1, it is guaranteed to return 0. So in the extremely
unlikely case of having just one byte remaining in the page, let's just
call scnprintf anyway. The only difference is that this will write a
'\0' to that
For various alignments of buf, the current expression computes
4096 ok
4095 ok
8190
8189
...
4097
i.e., if the caller has already written two bytes into the page buffer,
len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next
boundary. So if the printed version of the bitmap is
len is guaranteed to lie in [1, PAGE_SIZE]. If scnprintf is called with
a buffer size of 1, it is guaranteed to return 0. So in the extremely
unlikely case of having just one byte remaining in the page, let's just
call scnprintf anyway. The only difference is that this will write a
'\0' to that
For various alignments of buf, the current expression computes
4096 ok
4095 ok
8190
8189
...
4097
i.e., if the caller has already written two bytes into the page buffer,
len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next
boundary. So if the printed version of the bitmap is
A recent LKML thread had me look into bitmap.{h,c} again, and I
stumbled on/rediscovered a few things.
Rasmus Villemoes (7):
lib/bitmap.c: remove wrong documentation
linux/bitmap.h: handle constant zero-size bitmaps correctly
linux/bitmap.h: remove redundant uses of small_const_nbits()
This promise is violated in a number of places, e.g. already in the
second function below this paragraph. Since I don't think anybody relies
on this being true, and since actually honouring it would hurt
performance and code size in various places, just remove the paragraph.
Signed-off-by: Rasmus
A recent LKML thread had me look into bitmap.{h,c} again, and I
stumbled on/rediscovered a few things.
Rasmus Villemoes (7):
lib/bitmap.c: remove wrong documentation
linux/bitmap.h: handle constant zero-size bitmaps correctly
linux/bitmap.h: remove redundant uses of small_const_nbits()
This promise is violated in a number of places, e.g. already in the
second function below this paragraph. Since I don't think anybody relies
on this being true, and since actually honouring it would hurt
performance and code size in various places, just remove the paragraph.
Signed-off-by: Rasmus
Hi Lina,
On Fri, 17 Aug 2018 20:10:23 +0100,
Lina Iyer wrote:
>
> During suspend the system may power down some of the system rails. As a
> result, the TLMM hw block may not be operational anymore and wakeup
> capable GPIOs will not be detected. The PDC however will be operational
> and the
Hi Lina,
On Fri, 17 Aug 2018 20:10:23 +0100,
Lina Iyer wrote:
>
> During suspend the system may power down some of the system rails. As a
> result, the TLMM hw block may not be operational anymore and wakeup
> capable GPIOs will not be detected. The PDC however will be operational
> and the
On Sat, 2018-08-18 at 12:29 +0200, Mike Galbraith wrote:
> On Fri, 2018-08-17 at 16:23 -0400, Steven Rostedt wrote:
> > Pulling in stable releases into v4.14-rt I triggered this with my CPU
> > hotplug test:
> >
> > [ cut here ]
> > kernel BUG at
On Sat, 2018-08-18 at 12:29 +0200, Mike Galbraith wrote:
> On Fri, 2018-08-17 at 16:23 -0400, Steven Rostedt wrote:
> > Pulling in stable releases into v4.14-rt I triggered this with my CPU
> > hotplug test:
> >
> > [ cut here ]
> > kernel BUG at
On 15.08.2018 18:02, Jon Hunter wrote:
> On 14/08/18 15:01, Marcel Ziswiler wrote:
>> From: Marcel Ziswiler
>>
>> Actually report the error codes from of_get_named_gpio() resp.
>> devm_gpio_request_one() upon trying to get the codec reset resp. sync
>> GPIOs unless it is just a probe deferral.
>>
On 15.08.2018 18:02, Jon Hunter wrote:
> On 14/08/18 15:01, Marcel Ziswiler wrote:
>> From: Marcel Ziswiler
>>
>> Actually report the error codes from of_get_named_gpio() resp.
>> devm_gpio_request_one() upon trying to get the codec reset resp. sync
>> GPIOs unless it is just a probe deferral.
>>
On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> Because pci_alloc_consistent has been deprecated. We prefer to use
> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
^^^ typo "dma"
Also, typo in the patch subject "dectect" -> "detect"
Otherwise,
On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> Because pci_alloc_consistent has been deprecated. We prefer to use
> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
^^^ typo "dma"
Also, typo in the patch subject "dectect" -> "detect"
Otherwise,
On Fri, 17 Aug 2018, Greg Kroah-Hartman wrote:
> On Fri, Aug 17, 2018 at 02:39:00PM +0200, Jinpu Wang wrote:
> >
> > I found the problem, CONFIG_HOTPLUG_SMT is enable due to CONFIG_SMP,
> > but I did explicitly enable CONFIG_HOTPLUG_CPU.
> >
> > That's why the smt dir is missing, and kernel panic
On Fri, 17 Aug 2018, Greg Kroah-Hartman wrote:
> On Fri, Aug 17, 2018 at 02:39:00PM +0200, Jinpu Wang wrote:
> >
> > I found the problem, CONFIG_HOTPLUG_SMT is enable due to CONFIG_SMP,
> > but I did explicitly enable CONFIG_HOTPLUG_CPU.
> >
> > That's why the smt dir is missing, and kernel panic
On Sat, Aug 18, 2018 at 10:11:54AM +, Manish Narani wrote:
> Ping.
First of all, one ping is enough. If your patchset contained, say, 30
patches, were you really going to send a ping for each one of them?!?!?!
Secondly, you do know that we have merge window right now, don't you?
And during
On Sat, Aug 18, 2018 at 10:11:54AM +, Manish Narani wrote:
> Ping.
First of all, one ping is enough. If your patchset contained, say, 30
patches, were you really going to send a ping for each one of them?!?!?!
Secondly, you do know that we have merge window right now, don't you?
And during
On 14.08.2018 11:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
>
> Signed-off-by: Marcel Ziswiler
Reviewed-by: Stefan Agner
>
> ---
>
> Changes in v2:
> - Silence probe deferral
On 14.08.2018 11:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
>
> Signed-off-by: Marcel Ziswiler
Reviewed-by: Stefan Agner
>
> ---
>
> Changes in v2:
> - Silence probe deferral
On Sat, 18 Aug 2018, zhong jiang wrote:
> Because pci_alloc_consistent has been deprecated. We prefer to use
> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
> to increase the confidence.
>
> Signed-off-by: zhong jiang
Thanks for the suggestion.
Acked-by:
On Sat, 18 Aug 2018, zhong jiang wrote:
> Because pci_alloc_consistent has been deprecated. We prefer to use
> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
> to increase the confidence.
>
> Signed-off-by: zhong jiang
Thanks for the suggestion.
Acked-by:
Because pci_alloc_consistent has been deprecated. We prefer to use
dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
to increase the confidence.
Signed-off-by: zhong jiang
---
scripts/coccinelle/api/alloc/zalloc-simple.cocci | 41 +---
1 file
Because pci_alloc_consistent has been deprecated. We prefer to use
dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
to increase the confidence.
Signed-off-by: zhong jiang
---
scripts/coccinelle/api/alloc/zalloc-simple.cocci | 41 +---
1 file
101 - 200 of 432 matches
Mail list logo
