[PATCH 3.18 01/52] sparc32: Fix inverted invalid_frame_pointer checks on sigreturns

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Andreas Larsson 

commit 07b5ab3f71d318e52c18cc3b73c1d44c908aacfa upstream.

Signed-off-by: Andreas Larsson 
Signed-off-by: David S. Miller 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/sparc/kernel/signal_32.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/sparc/kernel/signal_32.c
+++ b/arch/sparc/kernel/signal_32.c
@@ -89,7 +89,7 @@ asmlinkage void do_sigreturn(struct pt_r
sf = (struct signal_frame __user *) regs->u_regs[UREG_FP];
 
/* 1. Make sure we are not getting garbage from the user */
-   if (!invalid_frame_pointer(sf, sizeof(*sf)))
+   if (invalid_frame_pointer(sf, sizeof(*sf)))
goto segv_and_exit;
 
if (get_user(ufp, >info.si_regs.u_regs[UREG_FP]))
@@ -150,7 +150,7 @@ asmlinkage void do_rt_sigreturn(struct p
 
synchronize_user_stack();
sf = (struct rt_signal_frame __user *) regs->u_regs[UREG_FP];
-   if (!invalid_frame_pointer(sf, sizeof(*sf)))
+   if (invalid_frame_pointer(sf, sizeof(*sf)))
goto segv;
 
if (get_user(ufp, >regs.u_regs[UREG_FP]))

[PATCH 3.18 13/52] can: gw: ensure DLC boundaries after CAN frame modification

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Oliver Hartkopp 

commit 0aaa81377c5a01f686bcdb8c7a6929a7bf330c68 upstream.

Muyu Yu provided a POC where user root with CAP_NET_ADMIN can create a CAN
frame modification rule that makes the data length code a higher value than
the available CAN frame data size. In combination with a configured checksum
calculation where the result is stored relatively to the end of the data
(e.g. cgw_csum_xor_rel) the tail of the skb (e.g. frag_list pointer in
skb_shared_info) can be rewritten which finally can cause a system crash.

Michael Kubecek suggested to drop frames that have a DLC exceeding the
available space after the modification process and provided a patch that can
handle CAN FD frames too. Within this patch we also limit the length for the
checksum calculations to the maximum of Classic CAN data length (8).

CAN frames that are dropped by these additional checks are counted with the
CGW_DELETED counter which indicates misconfigurations in can-gw rules.

This fixes CVE-2019-3701.

Reported-by: Muyu Yu 
Reported-by: Marcus Meissner 
Suggested-by: Michal Kubecek 
Tested-by: Muyu Yu 
Tested-by: Oliver Hartkopp 
Signed-off-by: Oliver Hartkopp 
Cc: linux-stable  # >= v3.2
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 

---
 net/can/gw.c |   30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -417,13 +417,29 @@ static void can_can_gw_rcv(struct sk_buf
while (modidx < MAX_MODFUNCTIONS && gwj->mod.modfunc[modidx])
(*gwj->mod.modfunc[modidx++])(cf, >mod);
 
-   /* check for checksum updates when the CAN frame has been modified */
+   /* Has the CAN frame been modified? */
if (modidx) {
-   if (gwj->mod.csumfunc.crc8)
+   /* get available space for the processed CAN frame type */
+   int max_len = nskb->len - offsetof(struct can_frame, data);
+
+   /* dlc may have changed, make sure it fits to the CAN frame */
+   if (cf->can_dlc > max_len)
+   goto out_delete;
+
+   /* check for checksum updates in classic CAN length only */
+   if (gwj->mod.csumfunc.crc8) {
+   if (cf->can_dlc > 8)
+   goto out_delete;
+
(*gwj->mod.csumfunc.crc8)(cf, >mod.csum.crc8);
+   }
+
+   if (gwj->mod.csumfunc.xor) {
+   if (cf->can_dlc > 8)
+   goto out_delete;
 
-   if (gwj->mod.csumfunc.xor)
(*gwj->mod.csumfunc.xor)(cf, >mod.csum.xor);
+   }
}
 
/* clear the skb timestamp if not configured the other way */
@@ -435,6 +451,14 @@ static void can_can_gw_rcv(struct sk_buf
gwj->dropped_frames++;
else
gwj->handled_frames++;
+
+   return;
+
+ out_delete:
+   /* delete frame due to misconfiguration */
+   gwj->deleted_frames++;
+   kfree_skb(nskb);
+   return;
 }
 
 static inline int cgw_register_filter(struct cgw_job *gwj)

[PATCH 3.18 14/52] media: em28xx: Fix misplaced reset of dev->v4l::field_count

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Hutchings 

The backport of commit afeaade90db4 "media: em28xx: make
v4l2-compliance happier by starting sequence on zero" added a
reset on em28xx_v4l2::field_count to em28xx_ctrl_notify(),
but it should be done in em28xx_start_analog_streaming().

Signed-off-by: Ben Hutchings 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/em28xx/em28xx-video.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -931,6 +931,8 @@ int em28xx_start_analog_streaming(struct
 
em28xx_videodbg("%s\n", __func__);
 
+   dev->v4l2->field_count = 0;
+
/* Make sure streaming is not already in progress for this type
   of filehandle (e.g. video, vbi) */
rc = res_get(dev, vq->type);
@@ -1141,8 +1143,6 @@ static void em28xx_ctrl_notify(struct v4
 {
struct em28xx *dev = priv;
 
-   dev->v4l2->field_count = 0;
-
/*
 * In the case of non-AC97 volume controls, we still need
 * to do some setups at em28xx, in order to mute/unmute

[PATCH 3.18 10/52] crypto: cts - fix crash on short inputs

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--


From: Eric Biggers 

[It's a minimal fix for a bug that was fixed incidentally by a large
refactoring in v4.8.]

In the CTS template, when the input length is <= one block cipher block
(e.g. <= 16 bytes for AES) pass the correct length to the underlying CBC
transform rather than one block.  This matches the upstream behavior and
makes the encryption/decryption operation correctly return -EINVAL when
1 <= nbytes < bsize or succeed when nbytes == 0, rather than crashing.

This was fixed upstream incidentally by a large refactoring,
commit 0605c41cc53c ("crypto: cts - Convert to skcipher").  But
syzkaller easily trips over this when running on older kernels, as it's
easily reachable via AF_ALG.  Therefore, this patch makes the minimal
fix for older kernels.

Cc: linux-cry...@vger.kernel.org
Fixes: 76cb9521795a ("[CRYPTO] cts: Add CTS mode required for Kerberos AES 
support")
Signed-off-by: Eric Biggers 
Signed-off-by: Greg Kroah-Hartman 
---
 crypto/cts.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -137,8 +137,8 @@ static int crypto_cts_encrypt(struct blk
lcldesc.info = desc->info;
lcldesc.flags = desc->flags;
 
-   if (tot_blocks == 1) {
-   err = crypto_blkcipher_encrypt_iv(, dst, src, bsize);
+   if (tot_blocks <= 1) {
+   err = crypto_blkcipher_encrypt_iv(, dst, src, nbytes);
} else if (nbytes <= bsize * 2) {
err = cts_cbc_encrypt(ctx, desc, dst, src, 0, nbytes);
} else {
@@ -232,8 +232,8 @@ static int crypto_cts_decrypt(struct blk
lcldesc.info = desc->info;
lcldesc.flags = desc->flags;
 
-   if (tot_blocks == 1) {
-   err = crypto_blkcipher_decrypt_iv(, dst, src, bsize);
+   if (tot_blocks <= 1) {
+   err = crypto_blkcipher_decrypt_iv(, dst, src, nbytes);
} else if (nbytes <= bsize * 2) {
err = cts_cbc_decrypt(ctx, desc, dst, src, 0, nbytes);
} else {

[PATCH 3.18 15/52] ipv6: fix kernel-infoleak in ipv6_local_error()

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric Dumazet 

[ Upstream commit 7d033c9f6a7fd3821af75620a0257db87c2b552a ]

This patch makes sure the flow label in the IPv6 header
forged in ipv6_local_error() is initialized.

BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
CPU: 1 PID: 24675 Comm: syz-executor1 Not tainted 4.20.0-rc7+ #4
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x173/0x1d0 lib/dump_stack.c:113
 kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
 kmsan_internal_check_memory+0x455/0xb00 mm/kmsan/kmsan.c:675
 kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
 _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
 copy_to_user include/linux/uaccess.h:177 [inline]
 move_addr_to_user+0x2e9/0x4f0 net/socket.c:227
 ___sys_recvmsg+0x5d7/0x1140 net/socket.c:2284
 __sys_recvmsg net/socket.c:2327 [inline]
 __do_sys_recvmsg net/socket.c:2337 [inline]
 __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
 __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
 entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x457ec9
Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f8750c06c78 EFLAGS: 0246 ORIG_RAX: 002f
RAX: ffda RBX: 0003 RCX: 00457ec9
RDX: 2000 RSI: 2400 RDI: 0005
RBP: 0073bf00 R08:  R09: 
R10:  R11: 0246 R12: 7f8750c076d4
R13: 004c4a60 R14: 004d8140 R15: 

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
 kmsan_save_stack mm/kmsan/kmsan.c:219 [inline]
 kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:439
 __msan_chain_origin+0x70/0xe0 mm/kmsan/kmsan_instr.c:200
 ipv6_recv_error+0x1e3f/0x1eb0 net/ipv6/datagram.c:475
 udpv6_recvmsg+0x398/0x2ab0 net/ipv6/udp.c:335
 inet_recvmsg+0x4fb/0x600 net/ipv4/af_inet.c:830
 sock_recvmsg_nosec net/socket.c:794 [inline]
 sock_recvmsg+0x1d1/0x230 net/socket.c:801
 ___sys_recvmsg+0x4d5/0x1140 net/socket.c:2278
 __sys_recvmsg net/socket.c:2327 [inline]
 __do_sys_recvmsg net/socket.c:2337 [inline]
 __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
 __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
 entry_SYSCALL_64_after_hwframe+0x63/0xe7

Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:204 [inline]
 kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:158
 kmsan_kmalloc+0xa6/0x130 mm/kmsan/kmsan_hooks.c:176
 kmsan_slab_alloc+0xe/0x10 mm/kmsan/kmsan_hooks.c:185
 slab_post_alloc_hook mm/slab.h:446 [inline]
 slab_alloc_node mm/slub.c:2759 [inline]
 __kmalloc_node_track_caller+0xe18/0x1030 mm/slub.c:4383
 __kmalloc_reserve net/core/skbuff.c:137 [inline]
 __alloc_skb+0x309/0xa20 net/core/skbuff.c:205
 alloc_skb include/linux/skbuff.h:998 [inline]
 ipv6_local_error+0x1a7/0x9e0 net/ipv6/datagram.c:334
 __ip6_append_data+0x129f/0x4fd0 net/ipv6/ip6_output.c:1311
 ip6_make_skb+0x6cc/0xcf0 net/ipv6/ip6_output.c:1775
 udpv6_sendmsg+0x3f8e/0x45d0 net/ipv6/udp.c:1384
 inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:621 [inline]
 sock_sendmsg net/socket.c:631 [inline]
 __sys_sendto+0x8c4/0xac0 net/socket.c:1788
 __do_sys_sendto net/socket.c:1800 [inline]
 __se_sys_sendto+0x107/0x130 net/socket.c:1796
 __x64_sys_sendto+0x6e/0x90 net/socket.c:1796
 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
 entry_SYSCALL_64_after_hwframe+0x63/0xe7

Bytes 4-7 of 28 are uninitialized
Memory access of size 28 starts at 8881937bfce0
Data copied to user address 2000

Signed-off-by: Eric Dumazet 
Reported-by: syzbot 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/datagram.c |1 +
 1 file changed, 1 insertion(+)

--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -287,6 +287,7 @@ void ipv6_local_error(struct sock *sk, i
skb_reset_network_header(skb);
iph = ipv6_hdr(skb);
iph->daddr = fl6->daddr;
+   ip6_flow_hdr(iph, 0, 0);
 
serr = SKB_EXT_ERR(skb);
serr->ee.ee_errno = err;

Re: [PATCH] clk: imx: Fix fractional clock set rate computation

[Stephen Boyd]

Quoting Abel Vesa (2019-01-18 04:54:13)
> Before multiplying by PLL_FRAC_DENOM, the temp64 needs to be
>  temp64 = rate * 2 - divfi * parent_rate * 8, instead of:
>  temp64 = (rate * 2 - divfi) * parent_rate
> 
> Fixes: 6209624b9a5c1e ("clk: imx: Add fractional PLL output clock")
> Signed-off-by: Abel Vesa 
> ---

Applied to clk-fixes

Re: [PATCH] clk: Remove global clk traversal on fetch parent index

[Stephen Boyd]

Quoting Derek Basehore (2018-12-20 16:31:00)
> It's not required to traverse the entire clk tree when the parents
> array contains a NULL value. You already have the parent clk_core
> pointer, so you can just compare the parent->name and parent_names[i]
> pointers.
> 
> In cases where clk names are never registered, this can be
> a substantial power improvement since a mux having an unregistered
> parent name will traverse the clk tree on every set_rate. This can
> happen hundreds of times a second on CPU clks.
> 
> Change-Id: I85499d2e576249568ff508e424ca8d5009e6e2b1
> Signed-off-by: Derek Basehore 
> ---

Applied to clk-fixes + some commit text and comment updates.

Re: [for next][PATCH 1/2] platform/x86: Fix unmet dependency warning for ACPI_CMPC

[Andy Shevchenko]

On Thu, Jan 24, 2019 at 12:54 PM Rafael J. Wysocki  wrote:
>
> On Monday, January 21, 2019 11:46:43 PM CET Sinan Kaya wrote:
> > Add BACKLIGHT_LCD_SUPPORT for ACPI_CMPC to fix the
> > warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
> >
> > ACPI_CMPC selects BACKLIGHT_LCD_SUPPORT but BACKLIGHT_LCD_SUPPORT
> > depends on BACKLIGHT_LCD_SUPPORT.
> >
> > Copy this dependency into ACPI_CMPC.

> Andy/Darren, these two seem to be for you, but I can take them too as
> related to ACPI tagentially, so please let me know.

Answered to v2. One comment still to be addressed, otherwise feel free
to take them.

-- 
With Best Regards,
Andy Shevchenko

Re: [for next][PATCH v2 2/2] platform/x86: Fix unmet dependency warning for SAMSUNG_Q10

[Andy Shevchenko]

On Thu, Jan 24, 2019 at 7:57 PM Sinan Kaya  wrote:
>
> Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the
> warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
>
> SAMSUNG_Q10 selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
> depends on BACKLIGHT_LCD_SUPPORT.
>
> Copy BACKLIGHT_LCD_SUPPORT dependency into SAMSUNG_Q10 to fix:
>
> WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
>   Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
>   Selected by [y]:
>   - SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]

Thanks for the fix.
One comment below though.

>  config SAMSUNG_Q10
> tristate "Samsung Q10 Extras"
> -   depends on ACPI

> +   depends on ACPI && BACKLIGHT_LCD_SUPPORT

I would like rather see it on a separate line in both patches.

Rafael, you may take it if it feels comfortable.

> select BACKLIGHT_CLASS_DEVICE
> ---help---
>   This driver provides support for backlight control on Samsung Q10
> --
> 2.19.0
>


-- 
With Best Regards,
Andy Shevchenko

RE: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain

[Stefano Stabellini]

On Thu, 24 Jan 2019, Peng Fan wrote:
> Hi stefano,
> 
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 2019年1月24日 7:44
> > To: h...@infradead.org
> > Cc: Stefano Stabellini ; Peng Fan
> > ; m...@redhat.com; jasow...@redhat.com;
> > xen-de...@lists.xenproject.org; linux-remotep...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; virtualizat...@lists.linux-foundation.org;
> > l...@kernel.org; jgr...@suse.com; boris.ostrov...@oracle.com;
> > bjorn.anders...@linaro.org; jli...@xilinx.com
> > Subject: Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain
> > 
> > On Wed, 23 Jan 2019, h...@infradead.org wrote:
> > > On Wed, Jan 23, 2019 at 01:04:33PM -0800, Stefano Stabellini wrote:
> > > > If vring_use_dma_api is actually supposed to return true when
> > > > dma_dev->dma_mem is set, then both Peng's patch and the patch I
> > > > wrote are not fixing the real issue here.
> > > >
> > > > I don't know enough about remoteproc to know where the problem
> > > > actually lies though.
> > >
> > > The problem is the following:
> > >
> > > Devices can declare a specific memory region that they want to use
> > > when the driver calls dma_alloc_coherent for the device, this is done
> > > using the shared-dma-pool DT attribute, which comes in two variants
> > > that would be a little to much to explain here.
> > >
> > > remoteproc makes use of that because apparently the device can only
> > > communicate using that region.  But it then feeds back memory obtained
> > > with dma_alloc_coherent into the virtio code.  For that it calls
> > > vmalloc_to_page on the dma_alloc_coherent, which is a huge no-go for
> > > the ĐMA API and only worked accidentally on a few platform, and
> > > apparently arm64 just changed a few internals that made it stop
> > > working for remoteproc.
> > >
> > > The right answer is to not use the DMA API to allocate memory from a
> > > device-speficic region, but to tie the driver directly into the DT
> > > reserved memory API in a way that allows it to easilt obtain a struct
> > > device for it.
> > 
> > If I understand correctly, Peng should be able to reproduce the problem on
> > native Linux without any Xen involvement simply by forcing
> > vring_use_dma_api to return true. Peng, can you confirm?
> 
> It is another issue without xen involvement, 
> There is an thread talking this: https://patchwork.kernel.org/patch/10742923/
> 
> Without xen, vring_use_dma_api will return false.
> With xen, if vring_use_dma_api returns true, it will dma_map_xx and trigger 
> dump.

It is true that for Xen on ARM DomUs it is not necessary today to return
true from vring_use_dma_api. However, returning true from
vring_use_dma_api should not break Linux. When the rpmesg issue is
fixed, this problem should also go away without any need for additional
changes on the xen side I think.

Re: [PATCH stable-4.9.y] locking/qspinlock: Pull in asm/byteorder.h to ensure correct endianness

[David Airlie]

On Fri, Jan 25, 2019 at 5:04 AM Greg KH  wrote:
>
> On Thu, Jan 24, 2019 at 06:54:15PM +, Will Deacon wrote:
> > From: Dave Airlie 
> >
> > This commit is not required upstream, but is required for the 4.9.y
> > stable series.
> >
> > Upstream commit 101110f6271c ("Kbuild: always define endianess in
> > kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is
> > defined to reflect the endianness of the target CPU architecture
> > regardless of whether or not  has been #included. The
> > upstream definition of 'struct qspinlock' relies on this property.
> >
> > Unfortunately, the 4.9.y stable series does not provide this guarantee,
> > so the 'spin_unlock()' routine can erroneously treat the underlying
> > lockword as big-endian on little-endian architectures using native
> > qspinlock (i.e. x86_64 without PV) if the caller has not included
> > . This can lead to hangs such as the one in
> > 'i915_gem_request()' reported via bugzilla:
> >
> >   https://bugzilla.kernel.org/show_bug.cgi?id=202063
> >
> > Fix the issue by ensuring that  is #included in
> > , where 'struct qspinlock' is defined.
>
> That is crazy...

You've no idea, we've spent a couple of days at LCA figuring it all out :-)

Dave.

Re: [PATCH] ALSA: hda: runtime PM is always active

[Takashi Iwai]

On Thu, 24 Jan 2019 20:01:13 +0100,
Sameer Pujar wrote:
> 
> 
> On 1/25/2019 12:13 AM, Takashi Iwai wrote:
> > On Thu, 24 Jan 2019 19:15:12 +0100,
> > Sameer Pujar wrote:
> >>
> >> On 1/24/2019 9:34 PM, Takashi Iwai wrote:
> >>> On Thu, 24 Jan 2019 16:57:11 +0100,
> >>> Sameer Pujar wrote:
>  The runtime PM count is incremented and set to active during hda codec
>  device init, but it is decremented and set to suspend during exit only.
>  Hence the runtime PM status is always active and hda device cannot be
>  put to runtime suspend. Keeping device usage active for entire period,
>  though nothing really happening on the device, seems unnecessary.
> 
>  This patch avoides incrementing runtime PM usage count of the device.
> 
>  Signed-off-by: Sameer Pujar 
>  Reviewed-by: Ravindra Lokhande 
>  Reviewed-by: Mohan Kumar D 
> >>> This breaks the existing things, I'm afraid.
> >>> Did you really test and verify the behavior...?
> >>>
> >>> The runtime PM refcount is decremented at snd_hda_codec_register(),
> >>> and that's the place to let runtime suspend of the codec really
> >>> effective.  (It's not about the controller, though.)
> >>>
> >> It worked fine at my end. I could put the device to runtime suspend
> >> and resume it back multiple times.
> >> Since you are suggesting it could break things, let me rework on the
> >> patch and dig up a little more to
> >> see if there is better way to fix this.
> > Well, I don't see what you want to "fix".  Do you see any bug?
> I was expecting the device to be runtime suspended, once probe is
> finished, until I playback something on it.
> But it appears that rutntime PM is always active and runtime PM
> suspend callback never happens.

Does the behavior really appear?  If so, it's a bug.

The current design is to enable the runtime PM *after* the device
registration.  Otherwise it makes no sense -- the problem doesn't
finish yet before that point.


thanks,

Takashi

Re: Nested KVM is broken on a AMD Ryzen 5 2400G

[Diego Viola]

Hi Joerg,

On Thu, Jan 24, 2019 at 6:42 AM Joerg Roedel  wrote:
>
> Hi Diego,
>
> thanks for the report!

You're welcome, many thanks for your quick reply.

>
> On Thu, Jan 24, 2019 at 01:57:31AM -0200, Diego Viola wrote:
> > [10499.577192] WARNING: CPU: 2 PID: 3487 at arch/x86/kvm/mmu.c:2066
> > nonpaging_update_pte+0x5/0x10 [kvm]
>
> Seems like the nested-paging emulation got broken somewhere in the past.
> Can you try to load the KVM module in the guest with 'npt=0' and see if
> it works then?

I tried this and snapcraft is still timing out on the guest:

diego@diego-Standard-PC-i440FX-PIIX-1996:~/mysnaps/hello$ snapcraft
Launching a VM.
start failed: timed out waiting for instance to respond
Stopping snapcraft-my-snap-name /^C
Aborted!
diego@diego-Standard-PC-i440FX-PIIX-1996:~/mysnaps/hello$

That said, I no longer see the dmesg stack trace on the host. Should I
try a more recent kernel on the guest?

>
> Thanks,
>
> Joerg

Regards,
Diego

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

[Dave Hansen]

On 1/24/19 6:17 AM, Michal Hocko wrote:
> and nr_cpus set to 4. The underlying reason is tha the device is bound
> to node 2 which doesn't have any memory and init_cpu_to_node only
> initializes memory-less nodes for possible cpus which nr_cpus restrics.
> This in turn means that proper zonelists are not allocated and the page
> allocator blows up.

This looks OK to me.

Could we add a few DEBUG_VM checks that *look* for these invalid
zonelists?  Or, would our existing list debugging have caught this?

Basically, is this bug also a sign that we need better debugging around
this?

Re: [PATCH] ALSA: hda/tegra: enable clock during probe

[Takashi Iwai]

On Thu, 24 Jan 2019 18:36:43 +0100,
Sameer Pujar wrote:
> 
> If CONFIG_PM is disabled or runtime PM calls are forbidden, the clocks
> will not be ON. This could cause issue during probe, where hda init
> setup is done. This patch checks whether runtime PM is enabled or not.
> If disabled, clocks are enabled in probe() and disabled in remove()
> 
> This patch does following minor changes as cleanup,
>   * return code check for pm_runtime_get_sync() to take care of failure
> and exit gracefully.
>   * In remove path runtime PM is disabled before calling snd_card_free().
>   * hda_tegra_disable_clocks() is moved out of CONFIG_PM_SLEEP check.
>   * runtime PM callbacks moved out of CONFIG_PM check
> 
> Signed-off-by: Sameer Pujar 
> Reviewed-by: Ravindra Lokhande 
> Reviewed-by: Jon Hunter 
(snip)
> @@ -555,6 +553,13 @@ static int hda_tegra_probe(struct platform_device *pdev)
>   if (!azx_has_pm_runtime(chip))
>   pm_runtime_forbid(hda->dev);
>  
> + /* explicit resume if runtime PM is disabled */
> + if (!pm_runtime_enabled(hda->dev)) {
> + err = hda_tegra_runtime_resume(hda->dev);
> + if (err)
> + goto out_free;
> + }
> +
>   schedule_work(>probe_work);

Calling runtime_resume here is really confusing...


> @@ -571,7 +576,14 @@ static void hda_tegra_probe_work(struct work_struct 
> *work)
>   struct platform_device *pdev = to_platform_device(hda->dev);
>   int err;
>  
> - pm_runtime_get_sync(hda->dev);
> + err = pm_runtime_get_sync(hda->dev);
> + if (err < 0) {
> + dev_err(hda->dev,
> + "failed in pm_runtime_get_syc with err = %d\n",
> + err);
> + return;
> + }

This pm_runtime_get_sync() is needed just because you enabled runtime
PM before probe_work.  Why not deferring the runtime PM enablement
after probing done?

That is what we need is the hda_tegra_enable_clocks() call at probe
unconditionally before enabling runtime PM.

>   err = hda_tegra_first_init(chip, pdev);
>   if (err < 0)
>   goto out_free;
> @@ -599,12 +611,13 @@ static void hda_tegra_probe_work(struct work_struct 
> *work)
>  
>  static int hda_tegra_remove(struct platform_device *pdev)
>  {
> - int ret;
> -
> - ret = snd_card_free(dev_get_drvdata(>dev));
>   pm_runtime_disable(>dev);
> + if (!pm_runtime_status_suspended(>dev)) {
> + hda_tegra_runtime_suspend(>dev);
> + pm_runtime_set_suspended(>dev);
> + }
> - return ret;
> + return snd_card_free(dev_get_drvdata(>dev));


Forcing the suspend *before* snd_card_free() doesn't sound right.
It's the point before the disconnect and release procedure of all the
rest.  That is, the other hardware components are still active at this
point.


thanks,

Takashi

Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component

[Pierre-Louis Bossart]

changes are legitimate. To move forward, maybe it's not worth spending too
much time on a grand unification of string theory, there are simpler
solutions: the Intel machine drivers already do get the platform driver name
as an platform_data argument, so we could modify the dailinks platform names
before even registering the card. I tested with the attached

Yes, that would be much better - it's vastly more idiomatic.  The
general idea is that a machine driver should know what it's expecting to
find before it starts probing.


Thanks for the feedback, will send a formal patch with the helper and 
machine driver changes after I test more with the legacy drivers. Do you 
have a preference for one patch that deals with multiple machines 
drivers in one shot, or individual patches? The latter are nicer for 
backports (e.g. for Chrome), the former nicer for maintainers...


The goal of reusing machine drivers as is isn't really achievable 
anyways, it looks like we are going to have additional changes, e.g. if 
we want to avoid the calls to snd_pcm_suspend as suggested by Takashi, 
we'll have to add a reference to snd_soc_pm_ops that's only used for 
SOF, the Atom/SST driver does things in different ways mostly due to 
historical reasons.


-Pierre

Re: [PATCH stable-4.9.y] locking/qspinlock: Pull in asm/byteorder.h to ensure correct endianness

[Greg KH]

On Thu, Jan 24, 2019 at 06:54:15PM +, Will Deacon wrote:
> From: Dave Airlie 
> 
> This commit is not required upstream, but is required for the 4.9.y
> stable series.
> 
> Upstream commit 101110f6271c ("Kbuild: always define endianess in
> kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is
> defined to reflect the endianness of the target CPU architecture
> regardless of whether or not  has been #included. The
> upstream definition of 'struct qspinlock' relies on this property.
> 
> Unfortunately, the 4.9.y stable series does not provide this guarantee,
> so the 'spin_unlock()' routine can erroneously treat the underlying
> lockword as big-endian on little-endian architectures using native
> qspinlock (i.e. x86_64 without PV) if the caller has not included
> . This can lead to hangs such as the one in
> 'i915_gem_request()' reported via bugzilla:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=202063
> 
> Fix the issue by ensuring that  is #included in
> , where 'struct qspinlock' is defined.

That is crazy...

Thanks for the patch, now queued up.

greg k-h

Re: [PATCH] ALSA: hda: runtime PM is always active

[Sameer Pujar]

On 1/25/2019 12:13 AM, Takashi Iwai wrote:

On Thu, 24 Jan 2019 19:15:12 +0100,
Sameer Pujar wrote:


On 1/24/2019 9:34 PM, Takashi Iwai wrote:

On Thu, 24 Jan 2019 16:57:11 +0100,
Sameer Pujar wrote:

The runtime PM count is incremented and set to active during hda codec
device init, but it is decremented and set to suspend during exit only.
Hence the runtime PM status is always active and hda device cannot be
put to runtime suspend. Keeping device usage active for entire period,
though nothing really happening on the device, seems unnecessary.

This patch avoides incrementing runtime PM usage count of the device.

Signed-off-by: Sameer Pujar 
Reviewed-by: Ravindra Lokhande 
Reviewed-by: Mohan Kumar D 

This breaks the existing things, I'm afraid.
Did you really test and verify the behavior...?

The runtime PM refcount is decremented at snd_hda_codec_register(),
and that's the place to let runtime suspend of the codec really
effective.  (It's not about the controller, though.)


It worked fine at my end. I could put the device to runtime suspend
and resume it back multiple times.
Since you are suggesting it could break things, let me rework on the
patch and dig up a little more to
see if there is better way to fix this.

Well, I don't see what you want to "fix".  Do you see any bug?
I was expecting the device to be runtime suspended, once probe is 
finished, until I playback something on it.
But it appears that rutntime PM is always active and runtime PM suspend 
callback never happens.

thanks,

Takashi


Thanks,
Sameer.


thanks,

Takashi



---
   sound/hda/hdac_device.c | 6 --
   1 file changed, 6 deletions(-)

diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c
index 95b073e..72aa342 100644
--- a/sound/hda/hdac_device.c
+++ b/sound/hda/hdac_device.c
@@ -31,9 +31,6 @@ static void default_release(struct device *dev)
*
* Returns zero for success or a negative error code.
*
- * This function increments the runtime PM counter and marks it active.
- * The caller needs to turn it off appropriately later.
- *
* The caller needs to set the device's release op properly by itself.
*/
   int snd_hdac_device_init(struct hdac_device *codec, struct hdac_bus *bus,
@@ -55,8 +52,6 @@ int snd_hdac_device_init(struct hdac_device *codec, struct 
hdac_bus *bus,
codec->bus = bus;
codec->addr = addr;
codec->type = HDA_DEV_CORE;
-   pm_runtime_set_active(>dev);
-   pm_runtime_get_noresume(>dev);
atomic_set(>in_pm, 0);
err = snd_hdac_bus_add_device(bus, codec);
@@ -123,7 +118,6 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_init);
*/
   void snd_hdac_device_exit(struct hdac_device *codec)
   {
-   pm_runtime_put_noidle(>dev);
snd_hdac_bus_remove_device(codec->bus, codec);
kfree(codec->vendor_name);
kfree(codec->chip_name);
--
2.7.4

int_sqrt() adjustments

[Florian La Roche]

__fls() is returning an unsigned long, but fls() and fls64() are
both returning a (signed) int.
As we need a signed int as right operand of "<<" (as Linus pointed out),
change __fls() to fls() for 32bit and also adjust masking the lowest bit
to be a signed int.
Now the 32bit and the 64bit version are again similar.

best regards,

Florian La Roche



Signed-off-by: Florian La Roche 
---
 lib/int_sqrt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/int_sqrt.c b/lib/int_sqrt.c
index 30e0f9770f88..66eb93105812 100644
--- a/lib/int_sqrt.c
+++ b/lib/int_sqrt.c
@@ -23,7 +23,7 @@ unsigned long int_sqrt(unsigned long x)
if (x <= 1)
return x;
 
-   m = 1UL << (__fls(x) & ~1UL);
+   m = 1UL << ((fls(x) - 1) & ~1);
while (m != 0) {
b = y + m;
y >>= 1;
@@ -52,7 +52,7 @@ u32 int_sqrt64(u64 x)
if (x <= ULONG_MAX)
return int_sqrt((unsigned long) x);
 
-   m = 1ULL << ((fls64(x) - 1) & ~1ULL);
+   m = 1ULL << ((fls64(x) - 1) & ~1);
while (m != 0) {
b = y + m;
y >>= 1;
-- 
2.17.1

Re: [PATCH 1/3] media: dt: bindings: sunxi-ir: Add A64 compatible

[Jernej Škrabec]

Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a):
> On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard  
wrote:
> > Hi,
> > 
> > I'm a bit late to the party, sorry for that.
> > 
> > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote:
> > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec  
wrote:
> > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > > > fallback.
> > > 
> > > We ask people to add the SoC-specific compatible as a contigency,
> > > in case things turn out to be not so "compatible".
> > > 
> > > To be consistent with all the other SoCs and other peripherals,
> > > unless you already spotted a "compatible" difference in the
> > > hardware, i.e. the hardware isn't completely the same, this
> > > patch isn't needed. On the other hand, if you did, please mention
> > > the differences in the commit log.
> > 
> > Even if we don't spot things, since we have the stable DT now, if we
> > ever had that compatible in the DT from day 1, it's much easier to
> > deal with.
> > 
> > I'd really like to have that pattern for all the IPs even if we didn't
> > spot any issue, since we can't really say that the datasheet are
> > complete, and one can always make a mistake and overlook something.
> > 
> > I'm fine with this version, and can apply it as is if we all agree.
> 
> I'm OK with having the fallback compatible. I'm just pointing out
> that there are and will be a whole bunch of them, and we don't need
> to document all of them unless we are actually doing something to
> support them.
> 
> On the other hand, the compatible string situation for IR needs a
> bit of cleaning up at the moment. Right now we have sun4i-a10 and
> sun5i-a13. As Jernej pointed out, the A13's register definition is
> different from A64 (or any other SoCs later than sun6i). So we need
> someone with an A10s/A13 device that has IR to test it and see if
> the driver or the manual is wrong, and we'd likely add a compatible
> for the A20.
> 
> Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This
> was lost in A31, and also all of sun8i / sun50i. So we're going to
> need to add an A31 compatible that all later platforms would need
> to switch to.

Actually, A13 also doesn't have IR TX capability. So I still think it's best 
having A13 compatible as a fallback and not A31. Unless A31 was released 
before A13?

Best regards,
Jernej

Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

[Karim Yaghmour]

On 1/23/19 11:37 PM, Daniel Colascione wrote:

While I think there's definitely a place for eBPF as part of the
Android performance toolkit, I think most users will end up using it
through rich front-end performance collection and analysis tools (of
the sort I'm working on) rather than directly as a first-line window
into the operation of the system.


Sure, I don't disagree.


Below this level is probably
something like bpftrace, and below that, raw eBPF and ftrace
manipulation. It's also worth noting that much of the time, system
analysis is retrospection, not inspection (e.g., investigating the
causes of rare and hard-to-reproduce bad behavior), and so iteration
via interactive specification of eBPF programs isn't a practical path
forward. It's still useful, even in this scenario, to be able (as part
of higher-level tools) attach "canned" eBPF programs to the kernel to
extract certain generally-useful bits of information, and in this
capacity, Joel's header module would be useful.


Hmm. Not sure I agree about that. There's no reason I can't use Android 
Studio to "right-click" on a line of code or even a span of code and 
select a "trace this in detail for me" option, where "in detail" could 
mean different things depending on the code that's highlighted. Doing 
I/O calls? Then automatically measure some I/O benchmarks for that 
portion of code. Doing graphics calls? Do the same for the graphics 
stack, etc.



Personally I advocated a more aggressive approach with Joel in private:
just put the darn headers straight into the kernel image, it's the
*only* artifact we're sure will follow the Android device whatever
happens to it (like built-in ftrace).


I was thinking along similar lines. Ordinarily, we make loadable
kernel modules. What we kind of want here is a non-loadable kernel
module --- or a non-loadable section in the kernel image proper. I'm
not familiar with early-stage kernel loader operation: I know it's
possible to crease discardable sections in the kernel image, but can
we create sections that are never slurped into memory in the first
place? If not, maybe loading and immediately discarding the header
section is good enough.


Interesting. Maybe just append it to the image but have it not loaded 
and have a kernel parameter than enables a "/proc/kheaders" driver to 
know where the fetch the appended headers from storage at runtime. There 
would be no RAM loading whatsoever of the headers, just some sort of 
"kheaders=/dev/foobar:offset:size" parameter. If you turn the option on, 
you get a fatter kernel image size to store on permanent storage, but no 
impact on what's loaded at boot time.



Would such a thing really do better than LZMA? LZMA already has very
clever techniques for eliminating long-range redundancies in
compressible text, including redundancies at the sub-byte level. I can
certainly understand the benefit of stripping comments, since removing
comments really does decrease the total amount of information the
compressor has to preserve, but I'm not sure how much the encoding
scheme you propose below would help, since it reminds me of the
encoding scheme that LZMA would discover automatically.


I'm no compression algorithm expert. If you say LZMA would do the 
same/better than what I suggested then I have no reason to contest that. 
My goal is to see the headers as part of the kernel image that's 
distributed on devices so that they don't have to be chased around. I'm 
just trying to make it as palatable as possible.



Whether such craziness makes sense or is adopted or not isn't mine to
chart, but I certainly can't see eBPF reaching the same mass deployment
ftrace has within the Android ecosystem until there's a way to use it
without having to chase kernel headers independently of kernel images.
There are "too many clicks" involved and someone somewhere will drop the
ball if it's not glued to the kernel in some way shape or form. Any
solution that solves this is one I'd love to hear about.


I agree. There definitely needs to be a "just collect a damn trace"
button that works on any device, and for this button to work and
incorporate eBPF, the system needs to be able to describe itself.


I like that: "the system needs to be able to describe itself". True.

Cheers,

--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour

Re: [PATCH 3/3] Revert "dt-bindings: marvell,mmp2: Add clock id for the SP clock"

[Stephen Boyd]

Quoting Lubomir Rintel (2019-01-20 22:22:56)
> It seems that the kernel has no business managing this clock: once the SP
> clock is disabled, it's not sufficient to just enable it in order to bring
> the SP core back up.
> 
> Pretty sure nothing ever used this and it's safe to remove.
> 
> This reverts commit e8a2c779141415105825e65a4715f1130bba61b1.
> 
> Signed-off-by: Lubomir Rintel 
> ---

Applied to clk-fixes

Re: [PATCH 1/3] Revert "Input: olpc_apsp - enable the SP clock"

[Stephen Boyd]

Quoting Dmitry Torokhov (2019-01-23 14:05:45)
> On Mon, Jan 21, 2019 at 07:22:54AM +0100, Lubomir Rintel wrote:
> > Turns out this is not such a great idea. Once the SP clock is disabled,
> > it's not sufficient to just enable in order to bring the SP core back up.
> > 
> > It seems that the kernel has no business managing this clock. Just let
> > the firmware keep it enabled.
> > 
> > This reverts commit ed22cee91a88c47e564478b012fdbcb079653499.
> > 
> > Link: 
> > https://lore.kernel.org/lkml/154783267051.169631.3197836544646625...@swboyd.mtv.corp.google.com/
> > Signed-off-by: Lubomir Rintel 
> 
> OK, as clock folks say it is a bad idea it must be so. Merge though clk
> tree?
> 
> Acked-by: Dmitry Torokhov 
> 

Ok sure. I'll merge them through clk tree. I'll fast track it through
clk-fixes too.

[PATCH stable-4.9.y] locking/qspinlock: Pull in asm/byteorder.h to ensure correct endianness

[Will Deacon]

From: Dave Airlie 

This commit is not required upstream, but is required for the 4.9.y
stable series.

Upstream commit 101110f6271c ("Kbuild: always define endianess in
kconfig.h") ensures that either __LITTLE_ENDIAN or __BIG_ENDIAN is
defined to reflect the endianness of the target CPU architecture
regardless of whether or not  has been #included. The
upstream definition of 'struct qspinlock' relies on this property.

Unfortunately, the 4.9.y stable series does not provide this guarantee,
so the 'spin_unlock()' routine can erroneously treat the underlying
lockword as big-endian on little-endian architectures using native
qspinlock (i.e. x86_64 without PV) if the caller has not included
. This can lead to hangs such as the one in
'i915_gem_request()' reported via bugzilla:

  https://bugzilla.kernel.org/show_bug.cgi?id=202063

Fix the issue by ensuring that  is #included in
, where 'struct qspinlock' is defined.

Cc:  # 4.9
Signed-off-by: Dave Airlie 
[will: wrote commit message]
Signed-off-by: Will Deacon 
---
 include/asm-generic/qspinlock_types.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/asm-generic/qspinlock_types.h 
b/include/asm-generic/qspinlock_types.h
index d10f1e7d6ba8..6503e96710fa 100644
--- a/include/asm-generic/qspinlock_types.h
+++ b/include/asm-generic/qspinlock_types.h
@@ -18,6 +18,8 @@
 #ifndef __ASM_GENERIC_QSPINLOCK_TYPES_H
 #define __ASM_GENERIC_QSPINLOCK_TYPES_H
 
+#include 
+
 /*
  * Including atomic.h with PARAVIRT on will cause compilation errors because
  * of recursive header file incluson via paravirt_types.h. So don't include
-- 
2.17.1

Re: [PATCH 2/3] Revert "clk: mmp2: add SP clock"

[Stephen Boyd]

Quoting Lubomir Rintel (2019-01-20 22:22:55)
> It seems that the kernel has no business managing this clock: once the SP
> clock is disabled, it's not sufficient to just enable in order to bring the
> SP core back up. Just let the firmware keep it enabled and don't expose it
> to drivers.
> 
> This reverts commit fc27c2394d96fd19854b7e2d3f0e60df0d86fc90.
> 
> Link: 
> https://lore.kernel.org/lkml/154783267051.169631.3197836544646625...@swboyd.mtv.corp.google.com/
> Signed-off-by: Lubomir Rintel 
> ---

Applied to clk-fixes

Re: [PATCH 1/3] Revert "Input: olpc_apsp - enable the SP clock"

[Stephen Boyd]

Quoting Lubomir Rintel (2019-01-20 22:22:54)
> Turns out this is not such a great idea. Once the SP clock is disabled,
> it's not sufficient to just enable in order to bring the SP core back up.
> 
> It seems that the kernel has no business managing this clock. Just let
> the firmware keep it enabled.
> 
> This reverts commit ed22cee91a88c47e564478b012fdbcb079653499.
> 
> Link: 
> https://lore.kernel.org/lkml/154783267051.169631.3197836544646625...@swboyd.mtv.corp.google.com/
> Signed-off-by: Lubomir Rintel 
> ---

Applied to clk-fixes

Applied "regulator: bd718x7: Constify regulator_ops" to the regulator tree

[Mark Brown]

The patch

   regulator: bd718x7: Constify regulator_ops

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 704c5c01ce6e0d322e2c9555490b39c41e729383 Mon Sep 17 00:00:00 2001
From: Axel Lin 
Date: Thu, 24 Jan 2019 18:02:08 +0800
Subject: [PATCH] regulator: bd718x7: Constify regulator_ops

Signed-off-by: Axel Lin 
Signed-off-by: Mark Brown 
---
 drivers/regulator/bd718x7-regulator.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/bd718x7-regulator.c 
b/drivers/regulator/bd718x7-regulator.c
index b8dcdc21dc22..ccea133778c8 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -79,7 +79,7 @@ static int bd718xx_set_voltage_sel_pickable_restricted(
return regulator_set_voltage_sel_pickable_regmap(rdev, sel);
 }
 
-static struct regulator_ops bd718xx_pickable_range_ldo_ops = {
+static const struct regulator_ops bd718xx_pickable_range_ldo_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -88,7 +88,7 @@ static struct regulator_ops bd718xx_pickable_range_ldo_ops = {
.get_voltage_sel = regulator_get_voltage_sel_pickable_regmap,
 };
 
-static struct regulator_ops bd718xx_pickable_range_buck_ops = {
+static const struct regulator_ops bd718xx_pickable_range_buck_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -98,7 +98,7 @@ static struct regulator_ops bd718xx_pickable_range_buck_ops = 
{
.set_voltage_time_sel = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops bd718xx_ldo_regulator_ops = {
+static const struct regulator_ops bd718xx_ldo_regulator_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -107,7 +107,7 @@ static struct regulator_ops bd718xx_ldo_regulator_ops = {
.get_voltage_sel = regulator_get_voltage_sel_regmap,
 };
 
-static struct regulator_ops bd718xx_ldo_regulator_nolinear_ops = {
+static const struct regulator_ops bd718xx_ldo_regulator_nolinear_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -116,7 +116,7 @@ static struct regulator_ops 
bd718xx_ldo_regulator_nolinear_ops = {
.get_voltage_sel = regulator_get_voltage_sel_regmap,
 };
 
-static struct regulator_ops bd718xx_buck_regulator_ops = {
+static const struct regulator_ops bd718xx_buck_regulator_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -126,7 +126,7 @@ static struct regulator_ops bd718xx_buck_regulator_ops = {
.set_voltage_time_sel = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops bd718xx_buck_regulator_nolinear_ops = {
+static const struct regulator_ops bd718xx_buck_regulator_nolinear_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -137,7 +137,7 @@ static struct regulator_ops 
bd718xx_buck_regulator_nolinear_ops = {
.set_voltage_time_sel = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops bd718xx_dvs_buck_regulator_ops = {
+static const struct regulator_ops bd718xx_dvs_buck_regulator_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
-- 
2.20.1

Applied "regulator: bd9571mwv: Constify regulator_ops" to the regulator tree

[Mark Brown]

The patch

   regulator: bd9571mwv: Constify regulator_ops

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e109e7111084e2c7be32c0bcc800dde20eeae126 Mon Sep 17 00:00:00 2001
From: Axel Lin 
Date: Thu, 24 Jan 2019 18:02:09 +0800
Subject: [PATCH] regulator: bd9571mwv: Constify regulator_ops

Signed-off-by: Axel Lin 
Signed-off-by: Mark Brown 
---
 drivers/regulator/bd9571mwv-regulator.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/bd9571mwv-regulator.c 
b/drivers/regulator/bd9571mwv-regulator.c
index e12dd1f750f3..e690c2ce5b3c 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -100,7 +100,7 @@ static int bd9571mwv_reg_set_voltage_sel_regmap(struct 
regulator_dev *rdev,
 }
 
 /* Operations permitted on AVS voltage regulator */
-static struct regulator_ops avs_ops = {
+static const struct regulator_ops avs_ops = {
.set_voltage_sel= bd9571mwv_avs_set_voltage_sel_regmap,
.map_voltage= regulator_map_voltage_linear,
.get_voltage_sel= bd9571mwv_avs_get_voltage_sel_regmap,
@@ -108,7 +108,7 @@ static struct regulator_ops avs_ops = {
 };
 
 /* Operations permitted on voltage regulators */
-static struct regulator_ops reg_ops = {
+static const struct regulator_ops reg_ops = {
.set_voltage_sel= bd9571mwv_reg_set_voltage_sel_regmap,
.map_voltage= regulator_map_voltage_linear,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
@@ -116,13 +116,13 @@ static struct regulator_ops reg_ops = {
 };
 
 /* Operations permitted on voltage monitors */
-static struct regulator_ops vid_ops = {
+static const struct regulator_ops vid_ops = {
.map_voltage= regulator_map_voltage_linear,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.list_voltage   = regulator_list_voltage_linear,
 };
 
-static struct regulator_desc regulators[] = {
+static const struct regulator_desc regulators[] = {
BD9571MWV_REG("VD09", "vd09", VD09, avs_ops, 0, 0x7f,
  0x80, 60, 1, 0x3c),
BD9571MWV_REG("VD18", "vd18", VD18, vid_ops, BD9571MWV_VD18_VID, 0xf,
-- 
2.20.1

Re: [PATCH] usb: musb: Fix potential NULL dereference

[Matwey V. Kornilov]

By the way, why do we need to store the qh in urb->hcpriv?
qh can always be accessible through urb->ep->hcpriv
Wouldn't it be better to drop entire urb->hcpriv usage?

ср, 23 янв. 2019 г. в 20:52, Matwey V. Kornilov :
>
> We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is
> hep->hcpriv in this code path.
>
> Fixes: 714bc5ef3eda ("musb: potential use after free")
> Signed-off-by: Matwey V. Kornilov 
> ---
>  drivers/usb/musb/musb_host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index c6118a962d37..6f267716768e 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2336,7 +2336,7 @@ static int musb_urb_enqueue(
>  * odd, rare, error prone, but legal.
>  */
> kfree(qh);
> -   qh = NULL;
> +   qh = hep->hcpriv;
> ret = 0;
> } else
> ret = musb_schedule(musb, qh,
> --
> 2.16.4
>


-- 
With best regards,
Matwey V. Kornilov

Applied "regulator: bd70528: Constify regulator_linear_range and regulator_ops" to the regulator tree

[Mark Brown]

The patch

   regulator: bd70528: Constify regulator_linear_range and regulator_ops

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 08f15f4a348a9e7d3be156126922da8d38731d53 Mon Sep 17 00:00:00 2001
From: Axel Lin 
Date: Thu, 24 Jan 2019 18:02:07 +0800
Subject: [PATCH] regulator: bd70528: Constify regulator_linear_range and
 regulator_ops

Signed-off-by: Axel Lin 
Signed-off-by: Mark Brown 
---
 drivers/regulator/bd70528-regulator.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/bd70528-regulator.c 
b/drivers/regulator/bd70528-regulator.c
index 0cf261c469b9..72c7f9aa84f3 100644
--- a/drivers/regulator/bd70528-regulator.c
+++ b/drivers/regulator/bd70528-regulator.c
@@ -21,22 +21,22 @@
 #define BUCK_RAMPRATE_125MV 1
 #define BUCK_RAMP_MAX 250
 
-static struct regulator_linear_range bd70528_buck1_volts[] = {
+static const struct regulator_linear_range bd70528_buck1_volts[] = {
REGULATOR_LINEAR_RANGE(120, 0x00, 0x1, 60),
REGULATOR_LINEAR_RANGE(275, 0x2, 0xf, 5),
 };
-static struct regulator_linear_range bd70528_buck2_volts[] = {
+static const struct regulator_linear_range bd70528_buck2_volts[] = {
REGULATOR_LINEAR_RANGE(120, 0x00, 0x1, 30),
REGULATOR_LINEAR_RANGE(155, 0x2, 0xd, 5),
REGULATOR_LINEAR_RANGE(300, 0xe, 0xf, 30),
 };
-static struct regulator_linear_range bd70528_buck3_volts[] = {
+static const struct regulator_linear_range bd70528_buck3_volts[] = {
REGULATOR_LINEAR_RANGE(80, 0x00, 0xd, 5),
REGULATOR_LINEAR_RANGE(180, 0xe, 0xf, 0),
 };
 
 /* All LDOs have same voltage ranges */
-static struct regulator_linear_range bd70528_ldo_volts[] = {
+static const struct regulator_linear_range bd70528_ldo_volts[] = {
REGULATOR_LINEAR_RANGE(165, 0x0, 0x07, 5),
REGULATOR_LINEAR_RANGE(210, 0x8, 0x0f, 10),
REGULATOR_LINEAR_RANGE(285, 0x10, 0x19, 5),
@@ -83,7 +83,7 @@ static int bd70528_led_set_voltage_sel(struct regulator_dev 
*rdev,
return -EBUSY;
 }
 
-static struct regulator_ops bd70528_buck_ops = {
+static const struct regulator_ops bd70528_buck_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -94,7 +94,7 @@ static struct regulator_ops bd70528_buck_ops = {
.set_ramp_delay = bd70528_set_ramp_delay,
 };
 
-static struct regulator_ops bd70528_ldo_ops = {
+static const struct regulator_ops bd70528_ldo_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -105,7 +105,7 @@ static struct regulator_ops bd70528_ldo_ops = {
.set_ramp_delay = bd70528_set_ramp_delay,
 };
 
-static struct regulator_ops bd70528_led_ops = {
+static const struct regulator_ops bd70528_led_ops = {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -114,8 +114,7 @@ static struct regulator_ops bd70528_led_ops = {
.get_voltage_sel = regulator_get_voltage_sel_regmap,
 };
 
-
-static struct regulator_desc bd70528_desc[] = {
+static const struct regulator_desc bd70528_desc[] = {
{
.name = "buck1",
.of_match = of_match_ptr("BUCK1"),
-- 
2.20.1

Re: [PATCH][V2] ASoC: Intel: make const arrays static, reduces object code size

[Pierre-Louis Bossart]

On 1/24/19 11:37 AM, Colin King wrote:

From: Colin Ian King 

Don't populate the const arrays on the stack but instead make
it static. Makes the object code smaller, for example:

Before:
textdata bss dec hex filename
   141078832 224   231635a7b bytcht_es8316.o

After:
textdata bss dec hex filename
   140158896 224   231355a5f bytcht_es8316.o

(gcc version 8.2.0 x86_64)

Signed-off-by: Colin Ian King 

Acked-by: Pierre-Louis Bossart 

---

V2: also fix up bytcr_rt5640.c and bytcr_rt5651.c, thanks to
Pierre-Louis Bossart for noticing these two.

---
  sound/soc/intel/boards/bytcht_es8316.c | 2 +-
  sound/soc/intel/boards/bytcr_rt5640.c  | 2 +-
  sound/soc/intel/boards/bytcr_rt5651.c  | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/intel/boards/bytcht_es8316.c 
b/sound/soc/intel/boards/bytcht_es8316.c
index fa9c4cf97686..1364e4e601d8 100644
--- a/sound/soc/intel/boards/bytcht_es8316.c
+++ b/sound/soc/intel/boards/bytcht_es8316.c
@@ -437,7 +437,7 @@ static const struct acpi_gpio_mapping 
byt_cht_es8316_gpios[] = {
  
  static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev)

  {
-   const char * const mic_name[] = { "in1", "in2" };
+   static const char * const mic_name[] = { "in1", "in2" };
struct byt_cht_es8316_private *priv;
struct device *dev = >dev;
struct snd_soc_acpi_mach *mach;
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index ca8b4d5ff70f..a79466c8fb29 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -1149,7 +1149,7 @@ struct acpi_chan_package {   /* ACPICA seems to require 
64 bit integers */
  
  static int snd_byt_rt5640_mc_probe(struct platform_device *pdev)

  {
-   const char * const map_name[] = { "dmic1", "dmic2", "in1", "in3" };
+   static const char * const map_name[] = { "dmic1", "dmic2", "in1", "in3" 
};
const struct dmi_system_id *dmi_id;
struct byt_rt5640_private *priv;
struct snd_soc_acpi_mach *mach;
diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index b618d984e2d5..e6945d11c8ab 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -919,7 +919,7 @@ struct acpi_chan_package {   /* ACPICA seems to require 64 
bit integers */
  
  static int snd_byt_rt5651_mc_probe(struct platform_device *pdev)

  {
-   const char * const mic_name[] = { "dmic", "in1", "in2", "in12" };
+   static const char * const mic_name[] = { "dmic", "in1", "in2", "in12" };
struct byt_rt5651_private *priv;
struct snd_soc_acpi_mach *mach;
struct device *codec_dev;

[ANNOUNCE] 3.18.132-rt112

[Tom Zanussi]

Hello RT Folks!

I'm pleased to announce the 3.18.132-rt112 stable release.

This release is just an update to the new stable 3.18.132 version
and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.18-rt
  Head SHA1: bf9a0c49219adf81c8535351bfc4ae8b0f4e69c6

Or to build 3.18.132-rt112 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.18.132.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.132-rt112.patch.xz


Enjoy!
   
   Tom

Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component

[Mark Brown]

On Tue, Jan 22, 2019 at 08:01:15PM -0600, Pierre-Louis Bossart wrote:

> changes are legitimate. To move forward, maybe it's not worth spending too
> much time on a grand unification of string theory, there are simpler
> solutions: the Intel machine drivers already do get the platform driver name
> as an platform_data argument, so we could modify the dailinks platform names
> before even registering the card. I tested with the attached

Yes, that would be much better - it's vastly more idiomatic.  The
general idea is that a machine driver should know what it's expecting to
find before it starts probing.


signature.asc
Description: PGP signature

[PATCH v4 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Jagan Teki]

Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.

Add panel driver for it.

Signed-off-by: Jagan Teki 
---
Changes for v5:
- rebase on master
- adjust the hporch values to satisfy the refresh
Changes for v4:
- use simple structure for command init
- update proper comments on power, reset delay sequnce
- fix to use set_display_off in disable function
- move mode type to structure
- drop refres rate value, let drm compute
Changes for v2:
- new patch, derived from another dsi series

 MAINTAINERS   |   6 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-feiyang-fy07024di26a30d.c | 286 ++
 4 files changed, 302 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e3f785bad68b..5c8591eb5840 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4831,6 +4831,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tve200/
 
+DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
+M: Jagan Teki 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+F: 
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
+
 DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 151ddf720b83..5304db7b7b55 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -47,6 +47,15 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.
 
+config DRM_PANEL_FEIYANG_FY07024DI26A30D
+   tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Feiyang FY07024DI26A30-D MIPI-DSI interface.
+
 config DRM_PANEL_ILITEK_IL9322
tristate "Ilitek ILI9322 320x240 QVGA panels"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 54db0921f329..c88dacf9d439 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_BANANAPI_S070WV20_ICN6211) += 
panel-bananapi-s070wv20-icn6211.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c 
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
new file mode 100644
index ..f655647aeade
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define FEIYANG_INIT_CMD_LEN   2
+
+struct feiyang {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator*dvdd;
+   struct regulator*avdd;
+   struct gpio_desc*reset;
+};
+
+static inline struct feiyang *panel_to_feiyang(struct drm_panel *panel)
+{
+   return container_of(panel, struct feiyang, panel);
+}
+
+struct feiyang_init_cmd {
+   u8 data[FEIYANG_INIT_CMD_LEN];
+};
+
+static const struct feiyang_init_cmd feiyang_init_cmds[] = {
+   { .data = { 0x80, 0x58 } },
+   { .data = { 0x81, 0x47 } },
+   { .data = { 0x82, 0xD4 } },
+   { .data = { 0x83, 0x88 } },
+   { .data = { 0x84, 0xA9 } },
+   { .data = { 0x85, 0xC3 } },
+   { .data = { 0x86, 0x82 } },
+};
+
+static int feiyang_prepare(struct drm_panel *panel)
+{
+   struct feiyang *ctx = panel_to_feiyang(panel);
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   unsigned int i;
+   int ret;
+
+   ret = regulator_enable(ctx->dvdd);
+   if (ret)
+   return ret;
+
+   /* T1 (dvdd start + dvdd rise) 0 < T1 <= 10ms */
+   msleep(10);
+
+   ret = regulator_enable(ctx->avdd);
+   if (ret)
+   return ret;
+
+   /* T3 (dvdd rise + avdd start + avdd rise) T3 >= 20ms */
+   msleep(20);
+
+   gpiod_set_value(ctx->reset, 1);
+   msleep(50);
+
+   gpiod_set_value(ctx->reset, 0);
+   /* T5 + T6 (avdd rise + video & logic signal rise)
+

[PATCH v4 1/2] dt-bindings: panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel

[Jagan Teki]

Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.

Add dt-bingings for it.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
---
Changes for v4, v3:
- none
Changes for v2:
- new patch, derived from another dsi series

 .../display/panel/feiyang,fy07024di26a30d.txt | 20 +++
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt 
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
new file mode 100644
index ..82caa7b65ae8
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
@@ -0,0 +1,20 @@
+Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
+
+Required properties:
+- compatible: must be "feiyang,fy07024di26a30d"
+- reg: DSI virtual channel used by that screen
+- avdd-supply: analog regulator dc1 switch
+- dvdd-supply: 3v3 digital regulator
+- reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+   compatible = "feiyang,fy07024di26a30d";
+   reg = <0>;
+   avdd-supply = <_dc1sw>;
+   dvdd-supply = <_dldo2>;
+   reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+   backlight = <>;
+};
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH] ALSA: hda: runtime PM is always active

[Takashi Iwai]

On Thu, 24 Jan 2019 19:15:12 +0100,
Sameer Pujar wrote:
> 
> 
> On 1/24/2019 9:34 PM, Takashi Iwai wrote:
> > On Thu, 24 Jan 2019 16:57:11 +0100,
> > Sameer Pujar wrote:
> >> The runtime PM count is incremented and set to active during hda codec
> >> device init, but it is decremented and set to suspend during exit only.
> >> Hence the runtime PM status is always active and hda device cannot be
> >> put to runtime suspend. Keeping device usage active for entire period,
> >> though nothing really happening on the device, seems unnecessary.
> >>
> >> This patch avoides incrementing runtime PM usage count of the device.
> >>
> >> Signed-off-by: Sameer Pujar 
> >> Reviewed-by: Ravindra Lokhande 
> >> Reviewed-by: Mohan Kumar D 
> > This breaks the existing things, I'm afraid.
> > Did you really test and verify the behavior...?
> >
> > The runtime PM refcount is decremented at snd_hda_codec_register(),
> > and that's the place to let runtime suspend of the codec really
> > effective.  (It's not about the controller, though.)
> >
> It worked fine at my end. I could put the device to runtime suspend
> and resume it back multiple times.
> Since you are suggesting it could break things, let me rework on the
> patch and dig up a little more to
> see if there is better way to fix this.

Well, I don't see what you want to "fix".  Do you see any bug?


thanks,

Takashi

> 
> Thanks,
> Sameer.
> 
> > thanks,
> >
> > Takashi
> >
> >
> >> ---
> >>   sound/hda/hdac_device.c | 6 --
> >>   1 file changed, 6 deletions(-)
> >>
> >> diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c
> >> index 95b073e..72aa342 100644
> >> --- a/sound/hda/hdac_device.c
> >> +++ b/sound/hda/hdac_device.c
> >> @@ -31,9 +31,6 @@ static void default_release(struct device *dev)
> >>*
> >>* Returns zero for success or a negative error code.
> >>*
> >> - * This function increments the runtime PM counter and marks it active.
> >> - * The caller needs to turn it off appropriately later.
> >> - *
> >>* The caller needs to set the device's release op properly by itself.
> >>*/
> >>   int snd_hdac_device_init(struct hdac_device *codec, struct hdac_bus *bus,
> >> @@ -55,8 +52,6 @@ int snd_hdac_device_init(struct hdac_device *codec, 
> >> struct hdac_bus *bus,
> >>codec->bus = bus;
> >>codec->addr = addr;
> >>codec->type = HDA_DEV_CORE;
> >> -  pm_runtime_set_active(>dev);
> >> -  pm_runtime_get_noresume(>dev);
> >>atomic_set(>in_pm, 0);
> >>err = snd_hdac_bus_add_device(bus, codec);
> >> @@ -123,7 +118,6 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_init);
> >>*/
> >>   void snd_hdac_device_exit(struct hdac_device *codec)
> >>   {
> >> -  pm_runtime_put_noidle(>dev);
> >>snd_hdac_bus_remove_device(codec->bus, codec);
> >>kfree(codec->vendor_name);
> >>kfree(codec->chip_name);
> >> -- 
> >> 2.7.4
> >>
> >>
> 

Re: [PATCH v8 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller

[Mark Brown]

On Tue, Jan 22, 2019 at 08:54:59AM +, Yogesh Narayan Gaur wrote:
> Hello Mark,
> 
> Can you please apply below patch in SPI tree?
> Patch has been reviewed by Boris and Frieder.

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.


signature.asc
Description: PGP signature

Re: [PATCHv4 1/4] arm64: dts: qcom: sdm845: Add Coresight support

[Sai Prakash Ranjan]

Good day Mathieu,

On 1/24/2019 9:37 PM, Mathieu Poirier wrote:

Good day Sai,

On Wed, 23 Jan 2019 at 13:18, Sai Prakash Ranjan
 wrote:


Hi Mathieu,

On 1/24/2019 12:44 AM, Mathieu Poirier wrote:

On Wed, 23 Jan 2019 at 05:12, Sai Prakash Ranjan
 wrote:

That depends on whether the ETMs have been modified at all, something
Suzuki has asked to be clarified.  If ETMs have been modified then we
need to understand how they differ from the driver's implementation.


We had asked hardware team for clarification regarding this. Let me
poke them again. As for the driver, downstream implementation also
uses the same driver, so I am not sure what do you mean by differing
from the driver's implementation.


The driver has been implemented in accordance to ARM's coresight
technical reference manual and expects the HW to behave in accordance
to that specification.  Here we want to make sure the IP on your board
is conformant to the same specification.  If not then the driver needs
to be made flexible to handle both kind IPs.



The HW does behave as per the specification. As discussed in reply to
Suzuki, Coresight peripherals do use JEP106 ID of ARM for SDM845 and for 
MSM8996, the ID is of QCOM(0x70) since it was not based on any ARM 
derivative.

And the etm4x driver handles it all well. Other values of PID registers
are implementation defined and can be different from standard ARM cpu
core types.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH V2 rdma-next 2/3] RDMA/hns: Fix the chip hanging caused by sending mailbox during reset

[Jason Gunthorpe]

On Thu, Jan 24, 2019 at 11:13:29AM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2019/1/24 6:40, Jason Gunthorpe wrote:
> > On Sat, Jan 19, 2019 at 11:36:06AM +0800, Wei Hu (Xavier) wrote:
> >
> >> +static int hns_roce_v2_cmd_hw_resetting(struct hns_roce_dev *hr_dev,
> >> +  unsigned long instance_stage,
> >> +  unsigned long reset_stage)
> >> +{
> >> +  struct hns_roce_v2_priv *priv = (struct hns_roce_v2_priv *)hr_dev->priv;
> >> +  struct hnae3_handle *handle = priv->handle;
> >> +  const struct hnae3_ae_ops *ops = handle->ae_algo->ops;
> >> +  unsigned long end;
> >> +
> >> +  /* When hardware reset is detected, we should stop sending mailbox
> >> +   * to hardware, and wait until hardware reset finished. If now
> >> +   * in .init_instance() function, we should exit with error. If now at
> >> +   * HNAE3_INIT_CLIENT stage of soft reset process, we should exit with
> >> +   * error, and then HNAE3_INIT_CLIENT related process can rollback the
> >> +   * operation like notifing hardware to free resources, HNAE3_INIT_CLIENT
> >> +   * related process will exit with error to notify NIC driver to
> >> +   * reschedule soft reset process once again.
> >> +   */
> >> +  end = msecs_to_jiffies(HNS_ROCE_V2_HW_RST_TIMEOUT) + jiffies;
> >> +  while (ops->get_hw_reset_stat(handle) && time_before(jiffies, end))
> >> +  udelay(1);
> > I thought you were getting rid of these loops?
> Hi, Jason
> 
> Upper applications maybe notify driver to issue mailbox or CMD
> commands to hardware, some commands used to cancel resources,
> destory bt/destory cq/unreg mr/destory qp etc. when such
> commands are executed successfully, the hardware engine will
> no longer access some memory registered by the driver.
> 
> When reset occurs, it is possible for upper applications notify driver
> to issue mailbox or CMD commands, we need to wait until hardware
> reset finished to ensure that hardware no longer accesses related
> memory.

You should not wait for things using loops like the above.

Jason

Re: [f2fs-dev] [PATCH] fscrypt: remove filesystem specific build config option

[Eric Biggers]

On Thu, Jan 24, 2019 at 12:03:37AM -0500, Theodore Y. Ts'o wrote:
> On Thu, Jan 10, 2019 at 05:01:17PM -0800, Eric Biggers wrote:
> > 
> > Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
> > problem (by removing the 'select BLOCK' from fs/ubifs/Kconfig), but it never
> > made it into the fscrypt tree and hence never made it into linux-next.
> > 
> > Ted, what you are planning to do with the fscrypt tree following the 
> > fsverity
> > discussion?  IMO, we should keep the fsverity stuff in its own branch, 
> > separate
> > from any fscrypt changes.  As a suggestion, in the branch "fscrypt" of my
> > linux.git repo [1], I applied just these four patches on top of v5.0-rc1 and
> > resolved the conflicts with them no longer being on top of fsverity...
> 
> Sorry, I was on vacation last week and I've been catching up on things
> this week.  I've reset the master branch on my fscrypt.git tree so
> that it has what you have on your fscrypt branch, rebased to 5.0-rc3.
> 
> Also, as we had talked about earlier, it probably makes sense to set
> up jointly maintained git tree for fscrypt and fsverity.  My proposal
> is that we set up a new fscrypt.git tree, at
> /pub/scm/fs/fscrypt/fscrypt.git, that would be owned by the "FSCRYPT
> group", with group membership being ebiggers, jaeguk, and tytso.
> We'll have to figure out ways that we can jointly update the git tree
> without stepping on each other, probably using a group chat.  Does
> that sound good to you?
> 

Hi Ted, that sounds good to me.  I assume you know how to get that set up?
Also, should I go ahead and send a patch that adds myself to the MAINTAINERS
file?

- Eric

[PATCH v8 2/2] drm/panel: Add Sitronix ST7701 panel driver

[Jagan Teki]

ST7701 designed for small and medium sizes of TFT LCD display, is
capable of supporting up to 480RGBX864 in resolution. It provides
several system interfaces like MIPI/RGB/SPI.

Currently added support for Techstar TS8550B which is ST7701 based
480x854, 2-lane MIPI DSI LCD panel.

Driver now registering mipi_dsi device, but indeed it can extendable
for RGB if any requirement trigger in future.

Signed-off-by: Jagan Teki 
---
Changes for v8:
- use DRM_DEV_ERROR instead of dev_err
- use devm_of_find_backlight() instead of of_parse_phandle()
- remove unneeded 'num_supplies' from struct st7701
- add proper comments about panel sepecific sleep mode delay as
  per st7701 datasheet
- update msleep delay values in .prepare as per datasheet and as per
  discussion in v7, thanks to 'Sam Ravnborg'  
- update msleep delay values in .unprepare as per datasheet and as per
  discussion in v7, thanks to 'Sam Ravnborg' 
- add proper comments on msleep delay values as per st7701 datasheet 
- use MIPI_DCS_ENTER_SLEEP_MODE in .unprepare
- drop unneeded gpio set in .prepare and .unprepare as per panel-simple
- remove unneeded include files
- rebase on master
Changes for v7:
- rebase on master
Changes for v6:
- use sleep delay value as per datasheet
- add panel_sleep_delay variable for panel specific delay
- use command sequnce display on and off instead panel
  functions
- add proper comments on the delays
- remove delays from command switch
- move mode type on struct display mode
- drop refresh rate value, let drm compute  
Changes for v5:
- found the chip from vendor, so added new panel driver
- here is v4: https://patchwork.kernel.org/patch/10680335/

 MAINTAINERS   |   6 +
 drivers/gpu/drm/panel/Kconfig |  10 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-sitronix-st7701.c | 429 ++
 4 files changed, 446 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7701.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 5c8591eb5840..875bba40157b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4937,6 +4937,12 @@ S:   Orphan / Obsolete
 F: drivers/gpu/drm/sis/
 F: include/uapi/drm/sis_drm.h
 
+DRM DRIVER FOR SITRONIX ST7701 PANELS
+M: Jagan Teki 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-sitronix-st7701.c
+F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
+
 DRM DRIVER FOR SITRONIX ST7586 PANELS
 M: David Lechner 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 5304db7b7b55..a65b3a065598 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -214,6 +214,16 @@ config DRM_PANEL_SHARP_LS043T1LE01
  Say Y here if you want to enable support for Sharp LS043T1LE01 qHD
  (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
 
+config DRM_PANEL_SITRONIX_ST7701
+   tristate "Sitronix ST7701 panel driver"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for the Sitronix
+ ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
+ system interfaces.
+
 config DRM_PANEL_SITRONIX_ST7789V
tristate "Sitronix ST7789V panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index c88dacf9d439..0ec4c41915dd 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += 
panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
+obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
 obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
 obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c 
b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
new file mode 100644
index ..499dd8a34a6d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
@@ -0,0 +1,429 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019, Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+/* Command2 BKx selection command */
+#define DSI_CMD2BKX_SEL0xFF
+
+/* Command2, BK0 commands */
+#define DSI_CMD2_BK0_PVGAMCTRL 0xB0 /* Positive Voltage Gamma Control 
*/
+#define DSI_CMD2_BK0_NVGAMCTRL 0xB1 /* Negative Voltage Gamma Control 
*/
+#define DSI_CMD2_BK0_LNESET0xC0 /* Display Line setting */
+#define 

[PATCH v8 1/2] dt-bindings: panel: Add Sitronix ST7701 panel documentation

[Jagan Teki]

Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel
with inbuilt ST7701 chip.

The default regulator names in ST7701 chip is renamed in Techstar TS8550B
so, add specific binding names for them.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
---
Changes for v8, v7:
- collect Rob Ack
Changes for v6:
- none

 .../display/panel/sitronix,st7701.txt | 30 +++
 1 file changed, 30 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt 
b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
new file mode 100644
index ..ccd17597f1f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
@@ -0,0 +1,30 @@
+Sitronix ST7701 based LCD panels
+
+ST7701 designed for small and medium sizes of TFT LCD display, is
+capable of supporting up to 480RGBX864 in resolution. It provides
+several system interfaces like MIPI/RGB/SPI.
+
+Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has
+inbuilt ST7701 chip.
+
+Required properties:
+- compatible: must be "sitronix,st7701" and one of
+  * "techstar,ts8550b"
+- reset-gpios: a GPIO phandle for the reset pin
+
+Required properties for techstar,ts8550b:
+- reg: DSI virtual channel used by that screen
+- VCC-supply: analog regulator for MIPI circuit
+- IOVCC-supply: I/O system regulator
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+   compatible = "techstar,ts8550b", "sitronix,st7701";
+   reg = <0>;
+   VCC-supply = <_dldo2>;
+   IOVCC-supply = <_dldo2>;
+   reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+   backlight = <>;
+};
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v5 2/4] perf: add arm64 smmuv3 pmu driver

[Robin Murphy]

On 23/01/2019 12:14, Andrew Murray wrote:
[...]

+static inline void smmu_pmu_counter_set_value(struct smmu_pmu

*smmu_pmu,

+ u32 idx, u64 value)
+{
+   if (smmu_pmu->counter_mask & BIT(32))
+   writeq(value, smmu_pmu->reloc_base + SMMU_PMCG_EVCNTR(idx,

8));

+   else
+   writel(value, smmu_pmu->reloc_base + SMMU_PMCG_EVCNTR(idx,

4));

The arm64 IO macros use __force u32 and so it's probably OK to provide a 64
bit
value to writel. But you could use something like lower_32_bits for clarity.


Yes, macro uses __force u32. I will change it to make it more clear though.


To be pedantic, the first cast which the value actually undergoes is to 
(__u32) ;)


Ultimately, __raw_writel() takes a u32, so in that sense it's never a 
problem to pass a u64, since unsigned truncation is well-defined in the 
C standard. The casting involved in the I/O accessors is mostly about 
going to an endian-specific type and back again.


[...]

+static void smmu_pmu_event_start(struct perf_event *event, int flags)
+{
+   struct smmu_pmu *smmu_pmu = to_smmu_pmu(event->pmu);
+   struct hw_perf_event *hwc = >hw;
+   int idx = hwc->idx;
+   u32 filter_span, filter_sid;
+   u32 evtyper;
+
+   hwc->state = 0;
+
+   smmu_pmu_set_period(smmu_pmu, hwc);
+
+   smmu_pmu_get_event_filter(event, _span, _sid);
+
+   evtyper = get_event(event) |
+ filter_span << SMMU_PMCG_SID_SPAN_SHIFT;
+
+   smmu_pmu_set_evtyper(smmu_pmu, idx, evtyper);
+   smmu_pmu_set_smr(smmu_pmu, idx, filter_sid);
+   smmu_pmu_interrupt_enable(smmu_pmu, idx);
+   smmu_pmu_counter_enable(smmu_pmu, idx);
+}
+
+static void smmu_pmu_event_stop(struct perf_event *event, int flags)
+{
+   struct smmu_pmu *smmu_pmu = to_smmu_pmu(event->pmu);
+   struct hw_perf_event *hwc = >hw;
+   int idx = hwc->idx;
+
+   if (hwc->state & PERF_HES_STOPPED)
+   return;
+
+   smmu_pmu_counter_disable(smmu_pmu, idx);


Is it intentional not to call smmu_pmu_interrupt_disable here?


Yes, it is. Earlier patch had the interrupt toggling and Robin pointed out that
it is not really needed as counters are anyway stopped and explicitly disabling
may not solve the spurious interrupt case as well.



Ah apologies for not seeing that in earlier reviews.


Hmm, I didn't exactly mean "keep enabling it every time an event is 
restarted and never disable it anywhere", though. I was thinking more 
along the lines of enabling in event_add() and disabling in event_del() 
(i.e. effectively tying it to allocation and deallocation of the counter).


Robin.

Re: [PATCH v7 1/6] fieldbus_dev: add Fieldbus Device subsystem.

[Greg KH]

On Thu, Jan 24, 2019 at 01:07:58PM -0500, Sven Van Asbroeck wrote:
> On Tue, Jan 22, 2019 at 1:52 PM Greg KH  wrote:
> >
> > SPDX "GPL-2.0+" please.
> >
> > > would be if this code was derived from v2-only code that can't be
> > > relicensed anymore.
> >
> > Are you _sure_ you want v2+?  I ask as I am forced to :)
> >
> 
> The licencing choice confuses me. Why would I choose a different
> licence to what the Linux kernel itself is provided under?

The Linux kernel is provided under "GPLv2" not "GPLv2+"

"GPLv2" means "GPLv2 only"

"GPLv2+" means "Any version of the GPL that the FSF decides to create
from now until the end of time."

> If I did pick a different one, what are the tradeoffs between GPLv2 and 
> GPLv2+ ?

That is for you and your lawyers to discuss :)

thanks,

greg k-h

Re: [PATCHv4 1/4] arm64: dts: qcom: sdm845: Add Coresight support

[Sai Prakash Ranjan]

On 1/24/2019 9:37 PM, Marc Gonzalez wrote:

On 23/01/2019 21:17, Sai Prakash Ranjan wrote:


On 1/24/2019 12:44 AM, Mathieu Poirier wrote:


What version of the Kryo CPU?


There is no Kryo version for MSM8996 (its only given as Kryo), MSM8998
onwards we have Kryo versions like Kryo 280 and so on. Hence I skipped
for this one and added the version for SDM845.


Speaking of MSM8998 (aka SDM835) ... could you take a stab at adding
coresight support for that platform as well? ^_^

Regards.



Sure Marc, I can do it on the next spin probably.

- Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 2/2] mm: Consider subtrees in memory.events

[Johannes Weiner]

On Thu, Jan 24, 2019 at 06:01:17PM +0100, Michal Hocko wrote:
> On Thu 24-01-19 11:00:10, Johannes Weiner wrote:
> [...]
> > We cannot fully eliminate a risk for regression, but it strikes me as
> > highly unlikely, given the extremely young age of cgroup2-based system
> > management and surrounding tooling.
> 
> I am not really sure what you consider young but this interface is 4.0+
> IIRC and the cgroup v2 is considered stable since 4.5 unless I
> missrememeber and that is not a short time period in my book.

If you read my sentence again, I'm not talking about the kernel but
the surrounding infrastructure that consumes this data. The risk is
not dependent on the age of the interface age, but on its adoption.

> Changing interfaces now represents a non-trivial risk and so far I
> haven't heard any actual usecase where the current semantic is
> actually wrong.  Inconsistency on its own is not a sufficient
> justification IMO.

It can be seen either way, and in isolation it wouldn't be wrong to
count events on the local level. But we made that decision for the
entire interface, and this file is the odd one out now. From that
comprehensive perspective, yes, the behavior is wrong. It really
confuses people who are trying to use it, because they *do* expect it
to behave recursively.

I'm really having a hard time believing there are existing cgroup2
users with specific expectations for the non-recursive behavior...

KASAN: global-out-of-bounds Read in validate_nla

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:30bac164aca7 Revert "Change mincore() to count "mapped" pa..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17b824c0c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
dashboard link: https://syzkaller.appspot.com/bug?extid=4157b036c5f4713b1f2f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1137adcf40
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16431b18c0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4157b036c5f4713b1...@syzkaller.appspotmail.com

audit: type=1800 audit(1548293866.971:30): pid=7616 uid=0 auid=4294967295  
ses=4294967295 subj==unconfined op=collect_data cause=failed(directio)  
comm="startpar" name="rmnologin" dev="sda1" ino=2423 res=0

==
BUG: KASAN: global-out-of-bounds in validate_nla+0x12c4/0x1580  
lib/nlattr.c:169

Read of size 1 at addr 88f41fc0 by task syz-executor771/7789

CPU: 1 PID: 7789 Comm: syz-executor771 Not tainted 5.0.0-rc3+ #40
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
 print_address_description.cold+0x5/0x20d mm/kasan/report.c:187
 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132
 validate_nla+0x12c4/0x1580 lib/nlattr.c:169
 nla_validate+0xc1/0x130 lib/nlattr.c:340
 validate_nla+0x711/0x1580 lib/nlattr.c:247
 __nla_parse+0x206/0x340 lib/nlattr.c:415
 nla_parse+0x45/0x60 lib/nlattr.c:439
 nlmsg_parse include/net/netlink.h:527 [inline]
 nl80211_dump_wiphy_parse.isra.0.constprop.0+0x133/0x610  
net/wireless/nl80211.c:2299

 nl80211_dump_wiphy+0x595/0x760 net/wireless/nl80211.c:2342
 genl_lock_dumpit+0x6d/0xa0 net/netlink/genetlink.c:481
 netlink_dump+0x5f2/0x1070 net/netlink/af_netlink.c:2244
 __netlink_dump_start+0x5b4/0x7e0 net/netlink/af_netlink.c:2352
 genl_family_rcv_msg+0xeb5/0x11a0 net/netlink/genetlink.c:549
 genl_rcv_msg+0xca/0x16c net/netlink/genetlink.c:626
 netlink_rcv_skb+0x17d/0x410 net/netlink/af_netlink.c:2477
 genl_rcv+0x29/0x40 net/netlink/genetlink.c:637
 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
 netlink_unicast+0x574/0x770 net/netlink/af_netlink.c:1336
 netlink_sendmsg+0xa05/0xf90 net/netlink/af_netlink.c:1917
 sock_sendmsg_nosec net/socket.c:621 [inline]
 sock_sendmsg+0xdd/0x130 net/socket.c:631
 ___sys_sendmsg+0x7ec/0x910 net/socket.c:2116
 __sys_sendmsg+0x112/0x270 net/socket.c:2154
 __do_sys_sendmsg net/socket.c:2163 [inline]
 __se_sys_sendmsg net/socket.c:2161 [inline]
 __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4400d9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7ffd4f4bf478 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 004400d9
RDX:  RSI: 2380 RDI: 0003
RBP: 006ca018 R08: 0006 R09: 004002c8
R10: 0008 R11: 0246 R12: 00401960
R13: 004019f0 R14:  R15: 

The buggy address belongs to the variable:
 nl80211_pmsr_attr_policy+0x60/0x80

Memory state around the buggy address:
 88f41e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88f41f00: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00

88f41f80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00

   ^
 88f42000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 00
 88f42080: 00 00 fa fa fa fa fa fa 00 00 00 00 fa fa fa fa
==


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCHv4 1/4] arm64: dts: qcom: sdm845: Add Coresight support

[Sai Prakash Ranjan]

Hi Suzuki,

On 1/24/2019 4:49 PM, Suzuki K Poulose wrote:

Hi Sai,


That looks fine with me. But as Mathieu said, this needs to be a separate
patch. But before all that please could you provide me the PIDR4 value for
the Kryo A75 and A55 please ?



Sure.

PIDR4 value is 0x4.

I get it now. So we are looking for JEP106 identification(PIDR1[7:4] and
PIDR2[2:0]) and continuation code(PIDR4[3:0]).

From ARM Coresight Spec:

DES_0, PIDR1 bits[7:4] JEP106 identification code bits[3:0].
DES_1, PIDR2 bits[2:0] JEP106 identification code bits[6:4].
DES_2, PIDR4 bits[3:0] JEP106 continuation code.

For SDM845(A75 based):

*0xB_B8_03* does indicate that the JEP106 identification
code is 0x3B and continuation code is 0x4 which is of ARM and not
QCOM(JEP106 ID is 0x70) which is expected.

And the other values of PIDR0[0:7] and PIDR1[3:0] are *Implementation
defined part numbers* and can be different from ARM A75/A55.

I think this clears up case for SDM845.

As for MSM8996, it is not based on any ARM derivative and hence the
JEP106 ID is of QCOM(0x70) from the value of pid = *0xF_02_11*
based on PIDR1[7:4] and PIDR2[2:0]. This clears this as well.

Please correct me if I am wrong and also let me know if I can
continue with PID addition to table.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [RFC/RFT PATCH 00/15] crypto: improved skcipher, aead, and hash tests

[Eric Biggers]

On Thu, Jan 24, 2019 at 05:23:59PM +0800, Herbert Xu wrote:
> On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote:
> >
> > Thanks for yet another round of cleanup
> > 
> > I'll look into these, but I'd like to clarify one thing first.
> > 
> > IIUC, you are trying to deal with the case where a single scatterlist
> > element describes a range that strides two pages, and I wonder if that
> > is a valid use of scatterlists in the first place.
> > 
> > Herbert?
> 
> Yes it is valid.  IIRC the network stack may generate such a
> scatterlist.
> 

Also it can easily happen with kmalloced buffers, e.g.

buf = kmalloc(1, GFP_KERNEL);

[...]

sg_init_one(, buf, 1);

- Eric

int_sqrt() adjustments

[Florian La Roche]

__fls() is returning an unsigned long, but fls() and fls64() are
both returning a (signed) int.
As we need a signed int as right operand of "<<" (as Linus pointed out),
change __fls() to fls() for 32bit and also adjust masking the lowest bit
to be a signed int.
Now the 32bit and the 64bit version are again similar.

best regards,

Florian La Roche



Signed-off-by: Florian La Roche 
---
 lib/int_sqrt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/int_sqrt.c b/lib/int_sqrt.c
index 30e0f9770f88..66eb93105812 100644
--- a/lib/int_sqrt.c
+++ b/lib/int_sqrt.c
@@ -23,7 +23,7 @@ unsigned long int_sqrt(unsigned long x)
if (x <= 1)
return x;
 
-   m = 1UL << (__fls(x) & ~1UL);
+   m = 1UL << ((fls(x) - 1) & ~1L);
while (m != 0) {
b = y + m;
y >>= 1;
@@ -52,7 +52,7 @@ u32 int_sqrt64(u64 x)
if (x <= ULONG_MAX)
return int_sqrt((unsigned long) x);
 
-   m = 1ULL << ((fls64(x) - 1) & ~1ULL);
+   m = 1ULL << ((fls64(x) - 1) & ~1LL);
while (m != 0) {
b = y + m;
y >>= 1;
-- 
2.17.1

Re: [PATCH] fs/devpts: always delete dcache dentry-s in dput()

[Al Viro]

On Thu, Jan 24, 2019 at 02:03:06PM +0100, v...@amazon.com wrote:

> diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
> index c538145..553a3f3 100644
> --- a/fs/devpts/inode.c
> +++ b/fs/devpts/inode.c
> @@ -455,6 +455,7 @@ devpts_fill_super(struct super_block *s, void *data, int 
> silent)
>   s->s_blocksize_bits = 10;
>   s->s_magic = DEVPTS_SUPER_MAGIC;
>   s->s_op = _sops;
> + s->s_d_op = _dentry_operations;
>   s->s_time_gran = 1;
>  
>   error = -ENOMEM;

Applied.

Re: [PATCH] mac80211: Remove attribute packed from struct 'action'

[Johannes Berg]

On Thu, 2019-01-24 at 19:14 +0100, Mathieu Malaterre wrote:

> > I'm not sure this will work on all platforms, didn't something like
> > alpha pad out u8's to u32 when not requiring packing?
> 
> I was not aware of that.

TBH, I'm not actually sure about that. Pure hearsay. If anyone knows,
I'd like to know too :)

johannes

[PATCH v2] mac80211: Add attribute aligned(2) to struct 'action'

[Mathieu Malaterre]

During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO
follow-MAC mode") a new struct 'action' was declared with packed
attribute as:

  struct {
  struct ieee80211_hdr_3addr hdr;
  u8 category;
  u8 action_code;
  } __packed action;

But since struct 'ieee80211_hdr_3addr' is declared with an aligned
keyword as:

  struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
u8 addr4[ETH_ALEN];
  } __packed __aligned(2);

Solve the ambiguity of placing aligned structure in a packed one by
adding the aligned(2) attribute to struct 'action'. This seems to be the
behavior of gcc anyway, since the following is still compiling:

  BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1);

This removes the following warning (W=1):

  net/mac80211/rx.c:234:2: warning: alignment 1 of 'struct ' is less 
than 2 [-Wpacked-not-aligned]

Cc: Johannes Berg 
Suggested-by: Johannes Berg 
Signed-off-by: Mathieu Malaterre 
---
v2: It was suggested by Johannes that an arch actually need the pack attribute 
(alpha).

 net/mac80211/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 45aad3d3108c..885df250b67e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -231,7 +231,7 @@ static void ieee80211_handle_mu_mimo_mon(struct 
ieee80211_sub_if_data *sdata,
struct ieee80211_hdr_3addr hdr;
u8 category;
u8 action_code;
-   } __packed action;
+   } __packed __aligned(2) action;
 
if (!sdata)
return;
-- 
2.19.2

Re: [PATCH v2] lightnvm: pblk: Switch to use new generic UUID API

[Matias Bjørling]

On 1/24/19 3:31 PM, Andy Shevchenko wrote:

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Signed-off-by: Andy Shevchenko 
---

v2:
- convert instance_uuid to guid_t and get rid of pblk_setup_uuid()
- fix subject line to show subsystem

  drivers/lightnvm/pblk-core.c |  4 ++--
  drivers/lightnvm/pblk-init.c |  2 +-
  drivers/lightnvm/pblk-recovery.c |  8 +---
  drivers/lightnvm/pblk.h  | 10 +-
  4 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
index 1ff165351180..189339965957 100644
--- a/drivers/lightnvm/pblk-core.c
+++ b/drivers/lightnvm/pblk-core.c
@@ -1065,7 +1065,7 @@ static int pblk_line_init_metadata(struct pblk *pblk, 
struct pblk_line *line,
bitmap_set(line->lun_bitmap, 0, lm->lun_bitmap_len);
  
  	smeta_buf->header.identifier = cpu_to_le32(PBLK_MAGIC);

-   memcpy(smeta_buf->header.uuid, pblk->instance_uuid, 16);
+   guid_copy((guid_t *)_buf->header.uuid, >instance_uuid);
smeta_buf->header.id = cpu_to_le32(line->id);
smeta_buf->header.type = cpu_to_le16(line->type);
smeta_buf->header.version_major = SMETA_VERSION_MAJOR;
@@ -1874,7 +1874,7 @@ void pblk_line_close_meta(struct pblk *pblk, struct 
pblk_line *line)
  
  	if (le32_to_cpu(emeta_buf->header.identifier) != PBLK_MAGIC) {

emeta_buf->header.identifier = cpu_to_le32(PBLK_MAGIC);
-   memcpy(emeta_buf->header.uuid, pblk->instance_uuid, 16);
+   guid_copy((guid_t *)_buf->header.uuid, 
>instance_uuid);
emeta_buf->header.id = cpu_to_le32(line->id);
emeta_buf->header.type = cpu_to_le16(line->type);
emeta_buf->header.version_major = EMETA_VERSION_MAJOR;
diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index f9a3e47b6a93..5768333d103f 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -130,7 +130,7 @@ static int pblk_l2p_recover(struct pblk *pblk, bool 
factory_init)
struct pblk_line *line = NULL;
  
  	if (factory_init) {

-   pblk_setup_uuid(pblk);
+   guid_gen(>instance_uuid);
} else {
line = pblk_recov_l2p(pblk);
if (IS_ERR(line)) {
diff --git a/drivers/lightnvm/pblk-recovery.c b/drivers/lightnvm/pblk-recovery.c
index 5ee20da7bdb3..6761d2afa4d0 100644
--- a/drivers/lightnvm/pblk-recovery.c
+++ b/drivers/lightnvm/pblk-recovery.c
@@ -703,11 +703,13 @@ struct pblk_line *pblk_recov_l2p(struct pblk *pblk)
  
  		/* The first valid instance uuid is used for initialization */

if (!valid_uuid) {
-   memcpy(pblk->instance_uuid, smeta_buf->header.uuid, 16);
+   guid_copy(>instance_uuid,
+ (guid_t *)_buf->header.uuid);
valid_uuid = 1;
}
  
-		if (memcmp(pblk->instance_uuid, smeta_buf->header.uuid, 16)) {

+   if (!guid_equal(>instance_uuid,
+   (guid_t *)_buf->header.uuid)) {
pblk_debug(pblk, "ignore line %u due to uuid 
mismatch\n",
i);
continue;
@@ -737,7 +739,7 @@ struct pblk_line *pblk_recov_l2p(struct pblk *pblk)
}
  
  	if (!found_lines) {

-   pblk_setup_uuid(pblk);
+   guid_gen(>instance_uuid);
  
  		spin_lock(_mg->free_lock);

WARN_ON_ONCE(!test_and_clear_bit(meta_line,
diff --git a/drivers/lightnvm/pblk.h b/drivers/lightnvm/pblk.h
index 85e38ed62f85..12bf02df4204 100644
--- a/drivers/lightnvm/pblk.h
+++ b/drivers/lightnvm/pblk.h
@@ -646,7 +646,7 @@ struct pblk {
  
  	int sec_per_write;
  
-	unsigned char instance_uuid[16];

+   guid_t instance_uuid;
  
  	/* Persistent write amplification counters, 4kb sector I/Os */

atomic64_t user_wa; /* Sectors written by user */
@@ -1360,14 +1360,6 @@ static inline unsigned int pblk_get_secs(struct bio *bio)
return  bio->bi_iter.bi_size / PBLK_EXPOSED_PAGE_SIZE;
  }
  
-static inline void pblk_setup_uuid(struct pblk *pblk)

-{
-   uuid_le uuid;
-
-   uuid_le_gen();
-   memcpy(pblk->instance_uuid, uuid.b, 16);
-}
-
  static inline char *pblk_disk_name(struct pblk *pblk)
  {
struct gendisk *disk = pblk->disk;



Thanks Andy. I've applied it for 5.1.

Re: [PATCH] ALSA: hda: runtime PM is always active

[Sameer Pujar]

On 1/24/2019 9:34 PM, Takashi Iwai wrote:

On Thu, 24 Jan 2019 16:57:11 +0100,
Sameer Pujar wrote:

The runtime PM count is incremented and set to active during hda codec
device init, but it is decremented and set to suspend during exit only.
Hence the runtime PM status is always active and hda device cannot be
put to runtime suspend. Keeping device usage active for entire period,
though nothing really happening on the device, seems unnecessary.

This patch avoides incrementing runtime PM usage count of the device.

Signed-off-by: Sameer Pujar 
Reviewed-by: Ravindra Lokhande 
Reviewed-by: Mohan Kumar D 

This breaks the existing things, I'm afraid.
Did you really test and verify the behavior...?

The runtime PM refcount is decremented at snd_hda_codec_register(),
and that's the place to let runtime suspend of the codec really
effective.  (It's not about the controller, though.)

It worked fine at my end. I could put the device to runtime suspend and 
resume it back multiple times.
Since you are suggesting it could break things, let me rework on the 
patch and dig up a little more to

see if there is better way to fix this.

Thanks,
Sameer.


thanks,

Takashi



---
  sound/hda/hdac_device.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c
index 95b073e..72aa342 100644
--- a/sound/hda/hdac_device.c
+++ b/sound/hda/hdac_device.c
@@ -31,9 +31,6 @@ static void default_release(struct device *dev)
   *
   * Returns zero for success or a negative error code.
   *
- * This function increments the runtime PM counter and marks it active.
- * The caller needs to turn it off appropriately later.
- *
   * The caller needs to set the device's release op properly by itself.
   */
  int snd_hdac_device_init(struct hdac_device *codec, struct hdac_bus *bus,
@@ -55,8 +52,6 @@ int snd_hdac_device_init(struct hdac_device *codec, struct 
hdac_bus *bus,
codec->bus = bus;
codec->addr = addr;
codec->type = HDA_DEV_CORE;
-   pm_runtime_set_active(>dev);
-   pm_runtime_get_noresume(>dev);
atomic_set(>in_pm, 0);
  
  	err = snd_hdac_bus_add_device(bus, codec);

@@ -123,7 +118,6 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_init);
   */
  void snd_hdac_device_exit(struct hdac_device *codec)
  {
-   pm_runtime_put_noidle(>dev);
snd_hdac_bus_remove_device(codec->bus, codec);
kfree(codec->vendor_name);
kfree(codec->chip_name);
--
2.7.4

Re: [PATCH] mac80211: Remove attribute packed from struct 'action'

[Mathieu Malaterre]

On Thu, Jan 24, 2019 at 7:08 PM Johannes Berg  wrote:
>
> On Thu, 2019-01-24 at 19:05 +0100, Mathieu Malaterre wrote:
> > During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO
> > follow-MAC mode") a new struct 'action' was declared with packed
> > attribute as:
> >
> >   struct {
> >   struct ieee80211_hdr_3addr hdr;
> >   u8 category;
> >   u8 action_code;
> >   } __packed action;
> >
> > But since struct 'ieee80211_hdr_3addr' is declared with an aligned
> > keyword as:
> >
> >   struct ieee80211_hdr {
> >   __le16 frame_control;
> >   __le16 duration_id;
> >   u8 addr1[ETH_ALEN];
> >   u8 addr2[ETH_ALEN];
> >   u8 addr3[ETH_ALEN];
> >   __le16 seq_ctrl;
> >   u8 addr4[ETH_ALEN];
> >   } __packed __aligned(2);
> >
> > Solve the ambiguity of placing aligned structure in a packed one by
> > removing the packed attribute from struct. This seems to be the behavior
> > of gcc anyway, since the following is still compiling:
> >
> >   BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1);
>
> I'm not sure this will work on all platforms, didn't something like
> alpha pad out u8's to u32 when not requiring packing?

I was not aware of that.

> I guess I'd feel better about using __packed __aligned(2) here as well,
> which should solve the warning too?

Indeed, I will re-spin a v2 then.

[PATCH v2 -next] rcu: rcu_qs -- Use raise_softirq_irqoff to not save irqs twice

[Cyrill Gorcunov]

The rcu_qs is disabling IRQs by self so no need to do the same in raise_softirq
but instead we can save some cycles using raise_softirq_irqoff directly.

CC: Paul E. McKenney 
Signed-off-by: Cyrill Gorcunov 
---
The prev patch body has been screwed, sorry.

 kernel/rcu/tiny.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-next.git/kernel/rcu/tiny.c
===
--- linux-next.git.orig/kernel/rcu/tiny.c
+++ linux-next.git/kernel/rcu/tiny.c
@@ -65,7 +65,7 @@ void rcu_qs(void)
local_irq_save(flags);
if (rcu_ctrlblk.donetail != rcu_ctrlblk.curtail) {
rcu_ctrlblk.donetail = rcu_ctrlblk.curtail;
-   raise_softirq(RCU_SOFTIRQ);
+   raise_softirq_irqoff(RCU_SOFTIRQ);
}
local_irq_restore(flags);
 }

[DO NOT MERGE] [PATCH v7 5/5] arm64: dts: allwinner: bananapi-m64: Add HDF5640 camera module

[Jagan Teki]

Bananapi M64 comes with an optional sensor based on the ov5640,
add support for it with below pin information.

- PE13, PE12 via i2c-gpio bitbanging
- CLK_CSI_MCLK as external clock
- PE1 as external clock pin muxing
- DLDO3 as AVDD supply
- ALDO1 as DOVDD supply
- ELDO3 as DVDD supply
- PE16 gpio for reset pin
- PE17 gpio for powerdown pin

Signed-off-by: Jagan Teki 
---
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 9d0afd7d50ec..c99f66271287 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -60,6 +60,41 @@
stdout-path = "serial0:115200n8";
};
 
+   i2c-csi {
+   compatible = "i2c-gpio";
+   sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* CSI0-SDA: PE13 */
+   scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* CSI0-SCK: PE12 */
+   i2c-gpio,delay-us = <5>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ov5640: camera@3c {
+   compatible = "ovti,ov5640";
+   reg = <0x3c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_mclk_pin>;
+   clocks = < CLK_CSI_MCLK>;
+   clock-names = "xclk";
+
+   AVDD-supply = <_dldo3>;
+   DOVDD-supply = <_aldo1>;
+   DVDD-supply = <_eldo3>;
+   reset-gpios = < 4 16 GPIO_ACTIVE_LOW>; /* CSI0-RST: 
PE16 */
+   powerdown-gpios = < 4 17 GPIO_ACTIVE_HIGH>; /* 
CSI0-PWDN: PE17 */
+
+   port {
+   ov5640_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <8>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+   };
+
hdmi-connector {
compatible = "hdmi-connector";
type = "a";
@@ -108,6 +143,24 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   csi_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <8>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
+
  {
status = "okay";
 };
@@ -298,6 +351,12 @@
regulator-name = "vcc-wifi";
 };
 
+_dldo3 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "avdd-csi";
+};
+
 _dldo4 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
@@ -315,6 +374,12 @@
regulator-name = "cpvdd";
 };
 
+_eldo3 {
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "dvdd-csi";
+};
+
 _fldo1 {
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
-- 
2.18.0.321.gffc6fa0e3

[PATCH v7 0/5] media/sun6i: Allwinner A64 CSI support

[Jagan Teki]

Add CSI support for Allwinner A64. Here is previous series[1]

Changes for v7:
- Drop quirk change, and add as suggusted by Maxime
- Use csi instead csi0 in pinctrl function
Changes for v6:
- set the mod rate in seett_power instead of probe
Changes for v5:
- Add mod_rate quirk for better handling clk_set code
Changes for v4:
- update the compatible string order
- add proper commit message
- included BPI-M64 patch
- skipped amarula-a64 patch
Changes for v3:
- update dt-bindings for A64
- set mod clock via csi driver
- remove assign clocks from dtsi
- remove i2c-gpio opendrian
- fix avdd and dovdd supplies
- remove vcc-csi pin group supply

[1] https://patchwork.kernel.org/cover/10771163/

Any inputs?
Jagan.

Jagan Teki (5):
  dt-bindings: media: sun6i: Add A64 CSI compatible
  media: sun6i: Add A64 CSI block support
  arm64: dts: allwinner: a64: Add A64 CSI controller
  arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
  [DO NOT MERGET] arm64: dts: allwinner: bananapi-m64: Add HDF5640 camera module

 .../devicetree/bindings/media/sun6i-csi.txt   |  1 +
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 65 +++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 +++
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 13 +++-
 4 files changed, 103 insertions(+), 1 deletion(-)

-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH] mac80211: Remove attribute packed from struct 'action'

[Johannes Berg]

On Thu, 2019-01-24 at 19:05 +0100, Mathieu Malaterre wrote:
> During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO
> follow-MAC mode") a new struct 'action' was declared with packed
> attribute as:
> 
>   struct {
>   struct ieee80211_hdr_3addr hdr;
>   u8 category;
>   u8 action_code;
>   } __packed action;
> 
> But since struct 'ieee80211_hdr_3addr' is declared with an aligned
> keyword as:
> 
>   struct ieee80211_hdr {
>   __le16 frame_control;
>   __le16 duration_id;
>   u8 addr1[ETH_ALEN];
>   u8 addr2[ETH_ALEN];
>   u8 addr3[ETH_ALEN];
>   __le16 seq_ctrl;
>   u8 addr4[ETH_ALEN];
>   } __packed __aligned(2);
> 
> Solve the ambiguity of placing aligned structure in a packed one by
> removing the packed attribute from struct. This seems to be the behavior
> of gcc anyway, since the following is still compiling:
> 
>   BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1);

I'm not sure this will work on all platforms, didn't something like
alpha pad out u8's to u32 when not requiring packing?

I guess I'd feel better about using __packed __aligned(2) here as well,
which should solve the warning too?

johannes

[PATCH v7 2/5] media: sun6i: Add A64 CSI block support

[Jagan Teki]

CSI block in Allwinner A64 has similar features as like in H3,
but the default CSI_SCLK rate cannot work properly to drive the
connected sensor interface.

The tested mod cock rate is 300 MHz and BSP vfe media driver is also
using the same rate. Unfortunately there is no valid information about
clock rate in manual or any other sources except the BSP driver. so more
faith on BSP code, because same has tested in mainline.

So, add support for A64 CSI block by setting updated mod clock rate.

Signed-off-by: Jagan Teki 
---
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index ee882b66a5ea..cd2d33242c17 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -154,6 +155,7 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
 int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
+   struct device *dev = sdev->dev;
struct regmap *regmap = sdev->regmap;
int ret;
 
@@ -161,15 +163,20 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool 
enable)
regmap_update_bits(regmap, CSI_EN_REG, CSI_EN_CSI_EN, 0);
 
clk_disable_unprepare(sdev->clk_ram);
+   if (of_device_is_compatible(dev->of_node, 
"allwinner,sun50i-a64-csi"))
+   clk_rate_exclusive_put(sdev->clk_mod);
clk_disable_unprepare(sdev->clk_mod);
reset_control_assert(sdev->rstc_bus);
return 0;
}
 
+   if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
+   clk_set_rate_exclusive(sdev->clk_mod, 3);
+
ret = clk_prepare_enable(sdev->clk_mod);
if (ret) {
dev_err(sdev->dev, "Enable csi clk err %d\n", ret);
-   return ret;
+   goto clk_mod_put;
}
 
ret = clk_prepare_enable(sdev->clk_ram);
@@ -192,6 +199,9 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
clk_disable_unprepare(sdev->clk_ram);
 clk_mod_disable:
clk_disable_unprepare(sdev->clk_mod);
+clk_mod_put:
+   if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
+   clk_rate_exclusive_put(sdev->clk_mod);
return ret;
 }
 
@@ -895,6 +905,7 @@ static const struct of_device_id sun6i_csi_of_match[] = {
{ .compatible = "allwinner,sun6i-a31-csi", },
{ .compatible = "allwinner,sun8i-h3-csi", },
{ .compatible = "allwinner,sun8i-v3s-csi", },
+   { .compatible = "allwinner,sun50i-a64-csi", },
{},
 };
 MODULE_DEVICE_TABLE(of, sun6i_csi_of_match);
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH 0/2] small optimization for accessing queue map

[Jens Axboe]

On 1/24/19 3:25 AM, Jianchao Wang wrote:
> Hi Jens
> 
> These two patches are small optimization for accessing the queue mapping
> in hot path. It saves the queue mapping results into blk_mq_ctx directly,
> then we needn't do the complicated bounce on queue_hw_ctx[] map[] and
> mq_map[].

I like this a lot, the current double indirect does suck, and it does show
up in profiles as well. I'll run some testing with this, thanks!

-- 
Jens Axboe

[PATCH v7 3/5] arm64: dts: allwinner: a64: Add A64 CSI controller

[Jagan Teki]

Add dts node details for Allwinner A64 CSI controller.

A64 CSI has similar features as like in H3, but the CSI_SCLK
need to update it to 300MHz than default clock rate.

Signed-off-by: Jagan Teki 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20 +++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 839b2ae88583..62fdf850e9e5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -558,6 +558,12 @@
interrupt-controller;
#interrupt-cells = <3>;
 
+   csi_pins: csi-pins {
+   pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
+  "PE7", "PE8", "PE9", "PE10", "PE11";
+   function = "csi";
+   };
+
i2c0_pins: i2c0_pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -925,6 +931,20 @@
status = "disabled";
};
 
+   csi: csi@1cb {
+   compatible = "allwinner,sun50i-a64-csi";
+   reg = <0x01cb 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "disabled";
+   };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun50i-a64-dw-hdmi",
 "allwinner,sun8i-a83t-dw-hdmi";
-- 
2.18.0.321.gffc6fa0e3

[PATCH v7 4/5] arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1

[Jagan Teki]

Some camera modules have the SoC feeding a master clock to the sensor
instead of having a standalone crystal. This clock signal is generated
from the clock control unit and output from the CSI MCLK function of
pin PE1.

Add a pinmux setting for it for camera sensors to reference.

Signed-off-by: Jagan Teki 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 62fdf850e9e5..6e5a608f56f2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -564,6 +564,11 @@
function = "csi";
};
 
+   csi_mclk_pin: csi-mclk {
+   pins = "PE1";
+   function = "csi";
+   };
+
i2c0_pins: i2c0_pins {
pins = "PH0", "PH1";
function = "i2c0";
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v7 1/6] fieldbus_dev: add Fieldbus Device subsystem.

[Sven Van Asbroeck]

On Tue, Jan 22, 2019 at 1:52 PM Greg KH  wrote:
>
> SPDX "GPL-2.0+" please.
>
> > would be if this code was derived from v2-only code that can't be
> > relicensed anymore.
>
> Are you _sure_ you want v2+?  I ask as I am forced to :)
>

The licencing choice confuses me. Why would I choose a different
licence to what the Linux kernel itself is provided under?
If I did pick a different one, what are the tradeoffs between GPLv2 and GPLv2+ ?

[PATCH v7 1/5] dt-bindings: media: sun6i: Add A64 CSI compatible

[Jagan Teki]

Allwinner A64 CSI is a single channel time-multiplexed BT.656
protocol interface.

Add separate compatible string for A64 since it require explicit
change in sun6i_csi driver to update default CSI_SCLK rate.

Reviewed-by: Rob Herring 
Signed-off-by: Jagan Teki 
---
 Documentation/devicetree/bindings/media/sun6i-csi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
index cc37cf7fd051..0dd540bb03db 100644
--- a/Documentation/devicetree/bindings/media/sun6i-csi.txt
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -8,6 +8,7 @@ Required properties:
 * "allwinner,sun6i-a31-csi"
 * "allwinner,sun8i-h3-csi"
 * "allwinner,sun8i-v3s-csi"
+* "allwinner,sun50i-a64-csi"
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
   - clocks: phandles to the clocks feeding the CSI
-- 
2.18.0.321.gffc6fa0e3

[PATCH 2/2] Bluetooth: Correctly annotate implicit fall through in __rfcomm_dlc_close

[Mathieu Malaterre]

There is a plan to build the kernel with -Wimplicit-fallthrough and
this place in the code produced a warning (W=1).

In this particular case put the fall through comment on a separate line so
as to match the regular expression expected by GCC.

This commit removes the following warning:

  net/bluetooth/rfcomm/core.c:479:6: warning: this statement may fall through 
[-Wimplicit-fallthrough=]

Cc: Peter Hurley 
Signed-off-by: Mathieu Malaterre 
---
 net/bluetooth/rfcomm/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 1a635df80643..caaae6accafa 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -480,9 +480,8 @@ static int __rfcomm_dlc_close(struct rfcomm_dlc *d, int err)
__rfcomm_dlc_disconn(d);
break;
}
-   /* if closing a dlc in a session that hasn't been started,
-* just close and unlink the dlc
-*/
+   /* fall through - if closing a dlc in a session that hasn't */
+   /* been started, just close and unlink the dlc */
 
default:
rfcomm_dlc_clear_timer(d);
-- 
2.19.2

[PATCH -next] rcu: rcu_qs -- Use raise_softirq_irqoff to not save irqs twice

[Cyrill Gorcunov]

The rcu_qs is disabling IRQs by self so no need to do the same in raise_softirq,
instead we can save some cycles using raise_softirq_irqoff directly.

CC: Paul E. McKenney 
Signed-off-by: Cyrill Gorcunov 
---
 kernel/rcu/tiny.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-next.git/kernel/rcu/tiny.c
===
--- linux-next.git.orig/kernel/rcu/tiny.c
+++ linux-next.git/kernel/rcu/tiny.c
@@ -65,7 +65,7 @@ void rcu_qs(void)
local_irq_save(flags);
if (rcu_ctrlblk.donetail != rcu_ctrlblk.curtail) {
rcu_ctrlblk.donetail = rcu_ctrlblk.curtail;
-   raise_softirq(RCU_SOFTIRQ);
+   raise_softirq_irqoff(RCU_SOFTIRQ);
}
local_irq_restore(flags);
 }
Subject: [PATCH]

[PATCH 1/2] Bluetooth: Annotate implicit fall through in l2cap_config_rsp

[Mathieu Malaterre]

There is a plan to build the kernel with -Wimplicit-fallthrough and
this place in the code produced a warning (W=1).

This commit removes the following warning:

  net/bluetooth/l2cap_core.c:4223:6: warning: this statement may fall through 
[-Wimplicit-fallthrough=]

Cc: Gustavo Padovan 
Signed-off-by: Mathieu Malaterre 
---
 net/bluetooth/l2cap_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 2a7fb517d460..a5b76e24940a 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4244,6 +4244,7 @@ static inline int l2cap_config_rsp(struct l2cap_conn 
*conn,
goto done;
break;
}
+   /* fall through */
 
default:
l2cap_chan_set_err(chan, ECONNRESET);
-- 
2.19.2

[PATCH] regmap: Remove attribute packed from struct 'regcache_rbtree_node'

[Mathieu Malaterre]

On one hand commit 28644c809f44 ("regmap: Add the rbtree cache support")
added 'regcache_rbtree_node' as packed structure, while on the other hand
commit e977145aeaad ("[RBTREE] Add explicit alignment to sizeof(long)
for struct rb_node.") declared struct 'rb_node' as aligned.

Solve the ambiguity of placing aligned structure in a packed one by
removing the packed attribute from struct. This seems to be the behavior
of gcc anyway.

This removes the following warning (W=1):

  drivers/base/regmap/regcache-rbtree.c:36:1: warning: alignment 1 of 'struct 
regcache_rbtree_node' is less than 4 [-Wpacked-not-aligned]

Cc: Dimitris Papastamos 
Cc: David Woodhouse 
Signed-off-by: Mathieu Malaterre 
---
 drivers/base/regmap/regcache-rbtree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regcache-rbtree.c 
b/drivers/base/regmap/regcache-rbtree.c
index 2e8f0144f9ab..9cbb4b0cd01b 100644
--- a/drivers/base/regmap/regcache-rbtree.c
+++ b/drivers/base/regmap/regcache-rbtree.c
@@ -33,7 +33,7 @@ struct regcache_rbtree_node {
unsigned int blklen;
/* the actual rbtree node holding this block */
struct rb_node node;
-} __attribute__ ((packed));
+};
 
 struct regcache_rbtree_ctx {
struct rb_root root;
-- 
2.19.2

[PATCH] mac80211: Remove attribute packed from struct 'action'

[Mathieu Malaterre]

During refactor in commit 9e478066eae4 ("mac80211: fix MU-MIMO
follow-MAC mode") a new struct 'action' was declared with packed
attribute as:

  struct {
  struct ieee80211_hdr_3addr hdr;
  u8 category;
  u8 action_code;
  } __packed action;

But since struct 'ieee80211_hdr_3addr' is declared with an aligned
keyword as:

  struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
u8 addr4[ETH_ALEN];
  } __packed __aligned(2);

Solve the ambiguity of placing aligned structure in a packed one by
removing the packed attribute from struct. This seems to be the behavior
of gcc anyway, since the following is still compiling:

  BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1);

This removes the following warning (W=1):

  net/mac80211/rx.c:234:2: warning: alignment 1 of 'struct ' is less 
than 2 [-Wpacked-not-aligned]

Cc: Johannes Berg 
Signed-off-by: Mathieu Malaterre 
---
 net/mac80211/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 45aad3d3108c..709359650149 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -231,7 +231,7 @@ static void ieee80211_handle_mu_mimo_mon(struct 
ieee80211_sub_if_data *sdata,
struct ieee80211_hdr_3addr hdr;
u8 category;
u8 action_code;
-   } __packed action;
+   } action;
 
if (!sdata)
return;
-- 
2.19.2

[PATCH] ext2: Annotate implicit fall through in __ext2_truncate_blocks

[Mathieu Malaterre]

There is a plan to build the kernel with -Wimplicit-fallthrough and
these places in the code produced warnings (W=1).

This commit removes the following warnings:

  fs/ext2/inode.c:1237:7: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
  fs/ext2/inode.c:1244:7: warning: this statement may fall through 
[-Wimplicit-fallthrough=]

Signed-off-by: Mathieu Malaterre 
---
 fs/ext2/inode.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index e4bb9386c045..e64029b1bd50 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -1239,6 +1239,7 @@ static void __ext2_truncate_blocks(struct inode *inode, 
loff_t offset)
mark_inode_dirty(inode);
ext2_free_branches(inode, , +1, 1);
}
+   /* fall through */
case EXT2_IND_BLOCK:
nr = i_data[EXT2_DIND_BLOCK];
if (nr) {
@@ -1246,6 +1247,7 @@ static void __ext2_truncate_blocks(struct inode *inode, 
loff_t offset)
mark_inode_dirty(inode);
ext2_free_branches(inode, , +1, 2);
}
+   /* fall through */
case EXT2_DIND_BLOCK:
nr = i_data[EXT2_TIND_BLOCK];
if (nr) {
-- 
2.19.2

[PATCH v1] mfd: intel-lpss: Move linux/pm.h to the local header

[Andy Shevchenko]

We now using a common macro for PM operations in Intel LPSS driver,
and, since that macro relies on the definition and macro from linux/pm.h
header file, it's logical to include it directly in intel-lpss.h.
Otherwise it's a bit fragile and requires a proper ordering
of header inclusion in C files.

Signed-off-by: Andy Shevchenko 
---
 drivers/mfd/intel-lpss-acpi.c | 1 -
 drivers/mfd/intel-lpss-pci.c  | 1 -
 drivers/mfd/intel-lpss.h  | 2 ++
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
index 7911b0a14a6d..6d9f03363ee7 100644
--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 0e5282fc1467..cba2eb166650 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h
index 865bbeaaf00c..3a120fecd2dc 100644
--- a/drivers/mfd/intel-lpss.h
+++ b/drivers/mfd/intel-lpss.h
@@ -14,6 +14,8 @@
 #ifndef __MFD_INTEL_LPSS_H
 #define __MFD_INTEL_LPSS_H
 
+#include 
+
 struct device;
 struct resource;
 struct property_entry;
-- 
2.20.1

Re: [RFC PATCH] x86, numa: always initialize all possible nodes

[Mike Rapoport]

On Thu, Jan 24, 2019 at 03:17:27PM +0100, Michal Hocko wrote:
> a friendly ping for this. Does anybody see any problem with this
> approach?

FWIW, it looks fine to me.

It'd just be nice to have a few more words in the changelog about *how* the
x86 init was reworked ;-)
 
> On Mon 14-01-19 09:24:16, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > Pingfan Liu has reported the following splat
> > [5.772742] BUG: unable to handle kernel paging request at 
> > 2088
> > [5.773618] PGD 0 P4D 0
> > [5.773618] Oops:  [#1] SMP NOPTI
> > [5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
> > [5.773618] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.4.3 
> > 06/29/2018
> > [5.773618] RIP: 0010:__alloc_pages_nodemask+0xe2/0x2a0
> > [5.773618] Code: 00 00 44 89 ea 80 ca 80 41 83 f8 01 44 0f 44 ea 89 da 
> > c1 ea 08 83 e2 01 88 54 24 20 48 8b 54 24 08 48 85 d2 0f 85 46 01 00 00 
> > <3b> 77 08 0f 82 3d 01 00 00 48 89 f8 44 89 ea 48 89
> > e1 44 89 e6 89
> > [5.773618] RSP: 0018:aa65fb20 EFLAGS: 00010246
> > [5.773618] RAX:  RBX: 006012c0 RCX: 
> > 
> > [5.773618] RDX:  RSI: 0002 RDI: 
> > 2080
> > [5.773618] RBP: 006012c0 R08:  R09: 
> > 0002
> > [5.773618] R10: 006080c0 R11: 0002 R12: 
> > 
> > [5.773618] R13: 0001 R14:  R15: 
> > 0002
> > [5.773618] FS:  () GS:8c69afe0() 
> > knlGS:
> > [5.773618] CS:  0010 DS:  ES:  CR0: 80050033
> > [5.773618] CR2: 2088 CR3: 00087e00a000 CR4: 
> > 003406e0
> > [5.773618] Call Trace:
> > [5.773618]  new_slab+0xa9/0x570
> > [5.773618]  ___slab_alloc+0x375/0x540
> > [5.773618]  ? pinctrl_bind_pins+0x2b/0x2a0
> > [5.773618]  __slab_alloc+0x1c/0x38
> > [5.773618]  __kmalloc_node_track_caller+0xc8/0x270
> > [5.773618]  ? pinctrl_bind_pins+0x2b/0x2a0
> > [5.773618]  devm_kmalloc+0x28/0x60
> > [5.773618]  pinctrl_bind_pins+0x2b/0x2a0
> > [5.773618]  really_probe+0x73/0x420
> > [5.773618]  driver_probe_device+0x115/0x130
> > [5.773618]  __driver_attach+0x103/0x110
> > [5.773618]  ? driver_probe_device+0x130/0x130
> > [5.773618]  bus_for_each_dev+0x67/0xc0
> > [5.773618]  ? klist_add_tail+0x3b/0x70
> > [5.773618]  bus_add_driver+0x41/0x260
> > [5.773618]  ? pcie_port_setup+0x4d/0x4d
> > [5.773618]  driver_register+0x5b/0xe0
> > [5.773618]  ? pcie_port_setup+0x4d/0x4d
> > [5.773618]  do_one_initcall+0x4e/0x1d4
> > [5.773618]  ? init_setup+0x25/0x28
> > [5.773618]  kernel_init_freeable+0x1c1/0x26e
> > [5.773618]  ? loglevel+0x5b/0x5b
> > [5.773618]  ? rest_init+0xb0/0xb0
> > [5.773618]  kernel_init+0xa/0x110
> > [5.773618]  ret_from_fork+0x22/0x40
> > [5.773618] Modules linked in:
> > [5.773618] CR2: 2088
> > [5.773618] ---[ end trace 1030c9120a03d081 ]---
> > 
> > with his AMD machine with the following topology
> >   NUMA node0 CPU(s): 0,8,16,24
> >   NUMA node1 CPU(s): 2,10,18,26
> >   NUMA node2 CPU(s): 4,12,20,28
> >   NUMA node3 CPU(s): 6,14,22,30
> >   NUMA node4 CPU(s): 1,9,17,25
> >   NUMA node5 CPU(s): 3,11,19,27
> >   NUMA node6 CPU(s): 5,13,21,29
> >   NUMA node7 CPU(s): 7,15,23,31
> > 
> > [0.007418] Early memory node ranges
> > [0.007419]   node   1: [mem 0x1000-0x0008efff]
> > [0.007420]   node   1: [mem 0x0009-0x0009]
> > [0.007422]   node   1: [mem 0x0010-0x5c3d6fff]
> > [0.007422]   node   1: [mem 0x643df000-0x68ff7fff]
> > [0.007423]   node   1: [mem 0x6c528000-0x6fff]
> > [0.007424]   node   1: [mem 0x0001-0x00047fff]
> > [0.007425]   node   5: [mem 0x00048000-0x00087eff]
> > 
> > and nr_cpus set to 4. The underlying reason is tha the device is bound
> > to node 2 which doesn't have any memory and init_cpu_to_node only
> > initializes memory-less nodes for possible cpus which nr_cpus restrics.
> > This in turn means that proper zonelists are not allocated and the page
> > allocator blows up.
> > 
> > Fix the issue by reworking how x86 initializes the memory less nodes.
> > The current implementation is hacked into the workflow and it doesn't
> > allow any flexibility. There is init_memory_less_node called for each
> > offline node that has a CPU as already mentioned above. This will make
> > sure that we will have a new online node without any memory. Much later
> > on we build a zone list for this node and things seem to work, except
> > they do not (e.g. due to nr_cpus). Not to mention that it doesn't really
> > make much sense to consider an empty node as 

Re: [PATCH v2] ipmi:pci: Blacklist a Realtek "IPMI" device

[Greg KH]

On Wed, Jan 23, 2019 at 05:44:57PM +0100, Paul Menzel wrote:
> From: Corey Minyard 
> Date: Thu, 15 Feb 2018 16:58:26 -0600
> 
> [ upstream commit bc48fa1b9d3b04106055b27078da824cd209865a ]
> 
> Realtek has some sort of "Virtual" IPMI device on the PCI bus as a
> KCS controller, but whatever it is, it's not one.  Ignore it if seen.
> 
> Reported-by: Chris Chiu 
> Signed-off-by: Corey Minyard 
> Tested-by: Daniel Drake 
> 
> [ Commit 13d0b35c (ipmi_si: Move PCI setup to another file) from Linux
>   4.15-rc1 has not been back ported, so the PCI code is still in
>   `drivers/char/ipmi/ipmi_si_intf.c`, requiring to apply the commit
>   manually.
> 
>   This fixes a 100 s boot delay on the HP EliteDesk 705 G4 MT with Linux
>   4.14.94. ]
> 
> Signed-off-by: Paul Menzel 
> ---
> 
> v2: Use tabs. Sorry for messing that up.

That worked, thanks.

greg k-h

[PATCH] media: ov5640: Fix set 15fps regression

[Jagan Teki]

The ov5640_try_frame_interval operation updates the FPS as per user
input based on default ov5640_frame_rate, OV5640_30_FPS which is failed
to update when user trigger 15fps.

So, initialize the default ov5640_frame_rate to OV5640_15_FPS so-that
it can satisfy to update all fps.

Fixes: 5a3ad937bc78 ("media: ov5640: Make the return rate type more explicit")
Signed-off-by: Jagan Teki 
---
 drivers/media/i2c/ov5640.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 5a909abd0a2d..4081c29176c6 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2072,7 +2072,7 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
 u32 width, u32 height)
 {
const struct ov5640_mode_info *mode;
-   enum ov5640_frame_rate rate = OV5640_30_FPS;
+   enum ov5640_frame_rate rate = OV5640_15_FPS;
int minfps, maxfps, best_fps, fps;
int i;
 
-- 
2.18.0.321.gffc6fa0e3

[for next][PATCH v2 2/2] platform/x86: Fix unmet dependency warning for SAMSUNG_Q10

[Sinan Kaya]

Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the
warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.

SAMSUNG_Q10 selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
depends on BACKLIGHT_LCD_SUPPORT.

Copy BACKLIGHT_LCD_SUPPORT dependency into SAMSUNG_Q10 to fix:

WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
  Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
  Selected by [y]:
  - SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]

Signed-off-by: Sinan Kaya 
---
 drivers/platform/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index b84c2c5b6684..129e37c296a7 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1127,7 +1127,7 @@ config INTEL_OAKTRAIL
 
 config SAMSUNG_Q10
tristate "Samsung Q10 Extras"
-   depends on ACPI
+   depends on ACPI && BACKLIGHT_LCD_SUPPORT
select BACKLIGHT_CLASS_DEVICE
---help---
  This driver provides support for backlight control on Samsung Q10
-- 
2.19.0

[for next][PATCH v2 1/2] platform/x86: Fix unmet dependency warning for ACPI_CMPC

[Sinan Kaya]

Add BACKLIGHT_LCD_SUPPORT for ACPI_CMPC to fix the
warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.

ACPI_CMPC selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
depends on BACKLIGHT_LCD_SUPPORT.

Copy BACKLIGHT_LCD_SUPPORT dependency into ACPI_CMPC to fix

WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
  Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
  Selected by [y]:
  - ACPI_CMPC [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] && 
INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n)

Signed-off-by: Sinan Kaya 
---
 drivers/platform/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 5e2109c54c7c..b84c2c5b6684 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -904,7 +904,7 @@ config TOSHIBA_WMI
 
 config ACPI_CMPC
tristate "CMPC Laptop Extras"
-   depends on ACPI && INPUT
+   depends on ACPI && INPUT && BACKLIGHT_LCD_SUPPORT
depends on RFKILL || RFKILL=n
select BACKLIGHT_CLASS_DEVICE
help
-- 
2.19.0

[PATCH] arm64: dts: allwinner: a64-amarula-relic: Add STLM75 sensor

[Jagan Teki]

Amarula A64 Relic has STLM75 sensor for digital temperature
and thermal watchdog.

Add support for it.

Signed-off-by: Jagan Teki 
---
Note: the respective driver change is already in mainline
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2e9a41bbc1079776dabe42ed8113b086b99ae56c

 .../dts/allwinner/sun50i-a64-amarula-relic.dts| 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index 6cb2b7f0c817..5d942543d978 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -34,6 +34,21 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+
+   temp@48 {
+   compatible = "st,stlm75";
+   reg = <0x48>;
+   };
+};
+
+_pins {
+   bias-pull-up;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.18.0.321.gffc6fa0e3

Re: [PATCH v4 RESEND] drm/panel: add Kingdisplay kd097d04 panel driver

[Sean Paul]

On Thu, Jan 24, 2019 at 05:18:12PM +0100, Thierry Reding wrote:
> On Thu, Jan 24, 2019 at 12:01:55PM -0300, Ezequiel Garcia wrote:
> > On Tue, 2018-10-30 at 10:15 +0100, Heiko Stuebner wrote:
> > > From: Nickey Yang 
> > > 
> > > Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
> > > it is a MIPI dual-DSI panel.
> > > 
> > > v4-resend:
> > > - Thierry noted missing dt-bindings for v4 but forgot that he
> > >   already had applied them one kernel release back in
> > >   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebc950fdff6d5f9250cd5a5a348af97f7d8508df
> > > v4:
> > > - address Philipp's comments
> > >   - real range for usleep_range and
> > >   - poweroff ordering in kingdisplay_panel_prepare
> > >   - return value beautification in panel_probe
> > > - update author naming for full name
> > > v3:
> > > - address Thierry's comments
> > >   - error handling for init dsi writes in init
> > >   - unconditionally remove the panel
> > >   - don't use drm_panel_detach
> > >   - a bit of variable signednes wiggling
> > > - I did talk to ChromeOS people and the delays really should be as short
> > >   as possible, so dropped the 100ms from the delay comments
> > > v2:
> > > - update timing + cmds from chromeos kernel
> > > - new backlight API including switch to devm_of_find_backlight
> > > - fix most of Sean Paul's comments
> > >   enable/prepare tracking seems something all panels do
> > > - document origins of the init sequence
> > > - lanes per dsi interface to 4 (two interfaces). Matches how tegra
> > >   and pending rockchip dual-dsi handle (dual-)dsi lanes
> > > - spdx header instead of license boilerplate
> > > 
> > > Signed-off-by: Nickey Yang 
> > > Signed-off-by: Heiko Stuebner 
> > 
> > Hm, this v4 patch has been stalling here for *four full months*.
> > 
> > Which deity do we need to pray to get this one moving? ;-)
> > 
> > Seriously, can someone please apply this?
> 
> If you care about this driver, perhaps you'd like to review and provide
> a Reviewed-by?

Looks good to me,

Reviewed-by: Sean Paul 

> 
> Thierry



-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH 1/5 v9] regulator: gpio: Convert to use descriptors

[Mark Brown]

On Mon, Jan 21, 2019 at 10:12:02AM +0100, Linus Walleij wrote:
> This converts the GPIO regulator driver to use decriptors only.

This patch breaks the build for me:

drivers/regulator/gpio-regulator.c: In function ‘gpio_regulator_probe’:
drivers/regulator/gpio-regulator.c:256:33: error: ‘dev’ undeclared (first use 
in this function); did you mean ‘pdev’?
  drvdata->gpiods = devm_kzalloc(dev, sizeof(struct gpio_desc *),


signature.asc
Description: PGP signature

[PATCH 4/7] MIPS: SGI-IP27: do xtalk scanning later

[Thomas Bogendoerfer]

Move xtalk scanning to a later boot stage to be able using things like
kmalloc and friends.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/sgi-ip27/ip27-init.c  |  3 ---
 arch/mips/sgi-ip27/ip27-xtalk.c | 13 -
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/mips/sgi-ip27/ip27-init.c b/arch/mips/sgi-ip27/ip27-init.c
index 83399e578b61..aba985cf07c0 100644
--- a/arch/mips/sgi-ip27/ip27-init.c
+++ b/arch/mips/sgi-ip27/ip27-init.c
@@ -52,8 +52,6 @@ EXPORT_SYMBOL_GPL(sn_cpu_info);
 
 extern void pcibr_setup(cnodeid_t);
 
-extern void xtalk_probe_node(cnodeid_t nid);
-
 static void per_hub_init(cnodeid_t cnode)
 {
struct hub_data *hub = hub_data(cnode);
@@ -71,7 +69,6 @@ static void per_hub_init(cnodeid_t cnode)
REMOTE_HUB_S(nasid, IIO_ICTO, 0xff);
 
hub_rtc_init(cnode);
-   xtalk_probe_node(cnode);
 
 #ifdef CONFIG_REPLICATE_EXHANDLERS
/*
diff --git a/arch/mips/sgi-ip27/ip27-xtalk.c b/arch/mips/sgi-ip27/ip27-xtalk.c
index 4fe5678ba74d..ce06aaa115ae 100644
--- a/arch/mips/sgi-ip27/ip27-xtalk.c
+++ b/arch/mips/sgi-ip27/ip27-xtalk.c
@@ -99,7 +99,7 @@ static int xbow_probe(nasid_t nasid)
return 0;
 }
 
-void xtalk_probe_node(cnodeid_t nid)
+static void xtalk_probe_node(cnodeid_t nid)
 {
volatile u64hubreg;
nasid_t nasid;
@@ -133,3 +133,14 @@ void xtalk_probe_node(cnodeid_t nid)
break;
}
 }
+
+static int __init xtalk_init(void)
+{
+   cnodeid_t cnode;
+
+   for_each_online_node(cnode)
+   xtalk_probe_node(cnode);
+
+   return 0;
+}
+arch_initcall(xtalk_init);
-- 
2.13.7

[PATCH 2/7] MIPS: SGI-IP27: clean up bridge access and header files

[Thomas Bogendoerfer]

Introduced bridge_read/bridge_write/bridge_set/bridge_clr for accessing
bridge register and get rid of volatile declarations. Also removed
all typedefs from arch/mips/include/asm/pci/bridge.h and cleaned up
language in arch/mips/pci/ops-bridge.c

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/pci/bridge.h   | 217 +--
 arch/mips/include/asm/sn/sn0/addrs.h |   5 -
 arch/mips/pci/ops-bridge.c   |  68 ---
 arch/mips/pci/pci-ip27.c |  31 +++--
 arch/mips/sgi-ip27/ip27-irq-pci.c|  24 ++--
 5 files changed, 153 insertions(+), 192 deletions(-)

diff --git a/arch/mips/include/asm/pci/bridge.h 
b/arch/mips/include/asm/pci/bridge.h
index 3206245d1ed6..6155618ce45b 100644
--- a/arch/mips/include/asm/pci/bridge.h
+++ b/arch/mips/include/asm/pci/bridge.h
@@ -44,19 +44,37 @@
  */
 
 #ifndef __ASSEMBLY__
+/* Address translation entry for mapped pci32 accesses */
+union bridge_ate {
+   u64 ent;
+   struct ate_s {
+   u64 rmf:16;
+   u64 addr:36;
+   u64 targ:4;
+   u64 reserved:3;
+   u64 barrier:1;
+   u64 prefetch:1;
+   u64 precise:1;
+   u64 coherent:1;
+   u64 valid:1;
+   } field;
+};
 
-/*
- * All accesses to bridge hardware registers must be done
- * using 32-bit loads and stores.
- */
-typedef u32bridgereg_t;
+#define ATE_V  0x01
+#define ATE_CO 0x02
+#define ATE_PREC   0x04
+#define ATE_PREF   0x08
+#define ATE_BAR0x10
 
-typedef u64bridge_ate_t;
+#define ATE_PFNSHIFT   12
+#define ATE_TIDSHIFT   8
+#define ATE_RMFSHIFT   48
 
-/* pointers to bridge ATEs
- * are always "pointer to volatile"
- */
-typedef volatile bridge_ate_t  *bridge_ate_p;
+#define mkate(xaddr, xid, attr) (((xaddr) & 0xf000ULL) | \
+((xid)base->reg)
+#define bridge_write(bc, reg, val) __raw_writel(val, >base->reg)
+#define bridge_set(bc, reg, val)   \
+   __raw_writel(__raw_readl(>base->reg) | (val), >base->reg)
+#define bridge_clr(bc, reg, val)   \
+   __raw_writel(__raw_readl(>base->reg) & ~(val), >base->reg)
+
 extern void register_bridge_irq(unsigned int irq);
 extern int request_bridge_irq(struct bridge_controller *bc);
 
diff --git a/arch/mips/include/asm/sn/sn0/addrs.h 
b/arch/mips/include/asm/sn/sn0/addrs.h
index 6b53070f400f..f13df84edfdd 100644
--- a/arch/mips/include/asm/sn/sn0/addrs.h
+++ b/arch/mips/include/asm/sn/sn0/addrs.h
@@ -134,11 +134,6 @@
 
 #define CALIAS_BASECAC_BASE
 
-
-
-#define BRIDGE_REG_PTR(_base, _off)((volatile bridgereg_t *) \
-   ((__psunsigned_t)(_base) + (__psunsigned_t)(_off)))
-
 #define SN0_WIDGET_BASE(_nasid, _wid)  (NODE_SWIN_BASE((_nasid), (_wid)))
 
 /* Turn on sable logging for the processors whose bits are set. */
diff --git a/arch/mips/pci/ops-bridge.c b/arch/mips/pci/ops-bridge.c
index a1d2c4ae0d1b..df95b0da08f2 100644
--- a/arch/mips/pci/ops-bridge.c
+++ b/arch/mips/pci/ops-bridge.c
@@ -44,7 +44,7 @@ static int pci_conf0_read_config(struct pci_bus *bus, 
unsigned int devfn,
 int where, int size, u32 * value)
 {
struct bridge_controller *bc = BRIDGE_CONTROLLER(bus);
-   bridge_t *bridge = bc->base;
+   struct bridge_regs *bridge = bc->base;
int slot = PCI_SLOT(devfn);
int fn = PCI_FUNC(devfn);
volatile void *addr;
@@ -56,11 +56,11 @@ static int pci_conf0_read_config(struct pci_bus *bus, 
unsigned int devfn,
return PCIBIOS_DEVICE_NOT_FOUND;
 
/*
-* IOC3 is fucking fucked beyond belief ...  Don't even give the
+* IOC3 is broken beyond belief ...  Don't even give the
 * generic PCI code a chance to look at it for real ...
 */
if (cf == (PCI_VENDOR_ID_SGI | (PCI_DEVICE_ID_SGI_IOC3 << 16)))
-   goto oh_my_gawd;
+   goto is_ioc3;
 
addr = >b_type0_cfg_dev[slot].f[fn].c[where ^ (4 - size)];
 
@@ -73,21 +73,16 @@ static int pci_conf0_read_config(struct pci_bus *bus, 
unsigned int devfn,
 
return res ? PCIBIOS_DEVICE_NOT_FOUND : PCIBIOS_SUCCESSFUL;
 
-oh_my_gawd:
+is_ioc3:
 
/*
-* IOC3 is fucking fucked beyond belief ...  Don't even give the
-* generic PCI code a chance to look at the wrong register.
+* IOC3 special handling
 */
if ((where >= 0x14 && where < 0x40) || (where >= 0x48)) {
*value = emulate_ioc3_cfg(where, size);
return PCIBIOS_SUCCESSFUL;
}
 
-   /*
-* IOC3 is fucking fucked beyond belief ...  Don't try to access
-* anything but 32-bit words ...
-*/
addr = >b_type0_cfg_dev[slot].f[fn].l[where >> 2];
 
if (get_dbe(cf, (u32 *) addr))
@@ 

[PATCH 6/7] MIPS: SGI-IP27: use generic PCI driver

[Thomas Bogendoerfer]

Converted bridge code to a platform driver using the PCI generic driver
framework and use adding platform devices during xtalk scan. This allows
easier sharing bridge drvier for other SGI platforms like IP30 (Octane) and
IP35 (Origin 3k, Fuel, Tezro).

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/Kconfig  |   2 +
 arch/mips/include/asm/pci/bridge.h |   6 +-
 arch/mips/include/asm/xtalk/xtalk.h|   9 -
 arch/mips/pci/Makefile |   1 -
 arch/mips/pci/pci-ip27.c   | 214 ---
 arch/mips/sgi-ip27/ip27-init.c |   2 +
 arch/mips/sgi-ip27/ip27-xtalk.c|  31 ++-
 drivers/pci/controller/Kconfig |   3 +
 drivers/pci/controller/Makefile|   1 +
 .../pci/controller/pci-xtalk-bridge.c  | 288 +
 include/linux/platform_data/xtalk-bridge.h |  17 ++
 11 files changed, 286 insertions(+), 288 deletions(-)
 delete mode 100644 arch/mips/pci/pci-ip27.c
 rename arch/mips/pci/ops-bridge.c => drivers/pci/controller/pci-xtalk-bridge.c 
(51%)
 create mode 100644 include/linux/platform_data/xtalk-bridge.h

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7d7f5d79af41..f2f258abee59 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -678,6 +678,8 @@ config SGI_IP27
select HAVE_PCI
select IRQ_MIPS_CPU
select NR_CPUS_DEFAULT_64
+   select PCI_DRIVERS_GENERIC
+   select PCI_XTALK_BRIDGE
select SYS_HAS_CPU_R1
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
diff --git a/arch/mips/include/asm/pci/bridge.h 
b/arch/mips/include/asm/pci/bridge.h
index 1fc60b1ae349..af2da166815e 100644
--- a/arch/mips/include/asm/pci/bridge.h
+++ b/arch/mips/include/asm/pci/bridge.h
@@ -816,15 +816,13 @@ struct bridge_err_cmdword {
 #define PCI64_ATTR_RMF_SHFT48
 
 struct bridge_controller {
-   struct pci_controller   pc;
struct resource mem;
struct resource io;
struct resource busn;
struct bridge_regs  *base;
-   nasid_t nasid;
-   unsigned intwidget_id;
u64 baddr;
unsigned intpci_int[8];
+   nasid_t nasid;
 };
 
 #define BRIDGE_CONTROLLER(bus) \
@@ -839,6 +837,4 @@ struct bridge_controller {
 
 extern int request_bridge_irq(struct bridge_controller *bc, int pin);
 
-extern struct pci_ops bridge_pci_ops;
-
 #endif /* _ASM_PCI_BRIDGE_H */
diff --git a/arch/mips/include/asm/xtalk/xtalk.h 
b/arch/mips/include/asm/xtalk/xtalk.h
index 26d2ed1fa917..680e7efebbaf 100644
--- a/arch/mips/include/asm/xtalk/xtalk.h
+++ b/arch/mips/include/asm/xtalk/xtalk.h
@@ -47,15 +47,6 @@ typedef struct xtalk_piomap_s *xtalk_piomap_t;
 #define XIO_PORT(x)((xwidgetnum_t)(((x)_PORT_BITS) >> XIO_PORT_SHIFT))
 #define XIO_PACK(p, o) uint64_t)(p))<
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * Max #PCI busses we can handle; ie, max #PCI bridges.
- */
-#define MAX_PCI_BUSSES 40
-
-/*
- * XXX: No kmalloc available when we do our crosstalk scan,
- * we should try to move it later in the boot process.
- */
-static struct bridge_controller bridges[MAX_PCI_BUSSES];
-
-extern struct pci_ops bridge_pci_ops;
-
-int bridge_probe(nasid_t nasid, int widget_id, int masterwid)
-{
-   unsigned long offset = NODE_OFFSET(nasid);
-   struct bridge_controller *bc;
-   static int num_bridges = 0;
-   int slot;
-
-   pci_set_flags(PCI_PROBE_ONLY);
-
-   printk("a bridge\n");
-
-   /* XXX: kludge alert.. */
-   if (!num_bridges)
-   ioport_resource.end = ~0UL;
-
-   bc = [num_bridges];
-
-   bc->pc.pci_ops  = _pci_ops;
-   bc->pc.mem_resource = >mem;
-   bc->pc.io_resource  = >io;
-
-   bc->pc.index= num_bridges;
-
-   bc->mem.name= "Bridge PCI MEM";
-   bc->pc.mem_offset   = offset;
-   bc->mem.start   = 0;
-   bc->mem.end = ~0UL;
-   bc->mem.flags   = IORESOURCE_MEM;
-
-   bc->io.name = "Bridge IO MEM";
-   bc->pc.io_offset= offset;
-   bc->io.start= 0UL;
-   bc->io.end  = ~0UL;
-   bc->io.flags= IORESOURCE_IO;
-
-   bc->widget_id = widget_id;
-   bc->nasid = nasid;
-
-   bc->baddr = (u64)masterwid << 60 | PCI64_ATTR_BAR;
-
-   /*
-* point to this bridge
-*/
-   bc->base = (struct bridge_regs *)RAW_NODE_SWIN_BASE(nasid, widget_id);
-
-   /*
-* Clear all pending interrupts.
-*/
-   bridge_write(bc, b_int_rst_stat, BRIDGE_IRR_ALL_CLR);
-
-   /*
-* Until otherwise set up, assume all interrupts are from slot 0
-*/
-   

[PATCH 1/7] MIPS: SGI-IP27: get rid of volatile and hubreg_t

[Thomas Bogendoerfer]

Replace hub register access with __raw_readq/__raw_writeq and get
rid of hubreg_t completely. Also remove no longer (probably never)
used defines

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/sn/addrs.h | 63 +++-
 arch/mips/include/asm/sn/arch.h  |  2 --
 arch/mips/sgi-ip27/ip27-hubio.c  |  2 +-
 arch/mips/sgi-ip27/ip27-init.c   |  2 +-
 arch/mips/sgi-ip27/ip27-irq.c|  4 +--
 arch/mips/sgi-ip27/ip27-memory.c |  6 ++--
 arch/mips/sgi-ip27/ip27-nmi.c|  2 +-
 7 files changed, 12 insertions(+), 69 deletions(-)

diff --git a/arch/mips/include/asm/sn/addrs.h b/arch/mips/include/asm/sn/addrs.h
index 66814f8ba8e8..3eb81e30a568 100644
--- a/arch/mips/include/asm/sn/addrs.h
+++ b/arch/mips/include/asm/sn/addrs.h
@@ -27,16 +27,11 @@
 
 #ifndef __ASSEMBLY__
 
-#define PS_UINT_CAST   (unsigned long)
 #define UINT64_CAST(unsigned long)
 
-#define HUBREG_CAST(volatile hubreg_t *)
-
 #else /* __ASSEMBLY__ */
 
-#define PS_UINT_CAST
 #define UINT64_CAST
-#define HUBREG_CAST
 
 #endif /* __ASSEMBLY__ */
 
@@ -256,42 +251,22 @@
  * Otherwise, the recommended approach is to use *_HUB_L() and *_HUB_S().
  * They're always safe.
  */
-#define LOCAL_HUB_ADDR(_x) (HUBREG_CAST (IALIAS_BASE + (_x)))
-#define REMOTE_HUB_ADDR(_n, _x) (HUBREG_CAST (NODE_SWIN_BASE(_n, 1) +  \
- 0x80 + (_x)))
-#ifdef CONFIG_SGI_IP27
-#define REMOTE_HUB_PI_ADDR(_n, _sn, _x) (HUBREG_CAST (NODE_SWIN_BASE(_n, 1) +  
\
- 0x80 + (_x)))
-#endif /* CONFIG_SGI_IP27 */
+#define LOCAL_HUB_ADDR(_x) (IALIAS_BASE + (_x))
+#define REMOTE_HUB_ADDR(_n, _x) ((NODE_SWIN_BASE(_n, 1) + 0x80 + (_x)))
 
 #ifndef __ASSEMBLY__
 
-#define HUB_L(_a)  *(_a)
-#define HUB_S(_a, _d)  *(_a) = (_d)
+#define HUB_L(_a)  __raw_readq((u64 *)(_a))
+#define HUB_S(_a, _d)  __raw_writeq((_d), (u64 *)(_a))
 
 #define LOCAL_HUB_L(_r)HUB_L(LOCAL_HUB_ADDR(_r))
 #define LOCAL_HUB_S(_r, _d)HUB_S(LOCAL_HUB_ADDR(_r), (_d))
 #define REMOTE_HUB_L(_n, _r)   HUB_L(REMOTE_HUB_ADDR((_n), (_r)))
 #define REMOTE_HUB_S(_n, _r, _d)   HUB_S(REMOTE_HUB_ADDR((_n), (_r)), (_d))
-#define REMOTE_HUB_PI_L(_n, _sn, _r)   HUB_L(REMOTE_HUB_PI_ADDR((_n), (_sn), 
(_r)))
-#define REMOTE_HUB_PI_S(_n, _sn, _r, _d) HUB_S(REMOTE_HUB_PI_ADDR((_n), (_sn), 
(_r)), (_d))
 
 #endif /* !__ASSEMBLY__ */
 
 /*
- * The following macros are used to get to a hub/bridge register, given
- * the base of the register space.
- */
-#define HUB_REG_PTR(_base, _off)   \
-   (HUBREG_CAST((__psunsigned_t)(_base) + (__psunsigned_t)(_off)))
-
-#define HUB_REG_PTR_L(_base, _off) \
-   HUB_L(HUB_REG_PTR((_base), (_off)))
-
-#define HUB_REG_PTR_S(_base, _off, _data)  \
-   HUB_S(HUB_REG_PTR((_base), (_off)), (_data))
-
-/*
  * Software structure locations -- permanently fixed
  *See diagram in kldir.h
  */
@@ -387,44 +362,14 @@
 
 #define SYMMON_STK_END(nasid)  (SYMMON_STK_ADDR(nasid, 0) + 
KLD_SYMMON_STK(nasid)->size)
 
-/* loading symmon 4k below UNIX. the arcs loader needs the topaddr for a
- * relocatable program
- */
-#define UNIX_DEBUG_LOADADDR0x30
-#define SYMMON_LOADADDR(nasid) \
-   TO_NODE(nasid, PHYS_TO_K0(UNIX_DEBUG_LOADADDR - 0x1000))
-
-#define FREEMEM_OFFSET(nasid)  KLD_FREEMEM(nasid)->offset
-#define FREEMEM_ADDR(nasid)SYMMON_STK_END(nasid)
-/*
- * XXX
- * Fix this. FREEMEM_ADDR should be aware of if symmon is loaded.
- * Also, it should take into account what prom thinks to be a safe
- * address
-   PHYS_TO_K0(NODE_OFFSET(nasid) + FREEMEM_OFFSET(nasid))
- */
-#define FREEMEM_SIZE(nasid)KLD_FREEMEM(nasid)->size
-
-#define PI_ERROR_OFFSET(nasid) KLD_PI_ERROR(nasid)->offset
-#define PI_ERROR_ADDR(nasid)   \
-   TO_NODE_UNCAC((nasid), PI_ERROR_OFFSET(nasid))
-#define PI_ERROR_SIZE(nasid)   KLD_PI_ERROR(nasid)->size
-
 #define NODE_OFFSET_TO_K0(_nasid, _off)
\
PHYS_TO_K0((NODE_OFFSET(_nasid) + (_off)) | CAC_BASE)
 #define NODE_OFFSET_TO_K1(_nasid, _off)
\
TO_UNCAC((NODE_OFFSET(_nasid) + (_off)) | UNCAC_BASE)
-#define K0_TO_NODE_OFFSET(_k0addr) \
-   ((__psunsigned_t)(_k0addr) & NODE_ADDRSPACE_MASK)
 
 #define KERN_VARS_ADDR(nasid)  KLD_KERN_VARS(nasid)->pointer
 #define KERN_VARS_SIZE(nasid)  KLD_KERN_VARS(nasid)->size
 
-#define KERN_XP_ADDR(nasid)KLD_KERN_XP(nasid)->pointer
-#define KERN_XP_SIZE(nasid)KLD_KERN_XP(nasid)->size
-
-#define GPDA_ADDR(nasid)   TO_NODE_CAC(nasid, GPDA_OFFSET)
-
 #endif /* !__ASSEMBLY__ */
 
 
diff --git a/arch/mips/include/asm/sn/arch.h b/arch/mips/include/asm/sn/arch.h
index 471e6870d876..3f1fb1454749 100644

[PATCH 7/7] MIPS: SGI-IP27: abstract chipset irq from bridge

[Thomas Bogendoerfer]

Bridge ASIC is widely used in different SGI systems, but the connected
chipset is either HUB, HEART or BEDROCK. This commit abstracts chipset
irq setup and moves the bridge related irq setup to bridge code.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/pci/bridge.h|  2 -
 arch/mips/include/asm/sn/intr.h   |  7 
 arch/mips/sgi-ip27/ip27-irq.c | 67 ---
 drivers/pci/controller/pci-xtalk-bridge.c | 64 -
 4 files changed, 87 insertions(+), 53 deletions(-)

diff --git a/arch/mips/include/asm/pci/bridge.h 
b/arch/mips/include/asm/pci/bridge.h
index af2da166815e..9b13bda5c3f6 100644
--- a/arch/mips/include/asm/pci/bridge.h
+++ b/arch/mips/include/asm/pci/bridge.h
@@ -835,6 +835,4 @@ struct bridge_controller {
 #define bridge_clr(bc, reg, val)   \
__raw_writel(__raw_readl(>base->reg) & ~(val), >base->reg)
 
-extern int request_bridge_irq(struct bridge_controller *bc, int pin);
-
 #endif /* _ASM_PCI_BRIDGE_H */
diff --git a/arch/mips/include/asm/sn/intr.h b/arch/mips/include/asm/sn/intr.h
index fc1348193957..9c9f2e883a71 100644
--- a/arch/mips/include/asm/sn/intr.h
+++ b/arch/mips/include/asm/sn/intr.h
@@ -126,4 +126,11 @@ do {   
\
 #define NI_ERROR_INTR  62
 #define MSC_PANIC_INTR 63
 
+struct irq_source_ops {
+   void (*start_irq_source)(cpuid_t cpu, int bit, void *d);
+   void (*stop_irq_source)(cpuid_t cpu, int bit, void *d);
+};
+
+extern int request_chipset_irq(struct irq_source_ops *o, void *d, nasid_t n);
+
 #endif /* __ASM_SN_INTR_H */
diff --git a/arch/mips/sgi-ip27/ip27-irq.c b/arch/mips/sgi-ip27/ip27-irq.c
index a9db2f28b609..cac5f6956048 100644
--- a/arch/mips/sgi-ip27/ip27-irq.c
+++ b/arch/mips/sgi-ip27/ip27-irq.c
@@ -12,10 +12,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -23,11 +23,11 @@
 #include 
 
 struct hub_irq_data {
-   struct bridge_controller *bc;
+   struct irq_source_ops *isrc_ops;
+   void*isrc_data;
u64 irq_mask_addr[2];
cpuid_t cpu;
int bit;
-   int pin;
 };
 
 static DECLARE_BITMAP(hub_irq_map, IP27_HUB_IRQ_COUNT);
@@ -67,65 +67,32 @@ static void disable_hub_irq(struct irq_data *d)
HUB_S(hd->irq_mask_addr[1], si->irq_enable_mask[1]);
 }
 
-static unsigned int startup_bridge_irq(struct irq_data *d)
+static unsigned int startup_hub_irq(struct irq_data *d)
 {
struct hub_irq_data *hd = irq_data_get_irq_chip_data(d);
-   struct bridge_controller *bc;
-   nasid_t nasid;
-   u32 device;
-   int pin;
 
if (!hd)
return -EINVAL;
 
-   pin = hd->pin;
-   bc = hd->bc;
-
-   nasid = COMPACT_TO_NASID_NODEID(cpu_to_node(hd->cpu));
-   bridge_write(bc, b_int_addr[pin].addr,
-(0x2 | hd->bit | (nasid << 8)));
-   bridge_set(bc, b_int_enable, (1 << pin));
-   bridge_set(bc, b_int_enable, 0x7e00); /* more stuff in int_enable */
-
-   /*
-* Enable sending of an interrupt clear packt to the hub on a high to
-* low transition of the interrupt pin.
-*
-* IRIX sets additional bits in the address which are documented as
-* reserved in the bridge docs.
-*/
-   bridge_set(bc, b_int_mode, (1UL << pin));
-
-   /*
-* We assume the bridge to have a 1:1 mapping between devices
-* (slots) and intr pins.
-*/
-   device = bridge_read(bc, b_int_device);
-   device &= ~(7 << (pin*3));
-   device |= (pin << (pin*3));
-   bridge_write(bc, b_int_device, device);
-
-   bridge_read(bc, b_wid_tflush);
+   if (hd->isrc_ops && hd->isrc_ops->start_irq_source)
+   hd->isrc_ops->start_irq_source(hd->cpu, hd->bit, hd->isrc_data);
 
enable_hub_irq(d);
 
return 0;   /* Never anything pending.  */
 }
 
-static void shutdown_bridge_irq(struct irq_data *d)
+static void shutdown_hub_irq(struct irq_data *d)
 {
struct hub_irq_data *hd = irq_data_get_irq_chip_data(d);
-   struct bridge_controller *bc;
-   int pin = hd->pin;
 
if (!hd)
return;
 
disable_hub_irq(d);
 
-   bc = hd->bc;
-   bridge_clr(bc, b_int_enable, (1 << pin));
-   bridge_read(bc, b_wid_tflush);
+   if (hd->isrc_ops && hd->isrc_ops->stop_irq_source)
+   hd->isrc_ops->stop_irq_source(hd->cpu, hd->bit, hd->isrc_data);
 }
 
 static void setup_hub_mask(struct hub_irq_data *hd, const struct cpumask *mask)
@@ -162,7 +129,7 @@ static int set_affinity_hub_irq(struct irq_data *d, const 
struct cpumask *mask,
setup_hub_mask(hd, mask);
 
if (irqd_is_started(d))
-   startup_bridge_irq(d);
+   startup_hub_irq(d);
 
irq_data_update_effective_affinity(d, cpumask_of(hd->cpu));
 
@@ -171,14 +138,14 

[PATCH 3/7] MIPS: SGI-IP27: use pr_info/pr_emerg and pr_cont to fix output

[Thomas Bogendoerfer]

Topology and NMI output needs pr_cont() to look the way it was in the
old days of printk.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/sgi-ip27/ip27-memory.c | 28 +-
 arch/mips/sgi-ip27/ip27-nmi.c| 62 
 2 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/arch/mips/sgi-ip27/ip27-memory.c b/arch/mips/sgi-ip27/ip27-memory.c
index 87ef4181934e..fb077a947575 100644
--- a/arch/mips/sgi-ip27/ip27-memory.c
+++ b/arch/mips/sgi-ip27/ip27-memory.c
@@ -154,11 +154,11 @@ static int __init compute_node_distance(nasid_t nasid_a, 
nasid_t nasid_b)
}
 
if (router_a == NULL) {
-   printk("node_distance: router_a NULL\n");
+   pr_info("node_distance: router_a NULL\n");
return -1;
}
if (router_b == NULL) {
-   printk("node_distance: router_b NULL\n");
+   pr_info("node_distance: router_b NULL\n");
return -1;
}
 
@@ -203,17 +203,17 @@ static void __init dump_topology(void)
klrou_t *router;
cnodeid_t row, col;
 
-   printk("** Topology \n");
+   pr_info("** Topology \n");
 
-   printk("");
+   pr_info("");
for_each_online_node(col)
-   printk("%02d ", col);
-   printk("\n");
+   pr_cont("%02d ", col);
+   pr_cont("\n");
for_each_online_node(row) {
-   printk("%02d  ", row);
+   pr_info("%02d  ", row);
for_each_online_node(col)
-   printk("%2d ", node_distance(row, col));
-   printk("\n");
+   pr_cont("%2d ", node_distance(row, col));
+   pr_cont("\n");
}
 
for_each_online_node(cnode) {
@@ -230,7 +230,7 @@ static void __init dump_topology(void)
do {
if (brd->brd_flags & DUPLICATE_BOARD)
continue;
-   printk("Router %d:", router_num);
+   pr_cont("Router %d:", router_num);
router_num++;
 
router = (klrou_t *)NODE_OFFSET_TO_K0(NASID_GET(brd), 
brd->brd_compts[0]);
@@ -244,11 +244,11 @@ static void __init dump_topology(void)
router->rou_port[port].port_offset);
 
if (dest_brd->brd_type == KLTYPE_IP27)
-   printk(" %d", dest_brd->brd_nasid);
+   pr_cont(" %d", dest_brd->brd_nasid);
if (dest_brd->brd_type == KLTYPE_ROUTER)
-   printk(" r");
+   pr_cont(" r");
}
-   printk("\n");
+   pr_cont("\n");
 
} while ( (brd = find_lboard_class(KLCF_NEXT(brd), 
KLTYPE_ROUTER)) );
}
@@ -373,7 +373,7 @@ static void __init szmem(void)
 
if ((nodebytes >> PAGE_SHIFT) * (sizeof(struct page)) >
(slot0sz << PAGE_SHIFT)) {
-   printk("Ignoring slot %d onwards on node %d\n",
+   pr_info("Ignoring slot %d onwards on node %d\n",
slot, node);
slot = MAX_MEM_SLOTS;
continue;
diff --git a/arch/mips/sgi-ip27/ip27-nmi.c b/arch/mips/sgi-ip27/ip27-nmi.c
index 8cb3a5d6d7d1..3aae388561d9 100644
--- a/arch/mips/sgi-ip27/ip27-nmi.c
+++ b/arch/mips/sgi-ip27/ip27-nmi.c
@@ -62,70 +62,70 @@ void nmi_cpu_eframe_save(nasid_t nasid, int slice)
(TO_UNCAC(TO_NODE(nasid, IP27_NMI_KREGS_OFFSET)) +
slice * IP27_NMI_KREGS_CPU_SIZE);
 
-   printk("NMI nasid %d: slice %d\n", nasid, slice);
+   pr_emerg("NMI nasid %d: slice %d\n", nasid, slice);
 
/*
 * Saved main processor registers
 */
for (i = 0; i < 32; ) {
if ((i % 4) == 0)
-   printk("$%2d   :", i);
-   printk(" %016lx", nr->gpr[i]);
+   pr_emerg("$%2d   :", i);
+   pr_cont(" %016lx", nr->gpr[i]);
 
i++;
if ((i % 4) == 0)
-   printk("\n");
+   pr_cont("\n");
}
 
-   printk("Hi: (value lost)\n");
-   printk("Lo: (value lost)\n");
+   pr_emerg("Hi: (value lost)\n");
+   pr_emerg("Lo: (value lost)\n");
 
/*
 * Saved cp0 registers
 */
-   printk("epc   : %016lx %pS\n", nr->epc, (void *) nr->epc);
-   printk("%s\n", print_tainted());
-   printk("ErrEPC: %016lx %pS\n", nr->error_epc, (void *) nr->error_epc);
-   printk("ra: 

[PATCH 5/7] MIPS: SGI-IP27: rework HUB interrupts

[Thomas Bogendoerfer]

This commit rearranges the HUB interrupt code by using MIPS_IRQ_CPU
interrupt handling code and modern Linux IRQ framework features to get
rid of global and per cpu arrays. It also adds support for irq affinity
setting.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/Kconfig|   1 +
 arch/mips/include/asm/mach-ip27/irq.h|  12 +-
 arch/mips/include/asm/mach-ip27/mmzone.h |   2 -
 arch/mips/include/asm/pci/bridge.h   |   4 +-
 arch/mips/pci/pci-ip27.c |  18 +-
 arch/mips/sgi-ip27/Makefile  |   3 +-
 arch/mips/sgi-ip27/ip27-init.c   |  26 +--
 arch/mips/sgi-ip27/ip27-irq-pci.c| 264 -
 arch/mips/sgi-ip27/ip27-irq.c| 326 ++-
 arch/mips/sgi-ip27/ip27-irqno.c  |  48 -
 arch/mips/sgi-ip27/ip27-timer.c  |  42 +---
 11 files changed, 250 insertions(+), 496 deletions(-)
 delete mode 100644 arch/mips/sgi-ip27/ip27-irq-pci.c
 delete mode 100644 arch/mips/sgi-ip27/ip27-irqno.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0d14f51d0002..7d7f5d79af41 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -676,6 +676,7 @@ config SGI_IP27
select DEFAULT_SGI_PARTITION
select SYS_HAS_EARLY_PRINTK
select HAVE_PCI
+   select IRQ_MIPS_CPU
select NR_CPUS_DEFAULT_64
select SYS_HAS_CPU_R1
select SYS_SUPPORTS_64BIT_KERNEL
diff --git a/arch/mips/include/asm/mach-ip27/irq.h 
b/arch/mips/include/asm/mach-ip27/irq.h
index b0b7261ff3ad..fd91c58aaf7d 100644
--- a/arch/mips/include/asm/mach-ip27/irq.h
+++ b/arch/mips/include/asm/mach-ip27/irq.h
@@ -10,13 +10,15 @@
 #ifndef __ASM_MACH_IP27_IRQ_H
 #define __ASM_MACH_IP27_IRQ_H
 
-/*
- * A hardwired interrupt number is completely stupid for this system - a
- * large configuration might have thousands if not tenthousands of
- * interrupts.
- */
 #define NR_IRQS 256
 
 #include_next 
 
+#define IP27_HUB_PEND0_IRQ (MIPS_CPU_IRQ_BASE + 2)
+#define IP27_HUB_PEND1_IRQ (MIPS_CPU_IRQ_BASE + 3)
+#define IP27_RT_TIMER_IRQ  (MIPS_CPU_IRQ_BASE + 4)
+
+#define IP27_HUB_IRQ_BASE  (MIPS_CPU_IRQ_BASE + 8)
+#define IP27_HUB_IRQ_COUNT 128
+
 #endif /* __ASM_MACH_IP27_IRQ_H */
diff --git a/arch/mips/include/asm/mach-ip27/mmzone.h 
b/arch/mips/include/asm/mach-ip27/mmzone.h
index 2ed3094dee07..8114253f5976 100644
--- a/arch/mips/include/asm/mach-ip27/mmzone.h
+++ b/arch/mips/include/asm/mach-ip27/mmzone.h
@@ -12,7 +12,6 @@
 
 struct slice_data {
unsigned long irq_enable_mask[2];
-   int level_to_irq[LEVELS_PER_SLICE];
 };
 
 struct hub_data {
@@ -20,7 +19,6 @@ struct hub_data {
DECLARE_BITMAP(h_bigwin_used, HUB_NUM_BIG_WINDOW);
cpumask_t   h_cpus;
unsigned long slice_map;
-   unsigned long irq_alloc_mask[2];
struct slice_data slice[2];
 };
 
diff --git a/arch/mips/include/asm/pci/bridge.h 
b/arch/mips/include/asm/pci/bridge.h
index 6155618ce45b..1fc60b1ae349 100644
--- a/arch/mips/include/asm/pci/bridge.h
+++ b/arch/mips/include/asm/pci/bridge.h
@@ -823,7 +823,6 @@ struct bridge_controller {
struct bridge_regs  *base;
nasid_t nasid;
unsigned intwidget_id;
-   unsigned intirq_cpu;
u64 baddr;
unsigned intpci_int[8];
 };
@@ -838,8 +837,7 @@ struct bridge_controller {
 #define bridge_clr(bc, reg, val)   \
__raw_writel(__raw_readl(>base->reg) & ~(val), >base->reg)
 
-extern void register_bridge_irq(unsigned int irq);
-extern int request_bridge_irq(struct bridge_controller *bc);
+extern int request_bridge_irq(struct bridge_controller *bc, int pin);
 
 extern struct pci_ops bridge_pci_ops;
 
diff --git a/arch/mips/pci/pci-ip27.c b/arch/mips/pci/pci-ip27.c
index 7cf50290a6d9..3c177b4d0609 100644
--- a/arch/mips/pci/pci-ip27.c
+++ b/arch/mips/pci/pci-ip27.c
@@ -24,22 +24,11 @@
 #define MAX_PCI_BUSSES 40
 
 /*
- * Max #PCI devices (like scsi controllers) we handle on a bus.
- */
-#define MAX_DEVICES_PER_PCIBUS 8
-
-/*
  * XXX: No kmalloc available when we do our crosstalk scan,
  * we should try to move it later in the boot process.
  */
 static struct bridge_controller bridges[MAX_PCI_BUSSES];
 
-/*
- * Translate from irq to software PCI bus number and PCI slot.
- */
-struct bridge_controller *irq_to_bridge[MAX_PCI_BUSSES * 
MAX_DEVICES_PER_PCIBUS];
-int irq_to_slot[MAX_PCI_BUSSES * MAX_DEVICES_PER_PCIBUS];
-
 extern struct pci_ops bridge_pci_ops;
 
 int bridge_probe(nasid_t nasid, int widget_id, int masterwid)
@@ -77,7 +66,6 @@ int bridge_probe(nasid_t nasid, int widget_id, int masterwid)
bc->io.end  = ~0UL;
bc->io.flags= IORESOURCE_IO;
 
-   bc->irq_cpu = smp_processor_id();
bc->widget_id = widget_id;
bc->nasid = nasid;
 
@@ -165,16 +153,12 @@ int pcibios_plat_dev_init(struct pci_dev *dev)
 
irq = 

[PATCH 0/7] MIPS: SGI-IP27 rework

[Thomas Bogendoerfer]

SGI IP27 (Origin/Onyx2) and SGI IP30 (Octane) have a similair
architecture and share some hardware (ioc3/bridge). To share
the software parts this patchset reworks SGI IP27 interrupt
and pci bridge code. By using features Linux gained during the
many years since SGI IP27 code was integrated this even results
in code reduction and IMHO cleaner code.

Tests have been done on a two module O200 (4 CPUs) and an
Origin 2000 (8 CPUs).

My next step in integrating SGI IP30 support is splitting ioc3eth
into a MFD and subdevice drivers. Prototype is working, but needs
still more clean ups.


Thomas Bogendoerfer (7):
  MIPS: SGI-IP27: get rid of volatile and hubreg_t
  MIPS: SGI-IP27: clean up bridge access and header files
  MIPS: SGI-IP27: use pr_info/pr_emerg and pr_cont to fix output
  MIPS: SGI-IP27: do xtalk scanning later
  MIPS: SGI-IP27: rework HUB interrupts
  MIPS: SGI-IP27: use generic PCI driver
  MIPS: SGI-IP27: abstract chipset irq from bridge

 arch/mips/Kconfig  |   3 +
 arch/mips/include/asm/mach-ip27/irq.h  |  12 +-
 arch/mips/include/asm/mach-ip27/mmzone.h   |   2 -
 arch/mips/include/asm/pci/bridge.h | 225 ++--
 arch/mips/include/asm/sn/addrs.h   |  63 +---
 arch/mips/include/asm/sn/arch.h|   2 -
 arch/mips/include/asm/sn/intr.h|   7 +
 arch/mips/include/asm/sn/sn0/addrs.h   |   5 -
 arch/mips/include/asm/xtalk/xtalk.h|   9 -
 arch/mips/pci/Makefile |   1 -
 arch/mips/pci/ops-bridge.c | 322 -
 arch/mips/pci/pci-ip27.c   | 233 
 arch/mips/sgi-ip27/Makefile|   3 +-
 arch/mips/sgi-ip27/ip27-hubio.c|   2 +-
 arch/mips/sgi-ip27/ip27-init.c |  33 +-
 arch/mips/sgi-ip27/ip27-irq-pci.c  | 266 --
 arch/mips/sgi-ip27/ip27-irq.c  | 297 ++-
 arch/mips/sgi-ip27/ip27-irqno.c|  48 ---
 arch/mips/sgi-ip27/ip27-memory.c   |  34 +-
 arch/mips/sgi-ip27/ip27-nmi.c  |  64 ++--
 arch/mips/sgi-ip27/ip27-timer.c|  42 +--
 arch/mips/sgi-ip27/ip27-xtalk.c|  44 ++-
 drivers/pci/controller/Kconfig |   3 +
 drivers/pci/controller/Makefile|   1 +
 drivers/pci/controller/pci-xtalk-bridge.c  | 558 +
 include/linux/platform_data/xtalk-bridge.h |  17 +
 26 files changed, 997 insertions(+), 1299 deletions(-)
 delete mode 100644 arch/mips/pci/ops-bridge.c
 delete mode 100644 arch/mips/pci/pci-ip27.c
 delete mode 100644 arch/mips/sgi-ip27/ip27-irq-pci.c
 delete mode 100644 arch/mips/sgi-ip27/ip27-irqno.c
 create mode 100644 drivers/pci/controller/pci-xtalk-bridge.c
 create mode 100644 include/linux/platform_data/xtalk-bridge.h

-- 
2.13.7

Re: [for next][PATCH 1/2] platform/x86: Fix unmet dependency warning for ACPI_CMPC

[Sinan Kaya]

On 1/24/2019 5:52 AM, Rafael J. Wysocki wrote:

Andy/Darren, these two seem to be for you, but I can take them too as
related to ACPI tagentially, so please let me know.


I'll post V2 to fix a "fat-finger" in summary. I was hoping to receive a
feedback until now.

I'll get the V2 out.

Re: [for next][PATCH 1/2] mfd: Fix unmet dependency warning for MFD_TPS68470

[Sinan Kaya]

On 1/24/2019 5:51 AM, Rafael J. Wysocki wrote:

Is anyone taking this or should I?


Nobody replied to this yet. I was hoping this series to go through acpi
tree like the rest of the other fixes.

Re: [for next][PATCH 2/2] x86/Kconfig: Select PCI_LOCKLESS_CONFIG if PCI is enabled

[Sinan Kaya]

On 1/24/2019 5:51 AM, Rafael J. Wysocki wrote:



Is anyone taking this or should I?





This got applied:

https://git.kernel.org/tip/625210cfa6c0c26ea422f655bf68288176f174e6

Re: [PATCH] x86/kvm/hyper-v: tweak HYPERV_CPUID_ENLIGHTMENT_INFO

[Liran Alon]

> On 24 Jan 2019, at 19:39, Vitaly Kuznetsov  wrote:
> 
> Liran Alon  writes:
> 
>>> On 24 Jan 2019, at 19:15, Vitaly Kuznetsov  wrote:
>>> 
>>> We shouldn't probably be suggesting using Enlightened VMCS when it's not
>>> enabled (not supported from guest's point of view). System reset through
>>> synthetic MSR is not recommended neither by genuine Hyper-V nor my QEMU.
>>> 
>>> Windows seems to be fine either way but let's be consistent.
>>> 
>>> Fixes: 2bc39970e932 ("x86/kvm/hyper-v: Introduce 
>>> KVM_GET_SUPPORTED_HV_CPUID")
>>> Signed-off-by: Vitaly Kuznetsov 
>>> ---
>>> arch/x86/kvm/hyperv.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>>> index ac44a681f065..4730fcaa70cf 100644
>>> --- a/arch/x86/kvm/hyperv.c
>>> +++ b/arch/x86/kvm/hyperv.c
>>> @@ -1847,11 +1847,11 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu 
>>> *vcpu, struct kvm_cpuid2 *cpuid,
>>> case HYPERV_CPUID_ENLIGHTMENT_INFO:
>>> ent->eax |= HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED;
>>> ent->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
>>> -   ent->eax |= HV_X64_SYSTEM_RESET_RECOMMENDED;
>>> ent->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
>>> ent->eax |= HV_X64_CLUSTER_IPI_RECOMMENDED;
>>> ent->eax |= HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED;
>>> -   ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>>> +   if (evmcs_ver)
>>> +   ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>>> 
>>> /*
>>>  * Default number of spinlock retry attempts, matches
>>> -- 
>>> 2.20.1
>>> 
>> 
>> Seems to me that there are 2 unrelated separated patches here. Why not
>> split them?
> 
> They seem to be too small :-) No problem, I'll split them up in v2.

I don’t think in general that it matters how small they are.
Separating to small logical patches allows better bisect, easier review and 
better revert resolution. So better overall. :)

> 
>> For content itself: Reviewed-by: Liran Alon 
>> 
> 
> Thanks!
> 
> -- 
> Vitaly

Fwd: Fwd: Tuxconfig - automated linux kernel module installer.

[Rob Brew]

Hi everyone / Linus

For my Master's dissertation at Kent University I've built a platform
and GUI to automate the process of submitting kernel module
configurations and installing kernel modules from those configurations.

Developers submit kernel module source code including a special file as
to how these kernel modules are built.
End users have a graphical way of installing said kernel modules, as
well as upgrading them and uninstalling them, and recovering failed builds.

Think of it as a Ubuntu restricted drivers app enhanced by allowing
anyone to contribute a git repository for others to install, or the
windows "install new device" process..

It's a proof of concept, and does need some work in order to be a final
version.

https://github.com/rydal/dissertation-doc
is the dissertation document,
with readme.md defining what it does.
https://github.com/rydal/tuxconfig-backend
is the back end written in
Java and JSP.
https://github.com/rydal/tuxconfig-frontend
is the front end written in
C++.


What i need:
In order to prevent malicious code and Trojan horses the platform will
need a team to vet each contribution to ensure binaries come from
trusted sources and Makefiles aren't damaging to the system.

The package and website for those contributing is at
https://www.linuxconf.feedthepenguin.org/hehe/


Features which could be added:
Change the udev rules to make the application run every time a new
device is inserted
Harsher recovery when adding Linux packages.
Cryptographicaly signing the get and post requests to ensure they are
from the application.

I'm happy to work on this concept, as well as moderate the git pull
requests.

Thanks,
  Rob Brew.

Re: [PATCH] x86/kvm/hyper-v: tweak HYPERV_CPUID_ENLIGHTMENT_INFO

[Vitaly Kuznetsov]

Liran Alon  writes:

>> On 24 Jan 2019, at 19:15, Vitaly Kuznetsov  wrote:
>> 
>> We shouldn't probably be suggesting using Enlightened VMCS when it's not
>> enabled (not supported from guest's point of view). System reset through
>> synthetic MSR is not recommended neither by genuine Hyper-V nor my QEMU.
>> 
>> Windows seems to be fine either way but let's be consistent.
>> 
>> Fixes: 2bc39970e932 ("x86/kvm/hyper-v: Introduce KVM_GET_SUPPORTED_HV_CPUID")
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>> arch/x86/kvm/hyperv.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index ac44a681f065..4730fcaa70cf 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1847,11 +1847,11 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu 
>> *vcpu, struct kvm_cpuid2 *cpuid,
>>  case HYPERV_CPUID_ENLIGHTMENT_INFO:
>>  ent->eax |= HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED;
>>  ent->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
>> -ent->eax |= HV_X64_SYSTEM_RESET_RECOMMENDED;
>>  ent->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
>>  ent->eax |= HV_X64_CLUSTER_IPI_RECOMMENDED;
>>  ent->eax |= HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED;
>> -ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>> +if (evmcs_ver)
>> +ent->eax |= HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>> 
>>  /*
>>   * Default number of spinlock retry attempts, matches
>> -- 
>> 2.20.1
>> 
>
> Seems to me that there are 2 unrelated separated patches here. Why not
> split them?

They seem to be too small :-) No problem, I'll split them up in v2.

> For content itself: Reviewed-by: Liran Alon 
>

Thanks!

-- 
Vitaly

Re: powerpc/ps3: Use struct_size() in kzalloc()

[Gustavo A. R. Silva]

On 1/23/19 9:40 PM, Michael Ellerman wrote:
> On Tue, 2019-01-08 at 21:00:10 UTC, "Gustavo A. R. Silva" wrote:
>> One of the more common cases of allocation size calculations is finding the
>> size of a structure that has a zero-sized array at the end, along with memory
>> for some number of elements for that array. For example:
>>
>> struct foo {
>> int stuff;
>> void *entry[];
>> };
>>
>> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>>
>> Instead of leaving these open-coded and prone to type mistakes, we can now
>> use the new struct_size() helper:
>>
>> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>>
>> This code was detected with the help of Coccinelle.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Applied to powerpc next, thanks.
> 
> https://git.kernel.org/powerpc/c/31367b9a01d6a3f4f77694bd44f547d6
> 

Thanks, Michael.

--
Gustavo

[PATCH][V2] ASoC: Intel: make const arrays static, reduces object code size

[Colin King]

From: Colin Ian King 

Don't populate the const arrays on the stack but instead make
it static. Makes the object code smaller, for example:

Before:
   textdata bss dec hex filename
  141078832 224   231635a7b bytcht_es8316.o

After:
   textdata bss dec hex filename
  140158896 224   231355a5f bytcht_es8316.o

(gcc version 8.2.0 x86_64)

Signed-off-by: Colin Ian King 
---

V2: also fix up bytcr_rt5640.c and bytcr_rt5651.c, thanks to
Pierre-Louis Bossart for noticing these two.

---
 sound/soc/intel/boards/bytcht_es8316.c | 2 +-
 sound/soc/intel/boards/bytcr_rt5640.c  | 2 +-
 sound/soc/intel/boards/bytcr_rt5651.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/intel/boards/bytcht_es8316.c 
b/sound/soc/intel/boards/bytcht_es8316.c
index fa9c4cf97686..1364e4e601d8 100644
--- a/sound/soc/intel/boards/bytcht_es8316.c
+++ b/sound/soc/intel/boards/bytcht_es8316.c
@@ -437,7 +437,7 @@ static const struct acpi_gpio_mapping 
byt_cht_es8316_gpios[] = {
 
 static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev)
 {
-   const char * const mic_name[] = { "in1", "in2" };
+   static const char * const mic_name[] = { "in1", "in2" };
struct byt_cht_es8316_private *priv;
struct device *dev = >dev;
struct snd_soc_acpi_mach *mach;
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index ca8b4d5ff70f..a79466c8fb29 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -1149,7 +1149,7 @@ struct acpi_chan_package {   /* ACPICA seems to require 
64 bit integers */
 
 static int snd_byt_rt5640_mc_probe(struct platform_device *pdev)
 {
-   const char * const map_name[] = { "dmic1", "dmic2", "in1", "in3" };
+   static const char * const map_name[] = { "dmic1", "dmic2", "in1", "in3" 
};
const struct dmi_system_id *dmi_id;
struct byt_rt5640_private *priv;
struct snd_soc_acpi_mach *mach;
diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index b618d984e2d5..e6945d11c8ab 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -919,7 +919,7 @@ struct acpi_chan_package {   /* ACPICA seems to require 64 
bit integers */
 
 static int snd_byt_rt5651_mc_probe(struct platform_device *pdev)
 {
-   const char * const mic_name[] = { "dmic", "in1", "in2", "in12" };
+   static const char * const mic_name[] = { "dmic", "in1", "in2", "in12" };
struct byt_rt5651_private *priv;
struct snd_soc_acpi_mach *mach;
struct device *codec_dev;
-- 
2.19.1

[PATCH] ALSA: hda/tegra: enable clock during probe

[Sameer Pujar]

If CONFIG_PM is disabled or runtime PM calls are forbidden, the clocks
will not be ON. This could cause issue during probe, where hda init
setup is done. This patch checks whether runtime PM is enabled or not.
If disabled, clocks are enabled in probe() and disabled in remove()

This patch does following minor changes as cleanup,
  * return code check for pm_runtime_get_sync() to take care of failure
and exit gracefully.
  * In remove path runtime PM is disabled before calling snd_card_free().
  * hda_tegra_disable_clocks() is moved out of CONFIG_PM_SLEEP check.
  * runtime PM callbacks moved out of CONFIG_PM check

Signed-off-by: Sameer Pujar 
Reviewed-by: Ravindra Lokhande 
Reviewed-by: Jon Hunter 
---
 sound/pci/hda/hda_tegra.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
index c8d18dc..155c2f5 100644
--- a/sound/pci/hda/hda_tegra.c
+++ b/sound/pci/hda/hda_tegra.c
@@ -219,7 +219,6 @@ static int hda_tegra_enable_clocks(struct hda_tegra *data)
return rc;
 }
 
-#ifdef CONFIG_PM_SLEEP
 static void hda_tegra_disable_clocks(struct hda_tegra *data)
 {
clk_disable_unprepare(data->hda2hdmi_clk);
@@ -227,6 +226,7 @@ static void hda_tegra_disable_clocks(struct hda_tegra *data)
clk_disable_unprepare(data->hda_clk);
 }
 
+#ifdef CONFIG_PM_SLEEP
 /*
  * power management
  */
@@ -257,7 +257,6 @@ static int hda_tegra_resume(struct device *dev)
 }
 #endif /* CONFIG_PM_SLEEP */
 
-#ifdef CONFIG_PM
 static int hda_tegra_runtime_suspend(struct device *dev)
 {
struct snd_card *card = dev_get_drvdata(dev);
@@ -283,7 +282,7 @@ static int hda_tegra_runtime_resume(struct device *dev)
int rc;
 
rc = hda_tegra_enable_clocks(hda);
-   if (rc != 0)
+   if (rc)
return rc;
if (chip && chip->running) {
hda_tegra_init(hda);
@@ -292,7 +291,6 @@ static int hda_tegra_runtime_resume(struct device *dev)
 
return 0;
 }
-#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops hda_tegra_pm = {
SET_SYSTEM_SLEEP_PM_OPS(hda_tegra_suspend, hda_tegra_resume)
@@ -555,6 +553,13 @@ static int hda_tegra_probe(struct platform_device *pdev)
if (!azx_has_pm_runtime(chip))
pm_runtime_forbid(hda->dev);
 
+   /* explicit resume if runtime PM is disabled */
+   if (!pm_runtime_enabled(hda->dev)) {
+   err = hda_tegra_runtime_resume(hda->dev);
+   if (err)
+   goto out_free;
+   }
+
schedule_work(>probe_work);
 
return 0;
@@ -571,7 +576,14 @@ static void hda_tegra_probe_work(struct work_struct *work)
struct platform_device *pdev = to_platform_device(hda->dev);
int err;
 
-   pm_runtime_get_sync(hda->dev);
+   err = pm_runtime_get_sync(hda->dev);
+   if (err < 0) {
+   dev_err(hda->dev,
+   "failed in pm_runtime_get_syc with err = %d\n",
+   err);
+   return;
+   }
+
err = hda_tegra_first_init(chip, pdev);
if (err < 0)
goto out_free;
@@ -599,12 +611,13 @@ static void hda_tegra_probe_work(struct work_struct *work)
 
 static int hda_tegra_remove(struct platform_device *pdev)
 {
-   int ret;
-
-   ret = snd_card_free(dev_get_drvdata(>dev));
pm_runtime_disable(>dev);
+   if (!pm_runtime_status_suspended(>dev)) {
+   hda_tegra_runtime_suspend(>dev);
+   pm_runtime_set_suspended(>dev);
+   }
 
-   return ret;
+   return snd_card_free(dev_get_drvdata(>dev));
 }
 
 static void hda_tegra_shutdown(struct platform_device *pdev)
-- 
2.7.4

Re: [RFC PATCH] ALSA: core: Add DMA share buffer support

[Mark Brown]

On Thu, Jan 24, 2019 at 02:43:02PM +0100, Jaroslav Kysela wrote:

> If I look to the dma_buf_fd() implementation:

>   fd = get_unused_fd_flags(flags);
>   fd_install(fd, dmabuf->file);

> .. what if we just add one new ioctl to the ALSA's PCM API which will
> return a new anonymous inode descriptor with the restricted access to
> the main PCM device to satisfy the SELinux requirements / security
> policies? It might be more nice and simple solution than to implement
> the full dma-buf interface for the ALSA's PCM devices.

That certainly works for me so long as the security people are happy.

> Question: The dma-buf also implements the fencing, but I am not able to
> determine, if this mechanism is used in android [1]. It may allow
> concurrent mmap and synchronize apps - but the sound server should
> manage the access to the DMA buffer anyway. In my opinion, it makes much
> sense for the video-pipes when the hardware does some accelerations
> (encoding/decoding).

We had the same discuission off list and couldn't think of a need for
that feature in the audio context but left it in as it's already there
with dma-buf so there's no real cost to implementing it and we weren't
sure we weren't missing something.


signature.asc
Description: PGP signature

Re: [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address

[Mark Rutland]

On Thu, Jan 24, 2019 at 07:25:53PM +0200, Mike Rapoport wrote:
> On Thu, Jan 24, 2019 at 04:51:53PM +, Mark Rutland wrote:
> > On Thu, Jan 24, 2019 at 04:19:33PM +, Christophe Leroy wrote:
> > > Since only the virtual address of allocated blocks is used,
> > > lets use functions returning directly virtual address.
> > > 
> > > Those functions have the advantage of also zeroing the block.
> > > 
> > > Suggested-by: Mike Rapoport 
> > > Acked-by: Mike Rapoport 
> > > Signed-off-by: Christophe Leroy 
> > 
> > [...]
> > 
> > > +static void *__init alloc_stack(void)
> > > +{
> > > + void *ptr = memblock_alloc(THREAD_SIZE, THREAD_SIZE);
> > > +
> > > + if (!ptr)
> > > + panic("cannot allocate stacks");
> > > +
> > > + return ptr;
> > > +}
> > 
> > I believe memblock_alloc() will panic() if it cannot allocate memory,
> > since that goes:
> > 
> >  memblock_alloc()
> >  -> memblock_alloc_try_nid()
> > -> panic()
> > 
> > So you can get rid of the panic() here, or if you want a custom panic
> > message, you can use memblock_alloc_nopanic().
> 
> As we've already discussed it in [1], I'm working on removing the
> _nopanic() versions and dropping the panic() calls from memblock_alloc()
> and friends.
> 
> I've posted v2 of the patches earlier this week [2].
>  
> > [...]
> 
> [1] https://lore.kernel.org/lkml/20190108143428.GB14063@rapoport-lnx/ 
> [2] 
> https://lore.kernel.org/lkml/1548057848-15136-1-git-send-email-r...@linux.ibm.com/

Fair enough.

Feel free to take the ack regardless, then!

Thanks,
Mark.