Quoting Viresh Kumar (2019-01-31 01:23:49)
> Adding few folks to the thread who might be interested in this stuff.
>
> On 28-01-19, 17:55, Stephen Boyd wrote:
> > This patch series is an RFC around how we can implement DVFS for devices
> > that aren't your typical OPPish device (i.e. GPU/CPU).
On Thu, 31 Jan 2019, Axel Lin wrote:
> Use pointer instead.
>
> Signed-off-by: Axel Lin
> ---
> drivers/mfd/at91-usart.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for
On Thu, 31 Jan 2019, Axel Lin wrote:
> They are never get changed, make them constant.
> While at it, fix indent as well.
>
> Signed-off-by: Axel Lin
> ---
> drivers/mfd/at91-usart.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
On Tue, 29 Jan 2019, Vijay Khemka wrote:
> Memory-region and flash phandle is not a required parameter, it is
> optional to describe in device tree and needed only use basis.
>
> Signed-off-by: Vijay Khemka
> ---
> Documentation/devicetree/bindings/mfd/aspeed-lpc.txt | 2 ++
> 1 file changed,
Move all the TC identifiers to one place, to the same enum that defines
the identifier of police action. This makes it easier choose numbers for
new actions since they are now defined in one place. We preserve the
original values for binary compatibility. New IDs should be added inside
the enum.
Modify the kernel users of the TCA_ACT_* macros to use TCA_ID_*. For
example, use TCA_ID_GACT instead of TCA_ACT_GACT. This will align with
TCA_ID_POLICE and also differentiates these identifier, used in struct
tc_action_ops type field, from other macros starting with TCA_ACT_.
To make things
This two patch series modifies TC actions identifiers to be more consistent and
also puts them in one place so new identifiers numbers can be chosen more
easily.
Eli Cohen (2):
net: Move all TC actions identifiers to one place
net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE
uv_bios_call_reentrant() has no callers nor is it exported, kill it.
Cc: Russ Anderson
Cc: Mike Travis
Cc: Dimitri Sivanich
Cc: Steve Wahl
Cc: sta...@vger.kernel.org
Signed-off-by: Hedi Berriche
---
arch/x86/include/asm/uv/bios.h | 1 -
arch/x86/platform/uv/bios_uv.c | 12
2
Den tors 7 feb. 2019 kl 06:38 skrev Davidlohr Bueso :
>
> Holding mmap_sem exclusively for a gup() is an overkill.
> Lets replace the call for gup_fast() and let the mm take
> it if necessary.
>
> Cc: David S. Miller
> Cc: Bjorn Topel
> Cc: Magnus Karlsson
> CC: net...@vger.kernel.org
>
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 +
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 +
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 |
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
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
---
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
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
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
On Tue, Feb 5, 2019 at 7:35 PM Hans Verkuil wrote:
>
> On 2/5/19 10:31 AM, Tomasz Figa wrote:
> > On Tue, Feb 5, 2019 at 6:00 PM Hans Verkuil wrote:
> >>
> >> On 2/5/19 7:26 AM, Tomasz Figa wrote:
> >>> On Fri, Feb 1, 2019 at 12:18 AM Nicolas Dufresne
> >>> wrote:
>
> Le jeudi 31
The CPU may only access DMA mapped memory if ownership has been
transferred back to the CPU using dma_sync_{single,sg}_to_cpu, and then
before the device can access it again ownership needs to be transferred
back to the device using dma_sync_{single,sg}_to_device.
> I've run some testing, and
An early preview release Git v2.21.0-rc0 is now available for
testing at the usual places. It is comprised of 426 non-merge
commits since v2.20.0, contributed by 57 people, 13 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The
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
Hi all,
Changes since 20190206:
The compiler-attributes tree gained a build failure so I used the version
from next-20190206.
The tegra tree gained a conflict against the imx-mxs tree.
The opp tree gained a conflict against the cpufreq-arm tree.
The net-next tree gained a conflict against
On Wed, 2019-02-06 at 17:25 +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2019 at 10:59:40AM -0800, Joe Perches wrote:
> > On Tue, 2019-02-05 at 19:44 +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Feb 05, 2019 at 08:36:24PM +0530, Nishad Kamdar wrote:
> > > > This patch corrects the style
On Wed, Feb 06, 2019 at 05:56:02PM +0300, Dmitry Osipenko wrote:
> > We don't have an IOMMU attached to I2C or APBDMA, so this can't happen
> > and even if we had an IOMMU attached, all we care about is the device's
> > DMA address space, which means IOVA space, and that would still be
> >
From: Madhavan Srinivasan
Add code to restrict user access to thread_imc pmu since
some event report privilege level information.
Fixes: f74c89bd80fb3 ('powerpc/perf: Add thread IMC PMU support')
Signed-off-by: Madhavan Srinivasan
Signed-off-by: Anju T Sudhakar
---
IMC (In-Memory collection counters) is a hardware monitoring facility
that collects large number of hardware performance events.
POWER9 support two modes for IMC which are the Accumulation mode and
Trace mode. In Accumulation mode, event counts are accumulated in
Add PMU functions to support trace-imc and define the format for
trace-imc events.
Signed-off-by: Anju T Sudhakar
Reviewed-by: Madhavan Srinivasan
---
arch/powerpc/perf/imc-pmu.c | 197 +++-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git
Patch detects trace-imc events, does memory initilizations for each online
cpu, and registers cpuhotplug call-backs.
Signed-off-by: Anju T Sudhakar
Reviewed-by: Madhavan Srinivasan
---
arch/powerpc/perf/imc-pmu.c | 91 +++
LDBAR holds the memory address allocated for each cpu. For thread-imc
the mode bit (i.e bit 1) of LDBAR is set to accumulation.
Currently, ldbar is loaded with per cpu memory address and mode set to
accumulation at boot time.
To enable trace-imc, the mode bit of ldbar should be set to 'trace'. So
Add the macros needed for IMC (In-Memory Collection Counters) trace-mode
and data structure to hold the trace-imc record data.
Also, add the new type "OPAL_IMC_COUNTERS_TRACE" in 'opal-api.h', since
there is a new switch case added in the opal-calls for IMC.
Signed-off-by: Anju T Sudhakar
3) How do we handle devices that already have power-domains specified in
DT? The opp binding for required-opps doesn't let us specify the power
domain to target, instead it assumes that whatever power domain is
attached to a device is the one that OPP needs to use to change the
genpd
Hi everyone,
This series enables USB OTG on the A83T boards. The AXP813/AXP818 PMICs
used with the A83T have the same behavior as the AXP221 and AXP223,
where if the N_VBUSEN pin is driven high, the VBUS sensing interrupts
stop working. In the past Hans made a polling workaround in the USB PHY
From: Quentin Schulz
The AXP813/818 has a VBUS power input. Add a device node for it, now
that we support it.
Signed-off-by: Quentin Schulz
[w...@csie.org: Add commit message]
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/axp81x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git
From: Quentin Schulz
The AXP813 has a VBUS power input. Now that the axp20x_usb_power driver
supports this variant, we can add an mfd cell for it to use it.
Signed-off-by: Quentin Schulz
[w...@csie.org: add commit message]
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 11 +++
On AXP221 and later AXP PMICs that have the N_VBUSEN pin, when this pin
is high, either due to the PMIC driving it high or as an input, the VBUS
detection related interrupt mechanisms are disabled.
Previously this was worked around in the phy-sun4i-usb driver, which
needed to sense VBUS changes
This adds the "x-powers,axp813-usb-power-supply" to the list of
compatibles for AXP20X VBUS power supply driver.
Signed-off-by: Chen-Yu Tsai
---
.../devicetree/bindings/power/supply/axp20x_usb_power.txt| 1 +
1 file changed, 1 insertion(+)
diff --git
The VBUS current limit value macros have VBUS typed as VBUC, while
the bitmask macro is named correctly. Fix it.
Fixes: 69fb4dcada77 ("power: Add an axp20x-usb-power driver")
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 16
1 file changed, 8
From: Quentin Schulz
To prepare for a new PMIC, factor out the code responsible of returning
the maximum current to axp20x_get_current_max.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 52 ++---
1 file changed, 30
The AXP PMICs allow the user to disable current limiting on the VBUS
input. While read-out of this setting was already supported by the
driver, it did not allow the user to configure the PMIC to disable
current limiting.
Add support for this.
Signed-off-by: Chen-Yu Tsai
---
From: Quentin Schulz
This adds support for AXP813 PMIC. It is almost the same as AXP22X but
has a different current limit.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 66 -
1 file changed, 65 insertions(+), 1
The Bananapi M3 and Cubietruck Plus both have USB OTG ports wired to the
SoC and PMIC in the same way, with the N_VBUSEN pin on the PMIC
controlling VBUS output, the PMIC's VBUS input for sensing VBUS, and
PH11 on the SoC for sensing the ID pin.
Enable OTG on both boards.
Signed-off-by: Chen-Yu
Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop failing
to deliver SIGHUP but always trying.
When the stack overflows delivery of SIGHUP fails and
Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop
failing to deliver SIGHUP but always trying.
Upon examination it turns out part of the problem is
Dmitry,
Can you please verify the follow two patches. The first one is a
simplification of the one you have already tested and makes the
processes killable. The second patch improves our heuristic for
detecting synchronous like SIGSEGV when the stack overflows allowing us
to process them
On Wed, Feb 06, 2019 at 11:52:03AM +0300, Cyrill Gorcunov wrote:
> On Wed, Feb 06, 2019 at 12:10:39AM +, Dmitry Safonov wrote:
> > From: Andrei Vagin
> >
> > Make timerfd respect timens offsets.
> > Provide two helpers timens_clock_to_host() timens_clock_from_host() that
> > are useful to
On 07/02/2019 04:08, Callum Sinclair wrote:
> Currently the only way to clear the mfc cache was to delete the entries
> one by one using the MRT_DEL_MFC socket option or to destroy and
> recreate the socket.
>
> Create a new socket option which will clear the multicast forwarding
> cache on the
On 01/02/2019 19:46, Boris Ostrovsky wrote:
> On 1/30/19 3:22 AM, Juergen Gross wrote:
>> 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
By switching to devm_device_add_group() we can complete driver conversion
to using managed resources and get rid of ili210x_i2c_remove().
Signed-off-by: Dmitry Torokhov
---
drivers/input/touchscreen/ili210x.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git
Hi all,
On Thu, 7 Feb 2019 16:51:34 +1100 Stephen Rothwell
wrote:
>
> On Thu, 7 Feb 2019 15:47:47 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the scsi-mkp tree got a conflict in:
> >
> > drivers/scsi/osd/osd_initiator.c
> >
> > between commit:
> >
> >
The PowerPC docs have yet to be converted to RST format. Let's kick it
off by doing all the files that _don't_ contain ASCII art.
- Add SPDX license identifier to each new RST file.
.. SPDX-License-Identifier: GPL-2.0
- User correct heading adornments.
- Make all lines < 72 characters in
Hi Michael,
As discussed at LCA here is the start to the docs conversion for PowerPC
to RST.
This applies cleanly on top of the mainline (5.20-rc5) and Jon's tree
(docs-next branch).
I'm guessing it should go in through the PowerPC tree because I doubt
you want to review this Jon, it's one big
Please get back to me My name is Sgt.Sherri Gallagher,
On Wed, Feb 06, 2019 at 09:31:27AM -0800, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2019-02-06 01:39:38)
> > @@ -86,9 +87,21 @@ static int bd71837_clk_probe(struct platform_device
> > *pdev)
> > dev_err(>dev, "No parent clk found\n");
> > return -EINVAL;
> >
On Wed, Feb 6, 2019 at 9:23 PM Jason Gunthorpe wrote:
>
> On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote:
> > On Wed, Feb 06, 2019 at 05:24:50PM -0500, Doug Ledford wrote:
> > > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote:
> > > > On Thu, Feb 07, 2019 at 08:03:56AM
Moro Kalle,
On Wed, Feb 06, 2019 at 08:31:32PM +0200, Kalle Valo wrote:
> Matti Vaittinen writes:
>
> > Patch series introducing support for ROHM BD70528 PMIC
> >
> > Please note that patch 1 breaks compilation without patches 2 and 3
> > Knowing the bd718x7 driver is already in upstream, it
Add on-board WiFi/BT support for Rock960 boards such as Rock960 based
on AP6356S and Ficus based on AP6354 wireless modules.
Firmwares for the respective boards are available here:
http://people.linaro.org/~manivannan.sadhasivam/rock960_wifi/
Thanks, but why initialization matters here? Is performance the main concern?
On Wed, Feb 6, 2019 at 9:52 PM Yizhuo Zhai wrote:
>
> Thanks, but why initialization matters here? Is performance the main concern?
>
> On Wed, Feb 6, 2019 at 8:17 PM David Miller wrote:
>>
>> From: Yizhuo
>> Date:
Hi all,
On Thu, 7 Feb 2019 15:47:47 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/scsi/osd/osd_initiator.c
>
> between commit:
>
> 24648908acac ("scsi: osd: osd_initiator: mark expected switch
> fall-throughs")
I will
Unlike what the subject says, this is not against -tip, it applies
on today's -next.
On Wed, 06 Feb 2019, Davidlohr Bueso wrote:
Hi,
Here are two more patchlets that cleanup mmap_sem and gup abusers.
The second is also a fixlet.
Compile-tested only. Please consider for v5.1
Thanks!
Fix fixed_phy not checking GPIO if no link_update callback
is registered.
In the original version all users registered a link_update
callback so the issue was masked.
Fixes: a5597008dbc2 ("phy: fixed_phy: Add gpio to determine link up/down.")
Reviewed-by: Andrew Lunn
Signed-off-by: Moritz
Hi,
Here are two more patchlets that cleanup mmap_sem and gup abusers.
The second is also a fixlet.
Compile-tested only. Please consider for v5.1
Thanks!
Davidlohr Bueso (2):
xsk: do not use mmap_sem
MIPS/c-r4k: do no use mmap_sem for gup_fast()
arch/mips/mm/c-r4k.c | 6 +-
Holding mmap_sem exclusively for a gup() is an overkill.
Lets replace the call for gup_fast() and let the mm take
it if necessary.
Cc: David S. Miller
Cc: Bjorn Topel
Cc: Magnus Karlsson
CC: net...@vger.kernel.org
Signed-off-by: Davidlohr Bueso
---
net/xdp/xdp_umem.c | 6 ++
1 file
It is well known that because the mm can internally
call the regular gup_unlocked if the lockless approach
fails and take the sem there, the caller must not hold
the mmap_sem already.
Fixes: e523f289fe4d (MIPS: c-r4k: Fix sigtramp SMP call to use kmap)
Cc: Ralf Baechle
Cc: Paul Burton
Cc: James
On Wed, Feb 06, 2019 at 06:28:49PM -0800, Nicolin Chen wrote:
> So we will keep allocating single pages in dev->cma_area if it's
> present, in order to address your previous concern?
Yes.
On Wed, Feb 06, 2019 at 04:22:16PM -0800, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 3:41 PM Jason Gunthorpe wrote:
> [..]
> > > You're describing the current situation, i.e. Linux already implements
> > > this, it's called Device-DAX and some users of RDMA find it
> > > insufficient. The
On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote:
> On Wed, Feb 06, 2019 at 05:24:50PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote:
> > > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote:
> > > > On Wed, Feb 06, 2019 at 07:16:21PM
The following traceback is sometimes seen when booting an image in qemu:
[ 54.608293] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 54.611085] Fusion MPT base driver 3.04.20
[ 54.611877] Copyright (c) 1999-2008 LSI Corporation
[ 54.616234] Fusion MPT SAS Host driver 3.04.20
[ 54.635139]
Murilo Opsfelder Araujo writes:
>> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
>> index 37b226e8df13..ef99edd63da3 100644
>> --- a/include/linux/uaccess.h
>> +++ b/include/linux/uaccess.h
>> @@ -263,6 +263,40 @@ extern long strncpy_from_unsafe(char *dst, const void
>>
On 06-02-19, 23:34, Yangtao Li wrote:
> Try and register an Energy Model from imx6q-cpufreq to allow
> interested subsystems like the task scheduler to use the provided
> information.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/cpufreq/imx6q-cpufreq.c | 1 +
> 1 file changed, 1 insertion(+)
>
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.0-rc4 next-20190206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/osd/osd_initiator.c
between commit:
24648908acac ("scsi: osd: osd_initiator: mark expected switch fall-throughs")
from the fixes tree and commit:
19fcae3d4f2d ("scsi: remove the SCSI OSD library")
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/lpfc/lpfc_nvme.c
between commit:
7961cba6f7d8 ("scsi: lpfc: nvme: avoid hang / use-after-free when destroying
localport")
from Linus' tree and commit:
4c47efc140fa ("scsi: lpfc: Move SCSI and NVME
On Thu, Feb 7, 2019 at 7:27 AM Matthias Kaehlcke wrote:
>
> On Wed, Feb 06, 2019 at 11:34:41AM -0800, Matthias Kaehlcke wrote:
> > On Wed, Feb 06, 2019 at 04:05:41PM +0530, Amit Kucheria wrote:
> > > On Sat, Jan 26, 2019 at 3:50 AM Matthias Kaehlcke
> > > wrote:
> > > > > > >
On 07-02-19, 11:47, Stephen Rothwell wrote:
> Hi Viresh,
>
> Today's linux-next merge of the opp tree got a conflict in:
>
> drivers/cpufreq/qcom-cpufreq-hw.c
>
> between commit:
>
> 5471b2c9bd08 ("cpufreq: qcom: Read voltage LUT and populate OPP")
>
> from the cpufreq-arm tree and
Try and register an Energy Model from omap-cpufreq.c to allow
interested subsystems like the task scheduler to use the provided
information.
Signed-off-by: Yangtao Li
---
drivers/cpufreq/omap-cpufreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On 06-02-19, 10:50, Matthias Kaehlcke wrote:
> Try and register an Energy Model from mediatek-cpufreq to allow
> interested subsystems like the task scheduler to use the provided
> information.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in v2:
> - register the EM after setting the
Try and register an Energy Model from imx6q-cpufreq to allow
interested subsystems like the task scheduler to use the provided
information.
Signed-off-by: Yangtao Li
---
drivers/cpufreq/imx6q-cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c
Hi Christoph,
I also didn’t notice the 32-bit DMA mask in your patch. I have to read your
patches and descriptions carefully in the future. I will test your new patch at
the weekend.
Thanks,
Christian
Sent from my iPhone
> On 6. Feb 2019, at 16:16, Christoph Hellwig wrote:
>
>> On Wed, Feb
Hi Laurent,
I'm not sure I'm convinced about this one. It seems like we're just
throwing away the warning because it's annoying.
Laurent Vivier writes:
> resize_hpt_for_hotplug() reports a warning when it cannot
> increase the hash page table ("Unable to resize hash page
> table to target
Changes since v1:
Addressed comments from Bhupesh Sharma, Thomas Gleixner, and Ard Biesheuvel:
* made __uv_bios_call() static
* moved the efi_enabled() cleanup to its own patchlet
* explained the reason for renaming the efi_runtime_lock semaphore
* dropped the reviewed-bys as they should be
Calls into UV firmware must be protected against concurrency, use the
now visible efi_runtime_sem lock to serialise them.
Cc: Russ Anderson
Cc: Mike Travis
Cc: Dimitri Sivanich
Cc: Steve Wahl
Cc: sta...@vger.kernel.org
Signed-off-by: Hedi Berriche
---
arch/x86/include/asm/uv/bios.h | 3 ++-
Make efi_runtime_lock semaphore global so that it can be used by EFI
runtime callers that may be defined outside efi/runtime-wrappers.c.
Also now that efi_runtime_lock semaphore is no longer static, rename it
to efi_runtime_sem so it doesn't clash with the efi_runtime_lock spinlock
defined in
From: Yizhuo
Date: Tue, 5 Feb 2019 14:15:59 -0800
> @@ -639,9 +639,14 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv
> *priv)
> struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
> struct device_node *node = priv->device->of_node;
> int ret;
> - u32 reg, val;
>
On 06-02-19, 10:16, Matthias Kaehlcke wrote:
> You are prefectly right, I missed the obvious and didn't get my hands
> on hardware yet for testing.
>
> So much for screwing up a one-liner ... I'll send a fix.
>
> I thought Viresh already applied the patch, however in opp/linux-next
> I currently
On Tue, Feb 05, 2019 at 09:21:33PM +0100, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> increase the hash page table ("Unable to resize hash page
> table to target order") but this is not blocking and
> can make user thinks something has not worked properly.
>
Neil Armstrong writes:
> Le 01/02/2019 15:53, Jerome Brunet a écrit :
>> This purpose of this patchset is to the main clock controller of the
>> g12a SoC family
>>
>> This patchset depends on the recent rework the meson clock directory [7].
[...]
> Reviewed-by: Neil Armstrong
>
> I'm
Jerome Brunet writes:
> The patchset remove the selection of CONFIG_COMMON_CLK_AMLOGIC.
> This CONFIG symbol:
> * Is already selected by controller driver which requires it.
> * Is being removed by this changeset [0]
>
> Whether or not series [0] is merged, selecting CONFIG_COMMON_CLK_AMLOGIC
>
On Wed, Feb 06, 2019 at 05:24:50PM -0500, Doug Ledford wrote:
> On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote:
> > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote:
> > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote:
> > > > On Wed, 6 Feb 2019, Doug
From: Bjorn Helgaas
Date: Tue, 05 Feb 2019 14:47:21 -0600
> From: Bjorn Helgaas
>
> 8c56df372bc1 ("net: add support for Cavium PTP coprocessor") added the
> Cavium PTP coprocessor driver and enabled it by default. Remove the
> "default y" because the driver only applies to Cavium ThunderX
syzbot has found a reproducer for the following crash on:
HEAD commit:8834f5600cf3 Linux 5.0-rc5
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=143fd61f40
kernel config: https://syzkaller.appspot.com/x/.config?x=8f00801d7b7c4fe6
dashboard link:
Neil Armstrong writes:
> On 18/01/2019 11:34, Jerome Brunet wrote:
>> This patchset adds support for the axg and g12a SoC family in amlogic's
>> clock measure driver and enable it on the related devices
>>
>> Changes since v1 [0]:
>> * re-order node in the g12a.dtsi
>> * change node name
>>
>>
Jerome Brunet writes:
> Fix apb, cbus, hiu and periph regions which are not aligned
> with the documentation and the information provided by Amlogic
>
> Fixes: 9c8c52f7cb4f ("arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT
> support")
> Cc: Jianxin Pan
> Signed-off-by: Jerome Brunet
On Wed, Feb 6, 2019 at 6:42 PM Doug Ledford wrote:
>
> On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote:
> > On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote:
> > > Can someone give me a real world scenario that someone is *actually*
> > > asking for with this?
> >
> > I'll point to this
Jerome Brunet writes:
> On Mon, 2019-01-21 at 14:53 +0100, Linus Walleij wrote:
>> On Thu, Jan 17, 2019 at 11:23 AM Jerome Brunet wrote:
>>
>> > This patchset fixes the initial pinctrl support added for th g12a SoC
>> > family, which is mainly around the register regions claimed by the
>> >
On Thu, Feb 07, 2019 at 10:38:58AM +0800, Coly Li wrote:
> On 2019/2/7 10:26 上午, Dave Chinner wrote:
> > On Thu, Feb 07, 2019 at 01:24:25AM +0100, Andre Noll wrote:
> >> On Thu, Feb 07, 10:43, Dave Chinner wrote
> >>> File data readahead: REQ_RAHEAD
> >>> Metadata readahead: REQ_META | REQ_RAHEAD
Jerome Brunet writes:
> Add device tree bindings for the reset controller of g12a SoC family.
>
> Acked-by: Neil Armstrong
> Signed-off-by: Jerome Brunet
Acked-by: Kevin Hilman
Randy Dunlap writes:
> On 2/6/19 2:05 AM, Michael Ellerman wrote:
>> Randy Dunlap writes:
>>> On 2/4/19 9:46 AM, Randy Dunlap wrote:
On 2/4/19 5:42 AM, Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.0-rc5[1] compared to
On Wed, Feb 6, 2019 at 5:57 PM Doug Ledford wrote:
[..]
> > > > Dave, you said the FS is responsible to arbitrate access to the
> > > > physical pages..
> > > >
> > > > Is it possible to have a filesystem for DAX that is more suited to
> > > > this environment? Ie designed to not require block
Hi Jarkko,
After merging the tpmdd tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/char/tpm/tpm_i2c_nuvoton.c:45: warning: "TPM_RETRY" redefined
#define TPM_RETRY 5
In file included from drivers/char/tpm/tpm_i2c_nuvoton.c:35:
drivers/char/tpm/tpm.h:43:
On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote:
> > Can someone give me a real world scenario that someone is *actually*
> > asking for with this?
>
> I'll point to this example. At the 6:35 mark Kodi talks about the
> Oracle use case
1 - 100 of 994 matches
Mail list logo
