Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 12:49:35PM +0200, Wouter Verhelst wrote: > A while back, we spent quite some time defining the semantics of the > various commands in the face of the NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA > write barriers. At the time, we decided that it would be unreasonable > to expect

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 02:26:31PM +0200, Wouter Verhelst wrote: > Yes. I think the kernel nbd driver should probably filter out FUA on > READ. It has no meaning in the case of nbd, and whatever expectations > the kernel may have cannot be provided for by nbd anyway. The kernel never sets FUA on

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

> On 15 Sep 2016, at 13:18, Christoph Hellwig wrote: > > Yes, please do that. A "barrier" implies draining of the queue. Done -- Alex Bligh

I hope this email meets you well in good health condition

How you doing today? I hope you are doing well. My name is Jones, from the US. I'm in Syria right now fighting ISIS. I want to get to know you better, if I may be so bold. I consider myself an easy-going man, and I am currently looking for a relationship in which I feel loved. Please tell me

[PATCH v6 0/2] add support for Allwinner SoCs ADC

The Allwinner SoCs all have an ADC that can also act as a touchscreen controller and a thermal sensor. The first four channels can be used either for the ADC or the touchscreen and the fifth channel is used for the thermal sensor. We currently have a driver for the two latter functions in

[PATCH v6 1/2] mfd: add support for Allwinner SoCs ADC

The Allwinner SoCs all have an ADC that can also act as a touchscreen controller and a thermal sensor. For now, only the ADC and the thermal sensor drivers are probed by the MFD, the touchscreen controller support will be added later. Signed-off-by: Quentin Schulz

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

> On 15 Sep 2016, at 13:41, Christoph Hellwig wrote: > > On Thu, Sep 15, 2016 at 01:39:11PM +0100, Alex Bligh wrote: >> That's probably right in the case of file-based back ends that >> are running on a Linux OS. But gonbdserver for instance supports >> (e.g.) Ceph based

Re: [PATCH 0/7] mfd: Fix all W=1 warnings

On Thu, Sep 15, 2016 at 12:45 PM, Lee Jones wrote: > It really is as simple as it sounds! > > Lee Jones (7): > mfd: max8997-irq: 'inline' should be at the beginning of the > declaration > mfd: ab8500-debugfs: Prevent initialised field from being over-written >

Re: [patch] leds: add driver for Mellanox systems leds

Hi! > +++ b/MAINTAINERS > @@ -7655,6 +7655,14 @@ W: http://www.mellanox.com > Q: http://patchwork.ozlabs.org/project/netdev/list/ > F: drivers/net/ethernet/mellanox/mlxsw/ > > +MELLANOX MLXCPLD LED DRIVER > +M: Vadim Pasternak > +L: linux-l...@vger.kernel.org

Re: [PATCH v2] leds: Introduce userspace leds driver

Hi! > >@@ -0,0 +1,23 @@ > >+/* > >+ * Userspace driver support for leds subsystem > >+ * > >+ * This program is free software; you can redistribute it and/or modify > >+ * it under the terms of the GNU General Public License as published by > >+ * the Free Software Foundation; either version 2 of

Re: [patch 11/32] greybus: camera driver

Hi Greg, Thank you for the patch. On Thursday 15 Sep 2016 14:23:51 Greg Kroah-Hartman wrote: > This driver implements the Greybus camera protocol. > > Signed-off-by: Greg Kroah-Hartman > --- > drivers/greybus/camera.c| 1400

[GIT PULL] tpmdd updates for Linux 4.9

Hi James, This pull request contains tpmdd updates for Linux 4.9. There are no major new features. This is purely a bug fix and cleanup release. /Jarkko The following changes since commit a39f44faa8c7d84dff7d1fc0bc851c6499f94d7b: Merge branch 'smack-for-4.9' of

Re: [PATCH v2] PM / Domains: Allow holes in genpd_data.domains array

On 15/09/16 13:05, Tomeu Vizoso wrote: > In platforms such as Rockchip's, the array of domains isn't always > filled without holes, as which domains are present depend on the > particular SoC revision. > > By allowing holes to be in the array, such SoCs can still use a single > set of constants

Re: [PATCH] of/platform: Initialise dev->fwnode appropriately

On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote: > Whilst we're some of the way towards a universal firmware property > interface, drivers which deal with both OF and ACPI probing end up > having to do things like this: > > dev->of_node ? >of_node->fwnode : dev->fwnode > > This

[PATCH] mwifiex: fix null pointer deference when adapter is null

From: Colin Ian King If adapter is null the error exit path in mwifiex_shutdown_sw is to down the semaphore sem and print some debug via mwifiex_dbg. However, passing a NULL adapter to mwifiex_dbg causes a null pointer deference when accessing adapter->dev. This fix

Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

On Thu, Sep 15, 2016 at 3:18 PM, Vladimir Zapolskiy wrote: >> No response from author, so betting on it and reverting this in isolation >> with your Reported-by. >> > > please revert the revert :) Sure I hadn't pushed it yet anyway. Yours, Linus Walleij

Re: [PATCH] lockdep: Quiet gcc about dangerous __builtin_return_address() operations

Peter, Can you pull this patch in? It probably should go to stable as well. -- Steve On Thu, 8 Sep 2016 20:33:13 +0200 Borislav Petkov wrote: > On Thu, Sep 08, 2016 at 12:34:33PM -0400, Steven Rostedt wrote: > > [ > > Boris, does this quiet gcc for you? > > I haven't

Re: [PATCH] [SCSI] wd719x: Avoid calling request_firmware under spinlock

On 15/09/2016 14:48, Vaishali Thakkar wrote: It is preferrable to use request_firmware where sleeping is allowed. Using it under spinlock can cause blocking. Here, the function wd719x_chip_init calls request_firmware while holding a spinlock. So, let's access it outside the spinlock. Coccinelle

Re: [PATCHv3 29/41] ext4: make ext4_mpage_readpages() hugepage-aware

On Sep 15, 2016, at 5:55 AM, Kirill A. Shutemov wrote: > > This patch modifies ext4_mpage_readpages() to deal with huge pages. > > We read out 2M at once, so we have to alloc (HPAGE_PMD_NR * > blocks_per_page) sector_t for that. I'm not entirely happy with

Re: [PATCH 2/2] mfd: wm8994-core: Don't use managed regulator bulk get API

On Thu, Sep 15, 2016 at 04:47:01PM +0530, Viresh Kumar wrote: > The kernel WARNs and then crashes today if wm8994_device_init() fails > after calling devm_regulator_bulk_get(). > > That happens because there are multiple devices involved here and the > order in which resources are freed isn't

Re: [RESEND PATCH] arm64: kgdb: fix single stepping

On 09/15/2016 05:41 AM, Daniel Thompson wrote: On 15/09/16 08:56, AKASHI Takahiro wrote: On Wed, Sep 14, 2016 at 03:58:51PM +0100, Will Deacon wrote: Hi Akashi, On Tue, Apr 21, 2015 at 02:13:13AM +0100, AKASHI Takahiro wrote: Could you please review my patch below? See also arm64

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

> On 15 Sep 2016, at 13:23, Christoph Hellwig wrote: > > On Thu, Sep 15, 2016 at 02:21:20PM +0200, Wouter Verhelst wrote: >> Right. So do I understand you correctly that blk-mq currently doesn't >> look at multiple queues, and just assumes that if a FLUSH is sent over >> any

Re: [PATCH 13/19] pinctrl: st: Remove STiH415/6 SoC pinctrl driver support.

On Wed, Sep 14, 2016 at 3:27 PM, Peter Griffin wrote: > STiH415/6 SoC support is being removed from the kernel. > This patch updates the ST pinctrl driver and removes > references to these obsolete platforms. As some structures > referenced by STiH407 based

Re: [PATCH] scsi: replace broken specification URL

Hi Martin, On 14/09/2016 19:00, Martin K. Petersen wrote: Michael> So, should we only that the cam-r12b document can be found from Michael> http://www.t10.org/t10docs.htm (registration required)?, and Michael> tell that a copy can be found on Michael>

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 01:39:11PM +0100, Alex Bligh wrote: > That's probably right in the case of file-based back ends that > are running on a Linux OS. But gonbdserver for instance supports > (e.g.) Ceph based backends, where each connection might be talking > to a completely separate ceph node,

Re: [PATCH] leds: Introduce userspace leds driver

Hi! > Thanks for the patch. It is very nice. I have only one minor remark > in the code. > > I think that it would be good to add a documentation for this > driver to Documentation/leds, with exemplary C program instead > of python one. The program could poll the dev node in a loop, > which

Re: lockdep: incorrect deadlock warning with two GPIO expanders

On Thu, Sep 15, 2016 at 9:51 AM, Peter Zijlstra wrote: > On Tue, Sep 13, 2016 at 02:29:24PM +0200, Linus Walleij wrote: >> On Mon, Sep 12, 2016 at 5:33 PM, Peter Zijlstra wrote: >> > On Mon, Sep 12, 2016 at 05:16:14PM +0200, Bartosz Golaszewski wrote:

Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe

On Wed, Sep 14, 2016 at 5:12 PM, Mika Westerberg wrote: > On Wed, Sep 14, 2016 at 02:46:01PM +0200, Linus Walleij wrote: >> > I'm going to re-read the hardware spec and see if there is anything we >> > can do about this. The newer hardware (Skylake, Broxton) has a

Re: [PATCH v2 0/8] Support Intel® Turbo Boost Max Technology 3.0

On Thu, 15 Sep 2016 14:14:30 +0200 Pavel Machek wrote: > Hi! > > > - Feature is enabled by default for single socket systems > > > > With Intel® Turbo Boost Max Technology 3.0 (ITMT), single-threaded > > performance is > > optimized by identifying processor's fastest core and

Re: [PATCH 4/7 v3] sched: propagate load during synchronous attach/detach

On 12/09/16 08:47, Vincent Guittot wrote: > When a task moves from/to a cfs_rq, we set a flag which is then used to > propagate the change at parent level (sched_entity and cfs_rq) during > next update. If the cfs_rq is throttled, the flag will stay pending until > the cfs_rw is unthrottled. > >

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

On 09/15/2016 03:19 PM, Andrey Utkin wrote: > On Thu, Sep 15, 2016 at 03:15:53PM +0200, Hans Verkuil wrote: >> It could be related to the fact that a PCI write may be delayed unless >> it is followed by a read (see also the comments in >> drivers/media/pci/ivtv/ivtv-driver.h). > > Thanks for

Re: lockdep: incorrect deadlock warning with two GPIO expanders

On Thu, Sep 15, 2016 at 03:20:58PM +0200, Bartosz Golaszewski wrote: > 2016-09-15 14:41 GMT+02:00 Linus Walleij : > >> So can't you walk up that and see if you encounter the exact same driver > >> again? > >> > >> Something like: > >> > >> for (nr = 0, parent =

Re: [PATCH v2 1/2] iio: Implement counter channel type and info constants

Hi William, [auto build test ERROR on iio/togreg] [also build test ERROR on v4.8-rc6 next-20160915] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

Hi Linus, On 09/15/2016 04:18 PM, Vladimir Zapolskiy wrote: Hi Linus, On 09/15/2016 03:19 PM, Linus Walleij wrote: On Wed, Sep 14, 2016 at 4:33 PM, Guenter Roeck wrote: On 09/14/2016 12:19 AM, Linus Walleij wrote: On Wed, Sep 14, 2016 at 5:20 AM, Guenter Roeck

Re: [PATCH] drm/amdgpu: clean function declarations in amdgpu_ttm.c up

Am 15.09.2016 um 15:43 schrieb Baoyou Xie: We get 2 warnings when building kernel with W=1: drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:985:5: warning: no previous prototype for 'amdgpu_ttm_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1092:6: warning: no previous prototype

[RFC PATCH 0/8] arm64: move thread_info off of the task stack

Building atop of Andy's work on x86 and generic code, these patches move arm64's thread_info off of the stack and into task_struct. This protects thread_info from corruption in the face of stack overflow, and serves as a step towards fully robust stack overflow handling will be addressed by

[RFC PATCH 2/8] thread_info: allow custom in-task thread_info

Currently, task_struct is defined in , which (indirectly) pulls in a number of low-level arch headers such as through a number of other headers. Thus, code and structures in these headers can't rely on the definition of task_struct. Some of these headers are necessary for the definition of

[RFC PATCH 5/8] arm64: assembler: introduce ldr_this_cpu

Shortly we will want to load a percpu variable in the return from userspace path. We can save an instruction by folding the addition of the percpu offset into the load instruction, and this patch adds a new helper to do so. At the same time, we clean up this_cpu_ptr for consistency. As with

[RFC PATCH 8/8] arm64: split thread_info from task stack

This patch moves arm64's struct thread_info from the task stack into task_struct. This protects thread_info from corruption in the case of stack overflows, and makes its address harder to determine if stack addresses are leaked, making a number of attacks more difficult. Precise detection and

[RFC PATCH 3/8] arm64: thread_info remove stale items

We have a comment claiming __switch_to() cares about where cpu_context is located relative to cpu_domain in thread_info. However arm64 has never had a thread_info::cpu_domain field, and neither __switch_to nor cpu_switch_to care where the cpu_context field is relative to others. Additionally, the

[RFC PATCH 1/8] thread_info: include for THREAD_INFO_IN_TASK

When CONFIG_THREAD_INFO_IN_TASK is selected, the current_thread_info() macro relies on current having been defined prior to its use. However, not all users of current_thread_info() include , and thus current is not guaranteed to be defined. When CONFIG_THREAD_INFO_IN_TASK is not selected, it's

Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq

On Thu, Sep 15, 2016 at 01:58:15PM +0200, Richard Cochran wrote: > Can the input clock be higher than 1 GHz? If not, I suggest using > clocks_calc_mult_shift() with maxsec=4 and a setting the watchdog also > to 4*HZ. On second thought, with the new 12% timer batching, using 4*HZ for 32 bits of 1

Re: [PATCH] mwifiex: fix null pointer deference when adapter is null

Hi All, On Thu, Sep 15, 2016 at 11:42 PM, Colin King wrote: > From: Colin Ian King > > If adapter is null the error exit path in mwifiex_shutdown_sw is > to down the semaphore sem and print some debug via mwifiex_dbg. > However, passing a NULL

Re: [PATCH] scsi: replace broken specification URL

> "Michael" == Michael Opdenacker > writes: Michael> + * 'cam-r12b.pdf' document on http://www.t10.org/t10docs.htm Michael> + * (registration required) That link really should be http://www.t10.org/drafts.htm. You can't look up draft

Re: [GIT PULL v2] phy: for 4.9

On Thu, Sep 15, 2016 at 06:26:18PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the updated PHY pull request for 4.9 based on usb-next. This > now fixes the merge conflicts caused because of extcon branch merged > into linux-phy. > > Please find the detailed list of changes in

Re: [PATCH 0/8] drm/rockchip: Flip wait clean-up

On Wed, Sep 14, 2016 at 8:54 AM, Tomasz Figa wrote: > The display controller found on Rockchip SoCs supported by Rockchip DRM > driver (VOP) is a bit problematic, because it does not provide hardware > vblank counter. Because vblank interrupt is used to feed the software >

Re: [PATCH 1/2] mfd: wm8994-core: disable regulators before removing them

On Thu, Sep 15, 2016 at 04:47:00PM +0530, Viresh Kumar wrote: > The order in which resources were freed in wm8994_device_exit() isn't > correct. The regulators are removed before they are disabled. > > Fix it by reordering code a bit, which makes it exact opposite of > wm8994_device_init() as

Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1

On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote: > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote: > > For example, you have absolutely no guarantee as to what backs > > get_cycles(). Despite this, the code assumes that get_cycles() is > > backed by something running at the

Re: perf: perf_fuzzer lockup in perf_cgroup_attach

On Wed, 14 Sep 2016, Stephane Eranian wrote: > I would think there is a way to disable KASLR for this kind of testing! yes, it's just I hadn't realized I had it enabled until I couldn't figure out why addr2line wasn't working. > Which of your fuzzer scripts are you using? fast_repro99.sh?

Important message

You have reached your mailbox folder's limit. Please remodify by clicking on the link below otherwise you will be blocked from sending and receiving email. http://auth-websupport.tk System Admin

Re: [GIT PULL] STi DT update for v4.9

On 09/14/2016 03:15 PM, Patrice Chotard wrote: > Hi Arnd, Kevin, Olof > > PLease consider this next batch for v4.9 > > The following changes since commit ba5ba11906d5462993f5fd4e3da4d234505427a0: > > ARM: dts: STiH41x-b2020: Update gpio specifier (2016-09-02 15:15:14 +0200) > > are

Re: [PATCH 4/7 v3] sched: propagate load during synchronous attach/detach

On 15 September 2016 at 14:55, Peter Zijlstra wrote: > On Mon, Sep 12, 2016 at 09:47:49AM +0200, Vincent Guittot wrote: > +/* Take into account change of utilization of a child task group */ >> +static inline void >> +update_tg_cfs_util(struct cfs_rq *cfs_rq, struct

[PATCH] scsi: replace broken specification URL

The t10.org website containing SCSI-2 draft specifications now requires to be from a member company to access the documents. Signed-off-by: Michael Opdenacker --- Documentation/DocBook/scsi.tmpl | 6 +++--- drivers/scsi/scsicam.c | 3 ++- 2 files

Re: [PATCH v3] leds: Introduce userspace leds driver

Hi! > >+if (copy_from_user(>user_dev, buffer, > >+ sizeof(struct uleds_user_dev))) { > >+ret = -EFAULT; > >+goto out; > >+} > >+ > >+if (!udev->user_dev.name[0]) { > >+ret = -EINVAL; > >+goto out; > >+} > >+ >

RE: [PATCH v3 1/4] tpm/tpm_crb: implement tpm crb idle state

> On Thu, Sep 15, 2016 at 08:23:03AM +, Winkler, Tomas wrote: > > > > > Subject: Re: [PATCH v3 1/4] tpm/tpm_crb: implement tpm crb idle > > > > > state > > > > > > > > > > On Mon, Sep 12, 2016 at 04:04:18PM +0300, Tomas Winkler wrote: > > > > > > The register TPM_CRB_CTRL_REQ_x contains bits

Re: [PATCH 4/7 v3] sched: propagate load during synchronous attach/detach

On 15 September 2016 at 14:59, Peter Zijlstra wrote: > On Mon, Sep 12, 2016 at 09:47:49AM +0200, Vincent Guittot wrote: >> + /* If the load of group cfs_rq is null, the load of the >> + * sched_entity will also be null so we can skip the formula >> + */ > >

Re: [PATCH 3/7 v3] sched: factorize PELT update

On Mon, Sep 12, 2016 at 09:47:48AM +0200, Vincent Guittot wrote: > @@ -3690,7 +3658,7 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity > *curr, int queued) > /* >* Ensure that runnable average is periodically updated. >*/ > - update_load_avg(curr, 1); > +

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

It could be related to the fact that a PCI write may be delayed unless it is followed by a read (see also the comments in drivers/media/pci/ivtv/ivtv-driver.h). That was probably the reason for the pci_read_config_word in the reg_write code. Try putting that back (and just that). Regards,

Re: lockdep: incorrect deadlock warning with two GPIO expanders

2016-09-15 14:41 GMT+02:00 Linus Walleij : > On Thu, Sep 15, 2016 at 9:51 AM, Peter Zijlstra wrote: >> On Tue, Sep 13, 2016 at 02:29:24PM +0200, Linus Walleij wrote: >>> On Mon, Sep 12, 2016 at 5:33 PM, Peter Zijlstra >>>

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

On Thu, Sep 15, 2016 at 03:15:53PM +0200, Hans Verkuil wrote: > It could be related to the fact that a PCI write may be delayed unless > it is followed by a read (see also the comments in > drivers/media/pci/ivtv/ivtv-driver.h). Thanks for explanation! > That was probably the reason for the

[PATCH 3/3] perf/x86/intel/pt: Do validate the size of a kernel address filter

Right now, the kernel address filters in PT are prone to integer overflow that may happen in adding filter's size to its offset to obtain the end of the range. Such an overflow would also throw a #GP in the PT event configuration path. Fix this by explicitly validating the result of this

[PATCH 2/3] perf/x86: Tighten up the kernel_ip() check

The kernel_ip() filter is used mostly by the DS/LBR code to look at the branch addresses, but Intel PT also uses it to validate the address filter offsets for kernel addresses, for which it is not sufficient: supplying something in bits 64:48 that's not a sign extension of the lower address bits

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On 09/15/2016 09:17 AM, Wouter Verhelst wrote: On Thu, Sep 15, 2016 at 01:44:29PM +0100, Alex Bligh wrote: On 15 Sep 2016, at 13:41, Christoph Hellwig wrote: On Thu, Sep 15, 2016 at 01:39:11PM +0100, Alex Bligh wrote: That's probably right in the case of file-based back

Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support

On 15 September 2016 at 15:49, Ulf Hansson wrote: > On 15 September 2016 at 09:59, Pramod Gurav wrote: >> On 9 September 2016 at 15:48, Georgi Djakov wrote: >>> On 09/08/2016 11:02 AM, Adrian Hunter wrote: On

Re: [RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device

Hi Marc, Thanks for your review, reply inline. On 09/14/2016 11:45 PM, Marc Zyngier wrote: On 14/09/16 15:21, Hanjun Guo wrote: From: Hanjun Guo With the platform msi domain created, we can set up the msi domain for a platform device when it's probed. This patch

Re: [PATCH 2/3] perf/x86: Tighten up the kernel_ip() check

On Thu, Sep 15, 2016 at 04:29:43PM +0300, Alexander Shishkin wrote: > The kernel_ip() filter is used mostly by the DS/LBR code to look at the > branch addresses, but Intel PT also uses it to validate the address > filter offsets for kernel addresses, for which it is not sufficient: > supplying

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On 15/09/2016 15:34, Eric Blake wrote: > On 09/15/2016 06:09 AM, Alex Bligh wrote: >> >> I also wonder whether any servers that can do caching per >> connection will always share a consistent cache between >> connections. The one I'm worried about in particular here >> is qemu-nbd - Eric Blake

Re: [PATCH] lockdep: Quiet gcc about dangerous __builtin_return_address() operations

On Thu, Sep 15, 2016 at 09:54:50AM -0400, Steven Rostedt wrote: > > Peter, > > Can you pull this patch in? It probably should go to stable as well. I'm not sure how this relates to lockdep, which is why I mostly ignored the patch.

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni wrote: > > -Original Message- > > On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele Paoloni wrote: > > > > > > From <<3.1.1. Open Firmware Properties for Bus Nodes>> in > > >

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 01:33:20PM +0100, Alex Bligh wrote: > At an implementation level that is going to be a little difficult > for some NBD servers, e.g. ones that fork() a different process per > connection. There is in general no IPC to speak of between server > instances. Such servers would

[GIT PULL v2] phy: for 4.9

Hi Greg, Please find the updated PHY pull request for 4.9 based on usb-next. This now fixes the merge conflicts caused because of extcon branch merged into linux-phy. Please find the detailed list of changes in the tag message. Let me know if you want me to change something. Thanks Kishon The

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: > On 9 September 2016 at 13:05, Greg KH wrote: > > On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: > >> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: > >> > From: Rafał Miłecki

Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

Hi Linus, On 09/15/2016 03:19 PM, Linus Walleij wrote: On Wed, Sep 14, 2016 at 4:33 PM, Guenter Roeck wrote: On 09/14/2016 12:19 AM, Linus Walleij wrote: On Wed, Sep 14, 2016 at 5:20 AM, Guenter Roeck wrote: So, in other words, lots of bugs here.

Re: [PATCH] documentation: fix broken lkml archive links in RCU requirements

On Thu, 15 Sep 2016 14:17:06 +0200 Michael Opdenacker wrote: > Fix 4 LKML archive links that became broken > (issue with https://lkml.kernel.org/g/ redirection links) > > Signed-off-by: Michael Opdenacker > --- >

Re: [PATCH] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

On Tue, Sep 06, 2016 at 02:56:39PM +0200, Neil Armstrong wrote: > Since the I2C sx150x GPIO expander driver uses platform_data to manage > the pins configurations, rewrite the driver as a pinctrl driver using > pinconf to get/set pin configurations from DT or debugfs. > > The pinctrl driver is

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 05:20:08AM -0700, Christoph Hellwig wrote: > On Thu, Sep 15, 2016 at 02:01:59PM +0200, Wouter Verhelst wrote: > > Yes. There was some discussion on that part, and we decided that setting > > the flag doesn't hurt, but the spec also clarifies that using it on READ > > does

Re: Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

On Mon 2016-09-05 00:20:06, Sven Joachim wrote: > Recently I got myself a new laptop with the following integrated GPU: > > 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Mullins [Radeon R3 Graphics] (rev 40) > > I found that hibernation is broken in Linux 4.7+ (it

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

> On 15 Sep 2016, at 13:36, Christoph Hellwig wrote: > > On Thu, Sep 15, 2016 at 01:33:20PM +0100, Alex Bligh wrote: >> At an implementation level that is going to be a little difficult >> for some NBD servers, e.g. ones that fork() a different process per >> connection.

[PATCH v6 2/2] iio: adc: add support for Allwinner SoCs ADC

The Allwinner SoCs all have an ADC that can also act as a touchscreen controller and a thermal sensor. This patch adds the ADC driver which is based on the MFD for the same SoCs ADC. This also registers the thermal adc channel in the iio map array so iio_hwmon could use it without modifying the

Re: [PATCH 4/7 v3] sched: propagate load during synchronous attach/detach

On Mon, Sep 12, 2016 at 09:47:49AM +0200, Vincent Guittot wrote: +/* Take into account change of utilization of a child task group */ > +static inline void > +update_tg_cfs_util(struct cfs_rq *cfs_rq, struct sched_entity *se) > +{ > + struct cfs_rq *gcfs_rq = group_cfs_rq(se); > + long

Re: [RESEND PATCH] arm64: kgdb: fix single stepping

On 04/20/2015 08:13 PM, AKASHI Takahiro wrote: Jason, Could you please review my patch below? See also arm64 maintainer's comment: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.html Thanks, -Takahiro AKASHI I tried to verify kgdb in vanilla kernel on fast model,

[PATCH 0/3] perf/x86/intel/pt: Address filtering fixes for perf/urgent

Hi, Hoping that it's not too late, here are fixes for issues that Adrian found. All three are good for -stable afaict. Two of the bugs result in a #GP and one in a misconfigured filter. 2/3 can be moved into the PT driver as well, but I decided that others may benefit from it at least

[PATCH 1/3] perf/x86/intel/pt: Fix an off-by-one in address filter configuration

PT address filter configuration requires that a range is specified by its first and last address, but at the moment we're obtaining the end of the range by adding user specified size to its start, which is off by one from what it actually needs to be. Fix this and make sure that zero-sized

Re: [PATCH 3/7 v3] sched: factorize PELT update

On 15 September 2016 at 15:09, Peter Zijlstra wrote: > On Mon, Sep 12, 2016 at 09:47:48AM +0200, Vincent Guittot wrote: >> @@ -3690,7 +3658,7 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity >> *curr, int queued) >> /* >>* Ensure that runnable average

Re: [PATCH v2 1/2] of: Make of_find_property_value_of_size take a length range

On Mon, Sep 12, 2016 at 02:01:28PM +0100, Richard Fitzgerald wrote: > In preparation for adding variable-length array reads, change > of_find_property_value_of_size so that it takes an optional > maximum length. If the maximum is passed as 0, the behaviour is > unchanged and it will return a

Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

Hi Guenter, On 09/14/2016 06:20 AM, Guenter Roeck wrote: Hi Vladimir, your commit e188cbf7564f ("gpio: mxc: shift gpio_mxc_init() to subsys_initcall level") in -next causes the following crash when running the 'kzm' target (and most likely the real thing) with qemu. [1.211426] Unable to

[PATCH] dmaengine: virt-dma: adjust function declarations in the virt-dma.h

We get 2 warnings when building kernel with W=1: drivers/dma/virt-dma.c:22:14: warning: no previous prototype for 'vchan_tx_submit' [-Wmissing-prototypes] drivers/dma/virt-dma.c:52:5: warning: no previous prototype for 'vchan_tx_desc_free' [-Wmissing-prototypes] In fact, both functions are

Re: [PATCH v3] leds: Introduce userspace leds driver

Hi! > > >+ if (copy_from_user(>user_dev, buffer, > > >+ sizeof(struct uleds_user_dev))) { > > >+ ret = -EFAULT; > > >+ goto out; > > >+ } > > >+ > > >+ if (!udev->user_dev.name[0]) { > > >+ ret = -EINVAL; > > >+ goto out; > > >+ } > > >+

Re: [PATCH v2 4/5] drm/qxl: squash lines for simple wrapper functions

2016-09-14 Masahiro Yamada : > Remove unneeded variables and assignments. > > Signed-off-by: Masahiro Yamada > --- > > drivers/gpu/drm/qxl/qxl_draw.c| 7 ++- > drivers/gpu/drm/qxl/qxl_release.c | 7 ++- > 2 files

Re: linux-next: manual merge of the amlogic tree with the pinctrl tree

On Thu, Sep 15, 2016 at 2:19 AM, Stephen Rothwell wrote: > 23b4ed268076 ("driver: base: pinctrl: return error from > pinctrl_bind_pins()") > > from the pinctrl tree and commit: > > eb4ec68acf5e ("driver: base: pinctrl: return error from > pinctrl_bind_pins()") > >

Re: [PATCH] pintctrl: amlogic: gxbb: add i2c pins

On Wed, Sep 14, 2016 at 11:45 AM, Jerome Brunet wrote: > Add EE domains pins for the i2c devices A,B,C > > Signed-off-by: Jerome Brunet Patch applied with Kevin's ACK. Yours, Linus Walleij

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 05:01:25AM -0700, Christoph Hellwig wrote: > On Thu, Sep 15, 2016 at 01:55:14PM +0200, Wouter Verhelst wrote: > > If that's not a write barrier, then I was using the wrong terminology > > (and offer my apologies for the confusion). > > It's not a write barrier - a write

Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements

On Thu, Sep 15, 2016 at 02:21:20PM +0200, Wouter Verhelst wrote: > Right. So do I understand you correctly that blk-mq currently doesn't > look at multiple queues, and just assumes that if a FLUSH is sent over > any one of the queues, it applies to all queues? Yes. The same is true at the

[REGRESSION] BISECTED : ethernet gadget not working anymore on several atmel platforms

Since: commit c32b5bcfa3c43a3c9bb59f65b5e76adb7384c4c8 Author: Alexandre Belloni Date: Tue Jul 12 22:45:59 2016 +0200 ARM: dts: at91: Fix USB endpoint nodes Endpoint nodes have a reg property. Add their mandatory unit-address. Booting with an USB

Re: [PATCH v2 4/5] drm/qxl: squash lines for simple wrapper functions

Hi Masahiro, 2016-09-14 Masahiro Yamada : > Remove unneeded variables and assignments. > > Signed-off-by: Masahiro Yamada > --- > > drivers/gpu/drm/qxl/qxl_draw.c| 7 ++- > drivers/gpu/drm/qxl/qxl_release.c | 7 ++- >

Re: [PATCH 14/19] pinctrl: st: Remove obsolete platforms from pinctrl-st dt doc

On Wed, Sep 14, 2016 at 3:27 PM, Peter Griffin wrote: > STiH415/6 SoC support is being removed from the kernel. > This patch updates the ST pinctrl dt doc and removes > references to these obsolete platforms. It also updates > the dt example to the currently supported

Re: perf: perf_fuzzer lockup in perf_cgroup_attach

On Thu, 15 Sep 2016, Peter Zijlstra wrote: > On Wed, Sep 14, 2016 at 10:43:29PM -0400, Vince Weaver wrote: > > > > so the skylake that was fuzzing finally is mostly locked up. > > > > Really hard to tell what's going, especially as KASLR made looking up the > > addresses a big pain. > > > >

Re: [PATCH v4 3/4] regulator: Add support for a fixed delay after voltage increases

Hi On Tue, Sep 13, 2016 at 2:36 AM, Mark Brown wrote: > On Tue, Sep 06, 2016 at 12:05:04PM -0700, Matthias Kaehlcke wrote: > >> the stabilisation time. This change introduces the device tree property >> "regulator-settle-time-up-us" which allows to specify a fixed delay > >>

Re: [PATCH 4/7 v3] sched: propagate load during synchronous attach/detach

On Mon, Sep 12, 2016 at 09:47:49AM +0200, Vincent Guittot wrote: > + /* If the load of group cfs_rq is null, the load of the > + * sched_entity will also be null so we can skip the formula > + */

solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Hi Krzysztof, Me and one more solo6010 board user experience machine lockup when solo6x10 module is loaded on kernel series starting with 4.3 (despite solo6110 board probes just fine on all kernels). That is, 3.16, 3.18, 4.1 and 4.2 are tested and fine, and 4.3, 4.4, and others up to current

  1   2   3   4   5   6   7   8   9   10   >