Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker()

[SF Markus Elfring]

>> Move the jump label directly before the desired log statement
>> so that the variable "err" will not be checked once more
>> after it was determined that a function call failed.
>> Use the identifier "report_failure" instead of the label "err".
> 
>Why?

I suggest to reconsider the places with which such a jump label
is connected.


> The code was smart enough

Which action should really be performed after a failure was detected
and handled a bit already?

* Another condition check

* Just additional error logging


> and you're making it uglier that it needs to be.

I assume that a software development taste can evolve, can't it?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net-libertas: Better exception handling in if_spi_host_to_card_worker()

[Julia Lawall]

On Sat, 2 Jan 2016, SF Markus Elfring wrote:

> >> Move the jump label directly before the desired log statement
> >> so that the variable "err" will not be checked once more
> >> after it was determined that a function call failed.
> >> Use the identifier "report_failure" instead of the label "err".
> > 
> >Why?
> 
> I suggest to reconsider the places with which such a jump label
> is connected.
> 
> 
> > The code was smart enough
> 
> Which action should really be performed after a failure was detected
> and handled a bit already?
> 
> * Another condition check
> 
> * Just additional error logging
> 
> 
> > and you're making it uglier that it needs to be.
> 
> I assume that a software development taste can evolve, can't it?

So far, you have gotten several down votes for this kind of change, and no 
enthusiasm.

Admittedly, this is a trivial case, because there are no local variables, 
but do you actually know the semantics in C of a jump into a block?  And 
if you do know, do you think that this semantics is common knowledge?  And 
do you really think that introducing poorly understandable code is really 
worth saving an if test of a single variable on a non-critical path?

Most of the kernel code is not performance critical at the level of a 
single if test.  So the goal should be for the code to be easy to 
understand and robust to change.  The code that is performance critical, 
you should probably not touch, ever.  The people who wrote it knew what 
was important and what was not.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net-brcmfmac: Delete an unnecessary variable initialisation in brcmf_sdio_download_firmware()

[Arend van Spriel]

On 01/01/2016 08:26 PM, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Fri, 1 Jan 2016 20:20:15 +0100


I think it has been said over and over, but please use driver name only 
as prefix. I don't see value to prepend it with 'net-'.



Omit explicit initialisation at the beginning for one local variable
that is redefined before its first use.



That being said here is my

Acked-by: Arend van Spriel 

Signed-off-by: Markus Elfring 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index ceb2a75..c21eeb1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3260,7 +3260,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio 
*bus,
const struct firmware *fw,
void *nvram, u32 nvlen)
  {
-   int bcmerror = -EFAULT;
+   int bcmerror;
u32 rstvec;

sdio_claim_host(bus->sdiodev->func[1]);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

[SF Markus Elfring]

>> I assume that a software development taste can evolve, can't it?
> 
> So far, you have gotten several down votes for this kind of change,

I am curious when more contributors will share corresponding opinions.


> and no enthusiasm.

How many software designers and developers can become enthusiastic
about better exception handling to some degree?


> The code that is performance critical, you should probably not touch, ever.

I imagine that technical evolution will result in further considerations
so that "unchangeable" components can be adjusted once more.


> The people who wrote it knew what was important and what was not.

I might come along at some places where the affected knowledge will also evolve.

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 RESEND 0/2] WM8505/WM8650 DT fixes for SD card controller

[Roman Volkov]

В Fri, 01 Jan 2016 22:53:33 +0100
Arnd Bergmann  пишет:

> On Friday 01 January 2016 20:32:30 Roman Volkov wrote:
> > > Applied both to next/dt, thanks a lot for following up!
> > > 
> > > Let me know if you think this should go into stable backports as
> > > well, I did not apply it to the fixes branch as you don't have a
> > > 'Cc: sta...@vger.kernel.org' tag and it has never worked so far.  
> > 
> > Yes, this must go into the stable too. Let me know if I must change
> > something or resend.  
> 
> I can put them in the fixes branch with the appropriate stable
> tag myself, but please clarify whether we need just the first or
> both patches there. It looks to me that the second one while
> correct only addresses a cosmetic problem and everything works
> without it.

Correct, everything works without the second one. One of reviewers
noticed that addresses are different between WM8505 and WM8650 where
the hardware is the same. If such trivial changes are not accepted,
please do not apply.

Happy New Year,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] crypto: af_alg - Disallow bind/setkey/... after accept(2)

[Stephan Mueller]

Am Freitag, 1. Januar 2016, 21:12:40 schrieb Stephan Mueller:

Hi Herbert,

> Am Mittwoch, 30. Dezember 2015, 11:47:53 schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Tue, Dec 29, 2015 at 07:36:14PM +0100, Dmitry Vyukov wrote:
> > > Hello,
> > > 
> > > On commit 8513342170278468bac126640a5d2d12ffbff106
> > > + crypto: algif_skcipher - Use new skcipher interface
> > > + crypto: algif_skcipher - Require setkey before accept(2)
> > > + crypto: af_alg - Disallow bind/setkey/... after accept(2)
> > 
> > OK there is a silly bug in the last patch.  Here is an updated
> > version.
> 
> With this patch, the AF_ALG interface stops working. I tested the HMAC
> operation and I am unable to set the key with the following call:
> 
> ret = setsockopt(handle->tfmfd, SOL_ALG, ALG_SET_KEY, key, keylen);
> 
> This call returns EBUSY.

Please disregard my email. I did not update my library to the newly requested 
order of performing the setkey before the accept call. After the update of my 
library I can confirm that the modification works for all AF_ALG interfaces.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI / OSL: Add kerneldoc comments to memory mapping functions

[Mathias Krause]

On 2 January 2016 at 03:10, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> Add kerneldoc comments to acpi_os_map_iomem() and acpi_os_unmap_iomem()
> and explain why the latter needs the __ref annotation in one of them
> (as suggested by Mathias Krause).
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/acpi/osl.c |   27 +++
>  1 file changed, 27 insertions(+)
>
> Index: linux-pm/drivers/acpi/osl.c
> ===
> --- linux-pm.orig/drivers/acpi/osl.c
> +++ linux-pm/drivers/acpi/osl.c
> @@ -366,6 +366,19 @@ static void acpi_unmap(acpi_physical_add
> iounmap(vaddr);
>  }
>
> +/**
> + * acpi_os_map_iomem - Get a virtual address for a given physical address 
> range.
> + * @phys: Start of the physical address range to map.
> + * @size: Size of the physical address range to map.
> + *
> + * Look up the given physical address range in the list of existing ACPI 
> memory
> + * mappings.  If found, get a reference to it and return a pointer to it (its
> + * virtual address).  If not found, map it, add it to that list and return a
> + * pointer to it.
> + *
> + * During early init (when acpi_gbl_permanent_mmap has not been set yet) this
> + * routine simply calls __acpi_map_table() to get the job done.
> + */
>  void __iomem *__init_refok
>  acpi_os_map_iomem(acpi_physical_address phys, acpi_size size)
>  {
> @@ -441,6 +454,20 @@ static void acpi_os_map_cleanup(struct a
> }
>  }
>
> +/**
> + * acpi_os_unmap_iomem - Drop a memory mapping reference.
> + * @virt: Start of the address range to drop a reference to.
> + * @size: Size of the address range to drop a reference to.
> + *
> + * Look up the given virtual address range in the list of existing ACPI 
> memory
> + * mappings, drop a reference to it and unmap it if there are no more active
> + * references to it.
> + *
> + * During early init (when acpi_gbl_permanent_mmap has not been set yet) this
> + * routine simply calls __acpi_unmap_table() to get the job done.  Since
> + * __acpi_unmap_table() is an __init function, the __ref annotation is needed
> + * here.
> + */
>  void __ref acpi_os_unmap_iomem(void __iomem *virt, acpi_size size)
>  {
> struct acpi_ioremap *map;
>

Looks much better than my two-liner comment!

Acked-by: Mathias Krause 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

[Arend van Spriel]

On 02-01-16 10:08, SF Markus Elfring wrote:
>>> I assume that a software development taste can evolve, can't it?
>>
>> So far, you have gotten several down votes for this kind of change,
> 
> I am curious when more contributors will share corresponding opinions.

Let's burn some cycles on this while the holidays give me time to do so.
"software development taste" is another term for "coding style". In
every project battles are fought over this between friends and foes. I
have never seen much evolution going on in this area.

>> and no enthusiasm.
> 
> How many software designers and developers can become enthusiastic
> about better exception handling to some degree?

I had to  take a look at this particular patch and I have to say that I
don't see, using your favorite term, evolution at work. It looks more
like the result of inbred. What the patch tries to do is avoid the extra
'if (err)'. Setting coding style aside, the question is whether there is
a good metric for the patch. So does it really safe processing time? Did
you look at the resulting assembly code for different target architectures?

You got pushed back on the change so you have to come up with solid
arguments for your change instead of spewing ideas about evolution in
software development. Running Coccinelle is one thing, but understanding
the results and what you are ultimately proposing to be changed is more
important.

Regards,
Arend

>> The code that is performance critical, you should probably not touch, ever.
> 
> I imagine that technical evolution will result in further considerations
> so that "unchangeable" components can be adjusted once more.
> 
> 
>> The people who wrote it knew what was important and what was not.
> 
> I might come along at some places where the affected knowledge will also 
> evolve.
> 
> Regards,
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] nbd: Timeouts are not user requested disconnects

[Markus Pargmann]

It may be useful to know in the client that a connection timed out. The
current code returns success for a timeout.

This patch reports the error code -ETIMEDOUT for a timeout.

Signed-off-by: Markus Pargmann 
---
 drivers/block/nbd.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 88762f640527..0ba3149c48bb 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -57,6 +57,7 @@ struct nbd_device {
int blksize;
loff_t bytesize;
int xmit_timeout;
+   bool timedout;
bool disconnect; /* a disconnect has been requested by user */
 
struct timer_list timeout_timer;
@@ -154,10 +155,9 @@ static void nbd_xmit_timeout(unsigned long arg)
if (list_empty(&nbd->queue_head))
return;
 
-   nbd->disconnect = true;
-
spin_lock_irqsave(&nbd->sock_lock, flags);
 
+   nbd->timedout = true;
 
if (nbd->sock)
kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
@@ -754,7 +754,10 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
nbd_device *nbd,
if (max_part > 0)
blkdev_reread_part(bdev);
if (nbd->disconnect) /* user requested, ignore socket errors */
-   return 0;
+   error = 0;
+   if (nbd->timedout)
+   error = -ETIMEDOUT;
+
return error;
}
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PULL] NBD changes

[Markus Pargmann]

Hi Jens,

This pull request contains 5 patches which are mainly cleanups.

Patch 1 fixes some unnecessarily complicated code I introduced some versions
ago for debugfs.

Patch 2 removes the criticised signal usage within NBD to kill the NBD threads
after a timeout. This code was used for the last years and is now replaced by
simply killing the tcp connection.

Patches 3-5 are some smaller cleanups.

Happy new year.

Best Regards,

Markus



The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://git.pengutronix.de/git/mpa/linux-nbd.git tags/nbd-for-4.5

for you to fetch changes up to e0f2a340a69db6c70e60bb55c96a75cf0268c9d7:

  nbd: Move flag parsing to a function (2015-11-16 14:44:11 +0100)


NBD for v4.5


Markus Pargmann (5):
  nbd: Fix debugfs error handling
  nbd: Remove signal usage
  nbd: Timeouts are not user requested disconnects
  nbd: Cleanup reset of nbd and bdev after a disconnect
  nbd: Move flag parsing to a function

 drivers/block/nbd.c | 258 +++-
 1 file changed, 114 insertions(+), 144 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] nbd: Move flag parsing to a function

[Markus Pargmann]

nbd changes properties of the blockdevice depending on flags that were
received. This patch moves this flag parsing into a separate function
nbd_parse_flags().

Signed-off-by: Markus Pargmann 
---
 drivers/block/nbd.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index a1fa356e4cbf..81a9be7d176c 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -641,6 +641,18 @@ static void nbd_bdev_reset(struct block_device *bdev)
}
 }
 
+static void nbd_parse_flags(struct nbd_device *nbd, struct block_device *bdev)
+{
+   if (nbd->flags & NBD_FLAG_READ_ONLY)
+   set_device_ro(bdev, true);
+   if (nbd->flags & NBD_FLAG_SEND_TRIM)
+   queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
+   if (nbd->flags & NBD_FLAG_SEND_FLUSH)
+   blk_queue_flush(nbd->disk->queue, REQ_FLUSH);
+   else
+   blk_queue_flush(nbd->disk->queue, 0);
+}
+
 static int nbd_dev_dbg_init(struct nbd_device *nbd);
 static void nbd_dev_dbg_close(struct nbd_device *nbd);
 
@@ -742,15 +754,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
nbd_device *nbd,
 
mutex_unlock(&nbd->tx_lock);
 
-   if (nbd->flags & NBD_FLAG_READ_ONLY)
-   set_device_ro(bdev, true);
-   if (nbd->flags & NBD_FLAG_SEND_TRIM)
-   queue_flag_set_unlocked(QUEUE_FLAG_DISCARD,
-   nbd->disk->queue);
-   if (nbd->flags & NBD_FLAG_SEND_FLUSH)
-   blk_queue_flush(nbd->disk->queue, REQ_FLUSH);
-   else
-   blk_queue_flush(nbd->disk->queue, 0);
+   nbd_parse_flags(nbd, bdev);
 
thread = kthread_run(nbd_thread_send, nbd, "%s",
 nbd_name(nbd));
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] nbd: Fix debugfs error handling

[Markus Pargmann]

Static checker complains about the implemented error handling. It is
indeed wrong. We don't care about the return values of created debugfs
files.

We only have to check the return values of created dirs for NULL
pointer. If we use a null pointer as parent directory for files, this
may lead to debugfs files in wrong places.

Signed-off-by: Markus Pargmann 
---
 drivers/block/nbd.c | 61 -
 1 file changed, 18 insertions(+), 43 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 93b3f99b6865..b9e4179a950a 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -891,57 +891,31 @@ static const struct file_operations nbd_dbg_flags_ops = {
 static int nbd_dev_dbg_init(struct nbd_device *nbd)
 {
struct dentry *dir;
-   struct dentry *f;
+
+   if (!nbd_dbg_dir)
+   return -EIO;
 
dir = debugfs_create_dir(nbd_name(nbd), nbd_dbg_dir);
-   if (IS_ERR_OR_NULL(dir)) {
-   dev_err(nbd_to_dev(nbd), "Failed to create debugfs dir for '%s' 
(%ld)\n",
-   nbd_name(nbd), PTR_ERR(dir));
-   return PTR_ERR(dir);
+   if (!dir) {
+   dev_err(nbd_to_dev(nbd), "Failed to create debugfs dir for 
'%s'\n",
+   nbd_name(nbd));
+   return -EIO;
}
nbd->dbg_dir = dir;
 
-   f = debugfs_create_file("tasks", 0444, dir, nbd, &nbd_dbg_tasks_ops);
-   if (IS_ERR_OR_NULL(f)) {
-   dev_err(nbd_to_dev(nbd), "Failed to create debugfs file 
'tasks', %ld\n",
-   PTR_ERR(f));
-   return PTR_ERR(f);
-   }
-
-   f = debugfs_create_u64("size_bytes", 0444, dir, &nbd->bytesize);
-   if (IS_ERR_OR_NULL(f)) {
-   dev_err(nbd_to_dev(nbd), "Failed to create debugfs file 
'size_bytes', %ld\n",
-   PTR_ERR(f));
-   return PTR_ERR(f);
-   }
-
-   f = debugfs_create_u32("timeout", 0444, dir, &nbd->xmit_timeout);
-   if (IS_ERR_OR_NULL(f)) {
-   dev_err(nbd_to_dev(nbd), "Failed to create debugfs file 
'timeout', %ld\n",
-   PTR_ERR(f));
-   return PTR_ERR(f);
-   }
-
-   f = debugfs_create_u32("blocksize", 0444, dir, &nbd->blksize);
-   if (IS_ERR_OR_NULL(f)) {
-   dev_err(nbd_to_dev(nbd), "Failed to create debugfs file 
'blocksize', %ld\n",
-   PTR_ERR(f));
-   return PTR_ERR(f);
-   }
-
-   f = debugfs_create_file("flags", 0444, dir, &nbd, &nbd_dbg_flags_ops);
-   if (IS_ERR_OR_NULL(f)) {
-   dev_err(nbd_to_dev(nbd), "Failed to create debugfs file 
'flags', %ld\n",
-   PTR_ERR(f));
-   return PTR_ERR(f);
-   }
+   debugfs_create_file("tasks", 0444, dir, nbd, &nbd_dbg_tasks_ops);
+   debugfs_create_u64("size_bytes", 0444, dir, &nbd->bytesize);
+   debugfs_create_u32("timeout", 0444, dir, &nbd->xmit_timeout);
+   debugfs_create_u32("blocksize", 0444, dir, &nbd->blksize);
+   debugfs_create_file("flags", 0444, dir, &nbd, &nbd_dbg_flags_ops);
 
return 0;
 }
 
 static void nbd_dev_dbg_close(struct nbd_device *nbd)
 {
-   debugfs_remove_recursive(nbd->dbg_dir);
+   if (nbd->dbg_dir)
+   debugfs_remove_recursive(nbd->dbg_dir);
 }
 
 static int nbd_dbg_init(void)
@@ -949,8 +923,8 @@ static int nbd_dbg_init(void)
struct dentry *dbg_dir;
 
dbg_dir = debugfs_create_dir("nbd", NULL);
-   if (IS_ERR(dbg_dir))
-   return PTR_ERR(dbg_dir);
+   if (!dbg_dir)
+   return -EIO;
 
nbd_dbg_dir = dbg_dir;
 
@@ -959,7 +933,8 @@ static int nbd_dbg_init(void)
 
 static void nbd_dbg_close(void)
 {
-   debugfs_remove_recursive(nbd_dbg_dir);
+   if (nbd_dbg_dir)
+   debugfs_remove_recursive(nbd_dbg_dir);
 }
 
 #else  /* IS_ENABLED(CONFIG_DEBUG_FS) */
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] nbd: Cleanup reset of nbd and bdev after a disconnect

[Markus Pargmann]

Group all variables that are reset after a disconnect into reset
functions. This patch adds two of these functions, nbd_reset() and
nbd_bdev_reset().

Signed-off-by: Markus Pargmann 
---
 drivers/block/nbd.c | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 0ba3149c48bb..a1fa356e4cbf 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -617,6 +617,30 @@ out:
return ret;
 }
 
+/* Reset all properties of an NBD device */
+static void nbd_reset(struct nbd_device *nbd)
+{
+   nbd->disconnect = false;
+   nbd->timedout = false;
+   nbd->blksize = 1024;
+   nbd->bytesize = 0;
+   set_capacity(nbd->disk, 0);
+   nbd->flags = 0;
+   nbd->xmit_timeout = 0;
+   queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
+   del_timer_sync(&nbd->timeout_timer);
+}
+
+static void nbd_bdev_reset(struct block_device *bdev)
+{
+   set_device_ro(bdev, false);
+   bdev->bd_inode->i_size = 0;
+   if (max_part > 0) {
+   blkdev_reread_part(bdev);
+   bdev->bd_invalidated = 1;
+   }
+}
+
 static int nbd_dev_dbg_init(struct nbd_device *nbd);
 static void nbd_dev_dbg_close(struct nbd_device *nbd);
 
@@ -745,19 +769,15 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
nbd_device *nbd,
sock_shutdown(nbd);
nbd_clear_que(nbd);
kill_bdev(bdev);
-   queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
-   set_device_ro(bdev, false);
-   nbd->flags = 0;
-   nbd->bytesize = 0;
-   bdev->bd_inode->i_size = 0;
-   set_capacity(nbd->disk, 0);
-   if (max_part > 0)
-   blkdev_reread_part(bdev);
+   nbd_bdev_reset(bdev);
+
if (nbd->disconnect) /* user requested, ignore socket errors */
error = 0;
if (nbd->timedout)
error = -ETIMEDOUT;
 
+   nbd_reset(nbd);
+
return error;
}
 
@@ -1024,14 +1044,12 @@ static int __init nbd_init(void)
nbd_dev[i].timeout_timer.data = (unsigned long)&nbd_dev[i];
init_waitqueue_head(&nbd_dev[i].active_wq);
init_waitqueue_head(&nbd_dev[i].waiting_wq);
-   nbd_dev[i].blksize = 1024;
-   nbd_dev[i].bytesize = 0;
disk->major = NBD_MAJOR;
disk->first_minor = i << part_shift;
disk->fops = &nbd_fops;
disk->private_data = &nbd_dev[i];
sprintf(disk->disk_name, "nbd%d", i);
-   set_capacity(disk, 0);
+   nbd_reset(&nbd_dev[i]);
add_disk(disk);
}
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] nbd: Remove signal usage

[Markus Pargmann]

As discussed on the mailing list, the usage of signals for timeout
handling has a lot of potential issues. The nbd driver used for some
time signals for timeouts. These signals where able to get the threads
out of the blocking socket operations.

This patch removes all signal usage and uses a socket shutdown instead.
The socket descriptor itself is cleared later when the whole nbd device
is closed.

The tasks_lock is removed as we do not depend on this anymore. Instead
a new lock for the socket is introduced so we can safely work with the
socket in the timeout handler outside of the two main threads.

Cc: Oleg Nesterov 
Cc: Christoph Hellwig 
Signed-off-by: Markus Pargmann 
---
 drivers/block/nbd.c | 126 
 1 file changed, 48 insertions(+), 78 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b9e4179a950a..88762f640527 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -60,7 +60,8 @@ struct nbd_device {
bool disconnect; /* a disconnect has been requested by user */
 
struct timer_list timeout_timer;
-   spinlock_t tasks_lock;
+   /* protects initialization and shutdown of the socket */
+   spinlock_t sock_lock;
struct task_struct *task_recv;
struct task_struct *task_send;
 
@@ -129,13 +130,20 @@ static void nbd_end_request(struct nbd_device *nbd, 
struct request *req)
  */
 static void sock_shutdown(struct nbd_device *nbd)
 {
-   if (!nbd->sock)
+   spin_lock_irq(&nbd->sock_lock);
+
+   if (!nbd->sock) {
+   spin_unlock_irq(&nbd->sock_lock);
return;
+   }
 
dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
+   sockfd_put(nbd->sock);
nbd->sock = NULL;
-   del_timer_sync(&nbd->timeout_timer);
+   spin_unlock_irq(&nbd->sock_lock);
+
+   del_timer(&nbd->timeout_timer);
 }
 
 static void nbd_xmit_timeout(unsigned long arg)
@@ -148,17 +156,15 @@ static void nbd_xmit_timeout(unsigned long arg)
 
nbd->disconnect = true;
 
-   spin_lock_irqsave(&nbd->tasks_lock, flags);
+   spin_lock_irqsave(&nbd->sock_lock, flags);
 
-   if (nbd->task_recv)
-   force_sig(SIGKILL, nbd->task_recv);
 
-   if (nbd->task_send)
-   force_sig(SIGKILL, nbd->task_send);
+   if (nbd->sock)
+   kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
 
-   spin_unlock_irqrestore(&nbd->tasks_lock, flags);
+   spin_unlock_irqrestore(&nbd->sock_lock, flags);
 
-   dev_err(nbd_to_dev(nbd), "Connection timed out, killed receiver and 
sender, shutting down connection\n");
+   dev_err(nbd_to_dev(nbd), "Connection timed out, shutting down 
connection\n");
 }
 
 /*
@@ -171,7 +177,6 @@ static int sock_xmit(struct nbd_device *nbd, int send, void 
*buf, int size,
int result;
struct msghdr msg;
struct kvec iov;
-   sigset_t blocked, oldset;
unsigned long pflags = current->flags;
 
if (unlikely(!sock)) {
@@ -181,11 +186,6 @@ static int sock_xmit(struct nbd_device *nbd, int send, 
void *buf, int size,
return -EINVAL;
}
 
-   /* Allow interception of SIGKILL only
-* Don't allow other signals to interrupt the transmission */
-   siginitsetinv(&blocked, sigmask(SIGKILL));
-   sigprocmask(SIG_SETMASK, &blocked, &oldset);
-
current->flags |= PF_MEMALLOC;
do {
sock->sk->sk_allocation = GFP_NOIO | __GFP_MEMALLOC;
@@ -212,7 +212,6 @@ static int sock_xmit(struct nbd_device *nbd, int send, void 
*buf, int size,
buf += result;
} while (size > 0);
 
-   sigprocmask(SIG_SETMASK, &oldset, NULL);
tsk_restore_flags(current, pflags, PF_MEMALLOC);
 
if (!send && nbd->xmit_timeout)
@@ -406,23 +405,18 @@ static int nbd_thread_recv(struct nbd_device *nbd)
 {
struct request *req;
int ret;
-   unsigned long flags;
 
BUG_ON(nbd->magic != NBD_MAGIC);
 
sk_set_memalloc(nbd->sock->sk);
 
-   spin_lock_irqsave(&nbd->tasks_lock, flags);
nbd->task_recv = current;
-   spin_unlock_irqrestore(&nbd->tasks_lock, flags);
 
ret = device_create_file(disk_to_dev(nbd->disk), &pid_attr);
if (ret) {
dev_err(disk_to_dev(nbd->disk), "device_create_file failed!\n");
 
-   spin_lock_irqsave(&nbd->tasks_lock, flags);
nbd->task_recv = NULL;
-   spin_unlock_irqrestore(&nbd->tasks_lock, flags);
 
return ret;
}
@@ -439,19 +433,7 @@ static int nbd_thread_recv(struct nbd_device *nbd)
 
device_remove_file(disk_to_dev(nbd->disk), &pid_attr);
 
-   spin_lock_irqsave(&nbd->tasks_lock, flags);
nbd->task_recv = NULL;
-   spin_unlock_irqrestore(&nbd->tasks_lock, flags);
-
-   if (signal_pending(current)) {
-   ret = kernel_dequeue_signal(NU

Re: [PATCH 2/4] irqchip: bcm2836: Add SMP support for the 2836

[Russell King - ARM Linux]

On Sat, Dec 26, 2015 at 01:47:22PM -0800, Eric Anholt wrote:
> +int __init bcm2836_smp_boot_secondary(unsigned int cpu,
> +   struct task_struct *idle)
> +{
> + unsigned long secondary_startup_phys =
> + (unsigned long)virt_to_phys((void *)secondary_startup);
> +
> + dsb();
> + writel(secondary_startup_phys,
> +intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);

Please explain why you need this dsb() - I can't see a reason for it.
writel() has a barrier internally prior to writing the register, and
therefore I think the above dsb() is entirely redundant.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: kernel: utilize hrtimer based broadcast

[Russell King - ARM Linux]

On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> On Mon, 28 Dec 2015, Arnd Bergmann wrote:
> 
> > On Monday 28 December 2015 07:18:58 Huan Wang wrote:
> > > Hi, Arnd,
> > > 
> > >   Could you help to review the following patch? Thanks.
> > > 
> > 
> > Hi Alison,
> > 
> > I'm sorry but I understand very little of this particular area of the 
> > kernel.
> > 
> > I've added Daniel Lezcano, John Stultz and Thomas Gleixner to Cc, they all
> > know this much better than I do and one of them should be able to comment 
> > after
> > their Christmas break.
> 
> I have no real opinion about that patch. It does no harm to unconditionally
> setup the hrtimer based broadcast even if it's never used.
> 
> Up to the arch maintainer to decide. 

That's really not fair to keep shovelling these kinds of decisions onto
architecture maintainers without any kind of explanation about how an
architecture maintainer should make such a decision.

Do I roll a 6-face dice, and if it gives an odd number, I apply this
patch, otherwise I reject it?

Is there a technical basis for making the decision?  If so, please
explain what the technical arguments are against having or not having
this change.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Question about DMA] Consistent memory?

[Russell King - ARM Linux]

On Thu, Dec 31, 2015 at 04:50:54PM +0900, Masahiro Yamada wrote:
> Hi.
> 
> I am new to the Linux DMA APIs.
> 
> First, I started by reading Documentation/DMA-API.txt,
> but I am confused with the term "consistent memory".

Just read "coherent memory" instead - the documentation confusingly uses
the two terms to refer to the same thing.  I think there was a patch a
while back to replace "consistent" with "coherent" in this document,
though I'm not sure what happened to it.

I think you have answers to your other points by others in this thread.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Question about DMA] Consistent memory?

[Russell King - ARM Linux]

On Thu, Dec 31, 2015 at 11:57:55PM +0900, Masahiro Yamada wrote:
> [1] DMA-coherent buffers
> 
> Allocate buffers with dma_alloc_coherent()
> and just have access to the buffers without cache synchronization.
> 
> There is no need to call dma_sync_single_for_*().

dma_sync_single_for_*() is part of the streaming API and should never
be used with DMA-coherent buffers.

> [2] Streaming DMA
> 
> Allocate buffers with kmalloc() or friends,
> and then map them for DMA with dma_map_single().
> 
> The buffers are cached, so they are non-consitent
> unless there exists hardware assist such as
> Cache Coherency Interconnect.
> 
> The drivers must invoke cache operations
> by calling dma_sync_single_for_*().

I have a problem with that last statement.  There is no "must".  One
way to look at the DMA API is that you're using the various calls to
transfer ownership (and access right) of the buffer between the CPU
and the DMA device.

So, dma_map_single() transfers ownership from the CPU to the DMA
device, as does dma_sync_single_for_device().  dma_unmap_single()
and dma_sync_single_for_cpu() transfers ownership from the DMA
device to the CPU.

If you intend to allocate a buffer, and then perform DMA on it, you
just need to allocate, use dma_map_single(), and then kick the DMA.
Once DMA has completed, use dma_unmap_single() before touching the
buffer.

If you intend to inspect the contents of the buffer during DMA, then
use dma_sync_single_for_cpu() before reading the buffer.  This
ensures that when you read from the buffer, you see up-to-date data.
You strictly don't need to use dma_sync_single_for_device() prior
to resuming DMA.

However, you must use dma_unmap_single() before you free the memory.

> I think, if the buffer size is small, [1] is more efficient
> because it need not invoke cache operations.
> 
> If the buffer is large, [2] seems better because
> the cost of uncached memory access gets more expensive
> than that of cache operations.

It doesn't always follow.  Coherent memory is only available in page
sized chunks, so aren't really "small buffers".

Generally, coherent memory is used for things like DMA descriptor ring
buffers, where we need simultaneous access by both the DMA device and
CPU (the DMA device updates descriptors as it processes them, the CPU
can inspect and queue new descriptors as the DMA device processes them.)
Network devices do this a lot.

The DMA API streaming interfaces tend to be used with buffers which are
allocated "out of control" of the driver - if we take the network device
example, the network packet buffers will be mapped and unmapped using
the streaming API.

With a different example, video capture, there's different trade offs.
A video capture buffer may be very large (8MB for a 1080p frame.)
Flushing the cache over 8MB of data is very inefficient, and it's
probably more performant to use DMA coherent memory instead, even
more so if you don't actually intend for the CPU to access it - eg,
you're passing the frame to another hardware block for further
processing.

> I grepped under drivers/mmc/host, and
> I found many drivers call dma_alloc_coherent(),
> but there are also some drivers that use dma_map_single().

Yes - you're probably seeing the pattern I mentioned above - DMA
descriptors on coherent memory, the data buffers being passed in
to the driver from elsewhere, and mapped using the streaming API.

Hope this is helpful.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 08/32] arm: reuse asm-generic/barrier.h

[Russell King - ARM Linux]

On Thu, Dec 31, 2015 at 09:06:46PM +0200, Michael S. Tsirkin wrote:
> On arm smp_store_mb, read_barrier_depends, smp_read_barrier_depends,
> smp_store_release, smp_load_acquire, smp_mb__before_atomic and
> smp_mb__after_atomic match the asm-generic variants exactly. Drop the
> local definitions and pull in asm-generic/barrier.h instead.
> 
> This is in preparation to refactoring this code area.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

Thanks, the asm-generic versions looks identical to me, so this should
result in no code generation difference.

Acked-by: Russell King 

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

[SF Markus Elfring]

> I have never seen much evolution going on in this area.

I can get an other impression from a specific document for example.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle


> What the patch tries to do is avoid the extra 'if (err)'.

Yes. - I propose to look at related consequences together with the usage
of a popular short jump label once more.


> Setting coding style aside, the question is whether there is
> a good metric for the patch.

A software development challenge is to accept changes also around a topic
like "error handling". My update suggestion for the source file
"drivers/net/wireless/marvell/libertas/if_spi.c" should only improve
exception handling. (I came along other source files where more improvements
will eventually be possible.)

When will the run-time behaviour matter also for exceptional situations?


> Did you look at the resulting assembly code for different target 
> architectures?

Not yet. - Which execution system variants would you recommend for
further comparisons?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 17/32] arm: define __smp_xxx

[Russell King - ARM Linux]

On Thu, Dec 31, 2015 at 09:07:59PM +0200, Michael S. Tsirkin wrote:
> This defines __smp_xxx barriers for arm,
> for use by virtualization.
> 
> smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
> 
> This reduces the amount of arch-specific boiler-plate code.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

In combination with patch 14, this looks like it should result in no
change to the resulting code.

Acked-by: Russell King 

My only concern is that it gives people an additional handle onto a
"new" set of barriers - just because they're prefixed with __*
unfortunately doesn't stop anyone from using it (been there with
other arch stuff before.)

I wonder whether we should consider making the smp memory barriers
inline functions, so these __smp_xxx() variants can be undef'd
afterwards, thereby preventing drivers getting their hands on these
new macros?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in shm_lock ipc

[Manfred Spraul]

Hi Dmitry,

shm locking differs too much from msg/sem locking, I never looked at it 
in depth, so I'm not able to perform a proper review.


Except for the obvious: Races that can be triggered from user space are 
inacceptable.

Regardless if there is a BUG_ON, a WARN_ON or nothing at all.

On 12/21/2015 04:44 PM, Dmitry Vyukov wrote:

+
+/* This is called by fork, once for every shm attach. */
+static void shm_open(struct vm_area_struct *vma)
+{
+   int err = __shm_open(vma);
+   /*
+* We raced in the idr lookup or with shm_destroy().
+* Either way, the ID is busted.
+*/
+   WARN_ON_ONCE(err);
  }

Is it possible to trigger this race? Parallel IPC_RMID & fork()?

--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] BTRFS: Adds the files and options needed for Hybrid Storage

[Martin Steigerwald]

Hello,

Am Freitag, 1. Januar 2016, 22:08:32 CET schrieb Sanidhya Solanki:
> This patch adds the file required for Hybrid Storage. It contains
> the memory, time and size limits for the cache and the statistics that
> will be provided while the cache is operating.
> It also adds the Makefile changes needed to add the Hybrid Storage.

Is this about what I think it is – using flash as cache for a BTRFS filesystem 
on rotational disk? I ask cause the last time I saw patched regarding they 
consisted of patches to add hot data tracking to VFS and BTRFS to support 
setting up an SSD to use for hot data.

Or is this something different?

Happy New Year and thanks,
Martin

> Signed-off-by: Sanidhya Solanki 
> ---
>  fs/btrfs/Makefile |  2 +-
>  fs/btrfs/cache.c  | 58
> +++ 2 files changed, 59
> insertions(+), 1 deletion(-)
>  create mode 100644 fs/btrfs/cache.c
> 
> diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile
> index 6d1d0b9..dc56ae4 100644
> --- a/fs/btrfs/Makefile
> +++ b/fs/btrfs/Makefile
> @@ -9,7 +9,7 @@ btrfs-y += super.o ctree.o extent-tree.o print-tree.o
> root-tree.o dir-item.o \ export.o tree-log.o free-space-cache.o zlib.o
> lzo.o \
>  compression.o delayed-ref.o relocation.o delayed-inode.o scrub.o \
>  reada.o backref.o ulist.o qgroup.o send.o dev-replace.o raid56.o \
> -uuid-tree.o props.o hash.o
> +uuid-tree.o props.o hash.o cache.o
> 
>  btrfs-$(CONFIG_BTRFS_FS_POSIX_ACL) += acl.o
>  btrfs-$(CONFIG_BTRFS_FS_CHECK_INTEGRITY) += check-integrity.o
> diff --git a/fs/btrfs/cache.c b/fs/btrfs/cache.c
> new file mode 100644
> index 000..0ece7a1
> --- /dev/null
> +++ b/fs/btrfs/cache.c
> @@ -0,0 +1,58 @@
> +/*
> + * (c) Sanidhya Solanki, 2016
> + *
> + * Licensed under the FSF's GNU Public License v2 or later.
> + */
> +#include 
> +
> +/* Cache size configuration )in MiB).*/
> +#define MAX_CACHE_SIZE = 1
> +#define MIN_CACHE_SIZE = 10
> +
> +/* Time (in seconds)before retrying to increase the cache size.*/
> +#define CACHE_RETRY = 10
> +
> +/* Space required to be free (in MiB) before increasing the size of the
> + * cache. If cache size is less than cache_grow_limit, a block will be
> freed + * from the cache to allow the cache to continue growning.
> + */
> +#define CACHE_GROW_LIMIT = 100
> +
> +/* Size required to be free (in MiB) after we shrink the cache, so that it
> + * does not grow in size immediately.
> + */
> +#define CACHE_SHRINK_FREE_SPACE_LIMIT = 100
> +
> +/* Age (in seconds) of oldest and newest block in the cache.*/
> +#define MAX_AGE_LIMIT = 300  /* Five Minute Rule recommendation,
> +  * optimum size depends on size of data
> +  * blocks.
> +  */
> +#define MIN_AGE_LIMIT = 15   /* In case of cache stampede.*/
> +
> +/* Memory constraints (in percentage) before we stop caching.*/
> +#define MIN_MEM_FREE = 10
> +
> +/* Cache statistics. */
> +struct cache_stats {
> + u64 cache_size;
> + u64 maximum_cache_size_attained;
> + int cache_hit_rate;
> + int cache_miss_rate;
> + u64 cache_evicted;
> + u64 duplicate_read;
> + u64 duplicate_write;
> + int stats_update_interval;
> +};
> +
> +#define cache_size   CACHE_SIZE /* Current cache size.*/
> +#define max_cache_size   MAX_SIZE /* Max cache limit. */
> +#define min_cache_size   MIN_SIZE /* Min cache limit.*/
> +#define cache_time   MAX_TIME /* Maximum time to keep data in cache.*/
> +#define evicted_csum EVICTED_CSUM/* Checksum of the evited data
> +  * (to avoid repeatedly caching
> +  * data that was just evicted.
> +  */
> +#define read_csumREAD_CSUM /* Checksum of the read data.*/
> +#define write_csum   WRITE_CSUM /* Checksum of the written data.*/
> +#define evict_interval   EVICT_INTERVAL /* Time to keep data before
> eviction.*/


-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread

[Tejun Heo]

Hello,

On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote:
> > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin
> > suggested using a system one. Tejun Heo confirmed that the system
> > workqueue has a pretty high concurrency level (256) by default.
> > Therefore we need not be afraid of too long blocking.
> 
> Right but fill has a 1/5 second sleep on failure - *that*
> is problematic for a system queue.

Why so?  As long as the maximum concurrently used workers are not
high, 1/5 second or even a lot longer sleeps are completely fine.

> > @@ -563,7 +534,7 @@ static void virtballoon_remove(struct virtio_device 
> > *vdev)
> > struct virtio_balloon *vb = vdev->priv;
> >  
> > unregister_oom_notifier(&vb->nb);
> > -   kthread_stop(vb->thread);
> > +   cancel_work_sync(&vb->wq_work);
> 
> OK but since job requeues itself, cancelling like this might not be enough.

As long as there's no further external queueing, cancel_work_sync() is
guaranteed to kill a self-requeueing work item.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH, RESEND] ipc/shm: handle removed segments gracefully in shm_mmap()

[Manfred Spraul]

On 11/13/2015 08:23 PM, Davidlohr Bueso wrote:


So considering EINVAL, even your approach to bumping up nattach by 
calling
_shm_open earlier isn't enough. Races exposed to user called rmid can 
still
occur between dropping the lock and doing ->mmap(). Ultimately this 
leads to
all ipc_valid_object() checks, as we totally ignore SHM_DEST segments 
nowadays

since we forbid mapping previously removed segments.

I think this is the first thing we must decide before going forward 
with this
mess. ipc currently defines invalid objects by merely checking the 
deleted flag.


Manfred, any thoughts?


With regards to locking: Sorry, shm is too different to msg/sem/mqueue.

With regards to EIDRM / EINVAL:
When all kernel memory was released, then the kernel cannot find out if 
the ID was valid at one time or not.
Thus EIDRM can only be a hint, the OS (kernel/libc) cannot guarantee 
that user space will never see something else.

(trivial example: user space sleeps just before the syscall)

So I would not create special code to optimize EIDRM handling for races. 
If we sometimes report EINVAL, it would be probably ok as well.


--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] nbd: fix ifnullfree.cocci warnings

[kbuild test robot]

drivers/block/nbd.c:937:2-26: WARNING: NULL check before freeing functions like 
kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. 
Maybe consider reorganizing relevant code to avoid passing NULL values.
drivers/block/nbd.c:918:2-26: WARNING: NULL check before freeing functions like 
kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. 
Maybe consider reorganizing relevant code to avoid passing NULL values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Markus Pargmann 
Signed-off-by: Fengguang Wu 
---

 nbd.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -914,8 +914,7 @@ static int nbd_dev_dbg_init(struct nbd_d
 
 static void nbd_dev_dbg_close(struct nbd_device *nbd)
 {
-   if (nbd->dbg_dir)
-   debugfs_remove_recursive(nbd->dbg_dir);
+   debugfs_remove_recursive(nbd->dbg_dir);
 }
 
 static int nbd_dbg_init(void)
@@ -933,8 +932,7 @@ static int nbd_dbg_init(void)
 
 static void nbd_dbg_close(void)
 {
-   if (nbd_dbg_dir)
-   debugfs_remove_recursive(nbd_dbg_dir);
+   debugfs_remove_recursive(nbd_dbg_dir);
 }
 
 #else  /* IS_ENABLED(CONFIG_DEBUG_FS) */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] nbd: Fix debugfs error handling

[kbuild test robot]

Hi Markus,

[auto build test WARNING on block/for-next]
[also build test WARNING on v4.4-rc7 next-20151231]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Markus-Pargmann/nbd-Fix-debugfs-error-handling/20160102-182030
base:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/block/nbd.c:937:2-26: WARNING: NULL check before freeing functions 
>> like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not 
>> needed. Maybe consider reorganizing relevant code to avoid passing NULL 
>> values.
   drivers/block/nbd.c:918:2-26: WARNING: NULL check before freeing functions 
like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not 
needed. Maybe consider reorganizing relevant code to avoid passing NULL values.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

[Milan Broz]

On 12/25/2015 08:40 AM, Herbert Xu wrote:
> Dmitry Vyukov  wrote:
>>
>> I am testing with your two patches:
>> crypto: algif_skcipher - Use new skcipher interface
>> crypto: algif_skcipher - Require setkey before accept(2)
>> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23).
> 
> You sent the email to everyone on the original CC list except me.
> Please don't do that.
> 
>> Now the following program causes a bunch of use-after-frees and them
>> kills kernel:
> 
> Yes there is an obvious bug in the patch that Julia Lawall has
> responded to in another thread.  Here is a fixed version.
> 
> ---8<--
> Some cipher implementations will crash if you try to use them
> without calling setkey first.  This patch adds a check so that
> the accept(2) call will fail with -ENOKEY if setkey hasn't been
> done on the socket yet.


Hi Herbert,

this patch breaks userspace in cryptsetup...

We use algif_skcipher in cryptsetup (for years, even before
there was Stephan's library) and with this patch applied
I see fail in ALG_SET_IV call (patch from your git).

I can fix it upstream, but for thousands of installations it will
be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices
it will be unusable. Also people who configured kernel crypto API as default
backend will have non-working cryptsetup).

Is it really thing for stable branch?

Milan

> 
> Cc: sta...@vger.kernel.org
> Reported-by: Dmitry Vyukov 
> Signed-off-by: Herbert Xu 
> 
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index 5c756b3..f4431bc 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -31,6 +31,11 @@ struct skcipher_sg_list {
>   struct scatterlist sg[0];
>  };
>  
> +struct skcipher_tfm {
> + struct crypto_skcipher *skcipher;
> + bool has_key;
> +};
> +
>  struct skcipher_ctx {
>   struct list_head tsgl;
>   struct af_alg_sgl rsgl;
> @@ -750,17 +755,41 @@ static struct proto_ops algif_skcipher_ops = {
>  
>  static void *skcipher_bind(const char *name, u32 type, u32 mask)
>  {
> - return crypto_alloc_skcipher(name, type, mask);
> + struct skcipher_tfm *tfm;
> + struct crypto_skcipher *skcipher;
> +
> + tfm = kzalloc(sizeof(*tfm), GFP_KERNEL);
> + if (!tfm)
> + return ERR_PTR(-ENOMEM);
> +
> + skcipher = crypto_alloc_skcipher(name, type, mask);
> + if (IS_ERR(skcipher)) {
> + kfree(tfm);
> + return ERR_CAST(skcipher);
> + }
> +
> + tfm->skcipher = skcipher;
> +
> + return tfm;
>  }
>  
>  static void skcipher_release(void *private)
>  {
> - crypto_free_skcipher(private);
> + struct skcipher_tfm *tfm = private;
> +
> + crypto_free_skcipher(tfm->skcipher);
> + kfree(tfm);
>  }
>  
>  static int skcipher_setkey(void *private, const u8 *key, unsigned int keylen)
>  {
> - return crypto_skcipher_setkey(private, key, keylen);
> + struct skcipher_tfm *tfm = private;
> + int err;
> +
> + err = crypto_skcipher_setkey(tfm->skcipher, key, keylen);
> + tfm->has_key = !err;
> +
> + return err;
>  }
>  
>  static void skcipher_wait(struct sock *sk)
> @@ -792,20 +821,25 @@ static int skcipher_accept_parent(void *private, struct 
> sock *sk)
>  {
>   struct skcipher_ctx *ctx;
>   struct alg_sock *ask = alg_sk(sk);
> - unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(private);
> + struct skcipher_tfm *tfm = private;
> + struct crypto_skcipher *skcipher = tfm->skcipher;
> + unsigned int len = sizeof(*ctx) + crypto_skcipher_reqsize(skcipher);
> +
> + if (!tfm->has_key)
> + return -ENOKEY;
>  
>   ctx = sock_kmalloc(sk, len, GFP_KERNEL);
>   if (!ctx)
>   return -ENOMEM;
>  
> - ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(private),
> + ctx->iv = sock_kmalloc(sk, crypto_skcipher_ivsize(skcipher),
>  GFP_KERNEL);
>   if (!ctx->iv) {
>   sock_kfree_s(sk, ctx, len);
>   return -ENOMEM;
>   }
>  
> - memset(ctx->iv, 0, crypto_skcipher_ivsize(private));
> + memset(ctx->iv, 0, crypto_skcipher_ivsize(skcipher));
>  
>   INIT_LIST_HEAD(&ctx->tsgl);
>   ctx->len = len;
> @@ -818,7 +852,7 @@ static int skcipher_accept_parent(void *private, struct 
> sock *sk)
>  
>   ask->private = ctx;
>  
> - skcipher_request_set_tfm(&ctx->req, private);
> + skcipher_request_set_tfm(&ctx->req, skcipher);
>   skcipher_request_set_callback(&ctx->req, CRYPTO_TFM_REQ_MAY_BACKLOG,
> af_alg_complete, &ctx->completion);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CGroup Namespaces (v8)

[Tejun Heo]

On Fri, Jan 01, 2016 at 11:14:14AM -0800, Dan Williams wrote:
> On Fri, Jan 1, 2016 at 10:06 AM, Serge E. Hallyn
>  wrote:
> > On Fri, Jan 01, 2016 at 01:42:57AM -0800, Dan Williams wrote:
> >> Commit 54b39d263704 "cgroup: cgroup namespace setns support" not
> >> booting is a separate issue.
> >
> > Oh - been there since my first version of the set (v4).  Odd, I
> > thought that the automated korg testing caught those.
> >
> > What is the simplest way to fix this?  Do I send new versions of
> > patches v3 and v4?  Does Tejun or Stephen just do it inline in the
> > git tree?  Do we leave it be?
> 
> I'm assuming it can be fixed up when you re-spin the patches to fix
> the boot failure.

I reverted the cgroup namespace patchset for the time being.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cgroup: BUG: unable to handle kernel NULL pointer dereference

[Tejun Heo]

On Fri, Jan 01, 2016 at 03:40:28PM -0800, Jeremiah Mahler wrote:
> all,
> 
> When running the latest linux-next (20151231) two of my machines
> hang early in the boot sequence.  The initial message is for a
> NULL pointer dereference.
> 
>   BUG: unable to handle kernel NULL pointer dereference at 0030
> 
> And the RIP line refers to cgroup_path.
> 
>   RIP [] cgroup_path+0x30/0x80
> 
> Attached are pictures of the back trace.
> 
> Let me know if I can do anything else to help.  I will investigate the
> problem further if I get a chance.

This is most likely from the recent changes from cgroup ns support.
Reverted the patchset for now as it also introduced a bisectability
issue.  Serge, can you please look into this one?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] BTRFS: Adds the files and options needed for Hybrid Storage

[Sanidhya Solanki]

On Sat, 02 Jan 2016 12:40:46 +0100
Martin Steigerwald  wrote:
> Or is this something different?
Yes, Martin this patch starts the implementation that I hope will lead
to the implementation of a Hybrid Cache to the BTRFS.

However, there is no need to limit ourselves to just Flash devices.
Depending on how the implementation for 3D X-point devices and NVDIMMs
work out, this can be used to cache on those layers as well.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ipc/sem.c: Fix complex_count vs. simple op race

[Manfred Spraul]

Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race:

sem_lock has a fast path that allows parallel simple operations.
There are two reasons why a simple operation cannot run in parallel:
- a non-simple operations is ongoing (sma->sem_perm.lock held)
- a complex operation is sleeping (sma->complex_count != 0)

As both facts are stored independently, a thread can bypass the current
checks by sleeping in the right positions. See below for more details
(or kernel bugzilla 105651).

The patch fixes that by creating one variable (complex_mode)
that tracks both reasons why parallel operations are not possible.

The patch also updates stale documentation regarding the locking.

With regards to stable kernels:
The patch is required for all kernels that include the commit 6d07b68ce16a
("ipc/sem.c: optimize sem_lock()") (3.10?)

The alternative is to revert the patch that introduced the race.

Background:
Here is the race of the current implementation:

Thread A: (simple op)
- does the first "sma->complex_count == 0" test

Thread B: (complex op)
- does sem_lock(): This includes an array scan. But the scan can't
  find Thread A, because Thread A does not own sem->lock yet.
- the thread does the operation, increases complex_count,
  drops sem_lock, sleeps

Thread A:
- spin_lock(&sem->lock), spin_is_locked(sma->sem_perm.lock)
- sleeps before the complex_count test

Thread C: (complex op)
- does sem_lock (no array scan, complex_count==1)
- wakes up Thread B.
- decrements complex_count

Thread A:
- does the complex_count test

Bug:
Now both thread A and thread C operate on the same array, without
any synchronization.

Reported-by: fel...@informatik.uni-bremen.de
Signed-off-by: Manfred Spraul 
Cc: 
---
 include/linux/sem.h |   1 +
 ipc/sem.c   | 124 ++--
 2 files changed, 72 insertions(+), 53 deletions(-)

diff --git a/include/linux/sem.h b/include/linux/sem.h
index 976ce3a..d0efd6e 100644
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@ -21,6 +21,7 @@ struct sem_array {
struct list_headlist_id;/* undo requests on this array 
*/
int sem_nsems;  /* no. of semaphores in array */
int complex_count;  /* pending complex operations */
+   boolcomplex_mode;   /* no parallel simple ops */
 };
 
 #ifdef CONFIG_SYSVIPC
diff --git a/ipc/sem.c b/ipc/sem.c
index b471e5a..87e1f5d 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -155,14 +155,21 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void 
*it);
 
 /*
  * Locking:
+ * a) global sem_lock() for read/write
  * sem_undo.id_next,
  * sem_array.complex_count,
- * sem_array.pending{_alter,_cont},
- * sem_array.sem_undo: global sem_lock() for read/write
- * sem_undo.proc_next: only "current" is allowed to read/write that field.
+ * sem_array.complex_mode
+ * sem_array.pending{_alter,_const},
+ * sem_array.sem_undo
  *
+ * b) global or semaphore sem_lock() for read/write:
  * sem_array.sem_base[i].pending_{const,alter}:
- * global or semaphore sem_lock() for read/write
+ * sem_array.complex_mode (for read)
+ *
+ * c) special:
+ * sem_undo_list.list_proc:
+ * * undo_list->lock for write
+ * * rcu for read
  */
 
 #define sc_semmsl  sem_ctls[0]
@@ -263,23 +270,25 @@ static void sem_rcu_free(struct rcu_head *head)
 #define ipc_smp_acquire__after_spin_is_unlocked()  smp_rmb()
 
 /*
- * Wait until all currently ongoing simple ops have completed.
+ * Enter the mode suitable for non-simple operations:
  * Caller must own sem_perm.lock.
- * New simple ops cannot start, because simple ops first check
- * that sem_perm.lock is free.
- * that a) sem_perm.lock is free and b) complex_count is 0.
  */
-static void sem_wait_array(struct sem_array *sma)
+static void complexmode_enter(struct sem_array *sma)
 {
int i;
struct sem *sem;
 
-   if (sma->complex_count)  {
-   /* The thread that increased sma->complex_count waited on
-* all sem->lock locks. Thus we don't need to wait again.
-*/
+   if (sma->complex_mode)  {
+   /* We are already in complex_mode. Nothing to do */
return;
}
+   WRITE_ONCE(sma->complex_mode, true);
+
+   /* We need a full barrier:
+* The write to complex_mode must be visible
+* before we read the first sem->lock spinlock state.
+*/
+   smp_mb();
 
for (i = 0; i < sma->sem_nsems; i++) {
sem = sma->sem_base + i;
@@ -289,6 +298,29 @@ static void sem_wait_array(struct sem_array *sma)
 }
 
 /*
+ * Try to leave the mode that disallows simple operations:
+ * Caller must own sem_perm.lock.
+ */
+static void complexmode_tryleave(struct sem_array *sma)
+{
+   if (sma->complex_count)  {
+   /* Complex ops are sleeping.
+* We must stay in co

Re: GPF in shm_lock ipc

[Dmitry Vyukov]

On Sat, Jan 2, 2016 at 12:33 PM, Manfred Spraul
 wrote:
> Hi Dmitry,
>
> shm locking differs too much from msg/sem locking, I never looked at it in
> depth, so I'm not able to perform a proper review.
>
> Except for the obvious: Races that can be triggered from user space are
> inacceptable.
> Regardless if there is a BUG_ON, a WARN_ON or nothing at all.
>
> On 12/21/2015 04:44 PM, Dmitry Vyukov wrote:
>>>
>>> +
>>> +/* This is called by fork, once for every shm attach. */
>>> +static void shm_open(struct vm_area_struct *vma)
>>> +{
>>> +   int err = __shm_open(vma);
>>> +   /*
>>> +* We raced in the idr lookup or with shm_destroy().
>>> +* Either way, the ID is busted.
>>> +*/
>>> +   WARN_ON_ONCE(err);
>>>   }
>
> Is it possible to trigger this race? Parallel IPC_RMID & fork()?

Hi Manfred,

As far as I see my reproducer triggers exactly this warning (and later a crash).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] video: ARM CLCD: Add the framebuffer parameters setting in probe

[Russell King - ARM Linux]

On Wed, Dec 30, 2015 at 08:38:48AM +0800, Rongjun Ying wrote:
> This patch fixes the user space applications can't get the framebuffer
> parameters, if disable the fb console feature.
> 
> Signed-off-by: Rongjun Ying 

I think this behaviour is intentional: userspace is expected to
set the initial mode for non-console frame buffers by using
FBIOPUT_VSCREENINFO.

Otherwise, register_fb() would always set an initial mode on all
framebuffers.

I remember this being discussed years ago (more than a decade)
when the FB layer was relatively new.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Nokia N900: twl4030-power different data in DTS and board code

[Pali Rohár]

Hello,

now I'm looking at differences between legacy board code and DTS file
for Nokia N900 and I see some inconsistency for twl4030-power driver.

In board code are defined more twl4030 power scripts which override
defaults defined in twl4030-power code. See:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51-peripherals.c#n790

Next in DTS file is defined just "compatible" keyword, but no custom
scripts, see:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n416

And the last in DTS file is defined line:

compatible = "ti,twl4030-power-n900" 

which is not in twl4030-power driver itself, see:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/twl4030-power.c#n851

So all this stuff looks like some errors when board code was ported to
DTS. Tony, can you look at this at all?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ASoC: cs35l32: avoid uninitialized variable access

[Mark Brown]

On Sat, Jan 02, 2016 at 12:19:52AM +0100, Arnd Bergmann wrote:

> - if (i2c_client->dev.of_node) {
> + if (IS_ENABLED(CONFIG_OF) && i2c_client->dev.of_node) {

This would be a lot nicer if there was an __always_null annotation we
could put on of_node for !OF configurations, that'd Just Work and this
can't be the only case where we have this idiom.


signature.asc
Description: PGP signature

Nokia N900: Proper C-states

[Pali Rohár]

Hello,

due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51
cpuidle parameters table)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc

we need patch cpuidle34xx.c code to fix commit for Nokia N900. See:

https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc

As Nokia N900 code is converting from legacy board code to DST, I would
like to know how to patch correctly omap3_idle_driver in DTS with
correct values measured for Nokia N900. Thanks!

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Nokia N900: Adjust MPU OPP values

[Pali Rohár]

Hello,

MPU OPP table table (omap36xx_vddcore_volt_data) defined in
opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
dirty patch in linux-n900 tree for it, see:

https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c

Now when doing transition to device tree, is there any way how correct
MPU OOP table for Nokia N900 could be defined in DT file?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH 0/3] net-rsi: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 15:36:25 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()
  Delete unnecessary variable initialisations in rsi_send_data_pkt()
  Replace variable initialisations by assignments in rsi_send_data_pkt()

 drivers/net/wireless/rsi/rsi_91x_pkt.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

[Milan Broz]

On 01/02/2016 12:52 PM, Milan Broz wrote:
> On 12/25/2015 08:40 AM, Herbert Xu wrote:
>> Dmitry Vyukov  wrote:
>>>
>>> I am testing with your two patches:
>>> crypto: algif_skcipher - Use new skcipher interface
>>> crypto: algif_skcipher - Require setkey before accept(2)
>>> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23).
>>
>> You sent the email to everyone on the original CC list except me.
>> Please don't do that.
>>
>>> Now the following program causes a bunch of use-after-frees and them
>>> kills kernel:
>>
>> Yes there is an obvious bug in the patch that Julia Lawall has
>> responded to in another thread.  Here is a fixed version.
>>
>> ---8<--
>> Some cipher implementations will crash if you try to use them
>> without calling setkey first.  This patch adds a check so that
>> the accept(2) call will fail with -ENOKEY if setkey hasn't been
>> done on the socket yet.
> 
> 
> Hi Herbert,
> 
> this patch breaks userspace in cryptsetup...
> 
> We use algif_skcipher in cryptsetup (for years, even before
> there was Stephan's library) and with this patch applied
> I see fail in ALG_SET_IV call (patch from your git).

(Obviously this was because of failing accept() call here, not set_iv.)

> 
> I can fix it upstream, but for thousands of installations it will
> be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices
> it will be unusable. Also people who configured kernel crypto API as default
> backend will have non-working cryptsetup).
> 
> Is it really thing for stable branch?

Also how it is supposed to work for cipher_null, where there is no key?
Why it should call set_key if it is noop? (and set key length 0 is not 
possible).

(We are using cipher_null for testing and for offline re-encryption tool
to create temporary "fake" header for not-yet encrypted device...)

Milan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 14:54:30 +0100

Omit explicit initialisation at the beginning for five local variables
which are redefined before their first use.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c 
b/drivers/net/wireless/rsi/rsi_91x_pkt.c
index 702593f..ee98f5b 100644
--- a/drivers/net/wireless/rsi/rsi_91x_pkt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c
@@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common,
  struct sk_buff *skb)
 {
struct rsi_hw *adapter = common->priv;
-   struct ieee80211_hdr *wh = NULL;
+   struct ieee80211_hdr *wh;
struct ieee80211_tx_info *info;
-   struct ieee80211_bss_conf *bss = NULL;
+   struct ieee80211_bss_conf *bss;
struct ieee80211_hw *hw = adapter->hw;
struct ieee80211_conf *conf = &hw->conf;
struct skb_info *tx_params;
-   int status = -E2BIG;
-   __le16 *msg = NULL;
-   u8 extnd_size = 0;
+   int status;
+   __le16 *msg;
+   u8 extnd_size;
u8 vap_id = 0;
 
info = IEEE80211_SKB_CB(skb);
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] rsi: Delete unnecessary variable initialisations in rsi_send_data_pkt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 15:15:12 +0100

Omit explicit initialisation at the beginning for four local variables
which are redefined before their first use.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c 
b/drivers/net/wireless/rsi/rsi_91x_pkt.c
index ee98f5b..ec65e1c 100644
--- a/drivers/net/wireless/rsi/rsi_91x_pkt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c
@@ -27,15 +27,15 @@
 int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb)
 {
struct rsi_hw *adapter = common->priv;
-   struct ieee80211_hdr *tmp_hdr = NULL;
+   struct ieee80211_hdr *tmp_hdr;
struct ieee80211_tx_info *info;
struct skb_info *tx_params;
-   struct ieee80211_bss_conf *bss = NULL;
+   struct ieee80211_bss_conf *bss;
int status = -EINVAL;
u8 ieee80211_size = MIN_802_11_HDR_LEN;
-   u8 extnd_size = 0;
+   u8 extnd_size;
__le16 *frame_desc;
-   u16 seq_num = 0;
+   u16 seq_num;
 
info = IEEE80211_SKB_CB(skb);
bss = &info->control.vif->bss_conf;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 15:25:34 +0100

Replace explicit initialisation for two local variables at the beginning
by assignments.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/rsi/rsi_91x_pkt.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c 
b/drivers/net/wireless/rsi/rsi_91x_pkt.c
index ec65e1c..fe36e7d 100644
--- a/drivers/net/wireless/rsi/rsi_91x_pkt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c
@@ -26,12 +26,12 @@
  */
 int rsi_send_data_pkt(struct rsi_common *common, struct sk_buff *skb)
 {
-   struct rsi_hw *adapter = common->priv;
+   struct rsi_hw *adapter;
struct ieee80211_hdr *tmp_hdr;
struct ieee80211_tx_info *info;
struct skb_info *tx_params;
struct ieee80211_bss_conf *bss;
-   int status = -EINVAL;
+   int status;
u8 ieee80211_size = MIN_802_11_HDR_LEN;
u8 extnd_size;
__le16 *frame_desc;
@@ -41,8 +41,10 @@ int rsi_send_data_pkt(struct rsi_common *common, struct 
sk_buff *skb)
bss = &info->control.vif->bss_conf;
tx_params = (struct skb_info *)info->driver_data;
 
-   if (!bss->assoc)
+   if (!bss->assoc) {
+   status = -EINVAL;
goto err;
+   }
 
tmp_hdr = (struct ieee80211_hdr *)&skb->data[0];
seq_num = (le16_to_cpu(tmp_hdr->seq_ctrl) >> 4);
@@ -97,7 +99,7 @@ int rsi_send_data_pkt(struct rsi_common *common, struct 
sk_buff *skb)
frame_desc[7] = cpu_to_le16(((tx_params->tid & 0xf) << 4) |
(skb->priority & 0xf) |
(tx_params->sta_id << 8));
-
+   adapter = common->priv;
status = adapter->host_intf_write_pkt(common->priv,
  skb->data,
  skb->len);
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Nokia N900: Broken lirc ir-rx51 driver

[Pali Rohár]

Hello,

due to this commit (ARM: OMAP2+: Disable code that currently does not
work with multiplaform)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/media/rc/Kconfig?id=a62a6e98c370ccca37d353a5f763b532411a4c14

lirc driver for Nokia N900 (ir-rx51) cannot be enabled via make
menuconfig. It is because Nokia N900 support cannot be compiled without
ARCH_MULTIPLATFORM, but Nokia N900 lirc driver (IR_RX51) cannot be
compiled when ARCH_MULTIPLATFORM is enabled.

Because ir-rx51 driver is just for Nokia N900 it is nonsense to have
such condition because nobody can use ir-rx51 driver... It is even not
possible to enable compilation for it...

Here is simple patch which enable compilation for Nokia N900 and fix
compile errors:

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index b6e1311..f70d4c7 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -335,7 +335,7 @@ config IR_TTUSBIR
 
 config IR_RX51
tristate "Nokia N900 IR transmitter diode"
-   depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC && 
!ARCH_MULTIPLATFORM
+   depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC
---help---
   Say Y or M here if you want to enable support for the IR
   transmitter diode built in the Nokia N900 (RX51) device.
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index b1e19a2..be29bd0 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -25,9 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
-#include 
+#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h"
 
 #include 
 #include 
@@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51)
}
 
clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer);
-   lirc_rx51->fclk_khz = clk_fclk->rate / 1000;
+   lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000;
 
return 0;
 

So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51
module for Nokia N900. Do you know how to fix this driver for upstream
kernel? It would be great to have driver working and not to have it in
this dead state...

Also platform data for this driver are only in legacy board code.
Support in DTS is missing, so driver (after fixing above problem) cannot
be used on DT booted kernel.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] rsi: Replace variable initialisations by assignments in rsi_send_data_pkt()

[Francois Romieu]

SF Markus Elfring  :
> From: Markus Elfring 
> Date: Sat, 2 Jan 2016 15:25:34 +0100
> 
> Replace explicit initialisation for two local variables at the beginning
> by assignments.

It makes no sense for the 'adapter' variable.

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

net-rsi: Reconsider usage of variable "vap_id" in rsi_send_mgmt_pkt()

[SF Markus Elfring]

Hello,

I have taken another look at the implementation of the function 
"rsi_send_mgmt_pkt".
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/net/wireless/rsi/rsi_91x_pkt.c?id=e8c58e7a5a106c3d557fccd01cd4d1128f9bab38#n114

I find the following statement combination interesting there.

…
u8 vap_id = 0;
…
msg[7] |= cpu_to_le16(vap_id << 8);
…

I would appreciate a further clarification.
Does a shift operation for a variable which contains zero indicate an open 
issue?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote:
> > > On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> > > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > > > > * Arnd Bergmann  [150515 14:26]:
> > > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > > > > If setting up the generic binding is expected to take a
> > > > > > > > while, you can naturally pass it in pdata while waiting
> > > > > > > > for the generic binding to get merged.
> > > > > > > 
> > > > > > > Yes, good idea. So the n900 machine can use auxdata to
> > > > > > > pass this for the time being, while the binding and
> > > > > > > generic implementation is being worked out.
> > > > > > 
> > > > > > Ok, so what is needed to finish this patch series?
> > > > > 
> > > > > I don't know where we are at this point. Has either the
> > > > > auxdata approach or the generic binding been worked on at
> > > > > all?
> > > > 
> > > > What are auxdata data?
> > > 
> > > I mean you can add the platform data to the omap_auxdata_lookup[]
> > > table for this board.
> > 
> > But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?
> 
> Yes.
> 
>   Arnd

Hm... looks like it is not possible. omap_hsmmc driver ignores any 
supplied platform data if there are device tree data. So array 
omap_auxdata_lookup[] does not help.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 0/3] OOM detection rework v4

[Tetsuo Handa]

Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Mon 28-12-15 21:08:56, Tetsuo Handa wrote:
> > > Tetsuo Handa wrote:
> > > > I got OOM killers while running heavy disk I/O (extracting kernel 
> > > > source,
> > > > running lxr's genxref command). (Environ: 4 CPUs / 2048MB RAM / no swap 
> > > > / XFS)
> > > > Do you think these OOM killers reasonable? Too weak against 
> > > > fragmentation?
> > > 
> > > Well, current patch invokes OOM killers when more than 75% of memory is 
> > > used
> > > for file cache (active_file: + inactive_file:). I think this is a 
> > > surprising
> > > thing for administrators and we want to retry more harder (but not 
> > > forever,
> > > please).
> > 
> > Here again, it would be good to see what is the comparision between
> > the original and the new behavior. 75% of a page cache is certainly
> > unexpected but those pages might be pinned for other reasons and so
> > unreclaimable and basically IO bound. This is hard to optimize for
> > without causing any undesirable side effects for other loads. I will
> > have a look at the oom reports later but having a comparision would be
> > a great start.
> 
> Prior to "mm, oom: rework oom detection" patch (the original), this stressor
> never invoked the OOM killer. After this patch (the new), this stressor easily
> invokes the OOM killer. Both the original and the new case, active_file: +
> inactive_file: occupies nearly 75%. I think we lost invisible retry logic for
> order > 0 allocation requests.
> 

I retested with below debug printk() patch.

--
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9d70a80..e433504 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3014,7 +3014,7 @@ static inline bool is_thp_gfp_mask(gfp_t gfp_mask)
 static inline bool
 should_reclaim_retry(gfp_t gfp_mask, unsigned order,
 struct alloc_context *ac, int alloc_flags,
-bool did_some_progress,
+unsigned long did_some_progress,
 int no_progress_loops)
 {
struct zone *zone;
@@ -3024,8 +3024,10 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
 * Make sure we converge to OOM if we cannot make any progress
 * several times in the row.
 */
-   if (no_progress_loops > MAX_RECLAIM_RETRIES)
+   if (no_progress_loops > MAX_RECLAIM_RETRIES) {
+   printk(KERN_INFO "Reached MAX_RECLAIM_RETRIES.\n");
return false;
+   }
 
/* Do not retry high order allocations unless they are __GFP_REPEAT */
if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
@@ -3086,6 +3088,8 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
 
return true;
}
+   printk(KERN_INFO "zone=%s reclaimable=%lu available=%lu 
no_progress_loops=%u did_some_progress=%lu\n",
+  zone->name, reclaimable, available, no_progress_loops, 
did_some_progress);
}
 
return false;
@@ -3273,7 +3277,7 @@ retry:
no_progress_loops++;
 
if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
-did_some_progress > 0, no_progress_loops))
+did_some_progress, no_progress_loops))
goto retry;
 
/* Reclaim has failed us, start killing things */
--

The output showed that __zone_watermark_ok() returning false on both DMA32 and 
DMA
zones is the trigger of the OOM killer invocation. Direct reclaim is constantly
reclaiming some pages, but I guess freelist for 2 <= order < MAX_ORDER are 
empty.
That trigger was introduced by commit 97a16fc82a7c5b0c ("mm, page_alloc: only
enforce watermarks for order-0 allocations"), and "mm, oom: rework oom 
detection"
patch hits the trigger.

--
[  154.547143] zone=DMA32 reclaimable=323478 available=325894 
no_progress_loops=0 did_some_progress=58
[  154.551119] zone=DMA32 reclaimable=323153 available=325770 
no_progress_loops=0 did_some_progress=58
[  154.571983] zone=DMA32 reclaimable=319582 available=322161 
no_progress_loops=0 did_some_progress=56
[  154.576121] zone=DMA32 reclaimable=319647 available=322016 
no_progress_loops=0 did_some_progress=56
[  154.583523] zone=DMA32 reclaimable=319467 available=321801 
no_progress_loops=0 did_some_progress=55
[  154.593948] zone=DMA32 reclaimable=317400 available=320988 
no_progress_loops=0 did_some_progress=56
[  154.730880] zone=DMA32 reclaimable=312385 available=313952 
no_progress_loops=0 did_some_progress=48
[  154.733226] zone=DMA32 reclaimable=312337 available=313919 
no_progress_loops=0 did_some_progress=48
[  154.737270] zone=DMA32 reclaimable=312417 available=313871 
no_progress_loops=0 did_some_progress=48
[  154.739569] zone=DMA32 reclaimable=312369 available=313844 
no_progress_loops=0 did_some_progress=48
[  154.743195] zone=DMA32 reclaimable=312385 available=313790 
no_progress_loops=0 did_some_progress=48
[  154.745

Re: [PATCH] power_suply: isp1704_charger: Fix isp1704_write() definition

[Pali Rohár]

On Friday 01 January 2016 12:33:03 Ivaylo Dimitrov wrote:
> Hi Pali,
> 
> On  1.01.2016 13:26, Pali Rohár wrote:
> > On Friday 01 January 2016 12:03:29 Ivaylo Dimitrov wrote:
> >> All calls to isp1704_write() are using parameter sequence of
> >> isp1704_write(isp, reg, val) but the function is defined as
> >> isp1704_write(isp, val, reg). Fix isp1704_write function
> >> definition so that the driver to be functional.
> >> 
> >> Signed-off-by: Ivaylo Dimitrov 
> > 
> > Reviewed-by: Pali Rohár 
> > 
> > This problem is there since inclusion of driver itself. No idea why
> > that driver could work... I remember that it detected correctly
> > type of charger.
> > 
> > I will test this patch on real N900 HW in one or two weeks to check
> > how it behave after patching...
> 
> Well, I  tested in on real HW, wall charger as well as USB were
> correctly detected. No idea what else needs to be tested, but I guess
> if you guide me, I can test whatever is needed.
> 
> Ivo

I think nothing more is needed to test. But I want to see how driver 
behave with and without this patch.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: GPF in shm_lock ipc

[Manfred Spraul]

Hi Dmitry,

On 01/02/2016 01:19 PM, Dmitry Vyukov wrote:

On Sat, Jan 2, 2016 at 12:33 PM, Manfred Spraul
 wrote:

Hi Dmitry,

shm locking differs too much from msg/sem locking, I never looked at it in
depth, so I'm not able to perform a proper review.

Except for the obvious: Races that can be triggered from user space are
inacceptable.
Regardless if there is a BUG_ON, a WARN_ON or nothing at all.

On 12/21/2015 04:44 PM, Dmitry Vyukov wrote:

+
+/* This is called by fork, once for every shm attach. */
+static void shm_open(struct vm_area_struct *vma)
+{
+   int err = __shm_open(vma);
+   /*
+* We raced in the idr lookup or with shm_destroy().
+* Either way, the ID is busted.
+*/
+   WARN_ON_ONCE(err);
   }

Is it possible to trigger this race? Parallel IPC_RMID & fork()?

Hi Manfred,

As far as I see my reproducer triggers exactly this warning (and later a crash).

Do I understand it right, shm_open() is also called by remap()?
Then please update the comment above shm_open().

And: If this is something that userspace can trigger, why a WARN_ON_ONCE()?
If the WARN_ON doesn't indicate a bug, then I would remove it entirely.

--
Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] irqchip: bcm2836: Add SMP support for the 2836

[Andrea Merello]

Agreed.
This probably comes from the downstream code, I think.. But I agree
it's actually redundant.

Thank you for pointing this out.

On Sat, Jan 2, 2016 at 11:27 AM, Russell King - ARM Linux
 wrote:
> On Sat, Dec 26, 2015 at 01:47:22PM -0800, Eric Anholt wrote:
>> +int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>> +   struct task_struct *idle)
>> +{
>> + unsigned long secondary_startup_phys =
>> + (unsigned long)virt_to_phys((void *)secondary_startup);
>> +
>> + dsb();
>> + writel(secondary_startup_phys,
>> +intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>
> Please explain why you need this dsb() - I can't see a reason for it.
> writel() has a barrier internally prior to writing the register, and
> therefore I think the above dsb() is entirely redundant.
>
> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Question about DMA] Consistent memory?

[James Bottomley]

On Sat, 2016-01-02 at 10:39 +, Russell King - ARM Linux wrote:
> On Thu, Dec 31, 2015 at 04:50:54PM +0900, Masahiro Yamada wrote:
> > Hi.
> > 
> > I am new to the Linux DMA APIs.
> > 
> > First, I started by reading Documentation/DMA-API.txt,
> > but I am confused with the term "consistent memory".
> 
> Just read "coherent memory" instead - the documentation confusingly 
> uses the two terms to refer to the same thing.  I think there was a 
> patch a while back to replace "consistent" with "coherent" in this 
> document, though I'm not sure what happened to it.

It's an standards issue.  The Document was originally based on the PCI
DMA API.  All the PCI standards documentation refers to "consistent
memory" instead of "coherent memory".  The original DMA API was
designed for PA-RISC and its standards documentation refers to
"coherent memory" hence the confusion.  The two terms are equivalent,
but there's no real way of removing either without someone reading the
actual specs and wondering what the other term means.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()

[kbuild test robot]

Hi Markus,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.4-rc7 next-20151231]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/net-rsi-Fine-tuning-for-two-function-implementations/20160102-224740
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: x86_64-randconfig-s2-01030012 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/net/wireless/rsi/rsi_91x_pkt.c: In function 'rsi_send_mgmt_pkt':
>> drivers/net/wireless/rsi/rsi_91x_pkt.c:211:2: warning: 'status' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 rsi_indicate_tx_status(common->priv, skb, status);
 ^

vim +/status +211 drivers/net/wireless/rsi/rsi_91x_pkt.c

dad0d04f Fariya Fatima 2014-03-16  195  /* Indicate to firmware to give 
cfm */
dad0d04f Fariya Fatima 2014-03-16  196  if ((skb->data[16] == 
IEEE80211_STYPE_PROBE_REQ) && (!bss->assoc)) {
dad0d04f Fariya Fatima 2014-03-16  197  msg[1] |= 
cpu_to_le16(BIT(10));
dad0d04f Fariya Fatima 2014-03-16  198  msg[7] = 
cpu_to_le16(PROBEREQ_CONFIRM);
dad0d04f Fariya Fatima 2014-03-16  199  common->mgmt_q_block = 
true;
dad0d04f Fariya Fatima 2014-03-16  200  }
dad0d04f Fariya Fatima 2014-03-16  201  
dad0d04f Fariya Fatima 2014-03-16  202  msg[7] |= cpu_to_le16(vap_id << 
8);
dad0d04f Fariya Fatima 2014-03-16  203  
dad0d04f Fariya Fatima 2014-03-16  204  status = 
adapter->host_intf_write_pkt(common->priv,
dad0d04f Fariya Fatima 2014-03-16  205  
  (u8 *)msg,
dad0d04f Fariya Fatima 2014-03-16  206  
  skb->len);
dad0d04f Fariya Fatima 2014-03-16  207  if (status)
dad0d04f Fariya Fatima 2014-03-16  208  rsi_dbg(ERR_ZONE, "%s: 
Failed to write the packet\n", __func__);
dad0d04f Fariya Fatima 2014-03-16  209  
dad0d04f Fariya Fatima 2014-03-16  210  err:
dad0d04f Fariya Fatima 2014-03-16 @211  
rsi_indicate_tx_status(common->priv, skb, status);
dad0d04f Fariya Fatima 2014-03-16  212  return status;
dad0d04f Fariya Fatima 2014-03-16  213  }

:: The code at line 211 was first introduced by commit
:: dad0d04fa7ba41ce603a01e8e64967650303e9a2 rsi: Add RS9113 wireless driver

:: TO: Fariya Fatima 
:: CC: John W. Linville 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 7/8] xfs: Support for transparent PUD pages

[Matthew Wilcox]

On Thu, Dec 31, 2015 at 10:30:27AM +1100, Dave Chinner wrote:
> > @@ -1637,6 +1669,7 @@ xfs_filemap_pfn_mkwrite(
> >  static const struct vm_operations_struct xfs_file_vm_ops = {
> > .fault  = xfs_filemap_fault,
> > .pmd_fault  = xfs_filemap_pmd_fault,
> > +   .pud_fault  = xfs_filemap_pud_fault,
> 
> This is getting silly - we now have 3 different page fault handlers
> that all do exactly the same thing. Please abstract this so that the
> page/pmd/pud is transparent and gets passed through to the generic
> handler code that then handles the differences between page/pmd/pud
> internally.
> 
> This, after all, is the original reason that the ->fault handler was
> introduced

I agree that it's silly, but this is the direction I was asked to go in by
the MM people at the last MM summit.  There was agreement that this needs
to be abstracted, but that should be left for a separate cleanup round.
I did prototype something I called a vpte (virtual pte), but that's very
much on the back burner for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: Broken lirc ir-rx51 driver

[Tony Lindgren]

Hi,

* Pali Rohár  [160102 06:46]:
> --- a/drivers/media/rc/ir-rx51.c
> +++ b/drivers/media/rc/ir-rx51.c
> @@ -25,9 +25,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#include 
> -#include 
> +#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h"

Well we don't want to export the dmtimer functions to drivers..But
we now have the PWM driver that can be already used for most of the
ir-rx51.c.

>  #include 
>  #include 
> @@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 
> *lirc_rx51)
>   }
>  
>   clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer);
> - lirc_rx51->fclk_khz = clk_fclk->rate / 1000;
> + lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000;
>  
>   return 0;
>  
> 
> So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51
> module for Nokia N900. Do you know how to fix this driver for upstream
> kernel? It would be great to have driver working and not to have it in
> this dead state...

Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support
using dual-mode timers". Chances are we still need to set up the dmtimer
code to provide also irqchip functions. That way ir-rx51.c can just do
request_irq on the selected dmtimer for interrupts.

> Also platform data for this driver are only in legacy board code.
> Support in DTS is missing, so driver (after fixing above problem) cannot
> be used on DT booted kernel.

Yeah those parts should be already doable with the PWM timer code AFAIK.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/8] mm: Add optional support for PUD-sized transparent hugepages

[Matthew Wilcox]

On Mon, Dec 28, 2015 at 12:05:51PM +0200, Kirill A. Shutemov wrote:
> On Thu, Dec 24, 2015 at 11:20:30AM -0500, Matthew Wilcox wrote:
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 4bf3811..e14634f 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -1958,6 +1977,17 @@ static inline spinlock_t *pmd_lock(struct mm_struct 
> > *mm, pmd_t *pmd)
> > return ptl;
> >  }
> >  
> > +/*
> > + * No scalability reason to split PUD locks yet, but follow the same 
> > pattern
> > + * as the PMD locks to make it easier if we have to.
> > + */
> 
> I don't think it makes any good unless you convert all other places where
> we use page_table_lock to protect pud table (like __pud_alloc()) to the
> same API.
> I think this would deserve separate patch.

Sure, a separate patch to convert existing users of the PTL.  But I
don't think it does any harm to introduce the PUD version of the PMD API.
Maybe with a comment indicating that tere is significant work to be done
in converting existing users to this API?

> > diff --git a/mm/memory.c b/mm/memory.c
> > index 416b129..7328df0 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -1220,9 +1220,27 @@ static inline unsigned long zap_pud_range(struct 
> > mmu_gather *tlb,
> > pud = pud_offset(pgd, addr);
> > do {
> > next = pud_addr_end(addr, end);
> > +   if (pud_trans_huge(*pud) || pud_devmap(*pud)) {
> > +   if (next - addr != HPAGE_PUD_SIZE) {
> > +#ifdef CONFIG_DEBUG_VM
> 
> IS_ENABLED(CONFIG_DEBUG_VM) ?
> 
> > +   if (!rwsem_is_locked(&tlb->mm->mmap_sem)) {
> > +   pr_err("%s: mmap_sem is unlocked! 
> > addr=0x%lx end=0x%lx vma->vm_start=0x%lx vma->vm_end=0x%lx\n",
> > +   __func__, addr, end,
> > +   vma->vm_start,
> > +   vma->vm_end);
> 
> dump_vma(), I guess.

These two issues are copy-and-paste from the existing PMD code.  I'm happy
to update the PMD code to the new-and-improved way of doing things;
I'm just not keen to have the PMD and PUD code diverge unnecessarily.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: twl4030-power different data in DTS and board code

[Tony Lindgren]

* Pali Rohár  [160102 06:14]:
> Hello,
> 
> now I'm looking at differences between legacy board code and DTS file
> for Nokia N900 and I see some inconsistency for twl4030-power driver.
> 
> In board code are defined more twl4030 power scripts which override
> defaults defined in twl4030-power code. See:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51-peripherals.c#n790
> 
> Next in DTS file is defined just "compatible" keyword, but no custom
> scripts, see:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n416
> 
> And the last in DTS file is defined line:
> 
> compatible = "ti,twl4030-power-n900" 
> 
> which is not in twl4030-power driver itself, see:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/twl4030-power.c#n851
> 
> So all this stuff looks like some errors when board code was ported to
> DTS. Tony, can you look at this at all?

AFAIK it should work fine with the generic "ti,twl4030-power-idle-osc-off".
This means reboot works and regulators are cut off during off mode.

The n900 specific code was based on something before the TI generic values
were available I think. And the last time I looked at it I came to the
conclusion the n900 specific code is no better.

Or did I miss something? Are you seeing some issues with PM with dts based
code?

We can certainly add it to twl4030-power if it provides something that
the "ti,twl4030-power-idle-osc-off" does not.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: Adjust MPU OPP values

[Tony Lindgren]

* Pali Rohár  [160102 06:31]:
> Hello,
> 
> MPU OPP table table (omap36xx_vddcore_volt_data) defined in
> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
> dirty patch in linux-n900 tree for it, see:
> 
> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c
> 
> Now when doing transition to device tree, is there any way how correct
> MPU OOP table for Nokia N900 could be defined in DT file?

Hmm I'd assume we can just define this in the dts.. Nishanth, got
any comments on this one?

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] xen-netback: Fine-tuning for three function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 18:46:45 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
  Delete an unnecessary assignment in connect_rings()
  Delete an unnecessary goto statement in connect_rings()
  Replace a variable initialisation by an assignment in read_xenbus_vif_flags()
  Replace a variable initialisation by an assignment in xen_register_watchers()
  Delete an unnecessary variable initialisation in xen_register_watchers()

 drivers/net/xen-netback/xenbus.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] xen-netback: Delete an unnecessary assignment in connect_rings()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 17:32:40 +0100

Remove the assignment for a local variable because its value is not
changed compared to the one from a previous function call.

Signed-off-by: Markus Elfring 
---
 drivers/net/xen-netback/xenbus.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 56ebd82..7f2895d 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -941,7 +941,6 @@ static int connect_rings(struct backend_info *be, struct 
xenvif_queue *queue)
goto err;
}
 
-   err = 0;
 err: /* Regular return falls through with err == 0 */
kfree(xspath);
return err;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] xen-netback: Delete an unnecessary goto statement in connect_rings()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 17:50:21 +0100

One goto statement referred to a source code position directly behind it.
Thus omit such an unnecessary jump.

Signed-off-by: Markus Elfring 
---
 drivers/net/xen-netback/xenbus.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 7f2895d..d4947e1 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -933,13 +933,11 @@ static int connect_rings(struct backend_info *be, struct 
xenvif_queue *queue)
/* Map the shared frame, irq etc. */
err = xenvif_connect(queue, tx_ring_ref, rx_ring_ref,
 tx_evtchn, rx_evtchn);
-   if (err) {
+   if (err)
xenbus_dev_fatal(dev, err,
 "mapping shared-frames %lu/%lu port tx %u rx 
%u",
 tx_ring_ref, rx_ring_ref,
 tx_evtchn, rx_evtchn);
-   goto err;
-   }
 
 err: /* Regular return falls through with err == 0 */
kfree(xspath);
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] xen-netback: Replace a variable initialisation by an assignment in read_xenbus_vif_flags()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 18:01:57 +0100

Replace an explicit initialisation for one local variable at the beginning
by an assignment.

Signed-off-by: Markus Elfring 
---
 drivers/net/xen-netback/xenbus.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index d4947e1..aff963f 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -946,7 +946,7 @@ err: /* Regular return falls through with err == 0 */
 
 static int read_xenbus_vif_flags(struct backend_info *be)
 {
-   struct xenvif *vif = be->vif;
+   struct xenvif *vif;
struct xenbus_device *dev = be->dev;
unsigned int rx_copy;
int err, val;
@@ -968,13 +968,14 @@ static int read_xenbus_vif_flags(struct backend_info *be)
if (xenbus_scanf(XBT_NIL, dev->otherend,
 "feature-rx-notify", "%d", &val) < 0)
val = 0;
+   vif = be->vif;
if (!val) {
/* - Reduce drain timeout to poll more frequently for
 *   Rx requests.
 * - Disable Rx stall detection.
 */
-   be->vif->drain_timeout = msecs_to_jiffies(30);
-   be->vif->stall_timeout = 0;
+   vif->drain_timeout = msecs_to_jiffies(30);
+   vif->stall_timeout = 0;
}
 
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-sg",
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] xen-netback: Replace a variable initialisation by an assignment in xen_register_watchers()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 18:23:16 +0100

Replace an explicit initialisation for one local variable at the beginning
by an assignment.

Signed-off-by: Markus Elfring 
---
 drivers/net/xen-netback/xenbus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index aff963f..e8dfc3d 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -687,11 +687,12 @@ static int xen_register_watchers(struct xenbus_device 
*dev, struct xenvif *vif)
 {
int err = 0;
char *node;
-   unsigned maxlen = strlen(dev->nodename) + sizeof("/rate");
+   unsigned maxlen;
 
if (vif->credit_watch.node)
return -EADDRINUSE;
 
+   maxlen = strlen(dev->nodename) + sizeof("/rate");
node = kmalloc(maxlen, GFP_KERNEL);
if (!node)
return -ENOMEM;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] xen-netback: Delete an unnecessary variable initialisation in xen_register_watchers()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 18:28:26 +0100

Omit explicit initialisation at the beginning for one local variable
that is redefined before its first use.

Signed-off-by: Markus Elfring 
---
 drivers/net/xen-netback/xenbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index e8dfc3d..55f0735 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -685,7 +685,7 @@ static void xen_net_rate_changed(struct xenbus_watch *watch,
 
 static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif)
 {
-   int err = 0;
+   int err;
char *node;
unsigned maxlen;
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Question about DMA] Consistent memory?

[Russell King - ARM Linux]

On Sat, Jan 02, 2016 at 08:17:51AM -0800, James Bottomley wrote:
> On Sat, 2016-01-02 at 10:39 +, Russell King - ARM Linux wrote:
> > On Thu, Dec 31, 2015 at 04:50:54PM +0900, Masahiro Yamada wrote:
> > > Hi.
> > > 
> > > I am new to the Linux DMA APIs.
> > > 
> > > First, I started by reading Documentation/DMA-API.txt,
> > > but I am confused with the term "consistent memory".
> > 
> > Just read "coherent memory" instead - the documentation confusingly 
> > uses the two terms to refer to the same thing.  I think there was a 
> > patch a while back to replace "consistent" with "coherent" in this 
> > document, though I'm not sure what happened to it.
> 
> It's an standards issue.  The Document was originally based on the PCI
> DMA API.  All the PCI standards documentation refers to "consistent
> memory" instead of "coherent memory".  The original DMA API was
> designed for PA-RISC and its standards documentation refers to
> "coherent memory" hence the confusion.  The two terms are equivalent,
> but there's no real way of removing either without someone reading the
> actual specs and wondering what the other term means.

May it be an idea to add a footnote explaining that the two terms
are interchangable and equivalent then - this is not the first time
that people have asked questions about it, and I suspect that unless
something is done, there will be a continuing stream of questions.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.

[Eric Anholt]

Michael Turquette  writes:

> Hi Arnd,
>
> Quoting Arnd Bergmann (2015-12-30 01:29:02)
>> It's also ok to merge the header file and binding with either the dts file
>> changes or the driver and then do the other part the following release.
>> 
>> In the past, we've worked around the issue by merging the driver through
>> arm-soc, or by merging the dts changes through a driver tree, with the
>> appropriate Acks in each case. Both of those approaches work of course,
>> but the former always feels awkward to me as we are not using the right
>> maintainer path, and the latter approach tends to cause merge conflicts,
>> especially when multiple headers for different subsystems get added or
>> the dts files are added at the same time.
>> 
>> Having a shared branch for the header file is another way to do it, and
>> we can do that in some cases, but I'd prefer not to make it the default.
>
> Well, I'm thinking that an immutable branch isn't such a bad idea given
> that both you and Rob are OK with subsystems merging headers and binding
> descriptions.
>
> A while back Stephen Boyd and I started to use topic branches for every
> driver, all based on -rc1 and merging those into clk-next. This makes it
> trivial for us to push a shareable branch with minimal dependencies.
>
> So at least for the clk tree, how do you feel about us merging driver +
> header + binding description and then sharing our topic branch as-needed
> with arm-soc? We could even push our topic branches by default to cut
> down on coordinating over email back-and-forth.
>
> As an example, patch #1 from the Hi3519 series[0] includes the clk
> driver, binding description and a shared header. Any objection to me
> taking that patch as-is, based on -rc1, and pushing out that topic
> branch as clk-hi3519 to the clk git tree with the expectation that
> you'll just merge that if you need to?
>
> You can let me know if you've pulled it in, and then I won't rebase
> without consulting with the arm-soc folks first.
>
> Does this workflow agreement Solve All the Problems?
>
> (Note that the patch I referenced is still under review so the branch
> name I mentioned above doesn't exist yet. It is just an example)

For what it's worth, this is a nice workflow for me as a driver
developer.  I have a couple of .dts patches that ended up waiting this
cycle because I didn't have the shareable branches necessary.


signature.asc
Description: PGP signature

Re: [PATCH 3/3] net-iwlegacy: Another refactoring for il_eeprom_init()

[Souptick Joarder]

On Sat, Jan 2, 2016 at 2:02 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Fri, 1 Jan 2016 21:16:01 +0100
>
> Rename a jump label according to the current Linux coding style convention.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/net/wireless/intel/iwlegacy/common.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlegacy/common.c 
> b/drivers/net/wireless/intel/iwlegacy/common.c
> index ae45fd3..660ab2b 100644
> --- a/drivers/net/wireless/intel/iwlegacy/common.c
> +++ b/drivers/net/wireless/intel/iwlegacy/common.c
> @@ -759,7 +759,7 @@ il_eeprom_init(struct il_priv *il)
>  IL_EEPROM_ACCESS_TIMEOUT);
> if (ret < 0) {
> IL_ERR("Time out reading EEPROM[%d]\n", addr);
> -   goto done;
> +   goto release_semaphore;

Current code looks good.
> }
> r = _il_rd(il, CSR_EEPROM_REG);
> e[addr / 2] = cpu_to_le16(r >> 16);
> @@ -769,7 +769,7 @@ il_eeprom_init(struct il_priv *il)
>  il_eeprom_query16(il, EEPROM_VERSION));
>
> ret = 0;
> -done:
> +release_semaphore:
> il->ops->eeprom_release_semaphore(il);
>
> if (ret) {
> --
> 2.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-Souptick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cgroup: BUG: unable to handle kernel NULL pointer dereference

[Serge E. Hallyn]

On Sat, Jan 02, 2016 at 06:54:37AM -0500, Tejun Heo wrote:
> On Fri, Jan 01, 2016 at 03:40:28PM -0800, Jeremiah Mahler wrote:
> > all,
> > 
> > When running the latest linux-next (20151231) two of my machines
> > hang early in the boot sequence.  The initial message is for a
> > NULL pointer dereference.
> > 
> >   BUG: unable to handle kernel NULL pointer dereference at 0030
> > 
> > And the RIP line refers to cgroup_path.
> > 
> >   RIP [] cgroup_path+0x30/0x80
> > 
> > Attached are pictures of the back trace.
> > 
> > Let me know if I can do anything else to help.  I will investigate the
> > problem further if I get a chance.
> 
> This is most likely from the recent changes from cgroup ns support.
> Reverted the patchset for now as it also introduced a bisectability
> issue.  Serge, can you please look into this one?

Tried to reproduce with setting CONFIG_CFQ_GROUP_IOSCHED=y, but did not
succeed.  Could you send me the .config?  Also, if someone could send
the objdump -d output that might help.  Though really, it seems clear
that current->nsproxy must be NULL.  Hm, that's right -  we used to have
that issue in pidns (or was it netns) during process exit.  I don't know
that I'll get time this afternoon, but I'll look into it asap.

thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 19:22:36 +0100

Omit explicit initialisation at the beginning for four local variables
which are redefined before their first use.

Signed-off-by: Markus Elfring 
---
 drivers/net/wireless/rsi/rsi_91x_pkt.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_pkt.c 
b/drivers/net/wireless/rsi/rsi_91x_pkt.c
index 702593f..571eaba 100644
--- a/drivers/net/wireless/rsi/rsi_91x_pkt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_pkt.c
@@ -123,15 +123,15 @@ int rsi_send_mgmt_pkt(struct rsi_common *common,
  struct sk_buff *skb)
 {
struct rsi_hw *adapter = common->priv;
-   struct ieee80211_hdr *wh = NULL;
+   struct ieee80211_hdr *wh;
struct ieee80211_tx_info *info;
-   struct ieee80211_bss_conf *bss = NULL;
+   struct ieee80211_bss_conf *bss;
struct ieee80211_hw *hw = adapter->hw;
struct ieee80211_conf *conf = &hw->conf;
struct skb_info *tx_params;
int status = -E2BIG;
-   __le16 *msg = NULL;
-   u8 extnd_size = 0;
+   __le16 *msg;
+   u8 extnd_size;
u8 vap_id = 0;
 
info = IEEE80211_SKB_CB(skb);
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iio: qcom-spmi-vadc: One check less in vadc_measure_ref_points() after error detection

[Jonathan Cameron]

On 26/12/15 13:04, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 26 Dec 2015 13:53:15 +0100
> 
> This issue was detected by using the Coccinelle software.
> 
> Move the jump label directly before the desired log statement
> so that the variable "ret" does not need to be checked once more
> after it was determined that a function call failed.
> 
> Signed-off-by: Markus Elfring 
If we are going to change this, I would prefer to see more useful
local error messages and direct returns rather than jumping to
a very generic message at the end.

I'm also less than keen on jumping into conditionals as I find
it slightly less readable. 

We might technically be 'simplifying' the code, but in this case
the gain is very minor for a fair bit of code churn...

Thanks,

Jonathan
> ---
>  drivers/iio/adc/qcom-spmi-vadc.c | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/adc/qcom-spmi-vadc.c 
> b/drivers/iio/adc/qcom-spmi-vadc.c
> index c2babe5..391eefa 100644
> --- a/drivers/iio/adc/qcom-spmi-vadc.c
> +++ b/drivers/iio/adc/qcom-spmi-vadc.c
> @@ -424,7 +424,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>   prop = vadc_get_channel(vadc, VADC_REF_1250MV);
>   ret = vadc_do_conversion(vadc, prop, &read_1);
>   if (ret)
> - goto err;
> + goto report_failure;
In this first case we have already had a report that a conversion failed.
I suppose adding that it was during reference point measurement 'might'
be useful additional information.  I'm not really convinced of it does
however... Hence I'd drop reporting it entirely in this function.
>  
>   /* Try with buffered 625mV channel first */
>   prop = vadc_get_channel(vadc, VADC_SPARE1);
> @@ -433,11 +433,11 @@ static int vadc_measure_ref_points(struct vadc_priv 
> *vadc)
>  
>   ret = vadc_do_conversion(vadc, prop, &read_2);
>   if (ret)
> - goto err;
> + goto report_failure;
>  
>   if (read_1 == read_2) {
>   ret = -EINVAL;
I think this one indicates we can't actually read anything at all
for some reason...  It's the only form of error we won't have effectively
already reported so is worthy of some sort of debug message...
> - goto err;
> + goto report_failure;
>   }
>  
>   vadc->graph[VADC_CALIB_ABSOLUTE].dy = read_1 - read_2;
> @@ -447,23 +447,24 @@ static int vadc_measure_ref_points(struct vadc_priv 
> *vadc)
>   prop = vadc_get_channel(vadc, VADC_VDD_VADC);
>   ret = vadc_do_conversion(vadc, prop, &read_1);
>   if (ret)
> - goto err;
> + goto report_failure;
>  
>   prop = vadc_get_channel(vadc, VADC_GND_REF);
>   ret = vadc_do_conversion(vadc, prop, &read_2);
>   if (ret)
> - goto err;
> + goto report_failure;
>  
>   if (read_1 == read_2) {
>   ret = -EINVAL;
> - goto err;
> + goto report_failure;
>   }
>  
>   vadc->graph[VADC_CALIB_RATIOMETRIC].dy = read_1 - read_2;
>   vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2;
> -err:
> - if (ret)
> + if (ret) {
> +report_failure:
>   dev_err(vadc->dev, "measure reference points failed\n");
> + }
>  
>   return ret;
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Question about DMA] Consistent memory?

[Mike Looijmans]

On 2-1-2016 11:39, Russell King - ARM Linux wrote:

On Thu, Dec 31, 2015 at 04:50:54PM +0900, Masahiro Yamada wrote:

Hi.

I am new to the Linux DMA APIs.

First, I started by reading Documentation/DMA-API.txt,
but I am confused with the term "consistent memory".


Just read "coherent memory" instead - the documentation confusingly uses
the two terms to refer to the same thing.  I think there was a patch a
while back to replace "consistent" with "coherent" in this document,
though I'm not sure what happened to it.


I wrote that patch. I never got any comments on it, so either I didn't 
post it to the right people, or no one really cares:

http://www.kernelhub.org/?msg=747166&p=2

I still think that if the kernel methods all have "coherent" in their 
name, we should use the word "coherent" in the documentation as well, 
and not confuse people even further. So I'd happily repost that patch.



--
Mike Looijmans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: most: add __iomem for io_base and registers

[Hugo Camboulive]

This removes a few Sparse warnings.

Signed-off-by: Hugo Camboulive 
---
 drivers/staging/most/hdm-dim2/dim2_hal.c | 6 +++---
 drivers/staging/most/hdm-dim2/dim2_hal.h | 6 +++---
 drivers/staging/most/hdm-dim2/dim2_hdm.c | 6 +++---
 drivers/staging/most/hdm-dim2/dim2_hdm.h | 2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/most/hdm-dim2/dim2_hal.c 
b/drivers/staging/most/hdm-dim2/dim2_hal.c
index 1722575..ff778d3 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hal.c
+++ b/drivers/staging/most/hdm-dim2/dim2_hal.c
@@ -84,7 +84,7 @@ static inline bool dim_on_error(u8 error_id, const char 
*error_message)
 struct lld_global_vars_t {
bool dim_is_initialized;
bool mcm_is_initialized;
-   struct dim2_regs *dim2; /* DIM2 core base address */
+   struct dim2_regs __iomem *dim2; /* DIM2 core base address */
u32 dbr_map[DBR_MAP_SIZE];
 };
 
@@ -650,7 +650,7 @@ static bool channel_detach_buffers(struct dim_channel *ch, 
u16 buffers_number)
 /* -- 
*/
 /* API */
 
-u8 dim_startup(void *dim_base_address, u32 mlb_clock)
+u8 dim_startup(void __iomem *dim_base_address, u32 mlb_clock)
 {
g.dim_is_initialized = false;
 
@@ -662,7 +662,7 @@ u8 dim_startup(void *dim_base_address, u32 mlb_clock)
if (mlb_clock >= 8)
return DIM_INIT_ERR_MLB_CLOCK;
 
-   g.dim2 = dim_base_address;
+   g.dim2 = (struct dim2_regs __iomem *)dim_base_address;
g.dbr_map[0] = 0;
g.dbr_map[1] = 0;
 
diff --git a/drivers/staging/most/hdm-dim2/dim2_hal.h 
b/drivers/staging/most/hdm-dim2/dim2_hal.h
index 48cdd9c..8df40c9 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hal.h
+++ b/drivers/staging/most/hdm-dim2/dim2_hal.h
@@ -65,7 +65,7 @@ struct dim_channel {
u16 done_sw_buffers_number; /*< Done software buffers number. */
 };
 
-u8 dim_startup(void *dim_base_address, u32 mlb_clock);
+u8 dim_startup(void __iomem *dim_base_address, u32 mlb_clock);
 
 void dim_shutdown(void);
 
@@ -103,9 +103,9 @@ bool dim_enqueue_buffer(struct dim_channel *ch, u32 
buffer_addr,
 
 bool dim_detach_buffers(struct dim_channel *ch, u16 buffers_number);
 
-u32 dimcb_io_read(u32 *ptr32);
+u32 dimcb_io_read(u32 __iomem *ptr32);
 
-void dimcb_io_write(u32 *ptr32, u32 value);
+void dimcb_io_write(u32 __iomem *ptr32, u32 value);
 
 void dimcb_on_error(u8 error_id, const char *error_message);
 
diff --git a/drivers/staging/most/hdm-dim2/dim2_hdm.c 
b/drivers/staging/most/hdm-dim2/dim2_hdm.c
index 327d738..7d22a6b 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hdm.c
+++ b/drivers/staging/most/hdm-dim2/dim2_hdm.c
@@ -99,7 +99,7 @@ struct dim2_hdm {
struct most_channel_capability capabilities[DMA_CHANNELS];
struct most_interface most_iface;
char name[16 + sizeof "dim2-"];
-   void *io_base;
+   void __iomem *io_base;
unsigned int irq_ahb0;
int clk_speed;
struct task_struct *netinfo_task;
@@ -138,7 +138,7 @@ bool dim2_sysfs_get_state_cb(void)
  * dimcb_io_read - callback from HAL to read an I/O register
  * @ptr32: register address
  */
-u32 dimcb_io_read(u32 *ptr32)
+u32 dimcb_io_read(u32 __iomem *ptr32)
 {
return __raw_readl(ptr32);
 }
@@ -148,7 +148,7 @@ u32 dimcb_io_read(u32 *ptr32)
  * @ptr32: register address
  * @value: value to write
  */
-void dimcb_io_write(u32 *ptr32, u32 value)
+void dimcb_io_write(u32 __iomem *ptr32, u32 value)
 {
__raw_writel(value, ptr32);
 }
diff --git a/drivers/staging/most/hdm-dim2/dim2_hdm.h 
b/drivers/staging/most/hdm-dim2/dim2_hdm.h
index 1c94e33..4050e7c 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hdm.h
+++ b/drivers/staging/most/hdm-dim2/dim2_hdm.h
@@ -18,7 +18,7 @@ struct device;
 
 /* platform dependent data for dim2 interface */
 struct dim2_platform_data {
-   int (*init)(struct dim2_platform_data *pd, void *io_base,
+   int (*init)(struct dim2_platform_data *pd, void __iomem *io_base,
int clk_speed);
void (*destroy)(struct dim2_platform_data *pd);
void *priv;
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ext4: disable retry logic in ext4_set_encrypted_filename

[Arnd Bergmann]

gcc correctly warns that the ctx variable in ext4_set_encrypted_filename
has gone out of scope in ext4_set_encrypted_filename if we enter the
retry path and a 'goto' into the previous code block can not guarantee
to get the contents back:

fs/ext4/namei.c: In function 'ext4_set_encrypted_filename':
fs/ext4/namei.c:4035:10: warning: 'ctx' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   retval = ext4_xattr_set_handle(handle, inode,

I tried moving the variable declaration to the start of the function,
but that does not shut up the warning, as it's apparently too hard
for the compiler to follow the control flow and determine that it's
correct (or for me reading the code, for that matter).

This adds a hack to avoid the undefined behavior at the cost of
losing the chance to retry on a spurious -ENOSPC error. We probably
need a better solution.

Signed-off-by: Arnd Bergmann 
Fixes: 374431bae296 ("ext4 crypto: add ioctls to allow backup of encryption 
metadata")
---
The warning appeared with next-20121231, which is the latest next release,
nevermind if it has already been fixed in the meantime.

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index c03f310200d6..fd2bd090bdfa 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -4113,7 +4113,7 @@ out:
}
if (handle)
ext4_journal_stop(handle);
-   if (do_retry) {
+   if (do_retry /* FIXME: ctx is invalid */ && 0) {
do_retry = 0;
goto retry;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: pxa: add defconfig covering all the boards

[Robert Jarzmik]

Add a defconfig covering all known pxa board, ie. all selectable machine
files in arch/arm/mach-pxa/*.c.

This defconfig was built by doing :
 - aggregation of all known defconfigs by cat
am200epdkit_defconfig
cm_x2xx_defconfig
cm_x300_defconfig
colibri_pxa270_defconfig
colibri_pxa300_defconfig
corgi_defconfig
em_x270_defconfig
eseries_pxa_defconfig
ezx_defconfig
h5000_defconfig
imote2_defconfig
lpd270_defconfig
lubbock_defconfig
magician_defconfig
mainstone_defconfig
multi_v7_defconfig
palmz72_defconfig
pcm027_defconfig
pxa255-idp_defconfig
pxa3xx_defconfig
raumfeld_defconfig
spitz_defconfig
trizeps4_defconfig
viper_defconfig
xcep_defconfig
zeus_defconfig
 - manual make menuconfig to ensure :
   - all pxa implementation were selected
   - all drivers were transformed into modules rather than builtin
 => as a consequence this single kernel will rely on an initramfs
 => as kernel size matters on pxa, each machine can take the subset
of modules required for it to work
   - all missed configurations are selected verified by :
 => grep -i pxa .config | grep "is not set"
 => this should only show the left on purpose options (either not
selectable or sharpsl exception below)
 - CONFIG_PXA_SHARPSL was disabled
   This breaks the boot very early on any non Sharp platform, see
   head-sharpsl.S

This defconfig was tested as booting up to the login phase on :
 - lubbock (pxa25x)
 - mainstone (pxa27x)
 - zylonite (pxa3xx)

The completion of this work will require to :
 - parse manually all the arch/arm/mach-pxa/*c files, look for all
   platform devices added, and verify they are all in pxa_defconfig
 - do the same to ensure all pxa specific drivers (leds, gpio, ...) are
   included

Signed-off-by: Robert Jarzmik 
---
 arch/arm/configs/pxa_defconfig | 783 +
 1 file changed, 783 insertions(+)
 create mode 100644 arch/arm/configs/pxa_defconfig

diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
new file mode 100644
index ..0cb724b5c639
--- /dev/null
+++ b/arch/arm/configs/pxa_defconfig
@@ -0,0 +1,783 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
+CONFIG_IRQ_DOMAIN_DEBUG=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=13
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+CONFIG_SLOB=y
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=m
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_LDM_PARTITION=y
+CONFIG_CMDLINE_PARTITION=y
+CONFIG_ARCH_PXA=y
+CONFIG_MACH_PXA27X_DT=y
+CONFIG_MACH_PXA3XX_DT=y
+CONFIG_ARCH_LUBBOCK=y
+CONFIG_MACH_MAINSTONE=y
+CONFIG_MACH_ZYLONITE300=y
+CONFIG_MACH_ZYLONITE320=y
+CONFIG_MACH_LITTLETON=y
+CONFIG_MACH_TAVOREVB=y
+CONFIG_MACH_SAAR=y
+CONFIG_ARCH_PXA_IDP=y
+CONFIG_ARCH_VIPER=y
+CONFIG_MACH_ARCOM_ZEUS=y
+CONFIG_MACH_BALLOON3=y
+CONFIG_MACH_CSB726=y
+CONFIG_CSB726_CSB701=y
+CONFIG_MACH_ARMCORE=y
+CONFIG_MACH_EM_X270=y
+CONFIG_MACH_EXEDA=y
+CONFIG_MACH_CM_X300=y
+CONFIG_MACH_CAPC7117=y
+CONFIG_ARCH_GUMSTIX=y
+CONFIG_MACH_INTELMOTE2=y
+CONFIG_MACH_STARGATE2=y
+CONFIG_MACH_XCEP=y
+CONFIG_TRIZEPS_PXA=y
+CONFIG_MACH_TRIZEPS4WL=y
+CONFIG_MACH_LOGICPD_PXA270=y
+CONFIG_MACH_PCM027=y
+CONFIG_MACH_PCM990_BASEBOARD=y
+CONFIG_MACH_COLIBRI=y
+CONFIG_MACH_COLIBRI_PXA270_INCOME=y
+CONFIG_MACH_COLIBRI300=y
+CONFIG_MACH_COLIBRI320=y
+CONFIG_MACH_COLIBRI_EVALBOARD=y
+CONFIG_MACH_VPAC270=y
+CONFIG_MACH_H4700=y
+CONFIG_MACH_H5000=y
+CONFIG_MACH_HIMALAYA=y
+CONFIG_MACH_MAGICIAN=y
+CONFIG_MACH_MIOA701=y
+CONFIG_PXA_EZX=y
+CONFIG_MACH_MP900C=y
+CONFIG_ARCH_PXA_PALM=y
+CONFIG_MACH_RAUMFELD_RC=y
+CONFIG_MACH_RAUMFELD_CONNECTOR=y
+CONFIG_MACH_RAUMFELD_SPEAKER=y
+CONFIG_PXA_SHARPSL=y
+CONFIG_MACH_POODLE=y
+CONFIG_MACH_CORGI=y
+CONFIG_MACH_SHEPHERD=y
+CONFIG_MACH_HUSKY=y
+CONFIG_MACH_AKITA=y
+CONFIG_MACH_BORZOI=y
+CONFIG_MACH_TOSA=y
+CONFIG_TOSA_BT=m
+CONFIG_TOSA_USE_EXT_KEYCODES=y
+CONFIG_MACH_ICONTROL=y
+CONFIG_ARCH_PXA_ESERIES=y
+CONFIG_MACH_ZIPIT2=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_PCCARD=m
+CONFIG_YENTA=m
+CONFIG_PCMCIA_PXA2XX=m
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_COMPACTION is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="root=/dev/ram0 ro"
+CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT_DETAILS=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=m
+CONFIG_CPU_FREQ_GOV_USERSPACE=m
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
+CONFIG_CPUFREQ_DT=m
+CONFIG_ARM_PXA2xx_CPUFREQ=m
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
+CONFIG_

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

[Stephan Mueller]

Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz:

Hi Milan,

> On 01/02/2016 12:52 PM, Milan Broz wrote:
> > On 12/25/2015 08:40 AM, Herbert Xu wrote:
> >> Dmitry Vyukov  wrote:
> >>> I am testing with your two patches:
> >>> crypto: algif_skcipher - Use new skcipher interface
> >>> crypto: algif_skcipher - Require setkey before accept(2)
> >>> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23).
> >> 
> >> You sent the email to everyone on the original CC list except me.
> >> Please don't do that.
> >> 
> >>> Now the following program causes a bunch of use-after-frees and them
> >> 
> >>> kills kernel:
> >> Yes there is an obvious bug in the patch that Julia Lawall has
> >> responded to in another thread.  Here is a fixed version.
> >> 
> >> ---8<--
> >> Some cipher implementations will crash if you try to use them
> >> without calling setkey first.  This patch adds a check so that
> >> the accept(2) call will fail with -ENOKEY if setkey hasn't been
> >> done on the socket yet.
> > 
> > Hi Herbert,
> > 
> > this patch breaks userspace in cryptsetup...
> > 
> > We use algif_skcipher in cryptsetup (for years, even before
> > there was Stephan's library) and with this patch applied
> > I see fail in ALG_SET_IV call (patch from your git).
> 
> (Obviously this was because of failing accept() call here, not set_iv.)
> 
> > I can fix it upstream, but for thousands of installations it will
> > be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices
> > it will be unusable. Also people who configured kernel crypto API as
> > default backend will have non-working cryptsetup).
> > 
> > Is it really thing for stable branch?
> 
> Also how it is supposed to work for cipher_null, where there is no key?
> Why it should call set_key if it is noop? (and set key length 0 is not
> possible).
> 
> (We are using cipher_null for testing and for offline re-encryption tool
> to create temporary "fake" header for not-yet encrypted device...)

The change implies that any setkey or set IV operations (i.e. any operations 
on the tfmfd) are done before the opfd(s) are created with one or more accept 
calls.

Thus, after a bind that returns the tfmfd, the setkey and setiv operations 
shall be called. This is followed by accept. If you change the order of 
invocations in your code, it should work.
> 
> Milan


-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Question about DMA] Consistent memory?

[James Bottomley]

On Sat, 2016-01-02 at 19:35 +0100, Mike Looijmans wrote:
> On 2-1-2016 11:39, Russell King - ARM Linux wrote:
> > On Thu, Dec 31, 2015 at 04:50:54PM +0900, Masahiro Yamada wrote:
> > > Hi.
> > > 
> > > I am new to the Linux DMA APIs.
> > > 
> > > First, I started by reading Documentation/DMA-API.txt,
> > > but I am confused with the term "consistent memory".
> > 
> > Just read "coherent memory" instead - the documentation confusingly
> > uses
> > the two terms to refer to the same thing.  I think there was a
> > patch a
> > while back to replace "consistent" with "coherent" in this
> > document,
> > though I'm not sure what happened to it.
> 
> I wrote that patch. I never got any comments on it, so either I
> didn't 
> post it to the right people, or no one really cares:
> http://www.kernelhub.org/?msg=747166&p=2
> 
> I still think that if the kernel methods all have "coherent" in their
> name, we should use the word "coherent" in the documentation as well,
> and not confuse people even further. So I'd happily repost that 
> patch.

They don't: the PCI API still uses consistent:

asm-generic/pci-dma-compat.h:pci_alloc_consistent(struct pci_dev *hwdev, size_t 
size,
asm-generic/pci-dma-compat.h:pci_zalloc_consistent(struct pci_dev *hwdev, 
size_t size,
asm-generic/pci-dma-compat.h:pci_free_consistent(struct pci_dev *hwdev, size_t 
size,
asm-generic/pci-dma-compat.h:static inline int 
pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask)
linux/pci.h:/* kmem_cache style wrapper around pci_alloc_consistent() */
linux/pci.h:static inline int pci_set_consistent_dma_mask(struct pci_dev *dev, 
u64 mask)

These are named based on the PCI specification.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

[Milan Broz]

On 01/02/2016 09:03 PM, Stephan Mueller wrote:
> Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz:
> 
> Hi Milan,
> 

...
>>> Hi Herbert,
>>>
>>> this patch breaks userspace in cryptsetup...
>>>
>>> We use algif_skcipher in cryptsetup (for years, even before
>>> there was Stephan's library) and with this patch applied
>>> I see fail in ALG_SET_IV call (patch from your git).
>>
>> (Obviously this was because of failing accept() call here, not set_iv.)
>>
>>> I can fix it upstream, but for thousands of installations it will
>>> be broken (for LUKS there is a fallback, cor TrueCrypt compatible devices
>>> it will be unusable. Also people who configured kernel crypto API as
>>> default backend will have non-working cryptsetup).
>>>
>>> Is it really thing for stable branch?
>>
>> Also how it is supposed to work for cipher_null, where there is no key?
>> Why it should call set_key if it is noop? (and set key length 0 is not
>> possible).
>>
>> (We are using cipher_null for testing and for offline re-encryption tool
>> to create temporary "fake" header for not-yet encrypted device...)
> 
> The change implies that any setkey or set IV operations (i.e. any operations 
> on the tfmfd) are done before the opfd(s) are created with one or more accept 
> calls.
> 
> Thus, after a bind that returns the tfmfd, the setkey and setiv operations 
> shall be called. This is followed by accept. If you change the order of 
> invocations in your code, it should work.

Hi,

I already changed it in cryptsetup upstream this way.

But I cannot change thousands of cryptsetup installations that are actively 
using that code.
This is clear userspace breakage which should not happen this way.

(Moreover it still doesn't work for cipher_null that has min/max key size 0.)

Milan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: most: add __iomem for io_base and registers

[Al Viro]

On Sat, Jan 02, 2016 at 08:30:21PM +, Hugo Camboulive wrote:
> This removes a few Sparse warnings.

> + g.dim2 = (struct dim2_regs __iomem *)dim_base_address;

> -u8 dim_startup(void *dim_base_address, u32 mlb_clock);
> +u8 dim_startup(void __iomem *dim_base_address, u32 mlb_clock);

Umm...  Why not have it take struct dim2_regs __iomem * as argument, and
to hell with that cast?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: Adjust MPU OPP values

[Nishanth Menon]

On 01/02/2016 11:16 AM, Tony Lindgren wrote:
> * Pali Rohár  [160102 06:31]:
>> Hello,
>>
>> MPU OPP table table (omap36xx_vddcore_volt_data) defined in
>> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have
>> dirty patch in linux-n900 tree for it, see:
>>
>> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c
>>
>> Now when doing transition to device tree, is there any way how correct
>> MPU OOP table for Nokia N900 could be defined in DT file?
> 
> Hmm I'd assume we can just define this in the dts.. Nishanth, got
> any comments on this one?
> 

We already have definitions in dtb for omap3 OPPs. I think we should
start using device tree as default. the oppxx_data.c is sticking around
waiting for legacy boot to go away, then those files should be deleted.


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

[Wolfram Sang]

On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote:
> 2015-12-11 13:08 GMT+01:00 Wolfram Sang :
> > On Wed, Dec 02, 2015 at 11:25:17AM +0100, Bartosz Golaszewski wrote:
> >> Chips from the at24cs EEPROM series have an additional read-only memory 
> >> area
> >> containing a factory pre-programmed serial number. In order to access it, a
> >> dummy write must be executed before reading the serial number bytes.
> >
> > Can't you instantiate a read-only EEPROM on this second address? Or a
> > seperate driver attaching to this address? What is the advantage of
> > having this in at24?
> >
> 
> The regular memory area and serial number read-only block share the
> internal address pointer. We must ensure that there's no race
> conditions between normal EEPROM reads/writes and serial number reads.

I don't get it. Both, regular at24 reads and the serial read, setup the
pointer every time by using two messages, first write to set the
pointer, then read. The per-adapter lock makes sure those two messages
will not get interrupted. So, it looks to me that it would be OK if a
serial read access gets inbetween a eeprom read access. Am I wrong?



signature.asc
Description: Digital signature

[PATCH 0/3] NFC-mei_phy: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 21:47:30 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Refactoring for mei_nfc_connect()
  Refactoring for mei_nfc_if_version()
  Delete an unnecessary variable initialisation in mei_nfc_if_version()

 drivers/nfc/mei_phy.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] NFC-mei_phy: Refactoring for mei_nfc_connect()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 21:21:24 +0100

This issue was detected by using the Coccinelle software.

Adjust jump targets according to the current Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/nfc/mei_phy.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c
index 83deda4..8e3a69f 100644
--- a/drivers/nfc/mei_phy.c
+++ b/drivers/nfc/mei_phy.c
@@ -173,8 +173,8 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy)
 
reply = kzalloc(connect_resp_length, GFP_KERNEL);
if (!reply) {
-   kfree(cmd);
-   return -ENOMEM;
+   r = -ENOMEM;
+   goto free_cmd;
}
 
connect_resp = (struct mei_nfc_connect_resp *)reply->data;
@@ -189,7 +189,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy)
r = mei_cldev_send(phy->cldev, (u8 *)cmd, connect_length);
if (r < 0) {
pr_err("Could not send connect cmd %d\n", r);
-   goto err;
+   goto free_reply;
}
 
bytes_recv = mei_cldev_recv(phy->cldev, (u8 *)reply,
@@ -197,7 +197,7 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy)
if (bytes_recv < 0) {
r = bytes_recv;
pr_err("Could not read connect response %d\n", r);
-   goto err;
+   goto free_reply;
}
 
MEI_DUMP_NFC_HDR("connect reply", &reply->hdr);
@@ -210,11 +210,10 @@ static int mei_nfc_connect(struct nfc_mei_phy *phy)
connect_resp->me_hotfix, connect_resp->me_build);
 
r = 0;
-
-err:
+free_reply:
kfree(reply);
+free_cmd:
kfree(cmd);
-
return r;
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] NFC-mei_phy: Refactoring for mei_nfc_if_version()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 21:33:04 +0100

Rename a jump label according to the current Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/nfc/mei_phy.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c
index 8e3a69f..3c74028 100644
--- a/drivers/nfc/mei_phy.c
+++ b/drivers/nfc/mei_phy.c
@@ -136,7 +136,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy)
if (bytes_recv < 0 || bytes_recv < sizeof(struct mei_nfc_reply)) {
pr_err("Could not read IF version\n");
r = -EIO;
-   goto err;
+   goto free_reply;
}
 
version = (struct mei_nfc_if_version *)reply->data;
@@ -144,8 +144,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy)
phy->fw_ivn = version->fw_ivn;
phy->vendor_id = version->vendor_id;
phy->radio_type = version->radio_type;
-
-err:
+free_reply:
kfree(reply);
return r;
 }
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] NFC-mei_phy: Delete an unnecessary variable initialisation in mei_nfc_if_version()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 2 Jan 2016 21:40:10 +0100

Omit explicit initialisation at the beginning for one local variable
that is redefined before its first use.

Signed-off-by: Markus Elfring 
---
 drivers/nfc/mei_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c
index 3c74028..99fd87d 100644
--- a/drivers/nfc/mei_phy.c
+++ b/drivers/nfc/mei_phy.c
@@ -105,7 +105,7 @@ static int mei_nfc_if_version(struct nfc_mei_phy *phy)
 {
 
struct mei_nfc_cmd cmd;
-   struct mei_nfc_reply *reply = NULL;
+   struct mei_nfc_reply *reply;
struct mei_nfc_if_version *version;
size_t if_version_length;
int bytes_recv, r;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: most: add __iomem for io_base and registers

[Hugo Camboulive]

On Saturday 02 Jan 2016 20:33:23 (+), Al Viro wrote:
> On Sat, Jan 02, 2016 at 08:30:21PM +, Hugo Camboulive wrote:
> > This removes a few Sparse warnings.
> 
> > +   g.dim2 = (struct dim2_regs __iomem *)dim_base_address;
> 
> > -u8 dim_startup(void *dim_base_address, u32 mlb_clock);
> > +u8 dim_startup(void __iomem *dim_base_address, u32 mlb_clock);
> 
> Umm...  Why not have it take struct dim2_regs __iomem * as argument, and
> to hell with that cast?
Oh, right. I wasn't sure if the original void* was there for a reason. I'll 
send a v2.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] DT: i2c: Add Epson RX8010 to list of trivial devices

[Wolfram Sang]

On Sun, Dec 27, 2015 at 05:02:48PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 23, 2015 at 8:38 PM, Akshay Bhat  wrote:
> > This adds devicetree documentation for the bindings of rtc-rx8010
> > driver.
> >
> > Signed-off-by: Akshay Bhat 
> > ---
> >  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> > index c50cf13..0f9c1de 100644
> > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> > @@ -49,6 +49,7 @@ dallas,ds4510 CPU Supervisor with Nonvolatile 
> > Memory and Programmable I/O
> >  dallas,ds75Digital Thermometer and Thermostat
> >  dlg,da9053 DA9053: flexible system level PMIC with multicore 
> > support
> >  dlg,da9063 DA9063: system PMIC for quad-core application 
> > processors
> > +epson,rx8010   I2C-BUS INTERFACE REAL TIME CLOCK MODULE
> 
> Is it indeed required to have all those capital letters together?

I agree. Fixing that in all Epson RTC entries would be nice.



signature.asc
Description: Digital signature

Re: [PATCH] DT: i2c: Update vendor prefix for 24c00

[Wolfram Sang]

On Sun, Dec 27, 2015 at 04:57:48PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat  wrote:
> > "at" is not a valid vendor prefix, correcting the same to "atmel"
> >
> 
> I'm afraid you can't just do this change alone as it's used in some
> DTS. Though you may deprecated it along with update of current users.

Well, in Linux, I2C core currently strips the vendor anyhow. This will
probably be changed somewhen (tm), but for now, the impact for Linux
should be extremly close to 0.


> 
> > Signed-off-by: Akshay Bhat 
> > ---
> >  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> > index c50cf13..c4a01c0 100644
> > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> > @@ -20,11 +20,11 @@ adi,adt7476 +/-1C TDM Extended Temp Range I.C
> >  adi,adt7490+/-1C TDM Extended Temp Range I.C
> >  adi,adxl345Three-Axis Digital Accelerometer
> >  adi,adxl346Three-Axis Digital Accelerometer 
> > (backward-compatibility value "adi,adxl345" must be listed too)
> > -at,24c08   i2c serial eeprom  (24cxx)
> >  atmel,24c00i2c serial eeprom  (24cxx)
> >  atmel,24c01i2c serial eeprom  (24cxx)
> >  atmel,24c02i2c serial eeprom  (24cxx)
> >  atmel,24c04i2c serial eeprom  (24cxx)
> > +atmel,24c08i2c serial eeprom  (24cxx)
> >  atmel,24c16i2c serial eeprom  (24cxx)
> >  atmel,24c32i2c serial eeprom  (24cxx)
> >  atmel,24c64i2c serial eeprom  (24cxx)
> > --
> > 2.6.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko


signature.asc
Description: Digital signature

Re: [PATCH 2/2] net-qmi_wwan: Delete an unnecessary variable initialisation in qmi_wwan_register_subdriver()

[Bjørn Mork]

SF Markus Elfring  writes:

> From: Markus Elfring 
> Date: Fri, 1 Jan 2016 17:35:03 +0100
>
> Omit explicit initialisation at the beginning for one local variable
> that is redefined before its first use.


This patch is unnecessary. The variable initialisation is redundant.
See the difference?  Sending an unnecessary patch causes unnecessary
load on reviewers and maintainers.  Keeping redundant code has no
measurable cost, and can save the same maintainers a lot of trouble
later.

I'd like to keep this particular redundant initialisation as a safe
guard against future code refactoring, causing for example the err label
to move up.  Yes, I do understand that any patch with such a bug should
be rejected, but I do know what happens in the real world and how easy
it is for something like that to slip through in a stream of unnecessary
"cleanup" patches.

Reducing redundancy in the kernel is only making the code less robust.
It is harmful. Please stop.  Thanks.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] staging: most: add __iomem for io_base and registers

[Hugo Camboulive]

This removes a few Sparse warnings.

Signed-off-by: Hugo Camboulive 
---
 drivers/staging/most/hdm-dim2/dim2_hal.c | 4 ++--
 drivers/staging/most/hdm-dim2/dim2_hal.h | 7 ---
 drivers/staging/most/hdm-dim2/dim2_hdm.c | 6 +++---
 drivers/staging/most/hdm-dim2/dim2_hdm.h | 2 +-
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/most/hdm-dim2/dim2_hal.c 
b/drivers/staging/most/hdm-dim2/dim2_hal.c
index 1722575..3c52450 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hal.c
+++ b/drivers/staging/most/hdm-dim2/dim2_hal.c
@@ -84,7 +84,7 @@ static inline bool dim_on_error(u8 error_id, const char 
*error_message)
 struct lld_global_vars_t {
bool dim_is_initialized;
bool mcm_is_initialized;
-   struct dim2_regs *dim2; /* DIM2 core base address */
+   struct dim2_regs __iomem *dim2; /* DIM2 core base address */
u32 dbr_map[DBR_MAP_SIZE];
 };
 
@@ -650,7 +650,7 @@ static bool channel_detach_buffers(struct dim_channel *ch, 
u16 buffers_number)
 /* -- 
*/
 /* API */
 
-u8 dim_startup(void *dim_base_address, u32 mlb_clock)
+u8 dim_startup(struct dim2_regs __iomem *dim_base_address, u32 mlb_clock)
 {
g.dim_is_initialized = false;
 
diff --git a/drivers/staging/most/hdm-dim2/dim2_hal.h 
b/drivers/staging/most/hdm-dim2/dim2_hal.h
index 48cdd9c..fc73d4f 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hal.h
+++ b/drivers/staging/most/hdm-dim2/dim2_hal.h
@@ -16,6 +16,7 @@
 #define _DIM2_HAL_H
 
 #include 
+#include "dim2_reg.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -65,7 +66,7 @@ struct dim_channel {
u16 done_sw_buffers_number; /*< Done software buffers number. */
 };
 
-u8 dim_startup(void *dim_base_address, u32 mlb_clock);
+u8 dim_startup(struct dim2_regs __iomem *dim_base_address, u32 mlb_clock);
 
 void dim_shutdown(void);
 
@@ -103,9 +104,9 @@ bool dim_enqueue_buffer(struct dim_channel *ch, u32 
buffer_addr,
 
 bool dim_detach_buffers(struct dim_channel *ch, u16 buffers_number);
 
-u32 dimcb_io_read(u32 *ptr32);
+u32 dimcb_io_read(u32 __iomem *ptr32);
 
-void dimcb_io_write(u32 *ptr32, u32 value);
+void dimcb_io_write(u32 __iomem *ptr32, u32 value);
 
 void dimcb_on_error(u8 error_id, const char *error_message);
 
diff --git a/drivers/staging/most/hdm-dim2/dim2_hdm.c 
b/drivers/staging/most/hdm-dim2/dim2_hdm.c
index 327d738..7d22a6b 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hdm.c
+++ b/drivers/staging/most/hdm-dim2/dim2_hdm.c
@@ -99,7 +99,7 @@ struct dim2_hdm {
struct most_channel_capability capabilities[DMA_CHANNELS];
struct most_interface most_iface;
char name[16 + sizeof "dim2-"];
-   void *io_base;
+   void __iomem *io_base;
unsigned int irq_ahb0;
int clk_speed;
struct task_struct *netinfo_task;
@@ -138,7 +138,7 @@ bool dim2_sysfs_get_state_cb(void)
  * dimcb_io_read - callback from HAL to read an I/O register
  * @ptr32: register address
  */
-u32 dimcb_io_read(u32 *ptr32)
+u32 dimcb_io_read(u32 __iomem *ptr32)
 {
return __raw_readl(ptr32);
 }
@@ -148,7 +148,7 @@ u32 dimcb_io_read(u32 *ptr32)
  * @ptr32: register address
  * @value: value to write
  */
-void dimcb_io_write(u32 *ptr32, u32 value)
+void dimcb_io_write(u32 __iomem *ptr32, u32 value)
 {
__raw_writel(value, ptr32);
 }
diff --git a/drivers/staging/most/hdm-dim2/dim2_hdm.h 
b/drivers/staging/most/hdm-dim2/dim2_hdm.h
index 1c94e33..4050e7c 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hdm.h
+++ b/drivers/staging/most/hdm-dim2/dim2_hdm.h
@@ -18,7 +18,7 @@ struct device;
 
 /* platform dependent data for dim2 interface */
 struct dim2_platform_data {
-   int (*init)(struct dim2_platform_data *pd, void *io_base,
+   int (*init)(struct dim2_platform_data *pd, void __iomem *io_base,
int clk_speed);
void (*destroy)(struct dim2_platform_data *pd);
void *priv;
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread

[Michael S. Tsirkin]

On Sat, Jan 02, 2016 at 06:43:16AM -0500, Tejun Heo wrote:
> Hello,
> 
> On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote:
> > > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin
> > > suggested using a system one. Tejun Heo confirmed that the system
> > > workqueue has a pretty high concurrency level (256) by default.
> > > Therefore we need not be afraid of too long blocking.
> > 
> > Right but fill has a 1/5 second sleep on failure - *that*
> > is problematic for a system queue.
> 
> Why so?  As long as the maximum concurrently used workers are not
> high, 1/5 second or even a lot longer sleeps are completely fine.

I always thought the right way to defer executing a work queue item
is to queue delayed work, not sleep + queue work.

Doing a sleep ties up one thread for 1/5 of a second, does it not?
If so, as long as it's the only driver doing this, we'll be fine,
but if many others copy this pattern, things will
start to break, will they not?

> > > @@ -563,7 +534,7 @@ static void virtballoon_remove(struct virtio_device 
> > > *vdev)
> > >   struct virtio_balloon *vb = vdev->priv;
> > >  
> > >   unregister_oom_notifier(&vb->nb);
> > > - kthread_stop(vb->thread);
> > > + cancel_work_sync(&vb->wq_work);
> > 
> > OK but since job requeues itself, cancelling like this might not be enough.
> 
> As long as there's no further external queueing, cancel_work_sync() is
> guaranteed to kill a self-requeueing work item.
> 
> Thanks.

I didn't realise this. Thanks!

Unfortunately in this case, there can be further requeueing
if a stats request arrives.

> -- 
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] net-qmi_wwan: Refactoring for qmi_wwan_bind()

[Bjørn Mork]

SF Markus Elfring  writes:

> From: Markus Elfring 
> Date: Fri, 1 Jan 2016 17:32:07 +0100
>
> Reduce the scope for the local variable "desc" to one branch
> of an if statement.

This patch is harmless.  But is also pointless.

You could at least try to explain why this must be changed.  I'm not
interested in why you think it is better this way - I might agree with
that.  what I am interested in is the advantage changing the code gives
us.  Some analysis of the risk and work involved would also be nice.  Is
this change really worth it?

Personally I am convinced that I wasted any time I used writing this,
and you wasted any time you used reading it.  Sorry.

Note:  This patch would have been fine if it was a natural part of some
*improvement* of the driver, i.e. a bugfix or feaure addition. As a
standalone patch I see it as noise.

Please stop the noise and start writing something useful.  I'm sure you
can fix bugs instead.  Wouldn't that be more interesting?  More
challenging?  These mindless robotic code refactoring patches are really
best left for robots.




Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900: twl4030-power different data in DTS and board code

[Pali Rohár]

On Saturday 02 January 2016 18:14:31 Tony Lindgren wrote:
> * Pali Rohár  [160102 06:14]:
> > Hello,
> > 
> > now I'm looking at differences between legacy board code and DTS
> > file for Nokia N900 and I see some inconsistency for twl4030-power
> > driver.
> > 
> > In board code are defined more twl4030 power scripts which override
> > defaults defined in twl4030-power code. See:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre
> > e/arch/arm/mach-omap2/board-rx51-peripherals.c#n790
> > 
> > Next in DTS file is defined just "compatible" keyword, but no
> > custom scripts, see:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre
> > e/arch/arm/boot/dts/omap3-n900.dts#n416
> > 
> > And the last in DTS file is defined line:
> > 
> > compatible = "ti,twl4030-power-n900"
> > 
> > which is not in twl4030-power driver itself, see:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre
> > e/drivers/mfd/twl4030-power.c#n851
> > 
> > So all this stuff looks like some errors when board code was ported
> > to DTS. Tony, can you look at this at all?
> 
> AFAIK it should work fine with the generic
> "ti,twl4030-power-idle-osc-off". This means reboot works and
> regulators are cut off during off mode.

Ok.

> The n900 specific code was based on something before the TI generic
> values were available I think. And the last time I looked at it I
> came to the conclusion the n900 specific code is no better.

Hm... if generic values are better, why old values are still there (in 
board n900 code)?

> Or did I miss something? Are you seeing some issues with PM with dts
> based code?

I'm just asking why we have different code for DST and board...

> We can certainly add it to twl4030-power if it provides something
> that the "ti,twl4030-power-idle-osc-off" does not.

But do we need 'compatible = "ti,twl4030-power-n900"' specification in 
omap3-n900.dts file at all?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] [BUG] clk: rockchip: don't mark clock names as initconst

[Michael Turquette]

Quoting Heiko Stübner (2016-01-01 14:05:10)
> Am Freitag, 1. Januar 2016, 22:50:43 schrieb Arnd Bergmann:
> > On Friday 01 January 2016 18:06:30 Heiko Stübner wrote:
> > > "[PATCH] clk: rockchip: fix section mismatches with new child-clocks" [0]
> > > 
> > > should be in Mike's + Stephen's inbox since last week as well, which moves
> > > the offending new elements into separate entities, which can have
> > > __initdata attributes again.
> > > 
> > > 
> > > Heiko
> > > 
> > > [0] http://www.spinics.net/lists/arm-kernel/msg471295.html
> > 
> > The patch looks good, but for some reason, the next-20151223 kernel had no
> > problem and next-20151231 was broken, the top commits in
> > drivers/clk/rockchips are:
> 
> That is correct. next-20151223 did not contain the offending patches yet. 
> After the patches got merged into the clock-tree the kbuild-robot alerted us 
> to the __initdata issue, so I created the linked patch as fixup.

The fix has been pushed to the clk mirror. The next -next should no
longer have the section mismatch warnings.

Regards,
Mike

> 
> 
> Heiko
> 
> > 
> > commit a915e30dd26ea5f3cc2e2c044aba38ee5973d3fa
> > Merge: ce6dd266d535 b0158bb27c7b
> > Author: Michael Turquette 
> > Date:   Wed Dec 23 13:08:56 2015 -0800
> > 
> > Merge branch 'clk-rockchip' into clk-next
> > 
> > commit b0158bb27c7b6e9843f541c17b24dbd964b76db6
> > Author: Xing Zheng 
> > Date:   Tue Dec 22 22:28:01 2015 +0100
> > 
> > clk: rockchip: rk3036: include downstream muxes into fractional dividers
> > 
> > Use the newly introduced possibility to combine the fractional dividers
> > 
> > 
> >   Arnd
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cgroup: BUG: unable to handle kernel NULL pointer dereference

[Jeremiah Mahler]

Serge,

On Sat, Jan 02, 2016 at 12:24:16PM -0600, Serge E. Hallyn wrote:
[...]
> 
> Tried to reproduce with setting CONFIG_CFQ_GROUP_IOSCHED=y, but did not
> succeed.  Could you send me the .config?  Also, if someone could send
> the objdump -d output that might help.  Though really, it seems clear
> that current->nsproxy must be NULL.  Hm, that's right -  we used to have
> that issue in pidns (or was it netns) during process exit.  I don't know
> that I'll get time this afternoon, but I'll look into it asap.
> 
> thanks.

Attached is the .config I used.  I can send an objdump, but do you want
a dump of the kernel, where the cgroup code is?

-- 
- Jeremiah Mahler
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.4.0-rc7 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=m
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
# CONFIG_NUMA_BALANCING_DEFAULT_ENABLED is not set
CONFIG_CGROUPS=y
# CONFIG_INTEL_RDT is not set
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
# CONFIG_MEMCG_SWAP_ENABLED is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR

Re: Nokia N900: Proper C-states

[Daniel Lezcano]

On 01/02/2016 03:26 PM, Pali Rohár wrote:

Hello,

due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51
cpuidle parameters table)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc

we need patch cpuidle34xx.c code to fix commit for Nokia N900. See:

https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc

As Nokia N900 code is converting from legacy board code to DST, I would
like to know how to patch correctly omap3_idle_driver in DTS with
correct values measured for Nokia N900. Thanks!


Hi Pali,

the conversion to the DT based arm cpuidle driver could be a bit complex 
with one issue (index 0 != cpu_do_idle()) and one performance regression 
(cpu_pm_enter/exit will be called in retention mode, even if this is not 
needed).


It will result in a PM code only on one side and on the other side, the 
generic cpuidle-arm.c driver will be used instead with the DT 
definition. It is worth to the conversion because the result will be 
nice IMO.


Added Lorenzo who is initially author of the arm generic driver. We 
already discussed in the past about those two issues above and I think 
this is something we should improve.




--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Charity Donation

[Jeff Skoll]

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the 
largest private foundations in the world. I believe strongly in ‘giving while 
living.’ I had one idea that never changed in my mind — that you should use 
your wealth to help people and I have decided to secretly give USD2.498 Million 
to a randomly selected individual. On receipt of this email, you should count 
yourself as the individual. Kindly get back to me at your earliest convenience, 
so I know your email address is valid.

Visit the web page to know more about me: 
http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/
 or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/