* Re: [PATCH v2] drm/mediatek: Support UYVY and YUYV format for overlay
From: Daniel Kurtz @ 2017-01-03 6:27 UTC (permalink / raw)
To: Bibby Hsieh
Cc: David Airlie, Matthias Brugger, Daniel Vetter, dri-devel,
moderated list:ARM/Mediatek SoC support, Yingjoe Chen, Cawa Cheng,
Philipp Zabel, YT Shen, Thierry Reding, CK Hu, Mao Huang,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sascha Hauer
In-Reply-To: <1483079183-38637-1-git-send-email-bibby.hsieh@mediatek.com>
On Fri, Dec 30, 2016 at 2:26 PM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 21 +++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c703102..de05845 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -40,10 +40,13 @@
> #define OVL_RDMA_MEM_GMC 0x40402020
>
> #define OVL_CON_BYTE_SWAP BIT(24)
> +#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
> #define OVL_CON_CLRFMT_RGB565 (0 << 12)
> #define OVL_CON_CLRFMT_RGB888 (1 << 12)
> #define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
> #define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
> +#define OVL_CON_CLRFMT_UYVY (4 << 12)
> +#define OVL_CON_CLRFMT_YUYV (5 << 12)
Why not just add " | OVL_CON_MTX_YUV_TO_RGB" here in the definition of
these two constants, instead of adding a helper function?
> #define OVL_CON_AEN BIT(8)
> #define OVL_CON_ALPHA 0xff
>
> @@ -162,6 +165,21 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
> case DRM_FORMAT_XBGR8888:
> case DRM_FORMAT_ABGR8888:
> return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
> + case DRM_FORMAT_UYVY:
> + return OVL_CON_CLRFMT_UYVY;
> + case DRM_FORMAT_YUYV:
> + return OVL_CON_CLRFMT_YUYV;
> + }
> +}
> +
> +static bool ovl_yuv_space(unsigned int fmt)
> +{
> + switch (fmt) {
> + case DRM_FORMAT_UYVY:
> + case DRM_FORMAT_YUYV:
> + return true;
> + default:
> + return false;
> }
> }
>
> @@ -183,6 +201,9 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
> if (idx != 0)
> con |= OVL_CON_AEN | OVL_CON_ALPHA;
>
> + if (ovl_yuv_space(fmt))
> + con |= OVL_CON_MTX_YUV_TO_RGB;
> +
> writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
> writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
> writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c461a23..8c02d1d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -28,6 +28,8 @@
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_ARGB8888,
> DRM_FORMAT_RGB565,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_YUYV,
> };
>
> static void mtk_plane_reset(struct drm_plane *plane)
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64:dt:ls1046a: Add TMU device tree support for LS1046A
From: Shawn Guo @ 2017-01-03 6:26 UTC (permalink / raw)
To: Troy Jia
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Scott Wood, edubezval@gmail.com, Y.T. Tang, robh+dt@kernel.org,
rui.zhang@intel.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM4PR0401MB1843C415E2CF7D58BD5A1064EB6E0@AM4PR0401MB1843.eurprd04.prod.outlook.com>
On Tue, Jan 03, 2017 at 03:49:33AM +0000, Troy Jia wrote:
> > > @@ -279,6 +282,82 @@
> > > clocks = <&sysclk>;
> > > };
> > >
> > > + tmu: tmu@1f00000 {
> > > + compatible = "fsl,qoriq-tmu";
> > > + reg = <0x0 0x1f00000 0x0 0x10000>;
> > > + interrupts = <0 33 0x4>;
> > > + fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x30062>;
> > > + fsl,tmu-calibration = <0x00000000 0x00000026
> > > + 0x00000001 0x0000002d
> > > + 0x00000002 0x00000032
> > > + 0x00000003 0x00000039
> > > + 0x00000004 0x0000003f
> > > + 0x00000005 0x00000046
> > > + 0x00000006 0x0000004d
> > > + 0x00000007 0x00000054
> > > + 0x00000008 0x0000005a
> > > + 0x00000009 0x00000061
> > > + 0x0000000a 0x0000006a
> > > + 0x0000000b 0x00000071
> > > +
> >
> > Instead of a newline, can we have a single line comment here to tell how these
> > calibration data is grouped?
>
> Each group represent one temperature range. It's a good idea to add comment here.
> Could I just add one comment like below to clarify all four groups?
> /* Each calibration data group represent one temperature range. There are four ranges in total */
Probably the following form?
/* Calibration data group 1 */
...
/* Calibration data group 2 */
...
/* Calibration data group 3 */
...
/* Calibration data group 4 */
...
>
> >
> > > + 0x00010000 0x00000025
> > > + 0x00010001 0x0000002c
> > > + 0x00010002 0x00000035
> > > + 0x00010003 0x0000003d
> > > + 0x00010004 0x00000045
> > > + 0x00010005 0x0000004e
> > > + 0x00010006 0x00000057
> > > + 0x00010007 0x00000061
> > > + 0x00010008 0x0000006b
> > > + 0x00010009 0x00000076
> > > +
> > > + 0x00020000 0x00000029
> > > + 0x00020001 0x00000033
> > > + 0x00020002 0x0000003d
> > > + 0x00020003 0x00000049
> > > + 0x00020004 0x00000056
> > > + 0x00020005 0x00000061
> > > + 0x00020006 0x0000006d
> > > +
> > > + 0x00030000 0x00000021
> > > + 0x00030001 0x0000002a
> > > + 0x00030002 0x0000003c
> > > + 0x00030003 0x0000004e>;
> > > + big-endian;
> > > + #thermal-sensor-cells = <1>;
> > > + };
> > > +
> > > + thermal-zones {
> > > + cpu_thermal: cpu-thermal {
> > > + polling-delay-passive = <1000>;
> > > + polling-delay = <5000>;
> > > +
> >
> > We usually do not have newline between properties but nodes, or between
> > property list and child node.
>
> I just follow the style of thermal binding of
> Documentation/devicetree/bindings/thermal/thermal.txt.
Different subsystem or binding examples use different style, but when we
put things together in the platform dts, we would like to have them in a
unified style.
Shawn
^ permalink raw reply
* Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command
From: Baolin Wang @ 2017-01-03 6:20 UTC (permalink / raw)
To: Mathias Nyman
Cc: Lu Baolu, Mathias Nyman, Greg KH, USB, LKML, Mark Brown,
Lu, Baolu
In-Reply-To: <586A6A61.8040902@linux.intel.com>
On 2 January 2017 at 22:57, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:
> On 27.12.2016 05:07, Baolin Wang wrote:
>>
>> Hi,
>>
>> On 21 December 2016 at 21:00, Mathias Nyman
>> <mathias.nyman@linux.intel.com> wrote:
>>>
>>> On 21.12.2016 04:22, Baolin Wang wrote:
>>>>
>>>>
>>>> Hi Mathias,
>>>>
>>>> On 20 December 2016 at 23:13, Mathias Nyman
>>>> <mathias.nyman@linux.intel.com> wrote:
>>>>>
>>>>>
>>>>> On 20.12.2016 09:30, Baolin Wang wrote:
>>>>> ...
>>>>>
>>>>> Alright, I gathered all current work related to xhci races and timeouts
>>>>> and put them into a branch:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git
>>>>> timeout_race_fixes
>>>>>
>>>>> Its based on 4.9
>>>>> It includes a few other patches just to avoid conflicts and make my
>>>>> life
>>>>> easier
>>>>>
>>>>> Interesting patches are:
>>>>>
>>>>> ee4eb91 xhci: remove unnecessary check for pending timer
>>>>> 0cba67d xhci: detect stop endpoint race using pending timer instead of
>>>>> counter.
>>>>> 4f2535f xhci: Handle command completion and timeout race
>>>>> b9d00d7 usb: host: xhci: Fix possible wild pointer when handling abort
>>>>> command
>>>>> 529a5a0 usb: xhci: fix possible wild pointer
>>>>> 4766555 xhci: Fix race related to abort operation
>>>>> de834a3 xhci: Use delayed_work instead of timer for command timeout
>>>>> 69973b8 Linux 4.9
>>>>>
>>>>> The fixes for command queue races will go to usb-linus and stable, the
>>>>> reworks for stop ep watchdog timer will go to usb-next.
>>>>
>>>>
>>>>
>>>> How about applying below patch in your 'timeout_race_fixes' branch?
>>>> [PATCH] usb: host: xhci: Clean up commands when stop endpoint command is
>>>> timeout
>>>> https://lkml.org/lkml/2016/12/13/94
>>>>
>>>
>>> usb_hc_died() should eventyally end up calling xhci_mem_cleanup()
>>> which will cleanup the command queue. But I need to look into that
>>
>>
>> usb_hc_died() did not call xhci_mem_cleanup() to clean up command
>> queue, it just disconnects all children devices attached on the dying
>> hub. I did not find where it will clean up the command queue when
>> issuing usb_hc_died(). Also before issuing usb_hc_died() in
>> xhci_handle_command_timeout(), we will call
>> xhci_cleanup_command_queue(). I think it should same as in
>> xhci_stop_endpoint_command_watchdog().
>>
>
> You're right, it doesn't call xhci_mem_cleanup.
> Need to look at this after getting first series of fixes to usb-linus
Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH net 9/9] virtio-net: XDP support for small buffers
From: Jason Wang @ 2017-01-03 6:16 UTC (permalink / raw)
To: John Fastabend, mst, virtualization, netdev, linux-kernel
Cc: john.r.fastabend
In-Reply-To: <586AD79B.2070203@gmail.com>
On 2017年01月03日 06:43, John Fastabend wrote:
> On 16-12-23 06:37 AM, Jason Wang wrote:
>> Commit f600b6905015 ("virtio_net: Add XDP support") leaves the case of
>> small receive buffer untouched. This will confuse the user who want to
>> set XDP but use small buffers. Other than forbid XDP in small buffer
>> mode, let's make it work. XDP then can only work at skb->data since
>> virtio-net create skbs during refill, this is sub optimal which could
>> be optimized in the future.
>>
>> Cc: John Fastabend <john.r.fastabend@intel.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/virtio_net.c | 112 ++++++++++++++++++++++++++++++++++++-----------
>> 1 file changed, 87 insertions(+), 25 deletions(-)
>>
> Hi Jason,
>
> I was doing some more testing on this what do you think about doing this
> so that free_unused_bufs() handles the buffer free with dev_kfree_skb()
> instead of put_page in small receive mode. Seems more correct to me.
>
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 783e842..27ff76c 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1898,6 +1898,10 @@ static void free_receive_page_frags(struct virtnet_info *vi)
>
> static bool is_xdp_queue(struct virtnet_info *vi, int q)
> {
> + /* For small receive mode always use kfree_skb variants */
> + if (!vi->mergeable_rx_bufs)
> + return false;
> +
> if (q < (vi->curr_queue_pairs - vi->xdp_queue_pairs))
> return false;
> else if (q < vi->curr_queue_pairs)
>
>
> patch is untested just spotted doing code review.
>
> Thanks,
> John
We probably need a better name for this function.
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Andy Lutomirski @ 2017-01-03 6:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kirill A. Shutemov, Linus Torvalds, Andrew Morton, X86 ML,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Andi Kleen,
Dave Hansen, linux-arch, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Linux API,
linux-arm-kernel@lists.infradead.org, Catalin Marinas,
Will Deacon
In-Reply-To: <2736959.3MfCab47fD@wuerfel>
On Mon, Jan 2, 2017 at 12:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
>> As with other resources you can set the limit lower than current usage.
>> It would affect only future virtual address space allocations.
I still don't buy all these use cases:
>>
>> Use-cases for new rlimit:
>>
>> - Bumping the soft limit to RLIM_INFINITY, allows current process all
>> its children to use addresses above 47-bits.
OK, I get this, but only as a workaround for programs that make
assumptions about the address space and don't use some mechanism (to
be designed?) to work correctly in spite of a larger address space.
>>
>> - Bumping the soft limit to RLIM_INFINITY after fork(2), but before
>> exec(2) allows the child to use addresses above 47-bits.
Ditto.
>>
>> - Lowering the hard limit to 47-bits would prevent current process all
>> its children to use addresses above 47-bits, unless a process has
>> CAP_SYS_RESOURCES.
I've tried and I can't imagine any reason to do this.
>>
>> - It’s also can be handy to lower hard or soft limit to arbitrary
>> address. User-mode emulation in QEMU may lower the limit to 32-bit
>> to emulate 32-bit machine on 64-bit host.
I don't understand. QEMU user-mode emulation intercepts all syscalls.
What QEMU would *actually* want is a way to say "allocate me some
memory with the high N bits clear". mmap-via-int80 on x86 should be
fixed to do this, but a new syscall with an explicit parameter would
work, as would a prctl changing the current limit.
>>
>> TODO:
>> - port to non-x86;
>>
>> Not-yet-signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> Cc: linux-api@vger.kernel.org
>
> This seems to nicely address the same problem on arm64, which has
> run into the same issue due to the various page table formats
> that can currently be chosen at compile time.
On further reflection, I think this has very little to do with paging
formats except insofar as paging formats make us notice the problem.
The issue is that user code wants to be able to assume an upper limit
on an address, and it gets an upper limit right now that depends on
architecture due to paging formats. But someone really might want to
write a *portable* 64-bit program that allocates memory with the high
16 bits clear. So let's add such a mechanism directly.
As a thought experiment, what if x86_64 simply never allocated "high"
(above 2^47-1) addresses unless a new mmap-with-explicit-limit syscall
were used? Old glibc would continue working. Old VMs would work.
New programs that want to use ginormous mappings would have to use the
new syscall. This would be totally stateless and would have no issues
with CRIU.
If necessary, we could also have a prctl that changes a
"personality-like" limit that is in effect when the old mmap was used.
I say "personality-like" because it would reset under exactly the same
conditions that personality resets itself.
Thoughts?
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: imx6q: Add mccmon6 board support
From: Lukasz Majewski @ 2017-01-03 6:02 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, Russell King, Fabio Estevam,
linux-kernel, devicetree, linux-arm-kernel, Vladimir Zapolskiy,
Sascha Hauer, Zerlauth Karl (LWN), Lukasz Majewski
In-Reply-To: <20170103020650.GM20956@dragon>
Hi Shawn,
Thank you for your comments.
> On Tue, Jan 03, 2017 at 12:43:38AM +0100, Lukasz Majewski wrote:
> > From: Lukasz Majewski <l.majewski@majess.pl>
> >
> > This patch provides support for Liebherr's Monitor 6 board
> > (abverrated as mccmon6) to Linux kernel.
> >
> > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > ---
> > Changes for v2:
> > - Reorganize the dts file according to Valdimir Zapolskiy's comments
> >
> > ---
> > MCCMON6 board support depends on following patches:
> >
> > 1. "video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count
> > during pwm_backlight_probe()"
> > http://patchwork.ozlabs.org/patch/708844/
> >
> > 2. "pwm: imx: Provide atomic operation for IMX PWM driver"
> > http://patchwork.ozlabs.org/patch/708847/ -
> > http://patchwork.ozlabs.org/patch/708843/ ---
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/imx6q-mccmon6.dts | 477
> > ++++++++++++++++++++++++++++++++++++ 2 files changed, 478
> > insertions(+) create mode 100644 arch/arm/boot/dts/imx6q-mccmon6.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index c558ba7..0aa8e89 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -383,6 +383,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6q-hummingboard.dtb \
> > imx6q-icore-rqs.dtb \
> > imx6q-marsboard.dtb \
> > + imx6q-mccmon6.dtb \
> > imx6q-nitrogen6x.dtb \
> > imx6q-nitrogen6_max.dtb \
> > imx6q-novena.dtb \
> > diff --git a/arch/arm/boot/dts/imx6q-mccmon6.dts
> > b/arch/arm/boot/dts/imx6q-mccmon6.dts new file mode 100644
> > index 0000000..7128dc2
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6q-mccmon6.dts
> > @@ -0,0 +1,477 @@
> > +/*
> > + * Copyright 2016-2017
> > + * Lukasz Majewski, DENX Software Engineering, lukma@denx.de
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2
> > as
> > + * published by the Free Software Foundation.
> > + *
> > + */
>
> You might want to GPL/X11 dual licence for non-Linux device tree
> users. There are a plenty of examples in arch/arm/boot/dts. But note
> the following correction.
>
> https://patchwork.kernel.org/patch/9475057/
For this board GPLv2 is enough. Is the above description correct or do
I need to add something?
>
> > +
> > +/dts-v1/;
> > +
> > +#include "imx6q.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/pwm/pwm.h>
> > +
> > +/ {
> > + model = "Liebherr (LWN) monitor6 i.MX6 Quad Board";
> > + compatible = "lwn,mccmon6", "fsl,imx6q";
> > +
> > + memory {
> > + reg = <0x10000000 0x80000000>;
> > + };
> > +
> > + backlight_lvds: backlight {
> > + compatible = "pwm-backlight";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_backlight>;
> > + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
> > + brightness-levels = < 0 1 2 3 4 5 6
> > 7 8 9
> > + 10 11 12 13 14 15 16
> > 17 18 19
> > + 20 21 22 23 24 25 26
> > 27 28 29
> > + 30 31 32 33 34 35 36
> > 37 38 39
> > + 40 41 42 43 44 45 46
> > 47 48 49
> > + 50 51 52 53 54 55 56
> > 57 58 59
> > + 60 61 62 63 64 65 66
> > 67 68 69
> > + 70 71 72 73 74 75 76
> > 77 78 79
> > + 80 81 82 83 84 85 86
> > 87 88 89
> > + 90 91 92 93 94 95 96
> > 97 98 99
> > + 100 101 102 103 104 105 106
> > 107 108 109
> > + 110 111 112 113 114 115 116
> > 117 118 119
> > + 120 121 122 123 124 125 126
> > 127 128 129
> > + 130 131 132 133 134 135 136
> > 137 138 139
> > + 140 141 142 143 144 145 146
> > 147 148 149
> > + 150 151 152 153 154 155 156
> > 157 158 159
> > + 160 161 162 163 164 165 166
> > 167 168 169
> > + 170 171 172 173 174 175 176
> > 177 178 179
> > + 180 181 182 183 184 185 186
> > 187 188 189
> > + 190 191 192 193 194 195 196
> > 197 198 199
> > + 200 201 202 203 204 205 206
> > 207 208 209
> > + 210 211 212 213 214 215 216
> > 217 218 219
> > + 220 221 222 223 224 225 226
> > 227 228 229
> > + 230 231 232 233 234 235 236
> > 237 238 239
> > + 240 241 242 243 244 245 246
> > 247 248 249
> > + 250 251 252 253 254 255>;
> > + default-brightness-level = <50>;
> > + enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + reg_lvds: regulator-lvds {
> > + compatible = "regulator-fixed";
> > + regulator-name = "lvds_ppen";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-boot-on;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_reg_lvds>;
> > + gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + panel-lvds0 {
> > + compatible = "innolux,g121x1-l03";
> > + backlight = <&backlight_lvds>;
> > + power-supply = <®_lvds>;
> > +
> > + port {
> > + panel_in_lvds0: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&iomuxc {
>
> Considering the data amount of this node, we generally put it at the
> bottom of the file to improve the readability of the rest.
But then it will not be alphabetically ordered :-).
I can put it on the end - no problem.
>
> > + pinctrl-names = "default";
> > +
> > + imx6q-mccmon6 {
>
> This container node can now be dropped completely to save one level of
> indentation.
Ok, I will remove imx6q-mccmon6 container node completely.
>
> > + pinctrl_backlight: dispgrp {
> > + fsl,pins = <
> > + /* BLEN_OUT */
> > + MX6QDL_PAD_GPIO_2__GPIO1_IO02
> > 0x1b0b0
> > + >;
> > + };
> > +
> > + pinctrl_ecspi3: ecspi3grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
> > +
> > MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
> > +
> > MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
> > + >;
> > + };
> > +
> > + pinctrl_ecspi3_cs: ecspi3cs {
>
> ecspi3csgrp, if we follow the naming scheme used in other nodes.
>
> > + fsl,pins = <
> > + MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24
> > 0x80000000
> > + >;
> > + };
> > +
> > + pinctrl_ecspi3_flwp: ecspi3flwp {
>
> Ditto
>
> > + fsl,pins = <
> > + MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27
> > 0x80000000
> > + >;
> > + };
> > +
> > + pinctrl_enet: enetgrp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> > +
> > MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
> > +
> > MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
> > + MX6QDL_PAD_GPIO_16__ENET_REF_CLK
> > 0x4001b0a8
> > +
> > MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
> > +
> > MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
> > + >;
> > + };
> > +
> > + pinctrl_i2c1: i2c1grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
> > +
> > MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_i2c2: i2c2grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> > +
> > MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_pwm2: pwm2grp {
> > + fsl,pins = <
> > + MX6QDL_PAD_GPIO_1__PWM2_OUT
> > 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_reg_lvds: req_lvds_grp {
>
> reglvdsgrp
>
> > + fsl,pins = <
> > + /* LVDS_PPEN_OUT */
> > +
> > MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x1b0b0
> > + >;
> > + };
> > +
> > + pinctrl_uart1: uart1grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> > +
> > MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_uart4: uart4grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
> > +
> > MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
> > +
> > MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
> > +
> > MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_usdhc2: usdhc2grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> > +
> > MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> > +
> > MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> > +
> > MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> > +
> > MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> > +
> > MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> > +
> > MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_usdhc3: usdhc3grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> > +
> > MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> > +
> > MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> > +
> > MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> > +
> > MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> > + >;
> > + };
> > +
> > + pinctrl_weim_cs0: weimcs0grp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> > + >;
> > + };
> > +
> > + pinctrl_weim_nor: weimnorgrp {
> > + fsl,pins = <
> > +
> > MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> > +
> > MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> > +
> > MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
> > +
> > MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
> > +
> > MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
> > +
> > MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
> > +
> > MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
> > + >;
> > + };
> > + };
> > +};
> > +
> > +&ecspi3 {
> > + cs-gpios = <&gpio4 24 0>;
>
> GPIO_ACTIVE_HIGH?
No, on our HW it is GPIO_ACTIVE_LOW
>
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs
> > &pinctrl_ecspi3_flwp>;
> > + status = "okay";
> > +
> > + flash: s25sl032p@0 {
>
> Node name should be as generic as possible, while label name can be
> specific. That said, 's25sl032p: flash@0' should be better.
OK.
>
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "spansion,s25sl032p", "jedec,spi-nor";
>
> "spansion,s25sl032p" doesn't seem to be documented. Can it be
> dropped?
This memory is jedec compatible and uses "jedec,spi-nor", so
"spansion,s25sl032p" can be dropped
>
> > + spi-max-frequency = <40000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +&fec {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_enet>;
> > + phy-mode = "rgmii";
> > + phy-reset-gpios = <&gpio1 27 0>;
>
> GPIO_ACTIVE_xxx? But you probably need GPIO_ACTIVE_LOW.
Yes.
>
> > + interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> > + <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> > + status = "okay";
> > +};
> > +
> > +&i2c1 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c1>;
> > + status = "okay";
> > +};
> > +
> > +&i2c2 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c2>;
> > + status = "okay";
> > +
> > + pmic: pfuze100@08 {
>
> pfuze100: pmic@08
>
> > + compatible = "fsl,pfuze100";
> > + reg = <0x08>;
> > +
> > + regulators {
> > + sw1a_reg: sw1ab {
> > + regulator-min-microvolt = <300000>;
> > + regulator-max-microvolt =
> > <1875000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + regulator-ramp-delay = <6250>;
> > + };
> > +
> > + sw1c_reg: sw1c {
> > + regulator-min-microvolt = <300000>;
> > + regulator-max-microvolt =
> > <1875000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + regulator-ramp-delay = <6250>;
> > + };
> > +
> > + sw2_reg: sw2 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <3950000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + sw3a_reg: sw3a {
> > + regulator-min-microvolt = <400000>;
> > + regulator-max-microvolt =
> > <1975000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + sw3b_reg: sw3b {
> > + regulator-min-microvolt = <400000>;
> > + regulator-max-microvolt =
> > <1975000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + sw4_reg: sw4 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + };
> > +
> > + swbst_reg: swbst {
> > + regulator-min-microvolt =
> > <5000000>;
> > + regulator-max-microvolt =
> > <5150000>;
> > + };
> > +
> > + snvs_reg: vsnvs {
> > + regulator-min-microvolt =
> > <1000000>;
> > + regulator-max-microvolt =
> > <3000000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + vref_reg: vrefddr {
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > + vgen1_reg: vgen1 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <1550000>;
> > + };
> > +
> > + vgen2_reg: vgen2 {
> > + regulator-min-microvolt = <800000>;
> > + regulator-max-microvolt =
> > <1550000>;
> > + };
> > +
> > + vgen3_reg: vgen3 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + };
> > +
> > + vgen4_reg: vgen4 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + vgen5_reg: vgen5 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + vgen6_reg: vgen6 {
> > + regulator-min-microvolt =
> > <1800000>;
> > + regulator-max-microvolt =
> > <3300000>;
> > + regulator-always-on;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&ldb {
> > + status = "okay";
> > +
> > + lvds0: lvds-channel@0 {
> > + fsl,data-mapping = "spwg";
> > + fsl,data-width = <24>;
> > + status = "okay";
> > +
> > + port@4 {
> > + reg = <4>;
> > +
> > + lvds0_out: endpoint {
> > + remote-endpoint =
> > <&panel_in_lvds0>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&pwm2 {
> > + #pwm-cells = <3>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_pwm2>;
> > + status = "okay";
> > +};
> > +
> > +&uart1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart1>;
> > + status = "okay";
> > +};
> > +
> > +&uart4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_uart4>;
> > + uart-has-rtscts;
> > + status = "okay";
> > +};
> > +
> > +&usdhc2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc2>;
> > + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&usdhc3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc3>;
> > + bus-width = <8>;
> > + non-removable;
> > + status = "okay";
> > +};
> > +
> > +&weim {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
> > + #address-cells = <2>;
> > + #size-cells = <1>;
>
> These two properties can be saved from board dts since commit
> 1be81ea58607 ("ARM: dts: imx6: Add imx-weim parameters to dtsi's").
Ok, I will remove them.
>
> Shawn
>
> > + ranges = <0 0 0x08000000 0x08000000>;
> > + status = "okay";
> > +
> > + nor@0,0 {
> > + compatible = "cfi-flash";
> > + reg = <0 0 0x02000000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + bank-width = <2>;
> > + use-advanced-sector-protection;
> > + fsl,weim-cs-timing = <0x00620081 0x00000001
> > 0x1c022000
> > + 0x0000c000 0x1404a38e 0x00000000>;
> > + };
> > +};
> > --
> > 2.1.4
> >
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
^ permalink raw reply
* Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions
From: Andy Lutomirski @ 2017-01-03 5:57 UTC (permalink / raw)
To: Tyler Hicks
Cc: Paul Moore, Eric Paris, Kees Cook, Will Drewry, linux-audit,
linux-kernel@vger.kernel.org
In-Reply-To: <1483375990-14948-1-git-send-email-tyhicks@canonical.com>
On Mon, Jan 2, 2017 at 8:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
> This patch set creates the basis for auditing information specific to a given
> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
> errno value that will be returned to userspace.
>
Not that I'm opposed to the idea, but what's the intended purpose?
^ permalink raw reply
* Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions
From: Andy Lutomirski @ 2017-01-03 5:56 UTC (permalink / raw)
To: Paul Moore
Cc: Tyler Hicks, Eric Paris, Kees Cook, Will Drewry, linux-audit,
linux-kernel@vger.kernel.org
In-Reply-To: <CAHC9VhSOwbY9WEOKZGsx4mf=MAXeudTnQF9nXmKu+OoAs0SDsQ@mail.gmail.com>
On Mon, Jan 2, 2017 at 2:47 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Mon, Jan 2, 2017 at 11:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
>> This patch set creates the basis for auditing information specific to a given
>> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
>> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
>> errno value that will be returned to userspace.
>
> I'm replying to this patchset posting because it his my inbox first,
> but my comments here apply to both this patchset and the other
> seccomp/audit patchset you posted.
>
> In my experience, we have two or three problems (the count varies
> depending on perspective) when it comes to seccomp filter reporting:
>
> 1. Inability to log all filter actions.
> 2. Inability to selectively enable filtering; e.g. devs want noisy
> logging, users want relative quiet.
> 3. Consistent behavior with audit enabled and disabled.
>
> My current thinking - forgive me, this has been kicking around in my
> head for the better part of six months (longer?) and I haven't
> attempted to code it up - is to create a sysctl knob for a system wide
> seccomp logging threshold that would be applied to the high 16-bits of
> *every* triggered action: if the action was at/below the threshold a
> record would be emitted, otherwise silence. This should resolve
> problems #1 and #2, and the code should be relatively straightforward
> and small.
>
> As part of the code above, I expect that all seccomp logging would get
> routed through a single logging function (sort of like a better
> implementation of the existing audit_seccomp()) that would check the
> threshold and trigger the logging if needed. This function could be
> augmented to check for CONFIG_AUDIT and in the case where audit was
> not built into the kernel, a simple printk could be used to log the
> seccomp event; solving problem #3.
Would this not be doable with a seccomp tracepoint and a BPF filter?
--Andy
^ permalink raw reply
* Re: [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
From: Baolin Wang @ 2017-01-03 5:54 UTC (permalink / raw)
To: myungjoo.ham, 최찬우, Chen-Yu Tsai, Kishon,
Heiko Stübner
Cc: LKML, linux-arm-kernel, linux-rockchip,
Linaro Kernel Mailman List, Baolin Wang, Mark Brown, NeilBrown
In-Reply-To: <23666cc1a5ff123ece5bdbb9821d1eab280d0927.1482307697.git.baolin.wang@linaro.org>
Hi Kison and Heiko,
On 21 December 2016 at 16:12, Baolin Wang <baolin.wang@linaro.org> wrote:
> According to the documentation, we should set the EXTCON_USB when
> one SDP charger connector was reported.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Could you apply this patch if there are no other comments? Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH] extcon: Add documentation for EXTCON_CHG_USB_SLOW/FAST
From: Baolin Wang @ 2017-01-03 5:50 UTC (permalink / raw)
To: myungjoo.ham, cw00.choi
Cc: linux-kernel, linaro-kernel, baolin.wang, broonie, neilb
Currently there are no documentation for EXTCON_CHG_USB_SLOW/FAST
charger connector. These names don't mean much and no guide to tell
users how to use it, thus try to add documentation to make them clear.
Suggested-by: NeilBrown <neilb@suse.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/linux/extcon.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 0020123..ceec1f0 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -53,6 +53,10 @@
* the USB connector, which means EXTCON_CHG_USB_SDP should always
* appear together with EXTCON_USB. The same as ACA charger connector,
* EXTCON_CHG_USB_ACA would normally appear with EXTCON_USB_HOST.
+ *
+ * A cable of type EXTCON_CHG_USB_SLOW can provide at least 500mA of
+ * current at 5V. A cable of type EXTCON_CHG_USB_FAST can provide at
+ * least 1A of current at 5V.
*/
#define EXTCON_CHG_USB_SDP 5 /* Standard Downstream Port */
#define EXTCON_CHG_USB_DCP 6 /* Dedicated Charging Port */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] nfc: Fix hangup of RC-S380* in port100_send_ack()
From: OGAWA Hirofumi @ 2017-01-03 5:48 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Aloisio Almeida Jr, Lauro Ramos Venancio, linux-wireless,
Andrew Morton, linux-kernel
In-Reply-To: <877f6clmn2.fsf_-_@mail.parknet.co.jp>
If port100_send_ack() was called twice or more, it has race to hangup.
port100_send_ack() port100_send_ack()
init_completion()
[...]
dev->cmd_cancel = true
/* this removes previous from completion */
init_completion()
[...]
dev->cmd_cancel = true
wait_for_completion()
/* never be waked up */
wait_for_completion()
Like above race, this code is not assuming port100_send_ack() is
called twice or more.
To fix, this checks dev->cmd_cancel to know if prior cancel is
in-flight or not. And never be remove prior task from completion by
using reinit_completion(), so this guarantees to be waked up properly
soon or later.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
drivers/nfc/port100.c | 37 ++++++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 13 deletions(-)
diff -puN drivers/nfc/port100.c~nfc-port100-hang-fix drivers/nfc/port100.c
--- linux-ibmpc/drivers/nfc/port100.c~nfc-port100-hang-fix 2017-01-03 12:32:13.261785257 +0900
+++ linux-ibmpc-hirofumi/drivers/nfc/port100.c 2017-01-03 12:33:51.965364300 +0900
@@ -726,23 +726,33 @@ static int port100_submit_urb_for_ack(st
static int port100_send_ack(struct port100 *dev)
{
- int rc;
+ int rc = 0;
mutex_lock(&dev->out_urb_lock);
- init_completion(&dev->cmd_cancel_done);
-
- usb_kill_urb(dev->out_urb);
+ /*
+ * If prior cancel is in-flight (dev->cmd_cancel == true), we
+ * can skip to send cancel. Then this will wait the prior
+ * cancel, or merged into the next cancel rarely if next
+ * cancel was started before waiting done. In any case, this
+ * will be waked up soon or later.
+ */
+ if (!dev->cmd_cancel) {
+ reinit_completion(&dev->cmd_cancel_done);
- dev->out_urb->transfer_buffer = ack_frame;
- dev->out_urb->transfer_buffer_length = sizeof(ack_frame);
- rc = usb_submit_urb(dev->out_urb, GFP_KERNEL);
+ usb_kill_urb(dev->out_urb);
- /* Set the cmd_cancel flag only if the URB has been successfully
- * submitted. It will be reset by the out URB completion callback
- * port100_send_complete().
- */
- dev->cmd_cancel = !rc;
+ dev->out_urb->transfer_buffer = ack_frame;
+ dev->out_urb->transfer_buffer_length = sizeof(ack_frame);
+ rc = usb_submit_urb(dev->out_urb, GFP_KERNEL);
+
+ /*
+ * Set the cmd_cancel flag only if the URB has been
+ * successfully submitted. It will be reset by the out
+ * URB completion callback port100_send_complete().
+ */
+ dev->cmd_cancel = !rc;
+ }
mutex_unlock(&dev->out_urb_lock);
@@ -929,8 +939,8 @@ static void port100_send_complete(struct
struct port100 *dev = urb->context;
if (dev->cmd_cancel) {
+ complete_all(&dev->cmd_cancel_done);
dev->cmd_cancel = false;
- complete(&dev->cmd_cancel_done);
}
switch (urb->status) {
@@ -1546,6 +1556,7 @@ static int port100_probe(struct usb_inte
PORT100_COMM_RF_HEAD_MAX_LEN;
dev->skb_tailroom = PORT100_FRAME_TAIL_LEN;
+ init_completion(&dev->cmd_cancel_done);
INIT_WORK(&dev->cmd_complete_work, port100_wq_cmd_complete);
/* The first thing to do with the Port-100 is to set the command type
_
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* [PATCH resend 3/4] nfc: Fix RC-S380* needs zero-length packet
From: OGAWA Hirofumi @ 2017-01-03 5:48 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Aloisio Almeida Jr, Lauro Ramos Venancio, linux-wireless,
Andrew Morton, linux-kernel
In-Reply-To: <87bmvolmnt.fsf@mail.parknet.co.jp>
If sent packet size is wMaxPacketSize boundary, this device doesn't
answer. To fix this, we have to send zero-length packet in usb spec.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
drivers/nfc/port100.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/nfc/port100.c~nfc-need-zero-packet drivers/nfc/port100.c
--- linux-ibmpc/drivers/nfc/port100.c~nfc-need-zero-packet 2016-12-31 18:27:14.814753508 +0900
+++ linux-ibmpc-hirofumi/drivers/nfc/port100.c 2016-12-31 18:32:12.928334607 +0900
@@ -1540,6 +1540,7 @@ static int port100_probe(struct usb_inte
usb_fill_bulk_urb(dev->out_urb, dev->udev,
usb_sndbulkpipe(dev->udev, out_endpoint),
NULL, 0, port100_send_complete, dev);
+ dev->out_urb->transfer_flags = URB_ZERO_PACKET;
dev->skb_headroom = PORT100_FRAME_HEADER_LEN +
PORT100_COMM_RF_HEAD_MAX_LEN;
_
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* [PATCH resend 2/4] nfc: Send same info for both of NFC_CMD_GET_DEVICE and NFC_EVENT_DEVICE_ADDED
From: OGAWA Hirofumi @ 2017-01-03 5:47 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Aloisio Almeida Jr, Lauro Ramos Venancio, linux-wireless,
Andrew Morton, linux-kernel
In-Reply-To: <87ful0lmop.fsf@mail.parknet.co.jp>
Now, NFC_EVENT_DEVICE_ADDED doesn't send NFC_ATTR_RF_MODE. But
NFC_CMD_GET_DEVICE send.
To get NFC_ATTR_RF_MODE, we have to call NFC_CMD_GET_DEVICE just for
NFC_ATTR_RF_MODE when get NFC_EVENT_DEVICE_ADDED.
This fixes those inconsistent.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
net/nfc/netlink.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff -puN net/nfc/netlink.c~nfc-send-same-info net/nfc/netlink.c
--- linux/net/nfc/netlink.c~nfc-send-same-info 2016-12-18 22:16:55.805686290 +0900
+++ linux-hirofumi/net/nfc/netlink.c 2016-12-18 22:16:55.806686296 +0900
@@ -311,6 +311,17 @@ free_msg:
return -EMSGSIZE;
}
+static int nfc_genl_setup_device_added(struct nfc_dev *dev, struct sk_buff *msg)
+{
+ if (nla_put_string(msg, NFC_ATTR_DEVICE_NAME, nfc_device_name(dev)) ||
+ nla_put_u32(msg, NFC_ATTR_DEVICE_INDEX, dev->idx) ||
+ nla_put_u32(msg, NFC_ATTR_PROTOCOLS, dev->supported_protocols) ||
+ nla_put_u8(msg, NFC_ATTR_DEVICE_POWERED, dev->dev_up) ||
+ nla_put_u8(msg, NFC_ATTR_RF_MODE, dev->rf_mode))
+ return -1;
+ return 0;
+}
+
int nfc_genl_device_added(struct nfc_dev *dev)
{
struct sk_buff *msg;
@@ -325,10 +336,7 @@ int nfc_genl_device_added(struct nfc_dev
if (!hdr)
goto free_msg;
- if (nla_put_string(msg, NFC_ATTR_DEVICE_NAME, nfc_device_name(dev)) ||
- nla_put_u32(msg, NFC_ATTR_DEVICE_INDEX, dev->idx) ||
- nla_put_u32(msg, NFC_ATTR_PROTOCOLS, dev->supported_protocols) ||
- nla_put_u8(msg, NFC_ATTR_DEVICE_POWERED, dev->dev_up))
+ if (nfc_genl_setup_device_added(dev, msg))
goto nla_put_failure;
genlmsg_end(msg, hdr);
@@ -604,11 +612,7 @@ static int nfc_genl_send_device(struct s
if (cb)
genl_dump_check_consistent(cb, hdr, &nfc_genl_family);
- if (nla_put_string(msg, NFC_ATTR_DEVICE_NAME, nfc_device_name(dev)) ||
- nla_put_u32(msg, NFC_ATTR_DEVICE_INDEX, dev->idx) ||
- nla_put_u32(msg, NFC_ATTR_PROTOCOLS, dev->supported_protocols) ||
- nla_put_u8(msg, NFC_ATTR_DEVICE_POWERED, dev->dev_up) ||
- nla_put_u8(msg, NFC_ATTR_RF_MODE, dev->rf_mode))
+ if (nfc_genl_setup_device_added(dev, msg))
goto nla_put_failure;
genlmsg_end(msg, hdr);
_
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* [PATCH resend 1/4] nfc: Add support RC-S380P to port100
From: OGAWA Hirofumi @ 2017-01-03 5:47 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Aloisio Almeida Jr, Lauro Ramos Venancio, linux-wireless,
Andrew Morton, linux-kernel
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
drivers/nfc/port100.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff -puN drivers/nfc/port100.c~nfc-add-rcs380p drivers/nfc/port100.c
--- linux/drivers/nfc/port100.c~nfc-add-rcs380p 2016-12-18 22:16:53.503673411 +0900
+++ linux-hirofumi/drivers/nfc/port100.c 2016-12-18 22:16:53.504673416 +0900
@@ -21,8 +21,9 @@
#define VERSION "0.1"
-#define SONY_VENDOR_ID 0x054c
-#define RCS380_PRODUCT_ID 0x06c1
+#define SONY_VENDOR_ID 0x054c
+#define RCS380S_PRODUCT_ID 0x06c1
+#define RCS380P_PRODUCT_ID 0x06c3
#define PORT100_PROTOCOLS (NFC_PROTO_JEWEL_MASK | \
NFC_PROTO_MIFARE_MASK | \
@@ -1477,7 +1478,8 @@ static struct nfc_digital_ops port100_di
};
static const struct usb_device_id port100_table[] = {
- { USB_DEVICE(SONY_VENDOR_ID, RCS380_PRODUCT_ID), },
+ { USB_DEVICE(SONY_VENDOR_ID, RCS380S_PRODUCT_ID), },
+ { USB_DEVICE(SONY_VENDOR_ID, RCS380P_PRODUCT_ID), },
{ }
};
MODULE_DEVICE_TABLE(usb, port100_table);
_
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations
From: Huang, Ying @ 2017-01-03 5:43 UTC (permalink / raw)
To: Minchan Kim
Cc: Jan Kara, Tim Chen, Andrew Morton, Ying Huang, dave.hansen, ak,
aaron.lu, linux-mm, linux-kernel, Hugh Dickins, Shaohua Li,
Rik van Riel, Andrea Arcangeli, Kirill A . Shutemov,
Vladimir Davydov, Johannes Weiner, Michal Hocko, Hillf Danton,
Christian Borntraeger, Jonathan Corbet, Peter Zijlstra,
Nicholas Piggin
In-Reply-To: <20170103043411.GA15657@bbox>
Hi, Minchan,
Minchan Kim <minchan@kernel.org> writes:
> Hi Jan,
>
> On Mon, Jan 02, 2017 at 04:48:41PM +0100, Jan Kara wrote:
>> Hi,
>>
>> On Tue 27-12-16 16:45:03, Minchan Kim wrote:
>> > > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
>> > > the rate that we have to contende for the radix tree.
>> >
>> > To me, it's rather hacky. I think it might be common problem for page cache
>> > so can we think another generalized way like range_lock? Ccing Jan.
>>
>> I agree on the hackyness of the patch and that page cache would suffer with
>> the same contention (although the files are usually smaller than swap so it
>> would not be that visible I guess). But I don't see how range lock would
>> help here - we need to serialize modifications of the tree structure itself
>> and that is difficult to achieve with the range lock. So what you would
>> need is either a different data structure for tracking swap cache entries
>> or a finer grained locking of the radix tree.
>
> Thanks for the comment, Jan.
>
> I think there are more general options. One is to shrink batching pages like
> Mel and Tim had approached.
>
> https://patchwork.kernel.org/patch/9008421/
> https://patchwork.kernel.org/patch/9322793/
This helps to reduce the lock contention on radix tree of swap cache.
But splitting swap cache has much better performance. So we switched
from that solution to current solution.
> Or concurrent page cache by peter.
>
> https://www.kernel.org/doc/ols/2007/ols2007v2-pages-311-318.pdf
I think this is good, it helps swap and file cache. But I don't know
whether other people want to go this way and how much effort will be
needed.
In contrast, splitting swap cache is quite simple, for implementation
and review. And the effect is good.
Best Regards,
Huang, Ying
> Ccing Nick who might have an interest on lockless page cache.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-03 5:38 UTC (permalink / raw)
To: Archit Taneja, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <da6d299e-be36-7564-f57f-ba5e3601cafc@codeaurora.org>
On Tuesday 03 January 2017 10:56 AM, Archit Taneja wrote:
> Hi Sekhar,
>
> On 1/2/2017 4:38 PM, Sekhar Nori wrote:
>> Hi Archit,
>>
>> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>>
>>>
>>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>>> THS8135 is a configurable video DAC, but no configuration is actually
>>>> necessary to make it work.
>>>>
>>>> For now use the dumb-vga-dac driver to support it.
>>>
>>> Queued to drm-misc-next
>>
>> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
>> to v4.10?
>
> These missed out on 4.10 because the drm related pull requests were
> already sent by then. These 2 patches are queued for 4.11.
Alright, thanks for the update.
Regards,
Sekhar
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Archit Taneja @ 2017-01-03 5:26 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <0b47c27e-cda4-b5f6-ff3c-da74c40ed204@ti.com>
Hi Sekhar,
On 1/2/2017 4:38 PM, Sekhar Nori wrote:
> Hi Archit,
>
> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>
>>
>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>>> THS8135 is a configurable video DAC, but no configuration is actually
>>> necessary to make it work.
>>>
>>> For now use the dumb-vga-dac driver to support it.
>>
>> Queued to drm-misc-next
>
> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
> to v4.10?
These missed out on 4.10 because the drm related pull requests were
already sent by then. These 2 patches are queued for 4.11.
Thanks,
Archit
>
> Thanks,
> Sekhar
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
From: James Bottomley @ 2017-01-03 5:26 UTC (permalink / raw)
To: Jarkko Sakkinen; +Cc: linux-security-module, tpmdd-devel, open list
In-Reply-To: <1483393248.2458.32.camel@HansenPartnership.com>
On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > This patch set adds support for TPM spaces that provide a
> > > > context for isolating and swapping transient objects. This
> > > > patch set does not yet include support for isolating policy and
> > > > HMAC sessions but it is trivial to add once the basic approach
> > > > is settled (and that's why I created an RFC patch set).
> > >
> > > The approach looks fine to me. The only basic query I have is
> > > about the default: shouldn't it be with resource manager on
> > > rather than off? I can't really think of a use case that wants
> > > the RM off (even if you're running your own, having another
> > > doesn't hurt anything, and it's still required to share with in
> > > -kernel uses).
> >
> > This is a valid question and here's a longish explanation.
> >
> > In TPM2_GetCapability and maybe couple of other commands you can
> > get handles in the response body. I do not want to have special
> > cases in the kernel for response bodies because there is no a
> > generic way to do the substitution. What's worse, new commands in
> > the standard future revisions could have such commands requiring
> > special cases. In addition, vendor specific commans could have
> > handles in the response bodies.
>
> OK, in general I buy this ... what you're effectively saying is that
> we need a non-RM interface for certain management type commands.
>
> However, let me expand a bit on why I'm fretting about the non-RM use
> case. Right at the moment, we have a single TPM device which you use
> for access to the kernel TPM. The current tss2 just makes direct use
> of this, meaning it has to have 0666 permissions. This means that
> any local user can simply DoS the TPM by running us out of transient
> resources if they don't activate the RM. If they get a connection
> always via the RM, this isn't a worry. Perhaps the best way of
> fixing this is to expose two separate device nodes: one raw to the
> TPM which we could keep at 0600 and one with an always RM connection
> which we can set to 0666. That would mean that access to the non-RM
> connection is either root only or governed by a system set ACL.
OK, so I put a patch together that does this (see below). It all works
nicely (with a udev script that sets the resource manager device to
0666):
jejb@jarvis:~> ls -l /dev/tpm*
crw------- 1 root root 10, 224 Jan 2 20:54 /dev/tpm0
crw-rw-rw- 1 root root 246, 65536 Jan 2 20:54 /dev/tpm0rm
I've modified the tss to connect to /dev/tpm0rm by default and it all
seems to work.
The patch applies on top of your tabrm branch, by the way.
James
---
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index ac4c05f..25b8d30 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -33,6 +33,7 @@ DEFINE_IDR(dev_nums_idr);
static DEFINE_MUTEX(idr_lock);
struct class *tpm_class;
+struct class *tpm_rm_class;
dev_t tpm_devt;
/**
@@ -169,27 +170,39 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
chip->dev_num = rc;
device_initialize(&chip->dev);
+ device_initialize(&chip->devrm);
chip->dev.class = tpm_class;
chip->dev.release = tpm_dev_release;
chip->dev.parent = pdev;
chip->dev.groups = chip->groups;
+ chip->devrm.parent = pdev;
+ chip->devrm.class = tpm_rm_class;
+
if (chip->dev_num == 0)
chip->dev.devt = MKDEV(MISC_MAJOR, TPM_MINOR);
else
chip->dev.devt = MKDEV(MAJOR(tpm_devt), chip->dev_num);
+ chip->devrm.devt = MKDEV(MAJOR(tpm_devt), chip->dev_num + TPM_NUM_DEVICES);
+
rc = dev_set_name(&chip->dev, "tpm%d", chip->dev_num);
if (rc)
goto out;
+ rc = dev_set_name(&chip->devrm, "tpm%drm", chip->dev_num);
+ if (rc)
+ goto out;
if (!pdev)
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
cdev_init(&chip->cdev, &tpm_fops);
+ cdev_init(&chip->cdevrm, &tpm_rm_fops);
chip->cdev.owner = THIS_MODULE;
+ chip->cdevrm.owner = THIS_MODULE;
chip->cdev.kobj.parent = &chip->dev.kobj;
+ chip->cdevrm.kobj.parent = &chip->devrm.kobj;
chip->tr_buf.data = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
if (!chip->tr_buf.data) {
@@ -208,6 +221,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
out:
put_device(&chip->dev);
+ put_device(&chip->devrm);
return ERR_PTR(rc);
}
EXPORT_SYMBOL_GPL(tpm_chip_alloc);
@@ -252,7 +266,7 @@ static int tpm_add_char_device(struct tpm_chip *chip)
dev_name(&chip->dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
- return rc;
+ goto err_1;
}
rc = device_add(&chip->dev);
@@ -262,16 +276,44 @@ static int tpm_add_char_device(struct tpm_chip *chip)
dev_name(&chip->dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
- cdev_del(&chip->cdev);
- return rc;
+ goto err_2;
+ }
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ rc = cdev_add(&chip->cdevrm, chip->devrm.devt, 1);
+ if (rc) {
+ dev_err(&chip->dev,
+ "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+ dev_name(&chip->devrm), MAJOR(chip->devrm.devt),
+ MINOR(chip->devrm.devt), rc);
+
+ goto err_3;
}
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ rc = device_add(&chip->devrm);
+ if (rc) {
+ dev_err(&chip->dev,
+ "unable to device_register() %s, major %d, minor %d, err=%d\n",
+ dev_name(&chip->devrm), MAJOR(chip->devrm.devt),
+ MINOR(chip->devrm.devt), rc);
+
+ goto err_4;
+ }
/* Make the chip available. */
mutex_lock(&idr_lock);
idr_replace(&dev_nums_idr, chip, chip->dev_num);
mutex_unlock(&idr_lock);
return rc;
+ err_4:
+ cdev_del(&chip->cdevrm);
+ err_3:
+ device_del(&chip->dev);
+ err_2:
+ cdev_del(&chip->cdev);
+ err_1:
+ return rc;
}
static void tpm_del_char_device(struct tpm_chip *chip)
@@ -279,6 +321,11 @@ static void tpm_del_char_device(struct tpm_chip *chip)
cdev_del(&chip->cdev);
device_del(&chip->dev);
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ cdev_del(&chip->cdevrm);
+ device_del(&chip->devrm);
+ }
+
/* Make the chip unavailable. */
mutex_lock(&idr_lock);
idr_replace(&dev_nums_idr, NULL, chip->dev_num);
diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
index 139638b..bed29f9 100644
--- a/drivers/char/tpm/tpm-dev.c
+++ b/drivers/char/tpm/tpm-dev.c
@@ -54,23 +54,28 @@ static void timeout_work(struct work_struct *work)
mutex_unlock(&priv->buffer_mutex);
}
-static int tpm_open(struct inode *inode, struct file *file)
+static int tpm_open_internal(struct inode *inode, struct file *file, bool is_rm)
{
- struct tpm_chip *chip =
- container_of(inode->i_cdev, struct tpm_chip, cdev);
+ struct tpm_chip *chip;
struct file_priv *priv;
+ if (is_rm)
+ chip = container_of(inode->i_cdev, struct tpm_chip, cdevrm);
+ else
+ chip = container_of(inode->i_cdev, struct tpm_chip, cdev);
+
/* It's assured that the chip will be opened just once,
* by the check of is_open variable, which is protected
* by driver_lock. */
- if (test_and_set_bit(0, &chip->is_open)) {
+ if (!is_rm && test_and_set_bit(0, &chip->is_open)) {
dev_dbg(&chip->dev, "Another process owns this TPM\n");
return -EBUSY;
}
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (priv == NULL) {
- clear_bit(0, &chip->is_open);
+ if (!is_rm)
+ clear_bit(0, &chip->is_open);
return -ENOMEM;
}
@@ -82,9 +87,27 @@ static int tpm_open(struct inode *inode, struct file *file)
INIT_WORK(&priv->work, timeout_work);
file->private_data = priv;
+
+ if (is_rm) {
+ priv->space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!priv->space.context_buf)
+ return -ENOMEM;
+ priv->has_space = true;
+ }
+
return 0;
}
+static int tpm_open(struct inode *inode, struct file *file)
+{
+ return tpm_open_internal(inode, file, false);
+}
+
+static int tpm_rm_open(struct inode *inode, struct file *file)
+{
+ return tpm_open_internal(inode, file, true);
+}
+
static ssize_t tpm_read(struct file *file, char __user *buf,
size_t size, loff_t *off)
{
@@ -169,65 +192,6 @@ static ssize_t tpm_write(struct file *file, const char __user *buf,
return in_size;
}
-/**
- * tpm_ioc_new_space - handler for %SGX_IOC_NEW_SPACE ioctl
- *
- * Creates a new TPM space that can hold a set of transient objects. The space
- * is isolated with virtual handles that are mapped into physical handles by the
- * driver.
- */
-static long tpm_ioc_new_space(struct file *file, unsigned int ioctl,
- unsigned long arg)
-{
- struct file_priv *priv = file->private_data;
- struct tpm_chip *chip = priv->chip;
- int rc = 0;
-
- if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
- return -EOPNOTSUPP;
-
- mutex_lock(&priv->buffer_mutex);
-
- if (priv->has_space) {
- rc = -EBUSY;
- goto out;
- }
-
- priv->space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
- if (!priv->space.context_buf) {
- rc = -ENOMEM;
- goto out;
- }
-
- /* The TPM device can be opened again as this file has been moved to a
- * TPM handle space.
- */
- priv->has_space = true;
- clear_bit(0, &chip->is_open);
-out:
- mutex_unlock(&priv->buffer_mutex);
- return rc;
-}
-
-static long tpm_ioctl(struct file *file, unsigned int ioctl,
- unsigned long arg)
-{
- switch (ioctl) {
- case TPM_IOC_NEW_SPACE:
- return tpm_ioc_new_space(file, ioctl, arg);
- default:
- return -ENOIOCTLCMD;
- }
-}
-
-#ifdef CONFIG_COMPAT
-static long tpm_compat_ioctl(struct file *file, unsigned int ioctl,
- unsigned long arg)
-{
- return tpm_ioctl(file, ioctl, arg);
-}
-#endif
-
/*
* Called on file close
*/
@@ -247,7 +211,8 @@ static int tpm_release(struct inode *inode, struct file *file)
flush_work(&priv->work);
file->private_data = NULL;
atomic_set(&priv->data_pending, 0);
- clear_bit(0, &priv->chip->is_open);
+ if (!priv->has_space)
+ clear_bit(0, &priv->chip->is_open);
kfree(priv);
return 0;
}
@@ -258,10 +223,15 @@ const struct file_operations tpm_fops = {
.open = tpm_open,
.read = tpm_read,
.write = tpm_write,
- .unlocked_ioctl = tpm_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = tpm_compat_ioctl,
-#endif
+ .release = tpm_release,
+};
+
+const struct file_operations tpm_rm_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .open = tpm_rm_open,
+ .read = tpm_read,
+ .write = tpm_write,
.release = tpm_release,
};
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a1ae57e..c1829de 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1194,9 +1194,17 @@ static int __init tpm_init(void)
return PTR_ERR(tpm_class);
}
- rc = alloc_chrdev_region(&tpm_devt, 0, TPM_NUM_DEVICES, "tpm");
+ tpm_rm_class = class_create(THIS_MODULE, "tpmrm");
+ if (IS_ERR(tpm_rm_class)) {
+ pr_err("couldn't create tpmrm class\n");
+ class_destroy(tpm_class);
+ return PTR_ERR(tpm_rm_class);
+ }
+
+ rc = alloc_chrdev_region(&tpm_devt, 0, 2*TPM_NUM_DEVICES, "tpm");
if (rc < 0) {
pr_err("tpm: failed to allocate char dev region\n");
+ class_destroy(tpm_rm_class);
class_destroy(tpm_class);
return rc;
}
@@ -1208,7 +1216,8 @@ static void __exit tpm_exit(void)
{
idr_destroy(&dev_nums_idr);
class_destroy(tpm_class);
- unregister_chrdev_region(tpm_devt, TPM_NUM_DEVICES);
+ class_destroy(tpm_rm_class);
+ unregister_chrdev_region(tpm_devt, 2*TPM_NUM_DEVICES);
}
subsys_initcall(tpm_init);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index c6171e5..890fb6b 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -186,8 +186,8 @@ struct tpm_buf {
};
struct tpm_chip {
- struct device dev;
- struct cdev cdev;
+ struct device dev, devrm;
+ struct cdev cdev, cdevrm;
/* A driver callback under ops cannot be run unless ops_sem is held
* (sometimes implicitly, eg for the sysfs code). ops becomes null
@@ -493,8 +493,10 @@ static inline void tpm_buf_append_u32(struct tpm_buf *buf, const u32 value)
}
extern struct class *tpm_class;
+extern struct class *tpm_rm_class;
extern dev_t tpm_devt;
extern const struct file_operations tpm_fops;
+extern const struct file_operations tpm_rm_fops;
extern struct idr dev_nums_idr;
enum tpm_transmit_flags {
^ permalink raw reply related
* RE: [PATCH 00/18] ACPICA 20161222 Release
From: Zheng, Lv @ 2017-01-03 5:23 UTC (permalink / raw)
To: Rafael J. Wysocki, Brown, Len
Cc: Lv Zheng, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
In-Reply-To: <4861890.YlOS97DeY7@aspire.rjw.lan>
Hi, Rafael
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Subject: Re: [PATCH 00/18] ACPICA 20161222 Release
>
> On Wednesday, December 28, 2016 03:28:00 PM Lv Zheng wrote:
> > The 20161222 ACPICA kernel-resident subsystem updates are linuxized based
> > on the linux-pm/linux-next branch.
> >
> > The patchset has passed the following build/boot tests.
> > Build tests are performed as follows:
> > 1. i386 + allyes
> > 2. i386 + allno
> > 3. i386 + default + ACPI_DEBUGGER=y
> > 4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
> > 5. i386 + default + ACPI_DEBUG=n + ACPI=y
> > 6. i386 + default + ACPI=n
> > 7. x86_64 + allyes
> > 8. x86_64 + allno
> > 9. x86_64 + default + ACPI_DEBUGGER=y
> > 10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y
> > 11.x86_64 + default + ACPI_DEBUG=n + ACPI=y
> > 12.x86_64 + default + ACPI=n
> > Boot tests are performed as follows:
> > 1. x86_64 + default + ACPI_DEBUGGER=y
> > Where:
> > 1. i386: machine named as "Dell Inspiron Mini 1010"
> > 2. x86_64: machine named as "Microsoft Surface Pro 3"
> > 3. default: kernel configuration with following items enabled:
> > All hardware drivers related to the machines of i386/x86_64
> > All "drivers/acpi" configurations
> > All "drivers/platform" drivers
> > All other drivers that link the APIs provided by ACPICA subsystem
> >
> > The divergences checking result:
> > Before applying (20161117 Release):
> > 467 lines
> > After applying (20161222 Release):
> > 369 lines
> >
> > Bob Moore (8):
> > ACPICA: Macro header: Fix some typos in comments. No functional change
> > ACPICA: Utilities: Update debug output
> > ACPICA: Resources: Not a valid resource if buffer length too long
> > ACPICA: Fix for implicit result conversion for the ToXXXX functions
> > ACPICA: Parser: Allow method invocations as target operands
> > ACPICA: Fix a problem with recent extra support for control method
> > invocations
> > ACPICA: Parser: Update parse info table for some operators
> > ACPICA: Update version to 20161222
> >
> > Colin Ian King (1):
> > ACPICA: Linux-specific header: Add support for s390x compilation.
> >
> > David E. Box (1):
> > ACPICA: Disassembler: Add Switch/Case disassembly support
> >
> > Lv Zheng (8):
> > ACPICA: Debugger: Rename debugger OSL names
> > ACPICA: Hardware: Remove bit_offset masking support
> > ACPICA: Hardware: Add access_width/bit_offset support in
> > acpi_hw_write()
> > ACPICA: Utilities: Add power of two rounding support
> > ACPICA: Hardware: Sort access bit width algorithm
> > ACPICA: Hardware: Add sleep register hooks
> > ACPICA: MSVC: Fix MSVC6 build issues
> > ACPICA: EFI: Add efihello demo application
> >
> > drivers/acpi/acpica/aclocal.h | 7 +-
> > drivers/acpi/acpica/acmacros.h | 72 +++++++++-
> > drivers/acpi/acpica/acopcode.h | 22 +--
> > drivers/acpi/acpica/amlcode.h | 20 ++-
> > drivers/acpi/acpica/dbxface.c | 4 +-
> > drivers/acpi/acpica/exconvrt.c | 1 -
> > drivers/acpi/acpica/exresop.c | 1 -
> > drivers/acpi/acpica/hwesleep.c | 35 +++--
> > drivers/acpi/acpica/hwregs.c | 153 +++++++++++++++------
> > drivers/acpi/acpica/hwsleep.c | 11 +-
> > drivers/acpi/acpica/psargs.c | 97 +++++++++----
> > drivers/acpi/acpica/psloop.c | 4 +
> > drivers/acpi/acpica/psobject.c | 10 +-
> > drivers/acpi/acpica/pstree.c | 10 +-
> > drivers/acpi/acpica/utdecode.c | 4 +-
> > drivers/acpi/acpica/utdelete.c | 6 +-
> > drivers/acpi/acpica/utresrc.c | 17 ++-
> > drivers/acpi/osl.c | 27 +++-
> > include/acpi/acexcep.h | 9 +-
> > include/acpi/acpiosxf.h | 12 +-
> > include/acpi/acpixf.h | 2 +-
> > include/acpi/platform/acenv.h | 5 +-
> > include/acpi/platform/aclinux.h | 7 +-
> > include/acpi/platform/aclinuxex.h | 4 +-
> > .../acpi/os_specific/service_layers/osunixxf.c | 22 +++
> > 25 files changed, 405 insertions(+), 157 deletions(-)
>
> Any chance to make patch [14/18] go to any mailing lists or actually any
> outside addresses *at* *all* without being filtered out by spam filters or
> similar?
It seems the ToXXX in the subject "ACPICA: Fix for implicit result conversion for the ToXXXX functions" hit spam filters from 1 of the chained MDAs:
#5.0.0 smtp; 5.3.0 - Other mail system problem 550-'5.7.1 Content-Policy reject msg: The capital Triple-X in subject is way too often associated with junk email, please rephrase.
I'll re-phrase and re-send the PATCH 14/18.
Thanks
Lv
^ permalink raw reply
* Re: [RFC] pps: fixing CONFIG_COMPAT issues
From: Matt Ranostay @ 2017-01-03 5:13 UTC (permalink / raw)
To: Rodolfo Giometti; +Cc: linux-kernel, David Woodhouse
In-Reply-To: <99f30723-d278-4cce-0802-d9812b187afe@enneenne.com>
On Fri, Dec 23, 2016 at 7:04 AM, Rodolfo Giometti <giometti@enneenne.com> wrote:
> On 12/22/16 21:39, Matt Ranostay wrote:
>>
>>
>> What would be the best way to fix the padding issue without breaking
>> userspace applications? Just fixing the alignment with explicit
>> padding is of course the clean easy way, but bashing the data in
>> compat_ioctl would avoid breakage.
>
>
> Hi Matt,
>
> I've no experience in this topic... I'm sorry! :(
>
> Maybe is better waiting for David's advices? In the meantime I'm going to
> study the problem a bit better.
Just poking to see if anyone has a better solution. Since the long
holidays are over :)
Thanks,
Matt
>
> Ciao,
>
> Rodolfo
>
> --
>
> HCE Engineering e-mail: giometti@hce-engineering.com
> GNU/Linux Solutions giometti@enneenne.com
> Linux Device Driver giometti@linux.it
> Embedded Systems phone: +39 349 2432127
> UNIX programming skype: rodolfo.giometti
> Cosino Project - the quick prototyping embedded system - www.cosino.io
> Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
^ permalink raw reply
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2017-01-03 5:06 UTC (permalink / raw)
To: Richard Cochran
Cc: Nicolas Ferre, Rafal Ozieblo, Andrei Pistirica,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
harini.katakam@xilinx.com, punnaia@xilinx.com, michals@xilinx.com,
anirudh@xilinx.com, boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <20170102161359.GD3609@localhost.localdomain>
Hi Richard,
On Mon, Jan 2, 2017 at 9:43 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote:
>> Le 02/01/2017 à 12:31, Richard Cochran a écrit :
>> > This Cadence IP core is a complete disaster.
>>
>> Well, it evolved and propose several options to different SoC
>> integrators. This is not something unusual...
>> I suspect as well that some other network adapters have the same
>> weakness concerning PTP timestamp in single register as the early
>> revisions of this IP.
>
> It appears that this core can neither latch the time on read or write,
> or even latch time stamps. I have worked with many different PTP HW
> implementations, even early ones like on the ixp4xx, and it is no
> exaggeration to say that this one is uniquely broken.
>
>> I suspect that Rafal tend to jump too quickly to the latest IP revisions
>> and add more options to this series: let's not try to pour too much
>> things into this code right now.
>
> Why can't you check the IP version in the driver?
There is an IP revision register but it would be probably be better
to rely on "caps" from the compatibility strings - to cover SoC
specific implementations. Also, when this extended BD is
added (with timestamp), additional words will need to be added
statically which will be consistent with Andrei's CONFIG_
checks.
>
> And is it really true that the registers don't latch the time stamps,
> as Rafal said? If so, then we cannot accept the non-descriptor driver
> version, since it cannot possibly work correctly.
>
AFAIK, the two sets of registers only hold the timestamp till the next
event (or peer event) packet comes in.
I understand that it is not accurate - it is an initial version.
Regards,
Harini
^ permalink raw reply
* Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint
From: Minchan Kim @ 2017-01-03 5:03 UTC (permalink / raw)
To: Michal Hocko
Cc: Hillf Danton, linux-mm, Andrew Morton, Mel Gorman,
Johannes Weiner, Vlastimil Babka, Rik van Riel, LKML
In-Reply-To: <20161230163742.GK13301@dhcp22.suse.cz>
Hi Michal,
On Fri, Dec 30, 2016 at 05:37:42PM +0100, Michal Hocko wrote:
> On Sat 31-12-16 01:04:56, Minchan Kim wrote:
> [...]
> > > From 5f1bc22ad1e54050b4da3228d68945e70342ebb6 Mon Sep 17 00:00:00 2001
> > > From: Michal Hocko <mhocko@suse.com>
> > > Date: Tue, 27 Dec 2016 13:18:20 +0100
> > > Subject: [PATCH] mm, vmscan: add active list aging tracepoint
> > >
> > > Our reclaim process has several tracepoints to tell us more about how
> > > things are progressing. We are, however, missing a tracepoint to track
> > > active list aging. Introduce mm_vmscan_lru_shrink_active which reports
> >
> > I agree this part.
> >
> > > the number of
> > > - nr_scanned, nr_taken pages to tell us the LRU isolation
> > > effectiveness.
> >
> > I agree nr_taken for knowing shrinking effectiveness but don't
> > agree nr_scanned. If we want to know LRU isolation effectiveness
> > with nr_scanned and nr_taken, isolate_lru_pages will do.
>
> Yes it will. On the other hand the number is there and there is no
> additional overhead, maintenance or otherwise, to provide that number.
You are adding some instructions, how can you imagine it's no overhead?
Let's say whether it's measurable. Although it's not big in particular case,
it would be measurable if everyone start to say like that "it's trivial so
what's the problem adding a few instructions although it was duplicated?"
You already said "LRU isolate effectiveness". It should be done in there,
isolate_lru_pages and we have been. You need another reasons if you want to
add the duplicated work, strongly.
> The inactive counterpart does that for quite some time already. So why
It couldn't be a reason. If it was duplicated in there, it would be
better to fix it rather than adding more duplciated work to match both
sides.
> exactly does that matter? Don't take me wrong but isn't this more on a
> nit picking side than necessary? Or do I just misunderstand your
> concenrs? It is not like we are providing a stable user API as the
My concern is that I don't see what we can get benefit from those
duplicated work. If it doesn't give benefit to us, I don't want to add.
I hope you think another reasonable reasons.
> tracepoint is clearly implementation specific and not something to be
> used for anything other than debugging.
My point is we already had things "LRU isolation effectivness". Namely,
isolate_lru_pages.
>
> > > - nr_rotated pages which tells us that we are hitting referenced
> > > pages which are deactivated. If this is a large part of the
> > > reported nr_deactivated pages then the active list is too small
> >
> > It might be but not exactly. If your goal is to know LRU size, it can be
> > done in get_scan_count. I tend to agree LRU size is helpful for
> > performance analysis because decreased LRU size signals memory shortage
> > then performance drop.
>
> No, I am not really interested in the exact size but rather to allow to
> find whether we are aging the active list too early...
Could you elaborate it more that how we can get active list early aging
with nr_rotated?
Thanks.
^ permalink raw reply
* linux-next: Tree for Jan 3
From: Stephen Rothwell @ 2017-01-03 4:56 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
Hi all,
Changes since 20161224:
Dropped tree: rdma-leon (complex conflicts)
The drm-intel-fixes tree gained a conflict against the vfio-fixes tree
and a build failure for which I applied a merge fix patch.
The mips tree gained a conflict against Linus' tree.
The rdma-leon tree gained conflicts against the net-next tree.
The drm-misc tree gained conflicts against the drm-intel tree.
Non-merge commits (relative to Linus' tree): 1439
1902 files changed, 58757 insertions(+), 24837 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.
Below is a summary of the state of the merge.
I am currently merging 246 trees (counting Linus' and 35 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (da2875673660 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to arm64 producing host-arch debs)
Merging arc-current/for-curr (7ce7d89f4883 Linux 4.10-rc1)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to definitions")
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (69973b830859 Linux 4.9)
Merging sparc/master (4bbc84ffd137 sparc: use symbolic names for tsb indexing)
Merging net/master (4e5da369df64 Documentation/networking: fix typo in mpls-sysctl)
Merging ipsec/master (bc3913a5378c Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging netfilter/master (6c5d5cfbe3c5 netfilter: ipt_CLUSTERIP: check duplicate config when initializing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (60f59ce02785 rtlwifi: rtl_usb: Fix missing entry in USB driver's private data)
Merging mac80211/master (35f432a03e41 mac80211: initialize fast-xmit 'info' later)
Merging sound-current/for-linus (2d706e790f05 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging pci-current/for-linus (4931a6781f83 x86/PCI: Ignore _CRS on Supermicro X8DTH-i/6/iF/6F)
Merging driver-core.current/driver-core-linus (0c744ea4f77d Linux 4.10-rc2)
Merging tty.current/tty-linus (0c744ea4f77d Linux 4.10-rc2)
Merging usb.current/usb-linus (0c744ea4f77d Linux 4.10-rc2)
Merging usb-gadget-fixes/fixes (7b0173811260 usb: gadget: udc: core: fix return code of usb_gadget_probe_driver())
Merging usb-serial-fixes/usb-linus (427157631648 USB: serial: f81534: detect errors from f81534_logic_to_phy_port())
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu)
Merging staging.current/staging-linus (890b73af6b00 Merge tag 'iio-fixes-for-4.10a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (0c744ea4f77d Linux 4.10-rc2)
Merging input-current/for-linus (72f0991354b2 Merge branch 'synaptics-rmi4' into for-linus)
Merging crypto-current/master (07825f0acd85 crypto: aesni - Fix failure when built-in with modular pcbc)
Merging ide/master (b2ae75052a8c ide: Fix interface autodetection in legacy IDE driver (trial #2))
Merging vfio-fixes/for-linus (45e869714489 vfio-pci: use 32-bit comparisons for register address for gcc-4.5)
Merging kselftest-fixes/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct)
Merging mfd-fixes/for-mfd-fixes (1a41741fd60b mfd: wm8994-core: Don't use managed regulator bulk get API)
Merging drm-intel-fixes/for-linux-next-fixes (ade4d4410f8b Merge tag 'gvt-fixes-2016-12-26' of https://github.com/01org/gvt-linux into drm-intel-fixes)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gvt/kvmgt.c
Merging drm-misc-fixes/for-linux-next-fixes (7ce7d89f4883 Linux 4.10-rc1)
Applying: vfio-mdev: fixup for "Make mdev_device private and abstract interfaces"
Merging kbuild/for-next (a6d1da25b333 Merge branch 'kbuild/kbuild' into kbuild/for-next)
Merging asm-generic/master (de4be6b87b6b asm-generic: page.h: fix comment typo)
CONFLICT (content): Merge conflict in include/asm-generic/percpu.h
Merging arc/for-next (e5517c2a5a49 Linux 4.9-rc7)
Merging arm/for-next (49b05da80546 Merge branch 'drm-armada-devel' into for-next)
Merging arm-perf/for-next/perf (f43365ee17f8 selftests: arm64: add test for unaligned/inexact watchpoint handling)
Merging arm-soc/for-next (991688bfc635 Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging amlogic/for-next (b21a5fc2bb8a Merge branch 'v4.10/defconfig' into tmp/aml-rebuild)
Merging at91/at91-next (0f59c948faed Merge tag 'at91-ab-4.8-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into at91-next)
Merging bcm2835/for-next (ec09fdf764ee Merge branch anholt/bcm2835-defconfig-64-next into for-next)
Merging berlin/berlin/for-next (5153351425c9 Merge branch 'berlin/dt' into berlin/for-next)
Merging cortex-m/for-next (f719a0d6a854 ARM: efm32: switch to vendor,device compatible strings)
Merging imx-mxs/for-next (242a001e48b7 Merge branch 'zte/dt64' into for-next)
Merging keystone/next (fb2a68db621a Merge branch 'for_4.9/keystone_dts' into next)
Merging mvebu/for-next (5cfcfe81e33b Merge branch 'mvebu/dt64' into mvebu/for-next)
Merging omap/for-next (1a38de880992 ARM: dts: am572x-idk: Add gpios property to control PCIE_RESETn)
Merging omap-pending/for-next (c20c8f750d9f ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence)
Merging qcom/for-next (bbf9c90768f9 Merge tag 'qcom-dts-for-4.10-2' into all-for-4.10-part2)
Merging renesas/next (411253aa4a68 Merge branch 'fixes-for-v4.10' into next)
CONFLICT (content): Merge conflict in drivers/soc/renesas/Makefile
Merging rockchip/for-next (7efd9733e204 Merge branch 'v4.11-clk/next' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (1001354ca341 Linux 4.9-rc1)
Merging samsung-krzk/for-next (8ae2065bd399 Merge branch 'next/dt64' into for-next)
Merging tegra/for-next (e8d16d40e269 Merge branch for-4.10/i2c into for-next)
Merging arm64/for-next/core (75037120e62b arm64: Disable PAN on uaccess_enable())
Merging clk/clk-next (cac53644aa06 clk: qcom: Add GCC_MSS_RESET support)
Merging blackfin/for-linus (391e74a51ea2 eth: bf609 eth clock: add pclk clock for stmmac driver probe)
CONFLICT (content): Merge conflict in arch/blackfin/mach-common/pm.c
Merging c6x/for-linux-next (ca3060d39ae7 c6x: Use generic clkdev.h header)
Merging cris/for-next (8f50f2a1b46a cris: No need to append -O2 and $(LINUXINCLUDE))
Merging h8300/h8300-next (58c57526711f h8300: Add missing include file to asm/io.h)
Merging hexagon/linux-next (02cc2ccfe771 Revert "Hexagon: fix signal.c compile error")
Merging ia64/next (fbb0e4da96f4 ia64: salinfo: use a waitqueue instead a sema down/up combo)
Merging m68k/for-next (ad595b77c4a8 m68k/atari: Use seq_puts() in atari_get_hardware_list())
Merging m68knommu/for-next (7ce7d89f4883 Linux 4.10-rc1)
Merging metag/for-next (f5d163aad31e metag: perf: fix build on Meta1)
Merging microblaze/next (3400606d8ffd microblaze: Add new fpga families)
Merging mips/mips-for-linux-next (12a733bf9158 MIPS: ralink: Fix incorrect assignment on ralink_soc)
CONFLICT (modify/delete): arch/mips/kernel/mips_ksyms.c deleted in mips/mips-for-linux-next and modified in HEAD. Version HEAD of arch/mips/kernel/mips_ksyms.c left in tree.
$ git rm -f arch/mips/kernel/mips_ksyms.c
Merging nios2/for-next (744606c76c4a nios2: add screen_info)
Merging openrisc/for-next (7c7808ce107d openrisc: prevent VGA console, fix builds)
Merging parisc-hd/for-next (b4a9eb4cd596 parisc: Add line-break when printing segfault info)
Merging powerpc/next (c6f6634721c8 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next)
Merging fsl/next (baae856ebdee powerpc/fsl/dts: add FMan node for t1042d4rdb)
Merging mpc5xxx/next (39e69f55f857 powerpc: Introduce the use of the managed version of kzalloc)
Merging s390/features (d8b99c36519c s390/pci: use proper endianness annotations)
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging sh/for-next (e61c10e468a4 sh: add device tree source for J2 FPGA on Mimas v2 board)
Merging tile/master (14e73e78ee98 tile: use __ro_after_init instead of tile-specific __write_once)
Merging uml/linux-next (f88f0bdfc32f um: UBD Improvements)
Merging unicore32/unicore32 (bc27113620ca unicore32-oldabi: add oldabi syscall interface)
Merging xtensa/xtensa-for-next (30b507051dd1 xtensa: update DMA-related Documentation/features entries)
Merging befs/for-next (f7b75aaed5ef befs: add NFS export support)
Merging btrfs/next (8b8b08cbfb90 Btrfs: fix delalloc accounting after copy_from_user faults)
Merging btrfs-kdave/for-next (2939e1a86f75 btrfs: limit async_work allocation and worker func duration)
Merging ceph/master (45ee2c1d6618 libceph: remove now unused finish_request() wrapper)
Merging cifs/for-next (7c0f6ba682b9 Replace <asm/uaccess.h> with <linux/uaccess.h> globally)
Merging configfs/for-next (e16769d4bca6 fs: configfs: don't return anything from drop_link)
Merging ecryptfs/next (be280b25c328 ecryptfs: remove private bin2hex implementation)
Merging ext3/for_next (2700e6067c72 quota: Fix bogus warning in dquot_disable())
Merging ext4/dev (a551d7c8deef Merge branch 'fscrypt' into dev)
Merging f2fs/dev (238d1d0f79f6 Merge tag 'docs-4.10-rc1-fix' of git://git.lwn.net/linux)
Merging freevxfs/for-next (bf1bb4b460c8 freevxfs: update Kconfig information)
Merging fscache/fscache (d52bd54db8be Merge branch 'akpm' (patches from Andrew))
Merging fuse/for-next (c01638f5d919 fuse: fix clearing suid, sgid for chown())
Merging gfs2/for-next (23754c081d1b GFS2: Limit number of transaction blocks requested for truncates)
Merging jfs/jfs-next (362ad5d58e9a fs: jfs: Replace CURRENT_TIME_SEC by current_time())
Merging nfs/linux-next (8ac2b42238f5 NFSv4: Retry the DELEGRETURN if the embedded GETATTR is rejected with EACCES)
Merging nfsd/nfsd-next (7d7e7597c313 SUNRPC: change UDP socket space reservation)
Merging orangefs/for-next (04102c76a779 orangefs: Axe some dead code)
Merging overlayfs/overlayfs-next (c3c869966480 ovl: fix reStructuredText syntax errors in documentation)
Merging v9fs/for-next (a333e4bf2556 fs/9p: use fscache mutex rather than spinlock)
Merging ubifs/linux-next (ba75d570b60c ubifs: Initialize fstr_real_len)
Merging xfs/for-next (9807b773dad4 Merge branch 'xfs-4.10-misc-fixes-4' into for-next)
Merging file-locks/linux-next (07d9a380680d Linux 4.9-rc2)
Merging vfs/for-next (59479ae85e43 Merge branches 'work.sendmsg' and 'work.splice-net' into for-next)
Merging vfs-jk/vfs (030b533c4fd4 fs: Avoid premature clearing of capabilities)
Merging vfs-miklos/next (b12826c5188e Merge branch 'vfs-ovl' into next)
CONFLICT (content): Merge conflict in fs/read_write.c
CONFLICT (content): Merge conflict in fs/overlayfs/dir.c
Merging pci/next (7ce7d89f4883 Linux 4.10-rc1)
Merging pstore/for-next/pstore (fc46d4e453f5 ramoops: add pdata NULL check to ramoops_probe)
Merging hid/for-next (d0dbfbe26b0c Merge branch 'for-4.10/upstream-fixes' into for-next)
Merging i2c/i2c/for-next (649ac63a9ae5 i2c: mux: mlxcpld: fix i2c mux selection caching)
Merging jdelvare-hwmon/master (08d27eb20666 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging dmi/master (27ec191a79ca firmware: dmi_scan: Always show system identification string)
Merging hwmon-staging/hwmon-next (53e678d75e7c hwmon: (sht21) Add Electronic Identification Code retrieval)
Merging jc_docs/docs-next (36f671be1db1 Documentation/unaligned-memory-access.txt: fix incorrect comparison operator)
Merging v4l-dvb/master (5dd2470bfddb Merge branch 'v4l_for_linus' into to_next)
Merging pm/linux-next (67ee75867f56 Merge branch 'pm-domains' into linux-next)
Merging idle/next (306899f94804 x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc())
Merging thermal/next (0faf7dd5a947 MAINTAINERS: Samsung: Update maintainer for PWM FAN and SAMSUNG THERMAL)
Merging thermal-soc/next (18591add41ec thermal: rockchip: handle set_trips without the trip points)
Merging ieee1394/for-next (e9300a4b7bba firewire: net: fix fragmented datagram_size off-by-one)
Merging dlm/next (aa9f1012858b dlm: don't specify WQ_UNBOUND for the ast callback workqueue)
Merging swiotlb/linux-next (d29fa0cb7602 swiotlb: Minor fix-ups for DMA_ATTR_SKIP_CPU_SYNC support)
Merging net-next/master (0a0a8d6b0e88 net: fealnx: use new api ethtool_{get|set}_link_ksettings)
Merging ipsec-next/master (d4aea20d889e tun: Use netif_receive_skb instead of netif_rx)
Merging netfilter-next/master (8f18e4d03ed8 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipvs-next/master (8d8e20e2d7bb ipvs: Decrement ttl)
Merging wireless-drivers-next/master (e16e558e83ed rtlwifi: fix spelling mistake: "encrypiton" -> "encryption")
Merging bluetooth/master (107bc0aa95ca Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next)
Merging mac80211-next/master (b7f98864de21 cfg80211: fix example REG_RULE usage in Documentation)
Merging rdma/for-next (6f94ba20799b Merge branch 'vmw_pvrdma' into merge-test)
Merging rdma-leon/rdma-next (5307ef0f92b8 Merge branch 'topic/flow-tag' into rdma-next)
CONFLICT (content): Merge conflict in include/linux/mlx5/mlx5_ifc.h
CONFLICT (content): Merge conflict in include/linux/mlx5/driver.h
CONFLICT (content): Merge conflict in include/linux/mlx5/device.h
CONFLICT (content): Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/main.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/eq.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
CONFLICT (content): Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/en_main.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/mlx5/qp.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/mlx5/mr.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/mlx5/mlx5_ib.h
CONFLICT (content): Merge conflict in drivers/infiniband/hw/mlx5/main.c
$ git merge --abort
Merging rdma-leon-test/testing/rdma-next (a909d3e63699 Linux 4.9-rc3)
Merging mtd/master (445caaa20c4d mtd: Allocate bdi objects dynamically)
Merging l2-mtd/master (445caaa20c4d mtd: Allocate bdi objects dynamically)
Merging nand/nand/next (7ce7d89f4883 Linux 4.10-rc1)
Merging crypto/master (c821f6ab2e47 crypto: skcipher - introduce walksize attribute for SIMD algos)
Merging drm/drm-next (2cf026ae85c4 Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next)
Merging drm-panel/drm/panel/for-next (8c31f6034b24 drm/panel: simple: Add support for AUO G185HAN01)
Merging drm-intel/for-linux-next (1c74eeaf16b8 drm/i915: Move number of scalers initialization to runtime init)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_pm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_stolen.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_debugfs.c
Merging drm-tegra/drm/tegra/for-next (585ee0f27ef7 drm/tegra: Set sgt pointer in BO pin)
Merging drm-misc/for-linux-next (23c4cfbdab49 drm/edid: constify edid quirk list)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_pm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_overlay.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_vma.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_evict.c
Merging drm-exynos/exynos-drm/for-next (7d1e04231461 Merge tag 'usercopy-v4.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging drm-msm/msm-next (2401a0084614 drm/msm: gpu: Add support for the GPMU)
Merging hdlcd/for-upstream/hdlcd (747e5a5ff2a2 drm: hdlcd: Fix cleanup order)
Merging mali-dp/for-upstream/mali-dp (8e3eb71c80ad drm/arm/malidp: Fix possible dereference of NULL)
Merging sunxi/sunxi/for-next (63e8e44adfdc Merge branch 'sunxi/dt-late-for-4.10' into sunxi/for-next)
CONFLICT (content): Merge conflict in arch/arm/boot/dts/sun8i-h3.dtsi
Merging kspp/for-next/kspp (3545d3c27c43 gcc-plugins: update gcc-common.h for gcc-7)
Merging kconfig/for-next (5bcba792bb30 localmodconfig: Fix whitespace repeat count after "tristate")
Merging regmap/for-next (a5cb009162e6 Merge tag 'regmap-v4.10' into regmap-linus)
Merging sound/for-next (823ff161fe51 ALSA: hda - Fix click noises on Samsung Ativ Book 8)
Merging sound-asoc/for-next (e48ebfe726e4 Merge remote-tracking branches 'asoc/fix/arizona', 'asoc/fix/dwc', 'asoc/fix/hdmi-codec' and 'asoc/fix/topology' into asoc-linus)
Merging modules/modules-next (4d217a5adccf module: fix DEBUG_SET_MODULE_RONX typo)
Merging input/next (f63bb4f442d6 Input: bma150 - switch to using usleep_range instead of msleep)
Merging block/for-next (cdb98c2698b4 Revert "nvme: add support for the Write Zeroes command")
Merging lightnvm/for-next (a5f78b7f7dd1 Merge branch 'for-4.10/block' into for-next)
Merging device-mapper/for-next (ef548c551e72 dm flakey: introduce "error_writes" feature)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc/next (9bd22fc27d92 mmc: block: Replace "goto retry" by a proper do / while loop)
Merging kgdb/kgdb-next (7a6653fca500 kdb: Fix handling of kallsyms_symbol_next() return value)
Merging md/for-next (3ea77e712089 md/r5cache: assign conf->log before r5l_load_log())
Merging mfd/for-mfd-next (93559191e71b mfd: tps65217: Support an interrupt pin as the system wakeup)
Merging backlight/for-backlight-next (0c9501f823a4 backlight: pwm_bl: Handle gpio that can sleep)
Merging battery/for-next (6480af4915d6 power_supply: wm97xx_battery: use power_supply_get_drvdata)
Merging omap_dss2/for-next (c456a2f30de5 video: smscufx: remove unused variable)
Merging regulator/for-next (d00b74613fb1 Merge remote-tracking branches 'regulator/topic/tps65086' and 'regulator/topic/twl' into regulator-next)
Merging security/next (50523a29d900 Yama: allow access for the current ptrace parent)
Merging integrity/next (b4bfec7f4a86 security/integrity: Harden against malformed xattrs)
Merging keys/keys-next (ed51e44e914c Merge branch 'keys-asym-keyctl' into keys-next)
Merging selinux/next (36872bf3f5e3 selinux: default to security isid in sel_make_bools() if no sid is found)
Merging tpmdd/next (1548c540d863 tpm/vtpm: fix kdoc warnings)
Merging watchdog/master (7ce7d89f4883 Linux 4.10-rc1)
Merging iommu/next (1465f481460c Merge branches 'arm/mediatek', 'arm/smmu', 'x86/amd', 's390', 'core' and 'arm/exynos' into next)
Merging dwmw2-iommu/master (910170442944 iommu/vt-d: Fix PASID table allocation)
Merging vfio/next (2b8bb1d771f7 vfio iommu type1: Fix size argument to vfio_find_dma() in pin_pages/unpin_pages)
Merging trivial/for-next (74dcba3589fc NTB: correct ntb_spad_count comment typo)
Merging audit/next (89670affa2a6 audit: Make AUDIT_ANOM_ABEND event normalized)
Merging devicetree/for-next (c21d1fcd61bc Docs: dt: Be explicit and consistent in reference to IOMMU specifiers)
Merging mailbox/mailbox-for-next (db4d22c07e3e mailbox: mailbox-test: allow reserved areas in SRAM)
Merging spi/for-next (b6bdcd05b510 Merge remote-tracking branches 'spi/fix/armada', 'spi/fix/fsl-dspi' and 'spi/fix/sh-msiof' into spi-linus)
Merging tip/auto-latest (92f2ab52e19a Merge branch 'x86/cache')
Applying: scsi: disable the QEDI driver for now
Merging clockevents/clockevents/next (f947ee147e08 clocksource/drivers/arm_arch_timer: Map frame with of_io_request_and_map())
Merging edac/linux_next (9cae24b7b113 Merge commit 'daf34710a9e8849e04867d206692dc42d6d22263' into next)
CONFLICT (content): Merge conflict in drivers/edac/edac_pci.c
CONFLICT (content): Merge conflict in drivers/edac/edac_device.c
CONFLICT (content): Merge conflict in Documentation/00-INDEX
Merging edac-amd/for-next (0de2788447b6 EDAC, amd64: Fix improper return value)
Merging irqchip/irqchip/for-next (88e20c74ee02 irqchip/mxs: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND)
Merging ftrace/for-next (3dbb16b87b57 selftests: ftrace: Shift down default message verbosity)
Merging rcu/rcu/next (729e8988a855 rcutorture: Add CBMC-based formal verification for SRCU)
Merging kvm/linux-next (ef85b6738543 kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF))
Merging kvm-arm/next (21cbe3cc8a48 arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest)
Merging kvm-mips/next (07d9a380680d Linux 4.9-rc2)
Merging kvm-ppc/kvm-ppc-next (e34af7849014 KVM: PPC: Book3S: Move prototypes for KVM functions into kvm_ppc.h)
Merging kvms390/next (252747dd7c67 KVM: s390: Get rid of ar_t)
Merging xen-tip/linux-next (61033e089cde xen: remove stale xs_input_avail() from header)
Merging percpu/for-next (3ca45a46f8af percpu: ensure the requested alignment is power of two)
Merging workqueues/for-next (8bc4a0445596 Merge branch 'for-4.9' into for-4.10)
Merging drivers-x86/for-next (b6a64704c25e platform/x86: mlx-platform: mlxcpld-hotplug driver style fixes)
Merging chrome-platform/for-next (31b764171cb5 Revert "platform/chrome: chromeos_laptop: Add Leon Touch")
Merging hsi/for-next (7ac5d7b1a125 HSI: hsi_char.h: use __u32 from linux/types.h)
Merging leds/for-next (aec71e2fb6f7 DT: leds: Improve examples by adding some context)
Merging ipmi/for-next (070cbd1d42aa ipmi: create hardware-independent softdep for ipmi_devintf)
Merging driver-core/driver-core-next (0c744ea4f77d Linux 4.10-rc2)
Merging tty/tty-next (0c744ea4f77d Linux 4.10-rc2)
Merging usb/usb-next (0c744ea4f77d Linux 4.10-rc2)
Merging usb-gadget/next (d5c024f3761d usb: gadget: serial: fix possible Oops caused by calling kthread_stop(NULL))
Merging usb-serial/usb-next (0c744ea4f77d Linux 4.10-rc2)
Merging usb-chipidea-next/ci-for-usb-next (223e92311583 usb: chipdata: Replace the extcon API)
Merging phy-next/next (5e253dfbdbea phy: rockchip-inno-usb2: select USB_COMMON)
Merging staging/staging-next (0c744ea4f77d Linux 4.10-rc2)
Merging char-misc/char-misc-next (0c744ea4f77d Linux 4.10-rc2)
Merging extcon/extcon-next (3bd62888574a extcon: Move defintion of struct extcon_dev to driver/extcon directory)
Merging slave-dma/next (de34fb79b95b Merge branch 'topic/zx' into next)
Merging cgroup/for-next (7b4632f04841 cgroup: fix a comment typo)
Merging scsi/for-next (cadb39085066 Merge branch 'misc' into for-next)
Merging scsi-mkp/for-next (f1e65d125678 scsi: dpt_i2o: double free if adpt_i2o_online_hba() fails)
Merging target-updates/for-next (291e3e51a34d target: fix spelling mistake: "limitiation" -> "limitation")
Merging target-merge/for-next-merge (2994a7518317 cxgb4: update Kconfig and Makefile)
Merging target-bva/for-next (83337e544323 iscsi-target: Return error if unable to add network portal)
Merging libata/for-next (7ddf6a387c68 Merge branch 'for-4.10' into for-next)
Merging binfmt_misc/for-next (4af75df6a410 binfmt_misc: add F option description to documentation)
Merging vhost/linux-next (6bdf1e0efb04 Makefile: drop -D__CHECK_ENDIAN__ from cflags)
Merging rpmsg/for-next (a9cff670138e Merge branches 'hwspinlock-next', 'rpmsg-next' and 'rproc-next' into for-next)
Merging gpio/for-next (4fe4d09cfd11 Merge branch 'devel' into for-next)
Merging pinctrl/for-next (9eb63a89ffd1 Merge branch 'devel' into for-next)
Merging dma-mapping/dma-mapping-next (1001354ca341 Linux 4.9-rc1)
Merging pwm/for-next (fdd3ff4db177 Merge branch 'for-4.10/drivers' into for-next)
Merging dma-buf/for-next (194cad44c4e1 dma-buf/sync_file: improve Kconfig description for Sync Files)
CONFLICT (content): Merge conflict in drivers/dma-buf/Kconfig
Merging userns/for-next (19339c251607 Revert "evm: Translate user/group ids relative to s_user_ns when computing HMAC")
Merging ktest/for-next (2dcd0af568b0 Linux 4.6)
Merging random/dev (59b8d4f1f5d2 random: use for_each_online_node() to iterate over NUMA nodes)
Merging aio/master (b562e44f507e Linux 4.5)
Merging kselftest/next (7ce7d89f4883 Linux 4.10-rc1)
Merging y2038/y2038 (549eb7b22e24 AFS: Correctly use 64-bit time for UUID)
CONFLICT (content): Merge conflict in fs/afs/main.c
Merging luto-misc/next (2dcd0af568b0 Linux 4.6)
Merging borntraeger/linux-next (e76d21c40bd6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging livepatching/for-next (b766922e6535 powerpc/livepatch: Remove klp_write_module_reloc() stub)
Merging coresight/next (e615a9a8e481 coresight: perf: Add a missing call to etm_free_aux)
Merging rtc/rtc-next (7ce7d89f4883 Linux 4.10-rc1)
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (1db175428ee3 ext4: Simplify DAX fault path)
Merging dax-misc/dax-misc (4d9a2c874667 dax: Remove i_mmap_lock protection)
Merging akpm-current/current (e1f8c36b6eb3 ipc/sem: add hysteresis)
$ git checkout -b akpm remotes/origin/akpm/master
Applying: fs: add i_blocksize()
Applying: Reimplement IDR and IDA using the radix tree
Applying: idr: support storing NULL in the IDR
Applying: reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr-checkpatch-fixes
Applying: scripts/spelling.txt: add "swith" pattern and fix typo instances
Applying: scripts/spelling.txt: add "swithc" pattern and fix typo instances
Applying: scripts/spelling.txt: add "an user" pattern and fix typo instances
Applying: scripts/spelling.txt: add "an union" pattern and fix typo instances
Applying: scripts/spelling.txt: add "an one" pattern and fix typo instances
Applying: scripts/spelling.txt: add "partiton" pattern and fix typo instances
Applying: scripts/spelling.txt: add "aligment" pattern and fix typo instances
Applying: scripts/spelling.txt: add "algined" pattern and fix typo instances
Applying: scripts/spelling.txt: add "efective" pattern and fix typo instances
Applying: scripts/spelling.txt: add "varible" pattern and fix typo instances
Applying: scripts/spelling.txt: add "embeded" pattern and fix typo instances
Applying: scripts/spelling.txt: add "againt" pattern and fix typo instances
Applying: scripts/spelling.txt: add "neded" pattern and fix typo instances
Applying: scripts/spelling.txt: add "unneded" pattern and fix typo instances
Applying: scripts/spelling.txt: add "intialization" pattern and fix typo instances
Applying: scripts/spelling.txt: add "initialiazation" pattern and fix typo instances
Applying: scripts/spelling.txt: add "intialise(d)" pattern and fix typo instances
Applying: scripts/spelling.txt: add "comsume(r)" pattern and fix typo instances
Applying: scripts/spelling.txt: add "disble(d)" pattern and fix typo instances
Applying: scripts/spelling.txt: add "overide" pattern and fix typo instances
Applying: scripts/spelling.txt: add "overrided" pattern and fix typo instances
Applying: scripts/spelling.txt: add "configuartion" pattern and fix typo instances
Applying: scripts/spelling.txt: add "applys" pattern and fix typo instances
Applying: scripts/spelling.txt: add "explictely" pattern and fix typo instances
Applying: scripts/spelling.txt: add "omited" pattern and fix typo instances
Applying: scripts/spelling.txt: add "disassocation" pattern and fix typo instances
Applying: scripts/spelling.txt: add "deintialize(d)" pattern and fix typo instances
Applying: scripts/spelling.txt: add "overwritting" pattern and fix typo instances
Applying: scripts/spelling.txt: add "overwriten" pattern and fix typo instances
Applying: scripts/spelling.txt: add "therfore" pattern and fix typo instances
Applying: scripts/spelling.txt: add "followings" pattern and fix typo instances
Merging akpm/master (f591e9a3e727 scripts/spelling.txt: add "followings" pattern and fix typo instances)
^ permalink raw reply
* Re: linux-next: build failure after merge of the drm-intel-fixes tree
From: Alex Williamson @ 2017-01-03 4:48 UTC (permalink / raw)
To: Zhenyu Wang
Cc: Stephen Rothwell, Daniel Vetter, Intel Graphics, DRI, linux-next,
linux-kernel, Jike Song
In-Reply-To: <20170103025929.35gp5n27uc7iszra@zhen-hp.sh.intel.com>
On Tue, 3 Jan 2017 10:59:29 +0800
Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> On 2017.01.03 10:42:39 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'intel_vgpu_open':
> > drivers/gpu/drm/i915/gvt/kvmgt.c:511:32: error: dereferencing pointer to incomplete type 'struct mdev_device'
> > vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> > ^
> >
> > Caused by commit
> >
> > 99e3123e3d72 ("vfio-mdev: Make mdev_device private and abstract interfaces")
> >
> > from the vfio-fixes tree interacting with commit
> >
> > 364fb6b789ff ("drm/i915/gvt/kvmgt: prevent double-release of vgpu")
> >
> > from the drm-intel-fixes tree.
>
> Alex, I liked to have kvmgt related mdev interface change be merged through
> vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> below fix in your tree? I think in general for possible interface change in
> future we still need a pull request for i915 to resolve dependence earlier.
Hi Zhenyu,
Hopefully this abstraction will help to isolate vendor drivers from
mdev API changes in the future. I can certainly roll this patch into
the original to maintain bisectability. I want to get these changes in
for rc3, will a pull request for the i915 changes be sent this week?
Thanks for spotting and fixing this, Stephen. Thanks,
Alex
> > I applied this merge fix patch:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 3 Jan 2017 10:38:48 +1100
> > Subject: [PATCH] vfio-mdev: fixup for "Make mdev_device private and abstract interfaces"
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index c24b665e007b..faaae07ae487 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@ -508,7 +508,7 @@ static int intel_vgpu_open(struct mdev_device *mdev)
> > return ret;
> >
> > undo_group:
> > - vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> > + vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
> > &vgpu->vdev.group_notifier);
> >
> > undo_iommu:
> > --
> > 2.10.2
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
^ permalink raw reply
* linux-next: build warning after merge of the pinctrl tree
From: Stephen Rothwell @ 2017-01-03 4:37 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-next, linux-kernel, Nehal Shah
Hi Linus,
After merging the pinctrl tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show':
drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized]
for (; i < pin_num; i++) {
^
drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
unsigned int bank, i, pin_num;
^
Introduced by commit
3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox