On Wed, Jan 30, 2019 at 04:18:48AM +, Jason Gunthorpe wrote:
> Every attempt to give BAR memory to struct page has run into major
> trouble, IMHO, so I like that this approach avoids that.
Way less problems than not having struct page for doing anything
non-trivial. If you map the BAR to
On Tue, Jan 29, 2019 at 08:58:35PM +, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
>
> > implement the mapping. And I don't think we should have 'special' vma's
> > for this (though we may need something to ensure we don't get mapping
> > requests
On Wed, Jan 30, 2019 at 08:57:47AM +0100, Ulf Hansson wrote:
> On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote:
> >
> > Instead of setting up a kernel pointer to track the current PIO address,
> > track the offset in the current page, and do an atomic kmap for the page
> > while doing the
On Tue, 22 Jan 2019, Zhenzhong Duan wrote:
> On a large system with many CPUs, using PMTMR as the clock source can
> have a significant impact on the overall system performance because
> of the following reasons:
> 1) There is a single PMTMR counter shared by all the CPUs.
> 2) PMTMR counter
Le 24/01/2019 à 17:19, Christophe Leroy a écrit :
40x/booke have another path to reach 3f from transfer_to_handler,
so ACCOUNT_CPU_USER_ENTRY() have to be moved there.
Signed-off-by: Christophe Leroy
Now ACCOUNT_CPU_USER_ENTRY() is also in the non-user entry path.
This change is crazy,
Hi Geert,
On 30/01/2019 08:35, Geert Uytterhoeven wrote:
Hi Jonas,
On Tue, Jan 29, 2019 at 9:55 PM Jonas Bonn wrote:
Some devices are slow and cannot keep up with the SPI bus and therefore
require a short delay between words of the SPI transfer.
The example of this that I'm looking at is a
On Tue, Jan 29, 2019 at 5:06 PM Michael S. Tsirkin wrote:
>
> On Tue, Jan 29, 2019 at 01:22:02AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:983542434e6b Merge tag 'edac_fix_for_5.0' of git://git.ker..
> > git tree: upstream
> >
On 29/01/2019 at 19:06, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement
> may
On 29.01.2019 23:29, Yang Shi wrote:
> ksmd need search stable tree to look for the suitable KSM page, but the
> KSM page might be locked for a while due to i.e. KSM page rmap walk.
> Basically it is not a big deal since commit 2c653d0ee2ae
> ("ksm: introduce ksm_max_page_sharing per page
On Tue, Jan 29, 2019 at 05:13:18PM +0530, Yash Shah wrote:
> DT documentation for PWM controller added.
>
> Signed-off-by: Wesley W. Terpstra
> [Atish: Compatible string update]
> Signed-off-by: Atish Patra
> Signed-off-by: Yash Shah
> ---
> .../devicetree/bindings/pwm/pwm-sifive.txt
Hi,
(changed the subject and added CRIU folks)
On Tue, Jan 29, 2019 at 06:40:58PM -0500, Andrea Arcangeli wrote:
> Hello,
>
> --
>
> In addition to the above "NUMA remote THP vs NUMA local non-THP
> tradeoff" topic, there are other developments in "userfaultfd" land that
> are approaching
Hi Jonas,
On Wed, Jan 30, 2019 at 9:10 AM Jonas Bonn wrote:
> On 30/01/2019 08:35, Geert Uytterhoeven wrote:
> > On Tue, Jan 29, 2019 at 9:55 PM Jonas Bonn wrote:
> >> Some devices are slow and cannot keep up with the SPI bus and therefore
> >> require a short delay between words of the SPI
On 29/01/2019 at 21:55, Jonas Bonn wrote:
> If the SPI slave requires an inter-word delay, configure the DLYBCT
> register accordingly.
>
> Tested on a SAMA5D2 board (derived from SAMA5D2-Xplained reference
> board).
>
> Signed-off-by: Jonas Bonn
> CC: Nicolas Ferre
> CC: Mark Brown
> CC:
A deadlock has been seen when swicthing clocksources which use PM runtime.
The call path is:
change_clocksource
...
write_seqcount_begin
...
timekeeping_update
...
sh_cmt_clocksource_enable
...
rpm_resume
On Wed, 30 Jan 2019 at 09:04, Christoph Hellwig wrote:
>
> On Wed, Jan 30, 2019 at 08:57:47AM +0100, Ulf Hansson wrote:
> > On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote:
> > >
> > > Instead of setting up a kernel pointer to track the current PIO address,
> > > track the offset in the
From: Hans Holmberg
pblk stripes writes of minimal write size across all non-offline chunks
in a line, which means that the maximum write pointer delta should not
exceed the minimal write size.
Extend the line write pointer balance check to cover this case, and
ignore the offline chunk wps.
On Tue, 29 Jan 2019, Lucas De Marchi wrote:
> On Tue, Jan 29, 2019 at 2:39 PM Stephen Rothwell
> wrote:
>>
>> Hi all,
>>
>> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/gpu/drm/i915/intel_display.c: In function
Hi Vincent,
On Wed, Jan 30, 2019 at 9:16 AM Vincent Guittot
wrote:
> A deadlock has been seen when swicthing clocksources which use PM runtime.
> The call path is:
> change_clocksource
> ...
> write_seqcount_begin
> ...
> timekeeping_update
> ...
>
On Thu, Jan 24, 2019 at 02:16:43PM +0800, Kai-Heng Feng wrote:
> The QCA Rome USB Bluetooth controller has several issues once LPM gets
> enabled:
> - Fails to get enumerated in coldboot. [1]
> - Drains more power (~ 0.2W) when the system is in S5. [2]
> - Disappears after a warmboot. [2]
>
> The
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added when adding PCI devices
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
parameter.
The
Don't allow memory to be added above the allowed maximum allocation
limit set by Xen.
Trying to do so would result in cases like the following:
[ 584.559652] [ cut here ]
[ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129
Steve Wise wrote on 01/29/2019 06:44:48 PM:
>
> On 1/29/2019 7:26 AM, Joel Nider wrote:
> > As discussed at LPC'18, there is a need to be able to register a
memory
> > region (MR) on behalf of another process. One example is the case of
> > post-copy container migration, in which CRIU is
Now if a new device replaced a old device, the sas address will change.
We unregister the old device and discover the new device in one
revalidation process. But after we deferred the sas_port_delete(), the
sas port is not deleted when we registering the new port and device.
The sas port cannot be
If the device is unplugged or disconnected, the negotiated_linkrate
still can be seen from the userspace by sysfs. This makes people
confused and leaks information of the device last used. So let's reset
the negotiated_linkrate after the phy is down.
Signed-off-by: Jason Yan
CC: John Garry
CC:
When we failed to discover the device, the phy address is still kept
in ex_phy. So when the next time we revalidate this phy the
address and device type is the same, it will be considered as flutter
and will not be discovered again. So the device will not be brought up.
Fix this by reset the phy
When the event queue is full of phy up and down events and reached the
threshold, we will queue a shutdown-event, and set phy->in_shutdown so
that we will not queue a shutdown-event again. But before the
shutdown-event can be executed, every phy-down event will clear
phy->in_shutdown and a new
The work flow of revalidation now is scanning expander phy by the
sequence of the phy and check if the phy have changed. This will leads
to some issues of swapping disks or replacing a disk with a new one.
This patchset addresses the issues above by these main changes:
1. Let the revalidation
The work flow of revalidation now is scanning expander phy by the
sequence of the phy and check if the phy have changed. This will leads
to an issue of swapping two sas disks on one expander.
Assume we have two sas disks, connected with expander phy10 and phy11:
phy10: 5000cca04eb1001d
On 30/01/19 01:59, Luwei Kang wrote:
> Some Posted-Interrupts from passthrough devices may be lost or
> overwritten when the vCPU is in runnable state.
>
> The SN (Suppress Notification) of PID (Posted Interrupt Descriptor) will
> be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
The ata device do not have a real sas address. If a ata device is
replaced with another one, the sas address is the same. Now libsas treat
this scenario as flutter and do not delete the old one and discover the
new one. This will cause the data read from or write to the wrong
device.
And also
sas_rediscover() returns error code if discover failed for a expander
phy. And sas_ex_revalidate_domain() only returns the last phy's error
code. So when sas_revalidate_domain() prints the return value of the
discover process, we do not know if the revalidation for every phy is
successful or not.
On Mon, Jan 21, 2019 at 07:01:42PM -0500, Theodore Y. Ts'o wrote:
> On Mon, Jan 21, 2019 at 05:26:42PM +0100, Greg Kroah-Hartman wrote:
> > By default, the kernel will automatically load the module of any line
> > dicipline that is asked for. As this sometimes isn't the safest thing
> > to do,
On 29/01/19 09:29, Yang Weijiang wrote:
> On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote:
>> On 28/01/19 11:33, Yang Weijiang wrote:
There is no code in this series to pass these fields to and from
userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and
linux-rdma-ow...@vger.kernel.org wrote on 01/29/2019 07:04:06 PM:
> On Tue, Jan 29, 2019 at 03:26:26PM +0200, Joel Nider wrote:
> > Add a new handler for new uverb reg_remote_mr. The purpose is to
register
> > a memory region in a different address space (i.e. process) than the
> > caller.
> >
Dropped in favor of https://lkml.org/lkml/2019/1/29/910
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Changed in v6:
* Changed name of field word_delay_us to word_delay_usecs as per
suggestion in patch review
* Add Nicolas' ACK to spi-atmel patch
Changed in v5:
* Rebased on linux-next
* Fixed up Atmel patch to simplify register setting
Changed in v4:
* Rename word_delay to word_delay_us and
If the SPI slave requires an inter-word delay, configure the DLYBCT
register accordingly.
Tested on a SAMA5D2 board (derived from SAMA5D2-Xplained reference
board).
Signed-off-by: Jonas Bonn
Acked-by: Nicolas Ferre
CC: Nicolas Ferre
CC: Mark Brown
CC: Alexandre Belloni
CC: Ludovic Desroches
Some devices are slow and cannot keep up with the SPI bus and therefore
require a short delay between words of the SPI transfer.
The example of this that I'm looking at is a SAMA5D2 with a minimum SPI
clock of 400kHz talking to an AVR-based SPI slave. The AVR cannot put
bytes on the bus fast
On Tue, Jan 29, 2019 at 05:28:48PM +0900, Sugaya, Taichi wrote:
> Hi,
>
> On 2019/01/22 20:50, Russell King - ARM Linux admin wrote:
> > On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
> > > Hi
> > >
> > > On 2018/12/04 22:32, Rob Herring wrote:
> > > > On Tue, Dec 4, 2018 at
The Bananapi M2+ uses a GPIO line to change the effective resistance of
the CPU supply regulator's feedback resistor network. The voltages
described in the device tree were given directly by the vendor. This
turns out to be slightly off compared to the real values.
The updated voltages are based
Hi everyone,
This series enables DVFS for the CPU cores (aka cpufreq) on the
Allwinner H5 SoC. The OPP table was taken from Armbian, with minor
tweaks to the maximum voltage to account for slightly increased voltage
on some of the boards.
This has been tested on the Bananapi M2+ v1.2 and Libre
The OrangePi Zero Plus 2 uses a fixed regulator to supply the CPU cores.
The feedback resistor network can be changed by toggling a GPIO line.
This is effectively a GPIO controlled regulator that can change between
roughly 1.1V and 1.3V. The actual voltage is slightly higher. The values
used in
The OrangePi PC 2 uses a Silergy SY8106A regulator to supply the CPU
cores. The fixed voltage when I2C programmed regulation is not in action
is slightly higher than 1.1V. The value in the device tree description
is based on calculations of the resistor values from the schematics.
Cc: Andre
Some of the device trees for H5 boards already have the CPU supply
regulator defined, but they are not referenced in the CPU node.
Add the reference, so CPU DVFS mechanisms can see them.
Signed-off-by: Chen-Yu Tsai
---
.../boot/dts/allwinner/sun50i-h5-emlid-neutis-n5-devboard.dts | 4
The OrangePi Zero Plus uses a fixed regulator to supply the CPU cores.
The feedback resistor network can be changed by toggling a GPIO line.
This is effectively a GPIO controlled regulator that can change between
roughly 1.1V and 1.3V. The actual voltage is slightly higher. The values
used in the
Add an OPP (Operating Performance Points) table for the CPU cores to
enable DVFS (Dynamic Voltage & Frequency Scaling) on the H5. The table
originates from Armbian, but the maximum voltage is raised slightly to
account for boards using slightly higher voltages.
This has been tested on the Libre
The original Bananapi M2+ uses a fixed regulator to supply the CPU
cores. According to Bananapi, the retail v1.1 version is designed to
supply 1.3V. Actual measurements show 1.310V. Earlier engineering
samples had it at 1.4V, but this is not covered here.
Signed-off-by: Chen-Yu Tsai
---
The Nanopi Neo 2 uses a fixed regulator to supply the CPU cores. The
feedback resistor network can be changed by toggling a GPIO line. This
is effectively a GPIO controlled regulator that can change between 1.1V
and 1.3V.
Cc: Icenowy Zheng
Signed-off-by: Chen-Yu Tsai
---
This patch is based
The ARM CPU cores are fed by the CPU clock from the CCU. Add a
reference to the clock for each CPU core, along with the clock
transition latency.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 8
1 file changed, 8 insertions(+)
diff --git
The OrangePi Prime uses a Silergy SY8106A regulator to supply the CPU
cores. The fixed voltage when I2C programmed regulation is not in action
is slightly higher than 1.1V. The value in the device tree description
is based on calculations of the resistor values from the schematics.
Cc: Icenowy
On Mon 2019-01-21 13:14:38, Miroslav Benes wrote:
> Hi,
>
> On Wed, 16 Jan 2019, Petr Mladek wrote:
>
> > Do not dereference pointers to the shadow variables when either
> > klp_shadow_alloc() or klp_shadow_get() fail.
>
> I may misunderstand the patch, so bear with me, please. Is this because
This patch adds Q6V5 ADSP pil remoteproc node
for SDM845 SoC.
Signed-off-by: Rohit kumar
---
Changes since v1:
Addressed comments given by Bjorn.
This depends on below upstream patch which defines adsp_mem node:
https://lkml.org/lkml/2019/1/29/1392
arch/arm64/boot/dts/qcom/sdm845.dtsi | 89
Hi Alex,
On 1/30/19 12:16 AM, Alex Williamson wrote:
> On Fri, 25 Jan 2019 17:49:20 +0100
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 1/11/19 10:30 PM, Alex Williamson wrote:
>>> On Tue, 8 Jan 2019 11:26:14 +0100
>>> Eric Auger wrote:
>>>
From: "Liu, Yi L"
In any
On Tue, Jan 29, 2019 at 08:25:58AM +0100, Laura Abbott wrote:
> On 1/23/19 5:24 AM, Heiko Carstens wrote:
> >On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
> >>There's a build failure with gcc9:
...
> >Hmmm, this works only for the kernel image, but not for modules, which
> >we
On Mon 2019-01-21 17:40:12, Joe Lawrence wrote:
> On Wed, Jan 16, 2019 at 05:17:18PM +0100, Petr Mladek wrote:
> > Do not dereference pointers to the shadow variables when either
> > klp_shadow_alloc() or klp_shadow_get() fail.
> >
> > There is no need to check the other locations explicitly. The
Hi Hans,
For I frame min QP, if global min QP is set, the QP choose algorithm
should meet both of them, hence QP will >=
max(V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP,
V4L2_CID_MPEG_VIDEO_H264_MIN_QP).
And this is also the same to the P frame and max QP.
I can add some description to describe this
The #mtd channel (on OFTC servers) is being used to discuss MTD related
topics. Add it to the MTD entry.
Signed-off-by: Boris Brezillon
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 51029a425dbe..7b39ba46384a 100644
--- a/MAINTAINERS
+++
Hi Rajmohan,
On Tue, Jan 29, 2019 at 02:27:36PM -0800, Rajmohan Mani wrote:
> Currently concurrent stream off operations on ImgU nodes are not
> synchronized, leading to use-after-free bugs (as reported by KASAN).
>
> [ 250.090724] BUG: KASAN: use-after-free in ipu3_dmamap_free+0xc5/0x116
>
Hi all,
I prefer to fix it. I guess people used their own correction.
I will send you a fix asap.
Best Regards
Gabriel
On 1/27/19 2:20 AM, Ken Sloat wrote:
> On Sat, Jan 26, 2019 at 5:15 PM Dmitry Torokhov
> wrote:
>> On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
>> wrote:
>>> On Tue, Jan
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on
On Tue, Jan 29, 2019 at 01:55:32PM +, Reshetova, Elena wrote:
> > On Mon, Jan 28, 2019 at 02:27:26PM +0200, Elena Reshetova wrote:
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 3cd13a3..a1e87d2 100644
> > > --- a/kernel/events/core.c
> > > +++
On Mon, Jan 28, 2019 at 05:44:29PM +0100, Andreas Kemnade wrote:
> On Mon, 28 Jan 2019 08:53:56 +0100
> Johan Hovold wrote:
>
> > On Fri, Jan 25, 2019 at 08:43:10PM +0100, Andreas Kemnade wrote:
> > > The GTA04 has a w2sg0004 or w2sg0084 gps chip. Not detectable
> > > which one is mounted so use
Florian reported a io hung issue when fsync(). It should be
triggered by following race condition.
data + post flush a flush
blk_flush_complete_seq
case REQ_FSEQ_DATA
blk_flush_queue_rq
issued to driver blk_mq_dispatch_rq_list
try to issue a
On Tue, Jan 29, 2019 at 08:38:43AM +0100, Andreas Kemnade wrote:
> The GTA04 has a w2sg0004 or w2sg0084 gps chip. Not detectable
> which one is mounted so use the compatibility entry for w2sg0004
> for all which will work for both.
>
> Signed-off-by: Andreas Kemnade
> ---
> Changes in v2:
> -
Patch series introducing support for ROHM BD70528 PMIC
Please note that patch 1 breaks compilation without patches 2 and 3
ROHM BD70528 is a programmable Power Management IC for battery
powered 'ultra low power' systems like the pre-announced NXP
i.MX7 ULP. This patch series introduces support
Hi Axel,
On Wed, 30 Jan 2019 15:11:09 +0800 wrote:
> Ensure unwind all resources if probe fails.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/uniphier-regulator.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/regulator/uniphier-regulator.c
On Wed, 30 Jan 2019 15:11:10 +0800 wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/uniphier-regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/uniphier-regulator.c
> b/drivers/regulator/uniphier-regulator.c
> index
Header rohm-bd718x7.h was split to generic and component specific
parts. This changed the struct bd718x7. Adapt the regulator driver to
these changes.
Signed-off-by: Matti Vaittinen
Acked-by: Mark Brown
---
drivers/regulator/bd718x7-regulator.c | 22 +++---
1 file changed, 11
By setting enable_reg, enable_mask, enable_val and disable_val, we can
use the regulator_enable/disable/is_enabled_regmap helpers. With this
change, then regB field can be removed from struct max77650_regulator_desc.
Signed-off-by: Axel Lin
---
Hi Bartosz,
I don't have this h/w, please help to
This is a platform driver, no need to include linux/i2c.h.
Include linux/of.h for of_match_ptr.
Signed-off-by: Axel Lin
---
drivers/regulator/max77650-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max77650-regulator.c
ROHM BD70528MWV is an ultra-low quiescent current general
purpose single-chip power management IC for battery-powered
portable devices.
Add MFD core which enables chip access for following subdevices:
- regulators/LED drivers
- battery-charger
- gpios
- 32.768kHz
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecombine while mmaping.
>> This fixes
Document bindings for regulators (3 bucks, 3 LDOs and 2 LED
drivers) and 4 GPIO pins which can be configured for I/O or
as interrupt sources withe configurable trigger levels.
Signed-off-by: Matti Vaittinen
---
.../devicetree/bindings/mfd/rohm,bd70528-pmic.txt | 104 +
1
Add following V4L2 QP parameters for H.264:
* V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP
* V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP
* V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP
* V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP
These controls will limit QP range for intra and inter frame,
provide more manual
ROHM BD70528 PMIC has 4 GPIO pins. Allow them to be
controlled by GPIO framework.
IRQs are handled by regmap-irq and GPIO driver is not
aware of the irq usage.
Signed-off-by: Matti Vaittinen
Reviewed-by: Linus Walleij
---
drivers/gpio/Kconfig| 11 +++
drivers/gpio/Makefile |
From: Michal Hocko
Mikhail has reported the following VM_BUG_ON triggered when reading
sysfs removable state of a memory block:
page:03d08300c000 is uninitialized and poisoned
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
Call Trace:
([<0038596c>]
Support RTC block in ROHM bd70528 power management IC. Support
getting and setting the time and date as well as arming an alarm
which can also be used to wake the PMIC from standby state.
HW supports wake interrupt only for the next 24 hours (sec, minute
and hour information only) so we limit
śr., 30 sty 2019 o 10:07 Axel Lin napisał(a):
>
> By setting enable_reg, enable_mask, enable_val and disable_val, we can
> use the regulator_enable/disable/is_enabled_regmap helpers. With this
> change, then regB field can be removed from struct max77650_regulator_desc.
>
> Signed-off-by: Axel
Hi Geert,
On Wed, 30 Jan 2019 at 09:21, Geert Uytterhoeven wrote:
>
> Hi Vincent,
>
> On Wed, Jan 30, 2019 at 9:16 AM Vincent Guittot
> wrote:
> > A deadlock has been seen when swicthing clocksources which use PM runtime.
> > The call path is:
> > change_clocksource
> > ...
> >
Split the bd718x7.h to ROHM common and bd718x7 specific parts
so that we do not need to add same things in every new ROHM
PMIC header. Please note that this change requires changes also
in bd718x7 sub-device drivers for regulators and clk.
Signed-off-by: Matti Vaittinen
---
On 1/30/19 05:41, Vinod Koul wrote:
> On 28-01-19, 19:32, Jorge Ramirez-Ortiz wrote:
>> Add a CPU OPP table to qcs404
>>
>> Co-developed-by: Niklas Cassel
>> Signed-off-by: Niklas Cassel
>> Signed-off-by: Jorge Ramirez-Ortiz
>> ---
>> arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++
On Wed 30-01-19 00:52:02, Jiri Kosina wrote:
> On Mon, 28 Jan 2019, Dominique Martinet wrote:
>
> > > So, any objections to aproaching it this way?
> >
> > I'm not sure why I'm the main recipient of that mail but answering
> > because I am -- let's get these patches in through the regular -mm
On Mon, Jan 28, 2019 at 07:43:33PM +0100, Tomasz Duszynski wrote:
> On Mon, Jan 28, 2019 at 08:58:19AM +0100, Johan Hovold wrote:
> > On Sun, Jan 27, 2019 at 07:19:16PM +0100, Tomasz Duszynski wrote:
> > > Add device tree support for Plantower PMS7003 particulate matter sensor.
> > >
> > >
Bartosz Golaszewski 於 2019年1月30日 週三 下午5:12寫道：
>
> śr., 30 sty 2019 o 10:07 Axel Lin napisał(a):
> >
> > By setting enable_reg, enable_mask, enable_val and disable_val, we can
> > use the regulator_enable/disable/is_enabled_regmap helpers. With this
> > change, then regB field can be removed from
Hi Linus,
here is a bunch of GPIO fixes for the v5.0 series. I was helped out
by Bartosz in collecting these fixes, for which I am very grateful,
the biggest achievement in GPIO right now is work distribution.
There is one serious core fix (timestamping) and a bunch of driver
fixes.
Please pull
Hi Viresh,
On Wednesday 30 Jan 2019 at 10:48:06 (+0530), Viresh Kumar wrote:
> On 29-01-19, 09:15, Quentin Perret wrote:
> > On Tuesday 29 Jan 2019 at 10:51:44 (+0530), Viresh Kumar wrote:
> > > On 28-01-19, 11:36, Matthias Kaehlcke wrote:
> > > > I think this patch will result in error messages
ROHM BD70528 is an ultra low power PMIC with similar 32K clk as
bd718x7. Only difference (from clk perspective) is register address.
Add support for controlling BD70528 clk using bd718x7 driver.
Signed-off-by: Matti Vaittinen
---
drivers/clk/Kconfig | 6 +++---
drivers/clk/clk-bd718x7.c
Header rohm-bd718x7.h was split to generic and component specific
parts. This changed the struct bd718x7. Adapt the clk driver to
these changes.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-bd718x7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Hi,
this is the second version of the series. v1 was posted [1]. There are
no functional changes since v1. I have just fixed up the changelog of
patch 1 which had a wrong trace (c mistake). I have also added
tested-bys and reviewed-bys.
Mikhail has posted fixes for the two bugs quite some time
śr., 30 sty 2019 o 10:07 Axel Lin napisał(a):
>
> This is a platform driver, no need to include linux/i2c.h.
> Include linux/of.h for of_match_ptr.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/max77650-regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
From: Mikhail Zaslonko
If memory end is not aligned with the sparse memory section boundary, the
mapping of such a section is only partly initialized. This may lead to
VM_BUG_ON due to uninitialized struct pages access from test_pages_in_a_zone()
function triggered by memory_hotplug sysfs
ROHM BD70528 PMIC includes battery charger block. Support charger
staus queries and doing few basic settings like input current limit
and charging current.
Signed-off-by: Matti Vaittinen
---
/*
* BD70528 charger HW state machine. Should this be added to the c-file?
*
* The thermal shutdown
On Tue, Jan 29, 2019 at 04:24:45PM +0100, Thomas Bogendoerfer wrote:
> > From an abstraction point of view this doesn't really belong into
> > a bridge driver as it is a global exported function. I guess we can
> > keep it here with a fixme comment, but we should probably move this
> > into a
add PMIC MT6358 related nodes which is for MT8183 platform
Signed-off-by: Hsin-Hsiung Wang
---
arch/arm64/boot/dts/mediatek/mt6358.dtsi | 318 +++
1 file changed, 318 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6358.dtsi
diff --git
add dt-binding document for MediaTek MT6358 PMIC
Signed-off-by: Hsin-Hsiung Wang
---
.../bindings/regulator/mt6358-regulator.txt| 318 +
1 file changed, 318 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
diff
This adds compatible for the MediaTek MT6358 PMIC.
Signed-off-by: Hsin-Hsiung Wang
---
Documentation/devicetree/bindings/mfd/mt6397.txt | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt
The MT6358 is a regulator found on boards based on MediaTek MT8183 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Signed-off-by: Hsin-Hsiung Wang
---
drivers/regulator/Kconfig | 9 +
This adds support for the MediaTek MT6358 PMIC. This is a
multifunction device with the following sub modules:
- Regulator
- RTC
- Codec
- Interrupt
It is interfaced to the host controller using SPI interface
by a proprietary hardware called PMIC wrapper or pwrap.
MT6358 MFD is a child device of
This patchset including refactoring interrupt add support to MT6358 PMIC.
MT6358 is the primary PMIC for MT8183 platform.
Hsin-Hsiung Wang (6):
mfd: mt6397: extract irq related code from core driver
dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
regulator: Add document for
1 - 100 of 1221 matches
Mail list logo
