On Mon, Feb 11, 2019 at 2:40 PM David Engraf wrote:
> On 11.02.19 at 12:40, Andy Shevchenko wrote:
> > On Mon, Feb 11, 2019 at 10:49 AM David Engraf
> > wrote:
> >> On 11.02.19 at 08:56, David Engraf wrote:
> >>> On 09.02.19 at 11:35, Andy Shevchenko wrote:
> On Sat, Feb 9, 2019 at 12:08
Hi
> -Original Message-
> From: Heikki Krogerus
> Sent: 2019年1月31日 0:03
> To: Greg Kroah-Hartman
> Cc: Andy Shevchenko ; Chen Yu
> ; Jun Li ; Hans de Goede
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH v2 0/9] device connection: Add support for device
Am Mittwoch, 6. Februar 2019, 02:47:33 CET schrieb Yizhuo:
> In function rockchip_emmc_phy_power(), local variable "caldone"
> could be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the later context, which
> is potentially unsafe.
>
>
Jianlin reported a panic when running sctp gso over gre over vlan device:
[ 84.772930] RIP: 0010:do_csum+0x6d/0x170
[ 84.790605] Call Trace:
[ 84.791054] csum_partial+0xd/0x20
[ 84.791657] gre_gso_segment+0x2c3/0x390
[ 84.792364] inet_gso_segment+0x161/0x3e0
[
The cpufreq core doesn't remove the cpufreq policy anymore on CPU
offline operation, rather that happens when the CPU device gets
unregistered from the kernel. This allows faster recovery when the CPU
comes back online. This is also very useful during system wide
suspend/resume where we offline
Am Mittwoch, 6. Februar 2019, 03:18:10 CET schrieb Yizhuo:
> In function rockchip_usb3_phy_power_on(), local variable
> "val" could be uninitialized if function regmap_read()
> returns -EINVAL. However, this value is directly used in
> later context. This is potentially unsafe.
While highly
In sctp_stream_init(), after sctp_stream_outq_migrate() freed the
surplus streams' ext, but sctp_stream_alloc_out() returns -ENOMEM,
stream->outcnt will not be set to 'outcnt'.
With the bigger value on stream->outcnt, when closing the assoc and
freeing its streams, the ext of those surplus
Hi Virendra,
On Mon, Feb 11, 2019 at 5:02 PM Virendra Kakade wrote:
>
> Document bindings for E31x device PMU MFD driver.
>
> Signed-off-by: Virendra Kakade
> ---
> Documentation/devicetree/bindings/mfd/e31x-pmu.txt | 14 ++
> 1 file changed, 14 insertions(+)
> create mode 100644
On 12/02/2019 10:37, Bartosz Golaszewski wrote:
> wt., 12 lut 2019 o 11:27 Marc Zyngier napisał(a):
>>
>> On 12/02/2019 09:19, Bartosz Golaszewski wrote:
>>> wt., 12 lut 2019 o 10:10 Marc Zyngier napisał(a):
On 29/01/2019 08:44, Bartosz Golaszewski wrote:
> From: Bartosz
On 2/12/19 1:48 AM, Anders Roxell wrote:
> With commit 876dd866c084 ("apparmor: Initial implementation of raw
> policy blob compression") and SECURITY_APPARMOR is set to '=y'
> ZLIB_DEFLATE must be enabled as well for the linker to see the symbols.
>
> aarch64-linux-gnu-ld:
On Tue, Feb 12, 2019 at 06:29:39PM +0800, Kyle Tso wrote:
> On Thu, Jan 31, 2019 at 3:02 PM Greg KH wrote:
>
> > On Thu, Jan 31, 2019 at 11:54:11AM +0800, Kyle Tso wrote:
> > > Provide a function to get the partner Source Capabilities.
> > >
> > > Signed-off-by: Kyle Tso
> > > ---
> > >
On Tue, Feb 12, 2019 at 11:47 AM Viresh Kumar wrote:
>
[cut]
> @@ -2488,7 +2505,8 @@ int cpufreq_register_driver(struct cpufreq_driver
> *driver_data)
> driver_data->target) ||
> (driver_data->setpolicy && (driver_data->target_index ||
>
Hi Matthias,
On 2/11/19 9:54 PM, Matthias Kaehlcke wrote:
> Hi Lukasz,
>
> On Mon, Feb 11, 2019 at 11:05:27AM +0100, Lukasz Luba wrote:
>> Hi Matthias,
>>
>> My apologize for late response, I did not have access to mailbox.
>> Thank you for review, please check the comments below.
>>
>> On
On Tue, 12 Feb 2019 at 11:23, Andy Shevchenko wrote:
>
> On Tue, Feb 12, 2019 at 12:21 PM Andy Shevchenko
> wrote:
> >
> > On Tue, Feb 12, 2019 at 12:15 PM Anders Roxell
> > wrote:
> > >
> > > Commit a893ea15d764 ("tpm: move tpm_chip definition to
> > > include/linux/tpm.h") introduced a build
Hi Nava,
a couple of nits inline. otherwise looks fine to me.
On Sun, Feb 10, 2019 at 8:17 AM Nava kishore Manne
wrote:
>
> Add documentation to describe Xilinx ZynqMP fpga driver
> bindings.
>
> Signed-off-by: Nava kishore Manne
> ---
> Changes for v3:
> -Created patches on
Hi Matthias,
On 2/11/19 10:36 PM, Matthias Kaehlcke wrote:
> Hi Lukasz,
>
> On Mon, Feb 11, 2019 at 04:30:05PM +0100, Lukasz Luba wrote:
>> This patch changes deferred work to delayed work, which is now not missed
>> when timer is put on CPU that entered idle state.
>> The devfreq framework
On Tue, Feb 12, 2019 at 10:27:54AM +, Marc Zyngier wrote:
> On 12/02/2019 09:19, Bartosz Golaszewski wrote:
> > When userspace wants to monitor GPIO line interrupts, the GPIO
> > framework requests a threaded interrupt with IRQF_TRIGGER_FALLING,
> > IRQF_TRIGGER_RISING or both. The testing
On Tue, Feb 12, 2019 at 11:27:19AM +0100, Jiri Slaby wrote:
> Yes, they do not end up in the symbol table. But the macros make clear
> where is the start of the function and especially where is the end
> (something like closing bracket '}' in C). If you prefer not annotating
> local symbols, I can
On Tue, 29 Jan 2019 at 06:50, Sumit Garg wrote:
>
> This series introduces a generic TEE bus driver concept for TEE based
> kernel drivers which would like to communicate with TEE based devices/
> services.
>
> Patch #1 adds TEE bus concept where devices/services are identified via
> Universally
The cpufreq core doesn't remove the cpufreq policy anymore on CPU
offline operation, rather that happens when the CPU device gets
unregistered from the kernel. This allows faster recovery when the CPU
comes back online. This is also very useful during system wide
suspend/resume where we offline
Hi Nava,
On Sun, Feb 10, 2019 at 8:17 AM Nava kishore Manne
wrote:
>
> This patch adds FPGA Manager support for the Xilinx
> ZynqMP chip.
>
> Signed-off-by: Nava kishore Manne
> ---
> Changes for v3:
> -Created patches on top of 5.0-rc5.
> No functional changes.
fix similar issue for aarch64 as the commit 7c64cc0531fa
("arm: Use _rcuidle for smp_cross_call() tracepoints") fixed
in aarch32
Signed-off-by: Mars Cheng
---
arch/arm64/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c
wt., 12 lut 2019 o 12:05 Uwe Kleine-König
napisał(a):
>
> On Tue, Feb 12, 2019 at 10:27:54AM +, Marc Zyngier wrote:
> > On 12/02/2019 09:19, Bartosz Golaszewski wrote:
> > > When userspace wants to monitor GPIO line interrupts, the GPIO
> > > framework requests a threaded interrupt with
In non-smp configuration, hartid can be higher that NR_CPUS.
riscv_of_processor_hartid should not be compared to hartid to NR_CPUS in
that case. Moreover, this function checks all the DT properties of a
hart node. NR_CPUS comparison seems out of place.
Signed-off-by: Atish Patra
Reviewed-by:
Currently, we set hwcap based on first valid hart from DT. This may not
be correct always as that hart might not be current booting cpu or may
have a different capability.
Set hwcap as the capabilities supported by all possible harts with "okay"
status.
Signed-off-by: Atish Patra
---
It is perfectly okay to call riscv_hartid_to_cpuid for a hartid that is
not mapped with an CPU id. It can happen if the calling functions
retrieves the hartid from DT. However, that hartid was never brought
online by the firmware or kernel for any reasons.
No need to BUG() in the above case. A
In SMP path, __cpu_up waits for other CPU to come online indefinitely.
This is wrong as other CPU might be disabled in machine mode and
possible CPU is set to the cpus present in DT.
Introduce a completion variable and waits only for a second.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Currently, clocksource registration happens for an invalid cpu for
non-smp kernels. This lead to kernel panic as cpu hotplug registration
will fail for those cpus. Moreover, riscv_hartid_to_cpuid can return
errors now.
Do not proceed if hartid or cpuid is invalid. Take this opprtunity to
print
Currently, logical CPU id to physical hartid mapping is defined for both
smp and non-smp configurations. This is not required as we need this
only for smp configuration. The mapping function can define directly
boot_cpu_hartid for non-smp use case.
The reverse mapping function i.e. hartid to
We should never have a cpuid greater that NR_CPUS. Compare with NR_CPUS
before creating the mapping between logical and physical CPU ids. This
is also mandatory as NR_CPUS check is removed from
riscv_of_processor_hartid.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Christoph
The existing upstream kernel doesn't boot for non-smp configuration.
This patch series address various issues with non-smp configurations.
The patch series is based on 5.0-rc5 + Johan's below mentioned patch
series. Tested on both QEMU and HiFive Unleashed board using both
OpenSBI & BBL.
riscv_hartid_to_cpuid can return invalid cpuid for a hart that is
present in DT but was never brought up.
Print the appropriate warning message and continue.
Signed-off-by: Atish Patra
Reviewed-by: Anup Patel
Reviewed-by: Christoph Hellwig
---
drivers/irqchip/irq-sifive-plic.c | 5 +
1
Hi,
Am Montag, 4. Februar 2019, 13:59:37 CET schrieb Katsuhiro Suzuki:
> On 2019/02/03 18:06, Heiko Stuebner wrote:
> > Am Samstag, 2. Februar 2019, 05:34:44 CET schrieb Katsuhiro Suzuki:
> >> This patch adds HDMI sound (I2S0) node and remove dma properties
> >> from UART2 node for rock64.
> >>
On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
> wt., 12 lut 2019 o 11:18 Lee Jones napisał(a):
> >
> > On Tue, 12 Feb 2019, Bartosz Golaszewski wrote:
> >
> > > wt., 12 lut 2019 o 10:55 Lee Jones napisał(a):
> > > >
> > > > * The declaration of a superfluous struct
> > > > * 100 lines of
On Mon 11-02-19 15:33:38, Miklos Szeredi wrote:
> On Mon, Feb 11, 2019 at 2:08 PM Amir Goldstein wrote:
> >
> > On Mon, Feb 11, 2019 at 2:37 PM Miklos Szeredi wrote:
> > >
> > > On Mon, Feb 11, 2019 at 1:06 PM Miklos Szeredi wrote:
> > > >
> > > > On Mon, Feb 11, 2019 at 8:38 AM Amir Goldstein
Hi Thomas,
On Mon, Feb 11, 2019 at 11:38:07PM +0100, Thomas Gleixner wrote:
> Ming,
>
> On Mon, 11 Feb 2019, Bjorn Helgaas wrote:
>
> > On Mon, Feb 11, 2019 at 11:54:00AM +0800, Ming Lei wrote:
> > > On Sun, Feb 10, 2019 at 05:30:41PM +0100, Thomas Gleixner wrote:
> > > > On Fri, 25 Jan 2019,
On Tue, 12 Feb 2019, Li, Aubrey wrote:
> On 2019/2/12 16:22, Thomas Gleixner wrote:
> > On Tue, 12 Feb 2019, Aubrey Li wrote:
> >> diff --git a/arch/x86/include/asm/processor.h
> >> b/arch/x86/include/asm/processor.h
> >> index d53c54b842da..60ee932070fe 100644
> >> ---
Am Dienstag, 12. Februar 2019, 16:20:11 schrieb Guoqing Jiang:
> On 2/11/19 11:12 PM, Wolfgang Walter wrote:
> > With 4.19.19 we see sometimes the following issue (practically only with
> > blk_mq, though):
> >
> > Feb 4 20:04:46 tettnang kernel: [252300.060165] INFO: task md0_raid1:317
> >
Hi Matthias,
On 2/11/19 10:42 PM, Matthias Kaehlcke wrote:
> Hi Lukasz,
>
> On Mon, Feb 11, 2019 at 04:30:04PM +0100, Lukasz Luba wrote:
>> There is no need for creating another workqueue in the system,
>> the existing one should meet the requirements.
>> This patch removes devfreq's custom
Commit a893ea15d764 ("tpm: move tpm_chip definition to
include/linux/tpm.h") introduced a build error when both ima and efi is
enabled. What happens is that both headers (ima.h and efi.h) defines the
same 'NONE' constant, and it broke when they started getting included
from the same file.
In file
Commit a893ea15d764 ("tpm: move tpm_chip definition to
include/linux/tpm.h") introduced a build error when both ima and efi is
enabled. What happens is that both headers (ima.h and efi.h) defines the
same 'NONE' constant, and it broke when they started getting included
from the same file.
In file
From: Colin Ian King
The null check on an allocation failure on pd is currently checking
if pd is non-null rather than null. Fix this by adding the missing !
operator.
Fixes: 21a428a019c9 ("RDMA: Handle PD allocations by IB/core")
Signed-off-by: Colin Ian King
---
This patchset support goodix GT5553 CTP.
Changes for v4:
- devm_add_action_or_reset for disabling regulator
Changes for v3:
- add cover-letter
- s/ADVV28/AVDD28 on commit head
- fix few typo
Changes for v2:
- Rename vcc-supply with AVDD28-supply
- disable regulator in remove
- fix to setup
Most of the Goodix CTP controllers are supply with AVDD28 pin.
which need to supply for controllers like GT5663 on some boards
to trigger the power.
So, document the supply property so-that the require boards
that used on GT5663 can enable it via device tree.
Signed-off-by: Jagan Teki
---
Hi,
On Tue, Feb 12, 2019 at 10:41:28AM +, Jun Li wrote:
> > @@ -32,6 +32,7 @@ typedef enum usb_role (*usb_role_switch_get_t)(struct
> > device *dev);
> > * usb_role_switch_register() before registering the switch.
> > */
> > struct usb_role_switch_desc {
> > + struct fwnode_handle
Goodix CTP controllers have AVDD28 pin connected to voltage
regulator which may not be turned on by default, like for GT5663.
Add support for such ctp used boards by adding voltage regulator
handling code to goodix ctp driver.
Signed-off-by: Jagan Teki
---
drivers/input/touchscreen/goodix.c |
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki
---
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum
On Tue, Feb 12, 2019 at 03:10:12AM -0800, Atish Patra wrote:
> Currently, we set hwcap based on first valid hart from DT. This may not
> be correct always as that hart might not be current booting cpu or may
> have a different capability.
>
> Set hwcap as the capabilities supported by all
On Tue, 12 Feb 2019, Li, Aubrey wrote:
> $ find . -name *.h | xargs grep arch_irq_stat
> ./arch/arm64/include/asm/hardirq.h:#define arch_irq_stat_cpu smp_irq_stat_cpu
> ./arch/arm/include/asm/hardirq.h:#define arch_irq_stat_cpusmp_irq_stat_cpu
> ./arch/x86/include/asm/hardirq.h:extern u64
Add vendor prefix for techstar, known as
Shenzhen Techstar Electronics Co., Ltd. a known producer for LCD modules.
Signed-off-by: Jagan Teki
---
Changes for v2:
- rebase for master
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
On Tue, Feb 12, 2019 at 11:22:33AM +, Colin King wrote:
> From: Colin Ian King
>
> The null check on an allocation failure on pd is currently checking
> if pd is non-null rather than null. Fix this by adding the missing !
> operator.
>
> Fixes: 21a428a019c9 ("RDMA: Handle PD allocations by
On Tue, Feb 12, 2019 at 10:44:35AM +, Jun Li wrote:
> Hi
> > -Original Message-
> > From: Heikki Krogerus
> > Sent: 2019年1月31日 0:03
> > To: Greg Kroah-Hartman
> > Cc: Andy Shevchenko ; Chen Yu
> > ; Jun Li ; Hans de Goede
> > ; linux-...@vger.kernel.org;
> >
SOCK_DEBUG is a very ancient debugging interface, and it's not very useful
for debugging.
This pacthset cleanups SOCK_DEBUG() and replace it with a new methord
based on BPF.
I cleanup SOCK_DEBUG() only for TCP, and other protocols are kept as is.
After this patchset, the SO_DEBUG interface will
Introuce this new op BPF_SOCK_OPS_STATS_CB for tcp_stats() such that it
can be traced via BPF on a per socket basis.
There's one argument in BPF_SOCK_OPS_STATS_CB, which is Linux MIB index
LINUX_MIB_* to indicate the TCP event.
All these Linux MIBs are defined in include/uapi/linux/snmp.h.
SOCK_DEBUG is a very ancient debugging interface, and it's not very useful
for debugging.
So this patch removes the SOCK_DEBUG() and introduce a new function
tcp_stats() to trace this kind of events.
Some MIBs are added for these events.
Regarding the SO_DEBUG in sock_{s,g}etsockopt, I think it
On Tue, Feb 12, 2019 at 09:54:54AM +0100, Lucas Stach wrote:
> Hi Bjorn,
>
> Am Montag, den 11.02.2019, 15:39 -0600 schrieb Bjorn Helgaas:
> > On Wed, Feb 06, 2019 at 10:57:32AM +0100, Stefan Agner wrote:
> > > Define the length of the DBI registers. This makes sure that
> > > the kernel does not
Hi Steve,
On Mon, 2019-02-11 at 17:20 -0800, Steve Longerbeam wrote:
[...]
> > Should we support YUV BT.601 <-> YUV REC.709 conversions? That would
> > require separate encodings for input and output.
>
> How about if we pass the input and output encodings to the init ic task
> functions, but
On 12/02/2019 11:05, Uwe Kleine-König wrote:
> On Tue, Feb 12, 2019 at 10:27:54AM +, Marc Zyngier wrote:
>> On 12/02/2019 09:19, Bartosz Golaszewski wrote:
>>> When userspace wants to monitor GPIO line interrupts, the GPIO
>>> framework requests a threaded interrupt with IRQF_TRIGGER_FALLING,
On 12. 02. 19, 12:05, Borislav Petkov wrote:
> On Tue, Feb 12, 2019 at 11:27:19AM +0100, Jiri Slaby wrote:
>> Yes, they do not end up in the symbol table. But the macros make clear
>> where is the start of the function and especially where is the end
>> (something like closing bracket '}' in C).
Add missing dt-binding documentation for lm75 hwmon sensor.
Signed-off-by: Jagan Teki
---
Changes for v2:
- Add all compatible nodes available in lm75.
.../devicetree/bindings/hwmon/lm75.txt| 37 +++
1 file changed, 37 insertions(+)
create mode 100644
Le 12/02/2019 à 02:08, Daniel Axtens a écrit :
Andrey Ryabinin writes:
On 2/11/19 3:25 PM, Andrey Konovalov wrote:
On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
wrote:
Hi Andrey,
Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy
From: Andress Kuo
If fmt on event_trace_printk is not a constant, It means that something not
guaranteed, so the compiler optimizes the fmt out, and then the
__trace_printk_fmt section is not filled. if __trace_printk_fmt is not
filled, the kernel will not allocate the special buffers needed for
On Tue, Feb 12, 2019 at 12:38:09PM +0100, Jiri Slaby wrote:
> OK, so I will switch all the *LOCAL* to .L prefix (perhaps as a separate
> patch prior the series/post the series)?
Sure.
I have been doing that off and on but apparently this undertaking
resembles the whack-a-mole game. :-)
Thx.
--
On 2019/2/12 19:19, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Li, Aubrey wrote:
>> On 2019/2/12 16:22, Thomas Gleixner wrote:
>>> On Tue, 12 Feb 2019, Aubrey Li wrote:
diff --git a/arch/x86/include/asm/processor.h
b/arch/x86/include/asm/processor.h
index
On 12. 02. 19, 12:46, Borislav Petkov wrote:
> On Tue, Feb 12, 2019 at 12:38:09PM +0100, Jiri Slaby wrote:
>> OK, so I will switch all the *LOCAL* to .L prefix (perhaps as a separate
>> patch prior the series/post the series)?
>
> Sure.
>
> I have been doing that off and on but apparently this
On 2019/2/12 19:27, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Li, Aubrey wrote:
>> $ find . -name *.h | xargs grep arch_irq_stat
>> ./arch/arm64/include/asm/hardirq.h:#define arch_irq_stat_cpu smp_irq_stat_cpu
>> ./arch/arm/include/asm/hardirq.h:#define arch_irq_stat_cpu smp_irq_stat_cpu
>>
Add vendor prefix for feiyang, known as
Shenzhen Fly Young Technology Co.,LTD. a known producer for LCD modules.
Signed-off-by: Jagan Teki
---
Note: notation about using 'feiyang' is based on the datasheet
http://files.pine64.org/doc/datasheet/pine64/FY07024DI26A30-D_feiyang_LCD_panel.pdf
Hi!
> diff --git
> a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> new file mode 100644
> index ..f3e00d41e299
> --- /dev/null
> +++
On Mon, Feb 11, 2019 at 6:45 PM Will Deacon wrote:
>
> The inX() I/O accessors must enforce ordering against subsequent calls
> to the delay() routines, so that a read-back from a device can be used
> to postpone a subsequent write to the same device.
>
> On some architectures, including arm64,
On Tue, 12 Feb 2019, Li, Aubrey wrote:
> On 2019/2/12 19:19, Thomas Gleixner wrote:
> > On Tue, 12 Feb 2019, Li, Aubrey wrote:
> >> On 2019/2/12 16:22, Thomas Gleixner wrote:
> >>> On Tue, 12 Feb 2019, Aubrey Li wrote:
> diff --git a/arch/x86/include/asm/processor.h
>
On Tue, 29 Jan 2019, Thomas Gleixner wrote:
> On Tue, 29 Jan 2019, Jan H. Schönherr wrote:
>
> > Am 29.01.2019 um 11:23 schrieb Jan H. Schönherr:
> > > +calibrate:
> > > + /*
> > > + * Extrapolate the error and fail fast if the error will
> > > + * never be below 500 ppm.
> > > + */
> > > + if
Tim,
On Wed, 30 Jan 2019, Thomas Gleixner wrote:
> Also please follow the L1TF documentation which explains for each of the
> mitigation modes which kind of attacks are prevented and which holes
> remain.
>
> It's a good start but far from where it should be.
what's the state of this?
Thanks,
On Fri 2019-02-01 10:47:31, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add the core mfd driver for max77650 PMIC. We define five sub-devices
> for which the drivers will be added in subsequent patches.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/mfd/Kconfig
On 2/12/19 4:08 AM, Daniel Axtens wrote:
> Andrey Ryabinin writes:
>
>> On 2/11/19 3:25 PM, Andrey Konovalov wrote:
>>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
>>> wrote:
Hi Andrey,
Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
> On Fri, Feb 8, 2019 at
On 2019/2/12 19:55, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Li, Aubrey wrote:
>> On 2019/2/12 19:19, Thomas Gleixner wrote:
>>> On Tue, 12 Feb 2019, Li, Aubrey wrote:
On 2019/2/12 16:22, Thomas Gleixner wrote:
> On Tue, 12 Feb 2019, Aubrey Li wrote:
>> diff --git
On Fri 08-02-19 01:04:37, Yu Zhao wrote:
> Declaration of struct node is required regardless. On UMA system,
> including compaction.h without proceeding node.h shouldn't cause
> build error.
Anybody requiring struct node shouldn't depend on compaction.h to get
the declaration. Anyway have you
On Tue, Feb 12, 2019 at 12:39 PM Christoph Hellwig wrote:
>
> On Sat, Jan 19, 2019 at 11:26:22AM +0530, Anup Patel wrote:
> > The plic_toggle() uses raw_spin_lock() and plic_irq_toggle has a
> > for loop so both these functions are not suitable for being inline
> > hence this patch removes the
Hi Chanwoo
On 2/12/19 6:46 AM, Chanwoo Choi wrote:
> Hi Lukasz,
>
> On 19. 2. 12. 오전 12:30, Lukasz Luba wrote:
>> This patch set changes workqueue related features in devfreq framework.
>> First patch switches to delayed work instead of deferred.
>> The second switches to regular system work and
Hi!
> +#define MAX77650_CHARGER_ENABLED BIT(0)
> +#define MAX77650_CHARGER_DISABLED0x00
> +#define MAX77650_CHARGER_CHG_EN_MASK BIT(0)
> +
> +#define MAX77650_CHARGER_CHG_DTLS_MASK GENMASK(7, 4)
> +#define MAX77650_CHARGER_CHG_DTLS_BITS(_reg) \
> +
On Fri 2019-02-01 10:47:32, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add basic support for the battery charger for max77650 PMIC.
>
> diff --git a/drivers/power/supply/max77650-charger.c
> b/drivers/power/supply/max77650-charger.c
> new file mode 100644
> index
The architecture specific information of the running processes could
be useful to the userland. Add support to examine process architecture
specific information externally.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
AVX-512 components use could cause core turbo frequency drop. So
it's useful to expose AVX-512 usage elapsed time as a heuristic hint
for the user space job scheduler to cluster the AVX-512 using tasks
together.
Example:
$ cat /proc/pid/status | grep AVX512_elapsed_ms
AVX512_elapsed_ms: 1020
Added AVX512_elapsed_ms in /proc//status. Report it
in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
Documentation/filesystems/proc.txt | 4 +++-
1 file changed, 3 insertions(+), 1
On Tue, 12 Feb 2019 at 16:35, Ard Biesheuvel wrote:
>
> On Tue, 29 Jan 2019 at 06:50, Sumit Garg wrote:
> >
> > This series introduces a generic TEE bus driver concept for TEE based
> > kernel drivers which would like to communicate with TEE based devices/
> > services.
> >
> > Patch #1 adds TEE
Hi!
> >> +static struct max77650_led *max77650_to_led(struct led_classdev *cdev)
> >> +{
> >> + return container_of(cdev, struct max77650_led, cdev);
> >> +}
> >> +
> >> +static int max77650_led_brightness_set(struct led_classdev *cdev,
> >> + enum led_brightness
On Tue, 12 Feb 2019 at 13:09, Sumit Garg wrote:
>
> On Tue, 12 Feb 2019 at 16:35, Ard Biesheuvel
> wrote:
> >
> > On Tue, 29 Jan 2019 at 06:50, Sumit Garg wrote:
> > >
> > > This series introduces a generic TEE bus driver concept for TEE based
> > > kernel drivers which would like to
From: Rafael J. Wysocki
Commit 4080ab083000 ("PM-runtime: Take suppliers into account in
__pm_runtime_set_status()") introduced a race condition that may
trigger if __pm_runtime_set_status() is used incorrectly (that is,
if it is called when PM-runtime is enabled for the target device
and
From: Anson Huang
Add i.MX8MQ cpu OPP table info for cpu-freq driver.
Signed-off-by: Anson Huang
Signed-off-by: Abel Vesa
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
From: Rafael J. Wysocki
If a stateless device link to a certain supplier with
DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the
consumer driver's probe callback, the supplier's PM-runtime usage
counter will be nonzero after that which effectively causes the
supplier to remain
Hi Greg at al,
These fix two issues on top of the recent device links material in
driver-core/driver-core-next.
The first one fixes a race condition that may trigger when
__pm_runtime_set_status() is used incorrectly (that is, when it is
called with PM-runtime enabled for the target device and
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index a72f97fca57b..6e7a8f51eccc 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -608,6 +608,12 @@ config LEDS_TLC591XX
> This option enables support for Texas Instruments TLC59108
> and TLC59116
On Thu, Feb 07, 2019 at 08:36:32PM +, Dexuan Cui wrote:
>
> When we unload pci-hyperv, the host doesn't send us a PCI_EJECT message.
> In this case we also need to make sure the sysfs pci slot directory
> is removed, otherwise "cat /sys/bus/pci/slots/2/address" will trigger
> "BUG: unable to
On 12.02.19 at 11:43, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 2:40 PM David Engraf wrote:
On 11.02.19 at 12:40, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 10:49 AM David Engraf wrote:
On 11.02.19 at 08:56, David Engraf wrote:
On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat,
On Tue, Feb 12, 2019 at 12:51:08PM +0100, Jiri Slaby wrote:
> And what if the LOCAL macros prepend .L automatically? The references
> would need to be via macro or by manually adding .L. I mean:
>
> SYM_CODE_START_LOCAL(function)
> ret
> SYM_CODE_END(function)
>
> And then used as:
> call
On 2/12/19 2:38 PM, Christophe Leroy wrote:
>
>
> Le 12/02/2019 à 02:08, Daniel Axtens a écrit :
>> Andrey Ryabinin writes:
>>
>>>
>>> Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g.
>>> x86_64) or
>>> in Makefile (e.g. arm64). And make early mapping writable, because
Hi Abel,
On Tue, Feb 12, 2019 at 10:13 AM Abel Vesa wrote:
>
> From: Anson Huang
>
> Add i.MX8MQ cpu OPP table info for cpu-freq driver.
Has the imx8m cpufreq driver already been submitted?
On Mon, Feb 11, 2019 at 01:17:47PM -0800, Florian Fainelli wrote:
> There is no code that will query the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
> attribute remove support for that.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Ido Schimmel
Hi!
> + error = device_property_read_string(dev,
> + "maxim,onkey-mode", _prop);
> + if (error)
> + mode_prop = "push";
> +
> + if (strcmp(mode_prop, "push") == 0)
> + mode = MAX77650_ONKEY_MODE_PUSH;
> + else if
On Mon, Feb 11, 2019 at 11:09:53AM -0800, Florian Fainelli wrote:
> Update the section about switchdev drivers having to implement a
> switchdev_port_attr_get() function to return
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
> commit bccb30254a4a ("net: Get rid of
>
201 - 300 of 1653 matches
Mail list logo
