A few other piddly suggestions.
On Thu, May 31, 2018 at 08:49:46AM -0600, Tycho Andersen wrote:
> This patch introduces a means for syscalls matched in seccomp to notify
> some other task that a particular filter has been triggered.
>
> The motivation for this is primarily for use with
Quoting Doug Anderson (2018-06-19 14:38:57)
> On Tue, Jun 19, 2018 at 2:18 PM, Stephen Boyd wrote:
> > Quoting Doug Anderson (2018-06-18 16:54:49)
> >>
> >> Is there a reason why you'd want to return 0 instead of some sort of
> >> error code? Wouldn't you want to know that this pin can't be a
A few other piddly suggestions.
On Thu, May 31, 2018 at 08:49:46AM -0600, Tycho Andersen wrote:
> This patch introduces a means for syscalls matched in seccomp to notify
> some other task that a particular filter has been triggered.
>
> The motivation for this is primarily for use with
Quoting Doug Anderson (2018-06-19 14:38:57)
> On Tue, Jun 19, 2018 at 2:18 PM, Stephen Boyd wrote:
> > Quoting Doug Anderson (2018-06-18 16:54:49)
> >>
> >> Is there a reason why you'd want to return 0 instead of some sort of
> >> error code? Wouldn't you want to know that this pin can't be a
Linux next (4.18.0-rc1-next-20180619) boot failed on beagle board x15.
Full log of trace please refer this link,
https://lkft.validation.linaro.org/scheduler/job/291535#L946
Here is back trace,
[3.561640] omap_rng 4809.rng: Random Number Generator ver. 20
[3.611949] brd: module
Linux next (4.18.0-rc1-next-20180619) boot failed on beagle board x15.
Full log of trace please refer this link,
https://lkft.validation.linaro.org/scheduler/job/291535#L946
Here is back trace,
[3.561640] omap_rng 4809.rng: Random Number Generator ver. 20
[3.611949] brd: module
On Wed, Jun 20, 2018 at 2:08 PM Michal Kubecek wrote:
>
>
> > @@ -254,10 +258,19 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm,
> > char __user *buf,
> > while (count) {
> > int got;
> > size_t size = min_t(size_t, PAGE_SIZE, count);
>
> We limit size to
On Wed, Jun 20, 2018 at 2:08 PM Michal Kubecek wrote:
>
>
> > @@ -254,10 +258,19 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm,
> > char __user *buf,
> > while (count) {
> > int got;
> > size_t size = min_t(size_t, PAGE_SIZE, count);
>
> We limit size to
get_monotonic_boottime() has been deprecated and might not be
safe to call in every context.
Change to use ktime_get_coarse_boottime_ts64.
Signed-off-by: Allen Pais
---
fs/proc/uptime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/uptime.c b/fs/proc/uptime.c
get_monotonic_boottime() has been deprecated and might not be
safe to call in every context.
Change to use ktime_get_coarse_boottime_ts64.
Signed-off-by: Allen Pais
---
fs/proc/uptime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/uptime.c b/fs/proc/uptime.c
Hi,
On Wed, 2018-06-20 at 07:09 +0800, Waiman Long wrote:
> On 05/24/2018 09:26 PM, Waiman Long wrote:
> > It was found that the use of up_read_non_owner() in NFS was causing
> > the following warning when DEBUG_RWSEMS was configured.
> >
> > DEBUG_LOCKS_WARN_ON(sem->owner != ((struct
Hi,
On Wed, 2018-06-20 at 07:09 +0800, Waiman Long wrote:
> On 05/24/2018 09:26 PM, Waiman Long wrote:
> > It was found that the use of up_read_non_owner() in NFS was causing
> > the following warning when DEBUG_RWSEMS was configured.
> >
> > DEBUG_LOCKS_WARN_ON(sem->owner != ((struct
From: Randy Dunlap
At over 4000 #includes, is the 9th most
#included header file in the Linux kernel. It does not need
, so drop that header and explicitly add
to source files that need it.
4146 #include
After this patch, there are 225 files that use ,
for a reduction of around 3900
From: Randy Dunlap
At over 4000 #includes, is the 9th most
#included header file in the Linux kernel. It does not need
, so drop that header and explicitly add
to source files that need it.
4146 #include
After this patch, there are 225 files that use ,
for a reduction of around 3900
On Sat, May 26, 2018 at 8:36 AM, Dmitry Vyukov wrote:
> On Thu, May 24, 2018 at 4:14 AM, Sergey Senozhatsky
> wrote:
>>> First, we should ask what we expect from this feature.
>>
>> Yeah. Can't really comment on this, it's up to Tetsuo and Dmitry to
>> decide. So far I've seen slightly different
From: Moritz Fischer
Date: Tue, 19 Jun 2018 09:54:53 -0700
> @@ -122,7 +122,7 @@ struct nixge_hw_dma_bd {
> u32 sw_id_offset;
> u32 reserved5;
> u32 reserved6;
> -};
> +} __packed;
As I understand it, based upon your replies to Florian, this bug doesn't
even show up with the
On Sat, May 26, 2018 at 8:36 AM, Dmitry Vyukov wrote:
> On Thu, May 24, 2018 at 4:14 AM, Sergey Senozhatsky
> wrote:
>>> First, we should ask what we expect from this feature.
>>
>> Yeah. Can't really comment on this, it's up to Tetsuo and Dmitry to
>> decide. So far I've seen slightly different
From: Moritz Fischer
Date: Tue, 19 Jun 2018 09:54:53 -0700
> @@ -122,7 +122,7 @@ struct nixge_hw_dma_bd {
> u32 sw_id_offset;
> u32 reserved5;
> u32 reserved6;
> -};
> +} __packed;
As I understand it, based upon your replies to Florian, this bug doesn't
even show up with the
There is race between nvme_remove and nvme_reset_work that can
lead to io hang.
nvme_removenvme_reset_work
-> nvme_remove_dead_ctrl
-> nvme_dev_disable
-> quiesce request_queue
There is race between nvme_remove and nvme_reset_work that can
lead to io hang.
nvme_removenvme_reset_work
-> nvme_remove_dead_ctrl
-> nvme_dev_disable
-> quiesce request_queue
On Mon, Aug 9, 2010 at 10:52 AM, Stefani Seibold wrote:
> Am Montag, den 09.08.2010, 09:37 +0100 schrieb David Woodhouse:
>> On Mon, 2010-08-09 at 09:25 +0100, stef...@seibold.net wrote:
>> > From: Stefani Seibold
>> >
>> > This patch add a quick format option which skips erasing of already
On Mon, Aug 9, 2010 at 10:52 AM, Stefani Seibold wrote:
> Am Montag, den 09.08.2010, 09:37 +0100 schrieb David Woodhouse:
>> On Mon, 2010-08-09 at 09:25 +0100, stef...@seibold.net wrote:
>> > From: Stefani Seibold
>> >
>> > This patch add a quick format option which skips erasing of already
Marek,
Am Mittwoch, 20. Juni 2018, 06:52:09 CEST schrieb Marek Vasut:
> On 06/19/2018 02:07 PM, Richard Weinberger wrote:
> > The denali NAND flash controller needs at least two clocks to operate,
> > nand_clk and nand_x_clk.
> > Since 1bb88666775e ("mtd: nand: denali: handle timing parameters by
Hi Keith
On 06/20/2018 12:39 AM, Keith Busch wrote:
> On Tue, Jun 19, 2018 at 04:30:50PM +0800, Jianchao Wang wrote:
>> There is race between nvme_remove and nvme_reset_work that can
>> lead to io hang.
>>
>> nvme_removenvme_reset_work
>> -> change state to DELETING
>>
Marek,
Am Mittwoch, 20. Juni 2018, 06:52:09 CEST schrieb Marek Vasut:
> On 06/19/2018 02:07 PM, Richard Weinberger wrote:
> > The denali NAND flash controller needs at least two clocks to operate,
> > nand_clk and nand_x_clk.
> > Since 1bb88666775e ("mtd: nand: denali: handle timing parameters by
Hi Keith
On 06/20/2018 12:39 AM, Keith Busch wrote:
> On Tue, Jun 19, 2018 at 04:30:50PM +0800, Jianchao Wang wrote:
>> There is race between nvme_remove and nvme_reset_work that can
>> lead to io hang.
>>
>> nvme_removenvme_reset_work
>> -> change state to DELETING
>>
On Wed, Jun 20, 2018 at 1:03 AM, Andrew Morton
wrote:
> On Mon, 11 Jun 2018 13:10:04 +0200 Dmitry Vyukov wrote:
>
>> Currently task hung checking interval is equal to timeout,
>> as the result hung is detected anywhere between timeout and 2*timeout.
>> This is fine for most interactive
On Wed, Jun 20, 2018 at 1:03 AM, Andrew Morton
wrote:
> On Mon, 11 Jun 2018 13:10:04 +0200 Dmitry Vyukov wrote:
>
>> Currently task hung checking interval is equal to timeout,
>> as the result hung is detected anywhere between timeout and 2*timeout.
>> This is fine for most interactive
Hi Sinan,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on v4.18-rc1 next-20180619]
[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/commits
Hi!
With the introduction of mux-locked I2C muxes, the concept of
locking only a segment of the I2C adapter tree was added. At the
time, I did not want to cause a lot of extra churn, so left most
users of i2c_lock_adapter alone and apparently didn't think enough
about it; they simply continued to
On 06/19/2018 11:45 AM, Peter Zijlstra wrote:
I suspect you want this through the DRM tree? Ingo are you OK with that?
Yes, I can ask Dave to pull this. Ingo?
Thanks,
Thomas
Hi Sinan,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on v4.18-rc1 next-20180619]
[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/commits
Hi!
With the introduction of mux-locked I2C muxes, the concept of
locking only a segment of the I2C adapter tree was added. At the
time, I did not want to cause a lot of extra churn, so left most
users of i2c_lock_adapter alone and apparently didn't think enough
about it; they simply continued to
On 06/19/2018 11:45 AM, Peter Zijlstra wrote:
I suspect you want this through the DRM tree? Ingo are you OK with that?
Yes, I can ask Dave to pull this. Ingo?
Thanks,
Thomas
On Wed, Jun 20, 2018 at 06:56:04AM +0900, Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 1:24 AM Michal Kubecek wrote:
> >
> > Recent rewrite introduced a regression, /proc/$pid/cmdline is missing the
> > trailing null character:
> >
> > mike@lion:/tmp> cat /proc/self/cmdline | od -t c
> >
On Wed, Jun 20, 2018 at 06:56:04AM +0900, Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 1:24 AM Michal Kubecek wrote:
> >
> > Recent rewrite introduced a regression, /proc/$pid/cmdline is missing the
> > trailing null character:
> >
> > mike@lion:/tmp> cat /proc/self/cmdline | od -t c
> >
Hi,
I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.
This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but
Hi,
I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.
This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.
Signed-off-by: Chris Packham
---
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
comment for the ECC status bits.
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.
Signed-off-by: Chris Packham
---
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
comment for the ECC status bits.
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.
Reviewed-by: Boris Brezillon
Signed-off-by: Chris Packham
---
This is now
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.
Reviewed-by: Boris Brezillon
Signed-off-by: Chris Packham
---
This is now
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.
Suggested-by: Boris Brezillon
Reviewed-by: Boris Brezillon
Signed-off-by: Chris Packham
---
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.
Suggested-by: Boris Brezillon
Reviewed-by: Boris Brezillon
Signed-off-by: Chris Packham
---
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from
>From the controllers point of view this is the same as no or
software only ECC.
Reviewed-by: Boris Brezillon
Signed-off-by: Chris Packham
---
Changes in v2:
- New
Changes in v3:
- Add review from Boris
drivers/mtd/nand/raw/marvell_nand.c | 1 +
1 file changed, 1 insertion(+)
diff --git
>From the controllers point of view this is the same as no or
software only ECC.
Reviewed-by: Boris Brezillon
Signed-off-by: Chris Packham
---
Changes in v2:
- New
Changes in v3:
- Add review from Boris
drivers/mtd/nand/raw/marvell_nand.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Thu, May 31, 2018 at 08:49:46AM -0600, Tycho Andersen wrote:
> This patch introduces a means for syscalls matched in seccomp to notify
> some other task that a particular filter has been triggered.
>
> The motivation for this is primarily for use with containers. For example,
> if a container
On Thu, May 31, 2018 at 08:49:46AM -0600, Tycho Andersen wrote:
> This patch introduces a means for syscalls matched in seccomp to notify
> some other task that a particular filter has been triggered.
>
> The motivation for this is primarily for use with containers. For example,
> if a container
Hi Martin,
On Tue, 19 Jun 2018 22:03:48 -0400 "Martin K. Petersen"
wrote:
>
> > Commit
> >
> > 508fbc44bbb7 ("scsi: be2iscsi: Include null char in SET_HOST_DATA")
> >
> > is missing a Signed-off-by from its author.
>
> Fixed, thanks!
Unfortunately, James had already merged your tree :-(
Hi Martin,
On Tue, 19 Jun 2018 22:03:48 -0400 "Martin K. Petersen"
wrote:
>
> > Commit
> >
> > 508fbc44bbb7 ("scsi: be2iscsi: Include null char in SET_HOST_DATA")
> >
> > is missing a Signed-off-by from its author.
>
> Fixed, thanks!
Unfortunately, James had already merged your tree :-(
On 06/19/2018 02:07 PM, Richard Weinberger wrote:
> The denali NAND flash controller needs at least two clocks to operate,
> nand_clk and nand_x_clk.
> Since 1bb88666775e ("mtd: nand: denali: handle timing parameters by
> setup_data_interface()") nand_x_clk is used to derive timing settings.
>
>
On 06/19/2018 02:07 PM, Richard Weinberger wrote:
> The denali NAND flash controller needs at least two clocks to operate,
> nand_clk and nand_x_clk.
> Since 1bb88666775e ("mtd: nand: denali: handle timing parameters by
> setup_data_interface()") nand_x_clk is used to derive timing settings.
>
>
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ba4dbdedd3edc2798659bcd8b1a184ea8bdd04dc
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 3
On Wed, May 30, 2018 at 1:57 PM, Andrew Lunn wrote:
> On Wed, May 30, 2018 at 01:48:30PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> moves the allocation into struct mdio_mux_gpio_state during probe.
>>
>> [1]
>>
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ba4dbdedd3edc2798659bcd8b1a184ea8bdd04dc
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 3
On Wed, May 30, 2018 at 1:57 PM, Andrew Lunn wrote:
> On Wed, May 30, 2018 at 01:48:30PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> moves the allocation into struct mdio_mux_gpio_state during probe.
>>
>> [1]
>>
Hi all,
Changes since 20180619:
Undropped tree: userns
The userns tree gained conflicts against the vfs tree.
The akpm-current tree gained a conflict against the scsi tree.
Non-merge commits (relative to Linus' tree): 1399
1468 files changed, 45747 insertions(+), 23865 deletions
Hi all,
Changes since 20180619:
Undropped tree: userns
The userns tree gained conflicts against the vfs tree.
The akpm-current tree gained a conflict against the scsi tree.
Non-merge commits (relative to Linus' tree): 1399
1468 files changed, 45747 insertions(+), 23865 deletions
On 19-06-18, 15:23, Daniel Lezcano wrote:
> Initially, the cpu_cooling device for ARM was changed by adding a new
> policy inserting idle cycles. The intel_powerclamp driver does a
> similar action.
>
> Instead of implementing idle injections privately in the cpu_cooling
> device, move the idle
On 19-06-18, 15:23, Daniel Lezcano wrote:
> Initially, the cpu_cooling device for ARM was changed by adding a new
> policy inserting idle cycles. The intel_powerclamp driver does a
> similar action.
>
> Instead of implementing idle injections privately in the cpu_cooling
> device, move the idle
All the pci_printk uses are at KERN_DEBUG which is always
emitted into the kernel logging whenever the console log
level is high enough.
Are any of these appropriate for conversion to pci_dbg
to allow these only to be emitted via dynamic_debug or
if necessary via a #define DEBUG during
All the pci_printk uses are at KERN_DEBUG which is always
emitted into the kernel logging whenever the console log
level is high enough.
Are any of these appropriate for conversion to pci_dbg
to allow these only to be emitted via dynamic_debug or
if necessary via a #define DEBUG during
On Tue, Jun 19, 2018 at 05:57:34PM -0700, Alistair Strachan wrote:
> There is no speed difference, and it makes the code harder to read.
>
> Cc: Greg Kroah-Hartman
> Cc: Arve Hjønnevåg
> Cc: Todd Kjos
> Cc: Martijn Coenen
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
On Tue, Jun 19, 2018 at 05:57:34PM -0700, Alistair Strachan wrote:
> There is no speed difference, and it makes the code harder to read.
>
> Cc: Greg Kroah-Hartman
> Cc: Arve Hjønnevåg
> Cc: Todd Kjos
> Cc: Martijn Coenen
> Cc: de...@driverdev.osuosl.org
> Cc: linux-kernel@vger.kernel.org
>
With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to
detect buffer overflows. If src or dest is declared as a char, attempts to
copy more than byte will result in a fortify_panic().
Address this problem in mvebu_setup_boot_addr_wa() by declaring
mvebu_boot_wa_start and
On Tue, Jun 19, 2018 at 05:57:35PM -0700, Alistair Strachan wrote:
> The ashmem driver did not check that the size/offset of the vma passed
> to its .mmap() function was not larger than the ashmem object being
> mapped. This could cause mmap() to succeed, even though accessing parts
> of the
With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to
detect buffer overflows. If src or dest is declared as a char, attempts to
copy more than byte will result in a fortify_panic().
Address this problem in mvebu_setup_boot_addr_wa() by declaring
mvebu_boot_wa_start and
On Tue, Jun 19, 2018 at 05:57:35PM -0700, Alistair Strachan wrote:
> The ashmem driver did not check that the size/offset of the vma passed
> to its .mmap() function was not larger than the ashmem object being
> mapped. This could cause mmap() to succeed, even though accessing parts
> of the
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Wednesday, June 20, 2018 3:20 AM
> To: Randy Dunlap
> Cc: Vadim Pasternak ; andy.shevche...@gmail.com;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; platform-driver-
> x...@vger.kernel.org;
> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Wednesday, June 20, 2018 3:20 AM
> To: Randy Dunlap
> Cc: Vadim Pasternak ; andy.shevche...@gmail.com;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; platform-driver-
> x...@vger.kernel.org;
On (06/20/18 12:38), Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 11:50 AM Sergey Senozhatsky
> wrote:
> >
> > It's not UART on its own that immediately calls into printk(), that would
> > be trivial to fix, it's all those subsystems that serial console driver
> > can call into.
>
> We
On (06/20/18 12:38), Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 11:50 AM Sergey Senozhatsky
> wrote:
> >
> > It's not UART on its own that immediately calls into printk(), that would
> > be trivial to fix, it's all those subsystems that serial console driver
> > can call into.
>
> We
Currently the function get_random_bytes_arch() has return value 'void'.
If the hw RNG fails we currently fall back to using get_random_bytes().
This defeats the purpose of requesting random material from the hw RNG
in the first place.
There are currently no intree users of
Currently printing [hashed] pointers requires enough entropy to be
available. Early in the boot sequence this may not be the case
resulting in a dummy string '(ptrval)' being printed. This
makes debugging the early boot sequence difficult. We can relax the
requirement to use
Currently the function get_random_bytes_arch() has return value 'void'.
If the hw RNG fails we currently fall back to using get_random_bytes().
This defeats the purpose of requesting random material from the hw RNG
in the first place.
There are currently no intree users of
Currently printing [hashed] pointers requires enough entropy to be
available. Early in the boot sequence this may not be the case
resulting in a dummy string '(ptrval)' being printed. This
makes debugging the early boot sequence difficult. We can relax the
requirement to use
Ted,
Version 8 changes patch 2 which you previously acked. Change is to
remove integer cast as suggested on LKML. I've kept the ACK.
Changes made to patch with reviewed-by tag from Steve were acknowledged
on LKML, I've also kept Steve's tag.
Currently printing pointers early in the boot
Ted,
Version 8 changes patch 2 which you previously acked. Change is to
remove integer cast as suggested on LKML. I've kept the ACK.
Changes made to patch with reviewed-by tag from Steve were acknowledged
on LKML, I've also kept Steve's tag.
Currently printing pointers early in the boot
Currently we must wait for enough entropy to become available before
hashed pointers can be printed. We can remove this wait by using the
hw RNG if available.
Use hw RNG to get keying material.
Reviewed-by: Steven Rostedt (VMware)
Suggested-by: Kees Cook
Signed-off-by: Tobin C. Harding
---
There are a couple of whitespace issues around the function
get_random_bytes_arch(). In preparation for patching this function
let's clean them up.
Acked-by: Theodore Ts'o
Signed-off-by: Tobin C. Harding
---
drivers/char/random.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
Currently we must wait for enough entropy to become available before
hashed pointers can be printed. We can remove this wait by using the
hw RNG if available.
Use hw RNG to get keying material.
Reviewed-by: Steven Rostedt (VMware)
Suggested-by: Kees Cook
Signed-off-by: Tobin C. Harding
---
There are a couple of whitespace issues around the function
get_random_bytes_arch(). In preparation for patching this function
let's clean them up.
Acked-by: Theodore Ts'o
Signed-off-by: Tobin C. Harding
---
drivers/char/random.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
On Wed, 20 Jun 2018, Linus Torvalds wrote:
> What is that odd binary blob i2c_hid_desc_override, and where does the
> data come from? Not explained anywhere.
Fair enough; it's a pretty standard HID descriptor override, but you're
right that we're usually replacing it in a bit more verbose way.
On Wed, 20 Jun 2018, Linus Torvalds wrote:
> What is that odd binary blob i2c_hid_desc_override, and where does the
> data come from? Not explained anywhere.
Fair enough; it's a pretty standard HID descriptor override, but you're
right that we're usually replacing it in a bit more verbose way.
* Nishanth Menon [180619 20:13]:
> Hi,
>
> This series was previously send out as part of a larger AM654 UART
> support series, but was determined to create a bit of merge conflicts
> due to interdependence.
Both patches look good to me:
Acked-by: Tony Lindgren
* Nishanth Menon [180619 20:13]:
> Hi,
>
> This series was previously send out as part of a larger AM654 UART
> support series, but was determined to create a bit of merge conflicts
> due to interdependence.
Both patches look good to me:
Acked-by: Tony Lindgren
On (06/19/18 22:32), Steven Rostedt wrote:
> On Wed, 20 Jun 2018 10:58:34 +0900
> Sergey Senozhatsky wrote:
>
> > Which one of these you'd prefer to see in ftrace_dump():
> >
> > - printk_nmi_direct_enter() / printk_nmi_direct_exit()
>
> The above appears to be the most sane.
OK. The original
On (06/19/18 22:32), Steven Rostedt wrote:
> On Wed, 20 Jun 2018 10:58:34 +0900
> Sergey Senozhatsky wrote:
>
> > Which one of these you'd prefer to see in ftrace_dump():
> >
> > - printk_nmi_direct_enter() / printk_nmi_direct_exit()
>
> The above appears to be the most sane.
OK. The original
Drivers are expected to call pci_reset_slot() or pci_reset_bus() by
querying if a system supports hotplug or not. A survey showed that most
drivers don't do this and we are leaking hotplug capability to the
user.
Hide pci_slot_reset() from drivers and embed into pci_bus_reset().
Change
Drivers are expected to call pci_reset_slot() or pci_reset_bus() by
querying if a system supports hotplug or not. A survey showed that most
drivers don't do this and we are leaking hotplug capability to the
user.
Hide pci_slot_reset() from drivers and embed into pci_bus_reset().
Change
Rename pci_reset_bridge_secondary_bus() to pci_bridge_secondary_bus_reset()
and move the declartation from linux/pci.h to drivers/pci.h to be used
internally in PCI directory only.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_hpc.c | 2 +-
drivers/pci/pci.c| 11
Drivers are expected to call pci_try_reset_slot() or pci_try_reset_bus() by
querying if a system supports hotplug or not. A survey showed that most
drivers don't do this and we are leaking hotplug capability to the user.
Hide pci_try_slot_reset() from drivers and embed into pci_try_bus_reset().
Rename pci_reset_bridge_secondary_bus() to pci_bridge_secondary_bus_reset()
and move the declartation from linux/pci.h to drivers/pci.h to be used
internally in PCI directory only.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_hpc.c | 2 +-
drivers/pci/pci.c| 11
Drivers are expected to call pci_try_reset_slot() or pci_try_reset_bus() by
querying if a system supports hotplug or not. A survey showed that most
drivers don't do this and we are leaking hotplug capability to the user.
Hide pci_try_slot_reset() from drivers and embed into pci_try_bus_reset().
commit 01fd61c0b9bd ("PCI: Add a return type for
pci_reset_bridge_secondary_bus()") added a return value to the function to
return if a device is accessible following a reset. Callers are not
checking the value.
Pass error code up high in the stack if device is not accessible.
Signed-off-by:
Getting ready to hide pci_reset_bridge_secondary_bus() from the drivers.
pci_reset_bridge_secondary_bus() should only be used internally by the
PCI code itself.
Other drivers should rely on higher level pci_reset_xxx() API.
Signed-off-by: Sinan Kaya
---
drivers/infiniband/hw/hfi1/pcie.c | 4
commit 01fd61c0b9bd ("PCI: Add a return type for
pci_reset_bridge_secondary_bus()") added a return value to the function to
return if a device is accessible following a reset. Callers are not
checking the value.
Pass error code up high in the stack if device is not accessible.
Signed-off-by:
Getting ready to hide pci_reset_bridge_secondary_bus() from the drivers.
pci_reset_bridge_secondary_bus() should only be used internally by the
PCI code itself.
Other drivers should rely on higher level pci_reset_xxx() API.
Signed-off-by: Sinan Kaya
---
drivers/infiniband/hw/hfi1/pcie.c | 4
On 20 June 2018 at 13:04, Benjamin Herrenschmidt
wrote:
> On Wed, 2018-06-13 at 14:36 -0500, Eddie James wrote:
>> }
>>
>> +static int fsi_i2c_remove(struct device *dev)
>> +{
>> + struct fsi_i2c_master *i2c = dev_get_drvdata(dev);
>> + struct fsi_i2c_port *port;
>> +
>> +
On 20 June 2018 at 13:04, Benjamin Herrenschmidt
wrote:
> On Wed, 2018-06-13 at 14:36 -0500, Eddie James wrote:
>> }
>>
>> +static int fsi_i2c_remove(struct device *dev)
>> +{
>> + struct fsi_i2c_master *i2c = dev_get_drvdata(dev);
>> + struct fsi_i2c_port *port;
>> +
>> +
1 - 100 of 1770 matches
Mail list logo
