This series adds Mediated device support to Linux host kernel. Purpose
of this series is to provide a common interface for mediated device
management that can be used by different devices. This series introduces
Mdev core module that creates and manages mediated devices, VFIO based
driver for media
vfio_mdev driver registers with mdev core driver.
mdev core driver creates mediated device and calls probe routine of
vfio_mdev driver for each device.
Probe routine of vfio_mdev driver adds mediated device to VFIO core module
This driver forms a shim layer that pass through VFIO devices operation
This change rearrange functions to have common function to increment
container_users
Signed-off-by: Kirti Wankhede
Signed-off-by: Neo Jia
Change-Id: I8bdeb352bc8439b107ffd519480fd4dc238677f2
---
drivers/vfio/vfio.c | 34 +-
1 file changed, 21 insertions(+), 13 de
Design for Mediated Device Driver:
Main purpose of this driver is to provide a common interface for mediated
device management that can be used by different drivers of different
devices.
This module provides a generic interface to create the device, add it to
mediated bus, add device to IOMMU grou
On Friday 04 November 2016 11:04 AM, Sekhar Nori wrote:
> Hi Kishon,
>
> On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
>>> There is only one ohci on the da8xx series of chips,
>>> so remove the ".0" when c
Fixed regulators (ex. TPS2087D) may have a over current pin that
is activated on over current. Consumers may be interested to know
about over current events to take appropriate actions.
Allow the fix regulator to take in an optional gpio pin for over
current and send the respective event to the co
On Fri, Nov 04, 2016 at 10:05:15AM -0700, Randy Dunlap wrote:
> On 11/03/16 23:53, Joe Perches wrote:
> > On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote:
> >> From: Madalin Bucur
> >> Date: Wed, 2 Nov 2016 22:17:26 +0200
> >>
> >>> This introduces the Freescale Data Path Acceleration Archit
Hello Mr. Torokhov,
As you can see that this patch is pending for a long time,
I request you to please review it at the earliest possible.
Thanks,
Aniroop Mathur
On Thu, Oct 13, 2016 at 12:05 AM, Aniroop Mathur
wrote:
> Hello Mr. Torokhov,
>
> Hope you are doing great!
>
> Could you please he
On 2016-11-04 16:42:33 [-0400], Charles (Chas) Williams wrote:
> This comes from here:
>
> unsigned int apicid = apic->cpu_present_to_apicid(cpu);
>
> if (apicid == BAD_APICID || !apic->apic_id_valid(apicid))
> continue;
> if
Quoting Peter Chen (2016-10-24 18:16:32)
> On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > > Hi,
> > >
> > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd
> > > wrote:
> > > > The ULPI bus can be built as a module, and it will soon
On Tue, Nov 1, 2016 at 9:51 PM, Joshua Clayton wrote:
> imx-weim should always set address-cells to 2,
> and size_cells to 1.
> On imx6, fsl,weim-cs-gpr will always be &gpr
>
> Set these common parameters in the dtsi file,
> rather than in a downstream dts.
>
> Signed-off-by: Joshua Clayton
Revi
Anyone have advice where else I can ask?
On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis wrote:
> Anyone have suggestions?
>
> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis
> wrote:
>> Hi,
>>
>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>> after loading the in
Hi!
> > Let me try v4.9-rc2... that works ok (cpus at the high frequency
> > during the kernel build). Unfortunately that sends my cpus to 99C
> > temperature range (and eventually forces emergency shutdown).
>
> This we have to debug. Do you see same line like
> "
> /sys/devices/system/cpu/cpu0
On 11/04/2016 02:03 PM, Sebastian Andrzej Siewior wrote:
On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote:
The initial CPU boots and is identified:
[0.009018] identify_boot_cpu
[0.009174] generic_identify: phys_proc_id is now 0
...
[0.009427] identify_cpu: before c
Bartosz Golaszewski writes:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Kevin Hilman
The patch
ASoC: sun4i-codec: Add support for A31 analog microphone inputs
has been applied to the asoc tree at
git://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 ho
The patch
ASoC: sun4i-codec: Add support for A31 board level audio routing
has been applied to the asoc tree at
git://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 h
Bartosz Golaszewski writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Kevin Hilman
The patch
ASoC: sun4i-codec: Add support for A31 Line Out playback
has been applied to the asoc tree at
git://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) an
This includes:
- Fix for a Qualcomm driver issue that causes a use-before-set crash
- Fix for DesignWare iATU unroll support that causes external aborts when
enabling the host bridge
The following changes since commit 02a1b8f4167eac709d269341f7c3c340984c28a6:
PCI: designware-plat: Upda
On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek wrote:
> On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
>> * Pavel Machek [161104 00:10]:
>> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
>> > Do you actually have hardware with more than one bq27xxx?
>>
>> I can at least see the twl4030 batter
On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote:
>
> There are a set of fixes for an oops we've been seeing around MST
> display unplug,
Side note: I heard from a couple of people at the KS that said that
they had had problems with suspend/resume after plugging in to a 4k
display (but _only_ a
On 2016-11-04 20:47:49 [+0100], Wolfram Sang wrote:
> Looks OK to me, still I'd like an ack from Sebastian for this patch.
>
Acked-by: Sebastian Andrzej Siewior
Sebastian
On 07/04, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> arch/arm/mach-omap2/Kconfig:config SOC_DRA7XX
> arch/arm/mach-omap2/Kconfig:bool "TI DRA7XX"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the mod
On Mon, Oct 31, 2016 at 6:37 PM, Kyle Huey wrote:
> Hardware support for faulting on the cpuid instruction is not required to
> emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
> MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
> cpuid-induced VM exit
On Mon, Oct 31, 2016 at 01:19:58AM +, Kuninori Morimoto wrote:
> +This Simple-Graph-Card should be located as CPU driver's port[s].
> +And then, CPU driver need to probe it by itself.
This document really needs quite a bit of fleshing out but I'm not sure
that should be a blocker for the seri
On 07/04, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> arch/arm/mach-tegra/Kconfig:config ARCH_TEGRA_124_SOC
> arch/arm/mach-tegra/Kconfig:bool "Enable support for Tegra124 family"
>
> ...meaning that it currently is not being built as a module by
On 07/04, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/clk/mvebu/Kconfig:config ARMADA_CP110_SYSCON
> drivers/clk/mvebu/Kconfig: bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular
On 07/04, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/clk/mvebu/Kconfig:config ARMADA_AP806_SYSCON
> drivers/clk/mvebu/Kconfig: bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular
[fixing akpm's email address]
On Fri, Nov 04, 2016 at 03:58:22PM +1100, Michael Ellerman wrote:
> Christopher Covington writes:
>
> > Checkpoint/Restore In Userspace (CRIU) needs to be able to unmap and remap
> > the VDSO to successfully checkpoint and restore applications in the face of
> > cha
On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
> * Pavel Machek [161104 00:10]:
> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> > Do you actually have hardware with more than one bq27xxx?
>
> I can at least see the twl4030 battery/charger features
> being used together with some bq devic
Hello.
On 11/04/2016 07:43 PM, Alexandre Bailon wrote:
During the init, the driver will use the mode to configure
the controller mode and the phy mode.
PHY -- be consistent please...
The PHY of DA8xx has some issues when the phy is forced in host or device.
Again.
Add way to skip
On 10/24/2016 09:17 AM, Vineet Gupta wrote:
> Older ARC700 cores (ARC750 specifically) lack instructions to implement
> atomic r-w-w. This is problematic for userspace libraries such as NPTL
> which need atomic primitives. So enable them by providing kernel assist.
> This is costly but really the o
On 11/02, Robert Jarzmik wrote:
> This is the initial stage to transfer the pxa25x and pxa27x CPU clocks
> handling from cpufreq to the clock API. More precisely, the clocks
> transferred are :
> - cpll : core pll, known also as the CPU core turbo frequency
> - core : core, known also as the CPU
On 11/04, Sricharan wrote:
> Hi,
> >
> >A better design would be to check if the associated GDSC is in hw
> >control mode and then skip the checks because the clocks are no
> >longer under the control of the registers. I presume we only
> >enable the clocks here to turn on parent clocks which don't
On 16-11-04 09:50 AM, Mark Lord wrote:
> Yeah, the device or driver is definitely getting confused with rx_desc
> structures.
> I added code to check for unlikely rx_desc values, and it found this for
> starters:
>
> rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 0048f400 pkt_len=2045
> r
On Mon, Oct 31, 2016 at 01:17:09AM +, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
> and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
> But graph base DT is using "remote-endpoint". This patch makes
On 04.11.2016 18:44, Joe Perches wrote:
> On Fri, 2016-11-04 at 11:07 -0400, David Miller wrote:
>> From: Lino Sanfilippo
>> > On 04.11.2016 07:53, Joe Perches wrote:
>> >> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to
>> >> shortest
>> >> #446: FILE: drivers/net/ethernet/ethoc.
On Fri, Nov 4, 2016 at 5:28 AM, Linus Walleij wrote:
> On Tue, Nov 1, 2016 at 4:57 PM, Andrey Smirnov
> wrote:
>
>> None of the OF match table entries contain any compatiblity strings that
>> could not be matched against using i2c_device_id table above and
>> of_modalias_node. Besides that entri
On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
>
> Yes they would: this is moving functionality from platform co
On Mon, Oct 31, 2016 at 01:59:47PM -0400, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/i2c/busses/Kconfig:config I2C_PXA_PCI
> drivers/i2c/busses/Kconfig: def_bool I2C_PXA && X86_32 && PCI && OF
>
> ...meaning that it currently is not bein
On Fri, 4 Nov 2016 13:11:35 +0100 Hans de Goede wrote:
> This reverts commit 05fd007e4629 ("console: don't prefer first registered
> if DT specifies stdout-path").
>
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Ra
Please pull nfsd bugfixes from
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.9-1
--b.
Fixes for some recent regressions including fallout from the vmalloc'd
stack change (after which we can no longer encrypt stuff on the sta
On Fri, 4 Nov 2016, Matthew Fortune wrote:
> > This code is executed in the user mode so while floating-point code may
> > not be needed there, not at least right now, there's actually nothing
> > which should stop us from from adding some should such a need arise.
>
> Indeed. For now though the
On 11/04/2016 11:43 AM, Alexandre Bailon wrote:
During the init, the driver will use the mode to configure
the controller mode and the phy mode.
The PHY of DA8xx has some issues when the phy is forced in host or device.
Add way to skip the set mode and let the da8xx glue manage the phy mode.
I
On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote:
> On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> > Pratyush Anand (6):
> > arm64: kprobe: protect/rename few definitions to be reused by uprobe
> > arm64: kgdb_step_brk_fn: ignore other's exception
> > arm64:
Hi
I've got these two stacktraces with the kernel 4.9-rc3. The strange thing
is that the kernel doesn't say what kind of problem happened - just a
register dump and stack trace.
It happened on virtual machine guest running in qemu-kvm.
Mikulas
[ 166.917189] CPU: 0 PID: 0 Comm: swapper/0 Not
Debian gcc's is nowdays compiled with --enable-default-pie which means it does
-fPIE by default. This breaks atleast x86-64 compiles.
This is the third attempt to fix it, this time by using runtime detection of
the -fno-PIE compiler switch (it was introduced in gcc 3.4, min required gcc is
currentl
From: Vivien Didelot
Date: Fri, 4 Nov 2016 03:23:25 +0100
> The Marvell chips have one internal SMI device per port, containing a
> set of registers used to configure a port's link, STP state, default
> VLAN or addresses database, etc.
>
> This patchset creates port files to implement the port
Debian started to build the gcc with -fPIE by default so the kernel
build ends before it starts properly with:
|kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
Also add to KBUILD_AFLAGS due to:
|gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY
Adding -no-PIE to the fstack protector check. -no-PIE was introduced
before -fstack-protector so there is no need for a runtime check.
Without it the build stops:
|Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available
but compiler is broken
due to -mcmodel=kernel + -fPIE
If the gcc is configured to do -fPIE by default then the build aborts
later with:
| Unsupported relocation type: unknown type rel type name (29)
Tagging it stable so it is possible to compile recent stable kernels as
well.
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
> -Original Message-
> From: Stuart Yoder
> Sent: Friday, November 04, 2016 4:32 PM
> To: Ruxandra Ioana Radulescu ;
> gre...@linuxfoundation.org
> Cc: German Rivera ; de...@driverdev.osuosl.org;
> linux-kernel@vger.kernel.org; ag...@suse.de; a...@arndb.de; Leo Li
> ; Roy Pledge
> Subject:
On Fri, Nov 04, 2016 at 04:55:05PM +, Matthew Fortune wrote:
> Maciej Rozycki writes:
> > On Fri, 4 Nov 2016, Guenter Roeck wrote:
> >
> > > > As above, unless absolutely critical to have floating point code
> > > > then the vDSO should just avoid all FP related issues and build
> > soft-floa
The BQ27510 and BQ27520 use a slightly different register map than the
BQ27500, add a new type enum and add these gauges to it.
Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional
bq27xxx family devices")
Based-on-patch-by: Kenneth R. Crudup
Signed-off-by: Andrew F. Davis
-
On Thu, 2016-11-03 at 18:07 +0800, Ooi, Joyce wrote:
> There are 2 usage types (Magnetic Flux and Heading data field) for
> HID
> compass sensor, thus the values of offset, scale, and sensitivity
> should
> be separated according to their respective usage type. The changes
> made
> are as below:
>
Hi David,
On 11/04/2016 06:54 PM, David Miller wrote:
> From: Sebastian Frias
> Date: Fri, 4 Nov 2016 18:02:15 +0100
>
>> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
>> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
>> delay for tx and rx only")
Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
delay for tx and rx only") added several RGMII definitions:
PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID and
PHY_INTERFACE_MODE_RGMII_TXID to d
The delay can be applied at PHY or MAC level, but since
PHY drivers will apply the delay at PHY level when using
one of the "internal delay" declinations of RGMII mode
(like PHY_INTERFACE_MODE_RGMII_TXID), applying it again
at MAC level causes issues.
Signed-off-by: Sebastian Frias
---
drivers/n
This is v3 of the series, it fixes formatting issues of v2.
In v2 of the series, only the second patch:
"net: ethernet: nb8800: handle all RGMII definitions" is modified
to account for Florian's suggestion.
Sebastian Frias (2):
net: ethernet: nb8800: Do not apply TX delay at MAC level
net: et
Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
delay for tx and rx only") added several RGMII definitions:
PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID and
PHY_INTERFACE_MODE_RGMII_TXID to d
On Thu, Nov 03, 2016 at 12:11:44PM +0100, Axel Haslam wrote:
> Fixed regulators (ex. TPS2087D) may have a over current pin that
> is activated on over current. Consumers may be interested to know
> about over current events to take appropriate actions.
This doesn't apply against current code, plea
The delay can be applied at PHY or MAC level, but since
PHY drivers will apply the delay at PHY level when using
one of the "internal delay" declinations of RGMII mode
(like PHY_INTERFACE_MODE_RGMII_TXID), applying it again
at MAC level causes issues.
Signed-off-by: Sebastian Frias
---
drivers/ne
This is v2 of the series, only the second patch:
"net: ethernet: nb8800: handle all RGMII definitions" is modified
to account for Florian's suggestion.
Sebastian Frias (2):
net: ethernet: nb8800: Do not apply TX delay at MAC level
net: ethernet: nb8800: handle all RGMII definitions
drivers/n
The patch
regulator: core: Add new API to poll for error conditions
has been applied to the regulator tree at
git://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
Hi Vineet,
A couple of misspellings in the commit message below.
> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Friday, November 04, 2016 12:32 AM
> To: Daniel Lezcano
> Cc: Noam Camus ; t...@linutronix.de;
> linux-snps-...@lists.infradead.org; linux-kern
Please squish this and patch 5 together. It makes no sense to separate
them.
> +static void send_unused_pages_info(struct virtio_balloon *vb,
> + unsigned long req_id)
> +{
> + struct scatterlist sg_in;
> + unsigned long pfn = 0, bmap_len, pfn_limit, last_pfn,
On Fri, 4 Nov 2016, Guenter Roeck wrote:
> > This code is executed in the user mode so while floating-point code may
> > not be needed there, not at least right now, there's actually nothing
> > which should stop us from from adding some should such a need arise.
> >
> Just for my understandin
On 2016-11-04 08:20:37 [-0400], Charles (Chas) Williams wrote:
> The initial CPU boots and is identified:
>
> [0.009018] identify_boot_cpu
> [0.009174] generic_identify: phys_proc_id is now 0
> ...
> [0.009427] identify_cpu: before c 81ae2680 logical_proc_id 0
> c->phys_proc
Hi Vineet,
> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Friday, November 04, 2016 12:32 AM
> To: Daniel Lezcano
> Cc: Noam Camus ; t...@linutronix.de;
> linux-snps-...@lists.infradead.org; linux-kernel@vger.kernel.org;
> alexey.brod...@synopsys.com; Vine
From: Sebastian Frias
Date: Fri, 4 Nov 2016 18:02:15 +0100
> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
> delay for tx and rx only") added several RGMII definitions:
> PHY_INTERFACE_MODE_RGMII_ID,
Some PWM regulator has the exponential transition in voltage change as
opposite to fixed slew-rate linear transition on other regulators.
For such PWM regulators, add the property for providing the delay
from DT node.
Add DT binding details of the new property
"pwm-regulator-voltage-ramp-time-us"
Some PWM regulator has the exponential transition in voltage change as
opposite to fixed slew-rate linear transition on other regulators.
For such PWM regulators, voltage transition is same for all voltage
change.
Add support for handling the voltage transition ramp time when voltage
transition is
On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> Pratyush Anand (6):
> arm64: kprobe: protect/rename few definitions to be reused by uprobe
> arm64: kgdb_step_brk_fn: ignore other's exception
> arm64: Handle TRAP_TRACE for user mode as well
> arm64: Handle TRAP_BRKPT for us
On Fri, 2016-11-04 at 15:03 +0100, Benjamin Tissoires wrote:
> On Nov 03 2016 or thereabouts, Ooi, Joyce wrote:
> >
> > User is unable to access to input-X-yyy and feature-X-yyy where
> > X is a hex value and more than 9 (e.g. input-a-yyy, feature-b-yyy)
> > in HID
> > sensor custom sysfs interfac
Hi Jacek,
Thank you very much.
Vadim.
> -Original Message-
> From: Jacek Anaszewski [mailto:j.anaszew...@samsung.com]
> Sent: Friday, November 04, 2016 10:38 AM
> To: Vadim Pasternak ; rpur...@rpsys.net
> Cc: linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; j...@resnulli.us
> Sub
The loop is scanning until the original max_ip (size of the BO), but
we want to not examine any code after the PROG_END's delay slots.
There was a block trying to do that, except that we had some early
continue statements if the signal wasn't a PROG_END or a BRANCH.
The failure mode would be that
The validation for it ends up being quite simple, but I hadn't got
around to it before merging the driver. For backwards compatibility,
we also need to add a flag so that the userspace GL driver can easily
tell if the kernel will allow ETC1 textures (on an old kernel, it will
continue to convert t
Hi Linus,
Here are some mmc fixes intended for v4.9 rc4. They are based on v4.9-rc2.
Details are as usual found in the signed tag. Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0
On Fri, 2016-11-04 at 11:07 -0400, David Miller wrote:
> From: Lino Sanfilippo
> > On 04.11.2016 07:53, Joe Perches wrote:
> >> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to
> >> shortest
> >> #446: FILE: drivers/net/ethernet/ethoc.c:446:
> >> +int size = bd.
Some TI Keystone family of SoCs contain a system controller (like the
Power Management Micro Controller (PMMC) on K2G SoCs) that manage the
low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations
are provided to the hos
Add TI SCI reset controller binding. This describes the DT binding
details for a reset controller node providing reset management services
to hardware blocks (reset consumers) using the Texas Instrument's System
Control Interface (TI SCI) protocol to communicate to a system controller
block present
Hello all,
This series adds a reset controller driver that uses the TI SCI
protocol to manage resets.
The TI SCI protocol is used to communicate with power management
controllers used by some SoCs. These controllers manage the various
power domains, clocks, and resets available on a SoC.
This se
On 11/03/2016 04:33 PM, Vineet Gupta wrote:
> ARC timers use aux registers for programming and this paves way for
> moving ARC timer drivers into drivers/clocksource
>
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/arcregs.h | 85
> +-
> arch/
On Thu, Nov 03, 2016 at 11:20:08PM +0100, Jason A. Donenfeld wrote:
> Hi David,
>
> On Thu, Nov 3, 2016 at 6:08 PM, David Miller wrote:
> > In any event no piece of code should be doing 32-bit word reads from
> > addresses like "x + 3" without, at a very minimum, going through the
> > kernel unal
On Sat, Nov 05, 2016 at 02:25:19AM +0900, Norbert Preining wrote:
> Hi Chris,
>
> > https://cgit.freedesktop.org/drm-intel/
>
> I pulled from there and rebuild my kernel. Rebooting and everything
> is fine. Looks much better!!!
>
> > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nex
Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
drm: make drm_get_format_name thread-safe
Signed-off-by: Eric Engestrom
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter
Note (Rob Clark):
I think we need to be a bit careful
Hi Linus,
My for-linus-4.9 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.9
Has some fixes that Dave Sterba collected. We held off on these last
week because I was focused on the memory corruption testing.
I had asked you about pulling this directly f
Hi Chris,
> https://cgit.freedesktop.org/drm-intel/
I pulled from there and rebuild my kernel. Rebooting and everything
is fine. Looks much better!!!
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you want me to test this
Sebastian Frias writes:
> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
> delay for tx and rx only") added several RGMII definitions:
> PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID and
On 27 October 2016 at 14:05, Markus Mayer wrote:
> From: Markus Mayer
>
> This series contains the CPUfreq driver for Broadcom SoCs that use "AVS
> Firmware" for voltage and frequency scaling. All voltage and frequency
> transitions are performed by the firmware and are therefore hidden from
> Li
On 11/03/16 23:53, Joe Perches wrote:
> On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote:
>> From: Madalin Bucur
>> Date: Wed, 2 Nov 2016 22:17:26 +0200
>>
>>> This introduces the Freescale Data Path Acceleration Architecture
>>> +static inline size_t bpool_buffer_raw_size(u8 index, u8 cnt)
>
On Thu, Nov 03, 2016 at 08:57:49PM -0700, Andy Lutomirski wrote:
>
> The crypto request objects can live on the stack just fine. It's the
> request buffers that need to live elsewhere (or the alternative
> interfaces can be used, or the crypto core code can start using
> something other than scat
From: Markus Mayer
Allow CPUfreq statistics to be cleared by writing anything to
/sys/.../cpufreq/stats/reset.
Signed-off-by: Markus Mayer
---
Documentation/cpu-freq/cpufreq-stats.txt | 6 ++
drivers/cpufreq/cpufreq_stats.c | 22 ++
2 files changed, 28 inserti
From: Markus Mayer
With the new attribute type, it is possible to create write-only
CPUfreq attributes.
Signed-off-by: Markus Mayer
---
include/linux/cpufreq.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 5fa55fc..ed09930 10064
On Sat, Nov 05, 2016 at 03:55:03AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Fri, 4 Nov 2016 15:48:02 + Liviu Dudau wrote:
> >
> > Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> > alone should be good. Baoyou's patch is in my tree to stop him repeatedly
Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition")
and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal
delay for tx and rx only") added several RGMII definitions:
PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID and
PHY_INTERFACE_MODE_RGMII_TXID to d
Hi Liviu,
On Fri, 4 Nov 2016 15:48:02 + Liviu Dudau wrote:
>
> Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> alone should be good. Baoyou's patch is in my tree to stop him repeatedly
> send me the same patch over and over again :) But yes, I will add my
> Signe
From: Markus Mayer
This series lets the user clear the CPUfreq stats by writing to a new
sysfs attribute.
Changes since v1:
- add new cpufreq_freq_attr_wr_perm() macro for write-only
attributes (because this is a separate commit, this patch has
turned into a series)
- remove
Maciej Rozycki writes:
> On Fri, 4 Nov 2016, Guenter Roeck wrote:
>
> > > As above, unless absolutely critical to have floating point code
> > > then the vDSO should just avoid all FP related issues and build
> soft-float.
...
> > Anyway, isn't the kernel supposed to not use floating point operat
101 - 200 of 486 matches
Mail list logo
