[PATCH] media: Fix get_key_haup_common.isra.4() debug message to print ptoggle value
Fix the debug message in get_key_haup_common.isra.4() doesn't print the
correct toggle value. Fix it. This shows up as an used uninitialized warn
message:
drivers/media/i2c/ir-kbd-i2c.c: In function ‘get_key_haup_common.isra.4’:
drivers/media/i2c/ir-kbd-i2c.c:62:2: warning: ‘toggle’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
printk(KERN_DEBUG MODULE_NAME ": " fmt , ## arg)
^~
drivers/media/i2c/ir-kbd-i2c.c:70:20: note: ‘toggle’ was declared here
int start, range, toggle, dev, code, ircode, vendor;
^~
Signed-off-by: Shuah Khan
---
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index f95a6bc..cede397 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -118,7 +118,7 @@ static int get_key_haup_common(struct IR_i2c *ir, enum
rc_type *protocol,
*protocol = RC_TYPE_RC6_MCE;
dev &= 0x7f;
dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d
dev=%d code=%d\n",
- toggle, vendor, dev, code);
+ *ptoggle, vendor, dev, code);
} else {
*ptoggle = 0;
*protocol = RC_TYPE_RC6_6A_32;
--
2.9.3
[PATCH] media: fix uninitialized variable warning in dib0700_rc_urb_completion()
Fix the following uninitialized variable compiler warning:
drivers/media/usb/dvb-usb/dib0700_core.c: In function
‘dib0700_rc_urb_completion’:
drivers/media/usb/dvb-usb/dib0700_core.c:763:2: warning: ‘protocol’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
rc_keydown(d->rc_dev, protocol, keycode, toggle);
^~~~
Signed-off-by: Shuah Khan
---
drivers/media/usb/dvb-usb/dib0700_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
b/drivers/media/usb/dvb-usb/dib0700_core.c
index f319665..cfe28ec 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -676,7 +676,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
{
struct dvb_usb_device *d = purb->context;
struct dib0700_rc_response *poll_reply;
- enum rc_type protocol;
+ enum rc_type protocol = RC_TYPE_UNKNOWN;
u32 uninitialized_var(keycode);
u8 toggle;
--
2.9.3
[PATCH] net/netfiliter: Fix used uninitialized warn in ip_vs_proc_sync_conn()
Fix the following warn:
net/netfilter/ipvs/ip_vs_sync.c: In function ‘ip_vs_proc_sync_conn’:
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.init_seq’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
struct ip_vs_sync_conn_options opt;
^~~
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.delta’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.previous_delta’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
*)&opt+12).init_seq’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).delta’
may be used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
*)&opt+12).previous_delta’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Signed-off-by: Shuah Khan
---
fs/nfs/nfs4session.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
index b629730..68e700e 100644
--- a/fs/nfs/nfs4session.c
+++ b/fs/nfs/nfs4session.c
@@ -196,7 +196,7 @@ static int nfs4_slot_get_seqid(struct nfs4_slot_table
*tbl, u32 slotid,
static bool nfs4_slot_seqid_in_use(struct nfs4_slot_table *tbl,
u32 slotid, u32 seq_nr)
{
- u32 cur_seq;
+ u32 cur_seq = 0;
bool ret = false;
spin_lock(&tbl->slot_tbl_lock);
--
2.9.3
Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option
Hi Robin,
On Tue, Nov 1, 2016 at 12:46 PM, Robin Murphy wrote:
To aid debugging and catch devices not supporting DMA to memory outside
the 32-bit address space, add a kernel command line option
"swiotlb=nobounce", which disables the use of bounce buffers.
If specified, trying to map memory that cannot be used with DMA will
fail, and a warning will be printed (rate-limited).
>>>
>>> This rationale seems questionable - how useful is non-deterministic
>>> behaviour for debugging really? What you end up with is DMA sometimes
>>> working or sometimes not depending on whether allocations happen to
>>> naturally fall below 4GB or not. In my experience, that in itself can be
>>> a pain in the arse to debug.
>>
>> It immediately triggered for me, though:
>>
>> rcar-dmac e730.dma-controller: Cannot do DMA to address
>> 0x00067a9b7000
>> ravb e680.ethernet: Cannot do DMA to address 0x00067aa07780
>>
>>> Most of the things you might then do to make things more deterministic
>>> again (like making the default DMA mask tiny or hacking out all the
>>> system's 32-bit addressable RAM) are also generally sufficient to make
>>> DMA fail earlier and make this option moot anyway. What's the specific
>>> use case motivating this?
>>
>> My use case is finding which drivers and DMA engines do not support 64-bit
>> memory. There's more info in my series "[PATCH/RFC 0/5] arm64: r8a7796:
>> 64-bit
>> Memory and Ethernet Prototype"
>> (https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg08393.html)
>
> Thanks for the context. I've done very similar things in the past, and
> my first instinct would be to change the default DMA mask in
> of_dma_configure() to something which can't reach RAM (e.g. <30 bits),
> then instrument dma_set_mask() to catch cleverer drivers. That's a
> straightforward way to get 100% coverage - the problem with simply
> disabling bounce buffering is that whilst statistically it almost
> certainly will catch >95% of cases, there will always be some that it
> won't; if some driver only ever does a single dma_alloc_coherent() early
> enough that allocations are still fairly deterministic, and always
> happens to get a 32-bit address on that platform, it's likely to slip
> through the net.
>
> I'm not against the idea of SWIOTLB growing a runtime-disable option,
> I'm just not sure what situation it's actually the best solution for.
If I set the DMA mask to a small value, DMA is never used, and SWIOTLB
always falls back to bounce buffers (and DMAing from the small pool)?
That's the inverse of what I want to achieve: I want to avoid using the
bounce feature, to make sure the DMA engine is always used with whatever
kind of memory.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] net/netfilter: Fix use uninitialized warn in nft_range_eval()
Fix the following warn:
CC [M] net/netfilter/nft_range.o
8601,8605c9105
net/netfilter/nft_range.c: In function ‘nft_range_eval’:
net/netfilter/nft_range.c:45:5: warning: ‘mismatch’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
if (mismatch)
^
Signed-off-by: Shuah Khan
---
net/netfilter/nft_range.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nft_range.c b/net/netfilter/nft_range.c
index c6d5358..fe5f69b 100644
--- a/net/netfilter/nft_range.c
+++ b/net/netfilter/nft_range.c
@@ -28,7 +28,7 @@ static void nft_range_eval(const struct nft_expr *expr,
const struct nft_pktinfo *pkt)
{
const struct nft_range_expr *priv = nft_expr_priv(expr);
- bool mismatch;
+ bool mismatch = false;
int d1, d2;
d1 = memcmp(®s->data[priv->sreg], &priv->data_from, priv->len);
--
2.9.3
Re: [PATCH] coresight: Add support for ARM Coresight STM-500
On 2 November 2016 at 10:19, Suzuki K Poulose wrote:
> Add the PIDs for STM-500 to the known STM devices list.
>
> Cc: Mathieu Poirier
> Cc: Chunyan Zhang
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-stm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c
> b/drivers/hwtracing/coresight/coresight-stm.c
> index 49e0f1b..3524452 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -920,6 +920,11 @@ static struct amba_id stm_ids[] = {
> .mask = 0x0003,
> .data = "STM32",
> },
> + {
> + .id = 0x0003b963,
> + .mask = 0x0003,
> + .data = "STM500",
> + },
> { 0, 0},
> };
Applied - thanks,
Mathieu
>
> --
> 2.7.4
>
BUG: 'list_empty(&vgdev->free_vbufs)' is true!
Hi, I can relatively easily reproduce this bug: BUG: 'list_empty(&vgdev->free_vbufs)' is true! [ cut here ] kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! invalid opcode: [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-next-20161028+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Workqueue: events drm_fb_helper_dirty_work task: 88007b124980 task.stack: 88007b8a RIP: 0010:virtio_gpu_get_vbuf+0x32e/0x630 RSP: 0018:88007b8a78c0 EFLAGS: 00010286 RAX: 002e RBX: 11000f714f1d RCX: RDX: 002e RSI: 0001 RDI: ed000f714f0e RBP: 88007b8a7970 R08: 0001 R09: R10: 0002 R11: 0001 R12: 0030 R13: 88007caeaba8 R14: 0018 R15: 88007cae FS: () GS:88007dc8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00601028 CR3: 7740d000 CR4: 06e0 Call Trace: Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 bb 01 00 00 4c 89 69 e8 eb 9e 48 c7 c6 e0 d2 d1 83 48 c7 c7 20 d3 d1 83 e8 6c fb 04 ff <0f> 0b 48 c7 c7 a0 fb b0 85 e8 09 95 86 ff 48 c7 c6 c0 d3 d1 83 RIP: virtio_gpu_get_vbuf+0x32e/0x630 RSP: 88007b8a78c0 There is no stacktrace, as the kernel starts panicing all over the place during its generation. Any ideas? thanks, -- js suse labs
Re: [PATCH] net/netfiliter: Fix used uninitialized warn in ip_vs_proc_sync_conn()
Hi Shuah,
On 11/07/2016 10:41 AM, Shuah Khan wrote:
> Fix the following warn:
>
> net/netfilter/ipvs/ip_vs_sync.c: In function ‘ip_vs_proc_sync_conn’:
> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.init_seq’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>struct ip_vs_sync_conn_options opt;
> ^~~
> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.delta’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.previous_delta’ may
> be used uninitialized in this function [-Wmaybe-uninitialized]
> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
> *)&opt+12).init_seq’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).delta’
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
> *)&opt+12).previous_delta’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
Are you sure you put the right commit message on this patch? The message
describes a warning in ip_vs_sync.c, but the patch is for nfs4session.c.
Thanks,
Anna
>
> Signed-off-by: Shuah Khan
> ---
> fs/nfs/nfs4session.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
> index b629730..68e700e 100644
> --- a/fs/nfs/nfs4session.c
> +++ b/fs/nfs/nfs4session.c
> @@ -196,7 +196,7 @@ static int nfs4_slot_get_seqid(struct nfs4_slot_table
> *tbl, u32 slotid,
> static bool nfs4_slot_seqid_in_use(struct nfs4_slot_table *tbl,
> u32 slotid, u32 seq_nr)
> {
> - u32 cur_seq;
> + u32 cur_seq = 0;
> bool ret = false;
>
> spin_lock(&tbl->slot_tbl_lock);
>
Re: [PATCHv4 0/4] WX checking for arm64
On Sun, Oct 30, 2016 at 03:03:07PM +, Catalin Marinas wrote:
> On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote:
> > Laura Abbott (4):
> > arm64: dump: Make ptdump debugfs a separate option
> > arm64: dump: Make the page table dumping seq_file optional
> > arm64: dump: Remove max_addr
> > arm64: dump: Add checking for writable and exectuable pages
>
> Queued for 4.10. Thanks.
Catalin mentioned to me that he saw some KASAN splats when testing; it
looks like need a fixup something like the below.
Apologies for not having spotted this when testing!
Thanks,
Mark.
>8
>From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
From: Mark Rutland
Date: Mon, 7 Nov 2016 15:24:40 +
Subject: [PATCH] Fix KASAN splats with DEBUG_WX
Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX
results in a stream of KASAN splats for stack-out-of-bounds accesses,
e.g.
==
BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr 8009364ebdd0
Read of size 8 by task swapper/0/1
page:7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-4-g25f7267 #77
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[] dump_backtrace+0x0/0x278
[] show_stack+0x14/0x20
[] dump_stack+0xa4/0xc8
[] kasan_report_error+0x4a8/0x4d0
[] kasan_report+0x40/0x48
[] __asan_load8+0x84/0x98
[] note_page+0xd8/0x650
[] walk_pgd.isra.1+0x114/0x220
[] ptdump_check_wx+0xa8/0x118
[] mark_rodata_ro+0x90/0xd0
[] kernel_init+0x28/0x110
[] ret_from_fork+0x10/0x50
Memory state around the buggy address:
8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2
^
8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00
8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
... this happens because note_page assumes that the marker array has at
least two elements (the latter of which may be the terminator), but the
marker array for ptdump_check_wx only contains one element. Thus we
dereference some garbage on the stack when looking at
marker[1].start_address.
Given we don't need the markers for the WX checks, we could modify
note_page to allow for a NULL marker array, but for now it's simpler to
add an entry to the ptdump_check_wx marker array, so let's do that. As
it's somewhat confusing to have two identical entries, we add an initial
entry with a start address of zero.
Reported-by: Catalin Marinas
Signed-off-by: Mark Rutland
---
arch/arm64/mm/dump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index ef8aca8..ca74a2a 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -383,6 +383,7 @@ void ptdump_check_wx(void)
struct pg_state st = {
.seq = NULL,
.marker = (struct addr_marker[]) {
+ { 0, NULL},
{ -1, NULL},
},
.check_wx = true,
--
1.9.1
Re: [PATCH] tracing: spelling fixes for CONFIG_HWLAT_TRACER
On Mon, 31 Oct 2016 11:08:28 +0100
Jesper Dangaard Brouer wrote:
> Trivial spelling fixes for Kconfig help text of config HWLAT_TRACER.
>
> Fixes: e7c15cd8a113 ("tracing: Added hardware latency tracer")
> Signed-off-by: Jesper Dangaard Brouer
Acked-by: Steven Rostedt
-- Steve
> ---
> kernel/trace/Kconfig |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index 2a96b063d659..fd241ef8febe 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -221,7 +221,7 @@ config HWLAT_TRACER
> select GENERIC_TRACER
> help
>This tracer, when enabled will create one or more kernel threads,
> - depening on what the cpumask file is set to, which each thread
> + depending on what the cpumask file is set to, which each thread
>spinning in a loop looking for interruptions caused by
>something other than the kernel. For example, if a
>System Management Interrupt (SMI) takes a noticeable amount of
> @@ -236,7 +236,7 @@ config HWLAT_TRACER
>iteration
>
>A kernel thread is created that will spin with interrupts disabled
> - for "width" microseconds in every "widow" cycle. It will not spin
> + for "width" microseconds in every "window" cycle. It will not spin
>for "window - width" microseconds, where the system can
>continue to operate.
>
Re: [PATCH 0/5] drm/sun4i: Handle TV overscan
On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote: > Hi Russell, > > On Thu, Nov 03, 2016 at 09:54:45AM +, Russell King - ARM Linux wrote: > > > Yes. And that is an XBMC only solution, that doesn't work with the > > > fbdev emulation and is probably doing an additional composition to > > > scale down and center their frames through OpenGL. > > > > Well, it will have to be doing a scaling step anyway. If the video > > frame is a different size to the active area, scaling is required > > no matter what. A 576p SD image needs to be scaled up, and a 1080p > > image would need to be scaled down for a 1080p overscanned display > > with a reduced active area to counter the overscanning - no matter > > how you do it. > > Yes, except that scaling is not always an option. In my particular > example, there's no scaler after the CRTC, which essentially prevents > it from being used in that use case. Which is also why I ended up > reducing the mode reported to the user. I think you completely missed my point. Let me try again. If you expose a reduced mode to the user, you are reporting that (eg) the 1080p-timings mode does not have 1920 pixels horizontally, and 1080 lines. You are instead reporting that it has (eg) 1800 pixels horizontally and maybe 1000 lines. So, when you play back a 1080 video, you are going to have to either: 1. crop the extra 120 pixels horizontally and 80 lines vertically or 2. scale the image. However, this is a completely independent issue to how we go about setting a video mode that is 1800x1000 in the first place. What you're suggesting is that we add code to the kernel to report that your non-EDID, analogue output transforms the standard 1920x1080 timings such that it has a 1800x1000 active area. I'm suggesting instead that you can do the same thing in userspace by specifically adding a mode which has the 1920x1080 standard timings, but with the porches increased and the active area reduced - in exactly the same way that you'd have to do within the kernel to report your active-area-reduced 1800x1000 mode. > > For graphics, userspace could add mode(s) with increased porches and > > reduced active area itself to achieve an underscanned display on a > > timing which the display device always overscans - there's no need to > > do that in the kernel, all the APIs are there to be able to do it > > already. > > > > That means your framebuffer will be smaller, but that's the case > > anyway. > > Yes, that would be a good idea. But it's not always an option for > applications that would rely on the fbdev emulation (like QT's eglfs), > which would then have no way to change whatever default there is (and > the only one able to know how bad it actually is is the user). I guess this is the problem with DRM people wanting to deprecate fbdev... too much stuff currently relies upon it, but DRM on x86 has always had the reduced functionality. I guess there's two solutions here: 1. Either DRMs fbdev gains increased functionality, or 2. The fbdev-only applications/libraries need to be ported over to support DRM natively. This has been a bar for some time to moving over to DRM, and I've heard very little desire on either side to find some sort of compromise on the issue, so I guess things are rather stuck where they are. > > So, I may want my graphics to appear on an overscanned display such > > that I can see the borders, but I may want the overlaid video to use > > the full active area (including overscan) to hide some of the broadcast > > mess at the edges of the screen. > > > > > > Yea, that's quite sad, "analog" has become a dirty word, but really > > > > this has nothing to do with "analog" at all - there are LCD TVs (and > > > > some monitors) out there which take HDMI signals but refuse to > > > > disable overscan no matter what you do to them if you provide them > > > > with a "broadcast" mode - so the analog excuse is very poor. > > > > > > I'd agree with you, but I was also told to not turn that into a > > > generic code and deal with that in my driver. > > > > I guess whoever told you that was wrong. I used to have a cheap TV > > here which took HDMI, and always overscans broadcast modes, and > > underscans PC modes. No amount of fiddling with various settings > > (either in the TV or AVI frames) changes that. > > > > I've run into that with a _monitor_ that Andrew Hutton has, which has > > a HDMI input - exactly the same thing - 1080p, 720p etc are all > > unconditionally overscanned, 1024x768 etc are all unconditionally > > underscanned and there's nothing that can be done to change it. > > > > The problem is that TVs are at liberty to have this behaviour, so > > the overscaned problem is always going to be there, and each driver > > should not be dealing with it in their own specific ways. > > I agree with you, however, without any directions on how to do this, > and willingness to merge this, I don't really see why we would work on > such a gene
Re: [PATCH v2 1/2] regulator: Add coupled regulator
Hi Mark, On Fri, Feb 05, 2016 at 03:32:58PM +, Mark Brown wrote: > On Fri, Feb 05, 2016 at 03:33:28PM +0100, Maxime Ripard wrote: > > On Thu, Jan 21, 2016 at 04:28:02PM +, Mark Brown wrote: > > > On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote: > > > > > Anyway, I'm fine with both approaches, just let me know what you > > > > prefer. > > > > Without seeing an implementation of the lists it's hard to say. > > > Just to make sure we're on the same page: you want to keep the > > regulator, but instead of giving the parent through vinX-supplies > > properties, you want to have a single *-supply property, with a list > > of regulators, right? > > Either that or an explicit regulator describing the merge. Rob wants > the list I think but I really don't care. So, I'm reviving this old thread after speaking to you about it at ELCE and trying to code something up, and getting lost.. To put a bit of context, I'm still trying to tackle the issue of devices that have two regulators powering them on the same pin for example when each regulator cannot provide enough current alone to power the device (all the setups like this one I've seen so far were for WiFi chips, but it might be different). I guess we already agreed on the fact that the DT binding should just be to allow a *-supply property to take multiple regulators, and mark them as "coupled" (or whatever name we see fit) in such a case. Since regulator_get returns a struct regulator pointer, it felt logical to try to add the list of parent regulators to it, especially as this structure is per-consumer, and different consumers might have different combinations of regulators. However, this structure embeds a pointer to a struct regulator_dev, which seems to model the regulator itself, but will also contain pointer to the struct regulator, probably to model its parent? I guess my first question would be do we care about nesting? or having a regulator with multiple parents? It also contains the constraints on each regulator, which might or might not be different for each of the coupled regulators, but I'm guessing the couple might have contraints of its own too I guess. Is it something that might happen? Should we care about it? And finally, my real question is, do we want to aggregate them in struct regulator, at the consumer level, which might make the more sense, or do we want to create an intermediate regulator internally? What is your take on this? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCHSET v2] block: IO polling improvements
> Fixed a few bugs in this, and addressed some review comments. Patches > are against my 4.10 block branch, for-4.10/block. Jens Thanks for proposing this. Looks very cool. I will try and get you a review and some testing this week... Cheers Stephen
Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0
On 07/11/16 14:59, Mika Westerberg wrote:
> On Mon, Nov 07, 2016 at 02:40:47PM +, Marc Zyngier wrote:
>> Sorry, missed this discussion entirely, as I was on the other side of
>> the world. Not having a irq_set_type definitely seems odd (and
>> configuring the trigger outside of the IRQ framework is quite ugly).
>>
>> Mika, can you please try the following (which is fully untested)?
>>
>> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
>> index 48e6d84..822a6b8 100644
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -1868,6 +1868,15 @@ static int ioapic_set_affinity(struct irq_data
>> *irq_data,
>> return ret;
>> }
>>
>> +static int ioapic_set_type(struct irq_data *data, unsigned int flow_type)
>> +{
>> +/*
>> + * The IOAPIC has already been programmed behind our back,
>> + * just pretend it all went OK, and too bad if it didn't.
>> + */
>> +return 0;
>> +}
>> +
>> static struct irq_chip ioapic_chip __read_mostly = {
>> .name = "IO-APIC",
>> .irq_startup= startup_ioapic_irq,
>> @@ -1876,6 +1885,7 @@ static struct irq_chip ioapic_chip __read_mostly = {
>> .irq_ack= irq_chip_ack_parent,
>> .irq_eoi= ioapic_ack_level,
>> .irq_set_affinity = ioapic_set_affinity,
>> +.irq_set_type = ioapic_set_type,
>> .flags = IRQCHIP_SKIP_SET_WAKE,
>> };
>
> Thanks! This fixes the problem for me.
Good to know. The more I think about this, the more I wonder if we
should have a dummy 'set_type' as this is just hiding the issue. If the
original warning does not impact the overall behaviour (ie. interrupts
still working) then may be it is legitimate as far as gen-irq is concerned?
Jon
--
nvpublic
Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
From: Madalin-Cristian Bucur Date: Mon, 7 Nov 2016 15:43:26 + >> From: David Miller [mailto:da...@davemloft.net] >> Sent: Thursday, November 03, 2016 9:58 PM >> >> Why? By clearing this, you disallow an important fundamental way to do >> performane testing, via pktgen. > > The Tx path in DPAA requires one to insert a back-pointer to the skb into > the Tx buffer. On the Tx confirmation path the back-pointer in the buffer > is used to release the skb. If Tx buffer is shared we'd alter the back-pointer > and leak/double free skbs. See also Then have your software state store an array of SKB pointers, one for each TX ring entry, just like every other driver does.
Re: [PATCH v3 1/2] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems
On Mon, Nov 07, 2016 at 03:07:46PM +0100, Ingo Molnar wrote:
> - cache domains might be seriously mixed up, resulting in serious drop in
>performance.
>
> - or domains might be partitioned 'wrong' but not catastrophically
> wrong, resulting in a minor performance drop (if at all)
Something between the two.
Here's some debugging output from set_cpu_sibling_map():
[0.202033] smpboot: set_cpu_sibling_map: cpu: 0, has_smt: 0, has_mp: 1
[0.202043] smpboot: set_cpu_sibling_map: first loop, llc(this): 65528, o:
0, llc(o): 65528
[0.202058] smpboot: set_cpu_sibling_map: first loop, link mask smt
so we link it into the SMT mask even if has_smt is off.
[0.202067] smpboot: set_cpu_sibling_map: first loop, link mask llc
[0.202077] smpboot: set_cpu_sibling_map: second loop, llc(this): 65528, o:
0, llc(o): 65528
[0.202091] smpboot: set_cpu_sibling_map: second loop, link mask die
I've attached the debug diff.
And since those llc(o), i.e. the cpu_llc_id of the *other* CPU in the
loops in set_cpu_sibling_map() underflows, we're generating the funniest
thread_siblings masks and then when I run 8 threads of nbench, they get
spread around the LLC domains in a very strange pattern which doesn't
give you the normal scheduling spread one would expect for performance.
And this is just one workload - I can't imagine what else might be
influenced by this funkiness.
Oh and other things like EDAC use cpu_llc_id so they will be b0rked too.
So we absolutely need to fix that cpu_llc_id thing.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 601d2b331350..5974098d8266 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -506,6 +506,9 @@ void set_cpu_sibling_map(int cpu)
struct cpuinfo_x86 *o;
int i, threads;
+ pr_info("%s: cpu: %d, has_smt: %d, has_mp: %d\n",
+ __func__, cpu, has_smt, has_mp);
+
cpumask_set_cpu(cpu, cpu_sibling_setup_mask);
if (!has_mp) {
@@ -519,11 +522,19 @@ void set_cpu_sibling_map(int cpu)
for_each_cpu(i, cpu_sibling_setup_mask) {
o = &cpu_data(i);
- if ((i == cpu) || (has_smt && match_smt(c, o)))
+ pr_info("%s: first loop, llc(this): %d, o: %d, llc(o): %d\n",
+ __func__, per_cpu(cpu_llc_id, cpu),
+ o->cpu_index, per_cpu(cpu_llc_id, o->cpu_index));
+
+ if ((i == cpu) || (has_smt && match_smt(c, o))) {
+ pr_info("%s: first loop, link mask smt\n", __func__);
link_mask(topology_sibling_cpumask, cpu, i);
+ }
- if ((i == cpu) || (has_mp && match_llc(c, o)))
+ if ((i == cpu) || (has_mp && match_llc(c, o))) {
+ pr_info("%s: first loop, link mask llc\n", __func__);
link_mask(cpu_llc_shared_mask, cpu, i);
+ }
}
@@ -534,7 +545,12 @@ void set_cpu_sibling_map(int cpu)
for_each_cpu(i, cpu_sibling_setup_mask) {
o = &cpu_data(i);
+ pr_info("%s: second loop, llc(this): %d, o: %d, llc(o): %d\n",
+ __func__, per_cpu(cpu_llc_id, cpu),
+ o->cpu_index, per_cpu(cpu_llc_id, o->cpu_index));
+
if ((i == cpu) || (has_mp && match_die(c, o))) {
+ pr_info("%s: second loop, link mask die\n", __func__);
link_mask(topology_core_cpumask, cpu, i);
/*
Re: [PATCH 1/2] irq,pci: allow drivers to specify complex affinity requirement
On Sun, 6 Nov 2016, Christoph Hellwig wrote:
> drivers/pci/msi.c | 61
> include/linux/interrupt.h | 26 ---
> include/linux/pci.h | 14 ++
> kernel/irq/affinity.c | 65
> ---
Can you please split that up in bits and pieces. This change it all patch
is not fun to review.
> 4 files changed, 98 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index bfdd074..c312535 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -551,14 +551,15 @@ static int populate_msi_sysfs(struct pci_dev *pdev)
> }
>
> static struct msi_desc *
> -msi_setup_entry(struct pci_dev *dev, int nvec, bool affinity)
> +msi_setup_entry(struct pci_dev *dev, int nvec, bool affinity,
> + struct irq_affinity *desc)
This should be 'const struct '. And can we please name this *affd or
something like that?
> {
> struct cpumask *masks = NULL;
> struct msi_desc *entry;
> u16 control;
>
> if (affinity) {
If we do it right, then we can get rid of the bool and depend on that irq
affinity pointer. We just have to push down the flag evaluation to
pci_alloc_irq_vectors[_affinity].
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -232,6 +232,24 @@ struct irq_affinity_notify {
> void (*release)(struct kref *ref);
> };
>
> +/*
> + * This structure allows drivers to optionally specify complex IRQ affinity
> + * requirements.
> + */
> +struct irq_affinity {
> + /*
> + * Number of vectors before the main affinity vectors that should not
> + * have have any CPU affinity:
> + */
Please make that kernel doc.
> + int pre_vectors;
> +
> + /*
> + * Number of vectors after the main affinity vectors that should not
> + * have have any CPU affinity:
> + */
> + int post_vectors;
> +};
> +
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0e49f70..be0abd2 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
...
> +#define pci_alloc_irq_vectors(dev, min_vecs, max_vecs, flags) \
> + pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs, flags, NULL)
static inline please
> #endif /* LINUX_PCI_H */
> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
> index 17f51d63..151b285 100644
> --- a/kernel/irq/affinity.c
> +++ b/kernel/irq/affinity.c
> @@ -51,16 +51,16 @@ static int get_nodes_in_cpumask(const struct cpumask
> *mask, nodemask_t *nodemsk)
>
> /**
> * irq_create_affinity_masks - Create affinity masks for multiqueue spreading
> - * @affinity:The affinity mask to spread. If NULL
> cpu_online_mask
> - * is used
> + * @desc:description of the affinity requirements
@affd and sentence starts with an uppercase letter, please.
> * @nvecs: The number of vectors
If you rename the argument then you want to rename this as well.
> *
> * Returns the masks pointer or NULL if allocation failed.
> */
> -struct cpumask *irq_create_affinity_masks(const struct cpumask *affinity,
> - int nvec)
> +struct cpumask *irq_create_affinity_masks(struct irq_affinity *desc,
> + int total_nvec)
Thanks,
tglx
RE: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, November 03, 2016 9:58 PM
>
> From: Madalin Bucur
> Date: Wed, 2 Nov 2016 22:17:26 +0200
>
> > This introduces the Freescale Data Path Acceleration Architecture
> > +static inline size_t bpool_buffer_raw_size(u8 index, u8 cnt)
> > +{
> > + u8 i;
> > + size_t res = DPAA_BP_RAW_SIZE / 2;
>
> Always order local variable declarations from longest to shortest line,
> also know as Reverse Christmas Tree Format.
>
> Please audit your entire submission for this problem, it occurs
> everywhere.
Thank you, I'll resolve this.
> > + /* we do not want shared skbs on TX */
> > + net_dev->priv_flags &= ~IFF_TX_SKB_SHARING;
>
> Why? By clearing this, you disallow an important fundamental way to do
> performane testing, via pktgen.
The Tx path in DPAA requires one to insert a back-pointer to the skb into
the Tx buffer. On the Tx confirmation path the back-pointer in the buffer
is used to release the skb. If Tx buffer is shared we'd alter the back-pointer
and leak/double free skbs. See also
static int dpaa_start_xmit(struct sk_buff *skb, struct net_device
*net_dev)
{
...
if (!nonlinear) {
/* We're going to store the skb backpointer at the
beginning
* of the data buffer, so we need a privately owned skb
*
* We've made sure skb is not shared in dev->priv_flags,
* we need to verify the skb head is not cloned
*/
if (skb_cow_head(skb, priv->tx_headroom))
goto enomem;
WARN_ON(skb_is_nonlinear(skb));
}
...
> > + int numstats = sizeof(struct rtnl_link_stats64) / sizeof(u64);
> ...
> > + cpustats = (u64 *)&percpu_priv->stats;
> > +
> > + for (j = 0; j < numstats; j++)
> > + netstats[j] += cpustats[j];
>
> This is a memcpy() on well-typed datastructures which requires no
> casting or special handling whatsoever, so use memcpy instead of
> needlessly open coding the operation.
Will fix.
> > +static int dpaa_change_mtu(struct net_device *net_dev, int new_mtu)
> > +{
> > + const int max_mtu = dpaa_get_max_mtu();
> > +
> > + /* Make sure we don't exceed the Ethernet controller's MAXFRM */
> > + if (new_mtu < 68 || new_mtu > max_mtu) {
> > + netdev_err(net_dev, "Invalid L3 mtu %d (must be between %d and
> %d).\n",
> > + new_mtu, 68, max_mtu);
> > + return -EINVAL;
> > + }
> > + net_dev->mtu = new_mtu;
> > +
> > + return 0;
> > +}
>
> MTU restrictions are handled in the net-next tree via net_dev->min_mtu and
> net_dev->max_mtu. Use that and do not define this NDO operation as you do
> not need it.
OK
> > +static int dpaa_set_features(struct net_device *dev, netdev_features_t
> features)
> > +{
> > + /* Not much to do here for now */
> > + dev->features = features;
> > + return 0;
> > +}
>
> Do not define unnecessary NDO operations, let the defaults do their job.
>
> > +static netdev_features_t dpaa_fix_features(struct net_device *dev,
> > + netdev_features_t features)
> > +{
> > + netdev_features_t unsupported_features = 0;
> > +
> > + /* In theory we should never be requested to enable features that
> > +* we didn't set in netdev->features and netdev->hw_features at
> probe
> > +* time, but double check just to be on the safe side.
> > +*/
> > + unsupported_features |= NETIF_F_RXCSUM;
> > +
> > + features &= ~unsupported_features;
> > +
> > + return features;
> > +}
>
> Unless you can show that your need this, do not "guess" by implement this
> NDO operation. You don't need it.
Will remove it.
> > +#ifdef CONFIG_FSL_DPAA_ETH_FRIENDLY_IF_NAME
> > +static int dpaa_mac_hw_index_get(struct platform_device *pdev)
> > +{
> > + struct device *dpaa_dev;
> > + struct dpaa_eth_data *eth_data;
> > +
> > + dpaa_dev = &pdev->dev;
> > + eth_data = dpaa_dev->platform_data;
> > +
> > + return eth_data->mac_hw_id;
> > +}
> > +
> > +static int dpaa_mac_fman_index_get(struct platform_device *pdev)
> > +{
> > + struct device *dpaa_dev;
> > + struct dpaa_eth_data *eth_data;
> > +
> > + dpaa_dev = &pdev->dev;
> > + eth_data = dpaa_dev->platform_data;
> > +
> > + return eth_data->fman_hw_id;
> > +}
> > +#endif
>
> Do not play network device naming games like this, use the standard name
> assignment done by the kernel and have userspace entities do geographic or
> device type specific naming.
>
> I want to see this code completely removed.
I'll remove the option, udev rules like these can achieve the same effect:
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="ffe4e",
NAME="fm1-mac1"
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="ffe4e2000",
NAME="fm1-mac2"
> > +static int dpaa_set_mac_address(s
[PATCH] ARM: cache-uniphier: include instead of
Nothing in this header file depends on . Rather, should be included for -ENODEV. Signed-off-by: Masahiro Yamada --- KernelVersion: 4.9-rc1 arch/arm/include/asm/hardware/cache-uniphier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h b/arch/arm/include/asm/hardware/cache-uniphier.h index eaa60da..0ef42ae 100644 --- a/arch/arm/include/asm/hardware/cache-uniphier.h +++ b/arch/arm/include/asm/hardware/cache-uniphier.h @@ -16,7 +16,7 @@ #ifndef __CACHE_UNIPHIER_H #define __CACHE_UNIPHIER_H -#include +#include #ifdef CONFIG_CACHE_UNIPHIER int uniphier_cache_init(void); -- 1.9.1
Re: [BUG][REGRESSION] mangled display since -rc1
Hello. Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger: > Am 2016-11-07 um 09:24 schrieb Jani Nikula: > > On Sun, 06 Nov 2016, Martin Kepplinger wrote: > >> I did not file a bug in bugzilla yet. I haven't given up that we can fix > >> this here before the release. I've ignored it the last few days though. > > > > You say it like filing the bug report and having the bug fixed are > > mutually exclusive things... > > > > Pretty please? It's easier for us to direct folks at the bug, with > > history and logs in one place. I realize only Daniel and me were Cc'd > > here, not intel-gfx list. > > > > Also, please double check your bisect. Not sure why the finger points at > > i915 when the bisect points at iommu merge. […] > Chris Clayton wrote off list and the mentioned patch fixes the problem > for me too, as it does for others. I hope it make it's way into the tree > soon: With 4.9-rc4 I have corruptions that look like the ones reported in this thread. I reported my finding on LKML thread about 3.9-rc4. And in Bugzilla in a bug report with an attachment that shows the same type of corruptions as here in this thread: https://patchwork.freedesktop.org/patch/116808/ mentioned in the other bug report and the following LKML thread does not fix the issue for me: Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4) https://lkml.org/lkml/2016/11/6/70 https://bugzilla.kernel.org/show_bug.cgi?id=177701#c4 In my case it looks like this: https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png I have a busy week, so I won´t to any bisecting at the moment. I am happy to test another patch during breaks between holding the training, but please point me specifically to what patch to test. Thank you. In general I am a bit confused about: 1) when do I use the bugtracker 2) when to just post on LKML 3) and which bugtracker to use? bugzilla.kernel.org versus the freedesktop one in this case. See: http://lkml.iu.edu/hypermail/linux/kernel/1611.0/03126.html 4) how to determine whether a bug report matches my case or not. In that case its easy enough considering the screenshots. (using this list archive as threading view in lkml.org seems broken) This bug is already being discussed in three places right now, I bet it makes sense to settle on one place. I´d opt for Bugzilla but I would like to use my MUA to access it for simple comments. Thanks, Martin > Weitergeleitete Nachricht > Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc > Datum: Mon, 7 Nov 2016 13:48:14 + > Von: Chris Clayton > An: mart...@posteo.de > > Hi Martin. > > > I can't contact you through LKML because I'm not subscribed, but I've > been working with Chris Wilson, one of the Intel > DRM developers to analyse and fix the corruption. We've got a patch that > fixes it for me and Norbert who also reported > the problem. The patch is at the bottom of this message. > > Hope it helps. > > Chris > > > Forwarded Message > Subject: Re: Redraw issues on i915 on 4.9-rc > Date: Mon, 7 Nov 2016 09:25:59 + > From: Chris Wilson > To: Chris Clayton > CC: Norbert Preining > > On Mon, Nov 07, 2016 at 09:16:38AM +, Chris Clayton wrote: > > Hello again. > > > > I wasn't at all happy about the last bisect I did, so I've run it > > again and this time spent at least 30 minutes using my > > > system before marking a kernel as good. I've also noticed that when I > > boot a bad kernel, the graphics associated with > > > three of my desktop icons do not get drawn, so that helps. > > > > The outcome of the bisection is: > > > > a61007a83a4671da77210790997d5c8c92ed87ea is the first bad commit > > commit a61007a83a4671da77210790997d5c8c92ed87ea > > Author: Chris Wilson > > Date: Thu Aug 18 17:17:02 2016 +0100 > > > > drm/i915: Fix partial GGTT faulting > > That's just the enabling patch, everything was meant to be in place by > then. > > Oh noes, care to try: > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > b/drivers/gpu/drm/i915/i915_gem.c > index c642385bb236..a52b40bbac6f 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1837,7 +1837,7 @@ int i915_gem_fault(struct vm_area_struct *area, > struct vm_fault *vmf) > /* Use a partial view if it is bigger than available > space */ > chunk_size = MIN_CHUNK_PAGES; > if (i915_gem_object_is_tiled(obj)) > - chunk_size = max(chunk_size, tile_row_pages(obj)); > + chunk_size = roundup(chunk_size, > tile_row_pages(obj)); > memset(&view, 0, sizeof(view)); > view.type = I915_GGTT_VIEW_PARTIAL; -- Martin
Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0
On Mon, 7 Nov 2016, Jon Hunter wrote:
> On 07/11/16 14:59, Mika Westerberg wrote:
> > On Mon, Nov 07, 2016 at 02:40:47PM +, Marc Zyngier wrote:
> >> Sorry, missed this discussion entirely, as I was on the other side of
> >> the world. Not having a irq_set_type definitely seems odd (and
> >> configuring the trigger outside of the IRQ framework is quite ugly).
> >>
> >> Mika, can you please try the following (which is fully untested)?
> >>
> >> diff --git a/arch/x86/kernel/apic/io_apic.c
> >> b/arch/x86/kernel/apic/io_apic.c
> >> index 48e6d84..822a6b8 100644
> >> --- a/arch/x86/kernel/apic/io_apic.c
> >> +++ b/arch/x86/kernel/apic/io_apic.c
> >> @@ -1868,6 +1868,15 @@ static int ioapic_set_affinity(struct irq_data
> >> *irq_data,
> >>return ret;
> >> }
> >>
> >> +static int ioapic_set_type(struct irq_data *data, unsigned int flow_type)
> >> +{
> >> + /*
> >> + * The IOAPIC has already been programmed behind our back,
> >> + * just pretend it all went OK, and too bad if it didn't.
> >> + */
> >> + return 0;
> >> +}
> >> +
> >> static struct irq_chip ioapic_chip __read_mostly = {
> >>.name = "IO-APIC",
> >>.irq_startup= startup_ioapic_irq,
> >> @@ -1876,6 +1885,7 @@ static struct irq_chip ioapic_chip __read_mostly = {
> >>.irq_ack= irq_chip_ack_parent,
> >>.irq_eoi= ioapic_ack_level,
> >>.irq_set_affinity = ioapic_set_affinity,
> >> + .irq_set_type = ioapic_set_type,
> >>.flags = IRQCHIP_SKIP_SET_WAKE,
> >> };
> >
> > Thanks! This fixes the problem for me.
>
> Good to know. The more I think about this, the more I wonder if we
> should have a dummy 'set_type' as this is just hiding the issue. If the
> original warning does not impact the overall behaviour (ie. interrupts
> still working) then may be it is legitimate as far as gen-irq is concerned?
No. We don't want a dummy set_type to paper over the issue. As Mika
correctly figured out that the ioapic is already configured, but it does
not propagate it to the irq descriptor. That wants to be fixed. I'll have a
look.
Thanks,
tglx
Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read()
On Mon, Nov 07, 2016 at 07:01:03AM -0800, Christoph Hellwig wrote: > On Mon, Nov 07, 2016 at 02:13:05PM +0300, Kirill A. Shutemov wrote: > > It looks like a huge limitation to me. > > The DAX PMD fault code can live just fine with it. There's no way out for DAX as we map backing storage directly into userspace. There's no such limitation for page-cache. And I don't see a point to introduce such limitation artificially. Backing storage fragmentation can be a weight on decision whether we want to allocate huge page, but it shouldn't be show-stopper. > And without it performance would suck anyway. It depends on workload, obviously. -- Kirill A. Shutemov
Re: [PATCH/RFC] z3fold: use per-page read/write lock
> I understand the reinvention part but you're not quite accurate here > with the numbers. > > E. g. on x86_64: > (gdb) p sizeof(rwlock_t) > $1 = 8 I was talking about spinlocks which are 4 bytes. Just use a spinlock then. rwlocks are usually a bad idea anyways because they often scale far worse than spinlocks due to the bad cache line bouncing behavior, and it doesn't make much difference unless your critical section is very long. -Andi
Re: [BUG][REGRESSION] mangled display since -rc1
Am 2016-11-07 um 17:01 schrieb Martin Steigerwald: > Hello. > > Am Montag, 7. November 2016, 16:34:35 CET schrieb Martin Kepplinger: >> Am 2016-11-07 um 09:24 schrieb Jani Nikula: >>> On Sun, 06 Nov 2016, Martin Kepplinger wrote: I did not file a bug in bugzilla yet. I haven't given up that we can fix this here before the release. I've ignored it the last few days though. >>> >>> You say it like filing the bug report and having the bug fixed are >>> mutually exclusive things... >>> >>> Pretty please? It's easier for us to direct folks at the bug, with >>> history and logs in one place. I realize only Daniel and me were Cc'd >>> here, not intel-gfx list. >>> >>> Also, please double check your bisect. Not sure why the finger points at >>> i915 when the bisect points at iommu merge. > […] >> Chris Clayton wrote off list and the mentioned patch fixes the problem >> for me too, as it does for others. I hope it make it's way into the tree >> soon: > > With 4.9-rc4 I have corruptions that look like the ones reported in this > thread. > > I reported my finding on LKML thread about 3.9-rc4. And in Bugzilla in a bug > report with an attachment that shows the same type of corruptions as here in > this thread: > > https://patchwork.freedesktop.org/patch/116808/ > > mentioned in the other bug report and the following LKML thread does not fix > the issue for me: > > Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: > Linux 4.9-rc4) > https://lkml.org/lkml/2016/11/6/70 > > https://bugzilla.kernel.org/show_bug.cgi?id=177701#c4 > > > In my case it looks like this: > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png > > > I have a busy week, so I won´t to any bisecting at the moment. I am happy to > test another patch during breaks between holding the training, but please > point me specifically to what patch to test. Thank you. this one: I just replaced max with roundup manually: diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index c642385bb236..a52b40bbac6f 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1837,7 +1837,7 @@ int i915_gem_fault(struct vm_area_struct *area, struct vm_fault *vmf) /* Use a partial view if it is bigger than available space */ chunk_size = MIN_CHUNK_PAGES; if (i915_gem_object_is_tiled(obj)) - chunk_size = max(chunk_size, tile_row_pages(obj)); + chunk_size = roundup(chunk_size, tile_row_pages(obj)); memset(&view, 0, sizeof(view)); view.type = I915_GGTT_VIEW_PARTIAL; > > > In general I am a bit confused about: > > 1) when do I use the bugtracker > > 2) when to just post on LKML > > 3) and which bugtracker to use? bugzilla.kernel.org versus the freedesktop > one > in this case. See: > > http://lkml.iu.edu/hypermail/linux/kernel/1611.0/03126.html > > 4) how to determine whether a bug report matches my case or not. In that case > its easy enough considering the screenshots. > > (using this list archive as threading view in lkml.org seems broken) > > This bug is already being discussed in three places right now, I bet it makes > sense to settle on one place. I´d opt for Bugzilla but I would like to use my > MUA to access it for simple comments. whatever, it's a mess :) that's what the kernel summit is for, right? > > Thanks, > Martin > >> Weitergeleitete Nachricht >> Betreff: Fwd: Re: Redraw issues on i915 on 4.9-rc >> Datum: Mon, 7 Nov 2016 13:48:14 + >> Von: Chris Clayton >> An: mart...@posteo.de >> >> Hi Martin. >> >> >> I can't contact you through LKML because I'm not subscribed, but I've >> been working with Chris Wilson, one of the Intel >> DRM developers to analyse and fix the corruption. We've got a patch that >> fixes it for me and Norbert who also reported >> the problem. The patch is at the bottom of this message. >> >> Hope it helps. >> >> Chris >> >> >> Forwarded Message >> Subject: Re: Redraw issues on i915 on 4.9-rc >> Date: Mon, 7 Nov 2016 09:25:59 + >> From: Chris Wilson >> To: Chris Clayton >> CC: Norbert Preining >> >> On Mon, Nov 07, 2016 at 09:16:38AM +, Chris Clayton wrote: >>> Hello again. >>> >>> I wasn't at all happy about the last bisect I did, so I've run it >> >> again and this time spent at least 30 minutes using my >> >>> system before marking a kernel as good. I've also noticed that when I >> >> boot a bad kernel, the graphics associated with >> >>> three of my desktop icons do not get drawn, so that helps. >>> >>> The outcome of the bisection is: >>> >>> a61007a83a4671da77210790997d5c8c92ed87ea is the first bad commit >>> commit a61007a83a4671da77210790997d5c8c92ed87ea >>> Author: Chris Wilson >>> Date: Thu Aug 18 17:17:02 2016 +0100 >>> >>> drm/i915: Fix partial GGTT faulting >> >> That's just the enabling patch, every
[RFC] proc: don't show kernel-internal mnt_id in fdinfo (if possible)
Some kernel special fs could be mounted by userspace, let's show
userspace mnt_id in those cases.
Otherwise, I got:
[~]# cat /proc/11299/fdinfo/3
pos: 0
flags:0202
mnt_id: 14
[~]# cat /proc/11299/mountinfo | grep '^14'
[~]# ls -l /proc/11299/fd/3
lrwx--. 1 root root 64 Nov 7 18:30 /proc/11299/fd/3 -> /test-queue
[~]# ls /dev/mqueue/
test-queue
[~]# cat /proc/11299/mountinfo | grep mqueue
32 18 0:14 / /dev/mqueue rw,relatime shared:17 - mqueue mqueue rw,seclabel
This happens because mqueue fs is mounted twice:
- the first is kernel-internal mnt on init:
kernel_init=>do_one_initcall=>init_mqueue_fs=>mq_init_ns=>vfs_kern_mount
- the second time it's systemd's mount-unit:
entry_SYSCALL_64_fastpath=>SyS_mount=>do_mount=>vfs_kern_mount
For the purpose of userspace parsing, having in-kernel mnt_id is less
useful then mnt_id of mount point: afterwards I'm able to see fs type,
path, etc:
[~]# cat /proc/11152/mountinfo | grep mqueue
32 18 0:14 / /dev/mqueue rw,relatime shared:18 - mqueue mqueue rw,seclabel
[~]# cat /proc/11152/fdinfo/3
pos: 0
flags:0202
mnt_id: 32
On a bad side - if we've no userspace mount, we still can't tell a thing
about opened fd..
Cc: Al Viro
Cc: Andrey Vagin
Cc: "Eric W. Biederman"
Cc: Rob Landley
Signed-off-by: Dmitry Safonov
---
fs/proc/fd.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index d21dafef3102..bfa8699bcd8e 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
@@ -19,9 +20,10 @@
static int seq_show(struct seq_file *m, void *v)
{
struct files_struct *files = NULL;
- int f_flags = 0, ret = -ENOENT;
+ int f_flags = 0, ret = -ENOENT, mnt_id = 0;
struct file *file = NULL;
struct task_struct *task;
+ struct mount *mount;
task = get_proc_task(m->private);
if (!task)
@@ -52,9 +54,25 @@ static int seq_show(struct seq_file *m, void *v)
if (ret)
return ret;
+ mount = real_mount(file->f_path.mnt);
+ if (mount->mnt_ns == MNT_NS_INTERNAL) {
+ struct mount *mnt;
+
+ lock_mount_hash();
+ list_for_each_entry(mnt, &mount->mnt_instance, mnt_instance) {
+ if (current->nsproxy->mnt_ns == mnt->mnt_ns) {
+ mnt_id = mnt->mnt_id;
+ break;
+ }
+ }
+ unlock_mount_hash();
+ }
+
+ if (mnt_id == 0)
+ mnt_id = mount->mnt_id;
+
seq_printf(m, "pos:\t%lli\nflags:\t0%o\nmnt_id:\t%i\n",
- (long long)file->f_pos, f_flags,
- real_mount(file->f_path.mnt)->mnt_id);
+ (long long)file->f_pos, f_flags, mnt_id);
show_fd_locks(m, file, files);
if (seq_has_overflowed(m))
--
2.10.2
Re: [PATCH] net/netfiliter: Fix used uninitialized warn in ip_vs_proc_sync_conn()
On 11/07/2016 08:44 AM, Anna Schumaker wrote:
> Hi Shuah,
>
> On 11/07/2016 10:41 AM, Shuah Khan wrote:
>> Fix the following warn:
>>
>> net/netfilter/ipvs/ip_vs_sync.c: In function ‘ip_vs_proc_sync_conn’:
>> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.init_seq’ may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
>>struct ip_vs_sync_conn_options opt;
>> ^~~
>> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.delta’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.previous_delta’ may
>> be used uninitialized in this function [-Wmaybe-uninitialized]
>> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
>> *)&opt+12).init_seq’ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
>> *)&opt+12).delta’ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void
>> *)&opt+12).previous_delta’ may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>
> Are you sure you put the right commit message on this patch? The message
> describes a warning in ip_vs_sync.c, but the patch is for nfs4session.c.
>
> Thanks,
> Anna
Oops. Sorry about this. Bad cut and paste from make output.
I will resend the patch with the correct changelog
thanks,
-- Shuah
>
>>
>> Signed-off-by: Shuah Khan
>> ---
>> fs/nfs/nfs4session.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/nfs/nfs4session.c b/fs/nfs/nfs4session.c
>> index b629730..68e700e 100644
>> --- a/fs/nfs/nfs4session.c
>> +++ b/fs/nfs/nfs4session.c
>> @@ -196,7 +196,7 @@ static int nfs4_slot_get_seqid(struct nfs4_slot_table
>> *tbl, u32 slotid,
>> static bool nfs4_slot_seqid_in_use(struct nfs4_slot_table *tbl,
>> u32 slotid, u32 seq_nr)
>> {
>> -u32 cur_seq;
>> +u32 cur_seq = 0;
>> bool ret = false;
>>
>> spin_lock(&tbl->slot_tbl_lock);
>>
>
Re: [PATCH] ARM: cache-uniphier: include instead of
On Tue, Nov 08, 2016 at 12:58:54AM +0900, Masahiro Yamada wrote: > Nothing in this header file depends on . > Rather, should be included for -ENODEV. So how do we end up with a definition for u32? I think you need both these include files. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH v5 6/6] i2c: use an IRQ to report Host Notify events, not alert
On Nov 07 2016 or thereabouts, Wolfram Sang wrote: > On Thu, Oct 13, 2016 at 02:10:40PM +0200, Benjamin Tissoires wrote: > > The current SMBus Host Notify implementation relies on .alert() to > > relay its notifications. However, the use cases where SMBus Host > > Notify is needed currently is to signal data ready on touchpads. > > > > This is closer to an IRQ than a custom API through .alert(). > > Given that the 2 touchpad manufacturers (Synaptics and Elan) that > > use SMBus Host Notify don't put any data in the SMBus payload, the > > concept actually matches one to one. > > I see the advantages. The only question I have: What if we encounter > devices in the future which do put data in the payload? Can this > mechanism be extended to handle that? I had this very same problem when dealing with hid-rmi. In that case, we have an interrupt that contains data. I somewhat solved this by the following commit transposed in the hid-rmi world: https://github.com/bentiss/linux/commit/d24d938e1eabba026c3c5e4daeee3a16403295de The idea is the following: - we extend the internal call of i2c_handle_smbus_host_notify() by re-adding a data payload. - this call takes a spinlock, and copy the data into an internal placeholder, releases the spinlock and then triggers the irq - when the client gets an interrupt, it calls i2c_retrieve_host_notify_data() which is protected by the spinlock and returns the *current* data The only difficulty for the client now is that it might access newer data than the origin interrupt. This can be solved by 2 solutions. Either we use a kfifo in i2c_core, to the risk of having some complex processing. Either we just let the client dealing with that by implementing itself the kfifo. The data just needs to be retrieved in the non threaded part of the interrupt handler, and stored by the client itself. So all in all, I think adding the data will be just adding a spinlock, a placeholder and a new internal API to retrieve it. I am not sure we have other means of extending the IRQ processing, but I am open to suggestions. Cheers, Benjamin > > > > > Benefits are multiple: > > - simpler code and API: the client will just have an IRQ, and > > nothing needs to be added in the adapter beside internally > > enabling it. > > - no more specific workqueue, the threading is handled by IRQ core > > directly (when required) > > - no more races when removing the device (the drivers are already > > required to disable irq on remove) > > - simpler handling for drivers: use plain regular IRQs > > - no more dependency on i2c-smbus for i2c-i801 (and any other adapter) > > - the IRQ domain is created automatically when the adapter exports > > the Host Notify capability > > - the IRQ are assign only if ACPI, OF and the caller did not assign > > one already > > - the domain is automatically destroyed on remove > > - fewer lines of code (minus 20, yeah!) > > > > Signed-off-by: Benjamin Tissoires > > Thanks for keeping at it! >
Re: [PATCH V2] btrfs: Remove some dead code
On Fri, Nov 04, 2016 at 08:02:35AM +0100, Christophe JAILLET wrote: > 'btrfs_iget()' can not return NULL, so this test can be removed. > > Signed-off-by: Christophe JAILLET Patch replaced, I've edited the subject to be a bit more specific.
[PATCH 2/3] arm64: dts: hisi: disable sas0 and sas2 for d03
The SAS nodes sas0 and sas2 are not available on d03, so
disable them.
Signed-off-by: John Garry
Acked-by: Xu Wei
---
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index f54b283..7c4114a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -41,18 +41,10 @@
status = "ok";
};
-&sas0 {
- status = "ok";
-};
-
&sas1 {
status = "ok";
};
-&sas2 {
- status = "ok";
-};
-
&usb_ohci {
status = "ok";
};
--
1.9.1
[PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes
This patchset resolves some hip06 SAS device tree issues. John Garry (3): arm64: dts: hisi: fix hip06 sas am-max-trans quirk arm64: dts: hisi: disable sas0 and sas2 for d03 arm64: dts: hisi: add refclk node to hip06 dts files for SAS arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 arch/arm64/boot/dts/hisilicon/hip06.dtsi| 11 ++- 2 files changed, 10 insertions(+), 9 deletions(-) -- 1.9.1
[PATCH 1/3] arm64: dts: hisi: fix hip06 sas am-max-trans quirk
The string for the am max transmissions quirk property is not correct -> fix it. Signed-off-by: John Garry Reviewed-by: Xiang Chen --- arch/arm64/boot/dts/hisilicon/hip06.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi index b548763..5330abb 100644 --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi @@ -590,7 +590,7 @@ reg = <0 0xa200 0 0x1>; sas-addr = [50 01 88 20 16 00 00 00]; hisilicon,sas-syscon = <&pcie_subctl>; - am-max-trans; + hip06-sas-v2-quirk-amt; ctrl-reset-reg = <0xa18>; ctrl-reset-sts-reg = <0x5a0c>; ctrl-clock-ena-reg = <0x318>; -- 1.9.1
[PATCH 3/3] arm64: dts: hisi: add refclk node to hip06 dts files for SAS
We will only maintain 1 dts for D03 and there are 50MHz
and 66MHz versions of D03: so we expect UEFI to update
refclk rate in the fdt at boot time.
Signed-off-by: John Garry
Reviewed-by: Xiang Chen
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5330abb..7b40dce 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,12 @@
#size-cells = <2>;
ranges;
+ refclk: refclk {
+ compatible = "fixed-clock";
+ clock-frequency = <5000>;
+ #clock-cells = <0>;
+ };
+
usb_ohci: ohci@a703 {
compatible = "generic-ohci";
reg = <0x0 0xa703 0x0 0x1>;
@@ -552,6 +558,7 @@
ctrl-reset-reg = <0xa60>;
ctrl-reset-sts-reg = <0x5a30>;
ctrl-clock-ena-reg = <0x338>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -594,6 +601,7 @@
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -635,6 +643,7 @@
ctrl-reset-reg = <0xae0>;
ctrl-reset-sts-reg = <0x5a70>;
ctrl-clock-ena-reg = <0x3a8>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <9>;
dma-coherent;
--
1.9.1
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
> On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
> > I am not sure if this a race with the new hotplug code or something that was
> > always there. Both (M. Vefa Bicakc and Charles) say that the box boots
> > sometimes fine (without the patch). smp_store_boot_cpu_info() should have
> > run
> > before the notofoert and thus should have set the info properly. However I
> > got
> > the following bootlog from Charles with this patch:
>
> I don't this this is a race. Here is some debugging from the two CPU VM
> (2 sockets, 1 core per socket). In identify_cpu() we have:
>
> /* The boot/hotplug time assigment got cleared, restore it */
> c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id);
>
> The values just after this:
>
> [0.228306] identify_cpu: c 88023fd0a040 logical_proc_id 65535
> c->phys_proc_id 2
>
> So what's interesting here, is the phys_proc_id of 2 for CPU1:
>
> int topology_phys_to_logical_pkg(unsigned int phys_pkg)
> {
> if (phys_pkg >= max_physical_pkg_id)
> return -1;
> return physical_to_logical_pkg[phys_pkg];
> }
>
> And we happen to know the max_physical_pkg_id is 2 in this case.
> So apparently, topology_phys_to_logical_pkg() returns -1 and it gets
> assigned to the logical_proc_id.
>
> I don't know why the CPU's phys_proc_id is 2.
max_physical_pkg_id gets initialized via:
cpus = boot_cpu_data.x86_max_cores;
max_physical_pkg_id = DIV_ROUND_UP(MAX_LOCAL_APIC, ncpus);
What's the value of boot_cpu_data.x86_max_cores and MAX_LOCAL_APIC?
Thanks,
tglx
Re: [PATCH 00/12] xen: add common function for reading optional value
On Mon, Nov 07, 2016 at 11:08:09AM +, David Vrabel wrote: > On 31/10/16 16:48, Juergen Gross wrote: > > There are multiple instances of code reading an optional unsigned > > parameter from Xenstore via xenbus_scanf(). Instead of repeating the > > same code over and over add a service function doing the job and > > replace the call of xenbus_scanf() with the call of the new function > > where appropriate. > > Acked-by: David Vrabel > > Please queue for the next release. If you want this change to tpmdd, please resend it to tpmdd mailing list and CC it to linux-security-module. Thanks. > David /Jarkko
Re: [PATCHv4 0/4] WX checking for arm64
On 11/07/2016 07:38 AM, Mark Rutland wrote:
On Sun, Oct 30, 2016 at 03:03:07PM +, Catalin Marinas wrote:
On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote:
Laura Abbott (4):
arm64: dump: Make ptdump debugfs a separate option
arm64: dump: Make the page table dumping seq_file optional
arm64: dump: Remove max_addr
arm64: dump: Add checking for writable and exectuable pages
Queued for 4.10. Thanks.
Catalin mentioned to me that he saw some KASAN splats when testing; it
looks like need a fixup something like the below.
Apologies for not having spotted this when testing!
Thanks,
Mark.
>8
From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
From: Mark Rutland
Date: Mon, 7 Nov 2016 15:24:40 +
Subject: [PATCH] Fix KASAN splats with DEBUG_WX
Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX
results in a stream of KASAN splats for stack-out-of-bounds accesses,
e.g.
==
BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr 8009364ebdd0
Read of size 8 by task swapper/0/1
page:7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-4-g25f7267 #77
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[] dump_backtrace+0x0/0x278
[] show_stack+0x14/0x20
[] dump_stack+0xa4/0xc8
[] kasan_report_error+0x4a8/0x4d0
[] kasan_report+0x40/0x48
[] __asan_load8+0x84/0x98
[] note_page+0xd8/0x650
[] walk_pgd.isra.1+0x114/0x220
[] ptdump_check_wx+0xa8/0x118
[] mark_rodata_ro+0x90/0xd0
[] kernel_init+0x28/0x110
[] ret_from_fork+0x10/0x50
Memory state around the buggy address:
8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2
^
8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00
8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
... this happens because note_page assumes that the marker array has at
least two elements (the latter of which may be the terminator), but the
marker array for ptdump_check_wx only contains one element. Thus we
dereference some garbage on the stack when looking at
marker[1].start_address.
Given we don't need the markers for the WX checks, we could modify
note_page to allow for a NULL marker array, but for now it's simpler to
add an entry to the ptdump_check_wx marker array, so let's do that. As
it's somewhat confusing to have two identical entries, we add an initial
entry with a start address of zero.
Reported-by: Catalin Marinas
Signed-off-by: Mark Rutland
---
arch/arm64/mm/dump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index ef8aca8..ca74a2a 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -383,6 +383,7 @@ void ptdump_check_wx(void)
struct pg_state st = {
.seq = NULL,
.marker = (struct addr_marker[]) {
+ { 0, NULL},
{ -1, NULL},
},
.check_wx = true,
Acked-by: Laura Abbott
Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n
On Mon, 07 Nov 2016 19:34:42 +1100 Michael Ellerman wrote: > Paolo Bonzini writes: > > On 04/11/2016 06:48, Michael Ellerman wrote: > >> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > >> index da6e2ce77495..6b51a4ebed8a 100644 > >> --- a/drivers/vfio/Kconfig > >> +++ b/drivers/vfio/Kconfig > >> @@ -6,12 +6,12 @@ config VFIO_IOMMU_TYPE1 > >> config VFIO_IOMMU_SPAPR_TCE > >>tristate > >>depends on VFIO && SPAPR_TCE_IOMMU > >> - default n > >> + default VFIO > > > > No need to depend on VFIO since you already have it in "default". depends and defaults are different beasts though, if VFIO is not enabled and we're not on a powerpc system with SPAPR, VFIO_IOMMU_SPAPR_TCE should not be selectable, not just default to 'n'. > > True, I can take that out. > > > (I assume you cannot use "default y" because "depends on" doesn't downgrade > > "y" to "m" when VFIO is a module. > > Correct. > > > A shorthand is > > > > def_tristate VFIO && SPAPR_TCE_IOMMU > > Yep. My experience though is that a lot of folks don't really know what > that means. So I prefer to spell it out with an explicit type, depends > and default. > > But I'll respin it that way if Alex prefers the shorter style. Perhaps I'm one of those people. Non-powerpc archs should not have an option to select this, which is why the depends is there, AIUI. So long as we don't start exposing options that aren't relevant to a platform, I'm flexible on what shorthands we use, but you may need to teach me about them first. Thanks, Alex
Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n
On 07/11/2016 17:25, Alex Williamson wrote: > On Mon, 07 Nov 2016 19:34:42 +1100 > Michael Ellerman wrote: > >> Paolo Bonzini writes: >>> On 04/11/2016 06:48, Michael Ellerman wrote: diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index da6e2ce77495..6b51a4ebed8a 100644 --- a/drivers/vfio/Kconfig +++ b/drivers/vfio/Kconfig @@ -6,12 +6,12 @@ config VFIO_IOMMU_TYPE1 config VFIO_IOMMU_SPAPR_TCE tristate depends on VFIO && SPAPR_TCE_IOMMU - default n + default VFIO >>> >>> No need to depend on VFIO since you already have it in "default". > > depends and defaults are different beasts though, if VFIO is not > enabled and we're not on a powerpc system with SPAPR, > VFIO_IOMMU_SPAPR_TCE should not be selectable, not just default to 'n'. AFAIU without a prompt nothing is selectable anyway (hence my preference for a shorthand). Paolo >> >> True, I can take that out. >> >>> (I assume you cannot use "default y" because "depends on" doesn't downgrade >>> "y" to "m" when VFIO is a module. >> >> Correct. >> >>> A shorthand is >>> >>> def_tristate VFIO && SPAPR_TCE_IOMMU >> >> Yep. My experience though is that a lot of folks don't really know what >> that means. So I prefer to spell it out with an explicit type, depends >> and default. >> >> But I'll respin it that way if Alex prefers the shorter style. > > Perhaps I'm one of those people. Non-powerpc archs should not have an > option to select this, which is why the depends is there, AIUI. So > long as we don't start exposing options that aren't relevant to a > platform, I'm flexible on what shorthands we use, but you may need to > teach me about them first. Thanks, > > Alex >
Re: [PATCH 2/3] arm64/setup: Use ID_AA64ISAR0_EL1_.* macros
On 03/09/15 19:12, Alexander Kuleshov wrote:
The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
testing) provides set of macros for the testing processor's crypto features.
Let's use these macros instead of direct calculation.
Signed-off-by: Alexander Kuleshov
---
arch/arm64/kernel/setup.c | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 926ae8d..a3faf4f 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
This patch doesn't apply on the current mainline tree. Where does this patch
apply ?
The elf_hwcap calculation has been moved to a separate function
setup_elf_hwcaps()
in arch/arm64/kernel/cpufeature.c, which makes uses of a table of
arm64_cpu_capabilities.
Suzuki
@@ -250,33 +250,22 @@ static void __init setup_processor(void)
/*
* ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
-* The blocks we test below represent incremental functionality
-* for non-negative values. Negative values are reserved.
*/
features = read_cpuid(ID_AA64ISAR0_EL1);
- block = (features >> 4) & 0xf;
- if (!(block & 0x8)) {
- switch (block) {
- default:
- case 2:
- elf_hwcap |= HWCAP_PMULL;
- case 1:
- elf_hwcap |= HWCAP_AES;
- case 0:
- break;
- }
- }
- block = (features >> 8) & 0xf;
- if (block && !(block & 0x8))
+ if (ID_AA64ISAR0_EL1_AES(features))
+ elf_hwcap |= HWCAP_AES;
+
+ if (ID_AA64ISAR0_EL1_PMULL(features))
+ elf_hwcap |= HWCAP_PMULL;
+
+ if (ID_AA64ISAR0_EL1_SHA1(features))
elf_hwcap |= HWCAP_SHA1;
- block = (features >> 12) & 0xf;
- if (block && !(block & 0x8))
+ if (ID_AA64ISAR0_EL1_SHA2(features))
elf_hwcap |= HWCAP_SHA2;
- block = (features >> 16) & 0xf;
- if (block && !(block & 0x8))
+ if (ID_AA64ISAR0_EL1_CRC32(features))
elf_hwcap |= HWCAP_CRC32;
[PATCH] target: fix spelling mistake and unwrap multi-line text
From: Colin Ian King
Trivial fix to spelling mistake "Obselete" to "Obsolete"
in error message and also turn multi-line text into one
line.
Signed-off-by: Colin Ian King
---
drivers/target/target_core_pr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
index 47463c9..0cd38af 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -253,8 +253,7 @@ target_scsi2_reservation_reserve(struct se_cmd *cmd)
if ((cmd->t_task_cdb[1] & 0x01) &&
(cmd->t_task_cdb[1] & 0x02)) {
- pr_err("LongIO and Obselete Bits set, returning"
- " ILLEGAL_REQUEST\n");
+ pr_err("LongIO and Obsolete Bits set, returning
ILLEGAL_REQUEST\n");
return TCM_UNSUPPORTED_SCSI_OPCODE;
}
/*
--
2.9.3
Re: [PATCH 3/3] arm64/fpsimd: Use ID_AA64PFR0_EL1_.* macros
On 03/09/15 19:12, Alexander Kuleshov wrote:
The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
testing) provides set of macros for the testing processor's FP and advanced
SIMD features.
Let's use these macros instead of direct calculation.
Signed-off-by: Alexander Kuleshov
---
arch/arm64/kernel/fpsimd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 44d6f75..12943a5 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#define FPEXC_IOF (1 << 0)
#define FPEXC_DZF (1 << 1)
@@ -333,13 +334,13 @@ static int __init fpsimd_init(void)
{
u64 pfr = read_cpuid(ID_AA64PFR0_EL1);
- if (pfr & (0xf << 16)) {
+ if (ID_AA64PFR0_EL1_FP(pfr)) {
pr_notice("Floating-point is not implemented\n");
return 0;
}
elf_hwcap |= HWCAP_FP;
- if (pfr & (0xf << 20))
+ if (ID_AA64PFR0_EL1_ADV_SIMD(pfr))
pr_notice("Advanced SIMD is not implemented\n");
else
elf_hwcap |= HWCAP_ASIMD;
Similar to the previous one, this won't apply anymore.
Suzuki
Re: [PATCHv4 0/4] WX checking for arm64
On Mon, Nov 07, 2016 at 08:26:34AM -0800, Laura Abbott wrote: > On 11/07/2016 07:38 AM, Mark Rutland wrote: > >From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001 > >From: Mark Rutland > >Date: Mon, 7 Nov 2016 15:24:40 + > >Subject: [PATCH] Fix KASAN splats with DEBUG_WX [...] > Acked-by: Laura Abbott Thanks. I'll queue the patch on top of the others. -- Catalin
[PATCH] bad_inode: add missing i_op initializers
New inode operations were forgotten to be added to bad_inode. Most of the
time the op is checked for NULL before being called but marking the inode
bad and the check can race (very unlikely).
However in case of ->get_link() only DCACHE_SYMLINK_TYPE is checked before
calling the op, so there's no race and will definitely oops when trying to
follow links on such a beast.
Also remove comments about extinct ops.
Signed-off-by: Miklos Szeredi
Cc:
---
fs/bad_inode.c | 55 +++
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/fs/bad_inode.c b/fs/bad_inode.c
index 8712062275b8..5f685c819298 100644
--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -106,6 +106,50 @@ static ssize_t bad_inode_listxattr(struct dentry *dentry,
char *buffer,
return -EIO;
}
+static const char *bad_inode_get_link(struct dentry *dentry,
+ struct inode *inode,
+ struct delayed_call *done)
+{
+ return ERR_PTR(-EIO);
+}
+
+static struct posix_acl *bad_inode_get_acl(struct inode *inode, int type)
+{
+ return ERR_PTR(-EIO);
+}
+
+static int bad_inode_fiemap(struct inode *inode,
+ struct fiemap_extent_info *fieinfo, u64 start,
+ u64 len)
+{
+ return -EIO;
+}
+
+static int bad_inode_update_time(struct inode *inode, struct timespec *time,
+int flags)
+{
+ return -EIO;
+}
+
+static int bad_inode_atomic_open(struct inode *inode, struct dentry *dentry,
+struct file *file, unsigned int open_flag,
+umode_t create_mode, int *opened)
+{
+ return -EIO;
+}
+
+static int bad_inode_tmpfile(struct inode *inode, struct dentry *dentry,
+umode_t mode)
+{
+ return -EIO;
+}
+
+static int bad_inode_set_acl(struct inode *inode, struct posix_acl *acl,
+int type)
+{
+ return -EIO;
+}
+
static const struct inode_operations bad_inode_ops =
{
.create = bad_inode_create,
@@ -118,14 +162,17 @@ static const struct inode_operations bad_inode_ops =
.mknod = bad_inode_mknod,
.rename = bad_inode_rename2,
.readlink = bad_inode_readlink,
- /* follow_link must be no-op, otherwise unmounting this inode
- won't work */
- /* put_link returns void */
- /* truncate returns void */
.permission = bad_inode_permission,
.getattr= bad_inode_getattr,
.setattr= bad_inode_setattr,
.listxattr = bad_inode_listxattr,
+ .get_link = bad_inode_get_link,
+ .get_acl= bad_inode_get_acl,
+ .fiemap = bad_inode_fiemap,
+ .update_time= bad_inode_update_time,
+ .atomic_open= bad_inode_atomic_open,
+ .tmpfile= bad_inode_tmpfile,
+ .set_acl= bad_inode_set_acl,
};
--
2.5.5
Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
On Wed, 2016-11-02 at 22:17 +0200, Madalin Bucur wrote: > This introduces the Freescale Data Path Acceleration Architecture > (DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan, > BMan, PAMU and FMan drivers to deliver Ethernet connectivity on > the Freescale DPAA QorIQ platforms. Nice to see DPAA support soon entering the kernel(not a day too early:) I would like to see BQL supported from day one though, if possible. Regards Joakim Tjernlund
Re: [PATCH v2] staging: vc04_services: setup DMA and coherent mask
Michael Zoran writes: > VCHI messages between the CPU and firmware use 32-bit > bus addresses. Explicitly set the DMA mask and coherent > on all platforms. Reviewed-by: Eric Anholt signature.asc Description: PGP signature
[PATCH] scsi: fix spelling mistake in error message
From: Colin Ian King
Trivial fix to spelling mistake "operatio" to "operation"
in critical error message
Signed-off-by: Colin Ian King
---
drivers/scsi/dpt_i2o.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 21c8d21..d84004b 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3350,7 +3350,7 @@ static int adpt_i2o_query_scalar(adpt_hba* pHba, int tid,
if (opblk_va == NULL) {
dma_free_coherent(&pHba->pDev->dev, sizeof(u8) * (8+buflen),
resblk_va, resblk_pa);
- printk(KERN_CRIT "%s: query operatio failed; Out of memory.\n",
+ printk(KERN_CRIT "%s: query operation failed; Out of memory.\n",
pHba->name);
return -ENOMEM;
}
--
2.9.3
Re: [PATCH v2] staging: vc04_services: add vchiq_pagelist_info structure
Michael Zoran writes: > The current dma_map_sg based implementation for bulk messages > computes many offsets into a single allocation multiple times in > both the create and free code paths. This is inefficient, > error prone and in fact still has a few lingering issues > with arm64. > > This change replaces a small portion of that inplementation with > new code that uses a new struct vchiq_pagelist_info to store the > needed information rather then complex offset calculations. > > This improved implementation should be more efficient and easier > to understand and maintain. > > Tests Run(Both Pass): > vchiq_test -p 1 > vchiq_test -f 10 Looks good, and it's a nice cleanup. Thanks! Reviewed-by: Eric Anholt I had one style note, which was that you're using an int and 0/1 for a boolean value, but we like to use proper bools and true/false instead. However, you're modifying code that was already using an int for related booleans, so that can be a separate cleanup. signature.asc Description: PGP signature
Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet
From: Madalin-Cristian Bucur Date: Mon, 7 Nov 2016 16:32:16 + >> -Original Message- >> From: David Miller [mailto:da...@davemloft.net] >> Sent: Monday, November 07, 2016 5:55 PM >> >> From: Madalin-Cristian Bucur >> Date: Mon, 7 Nov 2016 15:43:26 + >> >> >> From: David Miller [mailto:da...@davemloft.net] >> >> Sent: Thursday, November 03, 2016 9:58 PM >> >> >> >> Why? By clearing this, you disallow an important fundamental way to do >> >> performane testing, via pktgen. >> > >> > The Tx path in DPAA requires one to insert a back-pointer to the skb >> into >> > the Tx buffer. On the Tx confirmation path the back-pointer in the >> buffer >> > is used to release the skb. If Tx buffer is shared we'd alter the back- >> pointer >> > and leak/double free skbs. See also >> >> Then have your software state store an array of SKB pointers, one for each >> TX ring entry, just like every other driver does. > > There is no Tx ring in DPAA. Frames are send out on QMan HW queues towards > the FMan for Tx and then received back on Tx confirmation queues for cleanup. > Array traversal would for sure cost more than using the back-pointer. Also, > we can now process confirmations on a different core than the one doing Tx, > we'd have to keep the arrays percpu and force the Tx conf on the same core. > Or add locks. Report back an integer index, like every scsi driver out there which completes tagged queued block I/O operations asynchronously. You can associate the array with a specific TX confirmation queue.
[PATCH v5 2/5] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available
From: Jeff Westfahl Use the MTD function 'max_bad_blocks' to compute the UBI bad_peb_limit, if the function is implemented for an MTD and doesn't return an error. Signed-off-by: Jeff Westfahl Signed-off-by: Zach Brown Acked-by: Boris Brezillon --- drivers/mtd/ubi/build.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 85d54f3..e9940a9 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -584,6 +584,10 @@ static int get_bad_peb_limit(const struct ubi_device *ubi, int max_beb_per1024) int limit, device_pebs; uint64_t device_size; + limit = mtd_max_bad_blocks(ubi->mtd, 0, ubi->mtd->size); + if (limit > 0) + return limit; + if (!max_beb_per1024) return 0; -- 2.7.4
[PATCH v5 1/5] mtd: introduce function max_bad_blocks
From: Jeff Westfahl
If implemented, 'max_bad_blocks' returns the maximum number of bad
blocks to reserve for an MTD. An implementation for NAND is coming soon.
Signed-off-by: Jeff Westfahl
Signed-off-by: Zach Brown
Acked-by: Boris Brezillon
---
drivers/mtd/mtdpart.c | 12
include/linux/mtd/mtd.h | 11 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index fccdd49..565f0dd 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -349,6 +349,16 @@ static const struct mtd_ooblayout_ops part_ooblayout_ops =
{
.free = part_ooblayout_free,
};
+static int part_max_bad_blocks(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+ struct mtd_part *part = mtd_to_part(mtd);
+
+ if ((len + ofs) > mtd->size)
+ return -EINVAL;
+ return part->master->_max_bad_blocks(part->master,
+ofs + part->offset, len);
+}
+
static inline void free_partition(struct mtd_part *p)
{
kfree(p->mtd.name);
@@ -481,6 +491,8 @@ static struct mtd_part *allocate_partition(struct mtd_info
*master,
if (master->_put_device)
slave->mtd._put_device = part_put_device;
+ if (master->_max_bad_blocks)
+ slave->mtd._max_bad_blocks = part_max_bad_blocks;
slave->mtd._erase = part_erase;
slave->master = master;
slave->offset = part->offset;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 13f8052..c02d3c2 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -322,6 +322,7 @@ struct mtd_info {
int (*_block_isreserved) (struct mtd_info *mtd, loff_t ofs);
int (*_block_isbad) (struct mtd_info *mtd, loff_t ofs);
int (*_block_markbad) (struct mtd_info *mtd, loff_t ofs);
+ int (*_max_bad_blocks) (struct mtd_info *mtd, loff_t ofs, size_t len);
int (*_suspend) (struct mtd_info *mtd);
void (*_resume) (struct mtd_info *mtd);
void (*_reboot) (struct mtd_info *mtd);
@@ -402,6 +403,16 @@ int mtd_wunit_to_pairing_info(struct mtd_info *mtd, int
wunit,
int mtd_pairing_info_to_wunit(struct mtd_info *mtd,
const struct mtd_pairing_info *info);
int mtd_pairing_groups(struct mtd_info *mtd);
+
+static inline int mtd_max_bad_blocks(struct mtd_info *mtd,
+loff_t ofs, size_t len)
+{
+ if (mtd->_max_bad_blocks)
+ return mtd->_max_bad_blocks(mtd, ofs, len);
+
+ return -ENOTSUPP;
+}
+
int mtd_erase(struct mtd_info *mtd, struct erase_info *instr);
int mtd_point(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen,
void **virt, resource_size_t *phys);
--
2.7.4
[PATCH v5 0/5] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit
For ONFI-compliant NAND devices, the ONFI parameters report the maximum number of bad blocks per LUN that will be encountered over the lifetime of the device, so we can use that information to get a more accurate (and smaller) value for the UBI bad PEB limit. The ONFI parameter "maxiumum number of bad blocks per LUN" is the max number of bad blocks that each individual LUN will ever ecounter. It is not the number of bad blocks to reserve for the nand device per LUN in the device. This means that in the worst case a UBI device spanning X LUNs will encounter "maximum number of bad blocks per LUN" * X bad blocks. The implementation in this patch assumes this worst case and allocates bad block accordingly. These patches are ordered in terms of their dependencies, but ideally, all 5 would need to be applied for this to work as intended. v2: * Changed commit message to address concerns from v1[1] about this patch set making best case assumptions. v3: * Provided helper function for _max_bad_blocks * Two new patches * First new patch adds bb_per_lun and blocks_per_lun to nand_chip struct * Second new patch sets the new fields during nand_flash_detect_onfi * Max bad blocks calculation now uses the new nand_chip fields v4: * Changed bb_per_lun and blocks_per_lun to bb_per_die and blocks_per_die * Corrected type of bb_per_die and blocks_per_die from little endian to host unsigned int v5: * Changed bb_per_die to max_bb_per_die * Fixed spacing style issue [1] http://lkml.iu.edu/hypermail/linux/kernel/1505.1/04822.html Jeff Westfahl (2): mtd: introduce function max_bad_blocks mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available Zach Brown (3): mtd: nand: Add max_bb_per_die and blocks_per_die fields to nand_chip mtd: nand: implement 'max_bad_blocks' mtd function mtd: nand: set max_bb_per_die and blocks_per_die for ONFI compliant chips drivers/mtd/mtdpart.c| 12 drivers/mtd/nand/nand_base.c | 38 ++ drivers/mtd/ubi/build.c | 4 include/linux/mtd/mtd.h | 11 +++ include/linux/mtd/nand.h | 5 + 5 files changed, 70 insertions(+) -- 2.7.4
[PATCH v5 3/5] mtd: nand: Add max_bb_per_die and blocks_per_die fields to nand_chip
The fields max_bb_per_die and blocks_per_die are useful determining the
number of bad blocks a MTD needs to allocate. How they are set will
depend on if the chip is ONFI, JEDEC or a full-id entry in the nand_ids
table.
Signed-off-by: Zach Brown
Acked-by: Boris Brezillon
---
include/linux/mtd/nand.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index d8905a2..8e9dce1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -771,6 +771,9 @@ nand_get_sdr_timings(const struct nand_data_interface *conf)
* supported, 0 otherwise.
* @jedec_params: [INTERN] holds the JEDEC parameter page when JEDEC is
* supported, 0 otherwise.
+ * @max_bb_per_die:[INTERN] the max number of bad blocks each die of a
+ * this nand device will encounter their life times.
+ * @blocks_per_die:[INTERN] The number of PEBs in a die
* @read_retries: [INTERN] the number of read retry modes supported
* @onfi_set_features: [REPLACEABLE] set the features for ONFI nand
* @onfi_get_features: [REPLACEABLE] get the features for ONFI nand
@@ -853,6 +856,8 @@ struct nand_chip {
struct nand_onfi_params onfi_params;
struct nand_jedec_params jedec_params;
};
+ u16 max_bb_per_die;
+ u32 blocks_per_die;
struct nand_data_interface *data_interface;
--
2.7.4
[PATCH v5 4/5] mtd: nand: implement 'max_bad_blocks' mtd function
Implement the new mtd function 'max_bad_blocks'. Using the chip's
max_bb_per_die and blocks_per_die fields to determine the maximum bad
blocks to reserve for an MTD.
Signed-off-by: Jeff Westfahl
Signed-off-by: Zach Brown
Acked-by: Boris Brezillon
---
drivers/mtd/nand/nand_base.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 3bde96a..193a6b7 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3236,6 +3236,40 @@ static int nand_block_markbad(struct mtd_info *mtd,
loff_t ofs)
}
/**
+ * nand_max_bad_blocks - [MTD Interface] Max number of bad blocks for an mtd
+ * @mtd: MTD device structure
+ * @ofs: offset relative to mtd start
+ * @len: length of mtd
+ */
+static int nand_max_bad_blocks(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ uint32_t part_start_block;
+ uint32_t part_end_block;
+ uint32_t part_start_lun;
+ uint32_t part_end_lun;
+
+ /* max_bb_per_lun and blocks_per_lun used to determine
+* the maximum bad block count.
+*/
+ if (!chip->max_bb_per_die || !chip->blocks_per_die)
+ return -ENOTSUPP;
+
+ /* Get the start and end of the partition in erase blocks. */
+ part_start_block = mtd_div_by_eb(ofs, mtd);
+ part_end_block = mtd_div_by_eb(len, mtd) + part_start_block - 1;
+
+ /* Get the start and end LUNs of the partition. */
+ part_start_lun = part_start_block / chip->blocks_per_die;
+ part_end_lun = part_end_block / chip->blocks_per_die;
+
+ /* Look up the bad blocks per unit and multiply by the number of units
+* that the partition spans.
+*/
+ return chip->max_bb_per_die * (part_end_lun - part_start_lun + 1);
+}
+
+/**
* nand_onfi_set_features- [REPLACEABLE] set features for ONFI nand
* @mtd: MTD device structure
* @chip: nand chip info structure
@@ -4767,6 +4801,7 @@ int nand_scan_tail(struct mtd_info *mtd)
mtd->_block_isreserved = nand_block_isreserved;
mtd->_block_isbad = nand_block_isbad;
mtd->_block_markbad = nand_block_markbad;
+ mtd->_max_bad_blocks = nand_max_bad_blocks;
mtd->writebufsize = mtd->writesize;
/*
--
2.7.4
[PATCH v5 5/5] mtd: nand: set max_bb_per_die and blocks_per_die for ONFI compliant chips
ONFI compliant chips contain the values for the max_bb_per_die and blocks_per_die fields in the parameter page. When the ONFI paged is retrieved/parsed the chip's fields are set by the corresponding fields in the param page. Signed-off-by: Zach Brown Acked-by: Boris Brezillon --- drivers/mtd/nand/nand_base.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 193a6b7..fb5b585 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3599,6 +3599,9 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip, chip->chipsize *= (uint64_t)mtd->erasesize * p->lun_count; chip->bits_per_cell = p->bits_per_cell; + chip->max_bb_per_die = le16_to_cpu(p->bb_per_lun); + chip->blocks_per_die = le32_to_cpu(p->blocks_per_lun); + if (onfi_feature(chip) & ONFI_FEATURE_16_BIT_BUS) *busw = NAND_BUSWIDTH_16; else -- 2.7.4
Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]
On Mon, Nov 07, 2016 at 02:07:43PM +0100, Thomas Gleixner wrote:
> On Mon, 7 Nov 2016, Ville Syrjälä wrote:
> > I didn't manage to find a lot of time to play around with this, but it
> > definitely looks like the SMM trap is the problem here. I repeated my
> > pm_trace experiemnts and when it gets stuck it is trying to execute the
> > _WAK ACPI method which is where the SMM trap happens.
> >
> > Maybe the SMM code was written with the expectation of a periodic tick
> > or something like that?
>
> Can you try the untested hack below, please? It should confirm that.
>
> Thanks,
>
> tglx
>
> 8<---
> --- a/drivers/acpi/acpica/hwsleep.c
> +++ b/drivers/acpi/acpica/hwsleep.c
> @@ -269,6 +269,17 @@ acpi_status acpi_hw_legacy_wake_prep(u8
> return_ACPI_STATUS(status);
> }
>
> +static const ktime_t time10ms = { .tv64 = 10 * NSEC_PER_MSEC };
> +
> +static enum hrtimer_restart acpi_hw_legacy_tmr(struct hrtimer *tmr)
> +{
> + hrtimer_forward_now(tmr, time10ms);
> +
> + return HRTIMER_RESTART;
> +}
> +
> +
> +
>
> /***
> *
> * FUNCTION:acpi_hw_legacy_wake
> @@ -284,6 +295,7 @@ acpi_status acpi_hw_legacy_wake_prep(u8
>
> acpi_status acpi_hw_legacy_wake(u8 sleep_state)
> {
> + struct hrtimer timer;
> acpi_status status;
>
> ACPI_FUNCTION_TRACE(hw_legacy_wake);
> @@ -311,12 +323,18 @@ acpi_status acpi_hw_legacy_wake(u8 sleep
> return_ACPI_STATUS(status);
> }
>
> + hrtimer_init_on_stack(&timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + timer.function = acpi_hw_legacy_tmr;
> + hrtimer_start(&timer, time10ms, HRTIMER_MODE_REL);
> +
> /*
>* Now we can execute _WAK, etc. Some machines require that the GPEs
>* are enabled before the wake methods are executed.
>*/
> acpi_hw_execute_sleep_method(METHOD_PATHNAME__WAK, sleep_state);
>
> + hrtimer_cancel(&timer);
> +
> /*
>* Some BIOS code assumes that WAK_STS will be cleared on resume
>* and use it to determine whether the system is rebooting or
Doesn't really seem to help. I did get a few random successes, but
mostly it just fails.
diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c
index 3c9c10bd49e9..950319b619f1 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -44,6 +44,8 @@
#include
#include
+#include
+#include
#include "accommon.h"
#define _COMPONENT ACPI_HARDWARE
@@ -275,6 +277,8 @@ static enum hrtimer_restart acpi_hw_legacy_tmr(struct
hrtimer *tmr)
{
hrtimer_forward_now(tmr, time10ms);
+ TRACE_RESUME(0);
+
return HRTIMER_RESTART;
}
@@ -327,14 +331,17 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state)
timer.function = acpi_hw_legacy_tmr;
hrtimer_start(&timer, time10ms, HRTIMER_MODE_REL);
+ TRACE_RESUME(0);
/*
* Now we can execute _WAK, etc. Some machines require that the GPEs
* are enabled before the wake methods are executed.
*/
acpi_hw_execute_sleep_method(METHOD_PATHNAME__WAK, sleep_state);
+ TRACE_RESUME(0);
hrtimer_cancel(&timer);
+ TRACE_RESUME(0);
/*
* Some BIOS code assumes that WAK_STS will be cleared on resume
* and use it to determine whether the system is rebooting or
Tossing that on top shows the trace before the _WAK being the last one
executed. Adding an msleep() before the _WAK does make the trace from
the timer handler show up so at least the timer seems to be ticking
up until some point.
--
Ville Syrjälä
Intel OTC
Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes
On Nov 07, 2016 12:57, Peter Rosin wrote: > On 2016-11-07 12:37, Daniel Baluta wrote: > > On Mon, Oct 24, 2016 at 1:39 AM, Peter Rosin wrote: > >> From: Jonathan Cameron > >> > >> A large number of attributes can only take a limited range of values. > >> Currently in IIO this is handled by directly registering additional > >> *_available attributes thus providing this information to userspace. > >> > >> It is desirable to provide this information via the core for much the same > >> reason this was done for the actual channel information attributes in the > >> first place. If it isn't there, then it can only really be accessed from > >> userspace. Other in kernel IIO consumers have no access to what valid > >> parameters are. > >> > >> Two forms are currently supported: > >> * list of values in one particular IIO_VAL_* format. > >> e.g. 1.30 1.50 1.73 > >> * range specification with a step size: > >> e.g. [1.00 0.50 2.50] > >> equivalent to 1.00 1.500 2.00 2.50 > > > > Is there any driver using this format? :) > > Yes, soon. Hopefully. See patch 3/8 > iio: mcp4531: provide range of available raw values > https://patchwork.kernel.org/patch/9391283/ I would also like to add this to mcp4131.c and ds1803.c. -- Slawomir Stepien
Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching
On Tue, 25 Oct 2016 21:24:25 +0200
Laszlo Ersek wrote:
> On 10/25/16 20:42, Alex Williamson wrote:
> > On Tue, 25 Oct 2016 20:24:19 +0200
> > Laszlo Ersek wrote:
> >
> >> Some systems have multiple instances of the exact same kind of PCI device
> >> installed. When VFIO users intend to assign these devices to VMs, they
> >> occasionally don't want to assign all of them; they'd keep a few for
> >> host-side use. The current ID- and class-based matching in pci-stub
> >> doesn't accommodate this use case, so users are left with either
> >> rc.local-style host boot scripts, or QEMU wrapper scripts (which are
> >> inferior to a pure libvirt environment).
> >>
> >> Introduce the "except" module parameter for pci-stub. In addition to
> >> "ids", users can specify a list of Domain:Bus:Device.Function tuples. The
> >> tuples are parsed and saved before pci_add_dynid() is called. The pci-stub
> >> probe function will fail for the listed devices, for the initial and all
> >> later (explicit) binding attempts.
> >>
> >> Cc: Alex Williamson
> >> Cc: Andrei Grigore
> >> Cc: Bjorn Helgaas
> >> Cc: Jayme Howard
> >> Reported-by: Andrei Grigore
> >> Ref: https://www.redhat.com/archives/vfio-users/2016-October/msg00121.html
> >> Signed-off-by: Laszlo Ersek
> >> ---
> >> drivers/pci/pci-stub.c | 63
> >> ++
> >> 1 file changed, 63 insertions(+)
> >>
> >> diff --git a/drivers/pci/pci-stub.c b/drivers/pci/pci-stub.c
> >> index 886fb3570278..120c29609c44 100644
> >> --- a/drivers/pci/pci-stub.c
> >> +++ b/drivers/pci/pci-stub.c
> >> @@ -26,8 +26,44 @@ MODULE_PARM_DESC(ids, "Initial PCI IDs to add to the
> >> stub driver, format is "
> >>
> >> "\"vendor:device[:subvendor[:subdevice[:class[:class_mask\""
> >> " and multiple comma separated entries can be specified");
> >>
> >> +#define MAX_EXCEPT 16
> >> +
> >> +static unsigned num_except;
> >> +static struct except {
> >> + u16 domain;
> >> + u16 devid;
> >> +} except[MAX_EXCEPT];
> >> +
> >> +/*
> >> + * Accommodate substrings like ":00:1c.4," MAX_EXCEPT times, with the
> >> comma
> >> + * replaced with '\0' in the last instance
> >> + */
> >> +static char except_str[13 * MAX_EXCEPT] __initdata;
> >> +
> >> +module_param_string(except, except_str, sizeof except_str, 0);
> >> +MODULE_PARM_DESC(except, "Comma-separated list of PCI addresses to except
> >> "
> >> + "from the ID- and class-based binding. The address format is "
> >> + "Domain:Bus:Device.Function (all components are required and "
> >> + "written in hex), for example, :00:1c.4. At most "
> >> + __stringify(MAX_EXCEPT) " exceptions are supported.");
> >
> > So a user needs to specify both a set of set of vendor:device ids AND an
> > exception list? Wouldn't it be easier to make a list of _included_
> > devices by address, w/o needing an ids= list?
>
> First, I didn't want to drop the ids=... parameter for compatibility
> reasons.
>
> Second (because I realize you're likely not suggesting to *drop* "ids",
> just to provide a positive-sense replacement for it), I have no idea how
> to influence the PCI subsystem like this. As far as I know (which is
> very little, admittedly), the only way to get the PCI subsystem to call
> back into a specific driver probe function is to provide
> device/vendor/subsystem IDs, and class patterns, with that device driver.
>
> If I don't provide those IDs (either statically or dynamically), then
> the driver will bind nothing, because the core won't invoke the probe
> function for any device.
>
> If I provided a match-all pattern (not sure how), then the core would
> call the probe function for all devices. While that might help move the
> actual positive filtering into the stub probe function (i.e., without
> the "ids" parameter), I don't think it would be appreciated.
This is why we have a driver_override available for devices, it
supersedes the PCI ID match table. I'd rather see work towards making
a commandline interface to driver_override, which potentially benefits
drivers beyond pci-stub, beyond PCI actually (in fact, we can pretty
much eliminate pci-stub altogether simply by specifying a dummy
driver_override that doesn't match any drivers, ex. "NONE").
Regardless of an exception list being the easiest, or understood way to
currently code pci-stub to get what you want, I still consider an
id+exception list to be convoluted. Thanks,
Alex
> > FWIW, I think the reason
> > this hasn't been done to date is that PCI bus addresses (except for
> > root bus devices) are not stable. Depending on the system, the address
> > of a given device may change, not only based on the slot where the
> > device is installed, but whether other devices in other slots are
> > populated.
>
> I agree.
>
> However, while the addresses are not stable in the face of hardware
> changes, I think the addresses don't change haphazardly (that is,
> wit
Re: [PATCH v3] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest
On Mon, 7 Nov 2016, Borislav Petkov wrote:
> On Mon, Nov 07, 2016 at 10:10:07AM +0800, He Chen wrote:
> > It should be, but I found it conflcts with `struct cpuid_regs` in
> > `arch/x86/kernel/cpuid.c` since it got exported.
>
> So make the cpuid.c-one static.
That does not work.
processor.h
enum cpuid_regs {
};
cpuid.c
struct cpuid_regs {
};
How do you make that struct definition static? And even if that'd work, how
would that help to avoid the name clash in cpuid.c?
Not at all.
Both the enum and the struct should be in processor.h obviously with
different names so we won't trip over this once more. And the obvious
naming is:
struct cpuid_regs {
u32 eax, ebx, ecx, edx;
};
enum cpuid_regs_idx {
CPUID_EAX,
CPUID_EBX,
CPUID_ECX,
CPUID_EDX,
};
as CR_E*X is just not intuitive at all.
Thanks,
tglx
Re: [PATCH 4/7] mm: defer vmalloc from atomic context
On Mon, Nov 7, 2016 at 7:01 AM, Andrey Ryabinin wrote:
> On 11/05/2016 06:43 AM, Joel Fernandes wrote:
>> On Mon, Oct 24, 2016 at 8:44 AM, Andrey Ryabinin
>> wrote:
>>>
>>>
>>> On 10/22/2016 06:17 PM, Christoph Hellwig wrote:
We want to be able to use a sleeping lock for freeing vmap to keep
latency down. For this we need to use the deferred vfree mechanisms
no only from interrupt, but from any atomic context.
Signed-off-by: Christoph Hellwig
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a4e2cec..bcc1a64 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1509,7 +1509,7 @@ void vfree(const void *addr)
if (!addr)
return;
- if (unlikely(in_interrupt())) {
+ if (unlikely(in_atomic())) {
>>>
>>> in_atomic() cannot always detect atomic context, thus it shouldn't be used
>>> here.
>>> You can add something like vfree_in_atomic() and use it in atomic call
>>> sites.
>>>
>>
>> So because in_atomic doesn't work for !CONFIG_PREEMPT kernels, can we
>> always defer the work in these cases?
>>
>> So for non-preemptible kernels, we always defer:
>>
>> if (!IS_ENABLED(CONFIG_PREEMPT) || in_atomic()) {
>> // defer
>> }
>>
>> Is this fine? Or any other ideas?
>>
>
> What's wrong with my idea?
> We can add vfree_in_atomic() and use it to free vmapped stacks
> and for any other places where vfree() used 'in_atomict() && !in_interrupt()'
> context.
Yes, this sounds like a better idea as there may not be that many
callers and my idea may hurt perf.
Thanks,
Joel
Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On 05/11/16 00:21, Daniel Kurtz wrote: On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger wrote: On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote: [...] --- /dev/null +++ b/drivers/gpu/drm/bridge/parade-ps8640.c [...] + +/* Firmware */ +#define PS_FW_NAME "ps864x_fw.bin" + From where I can download this firmware image? I suppose this FW bits have to be added to linux-firmware repository first, before this patch can be accepted. All PS8640 devices should already ship with working firmware. The firmware update procedure is only used in the unlikely event where one wants to update the bridge to a different firmware provided by Parade. Why must the lack of firmware really block landing this driver? If this is really so, can we just land the functional part of the driver first, and add the firmware update in a follow-up patch. After checking other users of request_firmware and check them against linux-firmware I think we don't need the FW in linux-firmware to get the driver merged. Especially as there already is a working FW stored on the device. Regards, Matthias
[PATCH v2 12/15] pinctrl-sx150x: Simplify interrupt handler
Make use of for_each_set_bit macro and reduce boilerplate code.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index f2ec072..78e15c9 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -465,11 +465,9 @@ static int sx150x_irq_set_type(struct irq_data *d,
unsigned int flow_type)
static irqreturn_t sx150x_irq_thread_fn(int irq, void *dev_id)
{
struct sx150x_pinctrl *pctl = (struct sx150x_pinctrl *)dev_id;
- unsigned int nhandled = 0;
- unsigned int sub_irq;
- unsigned int n;
- s32 err;
+ unsigned long n, status;
unsigned int val;
+ int err;
err = regmap_read(pctl->regmap, pctl->data->reg_irq_src, &val);
if (err < 0)
@@ -479,15 +477,11 @@ static irqreturn_t sx150x_irq_thread_fn(int irq, void
*dev_id)
if (err < 0)
return IRQ_NONE;
- for (n = 0; n < pctl->data->ngpios; ++n) {
- if (val & BIT(n)) {
- sub_irq = irq_find_mapping(pctl->gpio.irqdomain, n);
- handle_nested_irq(sub_irq);
- ++nhandled;
- }
- }
+ status = val;
+ for_each_set_bit(n, &status, pctl->data->ngpios)
+ handle_nested_irq(irq_find_mapping(pctl->gpio.irqdomain, n));
- return (nhandled > 0 ? IRQ_HANDLED : IRQ_NONE);
+ return IRQ_HANDLED;
}
static void sx150x_irq_bus_lock(struct irq_data *d)
--
2.5.5
[PATCH v2 15/15] pinctrl-sx150x: Remove magic numbers from sx150x_reset
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 56abe36..dc1341f 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -49,6 +49,8 @@ enum {
SX150X_MAX_REGISTER = 0xad,
SX150X_IRQ_TYPE_EDGE_RISING = 0x1,
SX150X_IRQ_TYPE_EDGE_FALLING = 0x2,
+ SX150X_789_RESET_KEY1 = 0x12,
+ SX150X_789_RESET_KEY2 = 0x34,
};
struct sx150x_123_pri {
@@ -771,13 +773,13 @@ static int sx150x_reset(struct sx150x_pinctrl *pctl)
err = i2c_smbus_write_byte_data(pctl->client,
pctl->data->pri.x789.reg_reset,
- 0x12);
+ SX150X_789_RESET_KEY1);
if (err < 0)
return err;
err = i2c_smbus_write_byte_data(pctl->client,
pctl->data->pri.x789.reg_reset,
- 0x34);
+ SX150X_789_RESET_KEY2);
return err;
}
--
2.5.5
[PATCH v2 07/15] pinctrl-sx150x: Improve sx150x_init_misc for SX1504/5/6
For Sx1504/5/6 only SX1506 has RegAdvanced, so put some code in place to account for that. Tested-by: Neil Armstrong Acked-by: Neil Armstrong Signed-off-by: Andrey Smirnov --- drivers/pinctrl/pinctrl-sx150x.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c index 27194e7..d51ec73 100644 --- a/drivers/pinctrl/pinctrl-sx150x.c +++ b/drivers/pinctrl/pinctrl-sx150x.c @@ -936,6 +936,13 @@ static int sx150x_init_misc(struct sx150x_pinctrl *pctl) case SX150X_456: reg = pctl->data->pri.x456.reg_advance; value = 0x00; + + /* +* Only SX1506 has RegAdvanced, SX1504/5 are expected +* to initialize this offset to zero +*/ + if (!reg) + return 0; break; case SX150X_123: reg = pctl->data->pri.x123.reg_advance; -- 2.5.5
[PATCH v2 06/15] pinctrl-sx150x: Move some code out of sx150x_init_hw
Move the code configuring explicit IRQ acking into a standalone function
to declutter sx150x_init_hw a bit and make that code somewhat less
repetitious.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 0e3e1da..27194e7 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -924,6 +924,31 @@ static int sx150x_reset(struct sx150x_pinctrl *pctl)
return err;
}
+static int sx150x_init_misc(struct sx150x_pinctrl *pctl)
+{
+ u8 reg, value;
+
+ switch (pctl->data->model) {
+ case SX150X_789:
+ reg = pctl->data->pri.x789.reg_misc;
+ value = SX150X_789_REG_MISC_AUTOCLEAR_OFF;
+ break;
+ case SX150X_456:
+ reg = pctl->data->pri.x456.reg_advance;
+ value = 0x00;
+ break;
+ case SX150X_123:
+ reg = pctl->data->pri.x123.reg_advance;
+ value = 0x00;
+ break;
+ default:
+ WARN(1, "Unknown chip model %d\n", pctl->data->model);
+ return -EINVAL;
+ }
+
+ return sx150x_i2c_write(pctl->client, reg, value);
+}
+
static int sx150x_init_hw(struct sx150x_pinctrl *pctl)
{
int err;
@@ -935,18 +960,7 @@ static int sx150x_init_hw(struct sx150x_pinctrl *pctl)
return err;
}
- if (pctl->data->model == SX150X_789)
- err = sx150x_i2c_write(pctl->client,
- pctl->data->pri.x789.reg_misc,
- SX150X_789_REG_MISC_AUTOCLEAR_OFF);
- else if (pctl->data->model == SX150X_456)
- err = sx150x_i2c_write(pctl->client,
- pctl->data->pri.x456.reg_advance,
- 0x00);
- else
- err = sx150x_i2c_write(pctl->client,
- pctl->data->pri.x123.reg_advance,
- 0x00);
+ err = sx150x_init_misc(pctl);
if (err < 0)
return err;
--
2.5.5
[PATCH v2 14/15] pinctrl-sx150x: Remove magic numbers from sx150x_irq_set_type
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 798a8bb..56abe36 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -47,6 +47,8 @@ enum {
enum {
SX150X_789_REG_MISC_AUTOCLEAR_OFF = 1 << 0,
SX150X_MAX_REGISTER = 0xad,
+ SX150X_IRQ_TYPE_EDGE_RISING = 0x1,
+ SX150X_IRQ_TYPE_EDGE_FALLING = 0x2,
};
struct sx150x_123_pri {
@@ -441,6 +443,21 @@ static void sx150x_irq_unmask(struct irq_data *d)
pctl->irq.masked &= ~BIT(n);
}
+static void sx150x_irq_set_sense(struct sx150x_pinctrl *pctl,
+unsigned int line, unsigned int sense)
+{
+ /*
+* Every interrupt line is represented by two bits shifted
+* proportionally to the line number
+*/
+ const unsigned int n = line * 2;
+ const unsigned int mask = ~((SX150X_IRQ_TYPE_EDGE_RISING |
+SX150X_IRQ_TYPE_EDGE_FALLING) << n);
+
+ pctl->irq.sense &= mask;
+ pctl->irq.sense |= sense << n;
+}
+
static int sx150x_irq_set_type(struct irq_data *d, unsigned int flow_type)
{
struct sx150x_pinctrl *pctl =
@@ -453,12 +470,11 @@ static int sx150x_irq_set_type(struct irq_data *d,
unsigned int flow_type)
n = d->hwirq;
if (flow_type & IRQ_TYPE_EDGE_RISING)
- val |= 0x1;
+ val |= SX150X_IRQ_TYPE_EDGE_RISING;
if (flow_type & IRQ_TYPE_EDGE_FALLING)
- val |= 0x2;
+ val |= SX150X_IRQ_TYPE_EDGE_FALLING;
- pctl->irq.sense &= ~(3UL << (n * 2));
- pctl->irq.sense |= val << (n * 2);
+ sx150x_irq_set_sense(pctl, n, val);
return 0;
}
--
2.5.5
Re: [PATCH v3] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest
On Fri, 4 Nov 2016, Paolo Bonzini wrote: > On 04/11/2016 16:06, Borislav Petkov wrote: > > > With no usage? Sounds like a good use of Acked-by. :) > > I don't understand what do you mean here? > > I mean that the changes to scattered.c are small, so it makes no sense > to split them. With an Acked-by I could simply take the patch into my tree. Nope. We have other changes in that area coming up, so I rather take the cpuid bits into tip and provide you a branch with that commit to pull from. Thanks, tglx
Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
On Mon, 7 Nov 2016, Daniel Bristot de Oliveira wrote: > With these two options set, the user will guarantee some runtime > for non-rt-tasks on all CPUs, while keeping real-time tasks running > as much as possible. Excellent this would improve the situation with deadlocks as a result of cgroup_locks not being released due to lack of workqueue processing.
[PATCH v2 01/15] pinctrl-sx150x: Improve OF device matching code
Add proper device specific information to of_device_id table of the
driver and add code to match against and fetch said data from it.
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index d2d4211..0523f5a 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -862,10 +863,10 @@ static const struct i2c_device_id sx150x_id[] = {
};
static const struct of_device_id sx150x_of_match[] = {
- { .compatible = "semtech,sx1508q" },
- { .compatible = "semtech,sx1509q" },
- { .compatible = "semtech,sx1506q" },
- { .compatible = "semtech,sx1502q" },
+ { .compatible = "semtech,sx1508q", .data = &sx1508q_device_data },
+ { .compatible = "semtech,sx1509q", .data = &sx1509q_device_data },
+ { .compatible = "semtech,sx1506q", .data = &sx1506q_device_data },
+ { .compatible = "semtech,sx1502q", .data = &sx1502q_device_data },
{},
};
@@ -956,9 +957,6 @@ static int sx150x_probe(struct i2c_client *client,
struct sx150x_pinctrl *pctl;
int ret;
- if (!id->driver_data)
- return -EINVAL;
-
if (!i2c_check_functionality(client->adapter, i2c_funcs))
return -ENOSYS;
@@ -968,7 +966,14 @@ static int sx150x_probe(struct i2c_client *client,
pctl->dev = dev;
pctl->client = client;
- pctl->data = (void *)id->driver_data;
+
+ if (dev->of_node)
+ pctl->data = of_device_get_match_data(dev);
+ else
+ pctl->data = (struct sx150x_device_data *)id->driver_data;
+
+ if (!pctl->data)
+ return -EINVAL;
mutex_init(&pctl->lock);
--
2.5.5
[PATCH v2 10/15] pinctrl-sx150x: Remove excessive locking
Gpiochip and irqchip aspects of this driver do not access any shared
registers on the chip itself and atomicity of various regmap operations
is ensured by that API's implementation, so there doesn't seem to be a
reason to hold the lock in as many places as it is held now.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 70 +---
1 file changed, 16 insertions(+), 54 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 4725fac..c339800 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -343,13 +343,9 @@ static int sx150x_gpio_set_single_ended(struct gpio_chip
*chip,
sx150x_pin_is_oscio(pctl, offset))
return 0;
- mutex_lock(&pctl->lock);
ret = regmap_write_bits(pctl->regmap,
pctl->data->pri.x789.reg_drain,
BIT(offset), 0);
- mutex_unlock(&pctl->lock);
- if (ret < 0)
- return ret;
break;
case LINE_MODE_OPEN_DRAIN:
@@ -357,20 +353,16 @@ static int sx150x_gpio_set_single_ended(struct gpio_chip
*chip,
sx150x_pin_is_oscio(pctl, offset))
return -ENOTSUPP;
- mutex_lock(&pctl->lock);
ret = regmap_write_bits(pctl->regmap,
pctl->data->pri.x789.reg_drain,
BIT(offset), BIT(offset));
- mutex_unlock(&pctl->lock);
- if (ret < 0)
- return ret;
break;
-
default:
- return -ENOTSUPP;
+ ret = -ENOTSUPP;
+ break;
}
- return 0;
+ return ret;
}
static int __sx150x_gpio_set(struct sx150x_pinctrl *pctl, unsigned int offset,
@@ -385,57 +377,46 @@ static void sx150x_gpio_set(struct gpio_chip *chip,
unsigned int offset,
{
struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
- if (sx150x_pin_is_oscio(pctl, offset)) {
- mutex_lock(&pctl->lock);
+ if (sx150x_pin_is_oscio(pctl, offset))
regmap_write(pctl->regmap,
pctl->data->pri.x789.reg_clock,
(value ? 0x1f : 0x10));
- mutex_unlock(&pctl->lock);
- } else {
- mutex_lock(&pctl->lock);
+ else
__sx150x_gpio_set(pctl, offset, value);
- mutex_unlock(&pctl->lock);
- }
+
}
static int sx150x_gpio_direction_input(struct gpio_chip *chip,
unsigned int offset)
{
struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
- int ret;
if (sx150x_pin_is_oscio(pctl, offset))
return -EINVAL;
- mutex_lock(&pctl->lock);
- ret = regmap_write_bits(pctl->regmap,
- pctl->data->reg_dir,
- BIT(offset), BIT(offset));
- mutex_unlock(&pctl->lock);
-
- return ret;
+ return regmap_write_bits(pctl->regmap,
+pctl->data->reg_dir,
+BIT(offset), BIT(offset));
}
static int sx150x_gpio_direction_output(struct gpio_chip *chip,
unsigned int offset, int value)
{
struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
- int status;
+ int ret;
if (sx150x_pin_is_oscio(pctl, offset)) {
sx150x_gpio_set(chip, offset, value);
return 0;
}
- mutex_lock(&pctl->lock);
- status = __sx150x_gpio_set(pctl, offset, value);
- if (status >= 0)
- status = regmap_write_bits(pctl->regmap,
- pctl->data->reg_dir,
- BIT(offset), 0);
- mutex_unlock(&pctl->lock);
+ ret = __sx150x_gpio_set(pctl, offset, value);
+ if (ret < 0)
+ return ret;
- return status;
+ return regmap_write_bits(pctl->regmap,
+pctl->data->reg_dir,
+BIT(offset), 0);
}
static void sx150x_irq_mask(struct irq_data *d)
@@ -536,12 +517,9 @@ static int sx150x_pinconf_get(struct pinctrl_dev *pctldev,
unsigned int pin,
switch (param) {
case PIN_CONFIG_DRIVE_PUSH_PULL:
case PIN_CONFIG_OUTPUT:
- mutex_lock(&pctl->lock);
ret = regmap_read(pctl->regmap,
pctl->data->pri.x789.reg_clock,
&data);
- mutex_unlock(&pctl->lock);
-
[PATCH v2 03/15] bindings: pinctrl-sx150x: Document SX1503 compatibility string
Signed-off-by: Andrey Smirnov --- Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt index c293c8a..25b4ec8 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt @@ -9,7 +9,8 @@ Required properties: "semtech,sx1506q", "semtech,sx1508q", "semtech,sx1509q", - "semtech,sx1502q". + "semtech,sx1502q", + "semtech,sx1503q". - reg: The I2C slave address for this device. -- 2.5.5
[PATCH v2 09/15] pinctrl-sx150x: Replace sx150x_*_cfg by means of regmap API
The difference between 8 and 16 pin GPIO expanders can be accomodated by
the means of regmap API without resorting to usaing driver-specific
read/write accessors. This change, IMHO, brings the following benefits:
- Replaces driver's idiosyncratic way of dealing with
mult-register fields with regmap API, which, hopefuly,
makes the code a bit easier for a new reader to understand
- Removes various multi-read for-loop register read logic
from various places in the code and puts it in a signle
place
- Removes ad-hoc IRQ register caching code in
sx150x_irq_bus_sync_unlock, since that functionality is
provided by regmap
Besided aforementioned benefits this change also implements necessary
RegSense byte swap necessary for SX1503 and SX1506 variants of the chip.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 527 +--
1 file changed, 284 insertions(+), 243 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 2eb233f..4725fac 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -106,11 +106,8 @@ struct sx150x_pinctrl {
struct irq_chip irq_chip;
struct regmap *regmap;
struct {
- int update;
u32 sense;
u32 masked;
- u32 dev_sense;
- u32 dev_masked;
} irq;
struct mutex lock;
const struct sx150x_device_data *data;
@@ -171,16 +168,16 @@ static const struct sx150x_device_data
sx1508q_device_data = {
static const struct sx150x_device_data sx1509q_device_data = {
.model = SX150X_789,
- .reg_pullup = 0x07,
- .reg_pulldn = 0x09,
- .reg_dir= 0x0f,
- .reg_data = 0x11,
- .reg_irq_mask = 0x13,
- .reg_irq_src= 0x19,
- .reg_sense = 0x17,
+ .reg_pullup = 0x06,
+ .reg_pulldn = 0x08,
+ .reg_dir= 0x0e,
+ .reg_data = 0x10,
+ .reg_irq_mask = 0x12,
+ .reg_irq_src= 0x18,
+ .reg_sense = 0x14,
.pri.x789 = {
- .reg_drain = 0x0b,
- .reg_polarity = 0x0d,
+ .reg_drain = 0x0a,
+ .reg_polarity = 0x0c,
.reg_clock = 0x1e,
.reg_misc = 0x1f,
.reg_reset = 0x7d,
@@ -192,20 +189,20 @@ static const struct sx150x_device_data
sx1509q_device_data = {
static const struct sx150x_device_data sx1506q_device_data = {
.model = SX150X_456,
- .reg_pullup = 0x05,
- .reg_pulldn = 0x07,
- .reg_dir= 0x03,
- .reg_data = 0x01,
- .reg_irq_mask = 0x09,
- .reg_irq_src= 0x0f,
- .reg_sense = 0x0d,
+ .reg_pullup = 0x04,
+ .reg_pulldn = 0x06,
+ .reg_dir= 0x02,
+ .reg_data = 0x00,
+ .reg_irq_mask = 0x08,
+ .reg_irq_src= 0x0e,
+ .reg_sense = 0x0a,
.pri.x456 = {
- .reg_pld_mode = 0x21,
- .reg_pld_table0 = 0x23,
- .reg_pld_table1 = 0x25,
- .reg_pld_table2 = 0x27,
- .reg_pld_table3 = 0x29,
- .reg_pld_table4 = 0x2b,
+ .reg_pld_mode = 0x20,
+ .reg_pld_table0 = 0x22,
+ .reg_pld_table1 = 0x24,
+ .reg_pld_table2 = 0x26,
+ .reg_pld_table3 = 0x28,
+ .reg_pld_table4 = 0x2a,
.reg_advance= 0xad,
},
.ngpios = 16,
@@ -238,20 +235,20 @@ static const struct sx150x_device_data
sx1502q_device_data = {
static const struct sx150x_device_data sx1503q_device_data = {
.model = SX150X_123,
- .reg_pullup = 0x05,
- .reg_pulldn = 0x07,
- .reg_dir= 0x03,
- .reg_data = 0x01,
- .reg_irq_mask = 0x09,
- .reg_irq_src= 0x0f,
- .reg_sense = 0x07,
+ .reg_pullup = 0x04,
+ .reg_pulldn = 0x06,
+ .reg_dir= 0x02,
+ .reg_data = 0x00,
+ .reg_irq_mask = 0x08,
+ .reg_irq_src= 0x0e,
+ .reg_sense = 0x0a,
.pri.x123 = {
- .reg_pld_mode = 0x10,
- .reg_pld_table0 = 0x11,
- .reg_pld_table1 = 0x12,
- .reg_pld_table2 = 0x13,
- .reg_pld_table3 = 0x14,
- .reg_pld_table4 = 0x15,
+ .reg_pld_mode = 0x20,
+ .reg_pld_table0 = 0x22,
+ .reg_pld_table1 = 0x24,
+ .reg_pld_table2 = 0x26,
+ .reg_pld_table3 = 0x28,
+ .reg_pld_table4 = 0x2a,
.reg_advance= 0xad,
},
.ngpios = 16,
@@ -259,70 +256,6 @@ static const
[PATCH v2 11/15] pinctrl-sx150x: Improve oscio GPIO functions
Move actual code that configures oscio pin into a separate function and
use it instead of calling sx150x_gpio_set to avoid calling
sx150x_pin_is_oscio twice and correctly propagte error code in
sx150x_gpio_direction_output.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index c339800..f2ec072 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -372,15 +372,21 @@ static int __sx150x_gpio_set(struct sx150x_pinctrl *pctl,
unsigned int offset,
BIT(offset), value ? BIT(offset) : 0);
}
+static int sx150x_gpio_oscio_set(struct sx150x_pinctrl *pctl,
+int value)
+{
+ return regmap_write(pctl->regmap,
+ pctl->data->pri.x789.reg_clock,
+ (value ? 0x1f : 0x10));
+}
+
static void sx150x_gpio_set(struct gpio_chip *chip, unsigned int offset,
int value)
{
struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
if (sx150x_pin_is_oscio(pctl, offset))
- regmap_write(pctl->regmap,
-pctl->data->pri.x789.reg_clock,
-(value ? 0x1f : 0x10));
+ sx150x_gpio_oscio_set(pctl, value);
else
__sx150x_gpio_set(pctl, offset, value);
@@ -405,10 +411,8 @@ static int sx150x_gpio_direction_output(struct gpio_chip
*chip,
struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
int ret;
- if (sx150x_pin_is_oscio(pctl, offset)) {
- sx150x_gpio_set(chip, offset, value);
- return 0;
- }
+ if (sx150x_pin_is_oscio(pctl, offset))
+ return sx150x_gpio_oscio_set(pctl, value);
ret = __sx150x_gpio_set(pctl, offset, value);
if (ret < 0)
--
2.5.5
[PATCH v2 05/15] pinctrl-sx150x: Fix incorrect constant in sx150x_init_hw
According to the datasheet for SX1504/5/6, RegAdvanced's "Autoclear NINT" bit that turns the feature when set and disables it when cleared, so writing 0x04 to the register will have the opposite from desirable effect. Tested-by: Neil Armstrong Acked-by: Neil Armstrong Signed-off-by: Andrey Smirnov --- drivers/pinctrl/pinctrl-sx150x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c index 3ccd048..0e3e1da 100644 --- a/drivers/pinctrl/pinctrl-sx150x.c +++ b/drivers/pinctrl/pinctrl-sx150x.c @@ -942,7 +942,7 @@ static int sx150x_init_hw(struct sx150x_pinctrl *pctl) else if (pctl->data->model == SX150X_456) err = sx150x_i2c_write(pctl->client, pctl->data->pri.x456.reg_advance, - 0x04); + 0x00); else err = sx150x_i2c_write(pctl->client, pctl->data->pri.x123.reg_advance, -- 2.5.5
[PATCH v2 13/15] pinctrl-sx150x: Use handle_bad_irq instead of handle_edge_irq
Althought the function passed as a "handler" during GPIO chip
instantiation is not going to ever be called, specifying handle_edge_irq
there makes for a rather confusing read, both because no "ack" callback
in specified for irqchip and because there's no acking action is
necessary.
Specify handle_bad_irq instead a make a note of the situation. This
commit should be a no-op behaviour wise.
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 78e15c9..798a8bb 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1077,9 +1077,20 @@ static int sx150x_probe(struct i2c_client *client,
pctl->irq.masked = ~0;
pctl->irq.sense = 0;
+ /*
+* Because sx150x_irq_threaded_fn invokes all of the
+* nested interrrupt handlers via handle_nested_irq,
+* any "handler" passed to gpiochip_irqchip_add()
+* below is going to be ignored, so the choice of the
+* function does not matter that much.
+*
+* We set it to handle_bad_irq to avoid confusion,
+* plus it will be instantly noticeable if it is ever
+* called (should not happen)
+*/
ret = gpiochip_irqchip_add(&pctl->gpio,
&pctl->irq_chip, 0,
- handle_edge_irq, IRQ_TYPE_NONE);
+ handle_bad_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(dev, "could not connect irqchip to gpiochip\n");
return ret;
--
2.5.5
[PATCH v2 08/15] pinctrl-sx150x: Convert driver to use regmap API
To allow for future code simplification
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/pinctrl-sx150x.c | 102 +--
2 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 801fa8b..666e952 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -171,6 +171,7 @@ config PINCTRL_SX150X
select PINCONF
select GENERIC_PINCONF
select GPIOLIB_IRQCHIP
+ select REGMAP
help
Say yes here to provide support for Semtech SX150x-series I2C
GPIO expanders as pinctrl module.
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index d51ec73..2eb233f 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -18,6 +18,7 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
@@ -45,6 +46,7 @@ enum {
};
enum {
SX150X_789_REG_MISC_AUTOCLEAR_OFF = 1 << 0,
+ SX150X_MAX_REGISTER = 0xad,
};
struct sx150x_123_pri {
@@ -102,6 +104,7 @@ struct sx150x_pinctrl {
struct pinctrl_desc pinctrl_desc;
struct gpio_chip gpio;
struct irq_chip irq_chip;
+ struct regmap *regmap;
struct {
int update;
u32 sense;
@@ -256,30 +259,6 @@ static const struct sx150x_device_data sx1503q_device_data
= {
.npins = 16, /* oscio not available */
};
-static s32 sx150x_i2c_write(struct i2c_client *client, u8 reg, u8 val)
-{
- s32 err = i2c_smbus_write_byte_data(client, reg, val);
-
- if (err < 0)
- dev_warn(&client->dev,
- "i2c write fail: can't write %02x to %02x: %d\n",
- val, reg, err);
- return err;
-}
-
-static s32 sx150x_i2c_read(struct i2c_client *client, u8 reg, u8 *val)
-{
- s32 err = i2c_smbus_read_byte_data(client, reg);
-
- if (err >= 0)
- *val = err;
- else
- dev_warn(&client->dev,
- "i2c read fail: can't read from %02x: %d\n",
- reg, err);
- return err;
-}
-
/*
* These utility functions solve the common problem of locating and setting
* configuration bits. Configuration bits are grouped into registers
@@ -312,30 +291,32 @@ static int sx150x_write_cfg(struct i2c_client *client,
u8 offset, u8 width, u8 reg, u8 val)
{
u8 mask;
- u8 data;
+ unsigned int data;
u8 shift;
int err;
+ struct sx150x_pinctrl *pctl = i2c_get_clientdata(client);
sx150x_find_cfg(offset, width, ®, &mask, &shift);
- err = sx150x_i2c_read(client, reg, &data);
+ err = regmap_read(pctl->regmap, reg, &data);
if (err < 0)
return err;
data &= ~mask;
data |= (val << shift) & mask;
- return sx150x_i2c_write(client, reg, data);
+ return regmap_write(pctl->regmap, reg, data);
}
static int sx150x_read_cfg(struct i2c_client *client,
u8 offset, u8 width, u8 reg)
{
u8 mask;
- u8 data;
+ unsigned int data;
u8 shift;
int err;
+ struct sx150x_pinctrl *pctl = i2c_get_clientdata(client);
sx150x_find_cfg(offset, width, ®, &mask, &shift);
- err = sx150x_i2c_read(client, reg, &data);
+ err = regmap_read(pctl->regmap, reg, &data);
if (err < 0)
return err;
@@ -463,11 +444,10 @@ static void sx150x_gpio_set(struct gpio_chip *chip,
unsigned int offset,
struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
if (sx150x_pin_is_oscio(pctl, offset)) {
-
mutex_lock(&pctl->lock);
- sx150x_i2c_write(pctl->client,
- pctl->data->pri.x789.reg_clock,
- (value ? 0x1f : 0x10));
+ regmap_write(pctl->regmap,
+pctl->data->pri.x789.reg_clock,
+(value ? 0x1f : 0x10));
mutex_unlock(&pctl->lock);
} else {
mutex_lock(&pctl->lock);
@@ -567,19 +547,19 @@ static irqreturn_t sx150x_irq_thread_fn(int irq, void
*dev_id)
unsigned int sub_irq;
unsigned int n;
s32 err;
- u8 val;
+ unsigned int val;
int i;
for (i = (pctl->data->ngpios / 8) - 1; i >= 0; --i) {
- err = sx150x_i2c_read(pctl->client,
- pctl->data->reg_irq_src - i,
- &val);
+ err = regmap_read(pctl->regmap,
+ pctl->data->reg_irq_src - i,
+ &val);
if (err < 0)
continue;
-
[PATCH v2 00/15] pinctrl-sx150x: Various bug-fixes and code simplifications
Linus, Neil: Here's the second version of sx150x patches, it's all pretty much the same code with the following differences: - Commit removing OF tree match tables changed to code properly matching aginst OF data - Added REGMAP dependency in Kconfig - Documented "semtech,sx1503q" compatibility string I also added Neil's Tested-bys and Acked-bys to the patches that didn't change since v1. Let me know if I missed someting. Thank you, Andrey Smirnov Andrey Smirnov (15): pinctrl-sx150x: Improve OF device matching code pinctrl-sx150x: Add SX1503 specific data bindings: pinctrl-sx150x: Document SX1503 compatibility string pinctrl-sx150x: Replace magic number in sx150x_init_hw pinctrl-sx150x: Fix incorrect constant in sx150x_init_hw pinctrl-sx150x: Move some code out of sx150x_init_hw pinctrl-sx150x: Improve sx150x_init_misc for SX1504/5/6 pinctrl-sx150x: Convert driver to use regmap API pinctrl-sx150x: Replace sx150x_*_cfg by means of regmap API pinctrl-sx150x: Remove excessive locking pinctrl-sx150x: Improve oscio GPIO functions pinctrl-sx150x: Simplify interrupt handler pinctrl-sx150x: Use handle_bad_irq instead of handle_edge_irq pinctrl-sx150x: Remove magic numbers from sx150x_irq_set_type pinctrl-sx150x: Remove magic numbers from sx150x_reset .../devicetree/bindings/pinctrl/pinctrl-sx150x.txt | 3 +- drivers/pinctrl/Kconfig| 1 + drivers/pinctrl/pinctrl-sx150x.c | 766 - 3 files changed, 433 insertions(+), 337 deletions(-) -- 2.5.5
[PATCH v2 02/15] pinctrl-sx150x: Add SX1503 specific data
Tested-by: Neil Armstrong
Acked-by: Neil Armstrong
Signed-off-by: Andrey Smirnov
---
drivers/pinctrl/pinctrl-sx150x.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 0523f5a..9466777 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -230,6 +230,29 @@ static const struct sx150x_device_data sx1502q_device_data
= {
.npins = 8, /* oscio not available */
};
+static const struct sx150x_device_data sx1503q_device_data = {
+ .model = SX150X_123,
+ .reg_pullup = 0x05,
+ .reg_pulldn = 0x07,
+ .reg_dir= 0x03,
+ .reg_data = 0x01,
+ .reg_irq_mask = 0x09,
+ .reg_irq_src= 0x0f,
+ .reg_sense = 0x07,
+ .pri.x123 = {
+ .reg_pld_mode = 0x10,
+ .reg_pld_table0 = 0x11,
+ .reg_pld_table1 = 0x12,
+ .reg_pld_table2 = 0x13,
+ .reg_pld_table3 = 0x14,
+ .reg_pld_table4 = 0x15,
+ .reg_advance= 0xad,
+ },
+ .ngpios = 16,
+ .pins = sx150x_16_pins,
+ .npins = 16, /* oscio not available */
+};
+
static s32 sx150x_i2c_write(struct i2c_client *client, u8 reg, u8 val)
{
s32 err = i2c_smbus_write_byte_data(client, reg, val);
@@ -859,6 +882,7 @@ static const struct i2c_device_id sx150x_id[] = {
{"sx1509q", (kernel_ulong_t) &sx1509q_device_data },
{"sx1506q", (kernel_ulong_t) &sx1506q_device_data },
{"sx1502q", (kernel_ulong_t) &sx1502q_device_data },
+ {"sx1503q", (kernel_ulong_t) &sx1503q_device_data },
{}
};
@@ -867,6 +891,7 @@ static const struct of_device_id sx150x_of_match[] = {
{ .compatible = "semtech,sx1509q", .data = &sx1509q_device_data },
{ .compatible = "semtech,sx1506q", .data = &sx1506q_device_data },
{ .compatible = "semtech,sx1502q", .data = &sx1502q_device_data },
+ { .compatible = "semtech,sx1503q", .data = &sx1503q_device_data },
{},
};
--
2.5.5
Re: [PATCH] coredump: fix unfreezable coredumping task
On 09/30/2016 11:50 AM, Andrey Ryabinin wrote:
> It could be not possible to freeze coredumping task when it waits
> for 'core_state->startup' completion, because threads are frozen
> in get_signal() before they got a chance to complete 'core_state->startup'.
>
> Use freezer_do_not_count() to tell freezer to ignore coredumping
> task while it waits for core_state->startup completion.
>
> Signed-off-by: Andrey Ryabinin
> Cc: sta...@vger.kernel.org
> ---
Ping. Can someone apply this please?
> fs/coredump.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index 281b768..eb9c92c 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -1,6 +1,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -423,7 +424,9 @@ static int coredump_wait(int exit_code, struct core_state
> *core_state)
> if (core_waiters > 0) {
> struct core_thread *ptr;
>
> + freezer_do_not_count();
> wait_for_completion(&core_state->startup);
> + freezer_count();
> /*
>* Wait for all the threads to become inactive, so that
>* all the thread context (extended register state, like
>
Re: task isolation discussion at Linux Plumbers
On Sat, 5 Nov 2016, Chris Metcalf wrote: > == Remote statistics == > > We discussed the possibility of remote statistics gathering, i.e. load > average etc. The idea would be that we could have housekeeping > core(s) periodically iterate over the nohz cores to load their rq > remotely and do update_current etc. Presumably it should be possible > for a single housekeeping core to handle doing this for all the > nohz_full cores, as we only need to do it quite infrequently. > > Thomas suggested that this might be the last remaining thing that > needed to be done to allow disabling the current behavior of falling > back to a 1 Hz clock in nohz_full. > > I believe Thomas said he had a patch to do this already. No, Riek was working on that. > == Remote LRU cache drain == > > One of the issues with task isolation currently is that the LRU cache > drain must be done prior to entering userspace, but it requires > interrupts enabled and thus can't be done atomically. My previous > patch series have handled this by checking with interrupts disabled, > but then looping around with interrupts enabled to try to drain the > LRU pagevecs. Experimentally this works, but it's not provable that > it terminates, which is worrisome. Andy suggested adding a percpu > flag to disable creation of deferred work like LRU cache pages. > > Thomas suggested using an RT "local lock" to guard the LRU cache > flush; he is planning on bringing the concept to mainline in any case. > However, after some discussion we converged on simply using a spinlock > to guard the appropriate resources. As a result, the > lru_add_drain_all() code that currently queues work on each remote cpu > to drain it, can instead simply acquire the lock and drain it remotely. > This means that a task isolation task no longer needs to worry about > being interrupted by SMP function call IPIs, so we don't have to deal > with this in the task isolation framework any more. > > I don't recall anyone else volunteering to tackle this, so I will plan > to look at it. The patch to do that should be orthogonal to the > revised task isolation patch series. I offered to clean up the patch from RT. I'll do that in the next days. > == Missing oneshot_stopped callbacks == > > I raised the issue that various clock_event_device sources don't > always support oneshot_stopped, which can cause an additional > final interrupt to occur after the timer infrastructure believes the > interrupt has been stopped. I have patches to fix this for tile and > arm64 in my patch series; Thomas volunteered to look at adding > equivalent support for x86. Right. Thanks, tglx
Re: [PATCH v4 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
On 07/11/16 07:57, Rick Chang wrote: Add a DT binding documentation for Mediatek JPEG Decoder of MT2701 SoC. Signed-off-by: Rick Chang Signed-off-by: Minghsiu Tsai --- .../bindings/media/mediatek-jpeg-codec.txt | 35 ++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new file mode 100644 index 000..c7dbcc2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt @@ -0,0 +1,35 @@ +* Mediatek JPEG Decoder + +Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs + +Required properties: +- compatible : "mediatek,jpgdec" Is this block in all arm SoCs from Mediatek? If not, then I would prefer to use "mediatek,mt-jpgdec" where stands for the oldest model which has this block. In parallel to that the dts should have this compatible plus the one for mt2701, for example: compatible = "mediatek,mt2701-uart", "mediatek,mt6577-uart" Thanks, Matthias
Re: [PATCH] arm/vdso: introduce vdso_mremap hook
Hi Dmitry,
On 11/01/2016 01:22 PM, Dmitry Safonov wrote:
> Add vdso_mremap hook which will fix context.vdso pointer after mremap()
> on vDSO vma. This is needed for correct landing after syscall execution.
> Primary goal of this is for CRIU on arm - we need to restore vDSO image
> at the exactly same place where the vma was in dumped application. With
> the help of this hook we'll move vDSO at the new position.
> The CRIU code handles situations like when vDSO of dumped application
> was different from vDSO on restoring system. This usally happens when
> some new symbols are being added to vDSO. In these situations CRIU
> inserts jump trampolines from old vDSO blob to new vDSO on restore.
> By that reason even if on restore vDSO blob lies on the same address as
> blob in dumped application - we still need to move it if it differs.
>
> There was previously attempt to add this functionality for arm64 by
> arch_mremap hook [1], while this patch introduces this with minimal
> effort - the same way I've added it to x86:
> commit b059a453b1cf ("x86/vdso: Add mremap hook to vm_special_mapping")
>
> At this moment, vdso restoring code is disabled for arm/arm64 arch
> in CRIU [2], so C/R is only working for !CONFIG_VDSO kernels. This patch
> is aimed to fix that.
> The same hook may be introduced for arm64 kernel, but at this moment
> arm64 vdso code is actively reworked by Kevin, so we can do it on top.
> Separately, I've refactored arch_remap hook out from ppc64 [3].
>
> [1]: https://marc.info/?i=1448455781-26660-1-git-send-email-...@codeaurora.org
> [2]: https://github.com/xemul/criu/blob/master/Makefile#L39
> [3]: https://marc.info/?i=20161027170948.8279-1-dsafo...@virtuozzo.com
>
> Cc: Kevin Brodsky
> Cc: Christopher Covington
> Cc: Andy Lutomirski
> Cc: Oleg Nesterov
> Cc: Russell King
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux...@kvack.org
> Cc: Cyrill Gorcunov
> Cc: Pavel Emelyanov
> Signed-off-by: Dmitry Safonov
> ---
> arch/arm/kernel/vdso.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 53cf86cf2d1a..d1001f87c2f6 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -54,8 +54,11 @@ static const struct vm_special_mapping vdso_data_mapping =
> {
> .pages = &vdso_data_page,
> };
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma);
> static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
> .name = "[vdso]",
> + .mremap = vdso_mremap,
> };
>
> struct elfinfo {
> @@ -254,6 +257,24 @@ void arm_install_vdso(struct mm_struct *mm, unsigned
> long addr)
> mm->context.vdso = addr;
> }
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma)
> +{
> + unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
> + unsigned long vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
> +
> + /* Disallow partial vDSO blob remap */
> + if (vdso_size != new_size)
> + return -EINVAL;
> +
> + if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
> + return -EFAULT;
> +
> + current->mm->context.vdso = new_vma->vm_start;
> +
> + return 0;
> +}
> +
> static void vdso_write_begin(struct vdso_data *vdata)
> {
> ++vdso_data->seq_count;
>
What do you think about putting this code somewhere generic (not under
arch/*), so that powerpc and arm64 can reuse it once the cosmetic changes
to make them compatible are made? My thought was that it could be defined
underneath CONFIG_GENERIC_VDSO, which architectures could select as they
became compatible.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory
On 11/07/2016 11:19 AM, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Charles (Chas) Williams wrote:
On 11/02/2016 08:25 AM, Sebastian Andrzej Siewior wrote:
I am not sure if this a race with the new hotplug code or something that was
always there. Both (M. Vefa Bicakc and Charles) say that the box boots
sometimes fine (without the patch). smp_store_boot_cpu_info() should have
run
before the notofoert and thus should have set the info properly. However I
got
the following bootlog from Charles with this patch:
I don't this this is a race. Here is some debugging from the two CPU VM
(2 sockets, 1 core per socket). In identify_cpu() we have:
/* The boot/hotplug time assigment got cleared, restore it */
c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id);
The values just after this:
[0.228306] identify_cpu: c 88023fd0a040 logical_proc_id 65535
c->phys_proc_id 2
So what's interesting here, is the phys_proc_id of 2 for CPU1:
int topology_phys_to_logical_pkg(unsigned int phys_pkg)
{
if (phys_pkg >= max_physical_pkg_id)
return -1;
return physical_to_logical_pkg[phys_pkg];
}
And we happen to know the max_physical_pkg_id is 2 in this case.
So apparently, topology_phys_to_logical_pkg() returns -1 and it gets
assigned to the logical_proc_id.
I don't know why the CPU's phys_proc_id is 2.
max_physical_pkg_id gets initialized via:
cpus = boot_cpu_data.x86_max_cores;
max_physical_pkg_id = DIV_ROUND_UP(MAX_LOCAL_APIC, ncpus);
What's the value of boot_cpu_data.x86_max_cores and MAX_LOCAL_APIC?
I have discovered that that is not the problem. smp_init_package_map()
is calculating the physical core id using the following:
for_each_present_cpu(cpu) {
unsigned int apicid = apic->cpu_present_to_apicid(cpu);
...
if (!topology_update_package_map(apicid, cpu))
continue;
...
int topology_update_package_map(unsigned int apicid, unsigned int cpu)
{
unsigned int new, pkg = apicid >> boot_cpu_data.x86_coreid_bits;
But later when the secondary CPU's are identified they use a different
calculation using the local APIC ID from the CPU's registers:
static void generic_identify(struct cpuinfo_x86 *c)
...
if (c->cpuid_level >= 0x0001) {
c->initial_apicid = (cpuid_ebx(1) >> 24) & 0xFF;
...
c->phys_proc_id = c->initial_apicid;
So at the end of identify_cpu() when the boot/hotplug assignment is
put back:
c->logical_proc_id = topology_phys_to_logical_pkg(c->phys_proc_id);
topology_phys_to_logical_pkg() is returning an invalid logical processor
since one isn't configured.
It's not clear to me what the right thing to do is or which is right.
Re: [PATCH 3.12 69/72] Revert "fix minor infoleak in get_user_ex()"
So a patch something like this might be a safe way to fix the
potential infoleak in older kernels.
THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
it probably works. It just initializes the output variable with 0 in
the inline asm description, instead of doing it in the exception
handler.
It will generate slightly worse code (a few unnecessary ALU
operations), but it doesn't have any interactions with the exception
handler implementation.
Linus
arch/x86/include/asm/uaccess.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 5838fa911aa0..c2e06ee8b290 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -321,7 +321,7 @@ do {
\
#define __get_user_asm_u64(x, ptr, retval, errret) \
__get_user_asm(x, ptr, retval, "q", "", "=r", errret)
#define __get_user_asm_ex_u64(x, ptr) \
-__get_user_asm_ex(x, ptr, "q", "", "=r")
+__get_user_asm_ex(x, ptr, "q", "", "=&r")
#endif
#define __get_user_size(x, ptr, size, retval, errret) \
@@ -364,13 +364,13 @@ do {
\
__chk_user_ptr(ptr);\
switch (size) { \
case 1: \
- __get_user_asm_ex(x, ptr, "b", "b", "=q"); \
+ __get_user_asm_ex(x, ptr, "b", "b", "=&q"); \
break; \
case 2: \
- __get_user_asm_ex(x, ptr, "w", "w", "=r"); \
+ __get_user_asm_ex(x, ptr, "w", "w", "=&r"); \
break; \
case 4: \
- __get_user_asm_ex(x, ptr, "l", "k", "=r"); \
+ __get_user_asm_ex(x, ptr, "l", "k", "=&r"); \
break; \
case 8: \
__get_user_asm_ex_u64(x, ptr); \
@@ -384,7 +384,7 @@ do {
\
asm volatile("1:mov"itype" %1,%"rtype"0\n" \
"2:\n" \
_ASM_EXTABLE_EX(1b, 2b)\
-: ltype(x) : "m" (__m(addr)))
+: ltype(x) : "m" (__m(addr)), "0" (0))
#define __put_user_nocheck(x, ptr, size) \
({ \
Re: [Ksummit-discuss] Including images on Sphinx documents
On Mon, Nov 07, 2016 at 09:46:48AM -0200, Mauro Carvalho Chehab wrote: > That's said, PNG also doesn't seem to work fine on Sphinx 1.4.x. > > On my tests, I installed *all* texlive extensions on Fedora 24, to > be sure that the issue is not the lack of some extension[1], with: > > # dnf install $(sudo dnf search texlive |grep all|cut -d. -f 1|grep > texlive-) > > When running LaTeX in interactive mode, building just the media > PDF file with: > > $ cls;make cleandocs; make SPHINXOPTS="-j5" DOCBOOKS="" > SPHINXDIRS=media latexdocs > $ PDFLATEX=xelatex LATEXOPTS="-interaction=interactive" -C > Documentation/output/media/latex > > I get this: > > LaTeX Warning: Hyper reference `uapi/v4l/subdev-formats:bayer-patterns' > on page >153 undefined on input line 21373. > >[153] > ! Extra alignment tab has been changed to \cr. >\endtemplate > > l.21429 \unskip}\relax \unskip} > \relax \\ > ? > > This patch fixes the issue: > > https://git.linuxtv.org/mchehab/experimental.git/commit/?h=dirty-pdf&id=b709de415f34d77cc121cad95bece9c7ef4d12fd > > That means that Sphinx is not generating the right LaTeX output even for > (some?) PNG images. \includegraphics normally works just fine for PNG images in PDF documents. [...] > And it may even require "--shell-escape" to be passed at the xelatex > call if inkscape is not in the path, with seems to be a strong > indication that SVG support is not native to texlive, but, instead, > just a way to make LaTeX to call inkscape to do the image conversion. Please don't require --shell-escape as part of the TeX workflow. If LaTeX can't handle the desired image format natively, it needs conversion in advance. - Josh Triplett
Re: [PATCH v2 3/3] arm64: dts: Add Broadcom Northstar2 device tree entries for PDC driver.
On 06/30/2016 12:59 PM, Rob Rice wrote: > From: Rob Rice > > Add Broadcom Northstar2 SoC device tree entries for PDC driver. > > Signed-off-by: Rob Rice > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Applied, thanks Rob! -- Florian
Re: [PATCH v3] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest
On Mon, Nov 07, 2016 at 05:47:21PM +0100, Thomas Gleixner wrote:
> How do you make that struct definition static?
Not make it static - rename it. Sorry.
It is used only locally in that file anyway.
> Both the enum and the struct should be in processor.h obviously with
> different names so we won't trip over this once more. And the obvious
> naming is:
>
> struct cpuid_regs {
> u32 eax, ebx, ecx, edx;
> };
>
> enum cpuid_regs_idx {
> CPUID_EAX,
> CPUID_EBX,
> CPUID_ECX,
> CPUID_EDX,
> };
>
> as CR_E*X is just not intuitive at all.
Ok, that makes sense.
Also, grepping around the tree - we don't have one definitive enum
containing all the architectural registers and maybe we should have one.
We do have some PT_E*X ptrace definitions and others in entry*.S, and...
We probably should have something like:
enum regs {
AX = 0,
CX,
DX,
BX,
SP,
BP,
SI,
DI,
R8,
R9,
R10,
R11,
R12,
R13,
R14,
R15
};
in the exactly same order as they're encoded in the x86 opcodes.
Yeah, I don't see a pressing reason for that yet though but maybe
we should think about it. My angle is, avoid confusion and ad-hoc
definitions spreading around the code.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] Fix: disable sys_membarrier when nohz_full is enabled
- On Nov 3, 2016, at 1:49 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Thu, Nov 03, 2016 at 10:29:28AM -0600, Mathieu Desnoyers wrote:
>> Userspace applications should be allowed to expect the membarrier system
>> call with MEMBARRIER_CMD_SHARED command to issue memory barriers on
>> nohz_full CPUs, but synchronize_sched() does not take those into
>> account.
>>
>> Given that we do not want unrelated processes to be able to affect
>> real-time sensitive nohz_full CPUs, simply return ENOSYS when membarrier
>> is invoked on a kernel with enabled nohz_full CPUs.
>>
>> Signed-off-by: Mathieu Desnoyers
>> CC: "Paul E. McKenney"
>
> Acked-by: "Paul E. McKenney"
Hi Paul,
Do you plan to pick it up through your tree, or I should sent
it directly to Linus ?
Thanks,
Mathieu
>
>> CC: Josh Triplett
>> CC: Steven Rostedt
>> CC: Lai Jiangshan
>> CC: [3.10+]
>> ---
>> kernel/membarrier.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/kernel/membarrier.c b/kernel/membarrier.c
>> index 536c727..9f9284f 100644
>> --- a/kernel/membarrier.c
>> +++ b/kernel/membarrier.c
>> @@ -16,6 +16,7 @@
>>
>> #include
>> #include
>> +#include
>>
>> /*
>> * Bitmask made from a "or" of all commands within enum membarrier_cmd,
>> @@ -51,6 +52,9 @@
>> */
>> SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
>> {
>> +/* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
>> +if (tick_nohz_full_enabled())
>> +return -ENOSYS;
>> if (unlikely(flags))
>> return -EINVAL;
>> switch (cmd) {
>> --
>> 2.1.4
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Re: [RFC] proc: don't show kernel-internal mnt_id in fdinfo (if possible)
Dmitry Safonov writes:
> Some kernel special fs could be mounted by userspace, let's show
> userspace mnt_id in those cases.
You are asking the kernel to lie to userspace in the case when
the truth in inconvenient. That seems blantantly wrong.
In the case of an internal mount you may want to use the device id
of the device the filesystem is mounted on so you can tie all of
the mounts together. That would allow restore and other things
to do something useful.
That information is available with fstat on a file descriptor so I don't
think we need to export it. But if it is not available I can see
the point of a patch.
Outright ling to userpsace. No. That is just horrible.
Nacked-by: "Eric W. Biederman"
>
> Otherwise, I got:
> [~]# cat /proc/11299/fdinfo/3
> pos:0
> flags: 0202
> mnt_id: 14
> [~]# cat /proc/11299/mountinfo | grep '^14'
> [~]# ls -l /proc/11299/fd/3
> lrwx--. 1 root root 64 Nov 7 18:30 /proc/11299/fd/3 -> /test-queue
> [~]# ls /dev/mqueue/
> test-queue
> [~]# cat /proc/11299/mountinfo | grep mqueue
> 32 18 0:14 / /dev/mqueue rw,relatime shared:17 - mqueue mqueue rw,seclabel
>
> This happens because mqueue fs is mounted twice:
> - the first is kernel-internal mnt on init:
> kernel_init=>do_one_initcall=>init_mqueue_fs=>mq_init_ns=>vfs_kern_mount
> - the second time it's systemd's mount-unit:
> entry_SYSCALL_64_fastpath=>SyS_mount=>do_mount=>vfs_kern_mount
>
> For the purpose of userspace parsing, having in-kernel mnt_id is less
> useful then mnt_id of mount point: afterwards I'm able to see fs type,
> path, etc:
> [~]# cat /proc/11152/mountinfo | grep mqueue
> 32 18 0:14 / /dev/mqueue rw,relatime shared:18 - mqueue mqueue rw,seclabel
> [~]# cat /proc/11152/fdinfo/3
> pos:0
> flags: 0202
> mnt_id: 32
>
> On a bad side - if we've no userspace mount, we still can't tell a thing
> about opened fd..
>
> Cc: Al Viro
> Cc: Andrey Vagin
> Cc: "Eric W. Biederman"
> Cc: Rob Landley
> Signed-off-by: Dmitry Safonov
> ---
> fs/proc/fd.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/fs/proc/fd.c b/fs/proc/fd.c
> index d21dafef3102..bfa8699bcd8e 100644
> --- a/fs/proc/fd.c
> +++ b/fs/proc/fd.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -19,9 +20,10 @@
> static int seq_show(struct seq_file *m, void *v)
> {
> struct files_struct *files = NULL;
> - int f_flags = 0, ret = -ENOENT;
> + int f_flags = 0, ret = -ENOENT, mnt_id = 0;
> struct file *file = NULL;
> struct task_struct *task;
> + struct mount *mount;
>
> task = get_proc_task(m->private);
> if (!task)
> @@ -52,9 +54,25 @@ static int seq_show(struct seq_file *m, void *v)
> if (ret)
> return ret;
>
> + mount = real_mount(file->f_path.mnt);
> + if (mount->mnt_ns == MNT_NS_INTERNAL) {
> + struct mount *mnt;
> +
> + lock_mount_hash();
> + list_for_each_entry(mnt, &mount->mnt_instance, mnt_instance) {
> + if (current->nsproxy->mnt_ns == mnt->mnt_ns) {
> + mnt_id = mnt->mnt_id;
> + break;
> + }
> + }
> + unlock_mount_hash();
> + }
> +
> + if (mnt_id == 0)
> + mnt_id = mount->mnt_id;
> +
> seq_printf(m, "pos:\t%lli\nflags:\t0%o\nmnt_id:\t%i\n",
> -(long long)file->f_pos, f_flags,
> -real_mount(file->f_path.mnt)->mnt_id);
> +(long long)file->f_pos, f_flags, mnt_id);
>
> show_fd_locks(m, file, files);
> if (seq_has_overflowed(m))
Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
On Mon, 07 Nov 2016, Martin Steigerwald wrote: > It is also the same kind of corruptions as shown in > > [Bug 177701] warning in intel_dp_aux_transfer > https://bugzilla.kernel.org/show_bug.cgi?id=177701 > > Just compare > > https://bugzilla.kernel.org/attachment.cgi?id=241801 > > with > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png > > > However that bug report links to > > https://bugs.freedesktop.org/show_bug.cgi?id=97344 > > yet the patch mentioned in there does not fix the issue. So I wonder whether > bug #97344 and bug #177701 are really the same. They are the same, it's just that #177701 conflates two issues, a warning (tracked at fdo #973449) and a graphics corruption. The latter appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402. The fix has now been pushed to drm-intel-fixes branch of http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen latest fixes. Please try that and report back. > Of course I can report a bug at fdo as well, but I am a bit confused > whether it may not already have been reported. Well I hope I get a > chance to report it there as well and you get to decide. If drm-intel-fixes doesn't fix the issue for you, please file a *new* bug over at the freedesktop.org bugzilla. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
Re: [PATCH v2] drm: move allocation out of drm_get_format_name()
On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >
> > drm: make drm_get_format_name thread-safe
> >
> > Signed-off-by: Eric Engestrom
> > [danvet: Clarify that the returned pointer must be freed with
> > kfree().]
> > Signed-off-by: Daniel Vetter
>
> The Fixes: format is:
>
> Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
>
> But is this a fix, really, or just an improvement? What exactly is the
> bug being fixed? The commit message is not sufficient.
"The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.
Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory."
Does this sound good?
> > @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
> > int drm_format_vert_chroma_subsampling(uint32_t format);
> > int drm_format_plane_width(int width, uint32_t format, int plane);
> > int drm_format_plane_height(int height, uint32_t format, int plane);
> > -char *drm_get_format_name(uint32_t format) __malloc;
> > +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
> > *buf);
>
> I wonder if it would be better to make that return "const char *". If
> the user really wants to look under the hood, there's buf->str. *shrug*
Good idea, I'll do that in v3 with the proper commit msg and tags. It'll
have to wait another day though, -ENOTIME and all.
>
> With the commit message improved,
>
> Reviewed-by: Jani Nikula
Cheers :)
Eric
Re: [PATCH 3.12 00/72] 3.12.67-stable review
On 11/07/2016 05:04 AM, Jiri Slaby wrote:
This is the start of the stable review cycle for the 3.12.67 release.
There are 72 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Nov 9 14:03:48 CET 2016.
Anything received after that time might be too late.
Build results:
total: 128 pass: 127 fail: 1
Failed builds:
um:defconfig
Qemu test results:
total: 85 pass: 85 fail: 0
Details are available at http://kerneltests.org/builders.
Build error log for um:defconfig:
ipc/sem.c: In function 'complexmode_tryleave':
ipc/sem.c:317:2: error: implicit declaration of function 'smp_store_release'
ipc/sem.c: In function 'sem_lock':
ipc/sem.c:370:3: error: implicit declaration of function 'smp_load_acquire'
Culprit is commit a198951bf258 ("ipc/sem.c: fix complex_count vs. simple op
race"),
and reverting it fixes the problem. Copying the patch author for feedback.
Guenter
Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
Hi Hans,
On Sunday, 6 November 2016 11:54:35 GMT Hans de Goede wrote:
> > What I see in my systems, and what 05fd007e4629 ("console: don't prefer
> > first registered if DT specifies stdout-path") addressed, is that if
> > there are for example 2 UARTs uart0 & uart1 that are probed in that order
> > and stdout-path indicates that we should use uart1 we wind up essentially
> > ignoring it because>
> > the ordering of the relevant calls goes:
> > - of_console_check() for uart0
> > - add_preferred_console() for uart0
> > - register_console() for uart0
> > - of_console_check() for uart1
> > - add_preferred_console() for uart1
> > - register_console() for uart1
> >
> > Since of_check_console() doesn't get called for uart1 until after uart0
> > has
> > been probed, we don't add an entry for it to the console_cmdline array
> > until after register_console() has already decided to enable uart0
> > because preferred_console == -1.
> >
> > I'm not the only one seeing this oddity either, for example see the
> > discussion on this patch:
> >
> > https://patchwork.kernel.org/patch/9263753/
> >
> > By simply reverting my patch you restore us to a position where so far as
> > I
> > can see we simply do not honor stdout-path for the real kernel console.
>
> As said before, we do still honor it, but in your probe example we also get
> a (second) serial console on uart0, where as you only want one on uart1.
...but don't we only support one console per type of device? That's what
Documentation/serial-console.txt says anyway, which means having a console on
both uart0 & uart1 does not work. I could live with having console output on
an extra UART, but that's not what I was seeing when I wrote this patch.
> So I see a few possible solutions here:
>
> 1) Do a new version of your patch which changes the "&&
> !of_specified_console" check to "&& (newcon == tty0 ||
> !of_specified_console)", then we would still always register tty0 (as long
> as it gets registered first, just like now) and we would not register uart0
> in your above example, note the "newcon == tty0" check in my example is
> pseudo-code. I would be happy to try out such a patch
>
> 2) Add a new dt property to enable the new behavior you seek
>
> I'm myself tending towards 1 as a better solution: treat tty0 special,
> because some existing setups rely on it always being registered as a
> console even if stdout-path is specified and otherwise always honor
> stdout-path.
>
> Regards,
>
> Hans
That does feel a little hack-ish to me though... I don't like the reliance on
probe ordering, nor special casing tty0 in general.
In any case I don't think I have the time to unpick all this at the moment, so
I suggest we go ahead with your revert for now & I'll revisit the system I was
working on when I find the time.
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part.
Re: CISS driver error introduced with kernel-4.9.0-0.rc2.git1.1.fc26
On 11/07/2016 04:44 AM, Johnny Bieren wrote: Hello, It appears that a check_unmap kernel failure for the CISS driver was introduced with kernel-4.9.0-0.rc2.git1.1.fc26. When booting this kernel, or any newer kernel, I see the following: [3.676658] HP CISS Driver (v 3.6.26) 0m] Reached target System Initialization. Starting dracut initqueue hook... Starting Show Plymouth Boot Screen... [3.756592] scsi host0: pata_amd [3.772866] scsi host1: pata_amd [3.782052] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x2000 irq 14 [3.789616] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x2008 irq 15 [3.825789] cciss :02:04.0: cciss0: <0x46> at PCI :02:04.0 IRQ 24 using DAC [3.836530] audit: type=1130 audit(1478270493.962:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ OK ] Started Show[3.839544] [ cut here ] Plymouth Boot S[3.839555] WARNING: CPU: 0 PID: 193 at lib/dma-debug.c:1164 check_unmap+0x4af/0x940 creen. [3.839559] cciss :02:04.0: DMA-API: device driver failed to check map error[device address=0x38f521c0] [size=36 bytes] [mapped as single] [3.839563] Modules linked in: serio_raw cciss(+) pata_amd [3.839566] CPU: 0 PID: 193 Comm: kworker/0:2 Not tainted 4.9.0-0.rc2.git1.1.fc26.x86_64 #1 [3.839567] Hardware name: HP ProLiant DL385 G1, BIOS A05 03/01/2006 [3.839573] Workqueue: events work_for_cpu_fn [3.839577] 9e9ec05938f8 8546cd23 9e9ec0593948 [3.839579] 9e9ec0593938 850af4cb 048c0082 8aa07ca0ea60 [3.839582] 87483a00 8aa07b878180 0282 85c5ad66 [3.839582] Call Trace: [3.839588] [] dump_stack+0x86/0xc3 [3.839591] [] __warn+0xcb/0xf0 [3.839593] [] warn_slowpath_fmt+0x5f/0x80 [3.839595] [] check_unmap+0x4af/0x940 [3.839597] [] debug_dma_unmap_page+0x79/0xa0 [3.839613] [] sendcmd_withirq_core+0x217/0x260 [cciss] [3.839618] [] ? wait_for_completion+0x110/0x140 [3.839623] [] sendcmd_withirq+0x98/0xb0 [cciss] [3.839628] [] cciss_init_one+0x1a8f/0x1f70 [cciss] [3.839632] [] local_pci_probe+0x45/0xa0 [3.839634] [] work_for_cpu_fn+0x14/0x20 [3.839637] [] process_one_work+0x23e/0x6f0 [3.839638] [] ? process_one_work+0x1ba/0x6f0 [3.839641] [] worker_thread+0x1d3/0x490 [3.839642] [] ? process_one_work+0x6f0/0x6f0 [3.839644] [] ? process_one_work+0x6f0/0x6f0 [3.839648] [] kthread+0x102/0x120 [3.839652] [] ? trace_hardirqs_on_caller+0xf5/0x1b0 [3.839655] [] ? kthread_park+0x60/0x60 [3.839658] [] ret_from_fork+0x2a/0x40 [3.839659] ---[ end trace 1ec289ff52b16fd7 ]--- [3.839660] Mapped at: [3.839663] [3.839663] [] debug_dma_map_page+0x8c/0x160 [3.839668] [3.839668] [] fill_cmd+0x1bf/0x420 [cciss] [3.839672] [3.839672] [] sendcmd_withirq+0x64/0xb0 [cciss] [3.839676] [3.839676] [] cciss_init_one+0x1a8f/0x1f70 [cciss] [3.839679] [3.839679] [] local_pci_probe+0x45/0xa0 [3.859535] scsi host2: cciss This problem does not appear when booting with kernel-4.9.0-0.rc2.git0.1.fc26. It reproduces 100% of the time, simply try to boot kernel-4.9.0-0.rc2.git1.1.fc26 on a host with a CISS disk. Thank you, Johnny For reference, the corresponding upstream commits for the Fedora tags are 6edc51a8d43b0bb8263fefaa8eb0cf62e8499978 and 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 although I think those two tags may be a misdirection because kernel-4.9.0-0.rc2.git0.1.fc26 had DMA_API_DEBUG turned off. Thanks, Laura
Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option
Hi Geert,
On 07/11/16 15:41, Geert Uytterhoeven wrote:
> Hi Robin,
>
> On Tue, Nov 1, 2016 at 12:46 PM, Robin Murphy wrote:
> To aid debugging and catch devices not supporting DMA to memory outside
> the 32-bit address space, add a kernel command line option
> "swiotlb=nobounce", which disables the use of bounce buffers.
> If specified, trying to map memory that cannot be used with DMA will
> fail, and a warning will be printed (rate-limited).
This rationale seems questionable - how useful is non-deterministic
behaviour for debugging really? What you end up with is DMA sometimes
working or sometimes not depending on whether allocations happen to
naturally fall below 4GB or not. In my experience, that in itself can be
a pain in the arse to debug.
>>>
>>> It immediately triggered for me, though:
>>>
>>> rcar-dmac e730.dma-controller: Cannot do DMA to address
>>> 0x00067a9b7000
>>> ravb e680.ethernet: Cannot do DMA to address 0x00067aa07780
>>>
Most of the things you might then do to make things more deterministic
again (like making the default DMA mask tiny or hacking out all the
system's 32-bit addressable RAM) are also generally sufficient to make
DMA fail earlier and make this option moot anyway. What's the specific
use case motivating this?
>>>
>>> My use case is finding which drivers and DMA engines do not support 64-bit
>>> memory. There's more info in my series "[PATCH/RFC 0/5] arm64: r8a7796:
>>> 64-bit
>>> Memory and Ethernet Prototype"
>>> (https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg08393.html)
>>
>> Thanks for the context. I've done very similar things in the past, and
>> my first instinct would be to change the default DMA mask in
>> of_dma_configure() to something which can't reach RAM (e.g. <30 bits),
>> then instrument dma_set_mask() to catch cleverer drivers. That's a
>> straightforward way to get 100% coverage - the problem with simply
>> disabling bounce buffering is that whilst statistically it almost
>> certainly will catch >95% of cases, there will always be some that it
>> won't; if some driver only ever does a single dma_alloc_coherent() early
>> enough that allocations are still fairly deterministic, and always
>> happens to get a 32-bit address on that platform, it's likely to slip
>> through the net.
>>
>> I'm not against the idea of SWIOTLB growing a runtime-disable option,
>> I'm just not sure what situation it's actually the best solution for.
>
> If I set the DMA mask to a small value, DMA is never used, and SWIOTLB
> always falls back to bounce buffers (and DMAing from the small pool)?
Not quite - I meant setting the default mask to a value small enough
that any attempt to allocate or map within it (whether bounced or
otherwise) cannot possibly succeed. Of course, if you have RAM right
down to address 0 this becomes trickier - I'm not entirely certain that
going to extremes (DMA_BIT_MASK(1), say) wouldn't end up going wrong
somewhere for misleadingly unrelated reasons - but I got the impression
from the mainline DT that RAM on your platform starts at 0x4000,
hence the 30-bit suggestion.
At that point, you can instantly tell for certain that any driver for
which DMA starts failing is relying on the default mask and definitely
needs looking at for 64-bit support, and anything that doesn't just
needs a simple check of what it's passing to dma_set_*mask*().
Alternatively, the really bulletproof option is to get the firmware to
load the kernel into the >4GB area(s) of RAM (or hack dram_base in
handle_kernel_image() in arch/arm64/kernel/efi-stub.c) and simply remove
any 32-bit-addressable areas from the DT entirely (assuming the EFI
memory map isn't hard-coded). Then SWIOTLB becomes moot as there's
nowhere it can even allocate a usable bounce buffer.
> That's the inverse of what I want to achieve: I want to avoid using the
> bounce feature, to make sure the DMA engine is always used with whatever
> kind of memory.
As I said, it's that "always" that's the problem - there is already a
no-op path through the SWIOTLB code if the buffer happens to lie within
the device's DMA mask to start with, so just making SWIOTLB a no-op does
nothing to reveal anything sufficiently lucky to always hit that path on
current platforms.
Robin.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
Re: [PATCH] serial: sirf: Simplify a test
On Mon, 7 Nov 2016, Arnd Bergmann wrote:
> On Tuesday, November 1, 2016 8:03:33 AM CET Christophe JAILLET wrote:
> > 'dmaengine_prep_dma_cyclic()' does not return an error pointer, so the test
> > can be simplified to be more consistent.
> >
> > Signed-off-by: Christophe JAILLET
>
> The change looks correct in principle. It would be good to automate looking
> for other instances of this bug. How did you find it? Do you have e.g. a
> coccinelle script or did you just stumble over the issue by accident?
I'm working on collecting this information in a more general way. It is
complicated by the fact that there are some functions that have the same
names but different behaviors, and I want to be clear about when that is
an issue. There are nevertheless limits to the accuracy that can be
obtained with Coccinelle, because Coccinelle doesn't take values into
account. Sometimes a variable is initialized to NULL, just to have a
starting value, but in practice the only way to reach an error return is
via conditionals that have the effect of ensuring that the value is
ERR_PTR. So at least the cases that are reported as being able to return
both NULL and ERR_PTR will need some careful checking.
julia
>
> There is one problem with your patch:
>
> > drivers/tty/serial/sirfsoc_uart.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/sirfsoc_uart.c
> > b/drivers/tty/serial/sirfsoc_uart.c
> > index b186c9c4f850..666ca3156961 100644
> > --- a/drivers/tty/serial/sirfsoc_uart.c
> > +++ b/drivers/tty/serial/sirfsoc_uart.c
> > @@ -609,7 +609,7 @@ static void sirfsoc_uart_start_next_rx_dma(struct
> > uart_port *port)
> > sirfport->rx_dma_items.dma_addr, SIRFSOC_RX_DMA_BUF_SIZE,
> > SIRFSOC_RX_DMA_BUF_SIZE / 2,
> > DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
> > - if (IS_ERR_OR_NULL(sirfport->rx_dma_items.desc)) {
> > + if (!sirfport->rx_dma_items.desc) {
> > dev_err(port->dev, "DMA slave single fail\n");
> > return;
> > }
>
> The serial driver is for the sirf platform, which uses the sirf-dma
> dmaengine driver, and that particular driver has an incorrect
> dma_prep_cyclic implementation, so I think we also need this fix:
>
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index 8f62edad51be..220c611c89ae 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -775,7 +775,7 @@ sirfsoc_dma_prep_cyclic(struct dma_chan *chan, dma_addr_t
> addr,
>* BUFB
>*/
> if (buf_len != 2 * period_len)
> - return ERR_PTR(-EINVAL);
> + return NULL;
>
> /* Get free descriptor */
> spin_lock_irqsave(&schan->lock, iflags);
>
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default
On Thu, 3 Nov 2016 09:59:31 -0700 "Paul E. McKenney" wrote: > On Thu, Nov 03, 2016 at 05:33:27PM +0100, Sebastian Andrzej Siewior wrote: > > On 2016-11-03 09:22:28 [-0700], Paul E. McKenney wrote: > > > On Wed, Nov 02, 2016 at 05:30:02PM +0100, Sebastian Andrzej Siewior > > > wrote: > > > > RCU_EXPEDITE_BOOT should speed up the boot process by enforcing > > > > synchronize_rcu_expedited() instead of synchronize_rcu() during the boot > > > > process. There should be no reason why one does not want this and there > > > > is no need worry about real time latency at this point. > > > > Therefore make it default. > > > > > > > > Signed-off-by: Sebastian Andrzej Siewior > > > > > > Well, it has been awhile since I removed a Kconfig parameter. > > > > > > So why could this be a bad thing? > > > > > > 1.Very large systems might see scalability issues with > > > unconditional > > > expediting at boot. But if we don't try it, we won't know. > > > > You mean we would make the boot process slower for them instead of > > faster? > > For really bit systems, quite possibly, where "really big" means > many hundreds or (more likely) thousands of CPUs. > > But there are things that I can do to fix this when and if. > > > > 2.People bringing up new hardware might not want quite so many > > > IPIs. But they can just set rcu_normal to prevent that. > > > > I wanted to make things simple and not complicated… > > I know that feeling. ;-) > I agree, but if this creates a boot time regression in large machines, it may not be warranted. I know Linus usually doesn't like options with default y, but this may be one of those exceptions. Perhaps we should make it on by default and say in the config "if you have a machine with 100s or 1000s of CPUs, you may want to disable this". -- Steve
Re: [PATCH v3] console: use first console if stdout-path device doesn't appear
Hi Larry, On Monday, 7 November 2016 09:26:37 GMT Larry Finger wrote: > > A revert was already submitted by Hans de Goede & is being discussed over > > here: > > > > https://marc.info/?l=linux-kernel&m=147826151427455&w=2 > > I am a little surprised that I was not CCd on that thread. Hans started that thread without copying you just as you started your thread without copying Andreas, who reported issues first. > To reiterate, my > PowerBook G4 with a PPC32 processor CRASHES on boot. That is a lot more > serious than the console output disappearing. Crashes as in init dies due to lack of a console, right? > As it seems unlikely that this regression will be fixed in the current > cycle, I recommend that the reversion of commit 05fd007e4629 until a proper > fix is available. I agree that reverting is probably the best option for now, and have replied with that in the other thread too. Thanks, Paul signature.asc Description: This is a digitally signed message part.
Re: [PATCH 20/25] x86/mcheck: Be prepared for a rollback back to the ONLINE state
On 2016-11-07 13:31:29 [+0100], Borislav Petkov wrote: > Yeah, so say that please - slapping "()" after the state name doesn't > make it clear. Updated. Sebastian
Re: [Ksummit-discuss] Including images on Sphinx documents
On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote: > 2) add an Sphinx extension that would internally call ImageMagick and/or >inkscape to convert the bitmap; This seems sensible; Sphinx should directly handle the source format we want to use for images/diagrams. > 3) if possible, add an extension to trick Sphinx for it to consider the >output dir as a source dir too. Or to provide an additional source path and point that at the output directory.
Re: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info
On 11/06/2016 07:37 PM, Li, Liang Z wrote: >> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM. >> On a 1TB system, that's 256 passes through the top-level loop. >> The bottom-level lists have tens of thousands of pages in them, even on my >> laptop. Only 1/256 of these pages will get consumed in a given pass. >> > Your description is not exactly. > A 32k bitmap is used only when there is few free memory left in the system > and when > the extend_page_bitmap() failed to allocate more memory for the bitmap. Or > dozens of > 32k split bitmap will be used, this version limit the bitmap count to 32, it > means we can use > at most 32*32 kB for the bitmap, which can cover 128GB for RAM. We can > increase the bitmap > count limit to a larger value if 32 is not big enough. OK, so it tries to allocate a large bitmap. But, if it fails, it will try to work with a smaller bitmap. Correct? So, what's the _worst_ case? It sounds like it is even worse than I was positing. >> That's an awfully inefficient way of doing it. This patch essentially >> changed >> the data structure without changing the algorithm to populate it. >> >> Please change the *algorithm* to use the new data structure efficiently. >> Such a change would only do a single pass through each freelist, and would >> choose whether to use the extent-based (pfn -> range) or bitmap-based >> approach based on the contents of the free lists. > > Save the free page info to a raw bitmap first and then process the raw bitmap > to > get the proper ' extent-based ' and 'bitmap-based' is the most efficient way > I can > come up with to save the virtio data transmission. Do you have some better > idea? That's kinda my point. This patch *does* processing to try to pack the bitmaps full of pages from the various pfn ranges. It's a form of processing that gets *REALLY*, *REALLY* bad in some (admittedly obscure) cases. Let's not pretend that making an essentially unlimited number of passes over the free lists is not processing. 1. Allocate as large of a bitmap as you can. (what you already do) 2. Iterate from the largest freelist order. Store those pages in the bitmap. 3. If you can no longer fit pages in the bitmap, return the list that you have. 4. Make an approximation about where the bitmap does not make any more, and fall back to listing individual PFNs. This would make sens, for instance in a large zone with very few free order-0 pages left. > It seems the benefit we get for this feature is not as big as that in fast > balloon inflating/deflating. >> >> You should not be using get_max_pfn(). Any patch set that continues to use >> it is not likely to be using a proper algorithm. > > Do you have any suggestion about how to avoid it? Yes: get the pfns from the page free lists alone. Don't derive them from the pfn limits of the system or zones.
