The MAXIM PMIC MAX77620 and MAX20024 are power management IC
which supports RTC, GPIO, DCDC/LDO regulators, interrupt,
watchdog etc.
Add DT binding document for the different functionality of
this device.
Signed-off-by: Laxman Dewangan
Acked-by: Rob Herring
---
Changes from V1:
- Added units i
Add SW support for MAXIM Semiconductor's Power Management
IC (PMIC) MAX77620/MAX20024. This PMIC supports DC-DC/LDOS, GPIOs,
RTC, watchdog, clocks etc.
This series add respective driver for each of sub-modules.
---
Changes from V1:
DT DOC:
- Added units in some of properties.
- Change the boolean
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to control via GPIO APIs.
Signed-off-by: Laxman Dewangan
Reviewed-by: Linus Walleij
---
Changes from V1:
- Use the gpiochip_add_data and get the chip data
2016-03-09 10:23 GMT+09:00 Leizhen (ThunderTown) :
>
>
> On 2016/3/8 9:54, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/3/8 2:42, Laura Abbott wrote:
>>> On 03/07/2016 12:16 AM, Leizhen (ThunderTown) wrote:
On 2016/3/7 12:34, Joonsoo Kim wrote:
> On Fri, Mar 04, 2016 at 03:35:26
On Fri, Mar 11, 2016 at 03:30:31PM +0100, Michal Hocko wrote:
> On Fri 11-03-16 16:45:34, Vladimir Davydov wrote:
> > On Fri, Mar 11, 2016 at 01:51:05PM +0100, Michal Hocko wrote:
> > > On Fri 11-03-16 15:39:00, Vladimir Davydov wrote:
> > > > On Fri, Mar 11, 2016 at 12:54:50PM +0100, Michal Hocko
Hi Christopher,
On 03/10/2016 10:35 PM, Christopher Covington wrote:
> Version 2 of the Server Base System Architecture (SBSAv2) describes the
> Generic UART registers as 32 bits wide. At least one implementation, found
> on the Qualcomm Technologies QDF2432, only supports 32 bit accesses.
> SBSAv
On 03/11/2016 08:52 AM, Marc Titinger wrote:
> The user (or an init script) may setup RShunt via sysfs after the
> driver was initialized, for instance based on the EEPROM contents
> of a modular probe. The calibration register must be set accordingly.
>
> Signed-off-by: Marc Titinger
> ---
> tes
On 02/29/2016 06:42 PM, Michal Hocko wrote:
From: Michal Hocko
xol_add_vma needs mmap_sem for write. If the waiting task gets killed by
the oom killer it would block oom_reaper from asynchronous address space
reclaim and reduce the chances of timely OOM resolving. Wait for the
lock in the killa
Am Freitag, 11. März 2016, 15:56:04 schrieb Heiko Stübner:
> Hi Caesar,
>
> Am Freitag, 11. März 2016, 16:47:59 schrieb Sergei Shtylyov:
> > On 3/11/2016 1:55 PM, Caesar Wang wrote:
> > > This patch adds to support the emac phy reset.
> > >
> > > 1) phy-reset-gpios:
> > > The phy-reset-gpios is a
Am 11.03.2016 um 15:18 schrieb Josh Poimboeuf:
Simplify the control flow of cik_tiling_mode_table_init() similar to how
it was done in gfx_v7_0.c and gfx_v8_0.c.
Signed-off-by: Josh Poimboeuf
I'm not so deep into the tilling config stuff, but briefly skimming over
it it clearly looks good to
MAX77620/MAX20024 are Power Management IC from the MAXIM.
It supports RTC, multiple GPIOs, multiple DCDC and LDOs,
watchdog, clock etc.
Add MFD drier to provides common support for accessing the
device; additional drivers is developed on respected subsystem
in order to use the functionality of the
Hi, Namhyung
On 03/11/2016 11:11 PM, Namhyung Kim wrote:
Hi Taeung,
On Thu, Mar 10, 2016 at 11:04:27PM +0900, Taeung Song wrote:
In order to variously handle config key-value pairs,
prepare all default configs and collect
config key-value pairs from user and
system config files (i.e user wide
From: "liping.zhang"
There is no need to use the static variable here, pr_info_once is more
concise.
Signed-off-by: Liping Zhang
---
net/socket.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index c044d1e..c499784 100644
--- a/net/s
On Fri 11-03-16 23:53:18, Joonsoo Kim wrote:
> 2016-03-09 19:41 GMT+09:00 Michal Hocko :
> > On Wed 09-03-16 02:03:59, Joonsoo Kim wrote:
> >> 2016-03-09 1:05 GMT+09:00 Michal Hocko :
> >> > On Wed 09-03-16 00:19:03, Joonsoo Kim wrote:
[...]
> >> >> What's your purpose of OOM rework? From my unders
On 02/29/2016 02:26 PM, Michal Hocko wrote:
From: Michal Hocko
i915_gem_mmap_ioctl relies on mmap_sem for write. If the waiting
task gets killed by the oom killer it would block oom_reaper from
asynchronous address space reclaim and reduce the chances of timely OOM
resolving. Wait for the lock
On 02/29/2016 02:26 PM, Michal Hocko wrote:
From: Michal Hocko
radeon_mn_get which is called during ioct path relies on mmap_sem for
write. If the waiting task gets killed by the oom killer it would block
oom_reaper from asynchronous address space reclaim and reduce the
chances of timely OOM re
On 11/03/2016 16:04, Andrew F. Davis wrote:
...
@@ -599,6 +621,8 @@ static const struct iio_info ina2xx_info = {
.debugfs_reg_access = ina2xx_debug_reg,
};
+
+
?
Ok, will fix in v2, thanks !
M.
/* Initialize the configuration and calibration registers. */
static int ina
On Fri, Mar 11, 2016 at 01:59:52PM +, One Thousand Gnomes wrote:
> > > We can do the security check at the filesystem level, because we have
> > > sb->s_bdev->bd_inode, and if you have read and write permissions to
> > > that inode, you might as well have permission to create a unsafe hole.
>
On Fri 11-03-16 22:32:02, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 11-03-16 19:45:29, Tetsuo Handa wrote:
> > > (Posting as a reply to this thread.)
> >
> > I really do not see how this is related to this thread.
>
> All allocating tasks are looping at
>
> /*
On 02/29/2016 02:26 PM, Michal Hocko wrote:
From: Michal Hocko
amdgpu_mn_get which is called during ioct path relies on mmap_sem for
write. If the waiting task gets killed by the oom killer it would block
oom_reaper from asynchronous address space reclaim and reduce the
chances of timely OOM re
On Fri 11-03-16 15:58:43, Vlastimil Babka wrote:
> On 02/29/2016 06:42 PM, Michal Hocko wrote:
[...]
> >@@ -1468,7 +1470,8 @@ static void dup_xol_work(struct callback_head *work)
> > if (current->flags & PF_EXITING)
> > return;
> >
> >-if (!__create_xol_area(current->utask->dup_
On Thu, Mar 10, 2016 at 09:15:06PM -0500, Theodore Ts'o wrote:
> On Fri, Mar 11, 2016 at 11:44:54AM +1100, Daniel Axtens wrote:
> > Hi,
> >
> > Trying to run a Docker container on a mainline kernel is failing
> > intermittently, in interesting and exciting ways, such as:
> >
> > $ docker run -it
Yuriy M. Kaminskiy wrote:
> BTW, all those hash/conntrack/etc default sizes was calculated from
> physical memory size in assumption there will be only *one* instance of
> those tables. Obviously, introduction of network namespaces (and
> especially unprivileged user-ns) thrown this assumption in
On Fri, 2016-03-11 at 09:12 +, Borislav Petkov wrote:
> On Thu, Mar 10, 2016 at 09:45:45PM -0700, Toshi Kani wrote:
:
> >
> > -static inline void pat_disable(const char *reason)
> > +void pat_disable(const char *reason)
> > {
> > + if (boot_cpu_done) {
> > + pr_info("x86/PAT: PA
On 03/11/16 at 10:47am, walter harms wrote:
>
>
> Am 11.03.2016 10:19, schrieb Dan Carpenter:
> > On Fri, Mar 11, 2016 at 04:52:43PM +0800, Xunlei Pang wrote:
> >> Hi Dan,
> >>
> >> On 2016/03/11 at 16:07, Dan Carpenter wrote:
> >>> At the end of the function we check if "ret" has a negative erro
Oh boy oh boy. This thing runs at SCHED_FIFO MAX_USER_RT_PRIO/2 and
stops at mwait_idle_with_hints(). Why bother with /2?
There are a few things I haven't fully decoded. For instance why is it
looking at local_softirq_pending()?
The timer is probably here if mwait would let it sleep too long.
I tr
On 03/11/2016 07:52 AM, Roger Quadros wrote:
> Franklin,
>
> On 11/03/16 01:56, Franklin S Cooper Jr wrote:
>> The dma channel information is located within the GPMC node which is the
>> NAND's parent node. The NAND driver requires a handle to the GPMC's dev
>> to properly parse the DMA propertie
Hans Verkuil writes:
> On 03/11/2016 02:41 PM, Robert Jarzmik wrote:
>> Hans Verkuil writes:
> One area where I would like to see some helper functions is with respect to
> format/media bus processing. I played with this a little bit but it is
> surprisingly
> hard to do. A lot of devices have
On Fri, Mar 11, 2016 at 03:23:46PM +0100, Peter Zijlstra wrote:
> The below seems to fix the IBS issue tickled by syz-kaller on my
> machine. I've not yet ran perf-fuzzer, which seems able to tickle a
> different set of bugs.
>
> ---
> Subject: perf, amb: Fix IBS throttle
amd
bu
Hello,
This patchset extends cgroup v2 to support rgroup (resource group) for
in-process hierarchical resource control and implements PRIO_RGRP for
setpriority(2) on top to allow in-process hierarchical CPU cycle
control in a seamless way.
cgroup v1 allowed putting threads of a process in differe
To support in-process resource control, the previous patch implemented
the basic rgroup infrastructure which allows creating rgroups by
specifying CLONE_NEWRGRP during clone(2). This patch implements
control mask handling for rgroups so that controllers can be enabled
on them.
There can be multip
This updates MAINTEINERS file with information about maintainer of
ARC PGU display controller driver.
Signed-off-by: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.org
Cc: dri-de...@lists.freedesktop.org
---
No changes v2 -> v3.
No changes v1 -> v2.
MAINTAINERS | 6 ++
1 file changed,
This will be used from cgroup while implementing in-process resource
control.
Signed-off-by: Tejun Heo
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Oleg Nesterov
---
include/linux/sched.h | 2 ++
kernel/fork.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/lin
They're trivial wrappers now but to support in-process resource
control, cgroup_path() and friends will need to access more of cgroup
internals. Un-inline them.
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 31 +--
kernel/cgroup.c| 21
cgroup v1 allowed tasks of a process to be put in different cgroups
thus allowing controlling resource distribution inside a process;
however, controlling in-process properties through filesystem
interface is highly unusual and has various issues around delegation,
ownership, and lack of integratio
This add DT bindings documentation for ARC PGU display controller.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infra
One of the missing features in cgroup v2 is the ability to control cpu
cycle distribution hierarchically among threads of a process. With
rgroup infrastructure in place, this can be implemented as a natural
extension of setpriority().
This patch introduces a new @which selector PRIO_RGRP for
{set
Currently, when a process with rgroups is migrated, rgroup subtrees
are not preserved and all threads are put directly under the migration
destination cgroup. This patch implements rgroup subtree migration so
that rgroup subtrees are preserved across process migration.
Early during process migrat
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Alexey Brodkin
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-snps-...@lists.infradead.org
Cc: J
When threadgroup_change_begin/end() are called from fork path, pass in
@child and @clone_flags so that fork path can be distinguished and
fork related information is available.
While at it, un-inline cgroup_threadgroup_change_begin/end() and fold
cgroup_fork() into cgroup_threadgroup_change_begin(
Currently, the only migration modifier is boolean @threadgroup. Make
the functions pass around unsigned flag mask instead and replace
@threadgroup with CGRP_MIGRATE_PROCESS. This will allow addition of
other modifiers.
This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo
This series add support of ARC PGU display controller.
ARC PGU is a quite simple byte streamer that gets data from the framebuffer
and pushes it to hte connected encoder (DP or HDMI).
It was tested on ARC SDP boards (axs101 in particular).
Changes v2 -> v3:
* Improved failure path if arcpgu_conn
Synopsys DesignWare ARC SDP boards sport ARC SDP display
controller attached to ADV7511 HDMI encoder.
That change adds desctiption of both ARC PGU and ADV7511 in
ARC SDP'd base-board Device Tree.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
C
In preparation for removing the ->driverfs_dev member of a gendisk, add
an api that takes the parent device as a parameter to add_disk(). For
now this maintains the status quo of WARN()ing on failure, but not
return a error code.
Signed-off-by: Dan Williams
---
block/genhd.c | 13
Changes since v1: [1]
1/ Rebase on -next
2/ Drop the error return from device_add_disk() to keep the same error
semantics as add_disk() for now. (Christoph).
[1]: https://lkml.org/lkml/2016/2/25/664
---
Answer the "// FIXME: remove" include/linux/genhd.h. This should be
functionally equiva
Introduce thin wrappers which lock and unlock cgroup_mutex. While
this doesn't introduce any functional differences now, they will later
be used to perform some extra operations around locking.
Signed-off-by: Tejun Heo
---
kernel/cgroup.c | 100 +-
On Fri 11-03-16 18:02:24, Vladimir Davydov wrote:
> On Fri, Mar 11, 2016 at 03:30:31PM +0100, Michal Hocko wrote:
[...]
> > Not really. GFP_KERNEL would allow to invoke some shrinkers which are
> > GFP_NOFS incopatible.
>
> Can't a GFP_NOFS allocation happen when there is no shrinkable objects
> t
On Tue, Mar 8, 2016 at 4:37 PM, Andre Przywara wrote:
> Based on the Allwinner A64 user manual and on the previous sunxi
> pinctrl drivers this introduces the pin multiplex assignments for
> the ARMv8 Allwinner A64 SoC.
> Port A is apparently used for the fixed function DRAM controller, so
> the
Add two extra arguments to cgroup_{can|cancel|post}_fork(). These
will be used to implement in-process resource control. The extra
arguments aren't used yet.
Signed-off-by: Tejun Heo
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Oleg Nesterov
---
include/linux/cgroup-defs.h | 2 ++
include/linux/
Now that all drivers that specify a ->driverfs_dev have been converted
to device_add_disk(), the pointer can be removed from struct gendisk.
Cc: Jens Axboe
Cc: Christoph Hellwig
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
block/genhd.c |5 ++---
drivers/nvdimm/bus.c |2 +
For block drivers that specify a parent device, convert them to use
device_add_disk().
This conversion was done with the following semantic patch:
@@
struct gendisk *disk;
expression E;
@@
- disk->driverfs_dev = E;
...
- add_disk(disk);
+ device_add_disk(E, disk);
On Fri, Mar 11, 2016 at 09:27:40AM -0700, Toshi Kani wrote:
> How about pat_disable_setup()? It's only used for the disabled case, so
> I'd prefer to keep the word "disable".
What for?
Renaming pat_init() to pat_setup() is perfectly fine as it sets up PAT
after looking at pat_disabled() setting
On Thu, Mar 10, 2016 at 11:30:58AM +0100, Ludovic Desroches wrote:
> It was impossible to wake-up on card detect event because when sdhci
> controller is runtime suspend, it is assumed that all the clocks are
> disabled so we can't get irqs.
> If the device is removable and there is no gpio to mana
On Fri, 11 Mar, at 05:05:33PM, Chen Yu wrote:
> The problem is Linux registers pm_power_off = efi_power_off
> only if we are in hardware reduced mode. Actually, what we also
> want is to do this when ACPI S5 is simply not supported on
> non-legacy platforms. That should handle both the HW reduced m
For whatever reason, I've found that some laptops aren't immediately
capable of doing aux transactions with their docks when they come out of
standby. While I'm still not entirely sure what the cause of this is,
sleeping for 30ms and then retrying drm_dp_mst_topology_mgr_resume()
should be a suffic
Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.
This order was originally changed in
commit e7d6f7d70829 ("drm/
This is a follow-up to the original patches I sent to try to fix the issue of
drm_dp_mst_topology_mgr_resume() not working due to aux transactions failing
temporarily after resuming the machine. Unfortunately I haven't been able to
figure out the actual cause of this issue; there don't seem to be a
On Fri, Mar 11, 2016 at 04:47:04PM +0100, Michal Hocko wrote:
> On Fri 11-03-16 18:02:24, Vladimir Davydov wrote:
> > On Fri, Mar 11, 2016 at 03:30:31PM +0100, Michal Hocko wrote:
> [...]
> > > Not really. GFP_KERNEL would allow to invoke some shrinkers which are
> > > GFP_NOFS incopatible.
> >
>
On Fri, Mar 4, 2016 at 5:59 PM, Matthias Brugger wrote:
> The standby GPIO controller can be used as a interrupt controller.
> Select GPIOLIB_IRQCHIP when compiling this driver. Otherwise we get
> a compilation error:
>
> drivers/gpio/gpio-xgene-sb.c: In function 'xgene_gpio_sb_probe':
> drivers/
On 3/10/2016 9:06 PM, Vinod Koul wrote:
> On Thu, Feb 04, 2016 at 11:34:36PM -0500, Sinan Kaya wrote:
>
>> +
>> +#define EVRE_SIZE 16 /* each EVRE is 16 bytes */
>> +
>> +#define TRCA_CTRLSTS_OFFSET 0x000
>> +#define TRCA_RING_LOW_OFFSET0x008
>> +#def
Hi Marc,
[auto build test WARNING on iio/togreg]
[also build test WARNING on next-20160311]
[cannot apply to v4.5-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Marc-Titinger/iio-ina2xx
Hello,
The attached test-rgrp-burn.c is an example program making use of the
new PRIO_RGRP. The test program creates rgroup the following rgroup
hierarchy
sgroup - main thread
+ [rgroup-0] burner-0
+ [rgroup-1] + [rgroup-2] burner-1
+ [rgroup-3] burner-2
an
On 03/11/2016 04:40 PM, Robert Jarzmik wrote:
> Hans Verkuil writes:
>
>> On 03/11/2016 02:41 PM, Robert Jarzmik wrote:
>>> Hans Verkuil writes:
>> One area where I would like to see some helper functions is with respect to
>> format/media bus processing. I played with this a little bit but it i
On 3/10/2016 10:48 PM, Eric Auger wrote:
>> Well, I haven't seen that warning during testing. I was trying to be more
>> > proactive.
> Thank you for that. Personally I agree to proceed with the proposed
> change, ie. forbid vfio platform driver to be used if there is no reset
> function found but
On Fri, 11 Mar 2016 14:43:45 +0300
Andrey Ryabinin wrote:
> >> This is not about size, this about fragmentation. vmalloc allows to
> >> utilize available low-order pages,
> >> hence reduce the fragmentation.
> > I've attempted to add __vmalloc(STACK_ALLOC_SIZE, alloc_flags,
> > PAGE_KERNEL) (a
On Fri, Mar 11, 2016 at 3:01 PM, Christoph Hellwig wrote:
> On Mon, Feb 29, 2016 at 09:17:05AM +0100, Andreas Gruenbacher wrote:
>> Al,
>>
>> could you please make sure you are happy with the current version of the
>> richacl patch queue for the next merge window?
>
> I'm still not happy.
>
> For
The following commits:
commit 3fa609755c11 ("ARM: omap2: restore OMAP4 barrier behaviour")
commit f746929ffdc8 ("Revert "ARM: OMAP4: remove dead kconfig option
OMAP4_ERRATA_I688"")
and
commit ea827ad5ffbb ("ARM: DRA7: Provide proper IO map table")
came in around the same time, unfortunately this s
On Fri, Mar 11, 2016 at 12:53 AM, Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
>> On Thu, Mar 10, 2016 at 12:53 PM, Arjan van de Ven
>> wrote:
>> >> Arjan, or other folks, can you remember why x86_32 disabled mmap
>> >> randomization here? There doesn't seem to be a good reason for it that
>> >>
Hi,
I have written a Variant Symlink Filesystem for linux, currently
implemented as a kernel module:
https://github.com/onslauth/varsymfs
The code was written for the 3.x kernel.
I would like to try to get this included into the linux kernel, and am
willing to hand over all copyright and change t
Hi Linus
Two fixes showed up in last few days, and they should be included in 4.5. So
please consider PULL to recieve two driver fixes, one marked stable.
The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb:
Linux 4.5-rc7 (2016-03-06 14:48:03 -0800)
are available in th
On Fri, Mar 11, 2016 at 11:08:56AM +0300, Dan Carpenter wrote:
> It's basically harmless if "ref_level" isn't initialized since it's only
> used for an error message, but it causes a static checker warning.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: David Sterba
On Fri, Mar 11, 2016 at 3:07 PM, Christoph Hellwig wrote:
> On Mon, Feb 29, 2016 at 09:17:16AM +0100, Andreas Gruenbacher wrote:
>> POSIX ACLs and richacls are both objects allocated by kmalloc() with a
>> reference count which are freed by kfree_rcu(). An inode can either
>> cache an access and
Hi Peter,
You are right, SPCR console should support earlycon.
I will send next version that will try to follow your recommendations in
a week, after I return from vacations.
As we discussed with Christopher, "serial: pl011: use SPCR to setup
32-bit access" will be dropped.
Thank you
Alekse
On Fri, Mar 11, 2016 at 11:02:36AM -0500, Sinan Kaya wrote:
> > These are rest here are not namespace properly...
>
> If I understood it right, you want me to prefix them with as HIDMA_xyz.
> Correct?
Yes..
> >> + /* copy the TRE into its location in the TRE ring */
> >> + spin_lock_irqsave(&l
On 12/06/2015 11:44 AM, Zhaoxiu Zeng wrote:
> From: Zeng Zhaoxiu
The patch looks OK, but could you also provide a proper commit
message?
> Signed-off-by: Zeng Zhaoxiu
> ---
> drivers/media/platform/exynos4-is/fimc-is-regs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --
pca953x_gpio_set_multiple() divides by 4 to convert from longs to bytes,
which assumes a 32-bit platform, and is not correct on 64-bit platforms.
Use "sizeof(...)" instead to fix this.
Fixes: b4818afeacbd8182 ("gpio: pca953x: Add set_multiple to allow multiple
bits to be set in one write.")
Signe
Hi Matt,
> -Original Message-
> From: Matt Fleming [mailto:m...@codeblueprint.co.uk]
> Sent: Friday, March 11, 2016 11:56 PM
> To: Chen, Yu C
> Cc: linux-a...@vger.kernel.org; linux...@vger.kernel.org; Rafael J. Wysocki;
> Len Brown; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Zhang, Ru
The series looks fine to me,
Reviewed-by: Christoph Hellwig
From: Robert Doebbelin
Reading wrong data may cause the IO thread to starve waiting for completion.
The issue was introduced with commit 04b2fa9 and thus affects kernel >= 4.1. It
was discovered by KASan:
kernel: ==
kernel: BUG: KAS
These patches are fixes for the problems reported at
https://sourceforge.net/p/fuse/mailman/message/34537139/. The first
patch is one of those that Robert posted on that thread, and the second
is a different patch that Robert and I agree represents a more robust
solution to the race.
The first rac
The req member of fuse_io_priv serves two purposes. First is to
track the number of oustanding async requests to the server and
to signal that the io request is completed. The second is to be a
reference count on the structure to know when it can be freed.
For sync io requests these purposes can b
On Thu, Mar 10, 2016 at 8:31 PM, Arnaldo Carvalho de Melo
wrote:
> Em Thu, Mar 10, 2016 at 07:35:57PM +0100, Dmitry Vyukov escreveu:
>> On Tue, Jan 26, 2016 at 8:30 PM, Arnaldo Carvalho de Melo
>> wrote:
>> > Em Tue, Jan 26, 2016 at 08:27:48PM +0100, Dmitry Vyukov escreveu:
>> >> On Fri, Jan 22,
When initializing sd or sdio card, we get struct mmc_card
from mmc_alloc_card which allocates it by kzalloc. So we don't
need another memset while decoding cid.
Signed-off-by: Shawn Lin
---
drivers/mmc/core/sd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mmc/core/sd.c b/driver
From: Andrzej Hajda
Date: Fri, 11 Mar 2016 07:51:15 +0100
> Function skb_splice_bits can return negative values, its result should
> be assigned to signed variable to allow correct error checking.
>
> The problem has been detected using patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.
On 3/11/2016 11:32 AM, Vinod Koul wrote:
memcpy(lldev->tre_ring + lldev->tre_write_offset, &tre->tre_local[0],
> >> +TRE_SIZE);
> This one
>
> >> + lldev->tx_status_list[tre->idx].err_code = 0;
> >> + lldev->tx_status_list[tre->idx].err_info = 0;
> >> +
On 2016-03-11 11:20, Cole wrote:
Hi,
I have written a Variant Symlink Filesystem for linux, currently
implemented as a kernel module:
https://github.com/onslauth/varsymfs
The code was written for the 3.x kernel.
I would like to try to get this included into the linux kernel, and am
willing to h
Hi Nishanth,
Thank you for the patch.
On Friday 11 March 2016 10:12:28 Nishanth Menon wrote:
> The following commits:
> commit 3fa609755c11 ("ARM: omap2: restore OMAP4 barrier behaviour")
> commit f746929ffdc8 ("Revert "ARM: OMAP4: remove dead kconfig option
> OMAP4_ERRATA_I688"") and
> commit ea
Hi Alexey,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.5-rc7 next-20160311]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Alexey-Brodkin/drm-Add-support-of-ARC
drivers/gpu/drm/arc/arcpgu_drv.c:243:6-11: No need to set .owner here. The core
will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Alexey Brodkin
Signed-off-by: Fengguang Wu
---
arcpgu_drv.c |
From: David Daney
A follow-on patch uses PCI probing to find the Thunder MDIO hardware.
In preparation for this, split out the common code into a new file
mdio-cavium.c, which will be used by both the existing OCTEON driver,
and the new Thunder PCI based driver.
As part of the refactoring simpli
From: David Daney
The firmware on many Cavium Thunder systems configures the MDIO bus
hardware to be probed as a PCI device. In order to use the MDIO bus
drivers in this configuration, we must add PCI probing to the driver.
There are two parts to this set of three patches:
1) Cleanup the PHY
On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> > These could still be open coded in an inlined fashion, like the scheduler
>> > usage.
>>
>> We could have a raw_rdmsr for those.
>>
>> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior
From: David Daney
Remove the call to force the octeon-mdio driver to be loaded. Allow
the standard driver loading mechanisms to load the PHY drivers, and
use -EPROBE_DEFER to cause the BGX driver to be probed only after the
PHY drivers are available.
Reorder the setting of MAC addresses and PHY
From: David Daney
The Cavium Thunder SoCs have multiple MIDO buses that are part of a
single PCI device. To model this in the device tree we call the PCI
parent device a "cavium,thunder-8890-mdio-nexus", it has several
children, one for each MDIO bus.
The MDIO bus hardware is identical to that
#x27;t it?
>
> What happens without this patch applied. In other words, it all smells
> like the IO got stuck somewhere and the direct reclaim cannot perform it
> so we have to wait for the flushers to make a progress for us. Are those
> stuck? Is the IO making any progress at all
Use of a temporary R8 register here seems to be unnecessary.
"push %r8" is a two-byte insn (it needs REX prefix to specify R8),
"push $0" is two-byte too. It seems just using the latter would be
no worse.
Thus, code had an unnecessary "xorq %r8,%r8" insn.
It probably costs nothing in execution ti
The code was allowing platform devices to be used without a supporting VFIO
reset driver. The hardware can be left in some inconsistent state after a
guest machine abort.
The reset driver will put the hardware back to safe state and disable
interrupts before returning the control back to the host
The code is using the compatible DT string to associate a reset driver with
the actual device itself. The compatible string does not exist on ACPI
based systems. HID is the unique identifier for a device driver instead.
The change allows a driver to register with DT compatible string or ACPI
HID an
In situations where the userspace driver is stopped abnormally and the
VFIO platform device is released, the assigned HW device currently is
left running. As a consequence the HW device might continue issuing IRQs
and performing DMA accesses.
This patch is implementing a reset driver for HIDMA pla
; like the IO got stuck somewhere and the direct reclaim cannot perform it
> > so we have to wait for the flushers to make a progress for us. Are those
> > stuck? Is the IO making any progress at all or it is just too slow and
> > it would finish actually. Wouldn't we
301 - 400 of 727 matches
Mail list logo
