[PATCH v2 RESEND] usb: gadget: provide interface for legacy gadgets to get UDC name

Since commit 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb: gadget: udc-core: independent registration of gadgets and gadget drivers") gadget drivers can not assume that UDC drivers are already available on their initialization. This broke the HACK, which was used in gadgetfs driver, to get UDC

[PATCH v2 RESEND] usb: gadget: provide interface for legacy gadgets to get UDC name

Since commit 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb: gadget: udc-core: independent registration of gadgets and gadget drivers") gadget drivers can not assume that UDC drivers are already available on their initialization. This broke the HACK, which was used in gadgetfs driver, to get UDC

[PATCH RESEND] usb: gadget: gadgetfs: unregister gadget only if it got successfully registered

Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even if it didn't register it earlier due to other failures. This patch fixes this. Reported-by: Vegard Nossum Signed-off-by: Marek Szyprowski Tested-by: Vegard Nossum

[PATCH RESEND] usb: gadget: gadgetfs: unregister gadget only if it got successfully registered

Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even if it didn't register it earlier due to other failures. This patch fixes this. Reported-by: Vegard Nossum Signed-off-by: Marek Szyprowski Tested-by: Vegard Nossum --- drivers/usb/gadget/legacy/inode.c | 7 +-- 1

Re: [PATCH v1 5/8] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

2016-02-17 3:37 GMT+09:00 Alexander Potapenko : > On Mon, Feb 1, 2016 at 3:55 AM, Joonsoo Kim wrote: >> On Thu, Jan 28, 2016 at 02:27:44PM +0100, Alexander Potapenko wrote: >>> On Thu, Jan 28, 2016 at 1:51 PM, Alexander Potapenko >>>

Re: [PATCH v1 5/8] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

2016-02-17 3:37 GMT+09:00 Alexander Potapenko : > On Mon, Feb 1, 2016 at 3:55 AM, Joonsoo Kim wrote: >> On Thu, Jan 28, 2016 at 02:27:44PM +0100, Alexander Potapenko wrote: >>> On Thu, Jan 28, 2016 at 1:51 PM, Alexander Potapenko >>> wrote: >>> > >>> > On Jan 28, 2016 8:40 AM, "Joonsoo Kim"

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

* Bryan O'Donoghue wrote: > Currently when setting up an IMR around the kernel's .text area we lock > that IMR, preventing further modification. While superficially this appears > to be the right thing to do, in fact this doesn't account for a legitimate > change

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

* Bryan O'Donoghue wrote: > Currently when setting up an IMR around the kernel's .text area we lock > that IMR, preventing further modification. While superficially this appears > to be the right thing to do, in fact this doesn't account for a legitimate > change in the memory map such as when

Re: [PATCH] lightnvm: generalize rrpc ppa calculations

On 02/17/2016 12:00 PM, Javier González wrote: > In rrpc, some calculations assume a certain configuration (e.g., 1 LUN, > 1 sector per page). The reason behind this was that we have used a simple > configuration in QEMU to test core features generally in LightNVM, and > concretely in rrpc. This

Re: [PATCH] lightnvm: generalize rrpc ppa calculations

On 02/17/2016 12:00 PM, Javier González wrote: > In rrpc, some calculations assume a certain configuration (e.g., 1 LUN, > 1 sector per page). The reason behind this was that we have used a simple > configuration in QEMU to test core features generally in LightNVM, and > concretely in rrpc. This

[PATCH v2] serial: xuartps: Enable OF earlycon support

Support early console setup via DT for all listed compatible strings. Remove EARLYCON_DECLARE which was done by: "Use common framework for earlycon declarations" (sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd) when OF_EARLYCON_DECLARE is defined. Signed-off-by: Michal Simek

[PATCH v2] serial: xuartps: Enable OF earlycon support

Support early console setup via DT for all listed compatible strings. Remove EARLYCON_DECLARE which was done by: "Use common framework for earlycon declarations" (sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd) when OF_EARLYCON_DECLARE is defined. Signed-off-by: Michal Simek --- Changes in v2:

Re: [PATCH] ovl: fix working on distributed fs as lower layer

On 01/31/2016 03:22 PM, Konstantin Khlebnikov wrote: > This adds missing .d_select_inode into alternative dentry_operations. > > Signed-off-by: Konstantin Khlebnikov > Fixes: 7c03b5d45b8e ("ovl: allow distributed fs as lower layer") > Fixes: 4bacc9c9234c ("overlayfs: Make

Re: [PATCH] ovl: fix working on distributed fs as lower layer

On 01/31/2016 03:22 PM, Konstantin Khlebnikov wrote: > This adds missing .d_select_inode into alternative dentry_operations. > > Signed-off-by: Konstantin Khlebnikov > Fixes: 7c03b5d45b8e ("ovl: allow distributed fs as lower layer") > Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

Hi Mark, Thanks for your apply ;) - Yakir On 02/18/2016 02:12 PM, Mark yao wrote: On 2016年01月29日 14:42, Yakir Yang wrote: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

Hi Mark, Thanks for your apply ;) - Yakir On 02/18/2016 02:12 PM, Mark yao wrote: On 2016年01月29日 14:42, Yakir Yang wrote: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function

письмо от Екатерины

Приветствую Вас. У Вас нет заказов, телефоны молчат? Есть от всего этого отличное средство - наш сервис поиска клиентов. Обращайтесь не стесняйтесь 796 11 363521

письмо от Екатерины

Приветствую Вас. У Вас нет заказов, телефоны молчат? Есть от всего этого отличное средство - наш сервис поиска клиентов. Обращайтесь не стесняйтесь 796 11 363521

Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data

* Andi Kleen wrote: > > Do you have any data to back that up or is that just "believe" ? > > I've seen systems with discontiguous apic ids before. > > It is obvious if you consider setups with node hotplug. > > BTW reading this thread you don't seem interested in any

Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data

* Andi Kleen wrote: > > Do you have any data to back that up or is that just "believe" ? > > I've seen systems with discontiguous apic ids before. > > It is obvious if you consider setups with node hotplug. > > BTW reading this thread you don't seem interested in any code review > feedback,

Re: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson wrote: > > Add myself as co-maintainer for the remote processor related subsystems, > as agreed with Ohad. > > Signed-off-by: Bjorn Andersson Thank you Bjorn for the help! Acked-by: Ohad

Re: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson wrote: > > Add myself as co-maintainer for the remote processor related subsystems, > as agreed with Ohad. > > Signed-off-by: Bjorn Andersson Thank you Bjorn for the help! Acked-by: Ohad Ben-Cohen > --- > MAINTAINERS | 3 +++ > 1 file

Re: [RFC][PATCH 12/12] perf: Collapse and fix event_function_call() users

On Wed, Feb 17, 2016 at 05:38:43PM -0500, Sasha Levin wrote: > Hey Peter, > > I seem to be hitting a warning added by this patch: > > [ 258.890172] WARNING: CPU: 5 PID: 14801 at kernel/events/core.c:226 > event_function+0x3a7/0x550() Yes, I've been chasing this one for the past few days. I

Re: [RFC][PATCH 12/12] perf: Collapse and fix event_function_call() users

On Wed, Feb 17, 2016 at 05:38:43PM -0500, Sasha Levin wrote: > Hey Peter, > > I seem to be hitting a warning added by this patch: > > [ 258.890172] WARNING: CPU: 5 PID: 14801 at kernel/events/core.c:226 > event_function+0x3a7/0x550() Yes, I've been chasing this one for the past few days. I

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

2016-02-16 10:16 GMT+09:00 Steven Rostedt : > On Tue, 16 Feb 2016 09:47:20 +0900 > Joonsoo Kim wrote: > >> > They return true when CONFIG_TRACEPOINTS is configured in and the >> > tracepoint is enabled, and false otherwise. >> >> This implementation is

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

2016-02-16 10:16 GMT+09:00 Steven Rostedt : > On Tue, 16 Feb 2016 09:47:20 +0900 > Joonsoo Kim wrote: > >> > They return true when CONFIG_TRACEPOINTS is configured in and the >> > tracepoint is enabled, and false otherwise. >> >> This implementation is what you proposed before. Please refer below

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

Hi Paul, On Thursday 18 February 2016 12:12 PM, Paul Walmsley wrote: Hi Keerthy On Thu, 18 Feb 2016, Keerthy wrote: The patch adds rtc hwmod. RTC module The RTC module is physically present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently disabled. A secure RTC is used instead

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

Hi Paul, On Thursday 18 February 2016 12:12 PM, Paul Walmsley wrote: Hi Keerthy On Thu, 18 Feb 2016, Keerthy wrote: The patch adds rtc hwmod. RTC module The RTC module is physically present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently disabled. A secure RTC is used instead

[PATCH v3 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

Some Lenovo ideapad models lack a physical rfkill switch. On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, ideapad-laptop would wrongly report all radios as blocked by hardware which caused wireless network connections to fail. Add these models without an rfkill switch to the

[PATCH v3 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

Some Lenovo ideapad models lack a physical rfkill switch. On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, ideapad-laptop would wrongly report all radios as blocked by hardware which caused wireless network connections to fail. Add these models without an rfkill switch to the

Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

On 02/16/2016 05:56 PM, John Garry wrote: > On 16/02/2016 15:33, Hannes Reinecke wrote: >> On 02/16/2016 01:22 PM, John Garry wrote: >>> In high-datarate aging tests, it is found that >>> the SCSI framework can periodically >>> issue lu resets to the device. This is because scsi >>> commands begin

Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

On 02/16/2016 05:56 PM, John Garry wrote: > On 16/02/2016 15:33, Hannes Reinecke wrote: >> On 02/16/2016 01:22 PM, John Garry wrote: >>> In high-datarate aging tests, it is found that >>> the SCSI framework can periodically >>> issue lu resets to the device. This is because scsi >>> commands begin

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > > > Ccing The containers list because a related discussion is > > > happening > > > there > > > and somehow this thread has

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote: > On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > > > Ccing The containers list because a related discussion is > > > happening > > > there > > > and somehow this thread has

linux-next: Tree for Feb 18

Hi all, Changes since 20160217: The mvebu tree gained a conflict against the arm-soc tree. The net-next tree gained a build failure so I used the version from next-20160217. The crypto tree lost its build failure. The block tree gained a conflict against Linus' tree. The char-misc tree

linux-next: Tree for Feb 18

Hi all, Changes since 20160217: The mvebu tree gained a conflict against the arm-soc tree. The net-next tree gained a build failure so I used the version from next-20160217. The crypto tree lost its build failure. The block tree gained a conflict against Linus' tree. The char-misc tree

Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485 direction control

Also, forgot to mention that if serial8250_em485_init is called not upon uart startup but elsewhere (upon port register for example), and em485 is set, serial8250_do_startup should call serial8250_em485_rts_after_send, or else RTS might be in wrong state whenever the port device is opened, making

Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485 direction control

Also, forgot to mention that if serial8250_em485_init is called not upon uart startup but elsewhere (upon port register for example), and em485 is set, serial8250_do_startup should call serial8250_em485_rts_after_send, or else RTS might be in wrong state whenever the port device is opened, making

RE: [PATCH] PCI: imx6:don't sleep in atomic context

-Original Message- From: Bjorn Helgaas [mailto:helg...@kernel.org] Sent: Thursday, January 07, 2016 3:35 AM To: Sharma, Sanjeev Cc: richard@freescale.com; l.st...@pengutronix.de; bhelg...@google.com; linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;

RE: [PATCH] PCI: imx6:don't sleep in atomic context

-Original Message- From: Bjorn Helgaas [mailto:helg...@kernel.org] Sent: Thursday, January 07, 2016 3:35 AM To: Sharma, Sanjeev Cc: richard@freescale.com; l.st...@pengutronix.de; bhelg...@google.com; linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;

Re: [PATCH 3/6] hisi_sas: use slot abort in v1 hw

On 02/16/2016 05:13 PM, John Garry wrote: > On 16/02/2016 15:31, Hannes Reinecke wrote: >> On 02/16/2016 01:22 PM, John Garry wrote: >>> When TRANS_TX_CREDIT_TIMEOUT_ERR or >>> TRANS_TX_CLOSE_NORMAL_ERR errors occur for a >>> command, the command should be re-attempted. >>> >>> Signed-off-by: John

Re: [PATCH 3/6] hisi_sas: use slot abort in v1 hw

On 02/16/2016 05:13 PM, John Garry wrote: > On 16/02/2016 15:31, Hannes Reinecke wrote: >> On 02/16/2016 01:22 PM, John Garry wrote: >>> When TRANS_TX_CREDIT_TIMEOUT_ERR or >>> TRANS_TX_CLOSE_NORMAL_ERR errors occur for a >>> command, the command should be re-attempted. >>> >>> Signed-off-by: John

Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

Hi, Oliver Neukum writes: >> Oliver Neukum writes: >> >> > The API to user space. That is the point. We cannot break user space. >> >> > Once this sysfs API is upstream we are stuck with it. >> >> >> >> yeah, in fact I have been wondering if sysfs is the

Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

Hi, Oliver Neukum writes: >> Oliver Neukum writes: >> >> > The API to user space. That is the point. We cannot break user space. >> >> > Once this sysfs API is upstream we are stuck with it. >> >> >> >> yeah, in fact I have been wondering if sysfs is the best interface to >> > >> > That is

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

Hi Franklin On Wed, 17 Feb 2016, Franklin S Cooper Jr. wrote: > On 08/31/2015 10:51 AM, Paul Walmsley wrote: > > On Thu, 16 Jul 2015, R, Vignesh wrote: > >> On 07/16/2015 03:24 AM, Paul Walmsley wrote: > >>> On Wed, 3 Jun 2015, Vignesh R wrote: > >>> > Add hwmod entries for the PWMSS on

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

Hi Franklin On Wed, 17 Feb 2016, Franklin S Cooper Jr. wrote: > On 08/31/2015 10:51 AM, Paul Walmsley wrote: > > On Thu, 16 Jul 2015, R, Vignesh wrote: > >> On 07/16/2015 03:24 AM, Paul Walmsley wrote: > >>> On Wed, 3 Jun 2015, Vignesh R wrote: > >>> > Add hwmod entries for the PWMSS on

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote: > On Sat, 13 Feb 2016 12:58:31 +0100 (CET) > Sebastian Ott wrote: > > > [ 59.875935] [ cut here ] > > [ 59.875937] kernel BUG at mm/huge_memory.c:2884! > > [ 59.875979]

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote: > On Sat, 13 Feb 2016 12:58:31 +0100 (CET) > Sebastian Ott wrote: > > > [ 59.875935] [ cut here ] > > [ 59.875937] kernel BUG at mm/huge_memory.c:2884! > > [ 59.875979] illegal operation: 0001 ilc:1

Re: V4L docs and docbook

Hi Jon, On 02/17/2016 10:52 PM, Jonathan Corbet wrote: > Hey, Mauro, > > There's been a conversation going on that I keep meaning to bring you > into. In short, there's a fair amount of interest in improving our > formatted kernel documentation, and, in particular, making it easier to > write;

Re: V4L docs and docbook

Hi Jon, On 02/17/2016 10:52 PM, Jonathan Corbet wrote: > Hey, Mauro, > > There's been a conversation going on that I keep meaning to bring you > into. In short, there's a fair amount of interest in improving our > formatted kernel documentation, and, in particular, making it easier to > write;

Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan()

On 2016/2/17 8:35, David Rientjes wrote: > On Tue, 16 Feb 2016, Greg Kroah-Hartman wrote: > >> On Tue, Feb 16, 2016 at 05:37:05PM +0800, Xishi Qiu wrote: >>> Currently tasksize in lowmem_scan() only calculate rss, and not include >>> swap. >>> But usually smart phones enable zram, so swap space

Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan()

On 2016/2/17 8:35, David Rientjes wrote: > On Tue, 16 Feb 2016, Greg Kroah-Hartman wrote: > >> On Tue, Feb 16, 2016 at 05:37:05PM +0800, Xishi Qiu wrote: >>> Currently tasksize in lowmem_scan() only calculate rss, and not include >>> swap. >>> But usually smart phones enable zram, so swap space

Re: [tip:x86/urgent] hpet: Drop stale URLs

Hi, On Wed, Feb 17, 2016 at 04:14:54AM -0800, tip-bot for Michael S. Tsirkin wrote: > Commit-ID: 4e7f9df25874cedbbc604a5c5c2e7a6efe662387 > Gitweb: http://git.kernel.org/tip/4e7f9df25874cedbbc604a5c5c2e7a6efe662387 > Author: Michael S. Tsirkin > AuthorDate: Thu, 11 Feb

Re: [tip:x86/urgent] hpet: Drop stale URLs

Hi, On Wed, Feb 17, 2016 at 04:14:54AM -0800, tip-bot for Michael S. Tsirkin wrote: > Commit-ID: 4e7f9df25874cedbbc604a5c5c2e7a6efe662387 > Gitweb: http://git.kernel.org/tip/4e7f9df25874cedbbc604a5c5c2e7a6efe662387 > Author: Michael S. Tsirkin > AuthorDate: Thu, 11 Feb 2016 01:05:01

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

Hi Keerthy On Thu, 18 Feb 2016, Keerthy wrote: > The patch adds rtc hwmod. RTC module The RTC module is physically > present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently > disabled. A secure RTC is used instead on these devices, where needed. > . Hence adding it selectively

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

Hi Keerthy On Thu, 18 Feb 2016, Keerthy wrote: > The patch adds rtc hwmod. RTC module The RTC module is physically > present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently > disabled. A secure RTC is used instead on these devices, where needed. > . Hence adding it selectively

[PATCH v3 1/5] soc: qcom: smd: Introduce callback setter

From: Bjorn Andersson Introduce a setter for the callback function pointer to clarify the locking around the operation and to reduce some duplication. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson

[PATCH v3 1/5] soc: qcom: smd: Introduce callback setter

From: Bjorn Andersson Introduce a setter for the callback function pointer to clarify the locking around the operation and to reduce some duplication. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson --- Changes since v2: - None Changes since v1: - New patch

[PATCH v3 2/5] soc: qcom: smd: Split discovery and state change work

From: Bjorn Andersson Split the two steps of channel discovery and state change handling into two different workers. This allows for new channels to be found while we're are probing, which is required as we introduce multi-channel support. Signed-off-by: Bjorn

[PATCH v3 2/5] soc: qcom: smd: Split discovery and state change work

From: Bjorn Andersson Split the two steps of channel discovery and state change handling into two different workers. This allows for new channels to be found while we're are probing, which is required as we introduce multi-channel support. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn

[PATCH v3 4/5] soc: qcom: smd: Support multiple channels per sdev

From: Bjorn Andersson This patch allows chaining additional channels to a SMD device, enabling implementation of multi-channel SMD devies - like Bluetooth. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson

[PATCH v3 5/5] soc: qcom: smd: Support opening additional channels

From: Bjorn Andersson With the qcom_smd_open_channel() API we allow SMD devices to open additional SMD channels, to allow implementation of multi-channel SMD devices - like Bluetooth. Channels are opened from the same edge as the calling SMD device is tied to.

[PATCH v3 3/5] soc: qcom: smd: Refactor channel open and close handling

From: Bjorn Andersson Refactor opening and closing of channels into two separate functions instead of open coding this in the various places. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson

[PATCH v3 4/5] soc: qcom: smd: Support multiple channels per sdev

From: Bjorn Andersson This patch allows chaining additional channels to a SMD device, enabling implementation of multi-channel SMD devies - like Bluetooth. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson --- Changes since v2: - None Changes since v1: - New patch

[PATCH v3 5/5] soc: qcom: smd: Support opening additional channels

From: Bjorn Andersson With the qcom_smd_open_channel() API we allow SMD devices to open additional SMD channels, to allow implementation of multi-channel SMD devices - like Bluetooth. Channels are opened from the same edge as the calling SMD device is tied to. Signed-off-by: Bjorn Andersson

[PATCH v3 3/5] soc: qcom: smd: Refactor channel open and close handling

From: Bjorn Andersson Refactor opening and closing of channels into two separate functions instead of open coding this in the various places. Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson --- Changes since v2: - None Changes since v1: - New patch drivers/soc/qcom/smd.c |

[PATCH v3 0/5] Qualcomm SMD multi-channel client support

After trying to avoid implementing multi-channel support in SMD in v1 of the HCI driver for Qualcomm WCNSS BT, this new version includes the necessary SMD refactoring and additon of an API that allows SMD devices to call back into the SMD core to acquire additonal channels. The additional

[PATCH v3 0/5] Qualcomm SMD multi-channel client support

After trying to avoid implementing multi-channel support in SMD in v1 of the HCI driver for Qualcomm WCNSS BT, this new version includes the necessary SMD refactoring and additon of an API that allows SMD devices to call back into the SMD core to acquire additonal channels. The additional

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > Ccing The containers list because a related discussion is happening > > there > > and somehow this thread has never made it there. > > > > Ian Kent writes: > >

Re: call_usermodehelper in containers

On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote: > On 2016/02/18 11:57, Eric W. Biederman wrote: > > > > Ccing The containers list because a related discussion is happening > > there > > and somehow this thread has never made it there. > > > > Ian Kent writes: > > > > > On Mon,

[RESEND PATCH v3] isdn: divamnt: use y2038-safe ktime_get_ts64() for trace data timestamps

divamnt stores a start_time at module init and uses it to calculate elapsed time. The elapsed time, stored in secs and usecs, is part of the trace data the driver maintains for the DIVA Server ISDN cards. No change to the format of that time data is required. To avoid overflow on 32-bit systems

[RESEND PATCH v3] isdn: divamnt: use y2038-safe ktime_get_ts64() for trace data timestamps

divamnt stores a start_time at module init and uses it to calculate elapsed time. The elapsed time, stored in secs and usecs, is part of the trace data the driver maintains for the DIVA Server ISDN cards. No change to the format of that time data is required. To avoid overflow on 32-bit systems

Re: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

On 18-02-16, 14:13, Krzysztof Kozlowski wrote: > On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and > 12 steps for big core (700-1800 MHz). Add respective cooling cells. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Add

Re: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

On 18-02-16, 14:13, Krzysztof Kozlowski wrote: > On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and > 12 steps for big core (700-1800 MHz). Add respective cooling cells. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Add cooling properties to all

Re: [PATCH v2 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load

On 18-02-16, 14:13, Krzysztof Kozlowski wrote: > After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can > be easily overheated when launching eight CPU-intensive tasks: > thermal thermal_zone3: critical temperature reached(121 C),shutting down > > This seems to be specific

Re: [PATCH v2 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load

On 18-02-16, 14:13, Krzysztof Kozlowski wrote: > After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can > be easily overheated when launching eight CPU-intensive tasks: > thermal thermal_zone3: critical temperature reached(121 C),shutting down > > This seems to be specific

Re: [PATCH v2 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800

On 18-02-16, 14:13, Krzysztof Kozlowski wrote: > On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for > LITTLE > and 18 steps for big core (200-1700 MHz). Add respective cooling cells. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes

Re: [PATCH v2 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800

On 18-02-16, 14:13, Krzysztof Kozlowski wrote: > On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for > LITTLE > and 18 steps for big core (200-1700 MHz). Add respective cooling cells. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Add cooling

Re: [PATCH 12/12] cpufreq: governor: Narrow down the dbs_data_mutex coverage

On 18-02-16, 02:38, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since cpufreq_governor_dbs() is now always called with policy->rwsem > held, it cannot be executed twice in parallel for the same policy. > Thus it is not necessary to hold dbs_data_mutex

Re: [PATCH 12/12] cpufreq: governor: Narrow down the dbs_data_mutex coverage

On 18-02-16, 02:38, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since cpufreq_governor_dbs() is now always called with policy->rwsem > held, it cannot be executed twice in parallel for the same policy. > Thus it is not necessary to hold dbs_data_mutex around the invocations > of

Re: [PATCH 07/54] perf tools: Enable BPF object configure syntax

On 2016/2/12 22:09, Jiri Olsa wrote: On Fri, Feb 05, 2016 at 02:01:32PM +, Wang Nan wrote: SNIP } | -PE_BPF_SOURCE +PE_BPF_SOURCE opt_event_config { struct parse_events_evlist *data = _data; struct list_head *list; ALLOC_LIST(list); -

Re: [PATCH 07/54] perf tools: Enable BPF object configure syntax

On 2016/2/12 22:09, Jiri Olsa wrote: On Fri, Feb 05, 2016 at 02:01:32PM +, Wang Nan wrote: SNIP } | -PE_BPF_SOURCE +PE_BPF_SOURCE opt_event_config { struct parse_events_evlist *data = _data; struct list_head *list; ALLOC_LIST(list); -

Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec

Hi Kent, Thanks for your review. On Thu, Feb 18, 2016 at 12:24 PM, Kent Overstreet wrote: > On Mon, Feb 15, 2016 at 05:42:12PM +0800, Ming Lei wrote: >> Cc Kent and Keith. >> >> Follows another version which should be more efficient. >> Kent and Keith, I appreciate

Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec

Hi Kent, Thanks for your review. On Thu, Feb 18, 2016 at 12:24 PM, Kent Overstreet wrote: > On Mon, Feb 15, 2016 at 05:42:12PM +0800, Ming Lei wrote: >> Cc Kent and Keith. >> >> Follows another version which should be more efficient. >> Kent and Keith, I appreciate much if you may give a review

Re: [PATCH] regulator: s2mps11: Use local variable for number of regulators

Thanks, > Remove the s2mps11_info.rdev_num because it is not used outside of > probe. > > Suggested-by: Andi Shyti > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andi Shyti Andi

Re: [PATCH] regulator: s2mps11: Use local variable for number of regulators

Thanks, > Remove the s2mps11_info.rdev_num because it is not used outside of > probe. > > Suggested-by: Andi Shyti > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Andi Shyti Andi

[PATCH v2] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

From: Josh Wu For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they need the HSMC clock to be enabled to work. The NFC is a sub feature for current nand driver, it can be disabled. But if HSMC clock is controlled by NFC, so disable NFC will also disable the HSMC

[PATCH v2] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

From: Josh Wu For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they need the HSMC clock to be enabled to work. The NFC is a sub feature for current nand driver, it can be disabled. But if HSMC clock is controlled by NFC, so disable NFC will also disable the HSMC clock. then, it will

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

On 2016年01月29日 14:42, Yakir Yang wrote: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24,

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

On 2016年01月29日 14:42, Yakir Yang wrote: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24,

Re: [PATCH 11/12] cpufreq: governor: Make dbs_data_mutex static

On 18-02-16, 02:33, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > That mutex is only used by cpufreq_governor_dbs() and it doesn't > need to be exported to modules, so make it static and drop the > export incantation. > > No functional changes. > >

Re: [PATCH 11/12] cpufreq: governor: Make dbs_data_mutex static

On 18-02-16, 02:33, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > That mutex is only used by cpufreq_governor_dbs() and it doesn't > need to be exported to modules, so make it static and drop the > export incantation. > > No functional changes. > > Signed-off-by: Rafael J. Wysocki >

Re: [PATCH 10/12] cpufreq: governor: Relocate definitions of tuners structures

On 18-02-16, 02:32, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Move the definitions of struct od_dbs_tuners and struct cs_dbs_tuners > from the common governor header to the ondemand and conservative > governor code, respectively, as they don't need to be

Re: [PATCH 10/12] cpufreq: governor: Relocate definitions of tuners structures

On 18-02-16, 02:32, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Move the definitions of struct od_dbs_tuners and struct cs_dbs_tuners > from the common governor header to the ondemand and conservative > governor code, respectively, as they don't need to be in the common > header any

Re: [PATCH 9/12] cpufreq: governor: Move per-CPU data to the common code

On 18-02-16, 02:31, Rafael J. Wysocki wrote: > @@ -464,21 +455,24 @@ static void od_set_powersave_bias(unsign > > get_online_cpus(); > for_each_online_cpu(cpu) { > + struct cpufreq_policy *policy; > struct policy_dbs_info *policy_dbs; > + struct

Re: [PATCH 9/12] cpufreq: governor: Move per-CPU data to the common code

On 18-02-16, 02:31, Rafael J. Wysocki wrote: > @@ -464,21 +455,24 @@ static void od_set_powersave_bias(unsign > > get_online_cpus(); > for_each_online_cpu(cpu) { > + struct cpufreq_policy *policy; > struct policy_dbs_info *policy_dbs; > + struct

Re: [PATCH 8/12] cpufreq: governor: Make governor private data per-policy

On 18-02-16, 02:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Some fields in struct od_cpu_dbs_info_s and struct cs_cpu_dbs_info_s > are only used for a limited set of CPUs. Namely, if a policy is > shared between multiple CPUs, those fields will only be

Re: [PATCH 8/12] cpufreq: governor: Make governor private data per-policy

On 18-02-16, 02:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Some fields in struct od_cpu_dbs_info_s and struct cs_cpu_dbs_info_s > are only used for a limited set of CPUs. Namely, if a policy is > shared between multiple CPUs, those fields will only be used for one > of them

Re: [PATCH RESEND v3] asus-nb-wmi: add wapf=4 quirk for ASUS X75VD

Thanks for your patience ;). On середа, 17 лютого 2016 р. 21:23:45 EET Darren Hart wrote: > On Wed, Feb 17, 2016 at 01:35:46PM +0200, Oleksandr Natalenko wrote: > > Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module > > is loaded with wapf=4 option. Add quirk for this. > > > >

Re: [PATCH RESEND v3] asus-nb-wmi: add wapf=4 quirk for ASUS X75VD

Thanks for your patience ;). On середа, 17 лютого 2016 р. 21:23:45 EET Darren Hart wrote: > On Wed, Feb 17, 2016 at 01:35:46PM +0200, Oleksandr Natalenko wrote: > > Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module > > is loaded with wapf=4 option. Add quirk for this. > > > >

  1   2   3   4   5   6   7   8   9   10   >