Validated on the Quark platform, this adds interrupt support on rising
and/or falling edges.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- consistently use spinlock irqsave
drivers/gpio/gpio-sch.c | 144 +---
1 file changed, 137 insertions(+), 7
Add POWER_SUPPLY_HEALTH_OVERCURRENT constant in order to allow
singalling overcurrent condition via power supply health information.
Signed-off-by: Andrey Smirnov
Reviewed-by: Guenter Roeck
Cc: Enric Balletbo Serra
Cc: Chris Healy
Cc: Lucas Stach
Cc: Fabio Estevam
Cc: Guenter Roeck
Cc:
Everyone:
This small series adds a driver for UCS1002 Programmable USB Port
Power Controller with Charger Emulation. See [page] for product page
and [datasheet] for device dataseet. Hopefully each individual patch
is self explanatory.
Note that this series is a revival of the upstreaming effort
Add bindings for Microchip UCS1002 Programmable USB Port Power
Controller with Charger Emulation.
Signed-off-by: Andrey Smirnov
Cc: Enric Balletbo Serra
Cc: Chris Healy
Cc: Lucas Stach
Cc: Fabio Estevam
Cc: Guenter Roeck
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: Sebastian Reichel
On Sat, Apr 27, 2019 at 06:42:51AM -0400, Prarit Bhargava wrote:
> On 4/27/19 6:24 AM, Heiko Carstens wrote:
>
> >
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 410eeb7e4f1d..48748cfec991 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -3585,6 +3585,7 @@ again:
>
Replace calls to platform_get_resource() and devm_ioremap_resource()
with newly added devm_platform_ioremap_resource() for brevity. No
functional change intended.
Signed-off-by: Andrey Smirnov
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Cc: Chris Healy
Cc: linux-g...@vger.kernel.org
Cc:
On Mon, Apr 29, 2019 at 12:36 AM Takashi Iwai wrote:
>
> On Sun, 28 Apr 2019 09:18:40 +0200,
> Takashi Iwai wrote:
> >
> > On Sun, 28 Apr 2019 08:42:32 +0200,
> > Wenwen Wang wrote:
> > >
> > > In usX2Y_In04_init(), a new urb is firstly created through usb_alloc_urb()
> > > and saved to
On 28-04-19, 11:51, Daniel Lezcano wrote:
> The copyright format does not conform to the format requested by
> Linaro: https://wiki.linaro.org/Copyright
>
> Fix it.
>
> Signed-off-by: Daniel Lezcano
> Viresh Kumar
What exactly have I done here ? :)
> ---
> drivers/thermal/cpu_cooling.c | 6
Simplify error checking code by replacing multiple ERR macros with a
call to PTR_ERR_OR_ZERO. No functional change intended.
Signed-off-by: Andrey Smirnov
Cc: Linus Walleij
Cc: Bartosz Golaszewski
Cc: Chris Healy
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Add driver for Microchip UCS1002 Programmable USB Port Power
Controller with Charger Emulation. The driver exposed a power supply
device to control/monitor various parameter of the device as well as a
regulator to allow controlling VBUS line.
Signed-off-by: Enric Balletbo Serra
Signed-off-by:
On Tue, Apr 23, 2019 at 04:18:14PM +, Vineeth Remanan Pillai wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c055bad249a9..45d86b862750 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4132,7 +4132,7 @@ pick_next_entity(struct cfs_rq *cfs_rq, struct
On Sun, 28 Apr 2019 09:18:40 +0200,
Takashi Iwai wrote:
>
> On Sun, 28 Apr 2019 08:42:32 +0200,
> Wenwen Wang wrote:
> >
> > In usX2Y_In04_init(), a new urb is firstly created through usb_alloc_urb()
> > and saved to 'usX2Y->In04urb'. Then, a buffer is allocated through
> > kmalloc() and saved
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+15927486a4f1bfcba...@syzkaller.appspotmail.com
Tested on:
commit: b1da6a51 fsnotify: Fix NULL ptr deref in fanotify_get_fsid()
git tree:
On 09-04-19, 15:22, Peng Ma wrote:
> DPPA2(Data Path Acceleration Architecture 2) qDMA
> The qDMA supports channel virtualization by allowing DMA jobs to be enqueued
> into different frame queues. Core can initiate a DMA transaction by preparing
> a frame descriptor(FD) for each DMA job and
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
block/blk-sysfs.c
between commit:
4d25339e32a1 ("block: don't show io_timeout if driver has no timeout handler")
from the block tree and commit:
800f5aa1e7e1 ("block: Replace all ktype default_attrs with
On Sun, Apr 28, 2019 at 8:51 PM Al Viro wrote:
>
> On Sun, Apr 28, 2019 at 11:14:06AM -0700, syzbot wrote:
> > down_read+0x49/0x90 kernel/locking/rwsem.c:26
> > __get_super.part.0+0x203/0x2e0 fs/super.c:788
> > __get_super include/linux/spinlock.h:329 [inline]
> > get_super+0x2e/0x50
v5.1-rc7 fails to build on s390x due to
vmf->page = ZERO_PAGE(vmf->vm_start);
from commit 67f269b37f9b ("RDMA/ucontext: Fix regression with
disassociate"). This is not a problem on x86_64 where ZERO_PAGE()
doesn't use its argument but s390 version does.
I suppose the line should
On 26-04-19, 15:41, Arnaud Pouliquen wrote:
> >> During residue calculation. the DMA can switch to the next sg. When
> >> this race condition occurs, the residue returned value is not valid.
> >> Indeed the position in the sg returned by the hardware is the position
> >> of the next sg, not the
On 28-04-19, 12:00, Kefeng Wang wrote:
> Using dev_get_drvdata directly.
>
Applied both, thanks
--
~Vinod
On 28-04-19, 02:00, Peng Ma wrote:
> Hi Vinod,
>
> Thanks your comments.
> Please see my comments inline.
>
> Best Regards,
> Peng
>
> >-Original Message-
> >From: Vinod Koul
> >Sent: 2019年4月26日 19:51
> >To: Peng Ma
> >Cc: dan.j.willi...@intel.com; Leo Li ;
>
On 26-04-19, 06:55, Vabhav Sharma wrote:
> Enable support of NXP SoC lx2160a to handle the
> lx2160a SoC.
>
> Signed-off-by: Tang Yuantian
> Signed-off-by: Yogesh Gaur
> Signed-off-by: Vabhav Sharma
> Acked-by: Scott Wood
> Acked-by: Stephen Boyd
> Acked-by: Viresh Kumar
> ---
> Changes for
From: Ira Weiny
Signed-off-by: Ira Weiny
---
fs/locks.c | 20 ++-
include/trace/events/filelock.h | 35 +
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index
Hi,
>>> I'm thinking about whether we should lock down the powerpc xmon debug
>>> monitor - intuitively, I think the answer is yes if for no other reason
>>> than Least Astonishment, when lockdown is enabled you probably don't
>>> expect xmon to keep letting you access kernel memory.
>>
>> The
From: Ira Weiny
---
fs/locks.c | 1 +
include/trace/events/filelock.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/locks.c b/fs/locks.c
index c77eee081d11..42b96bfc71fa 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1592,6 +1592,7 @@ static void
From: Ira Weiny
In order to support longterm lease breaking operations. Lease break
code in the file systems need to know if a mapping is DAX.
Split out the logic to determine if a mapping is DAX and export it.
---
fs/dax.c| 23 ---
include/linux/dax.h | 6
From: Ira Weiny
In order to support RDMA to File system pages[*] without On Demand Paging a
number of things need to be done.
1) GUP "longterm"[1] users need to inform the other subsystems that they have
taken a pin on a page which may remain pinned for a very "long time".[1]
2) Any page
From: Ira Weiny
If a user has failed to take a F_LONGTERM lease on a file and they
do a longterm pin on the pages associated with a file, take a
FL_LONGTERM lease for them.
If the user has not taken a lease on the file they are trying to pin
create a FL_LONGTERM lease and attach it to the inode
From: Ira Weiny
---
fs/locks.c | 5 +
include/trace/events/filelock.h | 37 -
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/fs/locks.c b/fs/locks.c
index ae508d192223..58c6d7a411b6 100644
--- a/fs/locks.c
+++
From: Ira Weiny
Now that there is a mechanism for users to safely take LONGTERM pins on
FS DAX pages. Remove the FS DAX exclusion from GUP with FOLL_LONGTERM.
Special processing remains in effect for CONFIG_CMA
---
mm/gup.c | 65 ++--
1 file
From: Ira Weiny
Now that the taking of LONGTERM leases is in place we can now facilitate
sending a SIGBUS to process if a file truncate or hole punch is
performed and they do not respond by releasing the lease.
The standard file lease_break_time is used to time out the LONGTERM
lease which is
From: Ira Weiny
Honestly I think I should remove this patch. It is removed later in the
series and ensuring the lease is there at GUP time does not guarantee
the lease is held. The user could remove the lease???
Regardless the code in GUP to take the lease holds it even if the user
does try
From: Ira Weiny
GUP longterm pins of non-pagecache file system pages (FS DAX) are
currently disallowed because they are unsafe.
The danger for pinning these pages comes from the fact that hole punch
and/or truncate of those files results in the pages being mapped and
pinned by a user space
From: Ira Weiny
In order to support taking and/or checking for a LONGTERM lease on a FS
DAX inode these calls need to know if FOLL_LONGTERM was specified.
This patch passes the flags down but does not use them. It does this in
prep for 2 future patches.
---
mm/gup.c | 26
Currently there is no way to distinguish if the SoC entered DS0
mode or the RTC only mode. Hence add a print before entering
the RTC only mode.
Signed-off-by: Keerthy
---
drivers/soc/ti/pm33xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/ti/pm33xx.c
Hi Mark,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/spi/spi-ep93xx.c: In function 'ep93xx_spi_probe':
drivers/spi/spi-ep93xx.c:654:6: warning: unused variable 'i' [-Wunused-variable]
int i;
^
Introduced by commit
On 28-04-19, 17:17, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 9bd1be60f55b ("dmaengine: stm32-dma: Fix unsigned variable compared with
> zero")
>
> Fixes tag
>
> Fixes: f4fd2ec08f17: ("dmaengine: stm32-dma: use platform_get_irq()")
>
> has these problem(s):
>
> - The colon
On Mon, Apr 22, 2019 at 05:10:45PM +0800, Baoquan He wrote:
> kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
> to support the maximum amount of system RAM in 4-level paging mode, 64 TB.
>
> However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming
> the
I thought this script was run via "make tags" etc. but some people
run it directly.
Prior to commit a9a49c2ad9b9 ("kbuild: use $(srctree) instead of
KBUILD_SRC to check out-of-tree build"), in such a usecase, "tree"
was set empty since KBUILD_SRC is undefined. Now, "tree" is set to
"${srctree}/",
During suspend/resume, mtk_eint_mask may be called while
wake_mask is active. For example, this happens if a wake-source
with an active interrupt handler wakes the system:
irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so
that it can be handled later on in the resume flow.
However,
This fixes 2 issues when resuming from a wake source, especially if these
wake sources are level-sensitive.
Tested on mt8183 with the series in
https://patchwork.kernel.org/cover/10921121/,
but this should affect all mediatek platforms.
Nicolas Boichat (2):
pinctrl: mediatek: Ignore
Before suspending, mtk-eint would set the interrupt mask to the
one in wake_mask. However, some of these interrupts may not have a
corresponding interrupt handler, or the interrupt may be disabled.
On resume, the eint irq handler would trigger nevertheless,
and irq/pm.c:irq_pm_check_wakeup would
On Tue, Apr 23, 2019 at 06:45:27PM +, Vineeth Remanan Pillai wrote:
> >> - Processes with different tags can still share the core
>
> > I may have missed something... Could you explain this statement?
>
> > This, to me, is the whole point of the patch series. If it's not
> > doing this then
On 二, 2019-04-23 at 15:50 +0800, Kefeng Wang wrote:
> Using dev_get_drvdata directly.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Daniel Lezcano
> Cc: linux...@vger.kernel.org
> Signed-off-by: Kefeng Wang
> ---
> .../intel/int340x_thermal/processor_thermal_device.c | 8 +-
> --
>
"Enrico Weigelt, metux IT consult" writes:
> Formatting of Kconfig files doesn't look so pretty, so let the
> Great White Handkerchief come around and clean it up.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
> arch/powerpc/Kconfig | 28
On Tue, Apr 23, 2019 at 04:18:16PM +, Vineeth Remanan Pillai wrote:
> +/*
> + * l(a,b)
> + * le(a,b) := !l(b,a)
> + * g(a,b) := l(b,a)
> + * ge(a,b) := !l(a,b)
> + */
> +
> +/* real prio, less is less */
> +static inline bool __prio_less(struct task_struct *a, struct task_struct *b,
> bool
Setting this up will configure wake from suspend properly,
and wake only for the interrupts that are setup in wake_mask,
not all interrupts.
Signed-off-by: Nicolas Boichat
Reviewed-by: Chuanjia Liu
---
drivers/pinctrl/mediatek/pinctrl-mt8183.c | 1 +
1 file changed, 1 insertion(+)
diff --git
pinctrl variants that include pinctrl-mtk-common-v2.h (and not
pinctrl-mtk-common.h) also need to use mtk_eint_pm_ops to setup
wake mask properly, so copy over the pm_ops to v2.
It is not easy to merge the 2 copies (or move
mtk_eint_suspend/resume to mtk-eint.c), as we need to
dereference
This adds support for wake sources in pinctrl-mtk-common-v2, and
pinctrl-mt8183. Without this patch, all interrupts that are left
enabled on suspend act as wake sources (and wake sources without
interrupt enabled do not).
Nicolas Boichat (2):
pinctrl: mediatek: Add mtk_eint_pm_ops to common-v2
On Sat, Apr 27, 2019 at 12:29 AM Alexey Gladkov
wrote:
>
> On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote:
> > On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu wrote:
> > >
> > > +++ Masahiro Yamada [19/04/19 00:26 +0900]:
> > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote:
>
The pllv4 supports fractional-N function, the formula is:
PLL output freq = input * (mult + num/denom),
This patch adds fractional-N function support, including
clock round rate, calculate rate and set rate, with this
patch, the clock rate of APLL in clock tree is more accurate
than before:
Hi Lorenzo,
Thanks a lot for your comments, I am waiting for this patches approve of
http://patchwork.ozlabs.org/project/linux-pci/list/?series=102378, and once
these patches approved, I will resent the patches base on the latest base.
Best regards
Xiaowei
-Original Message-
From:
On Sun, Apr 28, 2019 at 5:28 PM Waiman Long wrote:
>
> Not really, this is a serious problem that have to be backported to
> earlier stable releases and downstream. The clever code is helpful in
> those cases.
Fair enough, I guess the code will live in the stable trees for a longish while.
On 2019/4/28 20:17, Ingo Molnar wrote:
>
> * Aubrey Li wrote:
>
>> On Sun, Apr 28, 2019 at 5:33 PM Ingo Molnar wrote:
>>> So because I'm a big fan of presenting data in a readable fashion, here
>>> are your results, tabulated:
>>
>> I thought I tried my best to make it readable, but this one
> From: S.j. Wang
> Sent: Sunday, April 28, 2019 5:53 PM
>
> Add macros to define masks and bits for imx6sx MQS registers
>
> Signed-off-by: Shengjiu Wang
Reviewed-by: Dong Aisheng
Regards
Dong Aisheng
Greetings Friend
Forgive me for writing you this letter , I will like to bring to your that
(8.5.million Euro claims ) This is a legitimate transaction and The money will
be shared 60% for me and 40% for you . get back to me, I will give you full
details on how the money will be transfer to
On Fri 26-04-19 04:13:00, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> general protection fault in fanotify_handle_event
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
>
On 2019/04/29 3:51, Al Viro wrote:
> ioctl(..., BLKRRPART) blocked on ->s_umount in __get_super().
> The trouble is, the only things holding ->s_umount appears to be
> these:
Not always true. lockdep_print_held_locks() from debug_show_all_locks() can not
report locks held by TASK_RUNNING threads.
On 2019年04月28日 18:03, Borislav Petkov wrote:
On Sun, Apr 28, 2019 at 09:56:35AM +0800, Zhao, Yakui wrote:
Thanks for the reminder about the access width.
It is 64-bit register. What I said is the "movq", not "movl".
(I understand that movl is incorrect for 64-bit register).
I didn't say
On Sun, Apr 28, 2019 at 07:02:58PM -0500, Bjorn Helgaas wrote:
> On Sat, Apr 27, 2019 at 02:13:01PM -0500, f...@fredlawl.com wrote:
> > From: Frederick Lawler
> >
> > Replace remaining instances of dev_*() printk wrappers with pci_*()
> > printk wrappers. No functional change intended.
> >
> >
On Sat, Apr 27, 2019 at 10:03:01PM +0200, Lukas Wunner wrote:
> On Sat, Apr 27, 2019 at 02:13:02PM -0500, f...@fredlawl.com wrote:
> > Hotplug useses custom ctrl_*() dev_*() printk wrappers for logging
> > messages. To make hotplug conform to pci logging, replace uses of these
> > wrappers with
--
Dear Friend (Assalamu Alaikum),
I came across your e-mail contact prior a private search while in need of
your assistance. My name is Aisha Al-Qaddafi a single Mother and a Widow
with three Children. I am the only biological Daughter of late Libyan
President (Late Colonel Muammar Gaddafi).
On 4/28/19 8:10 PM, Linus Torvalds wrote:
> On Sun, Apr 28, 2019 at 4:12 PM Waiman Long wrote:
>> I implemented your suggestion in patch 1 as it will produce simpler and
>> faster code. However, one of the changes in my patchset is to wake up
>> all the readers in the wait list. This means I have
If rc6 was bigger than I wished, it really does seem to have been just
due to timing of pull requests. Because rc7 is tiny.
Just under half of the patch is various kinds of networking changes: a
mix of core networking, network drivers and some netfilter selftests.
The rest is mostly the usual
On Sat, Apr 27, 2019 at 02:13:04PM -0500, f...@fredlawl.com wrote:
> From: Frederick Lawler
>
> Add dev_fmt() to port drivers.
>
> Signed-off-by: Frederick Lawler
> ---
> drivers/pci/hotplug/pciehp_core.c | 3 +++
> drivers/pci/hotplug/pciehp_ctrl.c | 2 ++
>
On Sun, Apr 28, 2019 at 4:12 PM Waiman Long wrote:
>
> I implemented your suggestion in patch 1 as it will produce simpler and
> faster code. However, one of the changes in my patchset is to wake up
> all the readers in the wait list. This means I have to jump over the
> writers and wake up the
On Sun, Apr 28, 2019 at 06:55:36PM +0300, Andy Shevchenko wrote:
> On Sat, Apr 27, 2019 at 02:13:03PM -0500, f...@fredlawl.com wrote:
> > Now that all uses for the ctrl_*() printk wrappers are removed from
> > files and replaces with pci_*() or pr_*() printk wrappers, remove the
> > unused macro
On Sun, Apr 28, 2019 at 4:49 PM Jason Gunthorpe wrote:
>
> It is for high availability - we have situations where the hardware
> can fault and needs some kind of destructive recovery. For instance a
> firmware reboot, or a VM migration.
>
> In these designs there may be multiple cards in the
On Sat, Apr 27, 2019 at 02:13:01PM -0500, f...@fredlawl.com wrote:
> From: Frederick Lawler
>
> Replace remaining instances of dev_*() printk wrappers with pci_*()
> printk wrappers. No functional change intended.
>
> Signed-off-by: Frederick Lawler
> ---
> drivers/pci/pcie/aer.c| 13
The documentation of __GFP_RETRY_MAYFAIL clearly mentioned that the
OOM killer will not be triggered and indeed the page alloc does not
invoke OOM killer for such allocations. However we do trigger memcg
OOM killer for __GFP_RETRY_MAYFAIL. Fix that.
Signed-off-by: Shakeel Butt
---
On Wed, Apr 24, 2019 at 11:49 PM Michal Hocko wrote:
>
> On Tue 23-04-19 08:44:05, Shakeel Butt wrote:
> > The commit 475d0487a2ad ("mm: memcontrol: use per-cpu stocks for socket
> > memory uncharging") added refill_stock() for skmem uncharging path to
> > optimize workloads having high network
On Sun, Apr 28, 2019 at 09:59:56AM -0700, Linus Torvalds wrote:
> On Sun, Apr 28, 2019 at 4:52 AM Jason Gunthorpe wrote:
> >
> > Nothing particularly special here. There is a small merge conflict
> > with Adrea's mm_still_valid patches which is resolved as below:
>
> I still don't understand
> On Apr 28, 2019, at 2:22 PM, Nicolai Stange wrote:
>
> Steven Rostedt writes:
>
>> On Sun, 28 Apr 2019 10:41:10 -0700
>> Andy Lutomirski wrote:
>>
>>
Note that at any given point
in time, there can be at most four such call insn emulations pending:
namely at most one per
On 23/04/2019 07:59, Zhang Rui wrote:
> Hi, Daniel,
>
> thanks for clarifying.
> It is true that we need to make thermal framework ready as early as
> possible. And a static table works for me as long as vmlinux.lds.h is
> the proper place.
>
> Arnd,
> are you okay with this patch? if yes, I
On 4/28/19 7:12 PM, Waiman Long wrote:
> On 4/28/19 6:46 PM, Linus Torvalds wrote:
>> This doesn't seem to be the full diff - looking at that patch 1 you
>> seem to have taken my suggested list_cut_before() change too.
>>
>> I'm not against it (it does seem to be simpler and better), I just
>>
On 4/28/19 6:46 PM, Linus Torvalds wrote:
> This doesn't seem to be the full diff - looking at that patch 1 you
> seem to have taken my suggested list_cut_before() change too.
>
> I'm not against it (it does seem to be simpler and better), I just
> hope you double-checked it, since I kind of
On Sun, Apr 28 2019, Lukas Bulwahn wrote:
> rdev_attr_store() should lock and unlock mddev->reconfig_mutex in a
> balanced way with mddev_lock() and mddev_unlock().
It does.
>
> But when rdev->mddev is NULL, rdev_attr_store() would try to unlock
> without locking before. Resolve this locking
This doesn't seem to be the full diff - looking at that patch 1 you
seem to have taken my suggested list_cut_before() change too.
I'm not against it (it does seem to be simpler and better), I just
hope you double-checked it, since I kind of hand-waved it.
Linus
On Sun, Apr
On Wed 24-04-19 14:20:13, Joel Savitz wrote:
> In the event of an oom kill, useful information about the killed
> process is printed to dmesg. Users, especially system administrators,
> will find it useful to immediately see the UID of the process.
>
> In the following example, abuse_the_ram is
On Mon, Apr 29, 2019, at 02:15, Greg Kroah-Hartman wrote:
> On Sun, Apr 28, 2019 at 11:19:57AM +1000, Tobin C. Harding wrote:
> > On Sat, Apr 27, 2019 at 09:28:09PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 27, 2019 at 06:13:30PM +1000, Tobin C. Harding wrote:
> > > > (Note at bottom on
On Fri, Apr 26, 2019 at 04:41:08PM +0200, Andrea Parri wrote:
> On Mon, Apr 22, 2019 at 12:18:09PM -0400, Alan Stern wrote:
> > This patch adds data-race detection to the Linux-Kernel Memory Model.
> > As part of this effort, support is added for:
> >
> > compiler barriers (the barrier()
On 12/04/19 8:29 PM, Mark Brown wrote:
> On Fri, Apr 12, 2019 at 05:02:10PM +1200, Chris Packham wrote:
>
>> Unfortunately recent changes have stopped my hacks from working. I've
>> tried adapting cs-gpios to work with my particular hardware but I came
>> to the realisation that the current
On Fri, Apr 26, 2019 at 7:43 AM Lucas Stach wrote:
>
> Hi Andrey,
>
> Am Mittwoch, den 17.04.2019, 01:44 -0700 schrieb Andrey Smirnov:
> > Add driver for Microchip UCS1002 Programmable USB Port Power
> > Controller with Charger Emulation. The driver exposed a power supply
> > device to
On Sat, Apr 27, 2019 at 02:02:30PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 25, 2019 at 06:50:55PM +0200, Oleg Nesterov wrote:
> > With this patch rcu_sync has a single state variable and the transition
> > rules
> > become really simple:
> >
> > GP_IDLE - owned by the first
Because of writer lock stealing, it is possible that a constant
stream of incoming writers will cause a waiting writer or reader to
wait indefinitely leading to lock starvation.
This patch implements a lock handoff mechanism to disable lock stealing
and force lock handoff to the first waiter or
On 64-bit architectures, each rwsem writer will have its unique lock
word for acquiring the lock. Right now, the writer code recomputes the
lock word every time it tries to acquire the lock. This is a waste of
time. The lock word is now cached and reused when it is needed.
When
During my rwsem testing, it was found that after a down_read(), the
reader count may occasionally become 0 or even negative. Consequently,
a writer may steal the lock at that time and execute with the reader
in parallel thus breaking the mutual exclusion guarantee of the write
lock. In other
With separate count and owner, there are timing windows where the two
values are inconsistent. That can cause problem when trying to figure
out the exact state of the rwsem. For instance, a RT task will stop
optimistic spinning if the lock is acquired by a writer but the owner
field isn't set yet.
The owner field in the rw_semaphore structure is used primarily for
optimistic spinning. However, identifying the rwsem owner can also be
helpful in debugging as well as tracing locking related issues when
analyzing crash dump. The owner field may also store state information
that can be important
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can help performance by avoiding
spinning on the
Reader optimistic spinning is helpful when the reader critical section
is short and there aren't that many readers around. It makes readers
relatively more preferred than writers. When a writer times out spinning
on a reader-owned lock and set the nospinnable bits, there are two main
reasons for
It is very unlikely that successive preemption at the middle of
down_read's inc-check-dec sequence will cause the reader count to
overflow, For absolute correctness, however, we still need to prevent
that possibility from happening. So preemption will be disabled during
the down_read*() call.
For
v7:
- Fix a bug in patch 1 and include changes suggested by Linus.
- Refresh the other patches accordingly.
v6:
- Add a new patch 1 to fix an existing rwsem bug that allows both
readers and writer to become rwsem owners simultaneously.
- Fix a missed wakeup bug (in patch 9) of the
When the rwsem is owned by reader, writers stop optimistic spinning
simply because there is no easy way to figure out if all the readers
are actively running or not. However, there are scenarios where
the readers are unlikely to sleep and optimistic spinning can help
performance.
This patch
The current way of using various reader, writer and waiting biases
in the rwsem code are confusing and hard to understand. I have to
reread the rwsem count guide in the rwsem-xadd.c file from time to
time to remind myself how this whole thing works. It also makes the
rwsem code harder to be
Bit 1 of sem->owner (RWSEM_ANONYMOUSLY_OWNED) is used to designate an
anonymous owner - readers or an anonymous writer. The setting of this
anonymous bit is used as an indicator that optimistic spinning cannot
be done on this rwsem.
With the upcoming reader optimistic spinning patches, a
An RT task can do optimistic spinning only if the lock holder is
actually running. If the state of the lock holder isn't known, there
is a possibility that high priority of the RT task may block forward
progress of the lock holder if it happens to reside on the same CPU.
This will lead to
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of optimistic spinning, the lock acquisition order is
Before combining owner and count, we are adding two new helpers for
accessing the owner value in the rwsem.
1) struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
2) bool is_rwsem_reader_owned(struct rw_semaphore *sem)
Signed-off-by: Waiman Long
---
kernel/locking/rwsem.c | 41
The upper bits of the count field is used as reader count. When
sufficient number of active readers are present, the most significant
bit will be set and the count becomes negative. If the number of active
readers keep on piling up, we may eventually overflow the reader counts.
This is not likely
After merging all the relevant rwsem code into one single file, there
are a number of optimizations and cleanups that can be done:
1) Remove all the EXPORT_SYMBOL() calls for functions that are not
accessed elsewhere.
2) Remove all the __visible tags as none of the functions will be
1 - 100 of 234 matches
Mail list logo
