Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness.
After the addition of led_update_brightness() this is no longer
true, as the function can change the brightness if a LED class
driver implements brightness_get op.
Adding more Thunderbolt(TM) register definitions
and some helper macros.
Signed-off-by: Amir Levy
---
drivers/thunderbolt/nhi_regs.h | 109 +
1 file changed, 109 insertions(+)
diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
in
This patch provides the communication protocol between the
Intel Connection Manager(ICM) firmware that is operational in the
Thunderbolt controller in non-Apple hardware.
The ICM firmware-based controller is used for establishing and maintaining
the Thunderbolt Networking connection - we need to be
Add Amir Levy as maintainer for Thunderbolt(TM) ICM driver
Signed-off-by: Amir Levy
---
MAINTAINERS | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 411e3b8..87763c44 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10652,7 +10652,13 @@ F:
Update to the Kconfig Thunderbolt description to add
Thunderbolt networking as an option.
The menu item "Thunderbolt support" now offers:
"Apple Hardware Support" (existing)
and/or
"Thunderbolt Networking" (new)
You can choose the driver for your platform or build both drivers -
each drive
This driver enables Thunderbolt Networking on non-Apple platforms
running Linux.
Thunderbolt Networking provides peer-to-peer connections to transfer
files between computers, perform PC migrations, and/or set up small
workgroups with shared storage.
This is a virtual connection that emulates an E
This patch provides the handling interface for sending and receiving
network packets between the hosts over the full communication route
(using the communication path established in the previous patch).
The Thunderbolt Network driver interfaces the Linux network stack
and the hardware controller c
This patch builds the peer to peer communication path.
Communication is established by a negotiation process whereby messages are
sent back and forth between the peers until a connection is established.
This includes the Thunderbolt Network driver communication with the second
peer via Intel Connec
This first patch updates the NHI Thunderbolt controller registers file to
reflect that it is not only for Cactus Ridge.
No functional change intended.
Signed-off-by: Amir Levy
Signed-off-by: Andreas Noever
---
drivers/thunderbolt/nhi_regs.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletio
Adding Thunderbolt(TM) networking documentation.
Signed-off-by: Amir Levy
---
Documentation/00-INDEX | 2 +
Documentation/thunderbolt/networking.txt | 132 +++
2 files changed, 134 insertions(+)
create mode 100644 Documentation/thunderbolt/network
Em Mon, 07 Nov 2016 12:53:55 +0200
Jani Nikula escreveu:
> On Mon, 07 Nov 2016, Mauro Carvalho Chehab wrote:
> > Hi Jon,
> >
> > I'm trying to sort out the next steps to do after KS, with regards to
> > images included on RST files.
> >
> > The issue is that Sphinx image support highly depends o
On 03/11/2016 14:58, John Garry wrote:
The following patch introduces an annoying WARN
when a device is removed from the SAS topology:
[SCSI] libsas: prevent domain rediscovery competing with ata error handling
Are there any views on this patch? I would have thought that the parties
who use t
Oliver Neukum writes:
> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>
>> These problems could very well be caused by running at SuperSpeed
>> (USB-3) instead of high speed (USB-2).
>>
>> Is there any way to test what happens when the device is attached to
>> the computer by a USB-2 cab
Hi!
> On 04-11-16 08:52, Jacek Anaszewski wrote:
> >Initially the claim about no need for lock in brightness_show()
> >was valid as the function was just returning unchanged
> >LED brightness. After the addition of led_update_brightness() this
> >is no longer true, as the funct
Hi!
> Initially the claim about no need for lock in brightness_show()
> was valid as the function was just returning unchanged
> LED brightness. After the addition of led_update_brightness() this
The claim was probably wrong from the day one, unless brightness is of
type "atomic_t".
The commit 4bcc595ccd80decb4245 ("printk: reinstate KERN_CONT for printing
continuation lines") added back KERN_CONT message header. As a result
it might appear in the middle of the line when the parts are squashed
via the temporary NMI buffer.
A reasonable solution seems to be to split the text i
The first patch fixes a messed output of continuous lines
when printing backtraces for all CPUs via NMI.
The other patches fix problems that I noticed when working
on the first patch.
I have incorporated the feedback and did much more testing.
Åll patches have changed so I did not add the taken R
On Mon, Nov 07, 2016 at 10:50:38AM +0800, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -12.7% regression of will-it-scale.per_process_ops due to
> commit:
>
>
> commit adb402cd1461eef6e1a21db4532a3b9e6a6be853 ("x86/copy_user: Unify the
> code by removing the 64-bit asm _copy_*
The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for
printing continuation lines") allows to define more message headers
for a single message. The motivation is that continuous lines might
get mixed. Therefore it make sense to define the right log level
for every piece of a cont li
The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for
printing continuation lines") allows to define more message headers
for a single message. The motivation is that continuous lines might
get mixed. Therefore it make sense to define the right log level
for every piece of a cont li
The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for
printing continuation lines") allows to define more message headers
for a single message. The motivation is that continuous lines might
get mixed. Therefore it make sense to define the right log level
for every piece of a cont li
As reported by gcc -Wmaybe-uninitialized, the cleanup path for
skd_acquire_msix tries to free the already allocated msi-x vectors
in reverse order, but the index variable may not have been
used yet:
drivers/block/skd_main.c: In function ‘skd_acquire_irq’:
drivers/block/skd_main.c:3890:8: error: ‘i
Building with W=1 shows a harmless warning for the skd driver:
drivers/block/skd_main.c:2959:1: error: ‘static’ is not at beginning of
declaration [-Werror=old-style-declaration]
This changes the prototype to the expected formatting.
Signed-off-by: Arnd Bergmann
---
drivers/block/skd_main.c |
2016-10-31 12:36 GMT+00:00 Stanislaw Gruszka :
> Patches remove accounting of utimescaled/stimescaled on architectures
> that do not provide those values (scaled cputimes are equal to normal
> cputimes) what is every architecture except powerpc and s390.
>
> Patches do not change user visible behav
On 11/04/2016 05:49 PM, Måns Rullgård wrote:
>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers
>>> will apply the delay.
>>>
>>> I think a better way of dealing with this is that both, PHY and MAC
>>> drivers exchange information so that the delay is applied only once.
>>
>
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 04, 2016 9:50 PM
[...]
> 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
Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu:
> On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote:
> > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf
> > wrote:
> > > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> > >> This patches fix problems in hierarchy outp
Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu:
> On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> > Hello,
> >
> > This patches fix problems in hierarchy output Markus reported some
> > time ago. The code is available on the 'perf/hierarchy-fix-v1' branch
> > in my tre
On Tue, Nov 08, 2016 at 10:39:55AM -0800, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. Exposing this feature to userspace will allow a
> ptracer to t
On 11/08/2016 10:18 PM, Robert Jarzmik wrote:
[...]
>>> +/**
>>> + * struct ac97_controller - The AC97 controller of the AC-Link
>>> + * @ops: the AC97 operations.
>>> + * @controllers: linked list of all existing controllers.
>>> + * @dev: the device providing the AC97 contro
On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom
wrote:
>> Well, had to drop it again since it didn't compile:
>>
>>
>> CC [M] drivers/gpu/drm/drm_blend.o
>> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
>> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments
On 2016.11.09 at 10:11 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2016 at 02:21:17PM +0100, Markus Trippelsdorf escreveu:
> > On 2016.11.08 at 22:08 +0900, Namhyung Kim wrote:
> > > Hello,
> > >
> > > This patches fix problems in hierarchy output Markus reported some
> > > time ago.
Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
> From: Andi Kleen
>
> Since the unprivileged sched switch event was added in perf,
> PT doesn't need need perf_event_paranoid=-1 anymore for
> per cpu decoding. So remove the obsolete paragraph in
> the documentation.
Thanks for poi
On 2016.11.09 at 10:10 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2016 at 04:10:23PM +0100, Markus Trippelsdorf escreveu:
> > On 2016.11.09 at 00:05 +0900, Namhyung Kim wrote:
> > > On Tue, Nov 8, 2016 at 10:43 PM, Markus Trippelsdorf
> > > wrote:
> > > > On 2016.11.08 at 22:08 +0900
On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote:
> On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote:
> >
> > Hello, Bruce.
> >
> > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote:
> > >
> > > Apologies, just cleaning out old mail and finding some I should have
>
On 16-11-09 08:09 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
..
>> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045
>> isn't
>> valid here.
>> And the rx_desc values look an awful lot like the rx_data values that follow
>> it.
>>
>> There's definitely more
On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote:
> The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
> this function.
>
> Stick the call at the end of init_scattered_cpuid_features() for now. I
> still need to figure out a proper place for it.
So Thomas and I
From: Ziyuan Xu
Control power domain for eMMC via genpd to reduce power consumption.
Signed-off-by: Elaine Zhang
Signed-off-by: Ziyuan Xu
Signed-off-by: Caesar Wang
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/376558
- Verified on ChromeOS kernel4.4
arch/arm64
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO power rail sources. When IO
interface are not used then IO pads can be configure in low power
state to reduce the power from that
Hi all,
Please allow me to integrate these patches.
They are missing or losing for upstream, then there are some patches
are always depending on them.
The following patches are releated to PD.
git log --oneline
827198c arm64: dts: rockchip: add the usb3 pd for rk3399
95e95b4 arm64: dts: rockchip
From: Yakir Yang
Add rk3399 eDP device node, and connect to VOP device node with
remote endpoint.
Signed-off-by: Yakir Yang
Signed-off-by: Caesar Wang
(Caesar rebase the lastest and solve the conflict)
---
Changes in v2:
- Yakir posted the original patch on
- https://patchwork.kernel.org/pat
From: zhangqing
1.add pd node for RK3399 Soc
2.create power domain tree
3.add qos node for domain
4.add the pd_sd consumers node
Signed-off-by: Elaine Zhang
Signed-off-by: Caesar Wang
---
Changes in v2:
- v1 on https://patchwork.kernel.org/patch/9322553/
- Reviewed-on: https://chromium-review
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
sources. When IO interfaces are not used then IO pads can be
configure in low power state to reduce th
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
In ACPI bases systems, in order to be able to create platform
devices and initialize them for ARM SMMU components, the IORT
kernel implementation requires a set of static functions to be
used by the IORT kernel layer to configure platform
From: Yakir Yang
The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver
would failed to operate the VIO GRF registers.
Signed-off-by: Yakir Yang
Signed-off-by: Caesar Wang
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertio
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for usb3
Signed-off-by: Caesar Wang
---
Changes in v2:
- Reviewed-on: https://chromium-review.googlesource.com/384280
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 18 ++
1
From: zhangqing
1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain
4. add the pd support for edp
Signed-off-by: Elaine Zhang
Signed-off-by: Caesar Wang
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +
1 file changed, 5 insertions(
NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
sources. When IO interfaces are not used then IO pads can be
configure in low power state to reduce th
From: Yakir Yang
Add backlight node for evb board, perpare for panel device node.
Signed-off-by: Yakir Yang
Signed-off-by: Caesar Wang
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/
From: Brian Norris
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris
Signed-off-by: Caesar Wang
---
Changes in v2:
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54
Hi,
Documentation/networking/phy.txt discusses phy_connect and states that:
"...
interface is a u32 which specifies the connection type used
between the controller and the PHY. Examples are GMII, MII,
RGMII, and SGMII. For a full list, see include/linux/phy.h
Now just make sure that phyd
From: Mark Yao
Add the core display-subsystem node and the two display controllers
available on the rk3399.
Signed-off-by: Mark Yao
Signed-off-by: Yakir Yang
Signed-off-by: Caesar Wang
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58
1
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from __do_page_fault on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont
to provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfe
Tegra SoC support the configutaion of IO pads to multi-level voltage
and low power state. The conifguration is done via pictrl framework
and the io pad driver in pinctrl frameowrk uses the APIs from pmc to
access PMC registers.
his series add the API to get the IO pad power status and register
the
On Tue, Nov 08, 2016 at 05:20:56PM +0100, Peter Rosin wrote:
> The TSE-850 is an FM Transmitter Station Equipment, designed to generate
> baseband signals for FM, mainly the DARC subcarrier, but other signals
> are also possible.
Please use subject lines matching the style for the subsystem. This
Power Management Controller(PMC) of Tegra does the multiple chip
power management related functionality for internal and IO interfacing.
Some of the functionalities are power gating of IP blocks, IO pads
voltage and power state configuration, system power state configurations,
wakeup controls etc.
Thanks Corrina for your info.
I tested my patch, it works for me on kernel 4.9-rc4.
"surprise removal" maybe another issue to solve. This one is enough to
solve my issue and other one's, could it be accept first?
Cao jin
On 11/09/2016 03:33 AM, Alexander Duyck wrote:
On Tue, Nov 8, 2016 at 1
Hello Wang Nan,
On 10/24/2016 08:52 AM, Wang Nan wrote:
> Linux 4.7 (86e7972f690c1017fd086cdfe53d8524e68c661c) introduces
> PERF_EVENT_IOC_PAUSE_OUTPUT feature. Document it.
>
> Signed-off-by: Wang Nan
> Reviewed-by: Vince Weaver
> Cc: Michael Kerrisk
> ---
> man2/perf_event_open.2 | 24 +
Add API to get the IO pad power status of the Tegra IO pads.
This will help client driver to get the current power status
of IO pads for handling IO pad power.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
None
---
drivers/soc/tegra/pmc.c | 22 ++
include/soc/tegra/pm
Remove tegra_io_rail_power_on() and tegra_io_rail_power_off()
from header as client has been moved to new APIs.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
None
---
include/soc/tegra/pmc.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/soc/tegra/pmc.h b/include/
On 08/11/16 22:07, Zach Brown wrote:
> On NI 9037 boards the max SDIO frequency is limited by trace lengths
> and other layout choices. The max SDIO frequency is stored in an ACPI
> table, as MXFQ.
>
> The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the
> f_max field of the ho
The IO pad voltage configuration can be done in the regulator
notifier callback which is atomic in nature.
Replace the mutex with spin lock for the locking mechanism.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
New in series based on pinctrl driver requirement.
---
drivers/soc/tegra/p
The newly added pxa glue driver for 8250 supports console output, but
fails to build if the 8250 console is disabled:
drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup':
8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup'
This adds an #ifdef like th
Hello Wang Nan,
On 10/24/2016 08:52 AM, Wang Nan wrote:
> Linux 4.7 (9ecda41acb971ebd07c8fb35faf24005c0baea12) introduces write_backward
> attribute to perf_event_attr. Document this feature.
>
> Signed-off-by: Wang Nan
> Reviewed-by: Vince Weaver
> Cc: Michael Kerrisk
> ---
> man2/perf_event
Hi Thomas,
On 09/11/16 10:15, Thomas Gleixner wrote:
On Wed, 2 Nov 2016, Matt Redfearn wrote:
The MIPS remote processor driver allows non-Linux firmware to take
control of and execute on one of the systems VPEs. The CPU must be
offlined from Linux first. A sysfs interface is created which allo
On 11/08/2016 08:50 PM, Peter Zijlstra wrote:
>> The problem is that using RT_RUNTIME_SHARE a CPU will almost always
>> > borrow enough runtime to make a CPU intensive rt task to run forever...
>> > well not forever, but until the system crash because a kworker starved
>> > in this CPU. Kworkers
Hi Arnd,
On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and
On Wed, 9 Nov 2016, Borislav Petkov wrote:
> On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote:
> > The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
> > this function.
> >
> > Stick the call at the end of init_scattered_cpuid_features() for now. I
> > still ne
On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote:
> +++ b/sound/soc/axentia/Kconfig
> @@ -0,0 +1,10 @@
> +config SND_SOC_AXENTIA_TSE850_PCM5142
> + tristate "ASoC driver for the Axentia TSE-850"
> + depends on ARCH_AT91 && OF
> + select ATMEL_SSC
> + select SND_ATMEL_SOC
New Cadence GEM hardware support Large Segment Offload (LSO):
TCP segmentation offload (TSO) as well as UDP fragmentation
offload (UFO). Support for those features was added to the driver.
Signed-off-by: Rafal Ozieblo
---
Changed in v2:
macb_lso_check_compatibility() changed to macb_features_chec
Add HWCAP2 for x86 and reserve its bit 0 to expose
ring 3 mwait.
Signed-off-by: Grzegorz Andrejczuk
---
arch/x86/include/asm/elf.h | 9 +
arch/x86/include/uapi/asm/hwcap2.h | 7 +++
arch/x86/kernel/cpu/common.c | 3 +++
3 files changed, 19 insertions(+)
create mode 100
These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT
instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs.
Then expose it as CPU feature and introduces elf HWCAP capability for x86.
Reference:
https://software.intel.com/en-us/blogs/2016/10/06/intel-xeon-phi-
Add Intel Xeon Phi x200 (KnightsLanding) CPU feature - ring 3 MONITOR/MWAIT.
Signed-off-by: Grzegorz Andrejczuk
---
arch/x86/include/asm/cpufeatures.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
inde
Intel Xeon Phi x200 (codenamed Knights Landing) allows to enable
MONITOR and MWAIT instructions outside of ring 0.
The feature is controlled by MSR MISC_FEATURE_ENABLES (0x140).
Setting bit 1 of this register enables it, so MONITOR and MWAIT
instructions do not cause invalid-opcode exceptions when
Unfortunately presence of this feature cannot be detected
automatically (by reading some other MSR) therefore it is required
to do explicit check for the family and model of the cpu.
If processor is Intel Xeon Phi x200 RING 3 MONITOR/MWAIT feature is enabled
by setting cpu cap X86_FEATURE_RING3MWA
Hi Mika,
Le 17/10/2016 à 16:58, Mika Westerberg a écrit :
> Add support for the SPI serial flash host controller found on many Intel
> CPUs including Baytrail and Braswell. The SPI serial flash controller is
> used to access BIOS and other platform specific information. By default the
> driver exp
> I think it is a relatively safe assumption that there is only one
> ISA bridge. A lot of old drivers hardcode PIO or memory addresses
It's not a safe assumption for x86 at least. There are a few systems with
multiple ISA busses particularly older laptops with a docking station.
> when talking t
Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
> > From: Andi Kleen
> >
> > Since the unprivileged sched switch event was added in perf,
> > PT doesn't need need perf_event_paranoid=-1 anymore for
> > p
On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote:
> Extend the driver to support Ricoh RC5T619.
> Support the additional regulators and slightly different voltage ranges.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung
looks good, my veyron-pinky and rk303
On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
>>> From: Andi Kleen
>>>
>>> Since the unprivileged sched switch event was added in perf,
>>> PT doesn
On 10/28/2016 05:29 PM, Randy Li wrote:
On 10/28/2016 05:11 PM, Shawn Lin wrote:
On 2016/10/23 3:18, Randy Li wrote:
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first.
On Wed, Nov 09, 2016 at 02:51:20PM +0100, Cyrille Pitchen wrote:
> > +/* Reads max 64 bytes from the device fifo */
> > +static int intel_spi_read_block(struct intel_spi *ispi, void *buf, size_t
> > size)
> > +{
> > + size_t bytes;
> > + int i = 0;
> > +
> > + if (size > 64)
>
> This is not
The of_iommu_{set/get}_ops() API is used to associate a device
tree node with a specific set of IOMMU operations. The same
kernel interface is required on systems booting with ACPI, where
devices are not associated with a device tree node, therefore
the interface requires generalization.
The struc
Device drivers (eg ARM SMMU) need to know if a specific component
is part of the IORT table, so that kernel data structures are not
initialized at initcalls time if the respective component is not
part of the IORT table.
To this end, this patch adds a trivial function that allows detecting
if a gi
In ACPI bases systems, in order to be able to create platform
devices and initialize them for ARM SMMU v3 components, the IORT
kernel implementation requires a set of static functions to be
used by the IORT kernel layer to configure platform devices for
ARM SMMU v3 components.
Add static configura
On systems booting with a device tree, every struct device is associated
with a struct device_node, that provides its DT firmware representation.
The device node can be used in generic kernel contexts (eg IRQ
translation, IOMMU streamid mapping), to retrieve the properties
associated with the devic
On Wed, 9 Nov 2016, Matt Redfearn wrote:
> On 09/11/16 10:15, Thomas Gleixner wrote:
> > On Wed, 2 Nov 2016, Matt Redfearn wrote:
> > > The MIPS remote processor driver allows non-Linux firmware to take
> > > control of and execute on one of the systems VPEs. The CPU must be
> > > offlined from Lin
Current ARM SMMUv3 probe functions intermingle HW and DT probing in the
initialization functions to detect and programme the ARM SMMU v3 driver
features. In order to allow probing the ARM SMMUv3 with other firmwares
than DT, this patch splits the ARM SMMUv3 init functions into DT and HW
specific po
On DT based systems, the of_dma_configure() API implements DMA
configuration for a given device. On ACPI systems an API equivalent to
of_dma_configure() is missing which implies that it is currently not
possible to set-up DMA operations for devices through the ACPI generic
kernel layer.
This patch
2016-11-09 13:12+0100, Radim Krčmář:
> 2016-11-09 00:25+0100, Paolo Bonzini:
>> On 08/11/2016 20:54, Radim Krčmář wrote:
>>> +static int em_fxsave(struct x86_emulate_ctxt *ctxt)
>>> +{
>>> + struct fxregs_state fx_state;
>>> + size_t size = 288; /* up to XMM7 */
>>
>> Sorry for noticing this o
On 10/28/2016 05:29 PM, Randy Li wrote:
On 10/28/2016 05:11 PM, Shawn Lin wrote:
On 2016/10/23 3:18, Randy Li wrote:
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first.
In ACPI bases systems, in order to be able to create platform
devices and initialize them for ARM SMMU components, the IORT
kernel implementation requires a set of static functions to be
used by the IORT kernel layer to configure platform devices for
ARM SMMU components.
Add static configuration f
IORT tables provide data that allow the kernel to carry out
device ID mappings between endpoints and system components
(eg interrupt controllers, IOMMUs). When the mapping for a
given device ID is carried out, the translation mechanism
is done on a per-subsystem basis rather than a component
subtyp
The current IORT id mapping API requires components to provide
an input requester ID (a Bus-Device-Function (BDF) identifier for
PCI devices) to translate an input identifier to an output
identifier through an IORT range mapping.
Named components do not have an identifiable source ID therefore
the
Current ARM SMMU v3 driver rely on the struct device.of_node pointer for
device look-up and iommu_ops retrieval.
In preparation for ACPI probing enablement, convert the driver to use
the struct device.fwnode member for device and iommu_ops look-up so that
the driver infrastructure can be used also
Current ARM SMMU probe functions intermingle HW and DT probing
in the initialization functions to detect and programme the ARM SMMU
driver features. In order to allow probing the ARM SMMU with other
firmwares than DT, this patch splits the ARM SMMU init functions into
DT and HW specific portions so
DT based systems have a generic kernel API to configure IOMMUs
for devices (ie of_iommu_configure()).
On ARM based ACPI systems, the of_iommu_configure() equivalent can
be implemented atop ACPI IORT kernel API, with the corresponding
functions to map device identifiers to IOMMUs and retrieve the
c
In ARM ACPI systems, IOMMU components are specified through static
IORT table entries. In order to create platform devices for the
corresponding ARM SMMU components, IORT kernel code should be made
able to parse IORT table entries and create platform devices
dynamically.
This patch adds the generi
On 2016-11-08 10:23:02 [+0100], Borislav Petkov wrote:
> On Mon, Nov 07, 2016 at 09:12:24PM +0100, Borislav Petkov wrote:
> > On Mon, Nov 07, 2016 at 10:55:24AM -0800, Luck, Tony wrote:
> > > I don't think that helps as much as you'd like it to help (at
> > > least on Intel). A broadcast machine ch
301 - 400 of 965 matches
Mail list logo
