On 18/04/17 02:04 PM, Ilia Mirkin wrote:
> On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote:
>> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
> However, I totally agree with Alex that someone
On 18/04/17 02:04 PM, Ilia Mirkin wrote:
> On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote:
>> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
> However, I totally agree with Alex that someone with a BE machine
> should review the
On 17.04.2017 08:02, Hoegeun Kwon wrote:
> This patch supports TM2e panel and the panel has 1600x2560 resolution
> in 5.65" physical.
>
> This identify panel type with compatibility string, also invoke
> display mode that matches the type. So add the check code for s6e3ha2
> compatibility and
On 17.04.2017 08:02, Hoegeun Kwon wrote:
> This patch supports TM2e panel and the panel has 1600x2560 resolution
> in 5.65" physical.
>
> This identify panel type with compatibility string, also invoke
> display mode that matches the type. So add the check code for s6e3ha2
> compatibility and
On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> make[7]: *** No rule to make target
>
On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> make[7]: *** No rule to make target
>
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error:
initialization from incompatible pointer type
[-Werror=incompatible-pointer-types]
.change_virtual_intf =
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error:
initialization from incompatible pointer type
[-Werror=incompatible-pointer-types]
.change_virtual_intf =
On 17.04.2017 08:02, Hoegeun Kwon wrote:
> The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
> panel similar to the s6e3ha2. So add the compatible string and
> comments.
>
>
On 17.04.2017 08:02, Hoegeun Kwon wrote:
> The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a
> panel similar to the s6e3ha2. So add the compatible string and
> comments.
>
>
I'm announcing the release of the 3.12.73 kernel.
All users of the 3.12 kernel series must upgrade.
The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.12.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 3.12.73 kernel.
All users of the 3.12 kernel series must upgrade.
The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.12.y
and can be browsed at the normal kernel.org git web
vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area
during boot process and those virtually mapped areas are never unmapped.
So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing
existing vmlist entries and prevent those areas from being removed from the
vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area
during boot process and those virtually mapped areas are never unmapped.
So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing
existing vmlist entries and prevent those areas from being removed from the
Christophe Leroy writes:
> This patch is a bunch of small cleanups of the do_page_fault()
> function:
> 1/ Function store_updates_sp() checks whether the faulting
> instruction is a store updating r1. Therefore we can limit its calls
> to stores exceptions
> 2/ Only the
Christophe Leroy writes:
> This patch is a bunch of small cleanups of the do_page_fault()
> function:
> 1/ Function store_updates_sp() checks whether the faulting
> instruction is a store updating r1. Therefore we can limit its calls
> to stores exceptions
> 2/ Only the get_user() in
On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote:
> Is it ? Again, you create a "concept" the user may have no idea about,
> "p2pmem memory". So now any kind of memory buffer on a device can could
> be use for p2p but also potentially a bunch of other things becomes
> special and called
On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote:
> Is it ? Again, you create a "concept" the user may have no idea about,
> "p2pmem memory". So now any kind of memory buffer on a device can could
> be use for p2p but also potentially a bunch of other things becomes
> special and called
On Mon, Apr 17, 2017 at 07:57:36PM +0800, Icenowy Zheng wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>
> Add it and its pinmux.
>
> Signed-off-by: Icenowy Zheng
> Acked-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxime Ripard,
On Mon, Apr 17, 2017 at 07:57:36PM +0800, Icenowy Zheng wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>
> Add it and its pinmux.
>
> Signed-off-by: Icenowy Zheng
> Acked-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and
On Mon, Apr 17, 2017 at 06:34:49PM +0800, Icenowy Zheng wrote:
> The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.
>
> Fix it by changing it to the correct H3 compatible.
>
> Signed-off-by: Icenowy Zheng
Applied, thanks
Maxime
--
Maxime Ripard, Free Electrons
On Mon, Apr 17, 2017 at 06:34:49PM +0800, Icenowy Zheng wrote:
> The R_CCU of H3/H5 currently wrongly used A64 R_CCU compatible.
>
> Fix it by changing it to the correct H3 compatible.
>
> Signed-off-by: Icenowy Zheng
Applied, thanks
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux
On Fri, Apr 14, 2017 at 09:08:04PM +0200, Andreas Färber wrote:
> Enabling uart2 node currently leads to a /dev/ttyS1 device, with ttyS0..4
> always present, causing confusion on the user's part.
>
> dtc cannot resolve an overlay's reference for strings, only for
> phandles, so it would need to
On Fri, Apr 14, 2017 at 09:08:04PM +0200, Andreas Färber wrote:
> Enabling uart2 node currently leads to a /dev/ttyS1 device, with ttyS0..4
> always present, causing confusion on the user's part.
>
> dtc cannot resolve an overlay's reference for strings, only for
> phandles, so it would need to
On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote:
> UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node
> available at the SoC level, to simplify enabling UART2 via DT overlay.
>
> Signed-off-by: Andreas Färber
Applied, thanks!
Could you also
On Fri, Apr 14, 2017 at 07:13:20PM +0200, Andreas Färber wrote:
> UART2 is exposed on the Pi connector of Pine64. Make a pinctrl node
> available at the SoC level, to simplify enabling UART2 via DT overlay.
>
> Signed-off-by: Andreas Färber
Applied, thanks!
Could you also create the node in
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
make[7]: *** No rule to make target
'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
needed by
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
make[7]: *** No rule to make target
'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
needed by
The madvise_behavior_valid() function should be called before
acting upon the behavior parameter. Hence move up the function.
This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options
as valid behavior parameter for the system call madvise().
Signed-off-by: Anshuman Khandual
The madvise_behavior_valid() function should be called before
acting upon the behavior parameter. Hence move up the function.
This also includes MADV_SOFT_OFFLINE and MADV_HWPOISON options
as valid behavior parameter for the system call madvise().
Signed-off-by: Anshuman Khandual
---
Changes in
On 17/04/17 11:04 AM, Dan Williams wrote:
>> Yes, in this scheme, it needs an additional p2pmem child. Why is that an
>> issue? It certainly makes it a lot easier for the user to understand the
>> p2pmem memory in the system (through the sysfs tree) and reason about
>> the topology and when to
On 17/04/17 11:04 AM, Dan Williams wrote:
>> Yes, in this scheme, it needs an additional p2pmem child. Why is that an
>> issue? It certainly makes it a lot easier for the user to understand the
>> p2pmem memory in the system (through the sysfs tree) and reason about
>> the topology and when to
From: Russ Dill
Many RTCs provide scratch registers that are maintained so long as the RTC
has power. Provide a generic method to access these registers.
Signed-off-by: Russ Dill
Signed-off-by: Keerthy
---
drivers/rtc/interface.c | 50
From: Russ Dill
Many RTCs provide scratch registers that are maintained so long as the RTC
has power. Provide a generic method to access these registers.
Signed-off-by: Russ Dill
Signed-off-by: Keerthy
---
drivers/rtc/interface.c | 50 +
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
On 17-04-17, 18:40, Rafael J. Wysocki wrote:
> On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote:
> > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote:
> > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki :
> > > > On Monday, April 10, 2017 02:51:35 PM
On 17-04-17, 18:40, Rafael J. Wysocki wrote:
> On Monday, April 17, 2017 06:35:25 PM Rafael J. Wysocki wrote:
> > On Monday, April 17, 2017 11:07:51 AM Masahiro Yamada wrote:
> > > 2017-04-15 7:47 GMT+09:00 Rafael J. Wysocki :
> > > > On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> > >
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski
Reported-by:
From: Russ Dill
The clock/dpll registers are in the WKUP power domain. Under both RTC-only
suspend and hibernation, these registers are lost. Hence save/restore
them accordingly.
Signed-off-by: Russ Dill
Signed-off-by: Keerthy
---
From: Russ Dill
The clock/dpll registers are in the WKUP power domain. Under both RTC-only
suspend and hibernation, these registers are lost. Hence save/restore
them accordingly.
Signed-off-by: Russ Dill
Signed-off-by: Keerthy
---
drivers/clk/clk.c| 70
On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
However, I totally agree with Alex that someone with a BE machine
should review the whole
On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
However, I totally agree with Alex that someone with a BE machine
should review the whole stack before we could be confident with
Hi Huang,
On Fri, Apr 07, 2017 at 02:49:01PM +0800, Huang, Ying wrote:
> From: Huang Ying
>
> To reduce the lock contention of swap_info_struct->lock when freeing
> swap entry. The freed swap entries will be collected in a per-CPU
> buffer firstly, and be really freed
Hi Huang,
On Fri, Apr 07, 2017 at 02:49:01PM +0800, Huang, Ying wrote:
> From: Huang Ying
>
> To reduce the lock contention of swap_info_struct->lock when freeing
> swap entry. The freed swap entries will be collected in a per-CPU
> buffer firstly, and be really freed later in batch. During
On Mon, Apr 17, 2017 at 12:25:38PM -0600, Shuah Khan wrote:
> On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.11 release.
> > There are 29 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Mon, Apr 17, 2017 at 12:25:38PM -0600, Shuah Khan wrote:
> On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.10.11 release.
> > There are 29 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Mon, Apr 17, 2017 at 12:18:19PM -0600, Shuah Khan wrote:
> On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.49 release.
> > There are 145 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Mon, Apr 17, 2017 at 12:18:19PM -0600, Shuah Khan wrote:
> On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.49 release.
> > There are 145 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote:
>
>
> Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> > 3.18-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Marcelo Ricardo Leitner
On Mon, Apr 17, 2017 at 05:00:50PM -0300, Marcelo Ricardo Leitner wrote:
>
>
> Em 16-04-2017 07:48, Greg Kroah-Hartman escreveu:
> > 3.18-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Marcelo Ricardo Leitner
> >
> >
> > [
On Tue, Apr 18, 2017 at 06:14:11AM +0200, Greg KH wrote:
> On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> > Swap string in the dev_warn() call with __func__ argument, instead of
> > explicitly calling the function name in the string:
> >
> > WARNING: Prefer using "%s",
On Tue, Apr 18, 2017 at 06:14:11AM +0200, Greg KH wrote:
> On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> > Swap string in the dev_warn() call with __func__ argument, instead of
> > explicitly calling the function name in the string:
> >
> > WARNING: Prefer using "%s",
On 04/17/2017 04:53 PM, Zheng, Lv wrote:
Hi,
From: Guenter Roeck [mailto:li...@roeck-us.net]
Subject: Re: [PATCH] ACPICA: Export mutex functions
On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote:
On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote:
On
On 04/17/2017 04:53 PM, Zheng, Lv wrote:
Hi,
From: Guenter Roeck [mailto:li...@roeck-us.net]
Subject: Re: [PATCH] ACPICA: Export mutex functions
On Mon, Apr 17, 2017 at 11:29:38PM +0200, Rafael J. Wysocki wrote:
On Mon, Apr 17, 2017 at 11:03 PM, Guenter Roeck wrote:
On Mon, Apr 17, 2017 at
thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system
thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system
orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the
orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the
On Mon, Apr 17, 2017 at 08:22:57PM +0200, Martin Kaiser wrote:
> Set the permissions for /proc/misc to 0444 explicitly. At the moment,
> we're using 0 and have proc_create_data() convert this to 0444.
> This fixes a checkpatch warning.
>
> Signed-off-by: Martin Kaiser
> ---
>
On Mon, Apr 17, 2017 at 08:22:57PM +0200, Martin Kaiser wrote:
> Set the permissions for /proc/misc to 0444 explicitly. At the moment,
> we're using 0 and have proc_create_data() convert this to 0444.
> This fixes a checkpatch warning.
>
> Signed-off-by: Martin Kaiser
> ---
> v2:
>separate
On 04/17/2017 02:50 AM, Greg KH wrote:
On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote:
adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow
the user to restrict unprivileged command injection using TIOCSTI
tty ioctls
"unpriviledged command injection"? That sounds
On 04/17/2017 02:50 AM, Greg KH wrote:
On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote:
adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow
the user to restrict unprivileged command injection using TIOCSTI
tty ioctls
"unpriviledged command injection"? That sounds
On Mon, Apr 17, 2017 at 04:37:38PM -0600, Alex Williamson wrote:
> v5:
> - patch 1/ Use bool* to cleanup vfio_lock_acct() callers; sorry
> we cannot re-test CAP_IPC_LOCK for all callers
> - patch 2/ Re-add pr_warn, add Kirti's R-b
> - patch 3/ NEW, analyzing impact of
On Mon, Apr 17, 2017 at 04:37:38PM -0600, Alex Williamson wrote:
> v5:
> - patch 1/ Use bool* to cleanup vfio_lock_acct() callers; sorry
> we cannot re-test CAP_IPC_LOCK for all callers
> - patch 2/ Re-add pr_warn, add Kirti's R-b
> - patch 3/ NEW, analyzing impact of
On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> Swap string in the dev_warn() call with __func__ argument, instead of
> explicitly calling the function name in the string:
>
> WARNING: Prefer using "%s", __func__ to embedded function names
> #417: FILE:
On Mon, Apr 17, 2017 at 04:58:48PM -0700, Chewie Lin wrote:
> Swap string in the dev_warn() call with __func__ argument, instead of
> explicitly calling the function name in the string:
>
> WARNING: Prefer using "%s", __func__ to embedded function names
> #417: FILE:
On Monday 17 April 2017 10:46 PM, Eduardo Valentin wrote:
> On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote:
>> orderly_poweroff is triggered when a graceful shutdown
>> of system is desired. This may be used in many critical states of the
>> kernel such as when subsystems detects
On Monday 17 April 2017 10:46 PM, Eduardo Valentin wrote:
> On Sat, Apr 15, 2017 at 08:38:29AM +0530, Keerthy wrote:
>> orderly_poweroff is triggered when a graceful shutdown
>> of system is desired. This may be used in many critical states of the
>> kernel such as when subsystems detects
On Mon, Apr 17, 2017 at 11:09:38AM -0700, Roy Franz (HPE) wrote:
> On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin wrote:
> > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
> >> On 13 April 2017 at 04:58, Gary Lin wrote:
> >> > This commit adds the new
On Mon, Apr 17, 2017 at 11:09:38AM -0700, Roy Franz (HPE) wrote:
> On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin wrote:
> > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
> >> On 13 April 2017 at 04:58, Gary Lin wrote:
> >> > This commit adds the new config options to allow the
On Mon, Apr 17, 2017 at 06:41:38PM +0800, Zefan Li wrote:
> On 2017/4/15 7:32, Andrei Vagin wrote:
> > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
> >> Hello,
> >>
> >> One of our CRIU tests hangs with this patch.
> >>
> >> Steps to reproduce:
> >> curl -o cgroupns.c
> >>
On Mon, Apr 17, 2017 at 06:41:38PM +0800, Zefan Li wrote:
> On 2017/4/15 7:32, Andrei Vagin wrote:
> > On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
> >> Hello,
> >>
> >> One of our CRIU tests hangs with this patch.
> >>
> >> Steps to reproduce:
> >> curl -o cgroupns.c
> >>
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.
When use this quirk, the controller implements a fixed 40-bit
Do not recommend people write to Dominic, rather everyone should be using
linux-input mailing list.
Signed-off-by: Dmitry Torokhov
---
Documentation/input/devices/xpad.rst | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/input/devices/xpad.rst
Do not recommend people write to Dominic, rather everyone should be using
linux-input mailing list.
Signed-off-by: Dmitry Torokhov
---
Documentation/input/devices/xpad.rst | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/input/devices/xpad.rst
kbuild test robot writes:
> Hi Aneesh,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.11-rc7 next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
>
kbuild test robot writes:
> Hi Aneesh,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.11-rc7 next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
>
On 04/13/17 05:33, Alexey Brodkin wrote:
> DWC3 driver uses of_usb_get_phy_mode() which is
> implemented in drivers/usb/phy/of.c and in bare minimal
> configuration it might not be pulled in kernel binary.
>
> In case of ARC or ARM this could be easily reproduced with
> "allnodefconfig"
On 04/13/17 05:33, Alexey Brodkin wrote:
> DWC3 driver uses of_usb_get_phy_mode() which is
> implemented in drivers/usb/phy/of.c and in bare minimal
> configuration it might not be pulled in kernel binary.
>
> In case of ARC or ARM this could be easily reproduced with
> "allnodefconfig"
On Mon, Apr 17, 2017 at 09:46:14AM -0300, Mauro Carvalho Chehab wrote:
> Unfortunately, Sphinx (or LaTeX) can't handle literal blocks
> inside footnotes. So, just use normal text for the two
> literal code-blocks that documents the output of
> /sys/kernel/debug/usb/devices for xpad devices.
>
>
On Mon, Apr 17, 2017 at 09:46:14AM -0300, Mauro Carvalho Chehab wrote:
> Unfortunately, Sphinx (or LaTeX) can't handle literal blocks
> inside footnotes. So, just use normal text for the two
> literal code-blocks that documents the output of
> /sys/kernel/debug/usb/devices for xpad devices.
>
>
On Mon, Apr 17, 2017 at 09:46:13AM -0300, Mauro Carvalho Chehab wrote:
> The /proc/bus/usb/devices got moved to sysfs. It is now
> sitting at:
> /sys/kernel/debug/usb/devices
>
> Signed-off-by: Mauro Carvalho Chehab
Applied, thank you.
> ---
>
On Mon, Apr 17, 2017 at 09:46:13AM -0300, Mauro Carvalho Chehab wrote:
> The /proc/bus/usb/devices got moved to sysfs. It is now
> sitting at:
> /sys/kernel/debug/usb/devices
>
> Signed-off-by: Mauro Carvalho Chehab
Applied, thank you.
> ---
>
Hi Mauro,
On Mon, Apr 17, 2017 at 09:46:15AM -0300, Mauro Carvalho Chehab wrote:
> xpad.rst requests a dump of the USB description, as found
> on the USB character device. When we got rid of usbfs,
> its location change. Update it.
I have not heard from Dom ever so I think the best option is to
Hi Mauro,
On Mon, Apr 17, 2017 at 09:46:15AM -0300, Mauro Carvalho Chehab wrote:
> xpad.rst requests a dump of the USB description, as found
> on the USB character device. When we got rid of usbfs,
> its location change. Update it.
I have not heard from Dom ever so I think the best option is to
On 2017年04月17日 07:19, Michael S. Tsirkin wrote:
Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.
Add an API for that - assuming there's space. If there's no space
naturally we can't do this and have to drop entries, but
On 2017年04月17日 07:19, Michael S. Tsirkin wrote:
Applications that consume a batch of entries in one go
can benefit from ability to return some of them back
into the ring.
Add an API for that - assuming there's space. If there's no space
naturally we can't do this and have to drop entries, but
Hi all,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/block/nbd.c: In function 'nbd_genl_connect':
drivers/block/nbd.c:1662:10: error: too few arguments to function
'nla_parse_nested'
ret = nla_parse_nested(socks, NBD_SOCK_MAX,
Hi all,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/block/nbd.c: In function 'nbd_genl_connect':
drivers/block/nbd.c:1662:10: error: too few arguments to function
'nla_parse_nested'
ret = nla_parse_nested(socks, NBD_SOCK_MAX,
On Mon, Apr 17, 2017 at 03:32:20PM -0600, Alex Williamson wrote:
> On Tue, 18 Apr 2017 01:02:12 +0530
> Kirti Wankhede wrote:
>
> > On 4/18/2017 12:49 AM, Alex Williamson wrote:
> > > On Tue, 18 Apr 2017 00:35:06 +0530
> > > Kirti Wankhede wrote:
> >
On Mon, Apr 17, 2017 at 03:32:20PM -0600, Alex Williamson wrote:
> On Tue, 18 Apr 2017 01:02:12 +0530
> Kirti Wankhede wrote:
>
> > On 4/18/2017 12:49 AM, Alex Williamson wrote:
> > > On Tue, 18 Apr 2017 00:35:06 +0530
> > > Kirti Wankhede wrote:
> > >
> > >> On 4/17/2017 8:02 PM, Alex
On 17/04/17 03:43 PM, Ilia Mirkin wrote:
> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
>>> However, I totally agree with Alex that someone with a BE machine
>>> should review the whole stack before we could be confident with anything.
>>
>> Here's what I'm confident
On 17/04/17 03:43 PM, Ilia Mirkin wrote:
> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
>>> However, I totally agree with Alex that someone with a BE machine
>>> should review the whole stack before we could be confident with anything.
>>
>> Here's what I'm confident about:
There is an argument for using these #pragmas for pr_fmt.
gcc/clang/icc all support push_macro and pop_macro pragmas.
As far as I can tell, these compilers are the only ones
used to compile
the kernel.
Anyone have any objection to using these pragmas?
On Tue, 2017-04-18 at 05:02 +0800, kbuild
There is an argument for using these #pragmas for pr_fmt.
gcc/clang/icc all support push_macro and pop_macro pragmas.
As far as I can tell, these compilers are the only ones
used to compile
the kernel.
Anyone have any objection to using these pragmas?
On Tue, 2017-04-18 at 05:02 +0800, kbuild
On Tue, Apr 18, 2017 at 10:53:10AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (04/18/17 08:53), Minchan Kim wrote:
> > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote:
> > > Hello Minchan,
> > >
> > > On (04/17/17 11:14), Minchan Kim wrote:
> > > > On Mon, Apr 17, 2017
On Tue, Apr 18, 2017 at 10:53:10AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (04/18/17 08:53), Minchan Kim wrote:
> > On Mon, Apr 17, 2017 at 07:50:16PM +0900, Sergey Senozhatsky wrote:
> > > Hello Minchan,
> > >
> > > On (04/17/17 11:14), Minchan Kim wrote:
> > > > On Mon, Apr 17, 2017
1 - 100 of 1040 matches
Mail list logo