RE:Manufacturer of bags

Dear purchasing manager, We have rich experience in manufacturing and exporting all kinds of bags, We have our own production base with advanced machine equipment, and employ professional workforce of technicians and engineers. Our products range from tote bags, drawstring bags, luggage bags,

RE:Manufacturer of bags

Dear purchasing manager, We have rich experience in manufacturing and exporting all kinds of bags, We have our own production base with advanced machine equipment, and employ professional workforce of technicians and engineers. Our products range from tote bags, drawstring bags, luggage bags,

Re: [RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

On Tue, May 3, 2016 at 9:00 AM, Baolin Wang wrote: > Integrate with the newly added USB charger interface to limit the current > we draw from the USB input based on the input device configuration > identified by the USB stack, allowing us to charge more quickly from high >

Re: [RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

On Tue, May 3, 2016 at 9:00 AM, Baolin Wang wrote: > Integrate with the newly added USB charger interface to limit the current > we draw from the USB input based on the input device configuration > identified by the USB stack, allowing us to charge more quickly from high > current inputs without

Re: [RESEND PATCH]nbd: fix might_sleep warning on socket shutdown

On Tue, May 3, 2016 at 5:45 AM, Greg KH wrote: > On Mon, May 02, 2016 at 08:58:34AM +0530, Pranay Srivastava wrote: >> Hi, >> >> Can the following patch be reviewed? I'm working on some more changes >> on top of this change, >> so it'll be really helpful if someone can

[RFC][RFP] LPC2016 Thermal MC

Linux-pm, As a continuation of the work done in 2015, I am proposing this year a micro conference (MC) to gather thermal interested parties to discuss improvements to the thermal subsystem [1]. Last year, I believe it was a success in terms of achieving the goal of creating awareness, however, I

Re: [RESEND PATCH]nbd: fix might_sleep warning on socket shutdown

On Tue, May 3, 2016 at 5:45 AM, Greg KH wrote: > On Mon, May 02, 2016 at 08:58:34AM +0530, Pranay Srivastava wrote: >> Hi, >> >> Can the following patch be reviewed? I'm working on some more changes >> on top of this change, >> so it'll be really helpful if someone can review this patch and let

[RFC][RFP] LPC2016 Thermal MC

Linux-pm, As a continuation of the work done in 2015, I am proposing this year a micro conference (MC) to gather thermal interested parties to discuss improvements to the thermal subsystem [1]. Last year, I believe it was a success in terms of achieving the goal of creating awareness, however, I

Re: Strange I/O slowdown with 4.x kernels

On Fri, Apr 29, 2016 at 9:36 PM, Rus wrote: > Hi, > > After switching from 3.x to 4.x I'm observing strange filesystem (ext4 > used) slowdown just after fresh boot - it is 100% reproducible. The > simple test just after boot at root fs first shows the good > performance : > >

Re: Strange I/O slowdown with 4.x kernels

On Fri, Apr 29, 2016 at 9:36 PM, Rus wrote: > Hi, > > After switching from 3.x to 4.x I'm observing strange filesystem (ext4 > used) slowdown just after fresh boot - it is 100% reproducible. The > simple test just after boot at root fs first shows the good > performance : > > dd if=/dev/zero

[PATCH] kvm: robustify steal time record

From: Wanpeng Li Guest should only trust data to be valid when version haven't changed before and after reads of steal time. Besides not changing, it has to be an even number. Hypervisor may write an odd number to version field to indicate that an update is in

[PATCH] kvm: robustify steal time record

From: Wanpeng Li Guest should only trust data to be valid when version haven't changed before and after reads of steal time. Besides not changing, it has to be an even number. Hypervisor may write an odd number to version field to indicate that an update is in progress. kvm_steal_clock() in

Re: [PATCH v10 1/3] gpio: dwapb: remove name from dwapb_port_property

在 4/29/2016 5:22 PM, Linus Walleij 写道: > On Thu, Apr 28, 2016 at 11:32 AM, Jiang Qiu wrote: > >> This patch removed the name property from dwapb_port_property. >> The name property is redundant, since we can get this info >> from dwapb_gpio dev node. >> >> Reviewed-by: Andy

Re: [PATCH v10 1/3] gpio: dwapb: remove name from dwapb_port_property

在 4/29/2016 5:22 PM, Linus Walleij 写道: > On Thu, Apr 28, 2016 at 11:32 AM, Jiang Qiu wrote: > >> This patch removed the name property from dwapb_port_property. >> The name property is redundant, since we can get this info >> from dwapb_gpio dev node. >> >> Reviewed-by: Andy Shevchenko >>

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

Hi, On Thu, Apr 28, 2016 at 3:19 PM, Olliver Schinagl wrote: > There are 3 kinds of OLinuXino Lime2 boards. > One without any on board storage, one with NAND storage and one with > eMMC storage. This patch adds the eMMC variant of boards. > > eMMC storage is different from a

Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

Hi, On Thu, Apr 28, 2016 at 3:19 PM, Olliver Schinagl wrote: > There are 3 kinds of OLinuXino Lime2 boards. > One without any on board storage, one with NAND storage and one with > eMMC storage. This patch adds the eMMC variant of boards. > > eMMC storage is different from a regular SD card in

Re: [PATCH] Make clocksource insert entry more efficiently

On 05/02/16 at 10:39P, John Stultz wrote: > On Mon, Apr 25, 2016 at 2:20 AM, Minfei Huang wrote: > > It is unnecessary to continue looping the list, if we find there is an > > entry that the value of rating is smaller than the new one. It is safe > > to be out the loop, because

Re: [PATCH] Make clocksource insert entry more efficiently

On 05/02/16 at 10:39P, John Stultz wrote: > On Mon, Apr 25, 2016 at 2:20 AM, Minfei Huang wrote: > > It is unnecessary to continue looping the list, if we find there is an > > entry that the value of rating is smaller than the new one. It is safe > > to be out the loop, because all of entry are

[RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

[RESEND PATCH v10 2/4] gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. It will report to the usb charger when the gadget state is changed, then the usb charger can do the power things. Signed-off-by: Baolin Wang

[RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

[RESEND PATCH v10 2/4] gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. It will report to the usb charger when the gadget state is changed, then the usb charger can do the power things. Signed-off-by: Baolin Wang ---

[RESEND PATCH v10 1/4] gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

[RESEND PATCH v10 1/4] gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

[RESEND PATCH v10 3/4] gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger can implement the usb_charger_plug_by_gadget() function and usb_charger_exit() function by getting 'struct usb_charger' from 'struct gadget'. Signed-off-by: Baolin Wang ---

[RESEND PATCH v10 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

[RESEND PATCH v10 3/4] gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger can implement the usb_charger_plug_by_gadget() function and usb_charger_exit() function by getting 'struct usb_charger' from 'struct gadget'. Signed-off-by: Baolin Wang --- drivers/usb/gadget/udc/charger.c | 39

[RESEND PATCH v10 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

linux-next: manual merge of the drm-msm tree with the drm-misc tree

Hi Rob, Today's linux-next merge of the drm-msm tree got a conflict in: drivers/gpu/drm/msm/msm_atomic.c between commit: a3ccfb9feb46 ("drm/msm: Rename async to nonblock.") from the drm-misc tree and commit: afadc4bb9380 ("drm/msm: remove fence_cbs") from the drm-msm tree. I fixed it

linux-next: manual merge of the drm-msm tree with the drm-misc tree

Hi Rob, Today's linux-next merge of the drm-msm tree got a conflict in: drivers/gpu/drm/msm/msm_atomic.c between commit: a3ccfb9feb46 ("drm/msm: Rename async to nonblock.") from the drm-misc tree and commit: afadc4bb9380 ("drm/msm: remove fence_cbs") from the drm-msm tree. I fixed it

linux-next: manual merge of the drm-misc tree with the drm-intel tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commits: f7e5838bb37d ("drm/i915: Simplify reset_counter handling during atomic modesetting") from the drm-intel tree and commit: 81072bfd13f2 ("drm/i915: Rename async

linux-next: manual merge of the drm-misc tree with the drm-intel tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commits: f7e5838bb37d ("drm/i915: Simplify reset_counter handling during atomic modesetting") from the drm-intel tree and commit: 81072bfd13f2 ("drm/i915: Rename async

Re: [PATCH v2 06/13] staging/android: remove name arg from sync_file_create()

> > I think we we will just remove the name arg from the ioctl there. > SW_SYNC ioctl is only for debugging test, we don't want to publicly > export its ABI in the kernel uapi headers. > JFYI, be mindful please of removing the arg. If current uses are broken, the mainline maintainer, MM, can be

Re: [PATCH v2 06/13] staging/android: remove name arg from sync_file_create()

> > I think we we will just remove the name arg from the ioctl there. > SW_SYNC ioctl is only for debugging test, we don't want to publicly > export its ABI in the kernel uapi headers. > JFYI, be mindful please of removing the arg. If current uses are broken, the mainline maintainer, MM, can be

[PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

From: "Du, Changbin" On most platforms, there is only one device controller available. In this case, we desn't care the UDC's name. So let's ignore the name by setting 'UDC' to 'any'. And also we can change UDC name at any time if it is not binded (no need set to ""

[PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

From: "Du, Changbin" On most platforms, there is only one device controller available. In this case, we desn't care the UDC's name. So let's ignore the name by setting 'UDC' to 'any'. And also we can change UDC name at any time if it is not binded (no need set to "" first). Signed-off-by: Du,

[PATCH 0/2] Add binding rule *any* support for USB Gadget Configfs

From: "Du, Changbin" When I am configuring Gadget Configfs, I need found a exactly UDC name before I can start my gadget. But, really I doesn't care about which UDC name is used, because I have only controller. "any" is a good option. Du, Changbin (2): usb: configfs:

[PATCH 2/2] Documentation: gadget_configfs: update UDC binding

From: "Du, Changbin" Add the usage of new binding mode 'any'. $ echo any > UDC Signed-off-by: Du, Changbin Signed-off-by: Du, Changbin --- Documentation/usb/gadget_configfs.txt | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH 0/2] Add binding rule *any* support for USB Gadget Configfs

From: "Du, Changbin" When I am configuring Gadget Configfs, I need found a exactly UDC name before I can start my gadget. But, really I doesn't care about which UDC name is used, because I have only controller. "any" is a good option. Du, Changbin (2): usb: configfs: allow UDC binding rule

[PATCH 2/2] Documentation: gadget_configfs: update UDC binding

From: "Du, Changbin" Add the usage of new binding mode 'any'. $ echo any > UDC Signed-off-by: Du, Changbin Signed-off-by: Du, Changbin --- Documentation/usb/gadget_configfs.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/usb/gadget_configfs.txt

linux-next: manual merge of the net-next tree with Linus' tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/ipv4/ip_gre.c between commits: 2090714e1d6e ("gre: build header correctly for collect metadata tunnels") b7f8fe251e46 ("gre: do not pull header in ICMP error processing") from Linus' tree and commit:

linux-next: manual merge of the net-next tree with Linus' tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/ipv4/ip_gre.c between commits: 2090714e1d6e ("gre: build header correctly for collect metadata tunnels") b7f8fe251e46 ("gre: do not pull header in ICMP error processing") from Linus' tree and commit:

Re: [PATCH 1/2] : Make hash_64(), hash_ptr() return 32 bits

On Mon, May 2, 2016 at 6:59 PM, George Spelvin wrote: > > AFAICT, none of the string-hash functions outside of fs/ are > on particularly hot paths. The goal is deleting redundant code. Yes, agreed. >> We'll never get rid of "hash_name()", it not only has that '/' case, >>

Re: [PATCH 1/2] : Make hash_64(), hash_ptr() return 32 bits

On Mon, May 2, 2016 at 6:59 PM, George Spelvin wrote: > > AFAICT, none of the string-hash functions outside of fs/ are > on particularly hot paths. The goal is deleting redundant code. Yes, agreed. >> We'll never get rid of "hash_name()", it not only has that '/' case, >> it's also inlined for

RE: [PATCH] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Yongji Xie > Sent: Wednesday, April 27, 2016 8:22 PM > > Current vfio-pci implementation disallows to mmap > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > page may be shared with other BARs. This will cause some > performance issues when we passthrough a PCI device with

RE: [PATCH] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

> From: Yongji Xie > Sent: Wednesday, April 27, 2016 8:22 PM > > Current vfio-pci implementation disallows to mmap > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > page may be shared with other BARs. This will cause some > performance issues when we passthrough a PCI device with

Re: [PATCH] vhost_net: stop polling socket during rx processing

On 04/28/2016 02:19 PM, Jason Wang wrote: > On 04/27/2016 07:28 PM, Michael S. Tsirkin wrote: >> > On Tue, Apr 26, 2016 at 03:35:53AM -0400, Jason Wang wrote: >>> >> We don't stop polling socket during rx processing, this will lead >>> >> unnecessary wakeups from under layer net devices (E.g >>>

Re: [PATCH] vhost_net: stop polling socket during rx processing

On 04/28/2016 02:19 PM, Jason Wang wrote: > On 04/27/2016 07:28 PM, Michael S. Tsirkin wrote: >> > On Tue, Apr 26, 2016 at 03:35:53AM -0400, Jason Wang wrote: >>> >> We don't stop polling socket during rx processing, this will lead >>> >> unnecessary wakeups from under layer net devices (E.g >>>

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

On Tue, May 03, 2016 at 01:26:46AM +, Rudoff, Andy wrote: > > >> The takeaway is that msync() is 9-10x slower than userspace cache > >> management. > > > >An alternative viewpoint: that flushing clean cachelines is > >extremely expensive on Intel CPUs. ;) > > > >i.e. Same numbers, different

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

On Tue, May 03, 2016 at 01:26:46AM +, Rudoff, Andy wrote: > > >> The takeaway is that msync() is 9-10x slower than userspace cache > >> management. > > > >An alternative viewpoint: that flushing clean cachelines is > >extremely expensive on Intel CPUs. ;) > > > >i.e. Same numbers, different

Re: [PATCH] tracing: Don't display trigger file for events that don't have register func

On Mon, 2 May 2016 22:14:14 +0800 Chunyu Hu wrote: > Currently register function of the event will be called > through the 'reg' field of event class directly without > any check when seting up triggers. > > Triggers for events that don't support register through > debug fs

Re: [PATCH] tracing: Don't display trigger file for events that don't have register func

On Mon, 2 May 2016 22:14:14 +0800 Chunyu Hu wrote: > Currently register function of the event will be called > through the 'reg' field of event class directly without > any check when seting up triggers. > > Triggers for events that don't support register through > debug fs (events under

Re: Watchdog reset trigger for eMMC

Hi Marek On 2 May 2016 at 11:57, Marek Szyprowski wrote: > Hi Anand > > > On 2016-04-30 08:06, Anand Moon wrote: >> >> Hi All, >> >> Using microSD card when I try to write into /dev/watchdog device >> it triggers reboot of the board after timer expires. >> >>

Re: Watchdog reset trigger for eMMC

Hi Marek On 2 May 2016 at 11:57, Marek Szyprowski wrote: > Hi Anand > > > On 2016-04-30 08:06, Anand Moon wrote: >> >> Hi All, >> >> Using microSD card when I try to write into /dev/watchdog device >> it triggers reboot of the board after timer expires. >> >>

Re: [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller

在 2016年04月28日 23:04, Eduardo Valentin 写道: On Thu, Apr 28, 2016 at 09:50:29AM +0800, Caesar Wang wrote: 在 2016年04月28日 07:48, Eduardo Valentin 写道: On Mon, Apr 18, 2016 at 11:35:56AM +0800, Caesar Wang wrote: + regmap_write(grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_TSEN_PD_ON); +

Re: [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller

在 2016年04月28日 23:04, Eduardo Valentin 写道: On Thu, Apr 28, 2016 at 09:50:29AM +0800, Caesar Wang wrote: 在 2016年04月28日 07:48, Eduardo Valentin 写道: On Mon, Apr 18, 2016 at 11:35:56AM +0800, Caesar Wang wrote: + regmap_write(grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_TSEN_PD_ON); +

Re: [PATCH 2/2] zram: user per-cpu compression streams

On (05/03/16 11:20), Minchan Kim wrote: [..] > We are concerning about returing back to no per-cpu options but actually, > I don't want. If duplicate compression is really problem(But It's really > unlikely), we should try to solve the problem itself with different way > rather than roll-back to

Re: [PATCH 2/2] zram: user per-cpu compression streams

On (05/03/16 11:20), Minchan Kim wrote: [..] > We are concerning about returing back to no per-cpu options but actually, > I don't want. If duplicate compression is really problem(But It's really > unlikely), we should try to solve the problem itself with different way > rather than roll-back to

Re: [PATCH v2] cgroup: allow management of subtrees by new cgroup namespaces

On Tue, 2016-05-03 at 11:59 +1000, Aleksa Sarai wrote: > > > Change the mode of the cgroup directory for each cgroup > > > association, > > > allowing the process to create subtrees and modify the limits of > > > the > > > subtrees *without* allowing the process to modify its own limits. > > > Due

Re: [PATCH v2] cgroup: allow management of subtrees by new cgroup namespaces

On Tue, 2016-05-03 at 11:59 +1000, Aleksa Sarai wrote: > > > Change the mode of the cgroup directory for each cgroup > > > association, > > > allowing the process to create subtrees and modify the limits of > > > the > > > subtrees *without* allowing the process to modify its own limits. > > > Due

[PATCH] thermal: rockchip: use the usleep_range instead of udelay

Documentation/timers/timers-howto.txt recommends to use usleep_range on delays > 10usec. The usleep_range indeed reduces CPU load, since the udelay will busy wait for enough loop cycles to achieve the desired delay. Fixes commit b06c52db39fd ("thermal: rockchip: handle the power sequence for

[PATCH] thermal: rockchip: use the usleep_range instead of udelay

Documentation/timers/timers-howto.txt recommends to use usleep_range on delays > 10usec. The usleep_range indeed reduces CPU load, since the udelay will busy wait for enough loop cycles to achieve the desired delay. Fixes commit b06c52db39fd ("thermal: rockchip: handle the power sequence for

[PATCH] fbdev: fbmem: implement error handling in fbmem_init()

fbmem_init() ignores all errors, while fbmem_exit() does not check if deallocating resources are valid. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/video/fbdev/core/fbmem.c | 20 +--- 1 file

[PATCH] fbdev: fbmem: implement error handling in fbmem_init()

fbmem_init() ignores all errors, while fbmem_exit() does not check if deallocating resources are valid. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/video/fbdev/core/fbmem.c | 20 +--- 1 file changed, 17

Re: [PATCH 2/2] zram: user per-cpu compression streams

Hi Sergey! On Tue, May 03, 2016 at 10:53:33AM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > On (05/03/16 10:40), Minchan Kim wrote: > > > > > > ...hm... inc ->failed_writes? > [..] > > Okay, let's add the knob to the existing sysfs(There is no different > > between sysfs and debugfs

Re: [PATCH 2/2] zram: user per-cpu compression streams

Hi Sergey! On Tue, May 03, 2016 at 10:53:33AM +0900, Sergey Senozhatsky wrote: > Hello Minchan, > > On (05/03/16 10:40), Minchan Kim wrote: > > > > > > ...hm... inc ->failed_writes? > [..] > > Okay, let's add the knob to the existing sysfs(There is no different > > between sysfs and debugfs

Re: Fwd: [PATCH v2 0/8] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

Dear Myungjoo, On 2016년 05월 02일 14:48, MyungJoo Ham wrote: > Sender : 최찬우 S5(책임)/Change Agent/Tizen Platform > Lab(S/W센터)/삼성전자 > Date : 2016-04-15 15:32 (GMT+09:00) >> >> This patchset support the AMBA bus frequency scaling on Exynos5422-based >> Odroid-XU3 board. But,

Re: [PATCH] mm/zsmalloc: don't fail if can't create debugfs info

Hello, Dan: 2016-04-28 23:36 GMT+08:00 Dan Streetman : > Change the return type of zs_pool_stat_create() to void, and > remove the logic to abort pool creation if the stat debugfs > dir/file could not be created. > > The debugfs stat file is for debugging/information only, and

Re: Fwd: [PATCH v2 0/8] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

Dear Myungjoo, On 2016년 05월 02일 14:48, MyungJoo Ham wrote: > Sender : 최찬우 S5(책임)/Change Agent/Tizen Platform > Lab(S/W센터)/삼성전자 > Date : 2016-04-15 15:32 (GMT+09:00) >> >> This patchset support the AMBA bus frequency scaling on Exynos5422-based >> Odroid-XU3 board. But, this series only support

Re: [PATCH] mm/zsmalloc: don't fail if can't create debugfs info

Hello, Dan: 2016-04-28 23:36 GMT+08:00 Dan Streetman : > Change the return type of zs_pool_stat_create() to void, and > remove the logic to abort pool creation if the stat debugfs > dir/file could not be created. > > The debugfs stat file is for debugging/information only, and doesn't > affect

Re: mainline build: 896 warnings 1 failures (mainline/v4.6-rc5-224-gda9373d)

On Mon, May 2, 2016 at 12:24 AM, Arnd Bergmann wrote: > On Sunday 01 May 2016 16:19:53 Olof Johansson wrote: >> On Sun, May 1, 2016 at 2:26 PM, Olof's autobuilder wrote: >> > Here are the build results from automated periodic testing. >> > >> > The tree being

Re: mainline build: 896 warnings 1 failures (mainline/v4.6-rc5-224-gda9373d)

On Mon, May 2, 2016 at 12:24 AM, Arnd Bergmann wrote: > On Sunday 01 May 2016 16:19:53 Olof Johansson wrote: >> On Sun, May 1, 2016 at 2:26 PM, Olof's autobuilder wrote: >> > Here are the build results from automated periodic testing. >> > >> > The tree being built was mainline, found at: >> >

Re: [PATCH v7 1/6] Shared library support

Hi Emese, 2016-05-03 2:56 GMT+09:00 Emese Revfy : > On Mon, 2 May 2016 14:03:00 +0900 > Masahiro Yamada wrote: > >> In the first place, >> I am wondering if we need to revive this documentation. >> What this commit is only interested in *.so

Re: [PATCH v7 1/6] Shared library support

Hi Emese, 2016-05-03 2:56 GMT+09:00 Emese Revfy : > On Mon, 2 May 2016 14:03:00 +0900 > Masahiro Yamada wrote: > >> In the first place, >> I am wondering if we need to revive this documentation. >> What this commit is only interested in *.so generation, >> not host program support. > > I agree

[PATCH 3.14 10/37] crypto: gcm - Fix rfc4543 decryption crash

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Herbert Xu This bug has already bee fixed upstream since 4.2. However, it was fixed during the AEAD conversion so no fix was backported to the older kernels.

[PATCH 3.14 15/37] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Javier Martinez Canillas commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream. The exynos5 I2C controller driver always prepares and enables a clock before using

Re: [PATCH v7 1/6] Shared library support

Hi Emese, 2016-05-03 2:56 GMT+09:00 Emese Revfy : > On Mon, 2 May 2016 14:03:00 +0900 > Masahiro Yamada wrote: > >> In the first place, >> I am wondering if we need to revive this documentation. >> What this commit is only interested in *.so

[PATCH 3.14 10/37] crypto: gcm - Fix rfc4543 decryption crash

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Herbert Xu This bug has already bee fixed upstream since 4.2. However, it was fixed during the AEAD conversion so no fix was backported to the older kernels. When we do an RFC 4543

[PATCH 3.14 15/37] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Javier Martinez Canillas commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream. The exynos5 I2C controller driver always prepares and enables a clock before using it and then disables

Re: [PATCH v7 1/6] Shared library support

Hi Emese, 2016-05-03 2:56 GMT+09:00 Emese Revfy : > On Mon, 2 May 2016 14:03:00 +0900 > Masahiro Yamada wrote: > >> In the first place, >> I am wondering if we need to revive this documentation. >> What this commit is only interested in *.so generation, >> not host program support. > > I agree

[PATCH 3.14 13/37] pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Keerthy commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe upstream. pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices ranging from 1 to MAX. This leads to a

[PATCH 3.14 14/37] i2c: cpm: Fix build break due to incompatible pointer types

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Michael Ellerman commit 609d5a1b2b35bb62b4b3750396e55453160c2a17 upstream. Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible pointer check into error"),

[PATCH 3.14 13/37] pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Keerthy commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe upstream. pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices ranging from 1 to MAX. This leads to a corner case where we

[PATCH 3.14 14/37] i2c: cpm: Fix build break due to incompatible pointer types

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Michael Ellerman commit 609d5a1b2b35bb62b4b3750396e55453160c2a17 upstream. Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible pointer check into error"), assignments from an

[PATCH 3.14 12/37] Input: gtco - fix crash on detecting device without endpoints

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Vladis Dronov commit 162f98dea487206d9ab79fc12ed64700667a894d upstream. The gtco driver expects at least one valid endpoint. If given malicious descriptors that specify 0

[PATCH 3.14 12/37] Input: gtco - fix crash on detecting device without endpoints

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Vladis Dronov commit 162f98dea487206d9ab79fc12ed64700667a894d upstream. The gtco driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of

Re: [PATCH 1/2] : Make hash_64(), hash_ptr() return 32 bits

> Right. But there is no reason to think that that should be the same > thing as the final hash. Your logic is absolutely correct. I agree with you. The two operations have different purposes, and should be thought of differently. HOWEVER, if you can find one operation which is good enough to

Re: [PATCH 1/2] : Make hash_64(), hash_ptr() return 32 bits

> Right. But there is no reason to think that that should be the same > thing as the final hash. Your logic is absolutely correct. I agree with you. The two operations have different purposes, and should be thought of differently. HOWEVER, if you can find one operation which is good enough to

[PATCH 3.14 16/37] EDAC: i7core, sb_edac: Dont return NOTIFY_BAD from mce_decoder callback

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Tony Luck commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream. Both of these drivers can return NOTIFY_BAD, but this terminates processing other callbacks that were

[PATCH 3.14 16/37] EDAC: i7core, sb_edac: Dont return NOTIFY_BAD from mce_decoder callback

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Tony Luck commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream. Both of these drivers can return NOTIFY_BAD, but this terminates processing other callbacks that were registered later on

Re: [PATCH v2] cgroup: allow management of subtrees by new cgroup namespaces

Change the mode of the cgroup directory for each cgroup association, allowing the process to create subtrees and modify the limits of the subtrees *without* allowing the process to modify its own limits. Due to the cgroup core restrictions and unix permission model, this allows for processes to

Re: [PATCH v2] cgroup: allow management of subtrees by new cgroup namespaces

Change the mode of the cgroup directory for each cgroup association, allowing the process to create subtrees and modify the limits of the subtrees *without* allowing the process to modify its own limits. Due to the cgroup core restrictions and unix permission model, this allows for processes to

[PATCH 3.14 17/37] ASoC: s3c24xx: use const snd_soc_component_driver pointer

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit ba4bc32eaa39ba7687f0958ae90eec94da613b46 upstream. An older patch to convert the API in the s3c i2s driver ended up passing a const pointer into a function

[PATCH 3.14 17/37] ASoC: s3c24xx: use const snd_soc_component_driver pointer

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit ba4bc32eaa39ba7687f0958ae90eec94da613b46 upstream. An older patch to convert the API in the s3c i2s driver ended up passing a const pointer into a function that takes a

[PATCH 3.14 02/37] assoc_array: dont call compare_object() on a node

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jerome Marchand commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream. Changes since V1: fixed the description and added KASan warning. In

[PATCH 3.14 00/37] 3.14.68-stable review

This is the start of the stable review cycle for the 3.14.68 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu May 5 00:04:10 UTC 2016. Anything

[PATCH 3.14 02/37] assoc_array: dont call compare_object() on a node

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jerome Marchand commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream. Changes since V1: fixed the description and added KASan warning. In assoc_array_insert_into_terminal_node(), we call

[PATCH 3.14 00/37] 3.14.68-stable review

This is the start of the stable review cycle for the 3.14.68 release. There are 37 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu May 5 00:04:10 UTC 2016. Anything

Re: [PATCH V2 2/7] PM / OPP: Mark cpumask as const in dev_pm_opp_set_sharing_cpus()

On 02-05-16, 17:43, Stephen Boyd wrote: > On 04/27, Viresh Kumar wrote: > > dev_pm_opp_set_sharing_cpus() isn't supposed to update the cpumask > > passed as its parameter, and so it should always have been marked > > 'const'. > > > > Do it now. > > > > Signed-off-by: Viresh Kumar

[PATCH 3.14 21/37] USB: usbip: fix potential out-of-bounds write

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Ignat Korchagin commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream. Fix potential out-of-bounds write to urb->transfer_buffer usbip handles network

<    1   2   3   4   5   6   7   8   9   10   >