On Fri, 15 Mar 2019, Chang S. Bae wrote:
> The helper functions will switch on faster accesses to FSBASE and GSBASE
> when the FSGSBASE feature is enabled.
>
> Accessing user GSBASE needs a couple of SWAPGS operations. It is avoidable
> if the user GSBASE is saved at kernel entry, being updated a
On Mon, Mar 25, 2019 at 09:23:09AM +, Anup Patel wrote:
> Currently, the setup_bootmem() reserves memory from RAM start to the
> kernel end. This prevents us from exploring ways to use the RAM below
> (or before) the kernel start hence this patch updates setup_bootmem()
> to only reserve memory
I'm still not sold on this at all. It is a lot more code, a lot harder
to read code and all for a very narrow corner case that isn't even
going to be enabled in default configs.
Hi Andreas,
On Tue, Mar 19, 2019 at 11:56 AM Yash Shah wrote:
>
> On Mon, Mar 18, 2019 at 10:56 PM Andreas Schwab wrote:
> >
> > On Mär 15 2019, Yash Shah wrote:
> >
> > > You need to make sure the period setting is passed via the
> > > conventional way in DT file.
> > > Example:
> > > pwmleds
On Mon, Mar 25, 2019 at 05:52:10PM +0800, zhuchangc...@cvte.com wrote:
> On Sat, Mar 23, 2019 at 02:51:52PM +0800, zhuchangc...@cvte.com wrote:
> > On Fri, Mar 22, 2019 at 11:14:14AM +0800, zhuchangc...@cvte.com wrote:
>
> > >From above,you can kown when you export a GPIO ,it will do request,
Hi Harish,
> This patch enables regulators for the Qualcomm Bluetooth WCN3998
> controller.
>
> Signed-off-by: Harish Bandi
> ---
> Changes in V4:
> - Removed new compatible WCN3998
> - changed wcn3990 to wcn399* to represent wcn399* family
> ---
> Documentation/devicetree/bindings/net/qualcomm-
On Mon, Mar 25, 2019 at 10:36:26AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 22.03.19 20:06, Andy Shevchenko wrote:
> > On Fri, Mar 22, 2019 at 07:32:28PM +0100, Enrico Weigelt, metux IT consult
> > wrote:
> >> On 21.03.19 10:23, Andy Shevchenko wrote:
> >>
> >>> ...and on top of that G
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> device_register() performs put_device() if device_add() fails.
> This balances with device_initialize().
>
> mdev core performing put_device() when device_register() fails,
> is an error that puts already released device again.
> Therefore,
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> During mdev parent registration in mdev_register_device(),
> if parent device is duplicate, it releases the reference of existing
> parent device.
> This is incorrect. Existing parent device should not be touched.
>
> Fixes: 7b96953bc640 ("v
On 25/03/2019 12:31, Harish Bandi wrote:
> +bool is_qca_soc_type_wcn399x_family(enum qca_btsoc_type soc_type)
> +{
> + if ((soc_type == QCA_WCN3990) || (soc_type == QCA_WCN3998))
^ ^
spurious white-space here as well
On Fri, Mar 22, 2019 at 11:45 PM Srinivas Pandruvada
wrote:
>
> As per ACPI specification "Guaranteed Performance Register" is a "Buffer"
> field. It can't be "Integer" field. So treat "Integer" type as invalid and
> ignore "Guaranteed Performance Register".
> Also save one cpc_read() call, when "
On Mon, Mar 25, 2019 at 10:31:13AM +0100, Rafael J. Wysocki wrote:
> On Fri, Mar 22, 2019 at 2:47 PM Thomas Preston
> wrote:
> >
> > Add an example for the magic PRP0001 device ID which allows matching
> > ACPI devices against drivers using OF Device Tree compatible property.
> > It wasn't clear t
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> Remove unused kref from the mdev_device structure.
>
> Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c| 1 -
> drivers/vfio/mdev/mdev_private.h | 1 -
> 2 fi
On 09/03/2019 04:02, Kangjie Lu wrote:
> idr_find may return NULL, so check its return value and return an
> error code.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/firmware/arm_scmi/driver.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/driver.c
> b/dr
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> There is no need use 'extern' for exported functions.
>
> Signed-off-by: Parav Pandit
> ---
> include/linux/mdev.h | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/mdev.h b/inc
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> Instead of masking return error to -EBUSY, return actual error
> returned by the driver.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/driver
On Mär 25 2019, Yash Shah wrote:
> I have sent out the v11 patchset, you can test the heartbeat
> application with that patchset.
> You still need to make that DT file modification which you previously
> did, using fsbl.bin
Why can't the driver make use of sifive,approx-period?
Andreas.
--
An
Hi, Uwe
Best Regards!
Anson Huang
> -Original Message-
> From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de]
> Sent: 2019年3月25日 17:30
> To: Anson Huang
> Cc: thierry.red...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker.
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> mdev_remove_sysfs_files() should follow exact mirror sequence of a
> create, similar to what is followed in error unwinding path of
> mdev_create_sysfs_files().
>
> Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
> Signed-off-by: P
On Fri, 2019-03-22 at 18:20 -0500, Parav Pandit wrote:
> device_for_each_child() stops executing callback function for remaining
> child devices, if callback hits an error.
> Each child mdev device is independent of each other.
> While unregistering parent device, mdev core must remove all child md
On Fri, Mar 22, 2019 at 03:39:48PM -0700, Guenter Roeck wrote:
> general protection fault: [#1] PREEMPT SMP KASAN PTI
> CPU: 1 PID: 2811 Comm: cat Tainted: GW 4.19.30 #15
> Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014
> RIP: 0010:snd_soc_suspend+0x5
From: Guo Ren
Previous syscall_trace implementation couldn't support AUDITSYSCALL and
SYSCALL_TRACEPOINTS. Now we redesign it to support audit_syscall
and syscall_tracepoints just like other archs'.
Signed-off-by: Guo Ren
Cc: Dmitry V. Levin
Cc: Arnd Bergmann
---
arch/csky/Kconfig
Patch series introducing support for ROHM BD70528 PMIC
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 for the PMIC. Please
note that this driver only supports HW setup where
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 cl
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
Acked-by: Stephen Boyd
---
drivers/clk/Kconfig | 6 +++---
dri
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
Reviewed-by: Rob Herring
Acked-by: Linus Walleij
---
.../bindings/mfd/rohm,bd70528-pmic
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
Acked-by: Mark Brown
Acke
On Fri, Mar 22, 2019 at 11:45 PM Srinivas Pandruvada
wrote:
>
> ACPI specifications stat that if the "Guaranteed Performance Register" is
> not implemented, OSPM assumes guaranteed performance is always equal to
> nominal performance. So for invalid and unimplemented guaranteed
> performance regis
Initial support for watchdog block included in ROHM BD70528
power management IC.
Configurations for low power states are still to be checked.
Signed-off-by: Matti Vaittinen
Acked-by: Guenter Roeck
---
drivers/watchdog/Kconfig | 12 +++
drivers/watchdog/Makefile | 1 +
drivers/wat
On 23/03/2019 21:04, Aditya Pakki wrote:
> In case __get_free_pages fail, the fix returns error upstream
> to avoid NULL pointer dereference.
>
> Signed-off-by: Aditya Pakki
Reviewed-by: Steven Price
>
> ---
> v1: Return error upstream as suggested by Steven
> ---
> drivers/pci/controller/pc
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 also
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
---
drivers/power/supply/Kconfig | 9 +
drivers/power/supply/Makefile | 1 +
drivers/p
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 | 1
On Mon, Mar 25, 2019 at 06:38:27AM +, Agrawal, Akshu wrote:
> v2: Removed clk set rate and enable/disable from da7219 ops as
> da7219 codec takes care of them internally. Clock configuration
> kept for those codecs where da7219 acts as master of clock.
> As suggested by Adam Thomson.
>
> Sign
On Mon, Mar 25, 2019 at 5:28 PM Andreas Schwab wrote:
>
> On Mär 25 2019, Yash Shah wrote:
>
> > I have sent out the v11 patchset, you can test the heartbeat
> > application with that patchset.
> > You still need to make that DT file modification which you previously
> > did, using fsbl.bin
>
> W
Stanimir,
Is v4 good enough for Bjorn to pick up?
Regards.
On 18/03/2019 18:14, Marc Gonzalez wrote:
> We don't need to fudge the device class in qcom_pcie_rd_own_conf()
> because dw_pcie_setup_rc() already does the right thing:
>
> /* Program correct class for RC */
> dw_pcie_wr_o
On Sat, Mar 23, 2019 at 09:55:46AM -0400, Pierre-Louis Bossart wrote:
> I'd like to highlight that there is a fundamental flaw in the way the
> machine drivers are handled. Since we don't have a hook for the machine
> driver in the BIOS, the DSP driver creates a platform_device which will
> instan
On Mon, Mar 25, 2019 at 06:38:27AM +, Agrawal, Akshu wrote:
> With CCF support in da7219, we can now set the correct rate of
> wclk and bclk.
> Setting bclk at lower rate at 1.53Mhz from its earlier default
> rate of 3Mhz, also fixes noise issue observed on some dmics.
This doesn't seem to app
On Mon, Mar 25, 2019 at 08:03:39PM +0800, guo...@kernel.org wrote:
[...]
> diff --git a/arch/csky/include/uapi/asm/ptrace.h
> b/arch/csky/include/uapi/asm/ptrace.h
> index a4eaa8d..9bf5b1a 100644
> --- a/arch/csky/include/uapi/asm/ptrace.h
> +++ b/arch/csky/include/uapi/asm/ptrace.h
> @@ -62,6 +62
On 25/03/2019 10:48, Jerome Brunet wrote:
> On Sun, 2019-03-24 at 17:43 +0100, Martin Blumenstingl wrote:
>> Make meson_clk_pll_is_better() consider a rate that precisely matches
>> the requested rate to be better than any previous rate (which was
>> smaller than the current).
>>
>> Prior to commit
On 25/03/2019 11:42, Jerome Brunet wrote:
> While some SoC samples are able to lock with a PLL factor of 55, others
> samples can't. ATM, a minimum of 60 appears to work on all the samples
> I have tried, so lets use this value until we have a good reason to put
> something else.
>
> Fixes: 085a4e
On Wednesday, February 27, 2019 8:58:35 PM CET Ulf Hansson wrote:
> To be able to predict the sleep duration for a CPU that is entering idle,
> knowing when the next timer/tick is going to expire, is extremely useful.
> Both the teo and the menu cpuidle governors already makes use of this
> informa
The patch
ASoC: intel: Fix crash at suspend/resume after failed codec registration
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the
The patch
regulator: tps65217: Constify regulator_ops
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
regulator: tps65218: Constify regulator_ops
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: stm32: sai: add power management
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
regulator: uniphier: Fix build dependency
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and se
The patch
spi: atmel-quadspi: Make atmel_qspi_get_name static
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
On Thu, Mar 21, 2019 at 06:05:47PM -0500, Jeremy Linton wrote:
> Arm64 machines should be displaying a human readable
> vulnerability status to speculative execution attacks in
> /sys/devices/system/cpu/vulnerabilities
>
> This series enables that behavior by providing the expected
> functions. T
The patch
ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the n
This series includes 4 patches:
1.add pintcrl binding document on mt8183.
2.add pintcrl file on mt8183.
3.add pintcrl device node on mt8183.
4.add drive for I2C related pins on MT8183.
Changes in patch v3:
1)add the patch "dt-bindings: pinctrl: mt8183: add binding document".
2)add the patch "arm64
This patch provides the advanced drive for I2C used pins on MT8183.
The detail strength specification description of the I2C pin:
When E1=0/E0=0, the strength is 0.125mA.
When E1=0/E0=1, the strength is 0.25mA.
When E1=1/E0=0, the strength is 0.5mA.
When E1=1/E0=1, the strength is 1mA.
For I2C pins
The commit adds mt8183 compatible node in binding document.
Signed-off-by: Zhiyong Tao
---
.../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 133 +
1 file changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
diff --gi
This patch adds pinctrl file for mt8183.
Signed-off-by: Zhiyong Tao
---
arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h | 1120 +
1 file changed, 1120 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
diff --git a/arch/arm64/boot/dts/mediatek/
The commit adds pintcrl device node for mt8183
Signed-off-by: Zhiyong Tao
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dt
Cc: Chaotian Jing
Signed-off-by: Ulf Hansson
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3e5a5d263f29..b43e563b4c95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9775,6 +9775,12 @@ F: drivers/media/platform/mtk-vpu/
F: Doc
Am Freitag, 22. März 2019, 20:59:23 CET schrieb Douglas Anderson:
> As far as I can tell/remember rev10 was originally created to support
> making a SKU of jerry that had a different LCD. rev11-rev15 were
> added to give some wiggle room for future builds. Downstream has a
> separate device tree
Am Freitag, 22. März 2019, 17:52:09 CET schrieb Douglas Anderson:
> When the rk3288-jerry device tree was first submitted we left out the
> dvs-gpios because I pointed out that the property "dvs-gpios" wasn't
> yet supported upstream [1]. Soon after that the property was added in
> commit bad47ad2
Am Donnerstag, 21. März 2019, 21:19:44 CET schrieb Douglas Anderson:
> The vdd_logic rail controls the voltage supplied to misc logic on
> rk3288, including the voltage supplied to the memory controller. The
> vcc logic is implemented by a PWM regulator.
>
> Right now there are no consumers of vd
Am Mittwoch, 20. März 2019, 21:13:59 CET schrieb Douglas Anderson:
> It can be seen that 0xffb4 < 0xffc01000, thus efuse comes first.
>
> Signed-off-by: Douglas Anderson
applied patch1 for 5.2 and the other 3 as fixes for 5.1
Thanks
Heiko
Am Donnerstag, 21. März 2019, 17:22:44 CET schrieb Katsuhiro Suzuki:
> Add UART dma channels as specified by the rk3399 TRM.
>
> Refer:
> RK3399 TRM V1.4: Chapter 12 DMA Controller
>
> Signed-off-by: Katsuhiro Suzuki
applied for 5.2
Thanks
Heiko
Tony
On 3/22/19 5:16 PM, Tony Lindgren wrote:
> Hi,
>
> * Dan Murphy [190321 14:29]:
>> Introduce the Texas Instruments LM3532 White LED driver.
>> The driver supports ALS configurability or manual brightness
>> control.
>>
>> The driver also supports associating LED strings with specific
>> con
clang correctly points out a code path that would lead
to an uninitialized variable use:
security/selinux/netlabel.c:310:6: error: variable 'addr' is used uninitialized
whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
if (ip_hdr(skb)->version == 4) {
This series includes 4 patches:
1.add pintcrl binding document on mt8183.
2.add pintcrl file on mt8183.
3.add pintcrl device node on mt8183.
4.add drive for I2C related pins on MT8183.
Changes in patch v3:
1)add the patch "dt-bindings: pinctrl: mt8183: add binding document".
2)add the patch "arm64
This patch adds pinctrl file for mt8183.
Signed-off-by: Zhiyong Tao
---
arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h | 1120 +
1 file changed, 1120 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pinfunc.h
diff --git a/arch/arm64/boot/dts/mediatek/
The commit adds pintcrl device node for mt8183
Signed-off-by: Zhiyong Tao
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dt
This patch provides the advanced drive for I2C used pins on MT8183.
The detail strength specification description of the I2C pin:
When E1=0/E0=0, the strength is 0.125mA.
When E1=0/E0=1, the strength is 0.25mA.
When E1=1/E0=0, the strength is 0.5mA.
When E1=1/E0=1, the strength is 1mA.
For I2C pins
The commit adds mt8183 compatible node in binding document.
Signed-off-by: Zhiyong Tao
---
.../devicetree/bindings/pinctrl/pinctrl-mt8183.txt | 132 +
1 file changed, 132 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt
diff --gi
Thx Dmitry,
On Mon, Mar 25, 2019 at 03:17:54PM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 25, 2019 at 08:03:39PM +0800, guo...@kernel.org wrote:
> [...]
> > diff --git a/arch/csky/include/uapi/asm/ptrace.h
> > b/arch/csky/include/uapi/asm/ptrace.h
> > index a4eaa8d..9bf5b1a 100644
> > --- a/arch
On Mon, Mar 25, 2019 at 5:09 PM Christoph Hellwig wrote:
>
> I'm still not sold on this at all. It is a lot more code, a lot harder
> to read code and all for a very narrow corner case that isn't even
> going to be enabled in default configs.
The old page table setup code does not exist anymore.
On Mon, 25 Mar 2019, Thomas Gleixner wrote:
> The whole point of FSGSBASE support is performance, right?
>
> So can please someone explain why having the following in the context
> switch path when it can be completely avoided is enhancing performance:
>
> - 4 x SWAPGS
> - 1 x RDMSR
> - 1 x
On Sun, 24 Mar 2019 at 09:33, Anand Moon wrote:
>
> Add suspend-to-mem node to regulator core to be enabled or disabled
> during system suspend and also support changing the regulator operating
> mode during runtime and when the system enter sleep mode (stand by mode).
>
> Cc: Marek Szyprowski
>
Hello,
This is the forth version of a series allowing to manage the cpu clock
for Armada 7K/8K. The third version was sent more than 3 months
without any relevant feedback since this end of decembe last year.
For these SoCs, the CPUs share the same clock by cluster, so actually
the clock manageme
Clock drivers for Armada AP and Armada CP use the same function to
generate unique clock name. A third drivers is coming with the same
need, so it's time to move this function in a common file.
Signed-off-by: Gregory CLEMENT
---
drivers/clk/mvebu/Kconfig | 5
drivers/clk/
Document the device tree binding for the cluster clock controllers found
in the Armada 7K/8K SoCs.
Signed-off-by: Gregory CLEMENT
---
.../arm/marvell/ap806-system-controller.txt | 25 +++
1 file changed, 25 insertions(+)
diff --git
a/Documentation/devicetree/bindings/arm/marv
This commit makes sure the driver for the Armada 7K/8K CPU clock is
enabled.
Signed-off-by: Gregory CLEMENT
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 70498a033cf5..b68b89e7bcb4 100644
---
Actually, the clocks exposed for the cluster are not the CPU clocks, but
the PLL clock used as entry clock for the CPU clocks. The CPU clock will
be managed by a driver submitting in the following patches.
Signed-off-by: Gregory CLEMENT
---
drivers/clk/mvebu/ap806-system-controller.c | 4 ++--
1
Add cpu clock node on AP
Signed-off-by: Gregory CLEMENT
---
arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi | 4
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 6 ++
2 files changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
b/arch/arm64
The CPU frequency is managed at the AP level for the Armada 7K/8K. The
CPU frequency is modified by cluster: the CPUs of the same cluster have
the same frequency.
This patch adds the clock driver that will be used by CPUFreq, it is
based on the work of Omri Itach .
Signed-off-by: Gregory CLEMENT
On Mon, Mar 25, 2019 at 5:09 PM Christoph Hellwig wrote:
>
> I'm still not sold on this at all. It is a lot more code, a lot harder
> to read code and all for a very narrow corner case that isn't even
> going to be enabled in default configs.
In case you missed my previous response about why its
On 3/24/19 4:47 PM, Jonathan Cameron wrote:
> On Fri, 22 Mar 2019 14:54:06 +0100
> Fabrice Gasnier wrote:
>
>> This fixes a possible circular locking dependency detected warning seen
>> with:
>> - CONFIG_PROVE_LOCKING=y
>> - consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
clang complains about assigning a variable to itself during the
declaration:
fs/ceph/ioctl.c:187:26: error: variable 'oid' is uninitialized when used within
its own initialization [-Werror,-Wuninitialized]
CEPH_DEFINE_OID_ONSTACK(oid);
^~~
include/linux/cep
On Sun, Mar 24, 2019 at 05:57:53PM -0500, Kangjie Lu wrote:
> In case kcalloc fails, the patch return an error to avoid
> potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> arch/x86/platform/uv/tlb_uv.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x
On Mon, 25 Mar 2019 at 13:46, Krzysztof Kozlowski wrote:
>
> On Sun, 24 Mar 2019 at 09:33, Anand Moon wrote:
> >
> > Add suspend-to-mem node to regulator core to be enabled or disabled
> > during system suspend and also support changing the regulator operating
> > mode during runtime and when the
From: Vladislav Dalechyn
Description: The ELAN1200:04F3:303E touchpad exposes several issues, all
caused by an error setting the correct IRQ_TRIGGER flag:
- i2c_hid incoplete error flood in journalctl;
- Five finger tap kill's module so you have to restart it;
- Two finger scoll is working incorr
Hi,
On 21/03/19 11:41 PM, Joakim Tjernlund wrote:
> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote:
>>
>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
>> Set(0x0002) for flash operations, therefore
>> drivers/mtd/chips/cfi_cmdset_0002.c
>> can be use as is.
Hi Jonathan,
Looks good to me. Looks like this hardware is so close to Just
Working with the generic driver; it's too bad we have to add more ECAM
quirks, but sometimes life gives us lemons. Trivial comments below.
Lorenzo may have additional comments.
The subject should be something like:
When lockdep is enabled, and -Wuninitialized warnings are enabled,
clang produces a silly warning for every file we compile:
In file included from kernel/sched/fair.c:23:
kernel/sched/sched.h:1094:15: error: variable 'cookie' is uninitialized when
used here [-Werror,-Wuninitialized]
rf-
BUG_ON(1) leads to bogus warnings from clang when
CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
fs/ext4/inode.c:544:4: error: variable 'retval' is used uninitialized whenever
'if' condition is false
[-Werror,-Wsometimes-uninitialized]
BUG_ON(1);
Date: Sun, 24 Mar 2019 21:44:31 +0530
Subject: [PATCH 2/2] arm64: defconfig: Enable stmmac qualcomm ethernet config
Some platforms like QCS404 sport stmmac ethernet conrollers, enable the
configs and phy drivers for it.
Signed-off-by: Vinod Koul
---
arch/arm64/configs/defconfig | 9 +
1
PM8XXX RTC driver is used as RTC is bunch of Qualcomm platforms so add
it to defconfig.
Signed-off-by: Vinod Koul
---
arch/arm64/configs/defconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2d9c39033c1a..5dbe372ee913
This fixes a possible circular locking dependency detected warning seen
with:
- CONFIG_PROVE_LOCKING=y
- consumer/provider IIO devices (ex: "voltage-divider" consumer of "adc")
When using the IIO consumer interface, e.g. iio_channel_get(), the consumer
device will likely call iio_read_channel_raw(
On Mon, Mar 25, 2019 at 01:51:18PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 25, 2019 at 10:31:13AM +0100, Rafael J. Wysocki wrote:
> > On Fri, Mar 22, 2019 at 2:47 PM Thomas Preston
> > wrote:
> > >
> > > Add an example for the magic PRP0001 device ID which allows matching
> > > ACPI devices ag
On 2019-03-21, Andy Lutomirski wrote:
> On Wed, Mar 20, 2019 at 7:38 AM Aleksa Sarai wrote:
> > Now that the holiday break is over, it's time to re-send this patch
> > series (with a few additions, due to new information we got from
> > CVE-2019-5736 -- which this patchset mostly protected agains
On Mon, 25 Mar 2019, Thomas Gleixner wrote:
> On Mon, 25 Mar 2019, Thomas Gleixner wrote:
> > The whole point of FSGSBASE support is performance, right?
> >
> > So can please someone explain why having the following in the context
> > switch path when it can be completely avoided is enhancing per
On Mon, Mar 25, 2019 at 10:38:54AM +0100, Lukas Wunner wrote:
> On Mon, Mar 25, 2019 at 03:22:23PM +0900, William Breathitt Gray wrote:
> > +/**
> > + * find_next_clump8 - find next 8-bit clump with set bits in a memory
> > region
> > + * @clump: location to store copy of found clump
> > + * @addr
On Mon, Mar 18, 2019 at 1:29 PM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> Add modifications necessary to make davinci part of the ARM v5
> multiplatform build.
>
> Move the arch-specific configuration out of arch/arm/Kconfig and
> into mach-davinci/Kconfig. Remove the sub-menu
Hi,
On 24/03/19 9:48 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote:
>
>> Add DT binding documentation for Hyperbus memory devices. Only
>> Hyperflash is supported at the moment.
>>
>> Signed-off-by: Vignesh Raghavendra
>> ---
>> Documentation/devicet
On Mon, Mar 25, 2019 at 03:26:18PM +0900, William Breathitt Gray wrote:
> Replace verbose implementation in set_multiple callback with
> for_each_set_clump8 macro to simplify code and improve clarity.
I guess it's better to group this with other GPIO related patches.
--
With Best Regards,
Andy S
Another comment found while creating compliance tests:
On 1/24/19 11:04 AM, Tomasz Figa wrote:
> +Drain
> +=
> +
> +To ensure that all the queued ``OUTPUT`` buffers have been processed and the
> +related ``CAPTURE`` buffers are given to the client, the client must follow
> the
> +drain sequen
301 - 400 of 1175 matches
Mail list logo
