On Tue, 8 Nov 2016, Jens Axboe wrote:
> On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
> > This series adds support for automatic interrupt assignment to devices
> > that have a few vectors that are set aside for admin or config purposes
> > and thus should not fall into the general per-cpu
On Tue, 8 Nov 2016, Jens Axboe wrote:
> On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
> > This series adds support for automatic interrupt assignment to devices
> > that have a few vectors that are set aside for admin or config purposes
> > and thus should not fall into the general per-cpu
> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wirel...@vger.kernel.org; Cathy
> Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris
>
> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wirel...@vger.kernel.org; Cathy
> Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris
>
Commit-ID: 0cf71b04467bc34063cecae577f12481da6cc565
Gitweb: http://git.kernel.org/tip/0cf71b04467bc34063cecae577f12481da6cc565
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:06 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016
Commit-ID: 0cf71b04467bc34063cecae577f12481da6cc565
Gitweb: http://git.kernel.org/tip/0cf71b04467bc34063cecae577f12481da6cc565
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:06 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100
PCI: Remove the
Commit-ID: 402723ad5c625ee052432698ae5e56b02d38d4ec
Gitweb: http://git.kernel.org/tip/402723ad5c625ee052432698ae5e56b02d38d4ec
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:05 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016
Commit-ID: 402723ad5c625ee052432698ae5e56b02d38d4ec
Gitweb: http://git.kernel.org/tip/402723ad5c625ee052432698ae5e56b02d38d4ec
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:05 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100
PCI/MSI: Provide
Commit-ID: 61e1c5905290efe48bacda5e342d4af4cb1b923b
Gitweb: http://git.kernel.org/tip/61e1c5905290efe48bacda5e342d4af4cb1b923b
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:04 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016
Commit-ID: 67c93c218dc5d1b45d547771f1fdb44a381e1faf
Gitweb: http://git.kernel.org/tip/67c93c218dc5d1b45d547771f1fdb44a381e1faf
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:03 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016
Commit-ID: 61e1c5905290efe48bacda5e342d4af4cb1b923b
Gitweb: http://git.kernel.org/tip/61e1c5905290efe48bacda5e342d4af4cb1b923b
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:04 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016 08:25:09 +0100
PCI/MSI: Propagate
Commit-ID: 67c93c218dc5d1b45d547771f1fdb44a381e1faf
Gitweb: http://git.kernel.org/tip/67c93c218dc5d1b45d547771f1fdb44a381e1faf
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:03 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016 08:25:09 +0100
genirq/affinity:
Commit-ID: 212bd846223c718b6577d4df16fd8d05a55ad914
Gitweb: http://git.kernel.org/tip/212bd846223c718b6577d4df16fd8d05a55ad914
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:02 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016
Commit-ID: 212bd846223c718b6577d4df16fd8d05a55ad914
Gitweb: http://git.kernel.org/tip/212bd846223c718b6577d4df16fd8d05a55ad914
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:02 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016 08:25:08 +0100
genirq/affinity:
Commit-ID: 20e407e195b29a4f5a18d713a61f54a75f992bd5
Gitweb: http://git.kernel.org/tip/20e407e195b29a4f5a18d713a61f54a75f992bd5
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:01 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016
Commit-ID: 20e407e195b29a4f5a18d713a61f54a75f992bd5
Gitweb: http://git.kernel.org/tip/20e407e195b29a4f5a18d713a61f54a75f992bd5
Author: Christoph Hellwig
AuthorDate: Tue, 8 Nov 2016 17:15:01 -0800
Committer: Thomas Gleixner
CommitDate: Wed, 9 Nov 2016 08:25:08 +0100
genirq/affinity:
Hi Will,
On 08/11/2016 20:02, Don Dutile wrote:
> On 11/08/2016 12:54 PM, Will Deacon wrote:
>> On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote:
>>> On 08/11/2016 03:45, Will Deacon wrote:
Rather than treat these as separate problems, a better interface is to
tell userspace
Hi Will,
On 08/11/2016 20:02, Don Dutile wrote:
> On 11/08/2016 12:54 PM, Will Deacon wrote:
>> On Tue, Nov 08, 2016 at 03:27:23PM +0100, Auger Eric wrote:
>>> On 08/11/2016 03:45, Will Deacon wrote:
Rather than treat these as separate problems, a better interface is to
tell userspace
On Tue 08-11-16 11:12:45, Johannes Weiner wrote:
> On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > The radix tree counts valid entries in each tree node. Entries stored
> > > in the tree cannot be removed by simpling storing NULL
On Tue 08-11-16 11:12:45, Johannes Weiner wrote:
> On Tue, Nov 08, 2016 at 10:53:52AM +0100, Jan Kara wrote:
> > On Mon 07-11-16 14:07:36, Johannes Weiner wrote:
> > > The radix tree counts valid entries in each tree node. Entries stored
> > > in the tree cannot be removed by simpling storing NULL
This patch tries to utilize tuntap rx batching by peeking the tx
virtqueue during transmission, if there's more available buffers in
the virtqueue, set MSG_MORE flag for a hint for tuntap to batch the
packets. The maximum number of batched tx packets were specified
through a module parameter:
This patch tries to utilize tuntap rx batching by peeking the tx
virtqueue during transmission, if there's more available buffers in
the virtqueue, set MSG_MORE flag for a hint for tuntap to batch the
packets. The maximum number of batched tx packets were specified
through a module parameter:
We should use vq->last_avail_idx instead of vq->avail_idx in the
checking of vhost_vq_avail_empty() since latter is the cached avail
index from guest but we want to know if there's pending available
buffers in the virtqueue.
Signed-off-by: Jason Wang
---
Backlog were used for tuntap rx, but it can only process 1 packet at
one time since it was scheduled during sendmsg() synchronously in
process context. This lead bad cache utilization so this patch tries
to do some batching before call rx NAPI. This is done through:
- accept MSG_MORE as a hint
We should use vq->last_avail_idx instead of vq->avail_idx in the
checking of vhost_vq_avail_empty() since latter is the cached avail
index from guest but we want to know if there's pending available
buffers in the virtqueue.
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 2 +-
1 file
Backlog were used for tuntap rx, but it can only process 1 packet at
one time since it was scheduled during sendmsg() synchronously in
process context. This lead bad cache utilization so this patch tries
to do some batching before call rx NAPI. This is done through:
- accept MSG_MORE as a hint
There are rx_ring_num queues. Each queue will load xdp prog. So
bpf_prog_add() should add rx_ring_num to ref_cnt.
Signed-off-by: Zhiyi Sun
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
There are rx_ring_num queues. Each queue will load xdp prog. So
bpf_prog_add() should add rx_ring_num to ref_cnt.
Signed-off-by: Zhiyi Sun
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Arnd Bergmann writes:
> On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote:
>> Arnd Bergmann writes:
>> If a non-exact match is found, either by closest_below or closest_above,
>> rate is
>> set (rate = freqs[closest_xxx].cpll). And a couple of lines
Arnd Bergmann writes:
> On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote:
>> Arnd Bergmann writes:
>> If a non-exact match is found, either by closest_below or closest_above,
>> rate is
>> set (rate = freqs[closest_xxx].cpll). And a couple of lines later after the
>> if/else,
On Fri, Nov 04, 2016 at 04:36:31PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)"
>
> When using CM to establish connections, qp number that was freed
> just now will be rejected by ib core. To fix these problem, We
> change qpn allocation to round-robin mode. We
On Fri, Nov 04, 2016 at 04:36:31PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)"
>
> When using CM to establish connections, qp number that was freed
> just now will be rejected by ib core. To fix these problem, We
> change qpn allocation to round-robin mode. We added the round-robin
> mode
On Fri, Nov 04, 2016 at 04:36:25PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)"
>
> This patch modified the logic of allocating memory using APIs in
> hns RoCE driver. We used kcalloc instead of kmalloc_array and
> bitmap_zero. And When kcalloc failed, call vzalloc
On Fri, Nov 04, 2016 at 04:36:25PM +, Salil Mehta wrote:
> From: "Wei Hu (Xavier)"
>
> This patch modified the logic of allocating memory using APIs in
> hns RoCE driver. We used kcalloc instead of kmalloc_array and
> bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> memory.
>
>
On 11/09/2016 02:15 AM, Christoph Hellwig wrote:
Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.
Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it
Hi!
> >+struct uleds_device {
> >+struct uleds_user_dev user_dev;
> >+struct led_classdev led_cdev;
> >+struct mutexmutex;
> >+enum uleds_statestate;
> >+wait_queue_head_t waitq;
> >+unsigned char brightness;
>
> I've just noticed
On 11/09/2016 02:15 AM, Christoph Hellwig wrote:
Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.
Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it
Hi!
> >+struct uleds_device {
> >+struct uleds_user_dev user_dev;
> >+struct led_classdev led_cdev;
> >+struct mutexmutex;
> >+enum uleds_statestate;
> >+wait_queue_head_t waitq;
> >+unsigned char brightness;
>
> I've just noticed
On 11/09/2016 02:15 AM, Christoph Hellwig wrote:
Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.
Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it
On 11/09/2016 02:15 AM, Christoph Hellwig wrote:
Only calculate the affinity for the main I/O vectors, and skip the
pre or post vectors specified by struct irq_affinity.
Also remove the irq_affinity cpumask argument that has never been used.
If we ever need it in the future we can pass it
On Tue, Nov 08, 2016 at 04:18:13PM -0800, Josh Triplett wrote:
> This prepares for making prctl optional.
>
> Signed-off-by: Josh Triplett
> +
...
> +static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)
> +{
> + struct fd exe;
> + struct file
On Tue, Nov 08, 2016 at 04:18:13PM -0800, Josh Triplett wrote:
> This prepares for making prctl optional.
>
> Signed-off-by: Josh Triplett
> +
...
> +static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)
> +{
> + struct fd exe;
> + struct file *old_exe, *exe_file;
> +
On Tue, Nov 08, 2016 at 03:00:49PM +0100, Arnd Bergmann wrote:
> The regulator changes assigned data to an uninitialized pointer:
>
> drivers/staging/iio/frequency/ad9832.c: In function 'ad9832_probe':
> drivers/staging/iio/frequency/ad9832.c:214:11: error: 'st' may be used
> uninitialized in
On Tue, Nov 08, 2016 at 03:00:49PM +0100, Arnd Bergmann wrote:
> The regulator changes assigned data to an uninitialized pointer:
>
> drivers/staging/iio/frequency/ad9832.c: In function 'ad9832_probe':
> drivers/staging/iio/frequency/ad9832.c:214:11: error: 'st' may be used
> uninitialized in
On Tue, Nov 08, 2016 at 09:58:24PM +0100, Luis R. Rodriguez wrote:
> > > Furthermore -- how does this framework compare to Andrzej's resource
> > > tracking
> > > solution? I confess I have not had a chance yet to review yet but in
> > > light of
> > > this question it would be good to know if
On Tue, Nov 08, 2016 at 09:58:24PM +0100, Luis R. Rodriguez wrote:
> > > Furthermore -- how does this framework compare to Andrzej's resource
> > > tracking
> > > solution? I confess I have not had a chance yet to review yet but in
> > > light of
> > > this question it would be good to know if
Thanks for Herbert's reminder.
I have drop this patch in a previous mail.
Regards!
Yanjiang
On 2016年11月08日 20:09, Herbert Xu wrote:
yanjiang@windriver.com wrote:
From: Yanjiang Jin
This is to eliminate the below compile error:
crypto/rsa_helper.c:19:29:
Thanks for Herbert's reminder.
I have drop this patch in a previous mail.
Regards!
Yanjiang
On 2016年11月08日 20:09, Herbert Xu wrote:
yanjiang@windriver.com wrote:
From: Yanjiang Jin
This is to eliminate the below compile error:
crypto/rsa_helper.c:19:29: fatal error: rsaprivkey-asn1.h:
Given two conditions like,
COND 1. jiffies >= rdp->rsp->gp_start + 2 * jiffies_till_sched_qs
COND 2. jiffies >= rdp->rsp->gp_start + jiffies_till_sched_qs
A set of jiffies satisfying COND 2 includes another set satisfying
COND 1. Thus COND 1 can be removed from a condition, (COND 1 || COND 2).
Given two conditions like,
COND 1. jiffies >= rdp->rsp->gp_start + 2 * jiffies_till_sched_qs
COND 2. jiffies >= rdp->rsp->gp_start + jiffies_till_sched_qs
A set of jiffies satisfying COND 2 includes another set satisfying
COND 1. Thus COND 1 can be removed from a condition, (COND 1 || COND 2).
Currently rcu code forces CPU into scheduler when jiffies >=
rcu_state.gp_start + jiffies_till_sched_qs, via resched_cpu().
It would be better to force CPU into scheduler when jiffies >=
rcu_state.jiffies_resched, too.
Signed-off-by: Byungchul Park
---
kernel/rcu/tree.c
Currently rcu code forces CPU into scheduler when jiffies >=
rcu_state.gp_start + jiffies_till_sched_qs, via resched_cpu().
It would be better to force CPU into scheduler when jiffies >=
rcu_state.jiffies_resched, too.
Signed-off-by: Byungchul Park
---
kernel/rcu/tree.c | 5 ++---
1 file
* Michal Marek wrote:
> On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote:
> > Debian started to build the gcc with -fPIE by default so the kernel
> > build ends before it starts properly with:
> > |kernel/bounds.c:1:0: error: code model kernel does not
* Michal Marek wrote:
> On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote:
> > Debian started to build the gcc with -fPIE by default so the kernel
> > build ends before it starts properly with:
> > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
On Tue, Nov 8, 2016 at 7:54 PM, Feng Tang wrote:
> On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
>>
>> I left the thing running for the weekend and it failed 26 out of 16057
>> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
>> when it
On Tue, Nov 8, 2016 at 7:54 PM, Feng Tang wrote:
> On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
>>
>> I left the thing running for the weekend and it failed 26 out of 16057
>> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
>> when it fails, but eventually
On Tue, Nov 08, 2016 at 02:38:52PM +0100, Arnd Bergmann wrote:
> A bugfix accidentally removed the implicit initialization of the
> dma channel number, causing undefined behavior when
> v->alloc_dma_channel is NULL:
>
> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
>
On Tue, Nov 08, 2016 at 02:38:52PM +0100, Arnd Bergmann wrote:
> A bugfix accidentally removed the implicit initialization of the
> dma channel number, causing undefined behavior when
> v->alloc_dma_channel is NULL:
>
> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
>
On 08-11-16, 21:25, Stratos Karafotis wrote:
> But this is the supposed behaviour of conservative governor. We want
> the CPU to increase the frequency in steps. The patch just resets
> the frequency to a lower frequency in case of idle.
>
> For argument's sake, let's assume that the governor
On 08-11-16, 21:25, Stratos Karafotis wrote:
> But this is the supposed behaviour of conservative governor. We want
> the CPU to increase the frequency in steps. The patch just resets
> the frequency to a lower frequency in case of idle.
>
> For argument's sake, let's assume that the governor
frequency-info currently rounds the frequnecy values to 2 decimal places
while printing "available frequency steps". Hence frequencies with 3rd
decimal place being greater than 5 will be rounded to next higher number
like 2.227GHz will be rounded to 2.23Ghz. On setting this frequency,
using
frequency-info currently rounds the frequnecy values to 2 decimal places
while printing "available frequency steps". Hence frequencies with 3rd
decimal place being greater than 5 will be rounded to next higher number
like 2.227GHz will be rounded to 2.23Ghz. On setting this frequency,
using
On Wed, Nov 09, 2016 at 01:32:04PM +1100, Balbir Singh wrote:
> On 08/11/16 10:31, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> > with feedbacks for ver.1.
> >
> > General description (no change since ver.1)
> >
On Wed, Nov 09, 2016 at 01:32:04PM +1100, Balbir Singh wrote:
> On 08/11/16 10:31, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> > with feedbacks for ver.1.
> >
> > General description (no change since ver.1)
> >
On 11/08/2016 01:18 AM, Benjamin Gaignard wrote:
> Ok so no more dev on ION but can we add ION drivers like hisilicon does ?
>
If we can agree upon bindings, yes I think it would make sense
to have more platform support. Ideally, it would translate over
to newer features as well.
Thanks,
Laura
On 11/08/2016 01:18 AM, Benjamin Gaignard wrote:
> Ok so no more dev on ION but can we add ION drivers like hisilicon does ?
>
If we can agree upon bindings, yes I think it would make sense
to have more platform support. Ideally, it would translate over
to newer features as well.
Thanks,
Laura
Hi all,
Changes since 20161108:
The drm-misc tree gained a build failure, so I used the version from
next-20161108.
The sound-asoc tree still had its build failure, so I used the version
from next-20161028.
The scsi-mkp tree gained conflicts against the block and scsi trees.
The rtc tree lost
Hi all,
Changes since 20161108:
The drm-misc tree gained a build failure, so I used the version from
next-20161108.
The sound-asoc tree still had its build failure, so I used the version
from next-20161028.
The scsi-mkp tree gained conflicts against the block and scsi trees.
The rtc tree lost
On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
This series adds support for automatic interrupt assignment to devices
that have a few vectors that are set aside for admin or config purposes
and thus should not fall into the general per-cpu assginment pool.
The first patch adds that support to
On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
This series adds support for automatic interrupt assignment to devices
that have a few vectors that are set aside for admin or config purposes
and thus should not fall into the general per-cpu assginment pool.
The first patch adds that support to
The denali->fwblks is set by detect_partition_feature(), but it is
not referenced from anywhere. That means the struct member fwblks
and the whole of detect_partition_feature() are unneeded.
The comment block implies this function is only for Intel platforms.
I found drivers/staging/spectra used
The denali->fwblks is set by detect_partition_feature(), but it is
not referenced from anywhere. That means the struct member fwblks
and the whole of detect_partition_feature() are unneeded.
The comment block implies this function is only for Intel platforms.
I found drivers/staging/spectra used
The driver calls devm_kzalloc()/devm_kfree() to allocate/free memory.
They are declared in , not in .
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 1 -
drivers/mtd/nand/denali_dt.c | 1 -
drivers/mtd/nand/denali_pci.c | 1 -
3 files
The struct member "idx" was used as an index for debug_array long
ago, but the DEBUG_DENALI feature was removed by commit 7cfffac06ca0
("nand/denali: use dev_xx debug function to replace nand_dbg_print
and some printk"). Since then, this has been only initialized, but
never referenced.
The driver calls devm_kzalloc()/devm_kfree() to allocate/free memory.
They are declared in , not in .
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 1 -
drivers/mtd/nand/denali_dt.c | 1 -
drivers/mtd/nand/denali_pci.c | 1 -
3 files changed, 3 deletions(-)
diff --git
The struct member "idx" was used as an index for debug_array long
ago, but the DEBUG_DENALI feature was removed by commit 7cfffac06ca0
("nand/denali: use dev_xx debug function to replace nand_dbg_print
and some printk"). Since then, this has been only initialized, but
never referenced.
The interrupt handler is setup in denali_init(), not in
denali_drv_init(). This comment is false.
Such a comment adds no value, so just delete it instead of move.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 1 -
1 file changed, 1 deletion(-)
The interrupt handler is setup in denali_init(), not in
denali_drv_init(). This comment is false.
Such a comment adds no value, so just delete it instead of move.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 1 -
1 file changed, 1 deletion(-)
diff --git
I am tackling on this driver to use it for my SoCs.
The difficulty is a bunch of platform specific stuff
(more specifically, Intel MRST specific) is hard-coded in this driver.
I need lots of rework to utilize the driver for generic cases,
but at the same time, I found the driver code is really
As far as I understood from the Kconfig menu deleted by commit
be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
specific to Intel Moorestown Platform.
The Denali NAND controller IP is used for various SoCs such as
Altera SOCFPGA, Socionext UniPhier, etc. The platform specific
The denali->blksperchip is set, but not referenced any more. The
denali->totalblks is used only for calculating denali->blksperchip.
Both of them are unneeded.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 8
drivers/mtd/nand/denali.h |
I am tackling on this driver to use it for my SoCs.
The difficulty is a bunch of platform specific stuff
(more specifically, Intel MRST specific) is hard-coded in this driver.
I need lots of rework to utilize the driver for generic cases,
but at the same time, I found the driver code is really
As far as I understood from the Kconfig menu deleted by commit
be7f39c5ecf5 ("Staging: delete spectra driver"), the "Spectra" is
specific to Intel Moorestown Platform.
The Denali NAND controller IP is used for various SoCs such as
Altera SOCFPGA, Socionext UniPhier, etc. The platform specific
The denali->blksperchip is set, but not referenced any more. The
denali->totalblks is used only for calculating denali->blksperchip.
Both of them are unneeded.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 8
drivers/mtd/nand/denali.h | 2 --
2 files changed, 10
The devm_request_irq() returns an appropriate error value when it
fails. Use it instead of the fixed -ENODEV.
While we are here, reword the comment to make it fit in a single
line, fixing the misspelling of "initialization".
Signed-off-by: Masahiro Yamada
---
Remove parentheses surrounding the whole right side of an assignment.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/denali.c
The nand_scan_ident/tail() returns an appropriate error value when
it fails. Use it instead of the fixed -ENXIO.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
Such debug lines might be useful when debugging the driver first,
but should be deleted from the upstream code.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/mtd/nand/denali.c
The devm_request_irq() returns an appropriate error value when it
fails. Use it instead of the fixed -ENODEV.
While we are here, reword the comment to make it fit in a single
line, fixing the misspelling of "initialization".
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 12
Remove parentheses surrounding the whole right side of an assignment.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index d482d8d..14e66ab
The nand_scan_ident/tail() returns an appropriate error value when
it fails. Use it instead of the fixed -ENXIO.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/denali.c
Such debug lines might be useful when debugging the driver first,
but should be deleted from the upstream code.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
Use the managed variant instead of request_irq() and free_irq().
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index
Use the managed variant instead of request_irq() and free_irq().
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/denali.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 548278b..44e075a 100644
---
On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
>
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so
On Tue, 2016-11-08 at 07:34 -0800, Andy Lutomirski wrote:
> > Would it not be better to emulate these instructions for them? What
> way
> > we can verify they're not malicious.
>
> Forget malice -- if they are really needed for some silly vm86-using
> program, let's trap them and emulate them so
On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
If these are backwards compatible, just mark them as compatible in DT,
e.g. hip06 can use
compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
If these are backwards compatible, just mark them as compatible in DT,
e.g. hip06 can use
compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
On Tue, 2016-11-08 at 18:00 +0100, Peter Zijlstra wrote:
> > > + }
> > > +#endif
> > > +
> >
> > NAK. If this code is going to exist, it needs to be deeply buried
> in
> > some unlikely if statement that already exists. There's no good
> > reason to penalize all context switches to
On Tue, 2016-11-08 at 18:00 +0100, Peter Zijlstra wrote:
> > > + }
> > > +#endif
> > > +
> >
> > NAK. If this code is going to exist, it needs to be deeply buried
> in
> > some unlikely if statement that already exists. There's no good
> > reason to penalize all context switches to
1 - 100 of 1918 matches
Mail list logo