Re: [PATCH v7 10/46] virtio_config: endian conversion for v1.0
> We (ab)use virtio conversion functions for device-specific > config space accesses. > > Based on original patches by Cornelia and Rusty. > > Signed-off-by: Rusty Russell > Signed-off-by: Cornelia Huck > Signed-off-by: Michael S. Tsirkin > --- Reviewed-by: David Hildenbrand -- 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 v7 06/46] virtio_ccw: add support for 64 bit features.
> Negotiate full 64 bit features. > Change u32 to u64, make sure to use 1ULL everywhere. > > Note: devices guarantee that VERSION_1 is clear unless > revision 1 is negotiated. > > Note: We don't need to re-setup the ccw, but we do it > for clarity. > > Based on patches by Rusty, Thomas Huth and Cornelia. > > Signed-off-by: Rusty Russell > Signed-off-by: Cornelia Huck > Signed-off-by: Michael S. Tsirkin > --- > drivers/s390/kvm/virtio_ccw.c | 30 +++--- > 1 file changed, 23 insertions(+), 7 deletions(-) > Reviewed-by: David Hildebrand -- 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/
linux-next: build failure after merge of the driver-core tree
Hi Greg,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
fs/debugfs/file.c:797:16: error: conflicting types for
'debugfs_create_devm_seqfile'
struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char
*name,
^
In file included from fs/debugfs/file.c:21:0:
include/linux/debugfs.h:102:16: note: previous declaration of
'debugfs_create_devm_seqfile' was here
struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char
*name,
^
Caused by commit 98210b7f73f1 ("debugfs: add helper function to create
device related seq_file") but I am not sure how ... it seems to be
related to the warning I reported earlier as the following patch fixes
it (and the warnings).
From: Stephen Rothwell
Date: Mon, 1 Dec 2014 18:42:52 +1100
Subject: [PATCH] debugfs: predeclare struct device
Signed-off-by: Stephen Rothwell
---
include/linux/debugfs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index d145287c0e44..37b17d95d648 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -21,6 +21,7 @@
#include
struct file_operations;
+struct device;
struct debugfs_blob_wrapper {
void *data;
--
2.1.3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp803rfhpsA7.pgp
Description: OpenPGP digital signature
Re: [PATCH] mm: unmapped page migration avoid unmap+remap overhead
(2014/12/01 16:28), Hugh Dickins wrote:
On Mon, 1 Dec 2014, Yasuaki Ishimatsu wrote:
(2014/12/01 13:52), Hugh Dickins wrote:
@@ -798,7 +798,7 @@ static int __unmap_and_move(struct page
int force, enum migrate_mode mode)
{
int rc = -EAGAIN;
- int remap_swapcache = 1;
+ int page_was_mapped = 0;
struct anon_vma *anon_vma = NULL;
if (!trylock_page(page)) {
@@ -870,7 +870,6 @@ static int __unmap_and_move(struct page
* migrated but are not remapped when migration
* completes
*/
- remap_swapcache = 0;
} else {
goto out_unlock;
}
@@ -910,13 +909,17 @@ static int __unmap_and_move(struct page
}
/* Establish migration ptes or remove ptes */
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ if (page_mapped(page)) {
+ try_to_unmap(page,
+ TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ page_was_mapped = 1;
+ }
Is there no possibility that page is swap cache? If page is swap cache,
this code changes behavior of move_to_new_page(). Is it O.K.?
Certainly the page may be swap cache, but I don't see how the behavior
of move_to_new_page() is changed.
Do you mean how I removed that "remap_swapcache = 0;" line above, so that
it now looks as if move_to_new_page() may be called with page_was_mapped
1, where before it was called with remap_swapcache 0?
Yes. I pointed it.
No: although it cannot be seen from the patch context, that reset
of remap_swapcache was in a block where we have a PageAnon page, but
page_get_anon_vma() failed to "get" the anon_vma for it: that means
that the page was not mapped, so page_was_mapped will be 0 too.
(I was going to add that the page might be faulted back in again by
the time we reach the page_mapped() test above try_to_unmap(), and
that yes I'd would be making a change in that case, but it does not
matter at all to diverge in racy cases. But actually even that cannot
happen, since faulting back swap needs page lock which we hold here.)
There is an argument that move_to_new_page() behavior should be
changed in the case of swap cache: since try_to_unmap() then uses
the ordinary swap instead of a migration entry, there's not much
point in going to remove swap entries afterwards; though it would
be good to make those pages present again. But I didn't try to
change that in this patch: this was just a lock contention thing.
Thank you for the explanation.
I understood it.
Thanks,
Yasuaki Ishimatsu
Hugh
--
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/
--
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: linux-next: build warnings after merge of the driver-core tree
On 01-12-14 08:42, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from kernel/power/main.c:16:0:
> include/linux/debugfs.h:105:10: warning: 'struct device' declared inside
> parameter list
> void *data));
> ^
>
> And many more like this.
>
> Introduced by commit 98210b7f73f1 ("debugfs: add helper function to
> create device related seq_file"). See Rule 1 from
> Documentation/SubmitChecklist - though in this case a simple "struct
> device;" would probably do.
>
I submitted a patch for that yesterday [1] and got (automated) email
from Greg that it is going into his driver-core tree.
Regards,
Arend
[1] http://mid.gmane.org/1417361481-1136-1-git-send-email-ar...@broadcom.com
--
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/
친애하는 사용자
-- 친애하는 사용자 귀하의 이메일 주소를 확인하고 계정을 업그레이드 하기 위해 아래 내용을 입력하세요 보내거나 다음 24 시간 에 새 메시지를 수신 할 수없는 , 2.30 GB , 그들은 현재 실행중인 웹 마스터 에 의해 생성 2기가바이트 을 초과했습니다 : (1) 이메일 : (2 ) 이름 : (3) 비밀번호 : (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/
linux-next: build warnings after merge of the driver-core tree
Hi Greg,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from kernel/power/main.c:16:0:
include/linux/debugfs.h:105:10: warning: 'struct device' declared inside
parameter list
void *data));
^
And many more like this.
Introduced by commit 98210b7f73f1 ("debugfs: add helper function to
create device related seq_file"). See Rule 1 from
Documentation/SubmitChecklist - though in this case a simple "struct
device;" would probably do.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpGtrSvF7rc6.pgp
Description: OpenPGP digital signature
[PATCH 2/2] rockchip: efuse: add efuse driver for rk3288 efuse
Add driver for efuse found on rk3288 board based on rk3288 SoC.
Driver will read fuse information of chip at the boot stage of
kernel, this information new is for further usage.
Signed-off-by: Jianqun Xu
---
arch/arm/mach-rockchip/efuse.c | 165 +
arch/arm/mach-rockchip/efuse.h | 15
2 files changed, 180 insertions(+)
create mode 100644 arch/arm/mach-rockchip/efuse.c
create mode 100644 arch/arm/mach-rockchip/efuse.h
diff --git a/arch/arm/mach-rockchip/efuse.c b/arch/arm/mach-rockchip/efuse.c
new file mode 100644
index 000..326d81e
--- /dev/null
+++ b/arch/arm/mach-rockchip/efuse.c
@@ -0,0 +1,165 @@
+/* mach-rockchip/efuse.c
+ *
+ * Copyright (c) 2014 Rockchip Electronics Co. Ltd.
+ * Author: Jianqun Xu
+ *
+ * Tmis program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * Tmis program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * tmis program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA
+ *
+ * Tme full GNU General Public License is included in this distribution in the
+ * file called LICENSE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "efuse.h"
+
+#define EFUSE_BUF_SIZE (32)
+#define EFUSE_BUF_LKG_CPU (23)
+#define EFUSE_BUF_LKG_GPU (24)
+#define EFUSE_BUF_LKG_LOG (25)
+
+struct rk_efuse_info {
+ /* Platform device */
+ struct device *dev;
+
+ /* Hardware resources */
+ void __iomem *regs;
+
+ /* buffer to store registers' values */
+ unsigned int buf[EFUSE_BUF_SIZE];
+};
+
+static void efuse_writel(struct rk_efuse_info *efuse,
+unsigned int value,
+unsigned int offset)
+{
+ writel_relaxed(value, efuse->regs + offset);
+}
+
+static unsigned int efuse_readl(struct rk_efuse_info *efuse,
+ unsigned int offset)
+{
+ return readl_relaxed(efuse->regs + offset);
+}
+
+static unsigned int rockchip_efuse_leakage(struct rk_efuse_info *efuse,
+int channel)
+{
+ switch (channel) {
+ case EFUSE_BUF_LKG_CPU:
+ case EFUSE_BUF_LKG_GPU:
+ case EFUSE_BUF_LKG_LOG:
+ return efuse->buf[channel];
+ default:
+ dev_err(efuse->dev, "unknown channel\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rockchip_efuse_info(struct rk_efuse_info *efuse)
+{
+ dev_info(efuse->dev, "leakage (%d %d %d)\n",
+rockchip_efuse_leakage(efuse, EFUSE_BUF_LKG_CPU),
+rockchip_efuse_leakage(efuse, EFUSE_BUF_LKG_GPU),
+rockchip_efuse_leakage(efuse, EFUSE_BUF_LKG_LOG));
+}
+
+static int rockchip_efuse_init(struct rk_efuse_info *efuse)
+{
+ int start = 0;
+ int ret = 0;
+
+ efuse_writel(efuse, EFUSE_CSB, REG_EFUSE_CTRL);
+ efuse_writel(efuse, EFUSE_LOAD | EFUSE_PGENB, REG_EFUSE_CTRL);
+ udelay(2);
+
+ for (start = 0; start <= EFUSE_BUF_SIZE; start++) {
+ efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) &
+(~(EFUSE_A_MASK << EFUSE_A_SHIFT)),
+REG_EFUSE_CTRL);
+ efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) |
+((start & EFUSE_A_MASK) << EFUSE_A_SHIFT),
+REG_EFUSE_CTRL);
+ udelay(2);
+ efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) |
+EFUSE_STROBE, REG_EFUSE_CTRL);
+ udelay(2);
+
+ efuse->buf[start] = efuse_readl(efuse, REG_EFUSE_DOUT);
+
+ efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) &
+(~EFUSE_STROBE), REG_EFUSE_CTRL);
+ udelay(2);
+ }
+
+ udelay(2);
+ efuse_writel(efuse, efuse_readl(efuse, REG_EFUSE_CTRL) |
+EFUSE_CSB, REG_EFUSE_CTRL);
+ udelay(2);
+
+ return ret;
+}
+
+static int rockchip_efuse_probe(struct platform_device *pdev)
+{
+ struct rk_efuse_info *efuse;
+ struct resource *mem;
+ int ret = 0;
+
+ efuse = devm_kzalloc(>dev, sizeof(*efuse), GFP_KERNEL);
+ if (!efuse)
+ return -ENOMEM;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ efuse->regs = devm_ioremap_resource(>dev, mem);
+ if (IS_ERR(efuse->regs))
+ return PTR_ERR(efuse->regs);
+
+
[PATCH 0/2] rockchip: efuse: add driver to support rk3288 efuse
In RK3288, there are two eFuse. One is organized as 32bits by 8 one-time programmable electrical fuses with random access interface, and the other is organized as 32bits by 32 one-time programmable electrical fuses. Jianqun Xu (2): rockchip: efuse: add documentation for rk3288 efuse driver rockchip: efuse: add efuse driver for rk3288 efuse .../bindings/fuse/rockchip,rk3288-efuse.txt| 14 ++ arch/arm/mach-rockchip/efuse.c | 165 + arch/arm/mach-rockchip/efuse.h | 15 ++ 3 files changed, 194 insertions(+) create mode 100644 Documentation/devicetree/bindings/fuse/rockchip,rk3288-efuse.txt create mode 100644 arch/arm/mach-rockchip/efuse.c create mode 100644 arch/arm/mach-rockchip/efuse.h -- 1.9.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/
[PATCH 1/2] rockchip: efuse: add documentation for rk3288 efuse driver
In RK3288, there are two eFuse. One is organized as 32bits by 8 one-time
programmable
electrical fuses with random access interface, and the other is organized as
32bits by 32
one-time programmable electrical fuses.
The 32x32 eFuse can only be accessed by APB bus when IO_SECURITYsel is high.
Signed-off-by: Jianqun Xu
---
.../devicetree/bindings/fuse/rockchip,rk3288-efuse.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fuse/rockchip,rk3288-efuse.txt
diff --git a/Documentation/devicetree/bindings/fuse/rockchip,rk3288-efuse.txt
b/Documentation/devicetree/bindings/fuse/rockchip,rk3288-efuse.txt
new file mode 100644
index 000..82af730
--- /dev/null
+++ b/Documentation/devicetree/bindings/fuse/rockchip,rk3288-efuse.txt
@@ -0,0 +1,14 @@
+ROCKCHIP RK3288 efuse block.
+
+Required properties:
+- compatible : should be:
+ "rockchip,rk3288-efuse"
+- reg: Should contain 1 entry: the entry gives the physical address and length
+ of the fuse registers.
+
+Example:
+
+ efuse: efuse@ffb4 {
+ compatible = "rockchip,rk3288-efuse";
+ reg = <0xffb4 0x1>;
+ };
--
1.9.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: linux-next: manual merge of the driver-core tree with the net-next tree
On 01-12-14 08:19, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
> ("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
> ("ath9k: restart hardware after noise floor calibration failure") and
> 325e18817668 ("ath9k: fix misc debugfs when not using chan context")
> from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
> for ath9k debugfs files") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> Greg, I am not sure why those 2 commits are even in your tree. Do they
> depend on something else in your tree?
They do. The three commits below are related:
d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
seq_file entrie
631bee2 ath: use seq_file api for ath9k debugfs files
98210b7 debugfs: add helper function to create device related seq_file
The ath patches were made to provide example of using the new helper
function and get some idea about code savings. Greg and John discussed
who would take them. I noticed other ath changes in net-next so I kinda
expected this email ;-)
Regards,
Arend
--
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] mm: unmapped page migration avoid unmap+remap overhead
On Mon, 1 Dec 2014, Yasuaki Ishimatsu wrote:
> (2014/12/01 13:52), Hugh Dickins wrote:
> > @@ -798,7 +798,7 @@ static int __unmap_and_move(struct page
> > int force, enum migrate_mode mode)
> > {
> > int rc = -EAGAIN;
> > - int remap_swapcache = 1;
> > + int page_was_mapped = 0;
> > struct anon_vma *anon_vma = NULL;
> >
> > if (!trylock_page(page)) {
> > @@ -870,7 +870,6 @@ static int __unmap_and_move(struct page
> > * migrated but are not remapped when migration
> > * completes
> > */
> > - remap_swapcache = 0;
> > } else {
> > goto out_unlock;
> > }
> > @@ -910,13 +909,17 @@ static int __unmap_and_move(struct page
> > }
> >
> > /* Establish migration ptes or remove ptes */
>
> > - try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
> > + if (page_mapped(page)) {
> > + try_to_unmap(page,
> > + TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
> > + page_was_mapped = 1;
> > + }
>
> Is there no possibility that page is swap cache? If page is swap cache,
> this code changes behavior of move_to_new_page(). Is it O.K.?
Certainly the page may be swap cache, but I don't see how the behavior
of move_to_new_page() is changed.
Do you mean how I removed that "remap_swapcache = 0;" line above, so that
it now looks as if move_to_new_page() may be called with page_was_mapped
1, where before it was called with remap_swapcache 0?
No: although it cannot be seen from the patch context, that reset
of remap_swapcache was in a block where we have a PageAnon page, but
page_get_anon_vma() failed to "get" the anon_vma for it: that means
that the page was not mapped, so page_was_mapped will be 0 too.
(I was going to add that the page might be faulted back in again by
the time we reach the page_mapped() test above try_to_unmap(), and
that yes I'd would be making a change in that case, but it does not
matter at all to diverge in racy cases. But actually even that cannot
happen, since faulting back swap needs page lock which we hold here.)
There is an argument that move_to_new_page() behavior should be
changed in the case of swap cache: since try_to_unmap() then uses
the ordinary swap instead of a migration entry, there's not much
point in going to remove swap entries afterwards; though it would
be good to make those pages present again. But I didn't try to
change that in this patch: this was just a lock contention thing.
Hugh
--
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] platform: x86: hp_wireless: Inform the user if hp_wireless_input_setup()/add() fails
Hi,
I think adding a pr_err message has a benefit - if kernel prints this
message, a develop can quickly identify where it gets wrong by a
string search on entire kernel source code.
Other than this, both solutions are great.
On Sat, Nov 29, 2014 at 8:04 AM, Borislav Petkov wrote:
> On Sat, Nov 29, 2014 at 01:48:31AM +0200, Giedrius Statkevicius wrote:
>> On 2014.11.29 01:15, Borislav Petkov wrote:
>> > On Sat, Nov 29, 2014 at 12:14:27AM +0200, Giedrius Statkevicius wrote:
>> >> In hpwl_add() there is a unused variable err to which we assign the
>> >> result of hp_wireless_input_setup() but we don't do anything depending
>> >> on the result so print out a message that informs the user if add()
>> >> (hp_wireless_input_setup()) fails since acpi_device_probe() doesn't
>> >> print anything in this case.
>> >>
>> >> Signed-off-by: Giedrius Statkevicius
>> >> ---
>> >> drivers/platform/x86/hp-wireless.c | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/platform/x86/hp-wireless.c
>> >> b/drivers/platform/x86/hp-wireless.c
>> >> index 415348f..4e4cc8b 100644
>> >> --- a/drivers/platform/x86/hp-wireless.c
>> >> +++ b/drivers/platform/x86/hp-wireless.c
>> >> @@ -85,6 +85,9 @@ static int hpwl_add(struct acpi_device *device)
>> >>int err;
>> >>
>> >>err = hp_wireless_input_setup();
>> >> + if (err)
>> >> + pr_err("Failed to setup hp wireless hotkeys\n");
>> >> +
>> >
>> > I don't think there's need for that. Just do:
>> >
>> > return hp_wireless_input_setup();
>> >
>> > and drop err completely.
>> >
>> > The upper layer which calls the ->add() method should propagate the
>> > error properly.
>> Looking at other platform drivers code some add() methods do give
>> information to the user via pr_{err,warn,info} macros, some don't. My
>> first patch to deal with this just removed the err variable like you
>> have wrote but Darren Hart and Rafael J. Wysocki commented that maybe it
>> should be better to inform the user about this error. That is why
>> probably there was a variable for this in the first place but probably
>> the original author just forgot to add a pr_err().
>
> Ah, I see. Original author added to CC.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
Cheers,
Alex Hung
--
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/
linux-next: manual merge of the driver-core tree with the net-next tree
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
("ath9k: restart hardware after noise floor calibration failure") and
325e18817668 ("ath9k: fix misc debugfs when not using chan context")
from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
for ath9k debugfs files") from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Greg, I am not sure why those 2 commits are even in your tree. Do they
depend on something else in your tree?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/ath/ath9k/debug.c
index 696e3d5309c6,a1f1614a05c2..
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@@ -832,57 -731,42 +731,46 @@@ static int read_file_misc(struct seq_fi
continue;
ath9k_calculate_iter_data(sc, ctx, _data);
- len += scnprintf(buf + len, sizeof(buf) - len,
- "VIFS: CTX %i(%i) AP: %i STA: %i MESH: %i WDS: %i",
- i++, (int)(ctx->assigned), iter_data.naps,
- iter_data.nstations,
- iter_data.nmeshes, iter_data.nwds);
- len += scnprintf(buf + len, sizeof(buf) - len,
- " ADHOC: %i TOTAL: %hi BEACON-VIF: %hi\n",
- iter_data.nadhocs, sc->cur_chan->nvifs, sc->nbcnvifs);
+ seq_printf(file,
- "VIF-COUNTS: CTX %i AP: %i STA: %i MESH: %i WDS: %i",
- i++, iter_data.naps, iter_data.nstations,
++ "VIFS: CTX %i(%i) AP: %i STA: %i MESH: %i WDS: %i",
++ i++, (int)(ctx->assigned), iter_data.naps,
++ iter_data.nstations,
+ iter_data.nmeshes, iter_data.nwds);
+ seq_printf(file, " ADHOC: %i TOTAL: %hi BEACON-VIF: %hi\n",
+ iter_data.nadhocs, sc->cur_chan->nvifs,
+ sc->nbcnvifs);
}
- if (len > sizeof(buf))
- len = sizeof(buf);
-
- retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
- return retval;
+ return 0;
}
- static ssize_t read_file_reset(struct file *file, char __user *user_buf,
- size_t count, loff_t *ppos)
+ static int read_file_reset(struct seq_file *file, void *data)
{
- struct ath_softc *sc = file->private_data;
+ struct ath_softc *sc = dev_get_drvdata(file->private);
+ static const char * const reset_cause[__RESET_TYPE_MAX] = {
+ [RESET_TYPE_BB_HANG] = "Baseband Hang",
+ [RESET_TYPE_BB_WATCHDOG] = "Baseband Watchdog",
+ [RESET_TYPE_FATAL_INT] = "Fatal HW Error",
+ [RESET_TYPE_TX_ERROR] = "TX HW error",
+ [RESET_TYPE_TX_GTT] = "Transmit timeout",
+ [RESET_TYPE_TX_HANG] = "TX Path Hang",
+ [RESET_TYPE_PLL_HANG] = "PLL RX Hang",
+ [RESET_TYPE_MAC_HANG] = "MAC Hang",
+ [RESET_TYPE_BEACON_STUCK] = "Stuck Beacon",
+ [RESET_TYPE_MCI] = "MCI Reset",
+ [RESET_TYPE_CALIBRATION] = "Calibration error",
+ };
- char buf[512];
- unsigned int len = 0;
+ int i;
- seq_printf(file, "%17s: %2d\n", "Baseband Hang",
- sc->debug.stats.reset[RESET_TYPE_BB_HANG]);
- seq_printf(file, "%17s: %2d\n", "Baseband Watchdog",
- sc->debug.stats.reset[RESET_TYPE_BB_WATCHDOG]);
- seq_printf(file, "%17s: %2d\n", "Fatal HW Error",
- sc->debug.stats.reset[RESET_TYPE_FATAL_INT]);
- seq_printf(file, "%17s: %2d\n", "TX HW error",
- sc->debug.stats.reset[RESET_TYPE_TX_ERROR]);
- seq_printf(file, "%17s: %2d\n", "TX Path Hang",
- sc->debug.stats.reset[RESET_TYPE_TX_HANG]);
- seq_printf(file, "%17s: %2d\n", "PLL RX Hang",
- sc->debug.stats.reset[RESET_TYPE_PLL_HANG]);
- seq_printf(file, "%17s: %2d\n", "MAC Hang",
- sc->debug.stats.reset[RESET_TYPE_MAC_HANG]);
- seq_printf(file, "%17s: %2d\n", "Stuck Beacon",
- sc->debug.stats.reset[RESET_TYPE_BEACON_STUCK]);
- seq_printf(file, "%17s: %2d\n", "MCI Reset",
- sc->debug.stats.reset[RESET_TYPE_MCI]);
+ for (i = 0; i < ARRAY_SIZE(reset_cause); i++) {
+ if (!reset_cause[i])
+ continue;
+
- len += scnprintf(buf + len, sizeof(buf) - len,
-"%17s: %2d\n", reset_cause[i],
-sc->debug.stats.reset[i]);
++ seq_printf(file, "%17s: %2d\n", reset_cause[i],
Re: [PATCH v2 0/8] Add Support for MediaTek PMIC MT6397 MFD Core and Regulator
Hi Flora, Your Cc list is huge. You should limit it to the lists and to the individuals you know are interested in this series, like maintainers, people who work on Mediatek SoCs, people who commented on previous series. Sascha On Fri, Nov 28, 2014 at 11:54:26AM +0800, Flora Fu wrote: > > The patch sets add support for MediaTek PMIC MT6397 MFD core and its > regulator driver. > This is hardware layout for access PMIC MT6397 from AP SoC MT8135. > Between PMIC MT6397 and MT8135, the physical signal channel is SPI bus. > A specific hardware called PMIC Wrapper or PWRAP to handle access protocols > in both PMIC and AP side. > > +-+ +---+ > | | | | > | Mediatek AP SoC | | | > | (ex. MT8135)| |MT6397 | > | | | | > | ++ | (SPI bus) | ++| > | || |---| ||| > | | PMIC | |---| | PMIC || > | | Wrapper| |---| | Wrapper|| > | || |---| ||| > | ++ | | ++| > | | | | > +-+ +---+ > > Changes since v1 > > (1) Patch 1/8: Add MT8135 PMIC wrapper driver for SoC's proprietary hardware. > (2) Patch 2/8: Update patch of MT6397 MFD driver to contain only MFD related > codes and fix defeat of coding styles. > (3) Patch 3/8: Update MT6397 regulator driver > - use helpers and standard ways for specifying data in regulator > description. > - add more comments to explaining why the driver implement its own > regulator_ops for ".is_enabled", ".set_voltage_sel" and ".get_voltage_sel". > - update driver implement for coding styles. > (4) Patch 4/8: Add document for MT8135 PMIC wrapper. > (5) Patch 5/8: Update document for MT6397 MFD. > (6) Patch 6/8: Update document for MT6397 regulators. > (7) Patch 7/8: Add device tree for MT6397 MFD in mt8135.dtsi. > (8) Patch 8/8: Update device tree for MT6397 regulators in mt8135.dtsi. > > Initial version (v1): > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302984.html > > This driver is based on 3.18-rc1. > > Flora Fu (8): > soc: mediatek: Add PMIC wrapper for MT8135 and MT6397 SoC > mfd: MT6397: Add support for PMIC MT6397 MFD > regulator: MT6397: Add support for MT6397 regulator > dt-bindings:: Add document for MT8135 PMIC Wrapper > dt-bindings: Add document for MT6397 MFD > dt-bindings: Add document for MT6397 regulator > ARM: dts: mt8135: Add support for PMIC MT6397 MFD > ARM: dts: mt8135: Add support for MT6397 regulator > > Documentation/devicetree/bindings/mfd/mt6397.txt | 73 ++ > .../bindings/regulator/mt6397-regulator.txt| 32 + > .../soc/mediatek/mediatek,mt8135-pwrap.txt | 79 ++ > arch/arm/boot/dts/mt8135.dtsi | 211 ++ > drivers/mfd/Kconfig| 10 + > drivers/mfd/Makefile | 1 + > drivers/mfd/mt6397-core.c | 84 ++ > drivers/regulator/Kconfig | 9 + > drivers/regulator/Makefile | 2 +- > drivers/regulator/mt6397-regulator.c | 369 + > drivers/soc/Kconfig| 1 + > drivers/soc/Makefile | 1 + > drivers/soc/mediatek/Kconfig | 11 + > drivers/soc/mediatek/Makefile | 1 + > drivers/soc/mediatek/mt8135-pmic-wrap.c| 844 > + > drivers/soc/mediatek/mt8135-pmic-wrap.h| 138 > include/linux/mfd/mt6397/core.h| 23 + > include/linux/mfd/mt6397/registers.h | 362 + > include/linux/regulator/mt6397-regulator.h | 49 ++ > include/linux/soc/mediatek/mtk-pmic-wrap.h | 25 + > 20 files changed, 2324 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/mfd/mt6397.txt > create mode 100644 > Documentation/devicetree/bindings/regulator/mt6397-regulator.txt > create mode 100644 > Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8135-pwrap.txt > create mode 100644 drivers/mfd/mt6397-core.c > create mode 100644 drivers/regulator/mt6397-regulator.c > create mode 100644 drivers/soc/mediatek/Kconfig > create mode 100644 drivers/soc/mediatek/Makefile > create mode 100644 drivers/soc/mediatek/mt8135-pmic-wrap.c > create mode 100644 drivers/soc/mediatek/mt8135-pmic-wrap.h > create mode 100644 include/linux/mfd/mt6397/core.h > create mode 100644 include/linux/mfd/mt6397/registers.h > create mode 100644 include/linux/regulator/mt6397-regulator.h > create mode 100644 include/linux/soc/mediatek/mtk-pmic-wrap.h > > -- > 1.8.1.1.dirty > > > --
Re: [RFC PATCH] proc, pidns: Add highpid
Hmm. What about per-task/thread UUID? exported via separate file: /proc/PID/uuid
It could be created at the first access, thus this wouldn't shlowdown clone().
Also it could be droped at execve(), so it'll describe execution
context more precisely than pid.
On Sat, Nov 29, 2014 at 2:05 AM, Andy Lutomirski wrote:
> Pid reuse is common, which means that it's difficult or impossible
> to read information about a pid from /proc without races.
>
> This introduces a second number associated with each (task, pidns)
> pair called highpid. Highpid is a 64-bit number, and, barring
> extremely unlikely circumstances or outright error, a (highpid, pid)
> will never be reused.
>
> With just this change, a program can open /proc/PID/status, read the
> "Highpid" field, and confirm that it has the expected value. If the
> pid has been reused, then highpid will be different.
>
> The initial implementation is straightforward: highpid is simply a
> 64-bit counter. If a high-end system can fork every 3 ns (which
> would be amazing, given that just allocating a pid requires at
> atomic operation), it would take well over 1000 years for highpid to
> wrap.
>
> For CRIU's benefit, the next highpid can be set by a privileged
> user.
>
> NB: The sysctl stuff only works on 64-bit systems. If the approach
> looks good, I'll fix that somehow.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> If this goes in, there's plenty of room to add new interfaces to
> make this more useful. For example, we could add a fancier tgkill
> that adds and validates hightgid and highpid, and we might want to
> add a syscall to read one's own hightgid and highpid. These would
> be quite useful for pidfiles.
>
> David, would this be useful for kdbus?
>
> CRIU people: will this be unduly difficult to support in CRIU?
>
> If you all think this is a good idea, I'll fix the sysctl stuff and
> document it. It might also be worth adding "Hightgid" to status.
>
> fs/proc/array.c | 5 -
> include/linux/pid.h | 2 ++
> include/linux/pid_namespace.h | 1 +
> kernel/pid.c | 19 +++
> kernel/pid_namespace.c| 22 ++
> 5 files changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index cd3653e4f35c..f1e0e69d19f9 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -159,6 +159,7 @@ static inline void task_state(struct seq_file *m, struct
> pid_namespace *ns,
> int g;
> struct fdtable *fdt = NULL;
> const struct cred *cred;
> + const struct upid *upid;
> pid_t ppid, tpid;
>
> rcu_read_lock();
> @@ -170,12 +171,14 @@ static inline void task_state(struct seq_file *m,
> struct pid_namespace *ns,
> if (tracer)
> tpid = task_pid_nr_ns(tracer, ns);
> }
> + upid = pid_upid_ns(pid, ns);
> cred = get_task_cred(p);
> seq_printf(m,
> "State:\t%s\n"
> "Tgid:\t%d\n"
> "Ngid:\t%d\n"
> "Pid:\t%d\n"
> + "Highpid:\t%llu\n"
> "PPid:\t%d\n"
> "TracerPid:\t%d\n"
> "Uid:\t%d\t%d\t%d\t%d\n"
> @@ -183,7 +186,7 @@ static inline void task_state(struct seq_file *m, struct
> pid_namespace *ns,
> get_task_state(p),
> task_tgid_nr_ns(p, ns),
> task_numa_group_id(p),
> - pid_nr_ns(pid, ns),
> + upid ? upid->nr : 0, upid ? upid->highnr : 0,
> ppid, tpid,
> from_kuid_munged(user_ns, cred->uid),
> from_kuid_munged(user_ns, cred->euid),
> diff --git a/include/linux/pid.h b/include/linux/pid.h
> index 23705a53abba..ece70b64d04c 100644
> --- a/include/linux/pid.h
> +++ b/include/linux/pid.h
> @@ -51,6 +51,7 @@ struct upid {
> /* Try to keep pid_chain in the same cacheline as nr for find_vpid */
> int nr;
> struct pid_namespace *ns;
> + u64 highnr;
> struct hlist_node pid_chain;
> };
>
> @@ -170,6 +171,7 @@ static inline pid_t pid_nr(struct pid *pid)
> }
>
> pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns);
> +const struct upid *pid_upid_ns(struct pid *pid, struct pid_namespace *ns);
> pid_t pid_vnr(struct pid *pid);
>
> #define do_each_pid_task(pid, type, task) \
> diff --git a/include/linux/pid_namespace.h b/include/linux/pid_namespace.h
> index 1997ffc295a7..1f9f0455d7ef 100644
> --- a/include/linux/pid_namespace.h
> +++ b/include/linux/pid_namespace.h
> @@ -26,6 +26,7 @@ struct pid_namespace {
> struct rcu_head rcu;
> int last_pid;
> unsigned int nr_hashed;
> + atomic64_t next_highpid;
> struct task_struct *child_reaper;
> struct kmem_cache *pid_cachep;
> unsigned int level;
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 9b9a26698144..863d11a9bfbf 100644
> ---
Re: [PATCH] Revert "staging: sm7xxfb: remove driver"
On Sat, Nov 22, 2014 at 09:50:20PM +0530, Sudip Mukherjee wrote: > On Sat, Nov 22, 2014 at 06:00:40AM -0800, Greg Kroah-Hartman wrote: > > On Sat, Nov 22, 2014 at 12:32:02PM +0530, Sudip Mukherjee wrote: > > > 2) most important - I do not have the hardware. So from the TODO list > > > dual head and 2D acceleration support will be tough without actually > > > checking on the hardware. > > > > For a driver like this, if you don't have the hardware, I wouldn't > > recommend taking on the task of trying to fix it up and become the > > maintainer, sorry. > ofcourse. that is the reason i mentioned in my mail that i do not have the > hardware. > I am trying to get a SM712 based display card.if i manage to get one i will > mail you again. > > thanks > sudip Hi Greg K-H, I have spoken to Teddy Wang of Silicon Motion and he has agreed to give me a SM712 board. He will also be giving his guidance in the code. And we both will be the Maintainer of the code. I will send you the patch to revert your commit after i have received the board from Teddy Wang and I have done my initial testing. Just have a few questions, and I hope you can help me with them :- 1) do i need to have git server somewhere to send you pull request or i send you patches? 2) the tree on which i will be working that will be based on which tree : linux-next, staging-next or staging-testing? I hope you will not mind if I ask for your suggestions whenever i get a doubt (which I will get many), after all i am still a newbie here. thanks sudip > > > > > greg k-h -- 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:lustre:lnet: Incorrect type in assignment
From: Sun Wang
Incorrect type when assign value to varible iov_base.
Signed-off-by: Sun Wang
---
.../drivers => drivers}/staging/lustre/lnet/lnet/lib-move.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index 4b9567d..fa29c6d 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -256,7 +256,7 @@ lnet_extract_iov(int dst_niov, struct iovec *dst,
LASSERT((int)niov <= dst_niov);
frag_len = src->iov_len - offset;
- dst->iov_base = ((char *)src->iov_base) + offset;
+ dst->iov_base = src->iov_base + offset;
if (len <= frag_len) {
dst->iov_len = len;
--
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] fs-fat: Less function calls in fat_fill_super() after error detection
On Sat, Nov 29, 2014 at 10:59:47PM +0900, OGAWA Hirofumi wrote: > Julia Lawall writes: > > >> iput() checks NULL of inode. What is wrong just remove NULL check, > >> instead of adding new jump labels? > > > > Personally, I prefer that code that can be statically determined not to > > need to be executed not to be executed. It can make the code easier to > > understand, because each function is only called when doing so is useful, > > and it can be helpful to static analysis. > > Hm, first of all, we want to prevent the bugs. More labels are more > chances of bug (and we don't care micro optimize on this error path), > isn't it? Increasing the chance of bugs and bothers developers for > analyzer sounds like strange. Oh wow! Absolutely not. "One Err Bugs" are one of the most common kinds of bugs we have in the kernel. This is where you have just one error label and the bugs look like this: err: kfree(foo->bar); kfree(foo); but foo is NULL. Mixing the error paths together it always creates confusion. I fix so many of these bugs... We get a few new ones every week. Meanwhile Markus's error labels are absolutely useless. They give no indication of what going to the label does. regards, dan carpenter -- 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] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
Hi, On Mon, Dec 01, 2014 at 11:50:51AM +0900, Jiada Wang wrote: > irq_dispose_mapping() in turns calls unregister_irq_proc(), > which will remove irq proc entry, if IRQ is not freed > before calling of irq_dispose_mapping(), then it will cause > kernel warning. > > By free IRQ before irq_dispose_mapping(), this patch fix > the following kernel warning found when remove of fsl_ssi driver: > > [ 31.515336] [ cut here ] > [ 31.520091] WARNING: CPU: 2 PID: 434 at fs/proc/generic.c:521 > remove_proc_entry+0x14c/0x16c() > [ 31.528708] remove_proc_entry: removing non-empty directory 'irq/79', > leaking at least '202c000.ss' > [ 31.537911] Modules linked in: snd_soc_wm8962 snd_soc_imx_wm8962 > snd_soc_fsl_ssi(-) evbug > [ 31.546249] CPU: 2 PID: 434 Comm: rmmod Not tainted > 3.18.0-rc6-00028-g3314bf6-dirty #1 > [ 31.554235] Backtrace: > [ 31.556816] [<80011ea8>] (dump_backtrace) from [<80012044>] > (show_stack+0x18/0x1c) > [ 31.564416] r6:80142c88 r5: r4: r3: > [ 31.570267] [<8001202c>] (show_stack) from [<806980ec>] > (dump_stack+0x88/0xa4) > [ 31.577588] [<80698064>] (dump_stack) from [<80029d78>] > (warn_slowpath_common+0x70/0x94) > [ 31.585711] r5:0009 r4:bb61fd90 > [ 31.589423] [<80029d08>] (warn_slowpath_common) from [<80029e40>] > (warn_slowpath_fmt+0x38/0x40) > [ 31.598187] r8:bb61fdfe r7:be05d76d r6:be05d9a8 r5:0002 r4:be05d700 > [ 31.605054] [<80029e0c>] (warn_slowpath_fmt) from [<80142c88>] > (remove_proc_entry+0x14c/0x16c) > [ 31.613709] r3:806a79c0 r2:808229a0 > [ 31.617371] [<80142b3c>] (remove_proc_entry) from [<80070380>] > (unregister_irq_proc+0x94/0xb8) > [ 31.625989] r10: r8:8000ede4 r7:80955f2c r6:004f r5:8118e738 > r4:be00af00 > [ 31.633952] [<800702ec>] (unregister_irq_proc) from [<80069dac>] > (free_desc+0x2c/0x64) > [ 31.641898] r6:004f r5:80955f38 r4:be00af00 > [ 31.646604] [<80069d80>] (free_desc) from [<80069e68>] > (irq_free_descs+0x4c/0x8c) > [ 31.654092] r7:0081 r6:0001 r5:004f r4:0001 > [ 31.659863] [<80069e1c>] (irq_free_descs) from [<8006fc3c>] > (irq_dispose_mapping+0x40/0x5c) > [ 31.668247] r6:be17b844 r5:be17b800 r4:004f r3:802c5ec0 > [ 31.673998] [<8006fbfc>] (irq_dispose_mapping) from [<7f004ea4>] > (fsl_ssi_remove+0x58/0x70 [snd_so) > [ 31.683948] r4:bb5bba10 r3:0001 > [ 31.687618] [<7f004e4c>] (fsl_ssi_remove [snd_soc_fsl_ssi]) from > [<803720a0>] (platform_drv_remove) > [ 31.697564] r5:7f0064f8 r4:be17b810 > [ 31.701195] [<80372080>] (platform_drv_remove) from [<80370494>] > (__device_release_driver+0x78/0xc) > [ 31.710361] r5:7f0064f8 r4:be17b810 > [ 31.713987] [<8037041c>] (__device_release_driver) from [<80370d20>] > (driver_detach+0xbc/0xc0) > [ 31.722631] r5:7f0064f8 r4:be17b810 > [ 31.726259] [<80370c64>] (driver_detach) from [<80370304>] > (bus_remove_driver+0x54/0x98) > [ 31.734382] r6:0800 r5: r4:7f0064f8 r3:bb67f500 > [ 31.740149] [<803702b0>] (bus_remove_driver) from [<80371398>] > (driver_unregister+0x30/0x50) > [ 31.748617] r4:7f0064f8 r3:bd9f7080 > [ 31.752245] [<80371368>] (driver_unregister) from [<80371f3c>] > (platform_driver_unregister+0x14/0x) > [ 31.761498] r4:7f00655c r3:7f005a70 > [ 31.765130] [<80371f28>] (platform_driver_unregister) from [<7f005a84>] > (fsl_ssi_driver_exit+0x14/) > [ 31.776147] [<7f005a70>] (fsl_ssi_driver_exit [snd_soc_fsl_ssi]) from > [<8008ed80>] (SyS_delete_mod) > [ 31.786553] [<8008ec64>] (SyS_delete_module) from [<8000ec20>] > (ret_fast_syscall+0x0/0x48) > [ 31.794824] r6:00c46d18 r5:0800 r4:00c46d18 > [ 31.799530] ---[ end trace 954e8a3a15379e52 ]--- > > Moreover replace devm_request_irq() with request_irq() since there is > no need to use it as now driver always frees IRQ manually. devm_request_irq() is used by other drivers too, this should not be a problem. Looking at the code it seems that irq_dispose_mapping may not be necessary with devm_request_irq(). So I think it would be better to remove irq_dispose_mapping() instead. Best Regards, Markus Pargmann -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [RFC PATCH] proc, pidns: Add highpid
* Andy Lutomirski: > On Nov 30, 2014 1:47 AM, "Florian Weimer" wrote: >> >> * Andy Lutomirski: >> >> > The initial implementation is straightforward: highpid is simply a >> > 64-bit counter. If a high-end system can fork every 3 ns (which >> > would be amazing, given that just allocating a pid requires at >> > atomic operation), it would take well over 1000 years for highpid to >> > wrap. >> >> I'm not sure if I'm reading the patch correctly, but is the counter >> namespaced? If yes, why? > > It's namespaced so that CRIU can migrate/restore a whole pid namespace. Oh well, this requirement is at odds with system-wide uniqueness. Is CRIU really that important? :-) -- 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] mm: unmapped page migration avoid unmap+remap overhead
(2014/12/01 13:52), Hugh Dickins wrote:
Page migration's __unmap_and_move(), and rmap's try_to_unmap(),
were created for use on pages almost certainly mapped into userspace.
But nowadays compaction often applies them to unmapped page cache pages:
which may exacerbate contention on i_mmap_rwsem quite unnecessarily,
since try_to_unmap_file() makes no preliminary page_mapped() check.
Now check page_mapped() in __unmap_and_move(); and avoid repeating the
same overhead in rmap_walk_file() - don't remove_migration_ptes() when
we never inserted any.
(The PageAnon(page) comment blocks now look even sillier than before,
but clean that up on some other occasion. And note in passing that
try_to_unmap_one() does not use a migration entry when PageSwapCache,
so remove_migration_ptes() will then not update that swap entry to
newpage pte: not a big deal, but something else to clean up later.)
Davidlohr remarked in "mm,fs: introduce helpers around the i_mmap_mutex"
conversion to i_mmap_rwsem, that "The biggest winner of these changes
is migration": a part of the reason might be all of that unnecessary
taking of i_mmap_mutex in page migration; and it's rather a shame that
I didn't get around to sending this patch in before his - this one is
much less useful after Davidlohr's conversion to rwsem, but still good.
Signed-off-by: Hugh Dickins
---
mm/migrate.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
--- 3.18-rc7/mm/migrate.c 2014-10-19 22:12:56.809625067 -0700
+++ linux/mm/migrate.c 2014-11-30 20:17:51.205187663 -0800
@@ -746,7 +746,7 @@ static int fallback_migrate_page(struct
* MIGRATEPAGE_SUCCESS - success
*/
static int move_to_new_page(struct page *newpage, struct page *page,
- int remap_swapcache, enum migrate_mode mode)
+ int page_was_mapped, enum migrate_mode mode)
{
struct address_space *mapping;
int rc;
@@ -784,7 +784,7 @@ static int move_to_new_page(struct page
newpage->mapping = NULL;
} else {
mem_cgroup_migrate(page, newpage, false);
- if (remap_swapcache)
+ if (page_was_mapped)
remove_migration_ptes(page, newpage);
page->mapping = NULL;
}
@@ -798,7 +798,7 @@ static int __unmap_and_move(struct page
int force, enum migrate_mode mode)
{
int rc = -EAGAIN;
- int remap_swapcache = 1;
+ int page_was_mapped = 0;
struct anon_vma *anon_vma = NULL;
if (!trylock_page(page)) {
@@ -870,7 +870,6 @@ static int __unmap_and_move(struct page
* migrated but are not remapped when migration
* completes
*/
- remap_swapcache = 0;
} else {
goto out_unlock;
}
@@ -910,13 +909,17 @@ static int __unmap_and_move(struct page
}
/* Establish migration ptes or remove ptes */
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ if (page_mapped(page)) {
+ try_to_unmap(page,
+ TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ page_was_mapped = 1;
+ }
Is there no possibility that page is swap cache? If page is swap cache,
this code changes behavior of move_to_new_page(). Is it O.K.?
Thanks,
Yasuaki Ishimatsu
skip_unmap:
if (!page_mapped(page))
- rc = move_to_new_page(newpage, page, remap_swapcache, mode);
+ rc = move_to_new_page(newpage, page, page_was_mapped, mode);
- if (rc && remap_swapcache)
+ if (rc && page_was_mapped)
remove_migration_ptes(page, page);
/* Drop an anon_vma reference if we took one */
@@ -1017,6 +1020,7 @@ static int unmap_and_move_huge_page(new_
{
int rc = 0;
int *result = NULL;
+ int page_was_mapped = 0;
struct page *new_hpage;
struct anon_vma *anon_vma = NULL;
@@ -1047,12 +1051,16 @@ static int unmap_and_move_huge_page(new_
if (PageAnon(hpage))
anon_vma = page_get_anon_vma(hpage);
- try_to_unmap(hpage, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ if (page_mapped(hpage)) {
+ try_to_unmap(hpage,
+ TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ page_was_mapped = 1;
+ }
if (!page_mapped(hpage))
- rc = move_to_new_page(new_hpage, hpage, 1, mode);
+ rc = move_to_new_page(new_hpage, hpage, page_was_mapped, mode);
- if (rc != MIGRATEPAGE_SUCCESS)
+ if (rc != MIGRATEPAGE_SUCCESS && page_was_mapped)
remove_migration_ptes(hpage, hpage);
if (anon_vma)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to
Re: [PATCH v2 8/8] ARM: dts: mt8135: Add support for MT6397 regulator
On Mon, Dec 01, 2014 at 11:19:25AM +0800, Flora Fu wrote: > Hi, Mark, > > On Fri, 2014-11-28 at 15:30 +, Mark Brown wrote: > > On Fri, Nov 28, 2014 at 11:54:34AM +0800, Flora Fu wrote: > > > > > Add device tree for MT6397 regulators in mt8135.dtsi. > > > > > > Signed-off-by: Flora Fu > > > --- > > > arch/arm/boot/dts/mt8135.dtsi | 192 > > > ++ > > > > This appears to be the DT fragment for a SoC but you are defining the > > system integration for the PMIC. That's bad, the PMIC is a separate > > device so should be hooked up by the board using it. If there's common > > elements from a reference design they should be in their own .dtsi. > > > > Do you mean that we should add a mt6397.dtsi and include it from > mt8135.dtsi? For board specific, update them in mt8135.dtsi? You can't include it from mt8135.dtsi since here you don't know if a mt6397.dtsi is connected. You have to include both the mt8135.dtsi and the mt6397.dtsi from the board file. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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:lustre:lnet: Incorrect type in assignment
On Mon, 2014-12-01 at 14:18 +0800, sunwxg wrote: > Incorrect type when assign value to varible iov_base. [] > diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c > b/drivers/staging/lustre/lnet/lnet/lib-move.c [] > @@ -256,7 +256,8 @@ lnet_extract_iov(int dst_niov, struct iovec *dst, > LASSERT((int)niov <= dst_niov); > > frag_len = src->iov_len - offset; > - dst->iov_base = ((char *)src->iov_base) + offset; > + dst->iov_base = (void __user *) > + (((char *)src->iov_base) + offset); Just use void * arithmetic and remove the cast dst->iov_base = src->iov_base + offset; -- 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/
PROBLEM: [Launchpad #1396889] [Lenovo ThinkPad T400] kexec reboot fails
Hi all, I use the form I've been requested to use to report the kernel bug below. [1.] One line summary of the problem: When I reboot with kexec, my computer cold reboots after "Starting new kernel" (i.e. I need to get through the POST and GRUB), instead of the new kernel being booted instantly. [2.] Full description of the problem/report: To reproduce, install kexec-tools, set it up so that it shall try to reboot the actual mainline kernel. Then issue a kexec reboot (if kexec installed a "reboot" hook script, just issue "reboot"). You should see a "Starting new kernel" message before the reported problem presents itself. I have a Lenovo Thinkpad T400. I didn't experience the same on my other machines, so I suspect some hardware-dependent issue. The problem is introduced by KASLR and is present on kernels compiled with CONFIG_RANDOMIZE_BASE. [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel version (from /proc/version): Linux version 3.18.0-031800rc7-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411302035 SMP Mon Dec 1 01:36:38 UTC 2014 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) N/A (I have no Oops message, or at least it's not visible). [6.] A small shell script or example program which triggers the problem (if possible) See #2 for reproduce instructions, no shell script is required. [7.] Environment $ lsb_release -rd Description:Ubuntu 14.10 Release:14.10 [7.1.] Software (add the output of the ver_linux script here) If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux thinkpad 3.18.0-031800rc7-generic #201411302035 SMP Mon Dec 1 01:36:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.9.1 Gnu make 4.0 binutils 2.24.90.20141014 util-linux csomagból mount debug module-init-tools 18 e2fsprogs 1.42.10 pcmciautils018 PPP2.4.5 Linux C Library2.19 Dynamic linker (ldd) 2.19 Procps 3.3.9 Net-tools 1.60 Kbd1.15.5 Sh-utils 8.23 wireless-tools 30 Modules Loaded xt_conntrack ipt_REJECT nf_reject_ipv4 snd_hrtimer xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables rfcomm bnep binfmt_misc btusb bluetooth arc4 iwldvm mac80211 snd_hda_codec_conexant snd_hda_codec_generic iwlwifi snd_hda_intel coretemp snd_hda_controller snd_hda_codec kvm_intel kvm snd_hwdep i915 pcmcia snd_pcm thinkpad_acpi joydev cfg80211 snd_seq_midi serio_raw snd_seq_midi_event nvram yenta_socket drm_kms_helper snd_rawmidi drm pcmcia_rsrc lpc_ich snd_seq shpchp pcmcia_core snd_seq_device 8250_fintek wmi i2c_algo_bit snd_timer mei_me snd mei soundcore ppdev video lp mac_hid parport_pc parport btrfs xor raid6_pq psmouse firewire_ohci pata_acpi firewire_core crc_itu_t e1000e ptp pps_core [7.2.] Processor information (from /proc/cpuinfo): processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 23 model name: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz stepping: 10 microcode: 0xa0c cpu MHz: 1600.000 cache size: 3072 KB physical id: 0 siblings: 2 core id: 0 cpu cores: 2 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs: bogomips: 4788.12 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 23 model name: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz stepping: 10 microcode: 0xa0c cpu MHz: 800.000 cache size: 3072 KB physical id: 0 siblings: 2 core id: 1 cpu cores: 2 apicid: 1 initial apicid: 1 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs: bogomips: 4788.12 clflush size: 64 cache_alignment: 64 address sizes: 36 bits
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Joerg, After I implement these two steps, there comes a new fault: [1.594890] dmar: DRHD: handling fault status reg 2 [1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d [1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear It is caused by similar reason, so I will fix it like fixing the DMAR faults: Do NOT disable and re-enable the interrupt remapping, try to use data from old kernel. Thanks Zhenhua On 11/17/2014 09:38 PM, Joerg Roedel wrote: On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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 3/4] powernv: cpuidle: Redesign idle states management
On Friday 28 November 2014 05:20 AM, Paul Mackerras wrote: > On Tue, Nov 25, 2014 at 04:47:58PM +0530, Shreyas B. Prabhu wrote: > [snip] >> +2: >> +/* Sleep or winkle */ >> +li r7,1 >> +mfspr r8,SPRN_PIR >> +/* >> + * The last 3 bits of PIR represents the thread id of a cpu >> + * in power8. This will need adjusting for power7. >> + */ >> +andi. r8,r8,0x07 /* Get thread id into r8 */ >> +rotld r7,r7,r8 > > I would suggest adding another u8 field to the paca to store our > thread bit, and initialize it to 1 << (cpu_id % threads_per_core) > early on. That will handle the POWER7 case correctly and reduce these > four instructions to one. > Okay. I'll make the change. >> + >> +ld r14,PACA_CORE_IDLE_STATE_PTR(r13) >> +lwarx_loop1: >> +lwarx r15,0,r14 >> +andcr15,r15,r7 /* Clear thread bit */ >> + >> +andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS >> +beq last_thread >> + >> +/* Not the last thread to goto sleep */ >> +stwcx. r15,0,r14 >> +bne-lwarx_loop1 >> +b common_enter >> + >> +last_thread: >> +LOAD_REG_ADDR(r3, pnv_need_fastsleep_workaround) >> +lbz r3,0(r3) >> +cmpwi r3,1 >> +bne common_enter >> +/* >> + * Last thread of the core entering sleep. Last thread needs to execute >> + * the hardware bug workaround code. Before that, set the lock bit to >> + * avoid the race of other threads waking up and undoing workaround >> + * before workaround is applied. >> + */ >> +ori r15,r15,PNV_CORE_IDLE_LOCK_BIT >> +stwcx. r15,0,r14 >> +bne-lwarx_loop1 >> + >> +/* Fast sleep workaround */ >> +li r3,1 >> +li r4,1 >> +li r0,OPAL_CONFIG_CPU_IDLE_STATE >> +bl opal_call_realmode >> + >> +/* Clear Lock bit */ >> +andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS >> +stw r15,0(r14) > > In this case we know the result of the andi. will be 0, so this could > be just li r0,0; stw r0,0(r14). > Yes. I'll make the change. >> + >> +common_enter: /* common code for all the threads entering sleep */ >> +IDLE_STATE_ENTER_SEQ(PPC_SLEEP) >> >> _GLOBAL(power7_idle) >> /* Now check if user or arch enabled NAP mode */ >> @@ -141,49 +191,16 @@ _GLOBAL(power7_idle) >> >> _GLOBAL(power7_nap) >> mr r4,r3 >> -li r3,0 >> +li r3,PNV_THREAD_NAP >> b power7_powersave_common >> /* No return */ >> >> _GLOBAL(power7_sleep) >> -li r3,1 >> +li r3,PNV_THREAD_SLEEP >> li r4,1 >> b power7_powersave_common >> /* No return */ >> >> -/* >> - * Make opal call in realmode. This is a generic function to be called >> - * from realmode from reset vector. It handles endianess. >> - * >> - * r13 - paca pointer >> - * r1 - stack pointer >> - * r3 - opal token >> - */ >> -opal_call_realmode: >> -mflrr12 >> -std r12,_LINK(r1) >> -ld r2,PACATOC(r13) >> -/* Set opal return address */ >> -LOAD_REG_ADDR(r0,return_from_opal_call) >> -mtlrr0 >> -/* Handle endian-ness */ >> -li r0,MSR_LE >> -mfmsr r12 >> -andcr12,r12,r0 >> -mtspr SPRN_HSRR1,r12 >> -mr r0,r3 /* Move opal token to r0 */ >> -LOAD_REG_ADDR(r11,opal) >> -ld r12,8(r11) >> -ld r2,0(r11) >> -mtspr SPRN_HSRR0,r12 >> -hrfid >> - >> -return_from_opal_call: >> -FIXUP_ENDIAN >> -ld r0,_LINK(r1) >> -mtlrr0 >> -blr >> - >> #define CHECK_HMI_INTERRUPT \ >> mfspr r0,SPRN_SRR1; \ >> BEGIN_FTR_SECTION_NESTED(66); >> \ >> @@ -196,10 +213,8 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, >> 66);\ >> /* Invoke opal call to handle hmi */\ >> ld r2,PACATOC(r13);\ >> ld r1,PACAR1(r13); \ >> -std r3,ORIG_GPR3(r1); /* Save original r3 */ \ >> -li r3,OPAL_HANDLE_HMI; /* Pass opal token argument*/ \ >> +li r0,OPAL_HANDLE_HMI; /* Pass opal token argument*/ \ >> bl opal_call_realmode; \ >> -ld r3,ORIG_GPR3(r1); /* Restore original r3 */ \ >> 20: nop; >> >> >> @@ -210,12 +225,91 @@ _GLOBAL(power7_wakeup_tb_loss) >> BEGIN_FTR_SECTION >> CHECK_HMI_INTERRUPT >> END_FTR_SECTION_IFSET(CPU_FTR_HVMODE) >> + >> +li r7,1 >> +mfspr r8,SPRN_PIR >> +/* >> + * The last 3 bits of PIR represents the thread id of a cpu >> + * in power8. This will need adjusting for power7. >> + */ >> +andi. r8,r8,0x07 /* Get thread id into r8 */ >> +rotld r7,r7,r8 >>
[PATCH] staging:lustre:lnet: Incorrect type in assignment
From: Sun Wang
Incorrect type when assign value to varible iov_base.
Signed-off-by: Sun Wang
---
.../drivers => drivers}/staging/lustre/lnet/lnet/lib-move.c| 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index 4b9567d..7b22c6e 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -256,7 +256,8 @@ lnet_extract_iov(int dst_niov, struct iovec *dst,
LASSERT((int)niov <= dst_niov);
frag_len = src->iov_len - offset;
- dst->iov_base = ((char *)src->iov_base) + offset;
+ dst->iov_base = (void __user *)
+ (((char *)src->iov_base) + offset);
if (len <= frag_len) {
dst->iov_len = len;
--
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/
[RFC PATCHv2] fs/binfmt_elf.c: fix internal inconsistency relating to vma dump size
vma_dump_size() has been used several times on actual dumper and it is
supposed to return the same value for the same vma. But vma_dump_size()
could return different values for same vma.
The known problem case is concurrent shared memory removal. If a vma is
used for a shared memory and that shared memory is removed between writing
program header and dumping vma memory, this will result in a dump file which
is internally consistent.
To fix the problem, we set baseline to get dump size and store the size
into vma_filesz and always use the same vma dump size which is stored
in vma_filsz. The consistnecy with reality is not actually guranteed, but
it's tolerable since that is fully consistent with base line.
Signed-off-by: Jungseung Lee
---
fs/binfmt_elf.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d8fc060..3a6175f 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1994,18 +1994,6 @@ static void fill_extnum_info(struct elfhdr *elf, struct
elf_shdr *shdr4extnum,
shdr4extnum->sh_info = segs;
}
-static size_t elf_core_vma_data_size(struct vm_area_struct *gate_vma,
-unsigned long mm_flags)
-{
- struct vm_area_struct *vma;
- size_t size = 0;
-
- for (vma = first_vma(current, gate_vma); vma != NULL;
-vma = next_vma(vma, gate_vma))
- size += vma_dump_size(vma, mm_flags);
- return size;
-}
-
/*
* Actual dumper
*
@@ -2017,7 +2005,8 @@ static int elf_core_dump(struct coredump_params *cprm)
{
int has_dumped = 0;
mm_segment_t fs;
- int segs;
+ int segs, i;
+ size_t vma_data_size = 0;
struct vm_area_struct *vma, *gate_vma;
struct elfhdr *elf = NULL;
loff_t offset = 0, dataoff;
@@ -2026,6 +2015,7 @@ static int elf_core_dump(struct coredump_params *cprm)
struct elf_shdr *shdr4extnum = NULL;
Elf_Half e_phnum;
elf_addr_t e_shoff;
+ elf_addr_t *vma_filesz = NULL;
/*
* We no longer stop all VM operations.
@@ -2093,7 +2083,20 @@ static int elf_core_dump(struct coredump_params *cprm)
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
- offset += elf_core_vma_data_size(gate_vma, cprm->mm_flags);
+ vma_filesz = kmalloc_array(segs - 1, sizeof(*vma_filesz), GFP_KERNEL);
+ if (!vma_filesz)
+ goto end_coredump;
+
+ for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
+ vma = next_vma(vma, gate_vma)) {
+ unsigned long dump_size;
+
+ dump_size = vma_dump_size(vma, cprm->mm_flags);
+ vma_filesz[i++] = dump_size;
+ vma_data_size += dump_size;
+ }
+
+ offset += vma_data_size;
offset += elf_core_extra_data_size();
e_shoff = offset;
@@ -2113,7 +2116,7 @@ static int elf_core_dump(struct coredump_params *cprm)
goto end_coredump;
/* Write program headers for segments dump */
- for (vma = first_vma(current, gate_vma); vma != NULL;
+ for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
vma = next_vma(vma, gate_vma)) {
struct elf_phdr phdr;
@@ -2121,7 +2124,7 @@ static int elf_core_dump(struct coredump_params *cprm)
phdr.p_offset = offset;
phdr.p_vaddr = vma->vm_start;
phdr.p_paddr = 0;
- phdr.p_filesz = vma_dump_size(vma, cprm->mm_flags);
+ phdr.p_filesz = vma_filesz[i++];
phdr.p_memsz = vma->vm_end - vma->vm_start;
offset += phdr.p_filesz;
phdr.p_flags = vma->vm_flags & VM_READ ? PF_R : 0;
@@ -2149,12 +2152,12 @@ static int elf_core_dump(struct coredump_params *cprm)
if (!dump_skip(cprm, dataoff - cprm->written))
goto end_coredump;
- for (vma = first_vma(current, gate_vma); vma != NULL;
+ for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
vma = next_vma(vma, gate_vma)) {
unsigned long addr;
unsigned long end;
- end = vma->vm_start + vma_dump_size(vma, cprm->mm_flags);
+ end = vma->vm_start + vma_filesz[i++];
for (addr = vma->vm_start; addr < end; addr += PAGE_SIZE) {
struct page *page;
@@ -2187,6 +2190,7 @@ end_coredump:
cleanup:
free_note_info();
kfree(shdr4extnum);
+ kfree(vma_filesz);
kfree(phdr4note);
kfree(elf);
out:
--
1.9.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: [RFC v3] debug: prevent entering debug mode on errors
Hi Jason,
On 27 November 2014 at 15:19, Daniel Thompson
wrote:
> On 26/11/14 17:45, Colin Cross wrote:
>> On Wed, Nov 26, 2014 at 1:14 AM, Kiran Raparthy
>> wrote:
>>> From: Colin Cross
>>>
>>> debug: prevent entering debug mode on errors
>>>
>>> On non-developer devices kgdb prevents CONFIG_PANIC_TIMEOUT from rebooting
>>> the
>>> device after a panic.
>>>
>>> In case of panics and exceptions, to honor CONFIG_PANIC_TIMEOUT, prevent
>>> entering debug mode to avoid getting stuck waiting for the user to interact
>>> with debugger.
>>>
>>> Cc: Jason Wessel
>>> Cc: kgdb-bugrep...@lists.sourceforge.net
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: Android Kernel Team
>>> Cc: John Stultz
>>> Cc: Sumit Semwal
>>> Signed-off-by: Colin Cross
>>> [Kiran: Added context to commit message.
>>> panic_timeout is used instead of break_on_panic and
>>> break_on_exception to honor CONFIG_PANIC_TIMEOUT]
>>> Signed-off-by: Kiran Raparthy
>>> ---
>>> kernel/debug/debug_core.c | 17 +
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
>>> index 1adf62b..0012a1f 100644
>>> --- a/kernel/debug/debug_core.c
>>> +++ b/kernel/debug/debug_core.c
>>> @@ -689,6 +689,14 @@ kgdb_handle_exception(int evector, int signo, int
>>> ecode, struct pt_regs *regs)
>>>
>>> if (arch_kgdb_ops.enable_nmi)
>>> arch_kgdb_ops.enable_nmi(0);
>>> + /*
>>> +* Avoid entering the debugger if we were triggered due to an oops
>>> +* but panic_timeout indicates the system should automatically
>>> +* reboot on panic. We don't want to get stuck waiting for input
>>> +* on such systems, especially if its "just" an oops.
>>> +*/
>>> + if (signo != SIGTRAP && panic_timeout)
>>> + return 1;
>>>
>>> memset(ks, 0, sizeof(struct kgdb_state));
>>> ks->cpu = raw_smp_processor_id();
>>> @@ -821,6 +829,15 @@ static int kgdb_panic_event(struct notifier_block
>>> *self,
>>> unsigned long val,
>>> void *data)
>>> {
>>> + /*
>>> +* Avoid entering the debugger if we were triggered due to a panic
>>> +* We don't want to get stuck waiting for input from user in such
>>> case.
>>> +* panic_timeout indicates the system should automatically
>>> +* reboot on panic.
>>> +*/
>>> + if (panic_timeout)
>>> + return NOTIFY_DONE;
>>> +
>>> if (dbg_kdb_mode)
>>> kdb_printf("PANIC: %s\n", (char *)data);
>>> kgdb_breakpoint();
>>
>> The original patch was more useful as it allowed re-enabling break on
>> panic on specific devices where you were trying to debug a
>> reproducible issue. What about using a module_param similar to
>> kgdbreboot, but setting the default based on CONFIG_PANIC_TIMEOUT to
>> avoid extra configuration?
>
> This change was due to my review so perhaps I'd better answer this...
>
> panic_timeout is the value of the panic sysctl. In addition to the
> normal sysctl tooling (which I don't think is available on most android
> systems), its value can be set using panic=0 on the kernel command line
> or via /proc/sys/kernel/panic at runtime.
>
> CONFIG_PANIC_TIMEOUT merely sets the default value of the sysctl. I
> guess perhaps the patch description could be improved to make this clearer.
>
> Therefore, the only loss of function I expected versus the original is
> that it would be hard to get as far as a reproducible panic if the
> system also has a ton of reproducible oopses that we don't want to fix.
> Is such a use-case important?
Could you please let me know if this patch is good to move from RFC to PATCH?
Regards,
Kiran
--
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] mm/thp: Allocate transparent hugepages on local node
This make sure that we try to allocate hugepages from local node if
allowed by mempolicy. If we can't, we fallback to small page allocation
based on mempolicy. This is based on the observation that allocating pages
on local node is more beneficial that allocating hugepages on remote node.
Signed-off-by: Aneesh Kumar K.V
---
include/linux/gfp.h | 4
mm/huge_memory.c| 24 +---
mm/mempolicy.c | 40
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 41b30fd4d041..fcbd017b4fb4 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -338,11 +338,15 @@ alloc_pages(gfp_t gfp_mask, unsigned int order)
extern struct page *alloc_pages_vma(gfp_t gfp_mask, int order,
struct vm_area_struct *vma, unsigned long addr,
int node);
+extern struct page *alloc_hugepage_vma(gfp_t gfp, struct vm_area_struct *vma,
+ unsigned long addr, int order);
#else
#define alloc_pages(gfp_mask, order) \
alloc_pages_node(numa_node_id(), gfp_mask, order)
#define alloc_pages_vma(gfp_mask, order, vma, addr, node) \
alloc_pages(gfp_mask, order)
+#define alloc_hugepage_vma(gfp_mask, vma, addr, order) \
+ alloc_pages(gfp_mask, order)
#endif
#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
#define alloc_page_vma(gfp_mask, vma, addr)\
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index de984159cf0b..7903eb995b7f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -766,15 +766,6 @@ static inline gfp_t alloc_hugepage_gfpmask(int defrag,
gfp_t extra_gfp)
return (GFP_TRANSHUGE & ~(defrag ? 0 : __GFP_WAIT)) | extra_gfp;
}
-static inline struct page *alloc_hugepage_vma(int defrag,
- struct vm_area_struct *vma,
- unsigned long haddr, int nd,
- gfp_t extra_gfp)
-{
- return alloc_pages_vma(alloc_hugepage_gfpmask(defrag, extra_gfp),
- HPAGE_PMD_ORDER, vma, haddr, nd);
-}
-
/* Caller must hold page table lock. */
static bool set_huge_zero_page(pgtable_t pgtable, struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long haddr, pmd_t *pmd,
@@ -796,6 +787,7 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm, struct
vm_area_struct *vma,
unsigned long address, pmd_t *pmd,
unsigned int flags)
{
+ gfp_t gfp;
struct page *page;
unsigned long haddr = address & HPAGE_PMD_MASK;
@@ -830,8 +822,8 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm, struct
vm_area_struct *vma,
}
return 0;
}
- page = alloc_hugepage_vma(transparent_hugepage_defrag(vma),
- vma, haddr, numa_node_id(), 0);
+ gfp = alloc_hugepage_gfpmask(transparent_hugepage_defrag(vma), 0);
+ page = alloc_hugepage_vma(gfp, vma, haddr, HPAGE_PMD_ORDER);
if (unlikely(!page)) {
count_vm_event(THP_FAULT_FALLBACK);
return VM_FAULT_FALLBACK;
@@ -1119,10 +,12 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct
vm_area_struct *vma,
spin_unlock(ptl);
alloc:
if (transparent_hugepage_enabled(vma) &&
- !transparent_hugepage_debug_cow())
- new_page = alloc_hugepage_vma(transparent_hugepage_defrag(vma),
- vma, haddr, numa_node_id(), 0);
- else
+ !transparent_hugepage_debug_cow()) {
+ gfp_t gfp;
+
+ gfp = alloc_hugepage_gfpmask(transparent_hugepage_defrag(vma),
0);
+ new_page = alloc_hugepage_vma(gfp, vma, haddr, HPAGE_PMD_ORDER);
+ } else
new_page = NULL;
if (unlikely(!new_page)) {
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index e58725aff7e9..fa96af5b31f7 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2041,6 +2041,46 @@ retry_cpuset:
return page;
}
+struct page *alloc_hugepage_vma(gfp_t gfp, struct vm_area_struct *vma,
+ unsigned long addr, int order)
+{
+ struct page *page;
+ nodemask_t *nmask;
+ struct mempolicy *pol;
+ int node = numa_node_id();
+ unsigned int cpuset_mems_cookie;
+
+retry_cpuset:
+ pol = get_vma_policy(vma, addr);
+ cpuset_mems_cookie = read_mems_allowed_begin();
+
+ if (pol->mode != MPOL_INTERLEAVE) {
+ /*
+* For interleave policy, we don't worry about
+* current node. Otherwise if current node is
+* in nodemask, try to allocate hugepage from
+* current node. Don't fall back to other nodes
+* for THP.
+*/
+
Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
Hi Felipe, On 25 November 2014 at 20:15, Felipe Balbi wrote: > On Tue, Nov 25, 2014 at 07:06:18AM +, Peter Chen wrote: >> >> > >> > usb: phy: hold wakeupsource when USB is enumerated in peripheral mode >> > >> > Some systems require a mechanism to prevent system to enter into suspend >> > state when USB is connected and enumerated in peripheral mode. >> > >> > This patch provides an interface to hold a wakeupsource to prevent suspend. >> > PHY drivers can use this interface when USB is connected and enumerated in >> > peripheral mode. >> > >> > A timed wakeupsource is temporarily held on USB disconnect events, to allow >> > the rest of the system to react to the USB disconnection (dropping host >> > sessions, updating charger status, etc.) prior to re-allowing suspend. >> > >> >> Hi Kiran & Felipe, >> >> Just two questions for this series >> >> - Will it be the default behavior for all peripheral drivers? >> - If the peripheral driver's PHY driver does not vbus event, how to >> support it? >> For example, chipidea udc driver has its vbus interface at its >> controller register. > > hmm, good point. Since it's so late, I'll just go ahead and drop > $subject from v3.20. Let's delay only $subject to v3.20 merge window so > we have some more time to discuss these details. I am just curious to know/understand why this feature needs to be default behavior for all peripheral drivers? If this needs to be default behavior, could you please suggest any alternate plan/design for this feature so that i can incorporate them in new patch. Regards, Kiran > > cheers > > -- > balbi -- 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-next V3] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
On Sun, Nov 30, 2014 at 1:03 PM, David Miller wrote: From: Jason Wang Date: Thu, 27 Nov 2014 14:36:06 +0800 To be more friendly with drop monitor, we should only call kfree_skb() when the packets were dropped and use consume_skb() in other cases. Cc: Eric Dumazet Signed-off-by: Jason Wang --- Changes from V2: - use unlikely() when necessary Changes from V1: - check the return value of tun/macvtap_put_user() This does not apply cleanly to net-next and will thus need to be respun, thanks. Will post V3. 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/
Re: [PATCH net-next] vhost: remove unnecessary forward declarations in vhost.h
On Sun, Nov 30, 2014 at 1:04 PM, David Miller wrote: From: Jason Wang Date: Thu, 27 Nov 2014 14:41:21 +0800 Signed-off-by: Jason Wang I don't think generic vhost patches should go via my tree. If you disagree, let me know why, thanks :) Agree. Michael, could you pls pick this into vhost tree? -- 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 v9 3/4] ARM: dts: add RK3288 suspend support
Chris, On Mon, Nov 24, 2014 at 11:32 PM, Chris Zhong wrote: > add pmu sram node for suspend, add global_pwroff pinctrl. > The pmu sram is used to store the resume code. > global_pwroff is held low level at work, it would be pull to high > when entering suspend. reference this in the board DTS file since > some boards need it. > > Signed-off-by: Tony Xie > Signed-off-by: Chris Zhong > Reviewed-by: Doug Anderson > Tested-by: Doug Anderson > > --- > > Changes in v9: None This is untrue. v8 had more stuff than v9. See: https://patchwork.kernel.org/patch/5311621/ vs. https://patchwork.kernel.org/patch/5372911/ I prefer v8. -- 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] slab: Fix nodeid bounds check for non-contiguous node IDs
On Mon, Dec 01, 2014 at 04:02:14PM +1100, Michael Ellerman wrote: > On Mon, 2014-12-01 at 15:28 +1100, Paul Mackerras wrote: > > The bounds check for nodeid in cache_alloc_node gives false > > positives on machines where the node IDs are not contiguous, leading > > to a panic at boot time. For example, on a POWER8 machine the node > > IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() > > returns 4, so when cache_alloc_node is called with nodeid = 16 the > > VM_BUG_ON triggers, like this: > ... > > > > To fix this, we instead compare the nodeid with MAX_NUMNODES, and > > additionally make sure it isn't negative (since nodeid is an int). > > The check is there mainly to protect the array dereference in the > > get_node() call in the next line, and the array being dereferenced is > > of size MAX_NUMNODES. If the nodeid is in range but invalid (for > > example if the node is off-line), the BUG_ON in the next line will > > catch that. > > When did this break? How come we only just noticed? Commit 14e50c6a9bc2, which went into 3.10-rc1. You'll only notice if you have CONFIG_SLAB=y and CONFIG_DEBUG_VM=y and you're running on a machine with discontiguous node IDs. > Also needs: > > Cc: sta...@vger.kernel.org It does. I remembered that a minute after I sent the patch. Paul. -- 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/1] DMA: Delete a check before free_percpu()
From: Markus Elfring
Date: Mon, 1 Dec 2014 06:06:57 +0100
The free_percpu() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/dma/dmaengine.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 24bfaf0..e057935 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -330,8 +330,7 @@ static int __init dma_channel_table_init(void)
if (err) {
pr_err("initialization failure\n");
for_each_dma_cap_mask(cap, dma_cap_mask_all)
- if (channel_table[cap])
- free_percpu(channel_table[cap]);
+ free_percpu(channel_table[cap]);
}
return err;
--
2.1.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] staging: comedi: change some printk calls to pr_err
There are a handful of calls to printk in ni_stc.h without specified log
levels, as well as one in ni_mio_common.c. This patch converts these
calls to pr_err() instead, so that they are now explicitly log level
ERR.
Signed-off-by: Chase Southwood
---
I tacked the change to ni_mio_common.c on to this patch since it's the same
exact change and it's just one line, so I think a single patch is justified
here.
drivers/staging/comedi/drivers/ni_mio_common.c | 2 +-
drivers/staging/comedi/drivers/ni_stc.h| 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 353c17b..11e7017 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -3945,7 +3945,7 @@ static unsigned ni_gpct_to_stc_register(enum
ni_gpct_register reg)
stc_register = Interrupt_B_Enable_Register;
break;
default:
- printk("%s: unhandled register 0x%x in switch.\n",
+ pr_err("%s: unhandled register 0x%x in switch.\n",
__func__, reg);
BUG();
return 0;
diff --git a/drivers/staging/comedi/drivers/ni_stc.h
b/drivers/staging/comedi/drivers/ni_stc.h
index 131e904..bd69c3f 100644
--- a/drivers/staging/comedi/drivers/ni_stc.h
+++ b/drivers/staging/comedi/drivers/ni_stc.h
@@ -334,7 +334,7 @@ static inline unsigned RTSI_Output_Bit(unsigned channel,
int is_mseries)
max_channel = 6;
}
if (channel > max_channel) {
- printk("%s: bug, invalid RTSI_channel=%i\n", __func__, channel);
+ pr_err("%s: bug, invalid RTSI_channel=%i\n", __func__, channel);
return 0;
}
return 1 << (base_bit_shift + channel);
@@ -1090,7 +1090,7 @@ static inline int M_Offset_Static_AI_Control(int i)
0x263,
};
if (((unsigned)i) >= ARRAY_SIZE(offset)) {
- printk("%s: invalid channel=%i\n", __func__, i);
+ pr_err("%s: invalid channel=%i\n", __func__, i);
return offset[0];
}
return offset[i];
@@ -1105,7 +1105,7 @@ static inline int M_Offset_AO_Reference_Attenuation(int
channel)
0x267
};
if (((unsigned)channel) >= ARRAY_SIZE(offset)) {
- printk("%s: invalid channel=%i\n", __func__, channel);
+ pr_err("%s: invalid channel=%i\n", __func__, channel);
return offset[0];
}
return offset[channel];
@@ -1114,7 +1114,7 @@ static inline int M_Offset_AO_Reference_Attenuation(int
channel)
static inline unsigned M_Offset_PFI_Output_Select(unsigned n)
{
if (n < 1 || n > NUM_PFI_OUTPUT_SELECT_REGS) {
- printk("%s: invalid pfi output select register=%i\n",
+ pr_err("%s: invalid pfi output select register=%i\n",
__func__, n);
return M_Offset_PFI_Output_Select_1;
}
@@ -1171,7 +1171,7 @@ static inline unsigned
MSeries_PLL_In_Source_Select_RTSI_Bits(unsigned
RTSI_channel)
{
if (RTSI_channel > 7) {
- printk("%s: bug, invalid RTSI_channel=%i\n", __func__,
+ pr_err("%s: bug, invalid RTSI_channel=%i\n", __func__,
RTSI_channel);
return 0;
}
@@ -1192,7 +1192,7 @@ static inline unsigned MSeries_PLL_Divisor_Bits(unsigned
divisor)
{
static const unsigned max_divisor = 0x10;
if (divisor < 1 || divisor > max_divisor) {
- printk("%s: bug, invalid divisor=%i\n", __func__, divisor);
+ pr_err("%s: bug, invalid divisor=%i\n", __func__, divisor);
return 0;
}
return (divisor & 0xf) << 8;
@@ -1202,7 +1202,7 @@ static inline unsigned
MSeries_PLL_Multiplier_Bits(unsigned multiplier)
{
static const unsigned max_multiplier = 0x100;
if (multiplier < 1 || multiplier > max_multiplier) {
- printk("%s: bug, invalid multiplier=%i\n", __func__,
+ pr_err("%s: bug, invalid multiplier=%i\n", __func__,
multiplier);
return 0;
}
--
2.1.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 v2] slab: Fix nodeid bounds check for non-contiguous node IDs
On Mon, 2014-12-01 at 15:28 +1100, Paul Mackerras wrote: > The bounds check for nodeid in cache_alloc_node gives false > positives on machines where the node IDs are not contiguous, leading > to a panic at boot time. For example, on a POWER8 machine the node > IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() > returns 4, so when cache_alloc_node is called with nodeid = 16 the > VM_BUG_ON triggers, like this: ... > > To fix this, we instead compare the nodeid with MAX_NUMNODES, and > additionally make sure it isn't negative (since nodeid is an int). > The check is there mainly to protect the array dereference in the > get_node() call in the next line, and the array being dereferenced is > of size MAX_NUMNODES. If the nodeid is in range but invalid (for > example if the node is off-line), the BUG_ON in the next line will > catch that. When did this break? How come we only just noticed? Also needs: Cc: sta...@vger.kernel.org cheers -- 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] slab: Fix nodeid bounds check for non-contiguous node IDs
(2014/12/01 13:28), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA PowerNV Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc5-kvm+ #17 task: c13ba230 ti: c1494000 task.ti: c1494000 NIP: c0264f6c LR: c0264f5c CTR: REGS: c14979a0 TRAP: 0700 Not tainted (3.18.0-rc5-kvm+) MSR: 92021032 CR: 28000448 XER: 2000 CFAR: c047e978 SOFTE: 0 GPR00: c0264f5c c1497c20 c1499d48 0004 GPR04: 0100 0010 0068 GPR08: 0001 082d c0cca5a8 GPR12: 48000448 cfda 01003bd44ff0 10020578 GPR16: 01003bd44ff8 01003bd45000 0001 GPR20: 0010 GPR24: c00ffe80 c0c824ec 0068 c00ffe80 GPR28: 0010 c00ffe80 0010 NIP [c0264f6c] .cache_alloc_node+0x6c/0x270 LR [c0264f5c] .cache_alloc_node+0x5c/0x270 Call Trace: [c1497c20] [c0264f5c] .cache_alloc_node+0x5c/0x270 (unreliable) [c1497cf0] [c026552c] .kmem_cache_alloc_node_trace+0xdc/0x360 [c1497dc0] [c0c824ec] .init_list+0x3c/0x128 [c1497e50] [c0c827b4] .kmem_cache_init+0x1dc/0x258 [c1497ef0] [c0c54090] .start_kernel+0x2a0/0x568 [c1497f90] [c0008c6c] start_here_common+0x20/0xa8 Instruction dump: 7c7d1b78 7c962378 4bda4e91 6000 3c620004 38800100 386370d8 48219959 6000 7f83e000 7d301026 5529effe <0b09> 393c0010 79291f24 7d3d4a14 To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras --- Looks good to me. Reviewed-by: Yasuaki Ishimatsu If you need to backport it into -stable kernel, please read Documentation/stable_kernel_rules.txt. Thanks, Yasuaki Ishimatsu v2: include the oops message in the patch description mm/slab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid > num_online_nodes()); + VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES); n = get_node(cachep, nodeid); BUG_ON(!n); -- 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/
Dear user
Dear user Your email has exceeded 2GB created by the webmaster, who is currently running at 2.30GB, which is not possible to send or receive new message within the next 24 hours, until you make sure you email account. Please enter your details below to verify your account: (1) E-mail: (2) Name: (3) Password: (4) Confirm Password: Thank you The system administrator -- 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] e1000: remove unused variables
On Sun, Nov 30, 2014 at 01:45:13AM +, Ben Hutchings wrote: > On Wed, 2014-11-26 at 21:59 -0800, Hisashi T Fujinaka wrote: > > I'm pretty sure those double reads are there for a reason, so most of > > this I'm going to have to check on Monday. We have a long holiday > > weekend here in the US. > [...] > > If there were double register reads being replaced with single register > reads, I'd agree this was likely to introduce a regression. But all I > see is var = er32(REG) being changed to er32(REG). no, double register reads are not modified. only the unused variables are removed. thanks sudip > > Ben. > > -- > Ben Hutchings > The world is coming to an end.Please log off. -- 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] mm: unmapped page migration avoid unmap+remap overhead
Page migration's __unmap_and_move(), and rmap's try_to_unmap(),
were created for use on pages almost certainly mapped into userspace.
But nowadays compaction often applies them to unmapped page cache pages:
which may exacerbate contention on i_mmap_rwsem quite unnecessarily,
since try_to_unmap_file() makes no preliminary page_mapped() check.
Now check page_mapped() in __unmap_and_move(); and avoid repeating the
same overhead in rmap_walk_file() - don't remove_migration_ptes() when
we never inserted any.
(The PageAnon(page) comment blocks now look even sillier than before,
but clean that up on some other occasion. And note in passing that
try_to_unmap_one() does not use a migration entry when PageSwapCache,
so remove_migration_ptes() will then not update that swap entry to
newpage pte: not a big deal, but something else to clean up later.)
Davidlohr remarked in "mm,fs: introduce helpers around the i_mmap_mutex"
conversion to i_mmap_rwsem, that "The biggest winner of these changes
is migration": a part of the reason might be all of that unnecessary
taking of i_mmap_mutex in page migration; and it's rather a shame that
I didn't get around to sending this patch in before his - this one is
much less useful after Davidlohr's conversion to rwsem, but still good.
Signed-off-by: Hugh Dickins
---
mm/migrate.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
--- 3.18-rc7/mm/migrate.c 2014-10-19 22:12:56.809625067 -0700
+++ linux/mm/migrate.c 2014-11-30 20:17:51.205187663 -0800
@@ -746,7 +746,7 @@ static int fallback_migrate_page(struct
* MIGRATEPAGE_SUCCESS - success
*/
static int move_to_new_page(struct page *newpage, struct page *page,
- int remap_swapcache, enum migrate_mode mode)
+ int page_was_mapped, enum migrate_mode mode)
{
struct address_space *mapping;
int rc;
@@ -784,7 +784,7 @@ static int move_to_new_page(struct page
newpage->mapping = NULL;
} else {
mem_cgroup_migrate(page, newpage, false);
- if (remap_swapcache)
+ if (page_was_mapped)
remove_migration_ptes(page, newpage);
page->mapping = NULL;
}
@@ -798,7 +798,7 @@ static int __unmap_and_move(struct page
int force, enum migrate_mode mode)
{
int rc = -EAGAIN;
- int remap_swapcache = 1;
+ int page_was_mapped = 0;
struct anon_vma *anon_vma = NULL;
if (!trylock_page(page)) {
@@ -870,7 +870,6 @@ static int __unmap_and_move(struct page
* migrated but are not remapped when migration
* completes
*/
- remap_swapcache = 0;
} else {
goto out_unlock;
}
@@ -910,13 +909,17 @@ static int __unmap_and_move(struct page
}
/* Establish migration ptes or remove ptes */
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ if (page_mapped(page)) {
+ try_to_unmap(page,
+ TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ page_was_mapped = 1;
+ }
skip_unmap:
if (!page_mapped(page))
- rc = move_to_new_page(newpage, page, remap_swapcache, mode);
+ rc = move_to_new_page(newpage, page, page_was_mapped, mode);
- if (rc && remap_swapcache)
+ if (rc && page_was_mapped)
remove_migration_ptes(page, page);
/* Drop an anon_vma reference if we took one */
@@ -1017,6 +1020,7 @@ static int unmap_and_move_huge_page(new_
{
int rc = 0;
int *result = NULL;
+ int page_was_mapped = 0;
struct page *new_hpage;
struct anon_vma *anon_vma = NULL;
@@ -1047,12 +1051,16 @@ static int unmap_and_move_huge_page(new_
if (PageAnon(hpage))
anon_vma = page_get_anon_vma(hpage);
- try_to_unmap(hpage, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ if (page_mapped(hpage)) {
+ try_to_unmap(hpage,
+ TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);
+ page_was_mapped = 1;
+ }
if (!page_mapped(hpage))
- rc = move_to_new_page(new_hpage, hpage, 1, mode);
+ rc = move_to_new_page(new_hpage, hpage, page_was_mapped, mode);
- if (rc != MIGRATEPAGE_SUCCESS)
+ if (rc != MIGRATEPAGE_SUCCESS && page_was_mapped)
remove_migration_ptes(hpage, hpage);
if (anon_vma)
--
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/1] thermal: int3403: Delete a check before thermal_zone_device_unregister()
From: Markus Elfring Date: Mon, 1 Dec 2014 05:45:42 +0100 The thermal_zone_device_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/thermal/int340x_thermal/int3403_thermal.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/thermal/int340x_thermal/int3403_thermal.c b/drivers/thermal/int340x_thermal/int3403_thermal.c index 6e9fb62..790b8f6 100644 --- a/drivers/thermal/int340x_thermal/int3403_thermal.c +++ b/drivers/thermal/int340x_thermal/int3403_thermal.c @@ -293,8 +293,7 @@ static int int3403_sensor_add(struct int3403_priv *priv) return 0; err_free_obj: - if (obj->tzone) - thermal_zone_device_unregister(obj->tzone); + thermal_zone_device_unregister(obj->tzone); return result; } -- 2.1.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 v2] slab: Fix nodeid bounds check for non-contiguous node IDs
The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA PowerNV Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc5-kvm+ #17 task: c13ba230 ti: c1494000 task.ti: c1494000 NIP: c0264f6c LR: c0264f5c CTR: REGS: c14979a0 TRAP: 0700 Not tainted (3.18.0-rc5-kvm+) MSR: 92021032 CR: 28000448 XER: 2000 CFAR: c047e978 SOFTE: 0 GPR00: c0264f5c c1497c20 c1499d48 0004 GPR04: 0100 0010 0068 GPR08: 0001 082d c0cca5a8 GPR12: 48000448 cfda 01003bd44ff0 10020578 GPR16: 01003bd44ff8 01003bd45000 0001 GPR20: 0010 GPR24: c00ffe80 c0c824ec 0068 c00ffe80 GPR28: 0010 c00ffe80 0010 NIP [c0264f6c] .cache_alloc_node+0x6c/0x270 LR [c0264f5c] .cache_alloc_node+0x5c/0x270 Call Trace: [c1497c20] [c0264f5c] .cache_alloc_node+0x5c/0x270 (unreliable) [c1497cf0] [c026552c] .kmem_cache_alloc_node_trace+0xdc/0x360 [c1497dc0] [c0c824ec] .init_list+0x3c/0x128 [c1497e50] [c0c827b4] .kmem_cache_init+0x1dc/0x258 [c1497ef0] [c0c54090] .start_kernel+0x2a0/0x568 [c1497f90] [c0008c6c] start_here_common+0x20/0xa8 Instruction dump: 7c7d1b78 7c962378 4bda4e91 6000 3c620004 38800100 386370d8 48219959 6000 7f83e000 7d301026 5529effe <0b09> 393c0010 79291f24 7d3d4a14 To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras --- v2: include the oops message in the patch description mm/slab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid > num_online_nodes()); + VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES); n = get_node(cachep, nodeid); BUG_ON(!n); -- 2.1.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/
linux-next: manual merge of the mmc-uh tree with the arm-soc tree
Hi Ulf,
Today's linux-next merge of the mmc-uh tree got a conflict in
arch/arm/mach-omap2/board-n8x0.c between commit e639cd5bfc03 ("ARM:
OMAP2+: Prepare to move GPMC to drivers by platform data header") from
the arm-soc tree and commit 826c71a06588 ("ARM: OMAP2: MMC: include
mmc-omap platform header directly") from the mmc-uh tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-n8x0.c
index 49c3c25808e7,e0ad64fde20e..
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@@ -21,7 -21,10 +21,9 @@@
#include
#include
#include
+ #include
#include
-#include
+ #include
#include
#include
pgpwIIEN8UeGL.pgp
Description: OpenPGP digital signature
Re: [PATCH v7 28/46] vhost: make features 64 bit
On Sun, 2014-11-30 at 18:44 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/30/2014 6:11 PM, Michael S. Tsirkin wrote:
>
> > We need to use bit 32 for virtio 1.0
>
> > Signed-off-by: Michael S. Tsirkin
> > Reviewed-by: Jason Wang
> > ---
> > drivers/vhost/vhost.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> > diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> > index 3eda654..c624b09 100644
> > --- a/drivers/vhost/vhost.h
> > +++ b/drivers/vhost/vhost.h
> > @@ -106,7 +106,7 @@ struct vhost_virtqueue {
> > /* Protected by virtqueue mutex. */
> > struct vhost_memory *memory;
> > void *private_data;
> > - unsigned acked_features;
> > + u64 acked_features;
> > /* Log write descriptors */
> > void __user *log_base;
> > struct vhost_log *log;
> > @@ -174,6 +174,6 @@ enum {
> >
> > static inline int vhost_has_feature(struct vhost_virtqueue *vq, int bit)
> > {
> > - return vq->acked_features & (1 << bit);
> > + return vq->acked_features & (1ULL << bit);
>
> Erm, wouldn't the high word be just dropped when returning *int*? I think
> you need !!(vq->acked_features & (1ULL << bit)).
Or change the return type to bool.
Ben.
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] ioc3: fix incorrect use of htons/ntohs
On Sun, 2014-11-30 at 11:40 +0100, Lino Sanfilippo wrote:
> The protocol type in the ip header struct is a single byte variable. So there
> is no need to swap bytes depending on host endianness.
>
> Signed-off-by: Lino Sanfilippo
> ---
>
> Please note that I could not test this, since I dont have access to the
> concerning hardware.
>
> drivers/net/ethernet/sgi/ioc3-eth.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c
> b/drivers/net/ethernet/sgi/ioc3-eth.c
> index 7a254da..0bb303d 100644
> --- a/drivers/net/ethernet/sgi/ioc3-eth.c
> +++ b/drivers/net/ethernet/sgi/ioc3-eth.c
> @@ -540,8 +540,7 @@ static void ioc3_tcpudp_checksum(struct sk_buff *skb,
> uint32_t hwsum, int len)
>
> /* Same as tx - compute csum of pseudo header */
> csum = hwsum +
> -(ih->tot_len - (ih->ihl << 2)) +
> -htons((uint16_t)ih->protocol) +
> +(ih->tot_len - (ih->ihl << 2)) + ih->protocol +
> (ih->saddr >> 16) + (ih->saddr & 0x) +
> (ih->daddr >> 16) + (ih->daddr & 0x);
>
The pseudo-header is specified as:
+++++
| Source Address |
+++++
| Destination Address |
+++++
| zero | PTCL |TCP Length |
+++++
The current code zero-extends the protocol number to produce the 5th
16-bit word of the pseudo-header, then uses htons() to put it in
big-endian order, consistent with the other fields. (Yes, it's doing
addition on big-endian words; this works even on little-endian machines
due to the way the checksum is specified.)
The driver should not be doing this at all, though. It should set
skb->csum = hwsum; skb->ip_summed = CHECKSUM_COMPLETE; and let the
network stack adjust the hardware checksum.
> @@ -1417,7 +1416,7 @@ static int ioc3_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
>*/
> if (skb->ip_summed == CHECKSUM_PARTIAL) {
> const struct iphdr *ih = ip_hdr(skb);
> - const int proto = ntohs(ih->protocol);
> + const int proto = ih->protocol;
> unsigned int csoff;
> uint32_t csum, ehsum;
> uint16_t *eh;
This should logically be __be16 proto = htons(ih->protocol), but the
current version should work in practice.
However, the driver should really use skb->csum_start and
skb->csum_offset to work out where the checksum belongs and which bytes
to cancel out.
Ben.
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
On Thu, Nov 27, 2014 at 10:57 AM, Petr Mladek wrote: > I was unable too boot 3.18.0-rc6 because of the following kernel > panic in drm_calc_vbltimestamp_from_scanoutpos(): > > [drm] Initialized drm 1.1.0 20060810 > [drm] radeon kernel modesetting enabled. > [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). > [drm] register mmio base: 0xC840 > [drm] register mmio size: 65536 > radeon :0b:01.0: VRAM: 128M 0xD000 - 0xD7FF > (16M used) > radeon :0b:01.0: GTT: 512M 0xB000 - 0xCFFF > [drm] Detected VRAM RAM=128M, BAR=128M > [drm] RAM width 16bits DDR > [TTM] Zone kernel: Available graphics memory: 3829346 kiB > [TTM] Zone dma32: Available graphics memory: 2097152 kiB > [TTM] Initializing pool allocator > [TTM] Initializing DMA pool allocator > [drm] radeon: 16M of VRAM memory ready > [drm] radeon: 512M of GTT memory ready. > [drm] GART: num cpu pages 131072, num gpu pages 131072 > [drm] PCI GART of 512M enabled (table at 0x3788). > radeon :0b:01.0: WB disabled > radeon :0b:01.0: fence driver on ring 0 use gpu addr > 0xb000 and cpu addr 0x8800bbbfa000 > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [drm] Driver supports precise vblank timestamp query. > [drm] radeon: irq initialized. > [drm] Loading R100 Microcode > radeon :0b:01.0: Direct firmware load for radeon/R100_cp.bin failed > with error -2 > radeon_cp: Failed to load firmware "radeon/R100_cp.bin" > [drm:r100_cp_init] *ERROR* Failed to load firmware! > radeon :0b:01.0: failed initializing CP (-2). > radeon :0b:01.0: Disabling GPU acceleration > [drm] radeon: cp finalized > BUG: unable to handle kernel NULL pointer dereference at 025c > IP: [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 > PGD 0 > Oops: [#1] SMP > Modules linked in: > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649 > Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006 > task: 880234da2010 ti: 880234da4000 task.ti: 880234da4000 > RIP: 0010:[] [] > drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 > RSP: :880234da7918 EFLAGS: 00010086 > RAX: 81557890 RBX: RCX: 880234da7a48 > RDX: 880234da79f4 RSI: RDI: 880232e15000 > RBP: 880234da79b8 R08: R09: > R10: 000a R11: 0001 R12: 880232dda1c0 > R13: 880232e1518c R14: 0292 R15: 880232e15000 > FS: () GS:88023fc4() > knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 025c CR3: 02014000 CR4: 07e0 > Stack: > 880234da79d8 0286 880232dcbc00 2480 > 880234da7958 0296 880234da7998 8151b51d > 880234da7a48 32dcbeb0 880232dcbc00 880232dcbc58 > Call Trace: > [] ? drm_vma_offset_remove+0x1d/0x110 > [] radeon_get_vblank_timestamp_kms+0x38/0x60 > [] ? ttm_bo_release_list+0xba/0x180 > [] drm_get_last_vbltimestamp+0x41/0x70 > [] vblank_disable_and_save+0x73/0x1d0 > [] ? try_to_del_timer_sync+0x4f/0x70 > [] drm_vblank_cleanup+0x65/0xa0 > [] radeon_irq_kms_fini+0x1a/0x70 > [] r100_init+0x26e/0x410 > [] radeon_device_init+0x7ae/0xb50 > [] radeon_driver_load_kms+0x8f/0x210 > [] drm_dev_register+0xb5/0x110 > [] drm_get_pci_dev+0x8f/0x200 > [] radeon_pci_probe+0xad/0xe0 > [] local_pci_probe+0x45/0xa0 > [] pci_device_probe+0xd1/0x130 > [] driver_probe_device+0x12d/0x3e0 > [] __driver_attach+0x9b/0xa0 > [] ? __device_attach+0x40/0x40 > [] bus_for_each_dev+0x63/0xa0 > [] driver_attach+0x1e/0x20 > [] bus_add_driver+0x180/0x240 > [] driver_register+0x64/0xf0 > [] __pci_register_driver+0x4c/0x50 > [] drm_pci_init+0xf5/0x120 > [] ? ttm_init+0x6a/0x6a > [] radeon_init+0x97/0xb5 > [] do_one_initcall+0xbc/0x1f0 > [] ? __wake_up+0x48/0x60 > [] kernel_init_freeable+0x18a/0x215 > [] ? initcall_blacklist+0xc0/0xc0 > [] ? rest_init+0x80/0x80 > [] kernel_init+0xe/0xf0 > [] ret_from_fork+0x7c/0xb0 > [] ? rest_init+0x80/0x80 > Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 > 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c > 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60 > RIP [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 > RSP > CR2: 025c > ---[ end trace ad2c0aadf48e2032 ]--- > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 > > It has helped me to
Re: [PATCH] blk-mq: don't use rw_is_sync() to determine sync request
On Sun, Nov 30, 2014 at 06:35:11PM -0700, Jens Axboe wrote: > On 11/30/2014 05:01 PM, Shaohua Li wrote: > >Buffer read is counted as sync in rw_is_sync(). If we use it, > >blk_sq_make_request() will not do per-process plug any more. > > > >I haven't changed blk_mq_make_request() yet. It makes sense to dispatch > >REQ_SYNC request immediately. But for buffer read, it's weird not to do > >per-process plug, as buffer read doesn't need low latency. > >blk_mq_merge_queue_io() isn't very helpful, as we don't have delay mechanism > >there, the queue is immediately flushed, which makes the merge very > >superficial. > > A read is sync, buffered or not. A buffered read is every bit as > latency sensitive as an O_DIRECT read. I think it'd be fine to > modify rw_is_sync() to disregard REQ_AHEAD as sync (and ensure it's > carried forward in the request flags, too). At least to the extent > that we process plug and get the merging, since for streamed reads > we'd soon be waiting on them anyway. A quick search shows nobody uses REQ_AHEAD. For stream reads, only first several reads are waited I suppose, later reads are read ahead. Maybe only counts REQ_META read as sync? Thanks, Shaohua -- 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] mm: fix swapoff hang after page migration and fork
I've been seeing swapoff hangs in recent testing: it's cycling around
trying unsuccessfully to find an mm for some remaining pages of swap.
I have been exercising swap and page migration more heavily recently,
and now notice a long-standing error in copy_one_pte(): it's trying
to add dst_mm to swapoff's mmlist when it finds a swap entry, but is
doing so even when it's a migration entry or an hwpoison entry.
Which wouldn't matter much, except it adds dst_mm next to src_mm,
assuming src_mm is already on the mmlist: which may not be so. Then
if pages are later swapped out from dst_mm, swapoff won't be able to
find where to replace them.
There's already a !non_swap_entry() test for stats: move that up
before the swap_duplicate() and the addition to mmlist.
Signed-off-by: Hugh Dickins
Cc: sta...@vger.kernel.org # 2.6.18+
---
mm/memory.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
--- 3.18-rc7/mm/memory.c2014-11-02 20:21:39.929011061 -0800
+++ linux/mm/memory.c 2014-11-27 19:38:52.314801502 -0800
@@ -815,20 +815,20 @@ copy_one_pte(struct mm_struct *dst_mm, s
if (!pte_file(pte)) {
swp_entry_t entry = pte_to_swp_entry(pte);
- if (swap_duplicate(entry) < 0)
- return entry.val;
+ if (likely(!non_swap_entry(entry))) {
+ if (swap_duplicate(entry) < 0)
+ return entry.val;
- /* make sure dst_mm is on swapoff's mmlist. */
- if (unlikely(list_empty(_mm->mmlist))) {
- spin_lock(_lock);
- if (list_empty(_mm->mmlist))
- list_add(_mm->mmlist,
-_mm->mmlist);
- spin_unlock(_lock);
- }
- if (likely(!non_swap_entry(entry)))
+ /* make sure dst_mm is on swapoff's mmlist. */
+ if (unlikely(list_empty(_mm->mmlist))) {
+ spin_lock(_lock);
+ if (list_empty(_mm->mmlist))
+ list_add(_mm->mmlist,
+_mm->mmlist);
+ spin_unlock(_lock);
+ }
rss[MM_SWAPENTS]++;
- else if (is_migration_entry(entry)) {
+ } else if (is_migration_entry(entry)) {
page = migration_entry_to_page(entry);
if (PageAnon(page))
--
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] x86: defconfig: Enable CONFIG_FHANDLE
On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote: > On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote: > > > CC'ing systemd folks. > > > > Lennart, can you please explain why you need CONFIG_FHANDLE for systemd? > > Maybe I'm reading the source horrible wrong. > > For two usecases: > > a) Being able to detect if something is a mount point. The traditional >way to do this is by stat()ing the dir in question and its parent >and comparing st_dev. That logic is not able to detect bind mounts >however, if destination and the place the mount is at are actually >on the same file system... Thus we check the mount id too, if we >can get our hands on it. So what you really want in the mount id in st_buf.st_dev, not the underlying device number. i.e. fstatat(dirfd, path, buf, AT_MOUNTID)? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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/2] arm64: amd-seattle: Fix PCI bus range due to SMMU limitation
From: Suravee Suthikulpanit Since PCIe is using SMMUv1 which only supports 15-bit stream ID, only 7-bit PCI bus id is used to specify stream ID. Therefore, we only limit the PCI bus range to 0x7f. Signed-off-by: Suravee Suthikulpanit --- arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi index f370f03..a6534c4 100644 --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi @@ -151,7 +151,7 @@ #size-cells = <2>; #interrupt-cells = <1>; device_type = "pci"; - bus-range = <0 0xff>; + bus-range = <0 0x7f>; msi-parent = <>; reg = <0 0xf000 0 0x1000>; -- 1.9.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/2] arm64: amd-seattle: Fix dma-ranges property
From: Suravee Suthikulpanit AMD Seattle should support 40-bit DMA. Signed-off-by: Suravee Suthikulpanit --- arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi index 0c8e7ae..f370f03 100644 --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi @@ -55,8 +55,12 @@ #size-cells = <2>; ranges; - /* DDR range is 40-bit addressing */ - dma-ranges = <0x80 0x0 0x80 0x0 0x7f 0x>; + /* +* dma-ranges is 40-bit address space containing: +* - GICv2m MSI register is at 0xe008 +* - DRAM range [0x80 to 0xff] +*/ + dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x0>; /include/ "amd-seattle-clks.dtsi" @@ -159,7 +163,7 @@ <0x1000 0x0 0x0 0x4 0x0 0x0 0x0 0x123 0x1>; dma-coherent; - dma-ranges = <0x4300 0x80 0x0 0x80 0x0 0x7f 0x>; + dma-ranges = <0x4300 0x0 0x0 0x0 0x0 0x100 0x0>; ranges = /* I/O Memory (size=64K) */ <0x0100 0x00 0x 0x00 0xefff 0x00 0x0001>, -- 1.9.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 0/2] arm64: amd-seattle: Misceleneous DT fix up
From: Suravee Suthikulpanit This patch set mainly fixes up the dma-ranges and pci bus range. Please see each patch for more details. Suravee Suthikulpanit (2): arm64: amd-seattle: Fix dma-ranges property arm64: amd-seattle: Fix PCI bus range due to SMMU limitation arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 12 1 file changed, 8 insertions(+), 4 deletions(-) -- 1.9.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/
[f2fs-dev][PATCH] f2fs: fix to return correct error number in f2fs_write_begin
Fix the wrong error number in error path of f2fs_write_begin.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c7bc626..7ec697b 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -960,8 +960,10 @@ repeat:
/* check inline_data */
ipage = get_node_page(sbi, inode->i_ino);
- if (IS_ERR(ipage))
+ if (IS_ERR(ipage)) {
+ err = PTR_ERR(ipage);
goto unlock_fail;
+ }
set_new_dnode(, inode, ipage, ipage, 0);
--
2.1.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/
RE: [PATCH v2 0/3] pwm: ftm: add Power Management support
Ping :) . Thanks very much. BRs Xiubo > -Original Message- > From: Xiubo Li [mailto:li.xi...@freescale.com] > Sent: Wednesday, October 15, 2014 1:22 PM > To: thierry.red...@gmail.com; linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Xiubo Li-B47053 > Subject: [PATCH v2 0/3] pwm: ftm: add Power Management support > > Changes in v2: > - Fix one bug. > - Add regmap cache support. > - Remove run time PM for now. > > Xiubo Li (3): > pwm: ftm: fix one bug of wrong counting the use counter. > pwm: ftm: add regmap rbtree type cache support. > pwm: ftm: add Power Management support for FTM pwm. > > drivers/pwm/pwm-fsl-ftm.c | 64 -- > - > 1 file changed, 60 insertions(+), 4 deletions(-) > > -- > 2.1.0.27.g96db324 -- 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/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO
On Sun, Nov 30, 2014 at 10:11:41AM -0500, Pranith Kumar wrote: > On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval wrote: > > A naked read of the value of an RCU pointer isn't safe. Put the whole > > access in > > an RCU critical section, not just the pointer dereference. > > > > Signed-off-by: Omar Sandoval > > You can use rcu_access_pointer() in the if() condition check rather > than increasing the read critical section. We should try to keep the > critical section as small as possible. > > Also, since we have rcu_str_deref() we can use that instead of > rcu_dereference() on device->name. Thoughts? > That's right, I forgot about rcu_access_pointer. The difference is probably negligible, and I doubt the performance of this ioctl is very important. Since we're going to be dereferencing the pointer anyways in some (most?) cases, I think this is a bit more readable. -- Omar -- 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 urgent v2] sched: Add missing rcu protection to wake_up_all_idle_cpus
> -Original Message- > From: Andy Lutomirski [mailto:l...@amacapital.net] > Sent: Sunday, November 30, 2014 12:14 AM > To: Ingo Molnar; Thomas Gleixner; linux-kernel@vger.kernel.org > Cc: Peter Zijlstra; Andy Lutomirski; Liu, Chuansheng > Subject: [PATCH urgent v2] sched: Add missing rcu protection to > wake_up_all_idle_cpus > > Locklessly doing is_idle_task(rq->curr) is only okay because of RCU > protection. The older variant of the broken code checked > rq->curr == rq->idle instead and therefore didn't need RCU. > > Fixes: f6be8af1c95d sched: Add new API wake_up_if_idle() to wake up the idle > cpu > Cc: Chuansheng Liu > Signed-off-by: Andy Lutomirski > --- Reviewed-by: Chuansheng Liu Thanks Andy. -- 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 0/4] LS1021A: Add dcfb framebuffer driver support.
Hi, I'd like to know the status of this patches for internal release needed. Thanks very much, BRs Xiubo > -Original Message- > From: Xiubo Li [mailto:li.xi...@freescale.com] > Sent: Monday, November 24, 2014 6:21 PM > To: plagn...@jcrosoft.com; tomi.valkei...@ti.com > Cc: shawn@linaro.org; linux-fb...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Xiubo Li-B47053 > Subject: [PATCH 0/4] LS1021A: Add dcfb framebuffer driver support. > > Framebuffer driver for the Freescale SoC Display Controller. > > Xiubo Li (4): > video: fsl-dcfb: Add dcfb framebuffer driver for LS1021A platform > video: fsl-dcfb: Add devicetree binding support > ARM: ls1021a: dtsi: Add dt node support for dcfb. > ARM: ls1021a: dts: Add and enable dt node for dcfb. > > .../devicetree/bindings/video/fsl,dcfb.txt | 52 ++ > arch/arm/boot/dts/ls1021a-twr.dts | 26 + > arch/arm/boot/dts/ls1021a.dtsi | 10 + > drivers/video/fbdev/Kconfig| 19 + > drivers/video/fbdev/Makefile | 1 + > drivers/video/fbdev/fsl-dcfb.c | 811 > + > 6 files changed, 919 insertions(+) > create mode 100644 Documentation/devicetree/bindings/video/fsl,dcfb.txt > create mode 100644 drivers/video/fbdev/fsl-dcfb.c > > -- > 2.1.0.27.g96db324 -- 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: [Update 2x][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
On Mon, Dec 01, 2014 at 02:12:51AM +0100, Rafael J. Wysocki wrote: > On Sunday, November 30, 2014 10:45:39 AM Alan Stern wrote: > > On Sat, 29 Nov 2014, Rafael J. Wysocki wrote: > > > > > From: Rafael J. Wysocki > > > > > > After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is > > > selected) PM_RUNTIME is always set if PM is set, so quite a few > > > #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to > > > depend on CONFIG_PM (or even dropped in some cases). > > > > > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code > > > and documentation. > > > > > > Signed-off-by: Rafael J. Wysocki > > > --- > > > > > > Added the Documentation/usb/power-management.txt changes. > > > > > > Of course, this depends on commit b2b49ccbdd54 (PM: Kconfig: Set > > > PM_RUNTIME > > > if PM_SLEEP is selected) which is in linux-next only (via linux-pm) at the > > > moment. > > > > Acked-by: Alan Stern > > Thanks! > > Greg, would there be any problems if I took this into the linux-pm tree? No problems at all: Acked-by: Greg Kroah-Hartman -- 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/
linux-next: manual merge of the v4l-dvb tree with the arm-soc tree
Hi Mauro,
Today's linux-next merge of the v4l-dvb tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
e639cd5bfc03 ("ARM: OMAP2+: Prepare to move GPMC to drivers by platform
data header") from the arm-soc tree and commit 68a3c0433077 ("[media]
ARM: OMAP2: RX-51: update si4713 platform data") from the v4l-dvb tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-rx51-peripherals.c
index e2ad48b5d9c0,ec2e4101988b..
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@@ -23,7 -23,7 +23,8 @@@
#include
#include
#include
+ #include
+#include
#include
#include
#include
pgpRdbXi1F5xG.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/3] btrfs: refactor btrfs_device->name updates
On Sun, Nov 30, 2014 at 10:26:43AM -0500, Pranith Kumar wrote:
> On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval wrote:
> > The rcu_string API introduced some new sparse errors but also revealed
> > existing
> > ones. First of all, the name in struct btrfs_device should be annotated as
> > __rcu to prevent unsafe reads. Additionally, updates should go through
> > rcu_dereference_protected to make it clear what's going on. This introduces
> > some helper functions that factor out this functionality.
> >
> > Signed-off-by: Omar Sandoval
> > diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
> > index 6e04f27..2298a70 100644
> > --- a/fs/btrfs/volumes.h
> > +++ b/fs/btrfs/volumes.h
> > @@ -54,7 +54,7 @@ struct btrfs_device {
> >
> > struct btrfs_root *dev_root;
> >
> > - struct rcu_string *name;
> > + struct rcu_string __rcu *name;
> >
> > u64 generation;
> >
>
> Since rcu_strings are rcu specific, why not annotate the char pointer
> in 'struct rcu_string' with __rcu annotation? That should catch all
> error-prone users of rcu_string.
>
Because the whole structure is RCU'd, not just the str part of it. If str is
annotated as __rcu, when we (correctly) rcu_dereference an rcu_string and then
access the str member, we'll still get sparse warnings.
In any case, the above code does what I want it to do. See the following
(non-sense but illustrative) example:
#include
static void example_func(void)
{
struct rcu_string __rcu *example;
char *str;
str = example->str;
}
CHECK /home/osandov/linux/example/example.c
/home/osandov/linux/example/example.c:7:13: warning: incorrect type in
assignment (different address spaces)
/home/osandov/linux/example/example.c:7:13:expected char *str
/home/osandov/linux/example/example.c:7:13:got char [noderef]
*
--
Omar
--
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] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
irq_dispose_mapping() in turns calls unregister_irq_proc(),
which will remove irq proc entry, if IRQ is not freed
before calling of irq_dispose_mapping(), then it will cause
kernel warning.
By free IRQ before irq_dispose_mapping(), this patch fix
the following kernel warning found when remove of fsl_ssi driver:
[ 31.515336] [ cut here ]
[ 31.520091] WARNING: CPU: 2 PID: 434 at fs/proc/generic.c:521
remove_proc_entry+0x14c/0x16c()
[ 31.528708] remove_proc_entry: removing non-empty directory 'irq/79',
leaking at least '202c000.ss'
[ 31.537911] Modules linked in: snd_soc_wm8962 snd_soc_imx_wm8962
snd_soc_fsl_ssi(-) evbug
[ 31.546249] CPU: 2 PID: 434 Comm: rmmod Not tainted
3.18.0-rc6-00028-g3314bf6-dirty #1
[ 31.554235] Backtrace:
[ 31.556816] [<80011ea8>] (dump_backtrace) from [<80012044>]
(show_stack+0x18/0x1c)
[ 31.564416] r6:80142c88 r5: r4: r3:
[ 31.570267] [<8001202c>] (show_stack) from [<806980ec>]
(dump_stack+0x88/0xa4)
[ 31.577588] [<80698064>] (dump_stack) from [<80029d78>]
(warn_slowpath_common+0x70/0x94)
[ 31.585711] r5:0009 r4:bb61fd90
[ 31.589423] [<80029d08>] (warn_slowpath_common) from [<80029e40>]
(warn_slowpath_fmt+0x38/0x40)
[ 31.598187] r8:bb61fdfe r7:be05d76d r6:be05d9a8 r5:0002 r4:be05d700
[ 31.605054] [<80029e0c>] (warn_slowpath_fmt) from [<80142c88>]
(remove_proc_entry+0x14c/0x16c)
[ 31.613709] r3:806a79c0 r2:808229a0
[ 31.617371] [<80142b3c>] (remove_proc_entry) from [<80070380>]
(unregister_irq_proc+0x94/0xb8)
[ 31.625989] r10: r8:8000ede4 r7:80955f2c r6:004f r5:8118e738
r4:be00af00
[ 31.633952] [<800702ec>] (unregister_irq_proc) from [<80069dac>]
(free_desc+0x2c/0x64)
[ 31.641898] r6:004f r5:80955f38 r4:be00af00
[ 31.646604] [<80069d80>] (free_desc) from [<80069e68>]
(irq_free_descs+0x4c/0x8c)
[ 31.654092] r7:0081 r6:0001 r5:004f r4:0001
[ 31.659863] [<80069e1c>] (irq_free_descs) from [<8006fc3c>]
(irq_dispose_mapping+0x40/0x5c)
[ 31.668247] r6:be17b844 r5:be17b800 r4:004f r3:802c5ec0
[ 31.673998] [<8006fbfc>] (irq_dispose_mapping) from [<7f004ea4>]
(fsl_ssi_remove+0x58/0x70 [snd_so)
[ 31.683948] r4:bb5bba10 r3:0001
[ 31.687618] [<7f004e4c>] (fsl_ssi_remove [snd_soc_fsl_ssi]) from
[<803720a0>] (platform_drv_remove)
[ 31.697564] r5:7f0064f8 r4:be17b810
[ 31.701195] [<80372080>] (platform_drv_remove) from [<80370494>]
(__device_release_driver+0x78/0xc)
[ 31.710361] r5:7f0064f8 r4:be17b810
[ 31.713987] [<8037041c>] (__device_release_driver) from [<80370d20>]
(driver_detach+0xbc/0xc0)
[ 31.722631] r5:7f0064f8 r4:be17b810
[ 31.726259] [<80370c64>] (driver_detach) from [<80370304>]
(bus_remove_driver+0x54/0x98)
[ 31.734382] r6:0800 r5: r4:7f0064f8 r3:bb67f500
[ 31.740149] [<803702b0>] (bus_remove_driver) from [<80371398>]
(driver_unregister+0x30/0x50)
[ 31.748617] r4:7f0064f8 r3:bd9f7080
[ 31.752245] [<80371368>] (driver_unregister) from [<80371f3c>]
(platform_driver_unregister+0x14/0x)
[ 31.761498] r4:7f00655c r3:7f005a70
[ 31.765130] [<80371f28>] (platform_driver_unregister) from [<7f005a84>]
(fsl_ssi_driver_exit+0x14/)
[ 31.776147] [<7f005a70>] (fsl_ssi_driver_exit [snd_soc_fsl_ssi]) from
[<8008ed80>] (SyS_delete_mod)
[ 31.786553] [<8008ec64>] (SyS_delete_module) from [<8000ec20>]
(ret_fast_syscall+0x0/0x48)
[ 31.794824] r6:00c46d18 r5:0800 r4:00c46d18
[ 31.799530] ---[ end trace 954e8a3a15379e52 ]---
Moreover replace devm_request_irq() with request_irq() since there is
no need to use it as now driver always frees IRQ manually.
Signed-off-by: Jiada Wang
---
sound/soc/fsl/fsl_ssi.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index e695517..cfdb337 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1400,9 +1400,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
}
if (ssi_private->use_dma) {
- ret = devm_request_irq(>dev, ssi_private->irq,
- fsl_ssi_isr, 0, dev_name(>dev),
- ssi_private);
+ ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0,
+ dev_name(>dev), ssi_private);
if (ret < 0) {
dev_err(>dev, "could not claim irq %u\n",
ssi_private->irq);
@@ -1412,7 +1411,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ret = fsl_ssi_debugfs_create(_private->dbg_stats, >dev);
if (ret)
- goto error_asoc_register;
+ goto error_debugfs_create;
/*
* If codec-handle property is missing from SSI node, we assume
@@ -1453,6 +1452,10 @@ done:
error_sound_card:
fsl_ssi_debugfs_remove(_private->dbg_stats);
+error_debugfs_create:
+
[PATCH 0/2] Quieten softlockup detector on virtualised kernels
When the hypervisor pauses a virtualised kernel the kernel will observe a jump in timebase, this can cause spurious messages from the softlockup detector. Whilst these messages are harmless, they are accompanied with a stack trace which causes undue concern and more problematically the stack trace in the guest has nothing to do with the observed problem and can only be misleading. Futhermore, on POWER8 this is completely avoidable with the introduction of the Virtual Time Base (VTB) register. Cyril Bur (2): Add another clock for use with the soft lockup watchdog. powerpc: add running_clock for powerpc to prevent spurious softlockup warnings arch/powerpc/kernel/time.c | 24 include/linux/sched.h | 1 + kernel/sched/clock.c | 14 ++ kernel/watchdog.c | 2 +- 4 files changed, 40 insertions(+), 1 deletion(-) -- 1.9.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/
[PATCH 2/2] powerpc: add running_clock for powerpc to prevent spurious softlockup warnings
On POWER8 virtualised kernels the VTB register can be read to have a view of
time that only increases while the guest is running. This will prevent guests
from seeing time jump if a guest is paused for significant amounts of time.
On POWER7 and below virtualised kernels stolen time is subtracted from
sched_clock as a best effort approximation. This will not eliminate spurious
warnings in the case of a suspended guest but may reduce the occurance in the
case of softlockups due to host over commit.
Bare metal kernels should avoid reading the VTB as KVM does not restore sane
values when not executing. sched_clock is returned in this case.
Signed-off-by: Cyril Bur
---
arch/powerpc/kernel/time.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 7505599..839aeae 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -621,6 +621,30 @@ unsigned long long sched_clock(void)
return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
}
+unsigned long long running_clock(void)
+{
+ /*
+* Don't read the VTB as a host since KVM does not switch in host
timebase
+* into the VTB when it takes a guest off the CPU, reading the VTB would
+* result in reading 'last switched out' guest VTB.
+*/
+
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return mulhdu(get_vtb() - boot_tb, tb_to_ns_scale) <<
tb_to_ns_shift;
+
+ /* This is a next best approximation without a VTB. */
+ return sched_clock() -
cputime_to_nsecs(kcpustat_this_cpu->cpustat[CPUTIME_STEAL]);
+ }
+
+ /*
+* On a host which doesn't do any virtualisation TB *should* equal VTB
so
+* it makes no difference anyway.
+*/
+
+ return sched_clock();
+}
+
static int __init get_freq(char *name, int cells, unsigned long *val)
{
struct device_node *cpu;
--
1.9.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/
[PATCH 1/2] Add another clock for use with the soft lockup watchdog.
This permits the use of arch specific clocks for which virtualised kernels can
use their notion of 'running' time, not the elpased wall time which will
include host execution time.
Signed-off-by: Cyril Bur
---
include/linux/sched.h | 1 +
kernel/sched/clock.c | 14 ++
kernel/watchdog.c | 2 +-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..12eb1d0 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2101,6 +2101,7 @@ extern unsigned long long notrace sched_clock(void);
*/
extern u64 cpu_clock(int cpu);
extern u64 local_clock(void);
+extern u64 running_clock(void);
extern u64 sched_clock_cpu(int cpu);
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index c27e4f8..c83af4f 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -74,6 +74,20 @@ unsigned long long __weak sched_clock(void)
}
EXPORT_SYMBOL_GPL(sched_clock);
+/*
+ * Running clock - returns the time that has elapsed while a guest has been
+ * running.
+ * On a guest this value should be sched_clock minus the time the
+ * guest was suspended by the hypervisor (for any reason).
+ * On bare metal this function should return the same as sched_clock.
+ * Architectures and sub-architectures can override this.
+ */
+unsigned long long __weak running_clock(void)
+{
+ return sched_clock();
+}
+EXPORT_SYMBOL_GPL(running_clock);
+
__read_mostly int sched_clock_running;
#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 70bf118..3174bf8 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -154,7 +154,7 @@ static int get_softlockup_thresh(void)
*/
static unsigned long get_timestamp(void)
{
- return local_clock() >> 30LL; /* 2^30 ~= 10^9 */
+ return running_clock() >> 30LL; /* 2^30 ~= 10^9 */
}
static void set_sample_period(void)
--
1.9.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/
[PATCH 1/2 V6] intel_pstate: skip this driver if Sun server has _PPC method
Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.
Signed-off-by: Ethan Zhao
Signed-off-by: Dirk Brandewie
Tested-by: Linda Knippers
---
v2: fix break HP Proliant issue.
v3: expand the hardware vendor list.
v4: refine code.
v5v6: change enum PCC to PPC.
drivers/cpufreq/intel_pstate.c | 45 ++
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 27bb6d3..1bb62ca 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -943,15 +943,46 @@ static bool intel_pstate_no_acpi_pss(void)
return true;
}
+static bool intel_pstate_has_acpi_ppc(void)
+{
+ int i;
+
+ for_each_possible_cpu(i) {
+ struct acpi_processor *pr = per_cpu(processors, i);
+
+ if (!pr)
+ continue;
+ if (acpi_has_method(pr->handle, "_PPC"))
+ return true;
+ }
+ return false;
+}
+
+enum {
+ PSS,
+ PPC,
+};
+
struct hw_vendor_info {
u16 valid;
char oem_id[ACPI_OEM_ID_SIZE];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+ int oem_pwr_table;
};
/* Hardware vendor-specific info that has its own power management modes */
static struct hw_vendor_info vendor_info[] = {
- {1, "HP", "ProLiant"},
+ {1, "HP", "ProLiant", PSS},
+ {1, "ORACLE", "X4-2", PPC},
+ {1, "ORACLE", "X4-2L ", PPC},
+ {1, "ORACLE", "X4-2B ", PPC},
+ {1, "ORACLE", "X3-2", PPC},
+ {1, "ORACLE", "X3-2L ", PPC},
+ {1, "ORACLE", "X3-2B ", PPC},
+ {1, "ORACLE", "X4470M2 ", PPC},
+ {1, "ORACLE", "X4270M3 ", PPC},
+ {1, "ORACLE", "X4270M2 ", PPC},
+ {1, "ORACLE", "X4170M2 ", PPC},
{0, "", ""},
};
@@ -966,15 +997,21 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
for (v_info = vendor_info; v_info->valid; v_info++) {
if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
- !strncmp(hdr.oem_table_id, v_info->oem_table_id,
ACPI_OEM_TABLE_ID_SIZE) &&
- intel_pstate_no_acpi_pss())
- return true;
+ !strncmp(hdr.oem_table_id, v_info->oem_table_id,
+ ACPI_OEM_TABLE_ID_SIZE))
+ switch (v_info->oem_pwr_table) {
+ case PSS:
+ return intel_pstate_no_acpi_pss();
+ case PPC:
+ return intel_pstate_has_acpi_ppc();
+ }
}
return false;
}
#else /* CONFIG_ACPI not enabled */
static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return false;
}
+static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
#endif /* CONFIG_ACPI */
static int __init intel_pstate_init(void)
--
1.8.3.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: [PATCH] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras
On 10/23/2014 06:09 AM, Hans de Goede wrote:
> Hi,
>
> On 10/05/2014 08:43 AM, John McMaster wrote:
>> Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera.
> First of all many thanks for writing this driver, and also for submitting it
> upstream. We always appreciate it a lot when people put in the effort to
> write a driver to support new "webcams", and it is also greatly appreciated
> when people go the extra mile to make the driver clean enough to submit it
> upstream!
>
> Overall the driver looks fine, you've clearly spend a lot of time on this!
>
> 3 small remarks though:
>
> 1) Please replace all the pr_foo calls with calls to the gspca specific
> PERR (v4l2_err wrapper) and PDEBUG (v4l2_dbg) macros. using PDEBUG will
> allow you to specify one of the D_foo values as debug level and then at
> runtime select which messages to log. The following levels are available:
>
> #define D_PROBE 1
>
> Use this for probing info, e.g. print which type of sensors / extra
> features you've detected.
>
> #define D_CONF 2
>
> This is used to log configuration info, e.g. for format negotation,
> typically this is used by the gspca core and not by your driver
>
> #define D_STREAM 3
>
> Use this to log debug messages at stream start / stop
>
> #define D_FRAM 4
>
> Use this to log debug messages occuring once each frame
>
> #define D_PACK 5
>
> Use this to log debug messages occuring once each video packet
>
> #define D_USBI 6
>
> Use this to log ctrl register reads
>
> #define D_USBO 7
>
> Use this to log ctrl register writes
>
> When you use this, you can use the gspca_main.debug module parameter
> to select a log level between 0 - 7.
>
Done
> 2) As for the "XXX: seems done automaticly, should rmeove" bit, yes
> controls are set automatically at the start of streaming, so please
> remove this (and double check things still work with it removed).
>
Done, seems to still work
> 3) In some places you do:
>
> rc = reg_w(gspca_dev, 0x, REG_SCALING_MODE);
> if (rc)
> return rc;
> rc = reg_w(gspca_dev, 0x0010, REG_SCALE_M);
> if (rc)
> return rc;
> rc = reg_w(gspca_dev, w, REG_X_OUTPUT_SIZE);
> if (rc)
> return rc;
> rc = reg_w(gspca_dev, gspca_dev->pixfmt.height, REG_Y_OUTPUT_SIZE);
> if (rc)
> return rc;
>
> The way we typically handle this in gspca is through gspca_dev->usb_err
> which you use in sd_s_ctrl but never set, here is an example of another reg_w
> function indicating how this is typically used:
>
> static void pac207_write_reg(struct gspca_dev *gspca_dev, u16 index, u16
> value)
> {
> struct usb_device *udev = gspca_dev->dev;
> int err;
>
> if (gspca_dev->usb_err < 0)
> return;
>
> err = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0x00,
> USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_INTERFACE,
> value, index, NULL, 0, PAC207_CTRL_TIMEOUT);
> if (err) {
> pr_err("Failed to write a register (index 0x%04X, value
> 0x%02X,
>index, value, err);
> gspca_dev->usb_err = err;
> }
> }
>
> And the above code would be changed into:
>
> gspca_dev->usb_err = 0;
>
> reg_w(gspca_dev, 0x, REG_SCALING_MODE);
> reg_w(gspca_dev, 0x0010, REG_SCALE_M);
> reg_w(gspca_dev, w, REG_X_OUTPUT_SIZE);
> reg_w(gspca_dev, gspca_dev->pixfmt.height, REG_Y_OUTPUT_SIZE);
>
> return gspca_dev->usb_err;
>
> The idea being that we can simply chain as many reg_w calls as we need,
> and the first one failing turns all the next ones into nops, and at the
> end we simply return gspca_dev->usb_err which on success is still 0.
>
> If you make this change then the return of gspca_dev->usb_err at the end
> of sd_s_ctrl also actually starts making sense :)
Changed. This does change the error handing though: you continue to
send commands in some cases even if a previous one failed. I guess it
shouldn't really matter though.
>
> If you can fix these 3 issues then I'll happily merge this driver for
> 3.19.
>
> Regards,
>
> Hans
Busy with work, took a while longer to get back to this than I hoped.
Posted new version, let me know if this looks better. No worries if it
doesn't make 3.19.
I found that depending on the microscope filters I use I cannot get the
full color range. At some point in the future I'd like to tweak the
gain model.
John
>
>> Signed-off-by: John McMaster
>> ---
>> drivers/media/usb/gspca/Kconfig | 10 +
>> drivers/media/usb/gspca/Makefile |2 +
>> drivers/media/usb/gspca/touptek.c | 859
>> +
>> 3 files changed, 871 insertions(+)
>> create mode 100644 drivers/media/usb/gspca/touptek.c
>>
>> diff --git a/drivers/media/usb/gspca/Kconfig
>> b/drivers/media/usb/gspca/Kconfig
>> index eed10d7..60af3b1 100644
>> ---
[PATCH] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras
Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera.
Signed-off-by: John McMaster
---
drivers/media/usb/gspca/Kconfig | 10 +
drivers/media/usb/gspca/Makefile |2 +
drivers/media/usb/gspca/touptek.c | 729 +
3 files changed, 741 insertions(+)
create mode 100644 drivers/media/usb/gspca/touptek.c
diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig
index eed10d7..60af3b1 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -395,6 +395,16 @@ config USB_GSPCA_TOPRO
To compile this driver as a module, choose M here: the
module will be called gspca_topro.
+config USB_GSPCA_TOUPTEK
+ tristate "Touptek USB Camera Driver"
+ depends on VIDEO_V4L2 && USB_GSPCA
+ help
+ Say Y here if you want support for cameras based on the ToupTek UCMOS
+ / AmScope MU series camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_touptek.
+
config USB_GSPCA_TV8532
tristate "TV8532 USB Camera Driver"
depends on VIDEO_V4L2 && USB_GSPCA
diff --git a/drivers/media/usb/gspca/Makefile b/drivers/media/usb/gspca/Makefile
index f46975e..9f5ccec 100644
--- a/drivers/media/usb/gspca/Makefile
+++ b/drivers/media/usb/gspca/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_USB_GSPCA_STK1135) += gspca_stk1135.o
obj-$(CONFIG_USB_GSPCA_STV0680) += gspca_stv0680.o
obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o
obj-$(CONFIG_USB_GSPCA_TOPRO)+= gspca_topro.o
+obj-$(CONFIG_USB_GSPCA_TOUPTEK) += gspca_touptek.o
obj-$(CONFIG_USB_GSPCA_TV8532) += gspca_tv8532.o
obj-$(CONFIG_USB_GSPCA_VC032X) += gspca_vc032x.o
obj-$(CONFIG_USB_GSPCA_VICAM)+= gspca_vicam.o
@@ -86,6 +87,7 @@ gspca_stv0680-objs := stv0680.o
gspca_sunplus-objs := sunplus.o
gspca_t613-objs := t613.o
gspca_topro-objs:= topro.o
+gspca_touptek-objs := touptek.o
gspca_tv8532-objs := tv8532.o
gspca_vc032x-objs := vc032x.o
gspca_vicam-objs:= vicam.o
diff --git a/drivers/media/usb/gspca/touptek.c
b/drivers/media/usb/gspca/touptek.c
new file mode 100644
index 000..2fd876c
--- /dev/null
+++ b/drivers/media/usb/gspca/touptek.c
@@ -0,0 +1,729 @@
+/*
+ * ToupTek UCMOS / AmScope MU series camera driver
+ * TODO: contrast with ScopeTek / AmScope MDC cameras
+ *
+ * Copyright (C) 2012-2014 John McMaster
+ *
+ * Special thanks to Bushing for helping with the decrypt algorithm and
+ * Sean O'Sullivan / the Rensselaer Center for Open Source
+ * Software (RCOS) for helping me learn kernel development
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "gspca.h"
+
+#define MODULE_NAME "touptek"
+
+MODULE_AUTHOR("John McMaster");
+MODULE_DESCRIPTION("ToupTek UCMOS / Amscope MU microscope camera driver");
+MODULE_LICENSE("GPL");
+
+/*
+Exposure reg is linear with exposure time
+Exposure (sec), E (reg)
+0.000400, 0x0002
+0.001000, 0x0005
+0.005000, 0x0019
+0.02, 0x0064
+0.08, 0x0190
+0.40, 0x07D0
+1.00, 0x1388
+2.00, 0x2710
+
+Three gain stages
+0x1000: master channel enable bit
+0x007F: low gain bits
+0x0080: medium gain bit
+0x0100: high gain bit
+gain = enable * (1 + regH) * (1 + regM) * z * regL
+
+Gain implementation
+Want to do something similar to mt9v011.c's set_balance
+
+Gain does not vary with resolution (checked 640x480 vs 1600x1200)
+
+Constant derivation:
+
+Raw data:
+Gain, GTOP, B, R, GBOT
+1.00, 0x105C, 0x1068, 0x10C8, 0x105C
+1.20, 0x106E, 0x107E, 0x10D6, 0x106E
+1.40, 0x10C0, 0x10CA, 0x10E5, 0x10C0
+1.60, 0x10C9, 0x10D4, 0x10F3, 0x10C9
+1.80, 0x10D2, 0x10DE, 0x11C1, 0x10D2
+2.00, 0x10DC, 0x10E9, 0x11C8, 0x10DC
+2.20, 0x10E5, 0x10F3, 0x11CF, 0x10E5
+2.40, 0x10EE, 0x10FE, 0x11D7, 0x10EE
+2.60, 0x10F7, 0x11C4, 0x11DE, 0x10F7
+2.80, 0x11C0, 0x11CA, 0x11E5, 0x11C0
+3.00, 0x11C5, 0x11CF, 0x11ED, 0x11C5
+
+zR = 0.0069605943152454778
+ about 3/431 = 0.0069605568445475635
+zB = 0.0095695970695970703
+ about 6/627 = 0.0095693779904306216
+zG = 0.010889328063241107
+ about 6/551 = 0.010889292196007259
+about 10 bits for constant + 7 bits for value => at least 17 bit intermediate
+with 32 bit ints should be fine for overflow etc
+Essentially gains are in range 0-0x001FF
+
Re: [PATCH 16/19] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Dear Mark,
On 11/28/2014 11:00 PM, Mark Rutland wrote:
> On Fri, Nov 28, 2014 at 01:18:25PM +, Chanwoo Choi wrote:
>> Dear Mark,
>>
>> On 11/27/2014 08:18 PM, Mark Rutland wrote:
>>> On Thu, Nov 27, 2014 at 07:35:13AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC
based on Octal core CPUs (quad Cortex-A57 and quad Cortex-A53).
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Acked-by: Geunsik Lim
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
+
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 523 +++
2 files changed, 1221 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>
>
> [...]
>
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ enable-method = "psci";
>>>
>>> While the CPU nodes have enable-methods, I didn't spot a PSCI node
>>> anywhere, so this dts cannot possibly have been used to bring up an SMP
>>> system.
>>>
>>> How has this dts been tested?
>>>
>>> What PSCI revision have you implemented? Have have you tested it?
>>
>> My mistake,
>> Exynos5433 supports PSCI v0.1. I'll add following PSCI nodes:
>> I tested the boot of secondary cpu.
>>
>> psci {
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x8402>;
>> cpu_on = <0xC403>;
>> };
>
> Ok. I take it _any_ CPU may be hotplugged (including CPU0), given that
> you don't have MIGRATE_INFO_TYPE from PSCI 0.2 to tell you that this is
> not possible? If not, attempting to hotplug CPU0 will result in a BUG()
> and the kernel will explode.
>
> Has that been tested?
I just tested secondary CPU on during kernel booting after added 'psci' dt node.
So, I got the ON state of Octa CPUs.
Maybe I need more time to implement CPU0 and secondary cpu hotplugged
dynamically on runtime.
>
> Do all CPUs enter the kernel at EL2?
I didn't consider EL2 for hypervisor mode.
First role of this job, I'll implement CPU on/off and suspend by using PSCI.
>
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fixed-rate-clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ xusbxti: clock@0 {
+ compatible = "fixed-clock";
+ clock-output-names = "xusbxti";
+ #clock-cells = <0>;
+ };
+ };
>>>
>>> Get rid of the fixed-rate-clocks container node. It's pointless and
>>> messy. Given you only have one there's no need for the bogus
>>> unit-address either.
>>
>> OK, I'll remove unneeded code and will add following dt node for fin_pll.
>>
>> fin_pll: xxti {
>> compatible = "fixed-clock";
>> clock-output-names = "fin_pll";
>> #clock-cells = <0>;
>> };
>
> That looks fine to me.
>
> [...]
>
+ mct@101c {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x101c 0x800>;
+ interrupts = <0 102 0>, <0 103 0>, <0 104 0>, <0
105 0>,
+ <0 106 0>, <0 107 0>, <0 108 0>, <0 109>,
+ <0 110 0>, <0 111 0>, <0 112 0>, <0 113 0>;
+ clocks = <_top CLK_FIN_PLL>, <_peris
CLK_PCLK_MCT>;
+ clock-names = "fin_pll", "mct";
+ };
>>>
>>> Hase this block had no changes whatsoever since its use in Exynos4210?
>>> Do we not need a "samsung,exynos5433-mct" comaptible string too?
>>
>> The type of Exynos5433's MCT(Multi-Core Timer) IP is the same with the type
>> of Exynos4210 MCT.
>> Just Exynos5433 have eight local timer for Octa cores.
>
> So "samsung,exynos4210-mct" should appear in the list. I'm just
> wondering if it's worth having:
>
> compatible = "samsung,exynos5433-mct", "samsung,exynos4210-mct";
>
> Just in case we need to special-case the 5433 MCT for some reason later.
OK, I'll add "samsung,exynos5433-mct" compatible string in exynos5433.dtsi
according to your comment.
>
>>
>>CPU0 CPU1 CPU2
Re: [RESEND PATCH 1/1] linux-firmware: Update AMD microcode patch firmware files
On Thu, Nov 06, 2014 at 07:38:26PM -0600, sherry.hurw...@amd.com wrote: > From: Sherry Hurwitz > > For AMD Family 15h Processors > file: amd-ucode/microcode_amd_family15h.bin > md5sum: ee3f0f46936aa1788dc31ca3487e0ff3 > > For AMD Family 16h Processors > file: amd-ucode/microcode_amd_family16h.bin > md5sum: 6a47a6393c52ddfc0b5b044efc076a77 > > Version: 2014_10_28 > Signed-off-by: Sherry Hurwitz Applied, thanks Sherry. Sorry for the delay. regards, Kyle -- 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: [tip:irq/irqdomain] irqdomain: Introduce helper function irq_domain_add_hierarchy()
On 2014/11/30 4:42, Thomas Gleixner wrote:
> On Sat, 29 Nov 2014, Borislav Petkov wrote:
>> So I'm seeing the lockdep splat below really early on an IVB laptop.
>>
>> Basically we're not supposed to do __GFP_FS allocations with IRQs off:
>>
>> 2737 /* We're only interested __GFP_FS allocations for now */
>> 2738 if (!(gfp_mask & __GFP_FS))
>> 2739 return;
>> 2740
>> 2741 /*
>> 2742* Oi! Can't be having __GFP_FS allocations with IRQs
>> disabled.
>> 2743*/
>> 2744 if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
>> <--- HERE!
>> 2745 return;
>> 2746
>> 2747 mark_held_locks(curr, RECLAIM_FS);
>> 2748 }
>>
>> Now, AFAICT, enable_IR_x2apic() disables interrupts and the whole init
>> is done with IRQs off but down that path intel_setup_irq_remapping()
>> calls irq_domain_add_hierarchy() and it does by default GFP_KERNEL
>> allocations.
>>
>> The obvious fix is this and the machine boots fine with it. I'm not sure
>> it is kosher though so I rather run it by people first:
>>
>> ---
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index 7fac311057b8..c21a003b996a 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -46,14 +46,18 @@ struct irq_domain *__irq_domain_add(struct device_node
>> *of_node, int size,
>> void *host_data)
>> {
>> struct irq_domain *domain;
>> +gfp_t gfp_flags = GFP_KERNEL;
>> +
>> +if (irqs_disabled())
>> +gfp_flags = GFP_NOFS;
>
> We want to use GFP_ATOMIC for that, but I really hate to do so. There
> is no reason except for the early boot stage to call into this code
> with interrupts disabled. And there we are covered by gfp_allowed_mask,
> so that a GFP_KERNEL allocation can succeed.
>
> I have no idea, why enable_IR_x2apic() has been bolted into
> smp_prepare_cpus(). Probably just because.
>
> There is no reason WHY this cannot be done in the early irq setup path
> (at least nowadays with the allocators being available early), but
> that is another area which needs some care and cleanup, but definitely
> too late before the 3.19 merge window opens.
Hi Thomas,
I will have a look at this after 3.19 merge window:)
>
> So we have to bite the bullet and apply something like this along with
> a big fat comment WHY we are doing so and I'm tempted to wrap this
> into a #ifdef CONFIG_X86 so that noone else thinks that calling this
> code with interrupts disabled - except for the early boot stage - is a
> brilliant idea.
>
> Thanks,
>
> tglx
>
--
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 v4 0/2] Add regulator-haptic driver
This patch series adds regulator-haptic driver. The regulator-haptic has haptic motor and it is controlled by voltage of regulator via force feedback framework. Changes in v4: - _regulator_get() -> _regulator_get_exclusive() Changes in v3: - fix typo in Documentation - add define in header file Changes in v2: - remove driver owner - merge enable/disable function - support platform data - fix wrong suspends_state check in regulator_haptic_resume() Jaewon Kim (2): Input: add regulator haptic driver ARM: dts: Add regulator-haptic device node for exynos3250-rinato .../devicetree/bindings/input/regulator-haptic.txt | 21 ++ arch/arm/boot/dts/exynos3250-rinato.dts|7 + drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 247 include/linux/input/regulator-haptic.h | 31 +++ 6 files changed, 318 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c create mode 100644 include/linux/input/regulator-haptic.h -- 1.7.9.5 -- 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 v4 1/2] Input: add regulator haptic driver
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim
Signed-off-by: Hyunhee Kim
Acked-by: Kyungmin Park
Tested-by: Chanwoo Choi
Reviewed-by: Chanwoo Choi
Reviewed-by: Pankaj Dubey
---
.../devicetree/bindings/input/regulator-haptic.txt | 21 ++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/regulator-haptic.c | 247
include/linux/input/regulator-haptic.h | 31 +++
5 files changed, 311 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..3ed1c7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,21 @@
+* Regulator Haptic Device Tree Bindings
+
+Required Properties:
+ - compatible : Should be "regulator-haptic"
+ - haptic-supply : Power supply to the haptic motor.
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+Example:
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <_regulator>;
+ max-microvolt = <270>;
+ min-microvolt = <110>;
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_REGULATOR_HAPTIC
+ tristate "regulator haptics support"
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_RETU_PWRBUTTON
tristate "Retu Power button Driver"
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..6bc8e45
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,247 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim
+ * Author: Hyunhee Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct regulator *regulator;
+ struct work_struct work;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int max_volt;
+ unsigned int min_volt;
+ unsigned int intensity;
+ unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
state)
+{
+ int error;
+
+ if (haptic->enabled == state)
+ return;
+
+ if (state)
+ error = regulator_enable(haptic->regulator);
+ else
+ error = regulator_disable(haptic->regulator);
+ if (error) {
+ dev_err(haptic->dev, "cannot enable regulator\n");
+ return;
+ }
+
+ haptic->enabled = state;
+}
+
+static void regulator_haptic_work(struct work_struct *work)
+{
+ struct regulator_haptic *haptic = container_of(work,
[PATCH v4 2/2] ARM: dts: Add regulator-haptic device node for exynos3250-rinato
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim
Reviewed-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-rinato.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 84380fa..da03005 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -104,6 +104,13 @@
};
};
};
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <_reg>;
+ min-microvolt = <110>;
+ max-microvolt = <270>;
+ };
};
{
--
1.7.9.5
--
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: Do you know who maintains firmware upstreaming for linux now?
> -Original Message- > From: Kyle McMartin [mailto:k...@infradead.org] > Sent: Monday, December 01, 2014 9:41 AM > To: Jie, Yang > Cc: linux-firmw...@kernel.org; linux-kernel@vger.kernel.org; > b...@decadent.org.uk; k...@infradead.org; Woodhouse, David; > k...@kernel.org; Girdwood, Liam R; Li, Jocelyn; Lin, Mengdong; Chehab, John; > Hindman, Gavin; Strasser, Kevin; Accardi, Kristen C; Schlobohm, Bruce; Nikula, > Jarkko > Subject: Re: Do you know who maintains firmware upstreaming for linux now? > > On Fri, Nov 28, 2014 at 11:51:16AM +, Jie, Yang wrote: > > > > Hi, All, > > > > Could someone clarify who maintains firmware upstreaming to Linux at the > moment? > > > > We are working on upstream a firmware binary and its license to > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, > We've sent the patch to linux-firmw...@kernel.org but got no reply for > several(4~5) weeks. > > I can imagine that maintainers may be very busy, and not sure if Ben/Kyle > have been on vacation, or can someone else help to review and apply our > firmware patch? > > > > Sorry, we've just been busy, and I figured someone would pick up my > slacking... > I'll get to it tonight. > > regards, Kyle [Keyon] Happy to know that you are available, Kyle, thanks for your taking time to help. Regards, ~Keyon -- 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: rt8192u: fix sparse warnings in r8192U_core.c
Fixed the following warnings in sparse:
drivers/staging/rtl8192u/r8192U_core.c:670:6: warning:
symbol 'dump_eprom' was not declared.
Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:1489:5: warning:
symbol 'ComputeTxTime' was not declared.
Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:1556:14: warning:
symbol 'txqueue2outpipe' was not declared.
Should it be static?
drivers/staging/rtl8192u/r8192U_core.c:4876:5: warning:
symbol 'GetRxPacketShiftBytes819xUsb' was not declared.
Should it be static?
Signed-off-by: Fred Chou
---
drivers/staging/rtl8192u/r8192U_core.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 7640386..6b647ad 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -667,7 +667,7 @@ static void tx_timeout(struct net_device *dev)
/* this is only for debug */
-void dump_eprom(struct net_device *dev)
+static void dump_eprom(struct net_device *dev)
{
int i;
for (i = 0; i < 63; i++)
@@ -1486,7 +1486,7 @@ inline u8 rtl8192_IsWirelessBMode(u16 rate)
u16 N_DBPSOfRate(u16 DataRate);
-u16 ComputeTxTime(u16 FrameLength, u16 DataRate, u8 bManagementFrame,
+static u16 ComputeTxTime(u16 FrameLength, u16 DataRate, u8 bManagementFrame,
u8 bShortPreamble)
{
u16 FrameTime;
@@ -1553,7 +1553,8 @@ u16 N_DBPSOfRate(u16 DataRate)
return N_DBPS;
}
-unsigned int txqueue2outpipe(struct r8192_priv *priv, unsigned int tx_queue)
+static unsigned int txqueue2outpipe(struct r8192_priv *priv,
+ unsigned int tx_queue)
{
if (tx_queue >= 9) {
RT_TRACE(COMP_ERR, "%s():Unknown queue ID!!!\n", __func__);
@@ -4873,7 +4874,8 @@ static void query_rxdesc_status(struct sk_buff *skb,
}
-u32 GetRxPacketShiftBytes819xUsb(struct ieee80211_rx_stats *Status, bool
bIsRxAggrSubframe)
+static u32 GetRxPacketShiftBytes819xUsb(struct ieee80211_rx_stats *Status,
+ bool bIsRxAggrSubframe)
{
#ifdef USB_RX_AGGREGATION_SUPPORT
if (bIsRxAggrSubframe)
--
1.9.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: Do you know who maintains firmware upstreaming for linux now?
On Fri, Nov 28, 2014 at 11:51:16AM +, Jie, Yang wrote: > > Hi, All, > > Could someone clarify who maintains firmware upstreaming to Linux at the > moment? > > We are working on upstream a firmware binary and its license to > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, > We've sent the patch to linux-firmw...@kernel.org but got no reply for > several(4~5) weeks. > I can imagine that maintainers may be very busy, and not sure if Ben/Kyle > have been on vacation, or can someone else help to review and apply our > firmware patch? > Sorry, we've just been busy, and I figured someone would pick up my slacking... I'll get to it tonight. regards, Kyle -- 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] blk-mq: don't use rw_is_sync() to determine sync request
On 11/30/2014 05:01 PM, Shaohua Li wrote: Buffer read is counted as sync in rw_is_sync(). If we use it, blk_sq_make_request() will not do per-process plug any more. I haven't changed blk_mq_make_request() yet. It makes sense to dispatch REQ_SYNC request immediately. But for buffer read, it's weird not to do per-process plug, as buffer read doesn't need low latency. blk_mq_merge_queue_io() isn't very helpful, as we don't have delay mechanism there, the queue is immediately flushed, which makes the merge very superficial. A read is sync, buffered or not. A buffered read is every bit as latency sensitive as an O_DIRECT read. I think it'd be fine to modify rw_is_sync() to disregard REQ_AHEAD as sync (and ensure it's carried forward in the request flags, too). At least to the extent that we process plug and get the merging, since for streamed reads we'd soon be waiting on them anyway. -- Jens Axboe -- 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-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
> I know there has been some criticism about those kind of "code > improvements" already but i would like to point out just one more thing: > > Some of those NULL pointer checks on input parameters may have been > added subsequently to functions. So there may be older kernel versions > out there in which those checks dont exists in some cases. If some of > the now "cleaned up" code is backported to such a kernel chances are > good that those missing checks are overseen. And then neither caller nor > callee is doing the NULL pointer check. I guess that the Coccinelle software can also help you in this use case. How do you think about to shield against "unwanted" or unexpected collateral evolutions with additional inline functions? I assume that a few backporters can tell you more about their corresponding software development experiences. http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html 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] blk-mq: move the kdump check to blk_mq_alloc_tag_set
On 11/30/2014 05:00 PM, Shaohua Li wrote: We call blk_mq_alloc_tag_set() first then blk_mq_init_queue(). The requests are allocated in the former function. So the kdump check should be moved to there to really save memory. Strange, it was even tested, but must have been altered after the fact. Patch looks good to me, applied. -- Jens Axboe -- 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 v10 2/2] ARM: kprobes: enable OPTPROBES for ARM 32
>>
>> +/* optinsn template addresses */
>> +extern __visible kprobe_opcode_t optprobe_template_entry;
>
> Why do we need the __visible annotation? I'm not suggesting that we
> don't, just curious what it achieves. (Code compiles and links OK for me
> without it).
>
These '__visible' are inherited from x86 code. Commit 04bb591 adds them
explicitly.
It is part from https://lkml.org/lkml/2013/8/5/595 , which is a patch series
to make all C functions which may be called from asm code LTO safety. Without
such __visible directive, LTO may do some asm-unfriendly optimization, like
triming them all because gcc think they are not used.
>> +extern __visible kprobe_opcode_t optprobe_template_val;
>> +extern __visible kprobe_opcode_t optprobe_template_call;
>> +extern __visible kprobe_opcode_t optprobe_template_end;
>> +
>> +#define MAX_OPTIMIZED_LENGTH(4)
>
> The parenthesis around the 4 are not needed. Same for RELATIVEJUMP_SIZE
> below.
>
This is my old habit... I'll fix it in next version.
>
>> +#define MAX_OPTINSN_SIZE\
>> +(((unsigned long)_template_end - \
>> + (unsigned long)_template_entry))
>> +#define RELATIVEJUMP_SIZE (4)
>> +
Also.
>> +struct arch_optimized_insn {
>> +/*
>> + * copy of the original instructions.
>> + * Different from x86, ARM kprobe_opcode_t is u32.
>> + */
>> +#define MAX_COPIED_INSN ((RELATIVEJUMP_SIZE) / sizeof(kprobe_opcode_t))
>
> Whilst the above gives the correct value, I think for correctness it
> should be expressed as
>
> #define MAX_COPIED_INSN (DIV_ROUND_UP(RELATIVEJUMP_SIZE,
> sizeof(kprobe_opcode_t))
>
Agree.
>
>> +kprobe_opcode_t copied_insn[MAX_COPIED_INSN];
>> +/* detour code buffer */
>> +kprobe_opcode_t *insn;
>> +/*
>> + * we always copies one instruction on arm32,
>> + * size always be 4, so no size field.
>> + */
>
> Not sure we need the above comment, it only makes sense if the person
> reading it knows what the x86 implementation looks like.
>
>> +};
>>
>> #endif /* _ARM_KPROBES_H */
>> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
>> index 45aed4b..8a16fcf 100644
>> --- a/arch/arm/kernel/Makefile
>> +++ b/arch/arm/kernel/Makefile
>> @@ -52,11 +52,12 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
>> insn.o
>> obj-$(CONFIG_JUMP_LABEL)+= jump_label.o insn.o patch.o
>> obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
>> obj-$(CONFIG_UPROBES) += probes.o probes-arm.o uprobes.o
>> uprobes-arm.o
>> -obj-$(CONFIG_KPROBES) += probes.o kprobes.o kprobes-common.o
>> patch.o probes-checkers-common.o
>> +obj-$(CONFIG_KPROBES) += probes.o kprobes.o kprobes-common.o
>> patch.o probes-checkers-common.o insn.o
>> ifdef CONFIG_THUMB2_KERNEL
>> obj-$(CONFIG_KPROBES) += kprobes-thumb.o probes-thumb.o
>> probes-checkers-thumb.o
>> else
>> obj-$(CONFIG_KPROBES) += kprobes-arm.o probes-arm.o
>> probes-checkers-arm.o
>> +obj-$(CONFIG_OPTPROBES) += kprobes-opt-arm.o
>> endif
>> obj-$(CONFIG_ARM_KPROBES_TEST) += test-kprobes.o
>> test-kprobes-objs := kprobes-test.o
>> diff --git a/arch/arm/kernel/kprobes-opt-arm.c
>> b/arch/arm/kernel/kprobes-opt-arm.c
>> new file mode 100644
>> index 000..f9d213c
>> --- /dev/null
>> +++ b/arch/arm/kernel/kprobes-opt-arm.c
>> @@ -0,0 +1,290 @@
>> +/*
>> + * Kernel Probes Jump Optimization (Optprobes)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
>> USA.
>> + *
>> + * Copyright (C) IBM Corporation, 2002, 2004
>> + * Copyright (C) Hitachi Ltd., 2012
>> + * Copyright (C) Huawei Inc., 2014
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +/* for arm_gen_branch */
>> +#include "insn.h"
>> +/* for patch_text */
>> +#include "patch.h"
>> +
>> +/*
>> + * NOTE: the first sub and add instruction will be modified according
>> + * to the stack cost of the instruction.
>> + */
>> +asm (
>> +".global optprobe_template_entry\n"
>> +"optprobe_template_entry:\n"
>> +" sub sp, sp, #0xff\n"
>> +" stmia sp, {r0 - r14} \n"
>
> AEABI requires that the
[PATCH 1/2 V5] intel_pstate: skip this driver if Sun server has _PPC method
Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.
Signed-off-by: Ethan Zhao
Signed-off-by: Dirk Brandewie
Tested-by: Linda Knippers
---
v2: fix break HP Proliant issue.
v3: expand the hardware vendor list.
v4: refine code.
v5: change enum PCC to PPC.
drivers/cpufreq/intel_pstate.c | 45 ++
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 27bb6d3..1bb62ca 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -943,15 +943,46 @@ static bool intel_pstate_no_acpi_pss(void)
return true;
}
+static bool intel_pstate_has_acpi_ppc(void)
+{
+ int i;
+
+ for_each_possible_cpu(i) {
+ struct acpi_processor *pr = per_cpu(processors, i);
+
+ if (!pr)
+ continue;
+ if (acpi_has_method(pr->handle, "_PPC"))
+ return true;
+ }
+ return false;
+}
+
+enum {
+ PSS,
+ PPC,
+};
+
struct hw_vendor_info {
u16 valid;
char oem_id[ACPI_OEM_ID_SIZE];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+ int oem_pwr_table;
};
/* Hardware vendor-specific info that has its own power management modes */
static struct hw_vendor_info vendor_info[] = {
- {1, "HP", "ProLiant"},
+ {1, "HP", "ProLiant", PSS},
+ {1, "ORACLE", "X4-2", PPC},
+ {1, "ORACLE", "X4-2L ", PPC},
+ {1, "ORACLE", "X4-2B ", PPC},
+ {1, "ORACLE", "X3-2", PPC},
+ {1, "ORACLE", "X3-2L ", PPC},
+ {1, "ORACLE", "X3-2B ", PPC},
+ {1, "ORACLE", "X4470M2 ", PPC},
+ {1, "ORACLE", "X4270M3 ", PPC},
+ {1, "ORACLE", "X4270M2 ", PPC},
+ {1, "ORACLE", "X4170M2 ", PPC},
{0, "", ""},
};
@@ -966,15 +997,21 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
for (v_info = vendor_info; v_info->valid; v_info++) {
if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
- !strncmp(hdr.oem_table_id, v_info->oem_table_id,
ACPI_OEM_TABLE_ID_SIZE) &&
- intel_pstate_no_acpi_pss())
- return true;
+ !strncmp(hdr.oem_table_id, v_info->oem_table_id,
+ ACPI_OEM_TABLE_ID_SIZE))
+ switch (v_info->oem_pwr_table) {
+ case PSS:
+ return intel_pstate_no_acpi_pss();
+ case PCC:
+ return intel_pstate_has_acpi_ppc();
+ }
}
return false;
}
#else /* CONFIG_ACPI not enabled */
static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return false;
}
+static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
#endif /* CONFIG_ACPI */
static int __init intel_pstate_init(void)
--
1.8.3.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: [PATCH 1/2] Input: add regulator haptic driver
Hi Mark,
2014년 11월 28일 21:50에 Mark Brown 이(가) 쓴 글:
On Thu, Nov 20, 2014 at 10:31:39PM +0900, Jaewon Kim wrote:
+ haptic->regulator = devm_regulator_get(>dev, "haptic");
+ if (IS_ERR(haptic->regulator)) {
+ dev_err(>dev, "failed to get regulator\n");
+ return PTR_ERR(haptic->regulator);
+ }
This needs to be _get_exclusive() - the driver will be broken if
something else shares the regualtor since it relies on both enabling and
disabling the regulator and on setting the voltage for effects. It's
not like a power supply where leaving the device powered when it could
be off is going to have no effect, if the power is left on then the
haptic motor will continue to operate.
Thanks to review my patch.
Haptic regulator has to only be used in this driver.
So, it is right to change like your advice.
I will fix next version.
Thanks
Jaewon Kim.
--
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 V4] intel_pstate: skip this driver if Sun server has _PPC method
Yasuaki,
On 2014/11/28 13:20, Yasuaki Ishimatsu wrote:
> (2014/11/28 12:36), Ethan Zhao wrote:
>> Oracle Sun X86 servers have dynamic power capping capability that works via
>> ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
>> enabled.
>>
>> Signed-off-by: Ethan Zhao
>> Signed-off-by: Dirk Brandewie
>> Tested-by: Linda Knippers
>> ---
>>v2: fix break HP Proliant issue.
>>v3: expand the hardware vendor list.
>>v4: refine code.
>>
>> drivers/cpufreq/intel_pstate.c | 45
>> ++
>> 1 file changed, 41 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
>> index 27bb6d3..1bb62ca 100644
>> --- a/drivers/cpufreq/intel_pstate.c
>> +++ b/drivers/cpufreq/intel_pstate.c
>> @@ -943,15 +943,46 @@ static bool intel_pstate_no_acpi_pss(void)
>> return true;
>> }
>>
>> +static bool intel_pstate_has_acpi_ppc(void)
>> +{
>> +int i;
>> +
>> +for_each_possible_cpu(i) {
>> +struct acpi_processor *pr = per_cpu(processors, i);
>> +
>> +if (!pr)
>> +continue;
>> +if (acpi_has_method(pr->handle, "_PPC"))
>> +return true;
>> +}
>> +return false;
>> +}
>> +
>> +enum {
>> +PSS,
>> +PCC,
>> +};
> What does PCC stand for? Is it PPC?
Good catch, should be PPC, not PCC.
> Thanks,
> Yasuaki Ishimatsu
>
>> +
>> struct hw_vendor_info {
>> u16 valid;
>> char oem_id[ACPI_OEM_ID_SIZE];
>> char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
>> +int oem_pwr_table;
>> };
>>
>> /* Hardware vendor-specific info that has its own power management modes */
>> static struct hw_vendor_info vendor_info[] = {
>> -{1, "HP", "ProLiant"},
>> +{1, "HP", "ProLiant", PSS},
>> +{1, "ORACLE", "X4-2", PCC},
>> +{1, "ORACLE", "X4-2L ", PCC},
>> +{1, "ORACLE", "X4-2B ", PCC},
>> +{1, "ORACLE", "X3-2", PCC},
>> +{1, "ORACLE", "X3-2L ", PCC},
>> +{1, "ORACLE", "X3-2B ", PCC},
>> +{1, "ORACLE", "X4470M2 ", PCC},
>> +{1, "ORACLE", "X4270M3 ", PCC},
>> +{1, "ORACLE", "X4270M2 ", PCC},
>> +{1, "ORACLE", "X4170M2 ", PCC},
>> {0, "", ""},
>> };
>>
>> @@ -966,15 +997,21 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
>>
>> for (v_info = vendor_info; v_info->valid; v_info++) {
>> if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
>> -!strncmp(hdr.oem_table_id, v_info->oem_table_id,
>> ACPI_OEM_TABLE_ID_SIZE) &&
>> -intel_pstate_no_acpi_pss())
>> -return true;
>> +!strncmp(hdr.oem_table_id, v_info->oem_table_id,
>> +ACPI_OEM_TABLE_ID_SIZE))
>> +switch (v_info->oem_pwr_table) {
>> +case PSS:
>> +return intel_pstate_no_acpi_pss();
>> +case PCC:
>> +return intel_pstate_has_acpi_ppc();
>> +}
>> }
>>
>> return false;
>> }
>> #else /* CONFIG_ACPI not enabled */
>> static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return
>> false; }
>> +static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
>> #endif /* CONFIG_ACPI */
>>
>> static int __init intel_pstate_init(void)
>>
>
--
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] uapi: fix to export linux/vm_sockets.h
A typo "header=y" was introduced by commit 7071cf7fc435 (uapi: add missing network related headers to kbuild). Signed-off-by: Masahiro Yamada Cc: Stephen Hemminger --- include/uapi/linux/Kbuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 4c94f31..8523f9b 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -427,7 +427,7 @@ header-y += virtio_net.h header-y += virtio_pci.h header-y += virtio_ring.h header-y += virtio_rng.h -header=y += vm_sockets.h +header-y += vm_sockets.h header-y += vt.h header-y += wait.h header-y += wanrouter.h -- 1.9.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: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
(2014/12/01 9:42), Paul Mackerras wrote: On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote: (2014/12/01 7:16), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers. Do you have the call trace? If you have it, please add it in the description. I can get it easily enough. To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras Do you need to backport it into -stable kernels? It does need to go to stable, yes, for 3.10 and later. --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid > num_online_nodes()); + VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES); How about use: VM_BUG_ON(!node_online(nodeid)); That would not be better, since node_online() doesn't bounds-check its argument. Ah. You are right. When allocating the memory, the node of the memory being allocated must be online. But your code cannot check the condition. The following two lines: n = get_node(cachep, nodeid); BUG_ON(!n); effectively check that condition already, as I tried to explain in the commit message. O.K. I understood. Thansk, Yasuaki Ishimatsu Regards, Paul. -- 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/
Linux 3.18-rc7
Things are calming down nicely, and everything looks pretty normal. In fact, if it wasn't for the pending issues with odd watchdog (and possibly rcu) lockups I'd be pretty happy. As it is, that isn't a regression from 3.17, but is still very disturbing. At the same time, with the holidays coming up, and the problem _not_ being a regression, I suspect that what will happen is that I'll release 3.18 on time in a week, because delaying it will either mess up the merge window and the holiday season, or I'd have to delay it a *lot*. We'll see. Maybe DaveJ will be able to bisect it a bit now that the false lead of "3.17 was ok" has been shown to be wrong (right now it looks like the problem seems to have crept in between 3.16 and 3.17). Annoying, because as mentioned, other than that we seem to be doing well. The rc7 patch looks very normal, with two thirds being drivers (spread all over: usb, networking, staging, thermal, gpu, sound..) and half of the remaining being arch updates (mostly mips, arm, powerpc). The remaining is mainly networking and some filesystem fixes (nfsd and btrfs). Linus Aaro Koskinen (1): MIPS: Loongson: Make platform serial setup always built-in. Akinobu Mita (3): ufs: fix reference counting of W-LUs ufs: ensure clk gating work is finished before module unloading ufs: fix NULL dereference when no regulators are defined Alex Deucher (1): drm/radeon: report disconnected for LVDS/eDP with PX if ddc fails Alexander Duyck (3): ipv6: Do not treat a GSO_TCPV4 request from UDP tunnel over IPv6 as invalid ip6_udp_tunnel: Fix checksum calculation vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX] Alexey Khoroshilov (1): xen-netback: do not report success if backend_create_xenvif() fails Andrew Lutomirski (1): net-timestamp: Fix a documentation typo Anton Blanchard (1): powerpc: 32 bit getcpu VDSO function uses 64 bit instructions Ard Biesheuvel (2): arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn() kvm: fix kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn() Arnaud Ebalard (1): hwmon: (g762) fix call to devm_hwmon_device_register_with_groups() Axel Lin (1): iio: adc: men_z188_adc: Add terminating entry for men_z188_ids Ben Sagal (1): Input: synaptics - adjust min/max on Thinkpad E540 Benjamin Herrenschmidt (6): PCI/MSI: Add device flag indicating that 64-bit MSIs don't work gpu/radeon: Set flag to indicate broken 64-bit MSI sound/radeon: Move 64-bit MSI quirk from arch to driver powerpc/powernv: Honor the generic "no_64bit_msi" flag powerpc/pseries: Honor the generic "no_64bit_msi" flag powerpc/pci: Remove unused force_32bit_msi quirk Boris Brezillon (3): irqchip: atmel-aic: Fix irqdomain initialization clk: at91: usb: fix at91rm9200 round and set rate clk: at91: usb: fix at91sam9x5 recalc, round and set rate Carolyn Wyborny (1): igb: Fixes needed for surprise removal support Charles Keepax (1): spi: Fix mapping from vmalloc-ed buffer to scatter list Chris Mason (1): btrfs: zero out left over bytes after processing compression streams Christian Sünkenberg (1): scsi: add Intel Multi-Flex to scsi scan blacklist Christoffer Dall (2): arm64: KVM: Handle traps of ICC_SRE_EL1 as RAZ/WI arm/arm64: KVM: vgic: Fix error code in kvm_vgic_create() Christoph Hellwig (1): nfsd: correctly define v4.2 support attributes Cristina Ciocan (1): iio: Fix IIO_EVENT_CODE_EXTRACT_DIR bit mask Daniel Baluta (1): iio: accel: kxcjk-1013: Fix kxcjk10013_set_range Daniel Borkmann (1): ixgbe: fix use after free adapter->state test in ixgbe_remove/ixgbe_probe David S. Miller (1): sparc: Add NOP dma_cache_sync() implementation. Dmitry Eremin-Solenikov (1): ARM: 8216/1: xscale: correct auxiliary register in suspend/resume Dmitry Torokhov (3): Input: elantech - trust firmware about trackpoint presence irqchip: bcm7120-l2: Fix error handling of irq_of_parse_and_map irqchip: brcmstb-l2: Fix error handling of irq_of_parse_and_map Dolev Raviv (4): scsi: ufs: fix static checker errors in ufshcd_system_suspend scsi: ufs: fix static checker warning in ufshcd_populate_vreg scsi: ufs: fix static checker warning in __ufshcd_setup_clocks scsi: ufs: fix static checker warning in ufshcd_parse_clock_info Eric Dumazet (1): tcp: fix possible NULL dereference in tcp_vX_send_reset() Felipe Balbi (1): usb: dwc3: ep0: fix for dead code Florian Fainelli (4): MIPS: Netlogic: handle modular USB case MIPS: Netlogic: handle modular AHCI builds net: dsa: bcm_sf2: fix unmapping registers in case of errors net: dsa: bcm_sf2: reset switch prior to initialization Gavin Shan (2): powerpc/eeh: Fix PE state format powerpc/powernv: Replace OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE
Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE
On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote: > CC'ing systemd folks. > > Lennart, can you please explain why you need CONFIG_FHANDLE for systemd? > Maybe I'm reading the source horrible wrong. For two usecases: a) Being able to detect if something is a mount point. The traditional way to do this is by stat()ing the dir in question and its parent and comparing st_dev. That logic is not able to detect bind mounts however, if destination and the place the mount is at are actually on the same file system... Thus we check the mount id too, if we can get our hands on it. This actually fixes real-life problems. For example time-based recursive clean-up logic in /tmp, where it is desirable that the clean up stops at submounts. However, we had reports where the clean-up fucked up people's home directories because they mounted them for some reason into some subdir in /tmp and they had /tmp and /home on the same fs. b) Because we sometimes want to know the mount options used for specific file systems. For that you want to correlate /proc/self/mountinfo with a path in the fs. You can of course try to do path prefix matching and then fuck things up as soon as people do weird mounts on top of each other. Or you can use use the mount id name_to_handle tells you and look it up in /proc/self/mountinfo, and everything is clean and reliable. We have no interest in the actual fhandle data. If you give us some other syscall to figure out the mount id, we'd be delighted to use it instead. udev uses the logic described in b) to determine if /dev is a devtmpfs instance. Since devtmpfs has the same fs magic as any other tmpfs we cannot use the statfs() magic stuff to detect this case. Lennart -- 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/
Possible memory leak in function (reserve_range) not freeing pointer (regionid)
Bug Report: https://bugzilla.kernel.org/show_bug.cgi?id=89101 Linux Version [3.17-rc1] Configuration: Default configuration for x86 Function (reserve_range) in file (drivers/pnp/system.c) allocates pointer (regionid) on line (32) and passes it to function (__request_region) through the macros: (request_region) at line (38) or (request_mem_region) at line (40). However, if the resource (res) is allocated through (__request_region) function, then the pointer (res->name) points to the allocated pointer (regionid). Then, there is no way in function (free_resource) or function (release_resource) to free the pointer (regionid) or (res->name). Thus, causing a potential memory leak! Function (reserve_range) source code reference: http://lxr.free-electrons.com/source/drivers/pnp/system.c#L25 Function (free_resource) source code reference:http://lxr.free-electrons.com/source/kernel/resource.c#L172 Function (release_resource) source code reference:http://lxr.free-electrons.com/source/kernel/resource.c#L322 ~Ahmed -- 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: frequent lockups in 3.18rc4
On Sun, 30 Nov 2014 16:21:19 -0800 Linus Torvalds wrote: > Maybe you'll have to turn off RCU_CPU_STALL_VERBOSE first. > > Although I think you should be able to just edit the .config file, > delete the like that says > > CONFIG_TREE_PREEMPT_RCU=y > > and then just do a "make oldconfig", and then verify that > TREE_PREEMPT_RCU hasn't been re-enabled by some dependency. But it > shouldn't have, and that "make oldconfig" should get rid of anything > that depends on TREE_PREEMPT_RCU. Ok, I did exactly that, but CONFIG_TREE_PREEMPT_RCU is re-enabled. I talked with Pranith Kumar and he suggested I could just disable preemption (No Forced Preemption (Server)) and that's the only way to disable CONFIG_TREE_PREEMPT_RCU. Now I'll try to make the system freeze, then I'll send you the Call trace. Thanks. -- Linux 3.17.0: Shuffling Zombie Juror http://www.youtube.com/DanielFragaBR http://exchangewar.info Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- 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 6/8 v2] crypto: replace memset by memzero_explicit
On Sun, 2014-11-30 at 18:03 +0100, Julia Lawall wrote: > From: Julia Lawall > > Memset on a local variable may be removed when it is called just before the > variable goes out of scope. Using memzero_explicit defeats this > optimization. A simplified version of the semantic patch that makes this > > Signed-off-by: Julia Lawall > > --- > Daniel Borkmann suggested that these patches could go through Herbert Xu's > cryptodev tree. That's fine by me: Acked-by: Michael Ellerman cheers -- 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: [RFC PATCH] set_mb: Use smp_store_release() instead of set_mb()
On Wed, Nov 26, 2014 at 11:57 AM, Pranith Kumar wrote:
> set_mb() and smp_store_release() perform the same function. Also there are
> only
> a few users of set_mb(). We can convert these users to use smp_store_release()
> and delete the set_mb() definition.
>
> The following patch changes the users and if this is OK I will go ahead and
> delete the set_mb() definition. Comments and suggestions welcome.
>
> Thanks!
> Pranith
>
> Signed-off-by: Pranith Kumar
Please disregard this patch. I just realized that I read the code
wrong. Sorry for the noise.
Thanks!
> ---
> fs/select.c | 6 +++---
> include/linux/sched.h | 14 +++---
> kernel/futex.c| 4 ++--
> kernel/sched/wait.c | 4 ++--
> 4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/fs/select.c b/fs/select.c
> index 467bb1c..959a908 100644
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -189,7 +189,7 @@ static int __pollwake(wait_queue_t *wait, unsigned mode,
> int sync, void *key)
> * doesn't imply write barrier and the users expect write
> * barrier semantics on wakeup functions. The following
> * smp_wmb() is equivalent to smp_wmb() in try_to_wake_up()
> -* and is paired with set_mb() in poll_schedule_timeout.
> +* and is paired with smp_store_release() in poll_schedule_timeout.
> */
> smp_wmb();
> pwq->triggered = 1;
> @@ -244,7 +244,7 @@ int poll_schedule_timeout(struct poll_wqueues *pwq, int
> state,
> /*
> * Prepare for the next iteration.
> *
> -* The following set_mb() serves two purposes. First, it's
> +* The following smp_store_release() serves two purposes. First, it's
> * the counterpart rmb of the wmb in pollwake() such that data
> * written before wake up is always visible after wake up.
> * Second, the full barrier guarantees that triggered clearing
> @@ -252,7 +252,7 @@ int poll_schedule_timeout(struct poll_wqueues *pwq, int
> state,
> * this problem doesn't exist for the first iteration as
> * add_wait_queue() has full barrier semantics.
> */
> - set_mb(pwq->triggered, 0);
> + smp_store_release(pwq->triggered, 0);
>
> return rc;
> }
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8db31ef..4621d0b 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -253,7 +253,7 @@ extern char ___assert_task_state[1 - 2*!!(
> #define set_task_state(tsk, state_value) \
> do {\
> (tsk)->task_state_change = _THIS_IP_; \
> - set_mb((tsk)->state, (state_value));\
> + smp_store_release((tsk)->state, (state_value)); \
> } while (0)
>
> /*
> @@ -272,10 +272,10 @@ extern char ___assert_task_state[1 - 2*!!(
> current->task_state_change = _THIS_IP_; \
> current->state = (state_value); \
> } while (0)
> -#define set_current_state(state_value) \
> - do {\
> - current->task_state_change = _THIS_IP_; \
> - set_mb(current->state, (state_value)); \
> +#define set_current_state(state_value) \
> + do {\
> + current->task_state_change = _THIS_IP_; \
> + smp_store_release(current->state, (state_value)); \
> } while (0)
>
> #else
> @@ -283,7 +283,7 @@ extern char ___assert_task_state[1 - 2*!!(
> #define __set_task_state(tsk, state_value) \
> do { (tsk)->state = (state_value); } while (0)
> #define set_task_state(tsk, state_value) \
> - set_mb((tsk)->state, (state_value))
> + smp_store_release((tsk)->state, (state_value))
>
> /*
> * set_current_state() includes a barrier so that the write of current->state
> @@ -299,7 +299,7 @@ extern char ___assert_task_state[1 - 2*!!(
> #define __set_current_state(state_value) \
> do { current->state = (state_value); } while (0)
> #define set_current_state(state_value) \
> - set_mb(current->state, (state_value))
> + smp_store_release(current->state, (state_value))
>
> #endif
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 63678b5..0604355 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2055,8 +2055,8 @@ static void futex_wait_queue_me(struct
> futex_hash_bucket *hb, struct futex_q *q,
> {
> /*
> * The task state is guaranteed to be set before another task can
> -* wake it. set_current_state() is implemented using set_mb() and
> -* queue_me() calls spin_unlock() upon completion, both serializing
> +*
Re: [Update 2x][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
On Sunday, November 30, 2014 10:45:39 AM Alan Stern wrote: > On Sat, 29 Nov 2014, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is > > selected) PM_RUNTIME is always set if PM is set, so quite a few > > #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to > > depend on CONFIG_PM (or even dropped in some cases). > > > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code > > and documentation. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > > > Added the Documentation/usb/power-management.txt changes. > > > > Of course, this depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME > > if PM_SLEEP is selected) which is in linux-next only (via linux-pm) at the > > moment. > > Acked-by: Alan Stern Thanks! Greg, would there be any problems if I took this into the linux-pm tree? Rafael -- 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] slab: Fix nodeid bounds check for non-contiguous node IDs
On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote: > (2014/12/01 7:16), Paul Mackerras wrote: > >The bounds check for nodeid in cache_alloc_node gives false > >positives on machines where the node IDs are not contiguous, leading > >to a panic at boot time. For example, on a POWER8 machine the node > >IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() > >returns 4, so when cache_alloc_node is called with nodeid = 16 the > >VM_BUG_ON triggers. > > Do you have the call trace? If you have it, please add it in the description. I can get it easily enough. > >To fix this, we instead compare the nodeid with MAX_NUMNODES, and > >additionally make sure it isn't negative (since nodeid is an int). > >The check is there mainly to protect the array dereference in the > >get_node() call in the next line, and the array being dereferenced is > >of size MAX_NUMNODES. If the nodeid is in range but invalid, the > >BUG_ON in the next line will catch that. > > > >Signed-off-by: Paul Mackerras > > Do you need to backport it into -stable kernels? It does need to go to stable, yes, for 3.10 and later. > >--- > >diff --git a/mm/slab.c b/mm/slab.c > >index eb2b2ea..f34e053 100644 > >--- a/mm/slab.c > >+++ b/mm/slab.c > >@@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache > >*cachep, gfp_t flags, > > void *obj; > > int x; > > > > >-VM_BUG_ON(nodeid > num_online_nodes()); > >+VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES); > > How about use: > VM_BUG_ON(!node_online(nodeid)); That would not be better, since node_online() doesn't bounds-check its argument. > When allocating the memory, the node of the memory being allocated must be > online. But your code cannot check the condition. The following two lines: > > n = get_node(cachep, nodeid); > > BUG_ON(!n); effectively check that condition already, as I tried to explain in the commit message. Regards, Paul. -- 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] x86: defconfig: Enable CONFIG_FHANDLE
Am 01.12.2014 um 01:18 schrieb Dave Chinner: > On Sun, Nov 30, 2014 at 10:08:01PM +0100, Richard Weinberger wrote: >> Am 30.11.2014 um 21:54 schrieb Dave Chinner: >>> On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote: systemd has a hard dependency on CONFIG_FHANDLE. If you run systemd with CONFIG_FHANDLE=n it will somehow boot but fail to spawn a getty or other basic services. As systemd is now used by most x86 distributions it makes sense to enabled this by default and save kernel hackers a lot of value debugging time. >>> >>> The bigger question to me is this: why does systemd need to >>> store/open by handle rather than just opening paths directly when >>> needed? This interface is intended for stable, pathless access to >>> inodes across unmount/mount contexts (e.g. userspace NFS servers, >>> filesystem backup programs, etc) so I'm curious as to the problem >>> systemd is solving using this interface. I just can't see the >>> problem being solved here, and why path based security checks on >>> every open() aren't necessary... >> >> Digging inter systemd source shows that they are using name_to_handle_at() >> to get the mount id of a given path. > > From the name_to_handle_at() man page: > > The mount_id argument returns an identifier for the filesystem > mount that corresponds to pathname. This corresponds to the > first field in one of the records in /proc/self/mountinfo. > Opening the pathname in the fifth field of that record yields a > file descriptor for the mount point; that file descriptor can be > used in a subsequent call to open_by_handle_at(). > > So why do they need CONFIG_FHANDLE to get the mount id in userspace? > Indeed, what do they even need the mount id for? > >> The actual struct file_handle result is always ignored. > > That sounds like a classic case of interface abuse. i.e. using an > interface for something it was not designed or intended for CC'ing systemd folks. Lennart, can you please explain why you need CONFIG_FHANDLE for systemd? Maybe I'm reading the source horrible wrong. Thanks, //richard -- 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 next-20141127] mm: Fix comment typo "CONFIG_TRANSPARNTE_HUGE"
Hello, On Thu, Nov 27, 2014 at 01:57:11PM +0100, Paul Bolle wrote: > The commit "mm: don't split THP page when syscall is called" added a > reference to CONFIG_TRANSPARNTE_HUGE in a comment. Use > CONFIG_TRANSPARENT_HUGEPAGE instead, as was probably intended. > > Signed-off-by: Paul Bolle Acked-by: Minchan Kim Thanks! > --- > Compile tested. > > If commit "mm: don't split THP page when syscall is called" is not yet > set in stone, I would prefer if this trivial fix would be squashed into > that commit. Hope so. :) > > mm/rmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/rmap.c b/mm/rmap.c > index d2a6e136b08d..95d394bbb6ab 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -708,7 +708,7 @@ static int page_referenced_one(struct page *page, struct > vm_area_struct *vma, > /* >* Use pmd_freeable instead of raw pmd_dirty because in some >* of architecture, pmd_dirty is not defined unless > - * CONFIG_TRANSPARNTE_HUGE is enabled > + * CONFIG_TRANSPARENT_HUGEPAGE is enabled >*/ > if (!pmd_freeable(*pmd)) > dirty++; > -- > 1.9.3 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- 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: [RFC PATCH] mm/zsmalloc: allocate exactly size of struct zs_pool
On Sat, Nov 29, 2014 at 07:23:55PM +0800, Ganesh Mahendran wrote: > In zs_create_pool(), we allocate memory more then sizeof(struct zs_pool) > ovhd_size = roundup(sizeof(*pool), PAGE_SIZE); > > This patch allocate memory of exactly needed size. > > Signed-off-by: Ganesh Mahendran Acked-by: Minchan Kim -- Kind regards, Minchan Kim -- 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 3/3] arm: dts: zynq: Add Digilent ZYBO board
On Sat, Nov 29, 2014 at 1:34 PM, Sören Brinkmann wrote: > Hi Peter, > > The patches look all good to me. But you may want to check your CC > lists. I think at least the DT list should be included. > Resent > For the whole series: > Acked-by: Soren Brinkmann > Thanks, Regards, Peter > Thanks, > Sören > -- 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/
