Hi Milan,
On 27 May 2016 at 14:31, Milan Broz wrote:
> On 05/25/2016 08:12 AM, Baolin Wang wrote:
>> Now some cipher hardware engines prefer to handle bulk block rather than one
>> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
>> the intermediate values (IV) by the
On 2016/5/27 12:20, Rob Herring wrote:
> On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown)
> wrote:
>>
>>
>> On 2016/5/26 21:13, Rob Herring wrote:
>>> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote:
For a normal memory@ devicetree node, its reg property can contains more
>>
On Fri 27-05-16 08:45:10, Michal Hocko wrote:
[...]
> It is still an operation which is not needed for 99% of situations. So
> if we do not need it for correctness then I do not think this is worth
> bothering.
Since you have pointed out exit_mm vs. __exit_signal race yesterday I
was thinking how
Linux userspace (systemd-logind) keeps on rechecking lid state when the
lid state is closed. If it failed to update the lid state to open after
boot/resume, the system suspending right after the boot/resume could be
resulted.
Graphics drivers also uses the lid notifications to implment
MODESET_ON_L
The _LID control method's initial returning value is not reliable.
The _LID control method is described to return the "current" lid state.
However the word of "current" has ambiguity, many BIOSen return the lid
state upon the last lid notification instead of returning the lid state
upon the last _
This patch simplies the code by merging the redundant code. No functional
changes.
Signed-off-by: Lv Zheng
---
drivers/acpi/button.c | 92 +++--
1 file changed, 50 insertions(+), 42 deletions(-)
diff --git a/drivers/acpi/button.c b/drivers/acpi/butt
The initial _LID returning value is not reliable after boot/resume because
the BIOS vendors may implement it by returning a cached value that is only
updated when a lid notification is received.
This causes strange things happening after resuming. This patchset fixes
the issue according to this fac
Root in a user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so, then any
unprivileged user on the host could map his own uid to root in a
namespace, write the xattr, and execute the file with privilege on the
host.
This patch introduces v3 of the
hi
在 2016/5/27 1:42, Jiri Olsa 写道:
On Tue, May 24, 2016 at 09:20:27AM +, He Kuang wrote:
Use thread specific unwind ops to unwind cross-platform callchains.
Currently, unwind methods is suitable for local unwind, this patch
changes the fixed methods to thread/map related. Each time a map i
On 05/26/2016 03:20 PM, Rob Herring wrote:
On Thu, May 26, 2016 at 8:05 AM, loic pallardy wrote:
On 05/26/2016 02:46 PM, Rob Herring wrote:
On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez
wrote:
On 25 May 2016 at 19:24, Rob Herring wrote:
On Wed, May 18, 2016 at 10:41:23AM +0200
On Fri, May 27, 2016 at 02:42:18PM +0800, Joonsoo Kim wrote:
> On Fri, May 27, 2016 at 02:25:27PM +0800, Feng Tang wrote:
> > On Fri, May 27, 2016 at 01:28:20PM +0800, Joonsoo Kim wrote:
> > > On Thu, May 26, 2016 at 04:04:54PM +0800, Feng Tang wrote:
> > > > On Thu, May 26, 2016 at 02:22:22PM +080
Hi CK,
On Mon, 2016-05-23 at 17:09 +0800, CK Hu wrote:
> Hi, YT:
>
> Some comments below.
>
> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote:
> > From: YT Shen
> >
> > This patch add support for the Mediatek MT2701 DISP subsystem.
> > There is only one OVL engine in MT2701.
> >
> >
> >> +
> >> +static int rockchip_pcie_rd_other_conf(struct rockchip_pcie_port *pp,
> >> + struct pci_bus *bus, u32 devfn,
> >> + int where, int size, u32 *val)
> >> +{
> >> + u32 busdev;
> >> +
> >> + busdev = PCIE_ECAM_ADDR(bus-
On Wed, May 25, 2016 at 07:59:57AM -0700, Guenter Roeck wrote:
> On Wed, May 25, 2016 at 04:20:56PM +0200, Oliver Neukum wrote:
> > On Wed, 2016-05-25 at 17:04 +0300, Heikki Krogerus wrote:
> >
> > > I'm not against leaving the responsibility of registering the alternate
> > > modes to the drivers
On Wed, May 25, 2016 at 08:19:47AM -0700, Guenter Roeck wrote:
> On Wed, May 25, 2016 at 02:28:46PM +0300, Heikki Krogerus wrote:
> > Hi,
> >
> > On Tue, May 24, 2016 at 02:51:40PM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > >
> > > Hi,
> > >
>
On (05/27/16 13:22), Minchan Kim wrote:
> On Wed, May 25, 2016 at 11:30:02PM +0900, Sergey Senozhatsky wrote:
> > We don't need to supply a zcomp pointer to compress/decompress
> > functions, drop it.
> >
> > Signed-off-by: Sergey Senozhatsky
> > Cc: Minchan Kim
> > Cc: Joonsoo Kim
>
> Could y
Hi CK,
On Mon, 2016-05-23 at 17:43 +0800, CK Hu wrote:
> Hi, YT:
>
> One comment below.
>
> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote:
> > From: YT Shen
> >
> > There are some hardware settings changed, between MT8173 & MT2701:
> > DISP_OVL address offset changed, color fo
Hi Brian,
On Thu, 26 May 2016 14:05:30 -0700
Brian Norris wrote:
> It doesn't make sense to allow the duty cycle to be larger than the
> period. I can see this behavior by, e.g.:
>
> # echo 1 > /sys/class/pwm/pwmchip0/export
> # cat /sys/class/pwm/pwmchip0/pwm1/period
> 100
> # echo 101
Hi,
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access
> bit width support
>
> On 05/26/2016 12:26 PM, Jan Beulich wrote:
> Boris Ostrovsky 05/25/16 9:17
> PM >>>
> >> On 05/05/2016 12:58 AM, Lv Zheng wrote:
> >
Hi Chris,
On 05/27/2016 02:02 PM, Chris Zhong wrote:
Hi all
This series patch is for rockchip Type-C phy and DisplayPort controller
driver.
The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in S
On Fri, May 27, 2016 at 03:13:04PM +0800, Hekuang wrote:
SNIP
> >- I understand we need to compile 3 objects from unwind-libunwind.c,
> > how about we create 3 files like:
> >
> > util/unwind-libunwind-local.c
> > util/unwind-libunwind-x86_32.c
> > util/unwind-libunwind-a
Hi Waiman,
On Thu, May 26, 2016 at 02:21:57PM -0400, Waiman Long wrote:
> Currently, calling pv_hash() and setting _Q_SLOW_VAL is only
> done once for any pv_node. It is either in pv_kick_node() or in
> pv_wait_head_or_lock(). Because of lock stealing, a pv_kick'ed node is
> not guaranteed to get
Because MCLK turns on later and turns off earlier than codec, this patch
changes the order of MCLK clock configuration.
Signed-off-by: PC Liao
---
Changes since v1:
update commit message
---
sound/soc/mediatek/mtk-afe-pcm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-
On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote:
> On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann
>
> So I entirely missed this, but this isn't really how to implement
> page_flip for an atomic driver. Working on some stuff and will hack up
> a likely
Hi,
> I guess I didn't do a good job at looking at your v2: Cursor is still
> using legacy interfaces and not a proper plane. Would be awesome if
> you could fix that up. Atomic drivers really shouldn't use the legacy
> cursor interfaces any more at all.
> -Daniel
Figured that one for the most
On Fri, May 27, 2016 at 09:46:03AM +0200, Gerd Hoffmann wrote:
> On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote:
> > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann wrote:
> > > Signed-off-by: Gerd Hoffmann
> >
> > So I entirely missed this, but this isn't really how to implement
> > page_f
On (05/27/16 13:43), Minchan Kim wrote:
[..]
> > modprobe zram
> > cat /proc/crypto | grep -i lz4
> > modprobe lz4
> > cat /proc/crypto | grep -i lz4
> > name : lz4
> > driver : lz4-generic
> > module : lz4
> >
> > So the user can't tell exactly if the lz4 is really support
On 05/27/2016 09:04 AM, Baolin Wang wrote:
> Hi Milan,
>
> On 27 May 2016 at 14:31, Milan Broz wrote:
>> On 05/25/2016 08:12 AM, Baolin Wang wrote:
>>> Now some cipher hardware engines prefer to handle bulk block rather than one
>>> sector (512 bytes) created by dm-crypt, cause these cipher engin
Hi,
On Wed, May 25, 2016 at 11:35:07AM -0700, Guenter Roeck wrote:
> From: Guenter Roeck
>
> New API functions (calls into class code)
> typec_set_usb_role()
> typec_set_pwr_role()
> typec_set_vconn_role()
> typec_set_pwr_opmode()
>
> Modified API functions (calls into c
Hello,
On 2016-05-25 16:38, Rob Herring wrote:
On Tue, May 24, 2016 at 11:29 PM, Jaewon Kim wrote:
From: Jaewon
There was an alignment mismatch issue for CMA and it was fixed by
commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with CMA
setup").
However the way of the
Currently khugepaged makes swapin readahead under
down_write. This patch supplies to make swapin
readahead under down_read instead of down_write.
The patch was tested with a test program that allocates
800MB of memory, writes to it, and then sleeps. The system
was forced to swap out all. Afterward
On 25 May 2016 at 06:35, David Daney wrote:
> From: David Daney
>
> As noted by Dennis Chen, we don't want to print "No NUMA configuration
> found" if NUMA was forced off from the command line.
>
> Change the type of numa_off to bool, and clean up printing code.
> Print "NUMA disabled" if forced
swapops.h included for a second time in the commit:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=639040960a340f6f987065fc52e149f4ea25ce25
This patch removes the duplication.
Signed-off-by: Ebru Akagunduz
---
Changes in v2:
- Nothing changed
mm/huge_memory.c | 1 -
Nested circular locking dependency detected by kernel robot (udevadm).
udevadm/221 is trying to acquire lock:
(&mm->mmap_sem){++}, at: [] __might_fault+0x83/0x150
but task is already holding lock:
(s_active#12){.+}, at: [] kernfs_fop_write+0x8e/0x250
which lock already depends
Pali Rohár wrote on 26.05.2016 17:51:
> On Thursday 26 May 2016 17:39:57 Thorsten Leemhuis wrote:
>> > I need to know if this patch fixes problem on Dell Studio XPS 8000
>> > and Dell Studio XPS 8100 machines, so we can revert git commits:
>> > 6220f4ebd7b4 ("hwmon: (dell-smm) Blacklist Dell Studio
On Thu, May 26, 2016 at 09:03:11AM +0800, Lu Baolu wrote:
> Hi Heikki,
>
> On 05/25/2016 07:06 PM, Heikki Krogerus wrote:
> > Hi Baolu,
> >
> > Sorry to comment this so late, but we got hardware that needs to
> > configure the mux in OS, and I noticed some problem.
>
> Comments are always welcome
On (05/27/16 13:31), Minchan Kim wrote:
[..]
> > int zcomp_compress(struct zcomp_strm *zstrm,
> > - const unsigned char *src, unsigned int *dst_len)
> > + const u8 *src, unsigned int *dst_len)
>
> Nitpick:
>
> The zcomp doesn't need to depend on implementation(i.e., crypto) s
The change to the oom_reaper to hold a mutex inside __oom_reap_task()
accidentally started calling mmput_async() on the local
mm before that variable got initialized, as reported by gcc
in linux-next:
mm/oom_kill.c: In function '__oom_reap_task':
mm/oom_kill.c:537:2: error: 'mm' may be used uninit
On (05/27/16 13:22), Minchan Kim wrote:
[..]
> > static void zcomp_strm_free(struct zcomp *comp, struct zcomp_strm *zstrm)
> > {
> > - if (zstrm->private)
> > - comp->backend->destroy(zstrm->private);
> > + if (!IS_ERR_OR_NULL(zstrm->private))
>
> Let's change private with tfm.
ok
This patch series removes duplication of included header
and fixes locking inconsistency in khugepaged swapin.
Ebru Akagunduz (3):
mm, thp: remove duplication of included header
mm, thp: fix possible circular locking dependency caused by
sum_vm_event()
mm, thp: make swapin readahead unde
On Fri 27-05-16 09:15:07, Michal Hocko wrote:
> On Fri 27-05-16 08:45:10, Michal Hocko wrote:
> [...]
> > It is still an operation which is not needed for 99% of situations. So
> > if we do not need it for correctness then I do not think this is worth
> > bothering.
>
> Since you have pointed out
On 25 May 2016 at 06:35, David Daney wrote:
> From: Hanjun Guo
>
> Introduce a new file to hold ACPI based NUMA information parsing from
> SRAT and SLIT.
>
> SRAT includes the CPU ACPI ID to Proximity Domain mappings and memory
> ranges to Proximity Domain mapping. SLIT has the information of in
在 2016/5/27 15:38, Jiri Olsa 写道:
On Fri, May 27, 2016 at 03:13:04PM +0800, Hekuang wrote:
SNIP
- I understand we need to compile 3 objects from unwind-libunwind.c,
how about we create 3 files like:
util/unwind-libunwind-local.c
util/unwind-libunwind-x86_32.c
util
Hi Chris,
On 05/27/2016 02:02 PM, Chris Zhong wrote:
Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
Type-C PHY is designed to support the USB3 and DP applications. The
PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can op
Hi,
On 05/27/2016 04:00 PM, Heikki Krogerus wrote:
>> I agree with you that we should move extcon out of the framework.
>> >
>> > In order to support multiport systems, I have below proposal.
>> >
>> > Currently, we have below interfaces.
>> >
>> > struct portmux_dev *portmux_register(struct po
On 21/04/2016 18:00, Laurent Dufour wrote:
> On 13/04/2016 07:14, Michael Ellerman wrote:
>> On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote:
>>> On 07/04/2016 23:49, Michael Ellerman wrote:
On 7 April 2016 7:23:46 pm AEST, Laurent Dufour
wrote:
> This series is required to
On Fri 27-05-16 10:00:48, Arnd Bergmann wrote:
> The change to the oom_reaper to hold a mutex inside __oom_reap_task()
> accidentally started calling mmput_async() on the local
> mm before that variable got initialized, as reported by gcc
> in linux-next:
>
> mm/oom_kill.c: In function '__oom_reap
On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrot
On Wed, May 25, 2016 at 02:06:17PM +0800, Ye Xiaolong wrote:
>On Mon, May 23, 2016 at 04:46:05PM -0400, Johannes Weiner wrote:
>>Hi,
>>
>>thanks for your report.
>>
>>On Tue, May 17, 2016 at 12:58:05PM +0800, kernel test robot wrote:
>>> FYI, we noticed vm-scalability.throughput -23.8% regression d
On Sun, May 22, 2016 at 6:39 PM, James Bottomley
wrote:
> On Tue, 2016-05-17 at 23:53 +0200, Miklos Szeredi wrote:
>> The two methods essentially do the same: find the real dentry/inode
>> belonging to an overlay dentry. The difference is in the usage:
>>
>> vfs_open() uses ->d_select_inode() and
Hi,
On 05/26/2016 06:29 PM, Sudeep Holla wrote:
> Hi Neil,
>
> On 26/05/16 10:38, Neil Armstrong wrote:
>> Since the current SCPI implementation, based on [0]:
>> - is (at leat) JUNO specific
>
> Agreed.
>
>> - does not specify a strong "standard"
>
> Not exactly, it's extensible. Refer section
On 25 May 2016 at 08:31, Sedat Dilek wrote:
> Hi Daniel,
>
> with latest Linus Git I see this with my Intel SandyBridge GPU...
>
> [ 17.629014] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
> [ 17.630652] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
On 05/26/2016 12:06 PM, Carlo Caione wrote:
> On 26/05/16 09:51, Neil Armstrong wrote:
>> Add watchdog specific driver for Amlogic Meson GXBB SoC.
>>
>> Signed-off-by: Neil Armstrong
>> +
>
> [...]
>> +#define DEFAULT_TIMEOUT 10 /* seconds */
>> +
>> +#define GXBB_WDT_CTRL_REG 0x0
>> +
From: Sascha Hauer
The .get_trend callback in struct thermal_zone_device_ops has
the prototype:
int (*get_trend) (struct thermal_zone_device *, int,
enum thermal_trend *);
whereas the .get_trend callback in struct thermal_zone_of_device_ops
has:
int (*get
The history patches come from Mikko and Sascha.
http://thread.gmane.org/gmane.linux.power-management.general/59451
Now, I pick them up to continue upstream.
Nevermind!
This series history patches:
v3: https://lkml.org/lkml/2016/5/24/797
v2: https://lkml.org/lkml/2016/5/3/220
v1: https://lkml.
Whenever the current temperature is updated, the trip points immediately
below and above the current temperature are found. A sensor driver
callback `set_trips' is then called with the temperatures.
Lastly, The sensor will trigger the hardware high temperature interrupts
to increase the sampleing r
From: Sascha Hauer
With interrupt driven thermal zones we pass the lower and upper
temperature on which shall be acted, so in the governor we have to act on
the exact lower temperature to be consistent. Otherwise an interrupt maybe
generated on the exact lower temperature, but the bang bang gover
On 05/26/2016 03:54 PM, Guenter Roeck wrote:
> On 05/26/2016 12:51 AM, Neil Armstrong wrote:
>> Add watchdog specific driver for Amlogic Meson GXBB SoC.
>>
>
> Wondering - why RFC ?
For these precious comments !
Thanks Guenter.
>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/watchdog/Ma
From: Sascha Hauer
This patch implements .set_trips for device tree thermal zones.
As the hardware-tracked trip points is supported by thermal core patch[0].
patch[0]
"thermal: Add support for hardware-tracked trip points".
Signed-off-by: Sascha Hauer
Signed-off-by: Caesar Wang
Cc: Zhang Rui
On Fri, May 27, 2016 at 04:50:52PM +0900, Sergey Senozhatsky wrote:
> On (05/27/16 13:43), Minchan Kim wrote:
> [..]
> > > modprobe zram
> > > cat /proc/crypto | grep -i lz4
> > > modprobe lz4
> > > cat /proc/crypto | grep -i lz4
> > > name : lz4
> > > driver : lz4-generic
> > > m
Hi Chris,
Am Freitag, 27. Mai 2016, 14:02:15 schrieb Chris Zhong:
> This patch adds a binding that describes the Rockchip USB Type-C PHY
> for rk3399.
>
> Signed-off-by: Chris Zhong
> ---
>
> .../devicetree/bindings/phy/phy-rockchip-typec.txt | 55
> ++ 1 file changed, 55 in
On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
>
> So if I understand correctly, the binding at the SoC level is fine.
> Keeping that but removing the additional made-up properties, viz. below
>
> rom-revision: phandle to the on-chip ROM node
> mscm: phandle to the MSCM
On Thu, 26 May 2016 16:19:26 +0200
Peter Zijlstra wrote:
> This patch updates/fixes all spin_unlock_wait() implementations.
>
> The update is in semantics; where it previously was only a control
> dependency, we now upgrade to a full load-acquire to match the
> store-release from the spin_unlock
From: Sascha Hauer
This adds support for hardware-tracked trip points to the device tree
thermal sensor framework.
The framework supports an arbitrary number of trip points. Whenever
the current temperature is updated, the trip points immediately
below and above the current temperature are found
From: Sascha Hauer
With interrupt driven thermal zones we pass the lower and upper
temperature on which shall be acted, so in the governor we have to act on
the exact lower temperature to be consistent. Otherwise an interrupt maybe
generated on the exact lower temperature, but the bang bang gover
On 05/25/2016 09:44 PM, Rhyland Klein wrote:
> On 5/25/2016 1:26 PM, Jon Hunter wrote:
>>
>> On 25/05/16 17:36, Rhyland Klein wrote:
>>
>> ...
>>
>>> I can see that getting the temperature could work. I would point out
>>> that I don't see any recent changes to bq27xxx or the power_supply_core
>>>
Whenever the current temperature is updated, the trip points immediately
below and above the current temperature are found. A sensor driver
callback `set_trips' is then called with the temperatures.
Lastly, The sensor will trigger the hardware high temperature interrupts
to increase the sampleing r
From: Sascha Hauer
The .get_trend callback in struct thermal_zone_device_ops has
the prototype:
int (*get_trend) (struct thermal_zone_device *, int,
enum thermal_trend *);
whereas the .get_trend callback in struct thermal_zone_of_device_ops
has:
int (*get
From: Sascha Hauer
This patch implements .set_trips for device tree thermal zones.
As the hardware-tracked trip points is supported by thermal core patch[0].
patch[0]
"thermal: Add support for hardware-tracked trip points".
Signed-off-by: Sascha Hauer
Signed-off-by: Caesar Wang
Cc: Zhang Rui
Hi Ebru,
On Fri, May 27, 2016 at 10:59:23AM +0300, Ebru Akagunduz wrote:
> Nested circular locking dependency detected by kernel robot (udevadm).
>
> udevadm/221 is trying to acquire lock:
>(&mm->mmap_sem){++}, at: [] __might_fault+0x83/0x150
> but task is already holding lock:
>(
On 05/26/2016 11:08 AM, Linus Walleij wrote:
> On Tue, May 17, 2016 at 8:02 AM, Krzysztof Kozlowski
> wrote:
>
>> Although unbinding a pinctrl driver requires root privileges but it
>> still might be used theoretically in certain attacks (by triggering NULL
>> pointer exception or memory corrupti
Forget to send a patch, sorry for the noise.:-(
Please ignore this series patches [PATCH v4 0/4].
RESEND the new series patches "[RESEND PATCH v4 0/5]".
On 2016年05月27日 16:23, Caesar Wang wrote:
The history patches come from Mikko and Sascha.
http://thread.gmane.org/gmane.linux.power-manage
On Friday, May 27, 2016 8:03:57 AM CEST Heiko Carstens wrote:
> > > > > Cost wise, this seems like it all cancels out in the end, but what
> > > > > do I know?
> > > >
> > > > I think you know something, and I also think Heiko and other s390 guys
> > > > know something as well. So I'd like to list
On Fri, May 27, 2016 at 05:27:44PM +0900, Minchan Kim wrote:
>
> Yes, it might be trivial to adding new "string" into the backend array
> if we consider frequency of adding new compressoin algorithm in linux
> but it would be better if we can get names of supported compression
> algorithm name by c
On Fri, May 27, 2016 at 04:02:59PM +0800, Hekuang wrote:
SNIP
> > > The only concern is that, if later we support more platforms,
> > > there will be too much files named as
> > > 'tools/perf/util/unwind-libunwind*.c'
> > > Is it acceptable or not?
> > >
> > > And I thought all files belongs to
Hi,
Reporting an oom/memleak issue in linux-next tree:
#Description:
dbench invokes oom-killer, make host unavaiable.
dbench was doing IO on nvdimm device mounted fs with dax mount option.
It happens on both xfs and ext4 filesystems.
It does not happen testing without dax mountoption.
Seems li
Hi Heiko
On 05/27/2016 04:29 PM, Heiko Stuebner wrote:
Hi Chris,
Am Freitag, 27. Mai 2016, 14:02:15 schrieb Chris Zhong:
This patch adds a binding that describes the Rockchip USB Type-C PHY
for rk3399.
Signed-off-by: Chris Zhong
---
.../devicetree/bindings/phy/phy-rockchip-typec.txt | 55
On 2016-05-26 02:36, Dmitry Torokhov wrote:
> On Tue, May 24, 2016 at 10:32:53AM +0200, Manfred Schlaegl wrote:
>> On 2016-05-20 18:59, Dmitry Torokhov wrote:
>>> Hi Manfred,
>>>
>>> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
@@ -133,6 +149,8 @@ static int pwm_beeper_rem
From: Honghui Zhang
Mediatek SMI has two generations of HW architecture, mt8173 uses the
second generation of SMI HW while mt2701 uses the first generation
HW of SMI.
There's slight differences between the two generations, for generation 2,
the register which control the iommu port access PA or
From: Honghui Zhang
Add the dtsi node of iommu and smi for mt2701.
Signed-off-by: Honghui Zhang
---
arch/arm/boot/dts/mt2701.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index
From: Honghui Zhang
Mediatek SoC's M4U has two generations of HW architcture. Generation one
uses flat, one layer pagetable, and was shipped with ARM architecture, it
only supports 4K size page mapping. MT2701 SoC uses this generation one
m4u HW. Generation two uses the ARM short-descriptor trans
From: Honghui Zhang
Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart
Multimedia Interface)have two generations HW. They basically sharing the
same hardware block diagram, but have some difference as below:
Generation one m4u only supports one layer, flat pagetable addressing,
From: Honghui Zhang
This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
add descriptions of binding for mediatek generation one iommu and smi.
Signed-off-by: Honghui Zhang
Acked-by: Rob Herring
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 13 +++-
.../memory-
From: Honghui Zhang
Move the struct defines of mtk iommu into a new header files for
common use.
Signed-off-by: Honghui Zhang
---
drivers/iommu/mtk_iommu.c | 48 +
drivers/iommu/mtk_iommu.h | 77 +++
2 files changed, 78 in
On Fri, May 27, 2016 at 08:03:57AM +0200, Heiko Carstens wrote:
> > > > The cost is pretty trivial though. See kernel/compat_wrapper.o:
> > > > COMPAT_SYSCALL_WRAP2(creat, const char __user *, pathname, umode_t,
> > > > mode);
> > > > 0: a9bf7bfdstp x29, x30, [sp,#-16]!
> > > > 4:
On Fri, May 27, 2016 at 09:48:22AM +0200, Gerd Hoffmann wrote:
> > I guess I didn't do a good job at looking at your v2: Cursor is still
> > using legacy interfaces and not a proper plane. Would be awesome if
> > you could fix that up. Atomic drivers really shouldn't use the legacy
> > cursor inter
On Fri, May 27, 2016 at 08:46:49AM +0200, Martin Schwidefsky wrote:
> > This fixes a number of spin_unlock_wait() users that (not
> > unreasonably) rely on this.
>
> All that is missing is an smp_rmb(), no?
Indeed.
> > --- a/arch/s390/include/asm/spinlock.h
> > +++ b/arch/s390/include/asm/spinl
On 27 May 2016 at 15:53, Milan Broz wrote:
> On 05/27/2016 09:04 AM, Baolin Wang wrote:
>> Hi Milan,
>>
>> On 27 May 2016 at 14:31, Milan Broz wrote:
>>> On 05/25/2016 08:12 AM, Baolin Wang wrote:
Now some cipher hardware engines prefer to handle bulk block rather than
one
sector
On Fri, May 27, 2016 at 04:43:45PM +0800, Herbert Xu wrote:
> On Fri, May 27, 2016 at 05:27:44PM +0900, Minchan Kim wrote:
> >
> > Yes, it might be trivial to adding new "string" into the backend array
> > if we consider frequency of adding new compressoin algorithm in linux
> > but it would be bet
On Thu, May 26, 2016 at 05:10:36PM -0400, Chris Metcalf wrote:
> On 5/26/2016 10:19 AM, Peter Zijlstra wrote:
> >--- a/arch/tile/lib/spinlock_32.c
> >+++ b/arch/tile/lib/spinlock_32.c
> >@@ -72,10 +72,14 @@ void arch_spin_unlock_wait(arch_spinlock
> > if (next == curr)
> > return;
>
On 2016-05-27 10:54, Manfred Schlaegl wrote:
>
> Ok. Thanks for clarification.
> I will send a patch with the modifications you suggested before.
>
> The following patch will also have some slight modifications in line numbers
> to make it apply after
> cfae56f18 (input: misc: pwm-beeper: Explic
On Thu, May 26, 2016 at 11:33:23AM -0400, Rich Felker wrote:
> On Thu, May 26, 2016 at 11:38:29AM +0100, Mark Rutland wrote:
> > On Wed, May 25, 2016 at 07:04:08PM -0400, Rich Felker wrote:
> > > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote:
> > > > * How must the value be written?
Pwm config may sleep so defer it using a worker.
On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.
Tested on Freescale i.MX53 SoC with 4.6.0.
Signed-off-by: Manfred Schlaegl
---
drivers/input/
Hi, Arnaldo
If you have a little time,
could you check this simple patch ?
This patch is minor but
everytime I build tools/perf code,
untracked file(arch/*/include/generated/) is always generated..
like below
taeung ~/git/linux-perf/tools/perf
:> make -j4
BUILD: Doing 'make -j4' parallel b
On 05/27/2016 10:37 AM, Krzysztof Kozlowski wrote:
>> And you might be completely correct, that is something that can only
>> happen specifically with the bq27xxx driver. In which case, making the
>> fix there should be the fix. I just know from the commit log (and some
>> previous work with power
> Tejun Heo wrote on 03/31/2016 08:14:35 PM:
>
> Hello, Michael.
>
> On Thu, Mar 31, 2016 at 08:17:13AM +0200, Michael Rapoport wrote:
> > > There really shouldn't be any difference when using unbound
> > > workqueues. workqueue becomes a convenience thing which manages
> > > worker pools and th
On 27 May 2016 at 08:31, YT Shen wrote:
> Hi CK,
>
>
> On Mon, 2016-05-23 at 17:43 +0800, CK Hu wrote:
>> Hi, YT:
>>
>> One comment below.
>>
>> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote:
>> > From: YT Shen
>> >
>> > There are some hardware settings changed, between MT8173 & M
On 20 May 2016 at 16:05, wrote:
> From: YT Shen
>
> Add MT8173 suffix for hardware related macros.
>
Why suffix ? Pretty much everyone else uses prefix.
-Emil
There seems to be some sort of race condition between
blkdev_issue_zeroout() and the scsi disk driver (disabling write same
after an illegal request). On my UAS drive, sometimes `blkdiscard -z
/dev/sdX` will return right away, even though if I then check
`write_same_max_bytes` it has turned 0. Some
On Fri, May 27, 2016 at 10:42:59AM +0200, Arnd Bergmann wrote:
> On Friday, May 27, 2016 8:03:57 AM CEST Heiko Carstens wrote:
> > > > > > Cost wise, this seems like it all cancels out in the end, but what
> > > > > > do I know?
> > > > >
> > > > > I think you know something, and I also think Heik
1 - 100 of 537 matches
Mail list logo
