From: Bartosz Golaszewski
We now have a proper clocksource driver for davinci. Switch the platform
to using it.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/dm365.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach
From: Bartosz Golaszewski
Switch all davinci boards using device tree to using the new
clocksource driver: remove the previous OF_TIMER_DECLARE() from
mach-davinci and select davinci-timer to be built for
davinci_all_defconfig.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/Kconfig
From: Bartosz Golaszewski
All platforms have now been switched to the new clocksource driver.
Remove the old code and various no longer needed bits and pieces.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/Makefile | 3 +-
arch/arm/mach-davinci/devices-da8xx.c
From: Bartosz Golaszewski
This series removes the legacy timer code from mach-davinci in favor of
a new clocksource driver it introduces.
The first patch fixes a device tree bug that's been around for a while.
Unfortunately any systems shipped with the buggy device will stop booting
once they sw
On 2/1/19 12:20 PM, Sean Christopherson wrote:
> On Fri, Feb 01, 2019 at 04:47:12PM +, Singh, Brijesh wrote:
>> svm.c is pretty huge, before we add more SEV specific commands (e.g SEV-ES,
>> SEV-Migration etc) lets move the SEV command handling into a separate file.
>> There is no logical cha
Frankly I still think this does not solve anything.
Concurrent write access from two sources to a single page is simply wrong.
You cannot make this right by allowing long term RDMA pins in a filesystem
and thus the filesystem can never update part of its files on disk.
Can we just disable RDMA to
From: Andrew Lunn
Date: Mon, 4 Feb 2019 15:58:54 +0100
> On Fri, Feb 01, 2019 at 06:50:48PM -0800, Moritz Fischer wrote:
>> Make MDIO child optional and only instantiate the
>> MDIO bus if the child is actually present.
>>
>> There are currently no (in-tree) users of this
>> binding; all (out-of
From: Kalle Valo
Date: Mon, 04 Feb 2019 15:58:08 +0200
> here are fixes to net tree for 5.0, more info below. Please let me know
> if there are any problems.
Pulled, thanks Kalle.
> + * field) in order to make sure that the reminding memory accesses will
remaining
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
A helper already exists for nearly every combination of parameters,
except of course the one that I now need.
Signed-off-by: Robin Murphy
---
include/linux/cpuhotplug.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index fd586d0
Like other system PMUs which associate themselves with an arbitrary CPU
for housekeeping purposes, arm_dsu has a race between registering the
hotplug notifier and registering the PMU device, such that the hotplug
niotifier can potentially fire and attempt to migrate the PMU context
before the latte
This is the only member of the family not exported already, but
happens to be the one I need to fix a bug in a modular driver.
Signed-off-by: Robin Murphy
---
kernel/cpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 91d5c38eb7e5..c1bd8ed7546e 100644
---
The arm-cci probe logic faces a cyclic dependency wherein it has to pick
a valid CPU to associate with before registering the PMU device, has to
have the PMU state initialised before handling hotplug events in case it
must be migrated, but has to have the hotplug notifier registered before
the chos
Like arm-cci, arm-ccn has the same issue where disabling preemption to
avoid races between registering the PMU device and the hotplug notifier
can lead to those operations taking mutexes in an invalid context. Fix
it the same way by disabling hotplug instead of preemption. Since we
only ever associ
Hi all,
Following the report of a preemption-related bug in arm-cci, it turns
out there's a fair bit of cleaning up to do in this area. I've started
here with the Arm drivers that I'm fairly familiar with - I suspect the
hisi/qcom/xgene ones suffer from similar issues, but it's going to take
me a
https://gitlab.com/MikeeUSA/GPC-Slots-2/
Is gone after a successful DMCA take-down by the Author (MikeeUSA).
Backstory: Author (MikeeUSA) revokes license from "JohnDoe".
"JohnDoe" defies revocation and uploads the work to gitlab.
"JohnDoe" modifies work to "remove sexism".
MikeeUSA issues a DMCA
On 02/02, Chao Yu wrote:
> On 2019-1-29 7:47, Jaegeuk Kim wrote:
> > After quota_off, we'll get some dirty blocks. If put_super don't have a
> > chance
> > to flush them by checkpoint, it causes NULL pointer exception in end_io
> > after
> > iput(node_inode). (e.g., by checkpoint=disable)
> >
>
On Mon, Feb 04, 2019 at 05:42:13PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Read MAC address 32-bit at a time and manually extract the individual
> bytes. This avoids pointer aliasing and gives the compiler a better
> chance of optimizing the operation.
>
> Suggested-by: Andrew Lu
On Mon, 4 Feb 2019, Christoph Hellwig wrote:
> On Mon, Feb 04, 2019 at 04:08:02PM +, Christopher Lameter wrote:
> > It may be worth noting a couple of times in this text that this was
> > designed for anonymous memory and that such use is/was ok. We are talking
> > about a use case here using
On 02/01, Chao Yu wrote:
> On 2019-1-29 7:47, Jaegeuk Kim wrote:
> > This mode returns mount() quickly with EAGAIN. We can trigger this by
> > shutdown(F2FS_GOING_DOWN_NEED_FSCK).
>
> Is the purpose of this patch making mount failed more quickly due to giving
> less
> GC time in f2fs_disable_chec
On 2/4/2019 11:23 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+ INTEL_CPU_DE
On Thu, Jan 31, 2019 at 06:23:37PM +, Valentin Schneider wrote:
> Since the enabling and disabling of IRQs within preempt_schedule_irq()
> is contained in a need_resched() loop, we don't need the outer arch
> code loop.
>
> Reported-by: Julien Thierry
> Reported-by: Will Deacon
> Signed-off-
Lorenzo,
My apologies again,
I have started looking into these.
Thanks,
On Mon, Feb 4, 2019 at 9:43 PM Lorenzo Pieralisi
wrote:
>
> On Mon, Feb 04, 2019 at 07:44:25PM +0530, Subrahmanya Lingappa wrote:
> >Bjorn,
> >My apologies, I was away for a while from this work.
> >I am star
On Sat, Feb 02, 2019 at 04:25:02PM +, Nicholas Johnson wrote:
> New systems with Thunderbolt are starting to use native PCI enumeration.
To clarify, I assume "native PCI enumeration" means platform firmware
is not involved in hotplug, which means we would use pciehp (not
acpiphp) for these Thu
From: Thierry Reding
Read MAC address 32-bit at a time and manually extract the individual
bytes. This avoids pointer aliasing and gives the compiler a better
chance of optimizing the operation.
Suggested-by: Andrew Lunn
Signed-off-by: Thierry Reding
---
Applies to net-next.
I tested this on
On Mon, Feb 04, 2019 at 03:14:27PM +, Ghannam, Yazen wrote:
> Yes, you're right. But it seems that the next pr_* that's not a pr_cont will
> be on
> a newline automatically.
Ah, that must be that printk continuation fun around
4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continu
On Mon, Feb 4, 2019 at 9:25 AM Greg Kroah-Hartman
wrote:
>
> On Mon, Feb 04, 2019 at 11:10:39AM +0100, Marc Gonzalez wrote:
> > + GKH
> >
> > On 01/02/2019 17:23, Marc Gonzalez wrote:
> >
> > > On 23/01/2019 13:31, Mike Rapoport wrote:
> > >
> > >> Signed-off-by: Mike Rapoport
> > >> Tested-by: M
Hello,
syzbot found the following crash on:
HEAD commit:dc4c89997735 Add linux-next specific files for 20190201
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=120a50b0c0
kernel config: https://syzkaller.appspot.com/x/.config?x=59aefae07c771af6
dashb
Brian Norris wrote:
> This reverts commit cfb353c0dc058bc1619cc226d3cbbda1f360bdd3.
>
> WCN3990 firmware does not yet implement this feature, and so it crashes
> like this:
>
> fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN
> RT:207a:PC=b001b4f0
>
> This feature can be re-implem
From: Thierry Reding
If the system was booted using a device tree and if the device tree
contains a MAC address, use it instead of reading one from the EEPROM.
This is useful in situations where the EEPROM isn't properly programmed
or where the firmware wants to override the existing MAC address.
On Mon, Feb 04, 2019 at 11:23:13AM -0500, Liang, Kan wrote:
> I mean that the microcode version number is irrelevant between stepping.
> Let's use SKL server as an example.
> + INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 3, 0x0021),
> + INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X,
On Mon, Jan 14, 2019 at 06:54:00PM +0530, Kishon Vijay Abraham I wrote:
> Add PCIe RC support for TI's AM654 SoC. The PCIe controller in AM654
> uses Synopsys core revision 4.90a and uses the same TI wrapper as used
> in keystone2 with certain modification. Hence AM654 will use the same
> pci wrapp
* Roger Quadros [190204 14:23]:
> From: "Andrew F. Davis"
>
> The Programmable Real-Time Unit Subsystem (PRUSS) contains an
> interrupt controller (INTC) that can handle various system input
> events and post interrupts back to the device-level initiators.
> The INTC can support upto 64 input ev
* Andrew F. Davis [190204 14:52]:
> On 2/4/19 8:22 AM, Roger Quadros wrote:
> > From: Suman Anna
> > +++ b/drivers/soc/ti/Kconfig
> > @@ -73,4 +73,16 @@ config TI_SCI_PM_DOMAINS
> > called ti_sci_pm_domains. Note this is needed early in boot before
> > rootfs may be available.
> >
>
On Mon, Feb 04, 2019 at 03:58:54PM +0100, Andrew Lunn wrote:
> On Fri, Feb 01, 2019 at 06:50:48PM -0800, Moritz Fischer wrote:
> > Make MDIO child optional and only instantiate the
> > MDIO bus if the child is actually present.
> >
> > There are currently no (in-tree) users of this
> > binding; al
Hi,
* Roger Quadros [190204 14:23]:
> From: Suman Anna
...
> +Example:
> +
> +1. /* AM33xx PRU-ICSS */
> +
> + pruss: pruss@0 {
> + compatible = "ti,am3356-pruss";
> + reg = <0x0 0x2000>,
> + <0x2000 0x2000>,
> + <0x1
Hello,
syzbot found the following crash on:
HEAD commit:dc4c89997735 Add linux-next specific files for 20190201
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17eb3dc4c0
kernel config: https://syzkaller.appspot.com/x/.config?x=59aefae07c771af6
dashb
Update accounting_timestamp field only when PM runtime is enable
and don't forget to account the last state before disabling it.
Suggested-by: Ulf Hansson
Signed-off-by: Vincent Guittot
---
drivers/base/power/runtime.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
d
On 2/4/2019 11:04 AM, Borislav Petkov wrote:
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+ INTEL_CPU_D
From: Kimberly Brown Sent: Sunday, February 3, 2019
11:13 PM
>
> Counter values for per-channel interrupts and ring buffer full
> conditions are useful for investigating performance.
>
> Expose counters in sysfs for 2 types of guest to host interrupts:
> 1) Interrupts caused by the channel's ou
Similarly to what happened whith autosuspend, a deadlock has been raised
with runtime accounting in the sequence:
change_clocksource
...
write_seqcount_begin
...
timekeeping_update
...
sh_cmt_clocksource_enable
...
rpm_resume
On Mon, Jan 28, 2019 at 01:57:17PM +0800, Icenowy Zheng wrote:
> The CP2104 chips feature 4 controllable GPIO pins, which are similar to
> the ones on CP2102N chip (output-only when push-pull, output or
> simulated input mode when open-drain).
>
> Add support for the GPIO pins for cp210x driver. T
Fix time accounting which has the same lock contraint as for using hrtimer
and update accounting_timestamp only when useful.
Vincent Guittot (2):
PM-runtime: move runtime accounting on ktime_get_mono_fast_ns()
PM-runtime: update time accounting only when enabled
drivers/base/power/runtime.c
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
>
>
> On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
> > > +static const struct x86_cpu_desc isolation_ucodes[] = {
> > > + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
On 2/4/2019 11:15 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 10:43:41AM -0500, Liang, Kan wrote:
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1628,6 +1628,7 @@ void __init intel_ds_init(void)
x86_pmu.bts = boot_cpu_has(X86_FEATURE_BTS);
x86_pmu
On 04/02/2019 15:48, Christian Borntraeger wrote:
On 01.02.2019 14:37, Pierre Morel wrote:
On 01/02/2019 11:56, David Hildenbrand wrote:
On 01.02.19 10:52, Pierre Morel wrote:
The case when the SIE for guest3 is not setup for using
encryption keys nor Adjunct processor but the guest2
does us
On 04/02/2019 16:15, David Hildenbrand wrote:
On 01.02.19 14:37, Pierre Morel wrote:
On 01/02/2019 11:56, David Hildenbrand wrote:
On 01.02.19 10:52, Pierre Morel wrote:
The case when the SIE for guest3 is not setup for using
encryption keys nor Adjunct processor but the guest2
does use these
On Mon, Feb 04, 2019 at 05:28:23PM +0300, Dmitry Osipenko wrote:
> 04.02.2019 17:00, Thierry Reding пишет:
> > On Mon, Feb 04, 2019 at 03:03:49PM +0300, Dmitry Osipenko wrote:
> >> 04.02.2019 14:05, Thierry Reding пишет:
> >>> On Mon, Feb 04, 2019 at 09:53:32AM +, Jon Hunter wrote:
>
> >>>
The patch
ASoC: mediatek: btcvsd: fix spelling mistake "offest" -> "offset"
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 2
The GMU code currently has some misguided code to try to work around
a hardware quirk that requires the power domains on the GPU be
collapsed in a certain order. Upcoming patches will do this the
right way so get rid of the unused and unwanted regulator
code.
Signed-off-by: Jordan Crouse
---
dr
The GMU should have two power domains defined: "cx" and "gx". "cx" is the
actual power domain for the device and "gx" will be attached at runtime
to manage reference counting on the GPU device in case of a GMU crash.
Signed-off-by: Jordan Crouse
---
Documentation/devicetree/bindings/display/msm
The HFI tasklet was removed in df0dff1 ("drm/msm/a6xx: Poll for HFI
responses") but the tasklet_struct was accidentally left behind.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b
On 2/4/2019 11:10 AM, Peter Zijlstra wrote:
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
+ INTEL_CPU_DESC(INTEL_FAM6_CANNONLAKE_MOBILE, 3, 0x),
Funny that, CNL doesn't have any perf support at all yet.. Maybe do that
patch first or delay this
Now that the GX domain is sorted we can wire up a working GMU reset.
IF a GMU hang was detected then try to forcefully shut down the GMU
in the power down sequence which should ensure that it can recover
normally on the next power up.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/
This is a stack of changes for 5.1 (if I'm not already too late). The bulk of
the changes implement a better GMU reset sequence using the new gpucc power
domain added in 5.0. If a GMU fault occurs during runtime we try to do a
standard GPU recovery and if the fault happens during GMU start then try
99.999% of the time during normal operation the GMU is responsible
for power and clock control on the GX domain and the CPU remains
blissfully unaware. However, there is one situation where the CPU
needs to get involved:
The power sequencing rules dictate that the GX needs to be turned
off before
Currently if the GMU resume function fails all we try to do is clear the
BOOT_SLUMBER oob which usually times out and ends up in a cycle of death.
If the resume function fails at any point remove any RPMh votes that might
have been added and try to shut down the GMU hardware cleanly.
Signed-off-by
On Mon, Feb 04, 2019 at 10:43:41AM -0500, Liang, Kan wrote:
> > --- a/arch/x86/events/intel/ds.c
> > +++ b/arch/x86/events/intel/ds.c
> > @@ -1628,6 +1628,7 @@ void __init intel_ds_init(void)
> > x86_pmu.bts = boot_cpu_has(X86_FEATURE_BTS);
> > x86_pmu.pebs = boot_cpu_has(X86_FEATURE_PEBS)
> As my understanding, the microcode version for each stepping is independent
> and irrelevant. The 0x004e should be just coincidence.
> If so, I don't think X86_STEPPING_ANY is very useful.
>
> Andi, if I'm wrong please correct me.
Yes that's right. You cannot match microcode without steppin
On Mon, Feb 04, 2019 at 07:44:25PM +0530, Subrahmanya Lingappa wrote:
>Bjorn,
>My apologies, I was away for a while from this work.
>I am starting to review now.
Hi,
I am not Bjorn and as I told you before you should not reply
with html context (ie use plain text, the public lists wil
On Mon, Feb 04, 2019 at 04:08:02PM +, Christopher Lameter wrote:
> It may be worth noting a couple of times in this text that this was
> designed for anonymous memory and that such use is/was ok. We are talking
> about a use case here using mmapped access with a regular filesystem that
> was no
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
> + INTEL_CPU_DESC(INTEL_FAM6_CANNONLAKE_MOBILE, 3, 0x),
Funny that, CNL doesn't have any perf support at all yet.. Maybe do that
patch first or delay this line to that patch?
On Tue, Jan 15, 2019 at 11:29:42AM +0100, Johan Hovold wrote:
> On Tue, Jan 15, 2019 at 10:26:07AM +0100, Johan Hovold wrote:
> > On Tue, Jan 15, 2019 at 09:17:58AM +, Karoly Pados wrote:
> > > > I think it's better to add the autopm call to gpio210x_gpio_get/set
> > > > only. This will allow f
Below is the list of build error/warning regressions/improvements in
v5.0-rc5[1] compared to v4.20[2].
Summarized:
- build errors: +2/-4
- build warnings: +113/-14843
JFYI, when comparing v5.0-rc5[1] to v5.0-rc4[3], the summaries are:
- build errors: +0/-0
- build warnings: +56/-59
Note
On Sun, 3 Feb 2019, john.hubb...@gmail.com wrote:
> Some kernel components (file systems, device drivers) need to access
> memory that is specified via process virtual address. For a long time, the
> API to achieve that was get_user_pages ("GUP") and its variations. However,
> GUP has critical lim
Paolo,
On 2/1/19 6:01 PM, Suravee Suthikulpanit wrote:
> Paolo,
>
> On 1/30/19 11:22 PM, Paolo Bonzini wrote:
>> On 29/01/19 09:09, Suthikulpanit, Suravee wrote:
>>> The function svm_refresh_apicv_exec_ctrl() always returning prematurely
>>> as kvm_vcpu_apicv_active() always return false when cal
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
>
>
> On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
> > > +static const struct x86_cpu_desc isolation_ucodes[] = {
> > > + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
On Mon 04 Feb 02:43 PST 2019, Mark Brown wrote:
> On Tue, Jan 29, 2019 at 11:46:52PM +0100, Niklas Cassel wrote:
>
> > Adding Mark Brown on CC.
>
> It really helps if you ask a specific question when doing something like
> this rather than just have a big quoted mail - it makes it much easier
>
On Thu, Jan 31, 2019 at 03:46:40PM +0100, Daniel Vetter wrote:
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
>
> We are introducing this, as I915 needs two different component
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
Hi,
This series adds PRU-ICSS support for AM57xx IDK.
PRU-ICSS is not present only on AM57xx SoCs so the PRUSS
nodes are left disabled in dra7.dtsi. The board that uses
a AM57xx SoC will have to enable them if required.
PRU-ICSS has a SYSC register but it requires custom handling.
So we add a ne
The PRUSS module has a SYSCFG which is unique. Add
support for it.
Signed-off-by: Roger Quadros
---
drivers/bus/ti-sysc.c | 77 +++
include/dt-bindings/bus/ti-sysc.h | 11 -
include/linux/platform_data/ti-sysc.h | 1 +
3 files changed, 78
* Andreas Kemnade [190202 06:01]:
> Enabling off mode was only reachable deeply hidden
> in the debugfs. As powersaving is an important feature,
> move the option out of its shady place.
How about let's enable always if we have the twl4030
configured to allow it? You can just check if the dts has
On Sun, Feb 03, 2019 at 08:09:37AM -0500, Prarit Bhargava wrote:
> Ted, the bug I'm trying to fix is the warning:
>
> random: get_random_bytes called from start_kernel+0x8e/0x587 with crng_init=0
>
> during early boot. Even with the kernel parameter the warning appears.
Sometimes the warnings a
From: Suman Anna
The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes (both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all
From: Suman Anna
Add the DT nodes for the PRU-ICSS1 and PRU-ICSS2 processor subsystems
that are present on AM57xx family of SoCs. Each PRU-ICSS instance is
represented by a pruss-soc-bus node and a child PRUSS subsystem node.
The two PRU-ICSSs are identical to each other. They are not supported
o
The PRUSS module has a SYSCFG which is unique. Add
support for it.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/bus/ti-sysc.txt | 1 +
include/dt-bindings/bus/ti-sysc.h | 11 +++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetr
Kees Cook wrote:
> Change snprintf to scnprintf. There are generally two cases where using
> snprintf causes problems.
>
> 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...) In this case,
> if snprintf would have written more characters than what the buffer
> size (SIZE) is, then size will
I think you sent to wrong address of Alistair on these and other patches.
Corrected address.
On Fri, Feb 01, 2019 at 06:39:03AM +0100, Hugo Lefeuvre wrote:
> simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using newly
> added wait_event_freezable_hrtimeout helper and remove useles
On Mon, Feb 04, 2019 at 04:44:21PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 04, 2019 at 03:37:20PM +, Sudeep Holla wrote:
> > On Thu, Jan 31, 2019 at 04:05:59PM +, Sudeep Holla wrote:
> > > On Thu, Jan 31, 2019 at 12:48:49AM +0100, Rafael J. Wysocki wrote:
> > > > On Friday, January 2
On 2/4/2019 10:38 AM, Peter Zijlstra wrote:
This then? That's nearly what you had; except a lot less noisy.
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "../perf_event.h"
@@ -3206,16 +
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
> +static const struct x86_cpu_desc isolation_ucodes[] = {
> + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
> + INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 10, 0x004e),
> + INTEL_CPU_DESC(INTEL_F
On Mon, Feb 04, 2019 at 10:36:10AM -0500, Scott Bauer wrote:
> > Which brings up another question: how do we get a properly maintained
> > version of the sed-opal tool up ASAP? It's been a bit bitrotting
> > unfortunately, and the documentation and error handling hasn't been all
> > that great to
On Mon, Feb 04, 2019 at 03:37:20PM +, Sudeep Holla wrote:
> On Thu, Jan 31, 2019 at 04:05:59PM +, Sudeep Holla wrote:
> > On Thu, Jan 31, 2019 at 12:48:49AM +0100, Rafael J. Wysocki wrote:
> > > On Friday, January 25, 2019 4:09:06 PM CET Sudeep Holla wrote:
> > > > The sysfs for the cpu cac
On 02/01/2019 11:41 AM, Mark Salyzyn wrote:
if (alloc_size < nlk->max_recvmsg_len) {
if (alloc_min_size < nlk->max_recvmgs_len) {
-- Mark
On 2/4/2019 10:17 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:06:23PM +0100, Peter Zijlstra wrote:
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
So what's wrong with the below?
Installing a quirk for
(typing hard..)
but what I was going to say is tha
This then? That's nearly what you had; except a lot less noisy.
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "../perf_event.h"
@@ -3206,16 +3207,27 @@ static struct perf_guest_switch_msr *int
On Thu, Jan 31, 2019 at 04:05:59PM +, Sudeep Holla wrote:
> On Thu, Jan 31, 2019 at 12:48:49AM +0100, Rafael J. Wysocki wrote:
> > On Friday, January 25, 2019 4:09:06 PM CET Sudeep Holla wrote:
> > > The sysfs for the cpu caches are managed by adding devices with cpu
> > > as the parent in cpu_
On Mon, Feb 04, 2019 at 07:04:15AM -0800, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 09:50:07PM +0100, David Kozub wrote:
> > This patch series extends SED OPAL support: it adds IOCTL for setting the
> > shadow
> > MBR done flag which can be useful for unlocking an OPAL disk on boot and it
This driver use the gpio consumer interface.
Add the header as it's needed.
Signed-off-by: Clément Péron
---
This has been triggered by Kbuild-all for information:
https://lists.01.org/pipermail/kbuild-all/2019-February/057379.html
sound/soc/codecs/ak4118.c | 1 +
1 file changed, 1 insertion(+
On 04/02/19 17:11, Andrew F. Davis wrote:
> On 2/4/19 8:22 AM, Roger Quadros wrote:
>> From: "Andrew F. Davis"
>>
>
> [...]
>
>> +static const struct pruss_intc_match_data am437x_pruss_intc_data = {
>> +.no_host7_intr = true,
>
> Like done for the PRUSS driver with 'has_no_sharedram' becomi
On 04/02/19 16:52, Andrew F. Davis wrote:
> On 2/4/19 8:22 AM, Roger Quadros wrote:
>> From: Suman Anna
>>
>> The Programmable Real-Time Unit - Industrial Communication
>> Subsystem (PRU-ICSS) is present on various TI SoCs such as
>> AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
>> on
No need for the array of structs of function pointers when we can just
call the handfull of functions directly.
This could be further cleaned up if acpi_gbl_reduced_hardware was defined
true in the ACPI_REDUCED_HARDWARE case, but that's material for the next
round.
Signed-off-by: Christoph Hellwi
From: Colin Ian King
There is a spelling mistake in a dev_warn message. Fix this.
Signed-off-by: Colin Ian King
---
sound/soc/mediatek/common/mtk-btcvsd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/common/mtk-btcvsd.c
b/sound/soc/mediatek/common/mtk
Hi Nicholas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on v5.0-rc4 next-20190204]
[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
On 2/4/19 8:22 AM, Roger Quadros wrote:
> From: Jason Reeder
>
[...]
> +/* .name matches on RPMsg Channels and causes a probe */
> +static const struct rpmsg_device_id rpmsg_driver_pru_id_table[] = {
> + { .name = "rpmsg-pru" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(rpmsg, rpmsg_driver_
On Mon, Feb 04, 2019 at 11:10:39AM +0100, Marc Gonzalez wrote:
> + GKH
>
> On 01/02/2019 17:23, Marc Gonzalez wrote:
>
> > On 23/01/2019 13:31, Mike Rapoport wrote:
> >
> >> Signed-off-by: Mike Rapoport
> >> Tested-by: Marc Gonzalez
> >> Acked-by: Marek Szyprowski
> >> ---
> >> drivers/of/of
On 2/4/19 8:22 AM, Roger Quadros wrote:
> From: David Lechner
>
> This adds a special handler to the default remoteproc ELF firmware
> loader that looks up the memory map on TI PRU firmware files.
>
> These processors have multiple memory maps that share the same address
> space, so we need to k
Hi,
There is a header missing "linux/gpio/consumer.h"
I will propose a patch.
Regards,
Clement
On Sun, 3 Feb 2019 at 03:43, kbuild test robot wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: f17b5f06cb92ef2250513a1e154c47b78df07d40
> com
From: Colin Ian King
There is a null check on pointer dev which implies it may be null, however
dev can never be null as it is set in rtl8192_usb_probe via the call
to usb_set_intfdata.
Detected by CoverityScan, CID#143078 ("Dereference after null check")
Fixes: 8fc8598e61f6 ("Staging: Added Re
501 - 600 of 1302 matches
Mail list logo
