On Fri, Oct 4, 2019 at 6:33 AM Rasmus Villemoes
wrote:
>
> Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
> state argument) updated the kernel-doc for pwm_apply_state(), but not
> for the ->apply callback in the pwm_ops struct.
>
> Signed-off-by: Rasmus
Hello,
On Sat, Oct 05, 2019 at 09:43:26PM -0700, Bjorn Andersson wrote:
> As the @state passed to apply() is now const the comment in the
> kerneldoc about drivers being expected to adjust the parameters is no
> longer valid. Update it to reflect the API change.
>
> Fixes: 715
As the @state passed to apply() is now const the comment in the
kerneldoc about drivers being expected to adjust the parameters is no
longer valid. Update it to reflect the API change.
Fixes: 71523d1812ac ("pwm: Ensure pwm_apply_state() doesn't modify the state
argument")
Signed-off
Hello,
On Fri, Oct 04, 2019 at 03:32:02PM +0200, Rasmus Villemoes wrote:
> In preparation for supporting setting the polarity, switch the driver
> to support the ->apply method.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drive
On Fri, Oct 04, 2019 at 03:32:07PM +0200, Rasmus Villemoes wrote:
> Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
> state argument) updated the kernel-doc for pwm_apply_state(), but not
> for the ->apply callback in the pwm_ops struct.
>
> Signed-off-by
Commit 71523d1812ac (pwm: Ensure pwm_apply_state() doesn't modify the
state argument) updated the kernel-doc for pwm_apply_state(), but not
for the ->apply callback in the pwm_ops struct.
Signed-off-by: Rasmus Villemoes
---
include/linux/pwm.h | 5 +
1 file changed, 1 insertion(+)
In preparation for supporting setting the polarity, switch the driver
to support the ->apply method.
Signed-off-by: Rasmus Villemoes
---
drivers/pwm/pwm-mxs.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/
Split breakinput routine that configures STM32 timers 'break' safety
feature upon probe, into two routines:
- stm32_pwm_apply_breakinputs() sets all the break inputs into registers.
- stm32_pwm_probe_breakinputs() probes the device tree break input settings
before calling
From: Takashi Iwai
commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 upstream.
It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen
Laptop) is fixed by the same workaround applied to other AMD chips.
Update the driver_data entry for Raven (1022:15e3) to use the newly
introduced
Some of the Pine64+ boards are known to use a batch of broken RTL8211E
PHYs. A magic number that is in an undocumented field of a register is
passed from Realtek via Pine64.
Add the property to apply the hack to the Pine64+ device tree.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts
From: Takashi Iwai
commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 upstream.
It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen
Laptop) is fixed by the same workaround applied to other AMD chips.
Update the driver_data entry for Raven (1022:15e3) to use the newly
introduced
From: Takashi Iwai
commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 upstream.
It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen
Laptop) is fixed by the same workaround applied to other AMD chips.
Update the driver_data entry for Raven (1022:15e3) to use the newly
introduced
From: Takashi Iwai
commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 upstream.
It's reported that the garbled sound on HP Envy x360 13z-ag000 (Ryzen
Laptop) is fixed by the same workaround applied to other AMD chips.
Update the driver_data entry for Raven (1022:15e3) to use the newly
introduced
Hello,
[expanded the recipents to include RMK and the clk list]
On Mon, Sep 23, 2019 at 11:04:39AM +0200, Rasmus Villemoes wrote:
> On 23/09/2019 10.24, Uwe Kleine-König wrote:
> > Also there is a bug already in .config: You are not supposed to call
> > clk_get_rate if the clk might be off.
>
>
On 23/09/2019 10.24, Uwe Kleine-König wrote:
> Hello Rasmus,
>
> On Mon, Sep 23, 2019 at 10:13:45AM +0200, Rasmus Villemoes wrote:
>> In preparation for supporting setting the polarity, switch the driver
>> to support the ->apply method.
>>
>
> Maybe it would
Hello Rasmus,
On Mon, Sep 23, 2019 at 10:13:45AM +0200, Rasmus Villemoes wrote:
> In preparation for supporting setting the polarity, switch the driver
> to support the ->apply method.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drive
In preparation for supporting setting the polarity, switch the driver
to support the ->apply method.
Signed-off-by: Rasmus Villemoes
---
drivers/pwm/pwm-mxs.c | 62 +++
1 file changed, 62 insertions(+)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/
[ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ]
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via
Building in a separate object directory causes a compilation
failure for a missing header:
samples/watch_queue/watch_test.c:23:10: fatal error: linux/watch_queue.h: No
such file or directory
I could not figure out why this does not work and applied this
patch locally. It would be good to fix
From: Jan-Marek Glogowski
[ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ]
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC
--
Attn: Are you in need of a loan? we offer all kinds of loan like
Personal
loans, Debt Consolidation Loan, Business Loan, with an interest rate of
3%
Have you been turned down by your bank? Do you have bad credit? Do you
have
unpaid bills? Are you in debt? Do you need to set up a
From: Takashi Iwai
commit de768ce45466f3009809719eb7b1f6f5277d9373 upstream.
MSI MPG X570 board is with another AMD HD-audio controller (PCI ID
1022:1487) and it requires the same workaround applied for X370, etc
(PCI ID 1022:1457).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
From: Takashi Iwai
commit de768ce45466f3009809719eb7b1f6f5277d9373 upstream.
MSI MPG X570 board is with another AMD HD-audio controller (PCI ID
1022:1487) and it requires the same workaround applied for X370, etc
(PCI ID 1022:1457).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
From: Takashi Iwai
commit de768ce45466f3009809719eb7b1f6f5277d9373 upstream.
MSI MPG X570 board is with another AMD HD-audio controller (PCI ID
1022:1487) and it requires the same workaround applied for X370, etc
(PCI ID 1022:1457).
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
Goodnews today Have you been rejected by the bank, do you have poor credit or
bad financial status and you need an urgent loan for any of the following
reasons
.settle your debts,
.pay school fees for your children,
.complete a project,
.build a house or
.start up a business. Or for whatever
What happened to these patches? All four make sense to me, for what
it's worth; feel free to add a
Reviewed-by: J. Bruce Fields
--b.
On Sat, Jul 13, 2019 at 06:11:57AM +0200, Max Kellermann wrote:
> The function posix_acl_create() applies the umask only if the inode
> has no ACL (=
On Mon, Aug 12, 2019 at 11:30:39AM -0600, Logan Gunthorpe wrote:
> When a P2PDMA transfer is rejected due to ACS being set, we can also check
> the whitelist and allow the transactions.
>
> Do this by pushing the whitelist check into the upstream_bridge_distance()
> function.
>
> Link:
[ Upstream commit 5ea3f6fb37b79da33ac9211df336fd2b9f47c39f ]
check_msr is used to fix a bug report in guest where KVM doesn't support
LBR MSR and cause #GP.
The msr check is bypassed on real HW to workaround a false failure,
see commit d0e1a507bdc7 ("perf/x86/intel: Disable check_msr for real
When a P2PDMA transfer is rejected due to ACS being set, we can also check
the whitelist and allow the transactions.
Do this by pushing the whitelist check into the upstream_bridge_distance()
function.
Link: https://lore.kernel.org/r/20190730163545.4915-6-log...@deltatee.com
Signed-off-by: Logan
From: Zhenzhong Duan
[ Upstream commit 5ea3f6fb37b79da33ac9211df336fd2b9f47c39f ]
check_msr is used to fix a bug report in guest where KVM doesn't support
LBR MSR and cause #GP.
The msr check is bypassed on real HW to workaround a false failure,
see commit d0e1a507bdc7 ("perf/x86/intel:
From: Hui Wang
commit 4b4e0e32e4b09274dbc9d173016c1a026f44608c upstream.
Without this patch, the headset-mic and headphone-mic don't work.
Cc:
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_realtek.c |5 +
1 file
From: Zhenzhong Duan
commit 517c3ba00916383af6411aec99442c307c23f684 upstream.
X86_HYPER_NATIVE isn't accurate for checking if running on native platform,
e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's
From: Zhenzhong Duan
commit 517c3ba00916383af6411aec99442c307c23f684 upstream.
X86_HYPER_NATIVE isn't accurate for checking if running on native platform,
e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's
On Thu, Aug 01, 2019 at 04:04:15PM -0400, Joel Fernandes wrote:
> On Thu, Aug 1, 2019 at 3:58 PM Paul E. McKenney wrote:
> >
> > On Thu, Aug 01, 2019 at 02:14:02PM -0400, Joel Fernandes (Google) wrote:
> > > This series fixes the rcu/dev branch so it can apply the ne
On Thu, Aug 1, 2019 at 3:58 PM Paul E. McKenney wrote:
>
> On Thu, Aug 01, 2019 at 02:14:02PM -0400, Joel Fernandes (Google) wrote:
> > This series fixes the rcu/dev branch so it can apply the new ReST
> > conversion patches.
> >
> > Patches based on "00ec8f46
On Thu, Aug 01, 2019 at 02:14:02PM -0400, Joel Fernandes (Google) wrote:
> This series fixes the rcu/dev branch so it can apply the new ReST conversion
> patches.
>
> Patches based on "00ec8f46465e rcu/nohz: Make multi_cpu_stop() enable tick on
> all online CPUs"
&
On Thu, Aug 1, 2019 at 2:14 PM Joel Fernandes (Google)
wrote:
>
> This series fixes the rcu/dev branch so it can apply the new ReST conversion
> patches.
Weirdly enough, Patch 4/9 did not get received by the archive, but
patchwork did pick it up:
https://lore.kernel.org/patchwork/patch/1109574/
This series fixes the rcu/dev branch so it can apply the new ReST conversion
patches.
Patches based on "00ec8f46465e rcu/nohz: Make multi_cpu_stop() enable tick on
all online CPUs"
The easiest was to do this is to revert the patches that conflict and then
applying the d
When a P2PDMA transfer is rejected due to ACS being set, we
can also check the white list and allow the transactions.
Do this by pushing the whitelist check into the
upstream_bridge_distance() function.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Christian König
---
drivers/pci/p2pdma.c | 25
Hi Uwe,
Le mer. 24 juil. 2019 à 2:47, Uwe =?iso-8859-1?q?Kleine-K=F6nig?=
a écrit :
Hello Paul,
On Tue, Jul 23, 2019 at 04:46:40PM -0400, Paul Cercueil wrote:
Le lun. 22 juil. 2019 à 15:34, Uwe =?iso-8859-1?q?Kleine-K=F6nig?=
a écrit :
> On Fri, Jun 07, 2019 at 05:44:07PM +0200, Paul
From: Hui Wang
commit 4b4e0e32e4b09274dbc9d173016c1a026f44608c upstream.
Without this patch, the headset-mic and headphone-mic don't work.
Cc:
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_realtek.c |5 +
1 file
On Thu, Jul 25, 2019 at 05:24:58PM -0400, Daniel Jordan wrote:
> padata will use these these interfaces in a later patch, so unconfine them.
>
> Signed-off-by: Daniel Jordan
Acked-by: Tejun Heo
Thanks.
--
tejun
From: Zhenzhong Duan
commit 517c3ba00916383af6411aec99442c307c23f684 upstream.
X86_HYPER_NATIVE isn't accurate for checking if running on native platform,
e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's
p-dx-lanes property should not apply to
the upstream port. The reason given in the breaking commit was that it's
inconsitent with respect to other port properties, but in fact it is not.
All other properties which only apply to the downstream ports explicitly
reject port 0, so there is pretty strong
From: Zhenzhong Duan
commit 517c3ba00916383af6411aec99442c307c23f684 upstream.
X86_HYPER_NATIVE isn't accurate for checking if running on native platform,
e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's
From: Zhenzhong Duan
commit 517c3ba00916383af6411aec99442c307c23f684 upstream.
X86_HYPER_NATIVE isn't accurate for checking if running on native platform,
e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's
Commit-ID: 5ea3f6fb37b79da33ac9211df336fd2b9f47c39f
Gitweb: https://git.kernel.org/tip/5ea3f6fb37b79da33ac9211df336fd2b9f47c39f
Author: Zhenzhong Duan
AuthorDate: Thu, 25 Jul 2019 10:39:26 +0800
Committer: Ingo Molnar
CommitDate: Thu, 25 Jul 2019 15:41:30 +0200
perf/x86: Apply more
: Apply more accurate check on hypervisor platform
X86_HYPER_NATIVE isn't accurate for checking if running on native platform,
e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking the CPU feature bit X86_FEATURE_HYPERVISOR to determine if it's
running on native platfo
On Thu, Jul 25, 2019 at 10:39:26AM +0800, Zhenzhong Duan wrote:
> check_msr is used to fix a bug report in guest where KVM doesn't support
> LBR MSR and cause #GP.
>
> The msr check is bypassed on real HW to workaround a false failure,
> see commit d0e1a507bdc7 ("perf/x86/intel: Disable check_msr
From: Hui Wang
commit 4b4e0e32e4b09274dbc9d173016c1a026f44608c upstream.
Without this patch, the headset-mic and headphone-mic don't work.
Cc:
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_realtek.c |5 +
1 file
check_msr is used to fix a bug report in guest where KVM doesn't support
LBR MSR and cause #GP.
The msr check is bypassed on real HW to workaround a false failure,
see commit d0e1a507bdc7 ("perf/x86/intel: Disable check_msr for real HW")
When running a guest with CONFIG_HYPERVISOR_GUEST not set
X86_HYPER_NATIVE isn't accurate for checking if running on native
platform, e.g. CONFIG_HYPERVISOR_GUEST isn't set or "nopv" is enabled.
Checking cpu flag X86_FEATURE_HYPERVISOR to determine if it's running
on native platform is more accurate.
This still doesn't consider the old platform where
From: Hui Wang
commit 4b4e0e32e4b09274dbc9d173016c1a026f44608c upstream.
Without this patch, the headset-mic and headphone-mic don't work.
Cc:
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_realtek.c |5 +
1 file
From: Hui Wang
commit 4b4e0e32e4b09274dbc9d173016c1a026f44608c upstream.
Without this patch, the headset-mic and headphone-mic don't work.
Cc:
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/patch_realtek.c |5 +
1 file
Hello Paul,
On Tue, Jul 23, 2019 at 04:46:40PM -0400, Paul Cercueil wrote:
> Le lun. 22 juil. 2019 à 15:34, Uwe =?iso-8859-1?q?Kleine-K=F6nig?=
> a écrit :
> > On Fri, Jun 07, 2019 at 05:44:07PM +0200, Paul Cercueil wrote:
> > > -is_enabled = jz4740_timer_is_enabled(pwm->hwpwm);
> > >
Hi Uwe,
Le lun. 22 juil. 2019 à 15:34, Uwe =?iso-8859-1?q?Kleine-K=F6nig?=
a écrit :
Hello Paul,
On Fri, Jun 07, 2019 at 05:44:07PM +0200, Paul Cercueil wrote:
-static int jz4740_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
- int duty_ns, int
Am 23.07.19 um 01:08 schrieb Logan Gunthorpe:
> When a P2PDMA transfer is rejected due to ACS being set, we
> can also check the white list and allow the transactions.
>
> Do this by pushing the whitelist check into the
> upstream_bridge_distance() function.
>
> Signed-off-by: Logan Gunthorpe
When a P2PDMA transfer is rejected due to ACS being set, we
can also check the white list and allow the transactions.
Do this by pushing the whitelist check into the
upstream_bridge_distance() function.
Signed-off-by: Logan Gunthorpe
---
drivers/pci/p2pdma.c | 25 ++---
1
Hello Paul,
On Fri, Jun 07, 2019 at 05:44:07PM +0200, Paul Cercueil wrote:
> -static int jz4740_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> - int duty_ns, int period_ns)
> +static int jz4740_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +
Apply soft-disabled and the filter rule of the trace events to
the printk output of tracepoints (a.k.a. tp_printk kernel parameter)
as same as trace buffer output.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/trace
The function posix_acl_create() applies the umask only if the inode
has no ACL (= NULL) or if ACLs are not supported by the filesystem
driver (= -EOPNOTSUPP).
However, this happens only after after the IS_POSIXACL() check
succeeeded. If the superblock doesn't enable ACL support, umask will
never
The function ext4_init_acl() calls posix_acl_create() which is
responsible for applying the umask. But without
CONFIG_EXT4_FS_POSIX_ACL, ext4_init_acl() is an empty inline function,
and nobody applies the umask.
This fixes a bug which causes the umask to be ignored with O_TMPFILE
on ext4:
On Mon, 2019-07-01 at 19:51 -0700, Florian Fainelli wrote:
> Hi Ben,
>
> On 6/18/2019 7:28 AM, Ben Hutchings wrote:
> > 3.16.69-rc1 review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Eric Dumazet
> >
> > commit
The function ext4_init_acl() calls posix_acl_create() which is
responsible for applying the umask. But without
CONFIG_EXT4_FS_POSIX_ACL, ext4_init_acl() is an empty inline function,
and nobody applies the umask.
This fixes a bug which causes the umask to be ignored with O_TMPFILE
on ext4:
The function posix_acl_create() applies the umask only if the inode
has no ACL (= NULL) or if ACLs are not supported by the filesystem
driver (= -EOPNOTSUPP).
However, this happens only after after the IS_POSIXACL() check
succeeeded. If the superblock doesn't enable ACL support, umask will
never
Hi Ben,
On 6/18/2019 7:28 AM, Ben Hutchings wrote:
> 3.16.69-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric Dumazet
>
> commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
>
> Jonathan Looney reported that a malicious peer can
From: Thomas Gleixner
None of those functions have any users outside of workqueue.c. Confine
them.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/workqueue.h | 4
kernel/workqueue.c| 7 +++
2 files changed, 3 insertions(+), 8
Apply soft-disabled and the filter rule of the trace events to
the printk output of tracepoints (a.k.a. tp_printk kernel parameter)
as same as trace buffer output.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/trace
Firstly, introduce two new flags MM_CP_UFFD_WP[_RESOLVE] for
change_protection() when used with uffd-wp and make sure the two new
flags are exclusively used. Then,
- For MM_CP_UFFD_WP: apply the _PAGE_UFFD_WP bit and remove _PAGE_RW
when a range of memory is write protected by uffd
On Wed, Jun 19, 2019 at 12:56:26PM -0600, Logan Gunthorpe wrote:
> Presently, there is no path to DMA map P2PDMA memory, so if a TLP
> targeting this memory hits the root complex and an IOMMU is present,
> the IOMMU will reject the transaction, even if the RC would support
> P2PDMA.
>
> So until
Presently, there is no path to DMA map P2PDMA memory, so if a TLP
targeting this memory hits the root complex and an IOMMU is present,
the IOMMU will reject the transaction, even if the RC would support
P2PDMA.
So until the kernel knows to map these DMA addresses in the IOMMU,
we should not
3.16.69-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
Jonathan Looney reported that a malicious peer can force a sender
to fragment its retransmit queue into tiny skbs,
: Apply new CPU topology sysfs attributes
The existing "thread_siblings" and "thread_siblings_list" attribute will
be deprecated.
Use the new CPU topology sysfs attributes, "core_cpus" and
"core_cpus_list", which are synonymous with the deprecated attributes.
Ch
From: Thomas Gleixner
None of those functions have any users outside of workqueue.c. Confine
them.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/workqueue.h | 4
kernel/workqueue.c| 7 +++
2 files changed, 3 insertions(+), 8
From: Kan Liang
The existing "thread_siblings" and "thread_siblings_list" attribute will
be deprecated.
Use the new CPU topology sysfs attributes, "core_cpus" and
"core_cpus_list", which are synonymous with the deprecated attributes.
Check the new name first. If not available, use the
.request = jz4740_pwm_request,
.free = jz4740_pwm_free,
- .config = jz4740_pwm_config,
- .set_polarity = jz4740_pwm_set_polarity,
- .enable = jz4740_pwm_enable,
- .disable = jz4740_pwm_disable,
+ .apply = jz4740_pwm_apply,
.owner = THIS_MODULE,
};
--
2.21.0.593.g511ec345e18
From: Kan Liang
The existing "thread_siblings" and "thread_siblings_list" attribute will
be deprecated.
Use the new CPU topology sysfs attributes, "core_cpus" and
"core_cpus_list", which are synonymous with the deprecated attributes.
Check the new name first. If not available, use the
From: Kan Liang
The existing "thread_siblings" and "thread_siblings_list" attribute will
be deprecated.
Use the new CPU topology sysfs attributes, "core_cpus" and
"core_cpus_list", which are synonymous with the deprecated attributes.
Check the new name first. If not available, use the
st,
.free = jz4740_pwm_free,
- .config = jz4740_pwm_config,
- .set_polarity = jz4740_pwm_set_polarity,
- .enable = jz4740_pwm_enable,
- .disable = jz4740_pwm_disable,
+ .apply = jz4740_pwm_apply,
.owner = THIS_MODULE,
};
--
2.21.0.593.g511ec345e18
3.16.68-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jiri Kosina
commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.
Currently, IBPB is only issued in cases when switching into a non-dumpable
process, the rationale being to protect such
From: Jiri Kosina
commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.
Currently, IBPB is only issued in cases when switching into a non-dumpable
process, the rationale being to protect such 'important and security
sensitive' processess (such as GPG) from data leaking into a different
From: Takashi Iwai
commit 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd upstream.
Some ASUS models like Q325UAR with ALC295 codec requires the same
fixup that has been applied to ALC294 codec. Just copy the entry with
the pin matching to cover ALC295 too.
BugLink:
From: Takashi Iwai
commit 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd upstream.
Some ASUS models like Q325UAR with ALC295 codec requires the same
fixup that has been applied to ALC294 codec. Just copy the entry with
the pin matching to cover ALC295 too.
BugLink:
Firstly, introduce two new flags MM_CP_UFFD_WP[_RESOLVE] for
change_protection() when used with uffd-wp and make sure the two new
flags are exclusively used. Then,
- For MM_CP_UFFD_WP: apply the _PAGE_UFFD_WP bit and remove _PAGE_RW
when a range of memory is write protected by uffd
Hi,
On 4/9/19 4:25 AM, Andy Shevchenko wrote:
Apply same width for offset definitions to make code more consistent.
Looks good.
Signed-off-by: Andy Shevchenko
Reviewed-by: Kuppuswamy Sathyanarayanan
---
drivers/platform/x86/intel_pmc_ipc.c | 6 +++---
1 file changed, 3 insertions
Apply same width for offset definitions to make code more consistent.
Signed-off-by: Andy Shevchenko
---
drivers/platform/x86/intel_pmc_ipc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/intel_pmc_ipc.c
b/drivers/platform/x86/intel_pmc_ipc.c
From: Marek Vasut
[ Upstream commit 0e7d6f94016407fd7e1ae472e254d64d4454e9c8 ]
Since commit d6cd33ad7102 ("regulator: gpio: Convert to use descriptors")
the GPIO regulator had inverted the polarity of the control GPIO. This
problem manifested itself on systems with DT containing the following
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 97dc47a1308a3af46a09b1546cfb869f2e382a81 ]
The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally
5.0-stable review patch. If anyone has any objections, please let me know.
--
From: Sean Christopherson
commit 8570f9e881e3fde98801bb3a47eef84dd934d405 upstream.
The address size of an instruction affects the effective address, not
the virtual/linear address. The final
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Sean Christopherson
commit 8570f9e881e3fde98801bb3a47eef84dd934d405 upstream.
The address size of an instruction affects the effective address, not
the virtual/linear address. The final
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 97dc47a1308a3af46a09b1546cfb869f2e382a81 ]
The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Sean Christopherson
commit 8570f9e881e3fde98801bb3a47eef84dd934d405 upstream.
The address size of an instruction affects the effective address, not
the virtual/linear address. The final
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 97dc47a1308a3af46a09b1546cfb869f2e382a81 ]
The 1199:68C0 USB ID is reused by Sierra WP7607 which requires the DTR
quirk to be detected. Apply QMI_QUIRK_SET_DTR unconditionally
all patches that are
> > > submitted to stable@ but don't apply directly?
> > >
> > > I get notified by mail, that's fine though it's not that convenient to
> > > see all the pending patches for backport to a given version.
> > >
&g
On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > Hi,
> >
> > would it be possible to have a git repository with all patches that are
> > submitted to stable@ but don't apply directly?
>
On Thu, Mar 21, 2019 at 05:39:41PM +0100, Greg KH wrote:
> On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> > Hi,
> >
> > would it be possible to have a git repository with all patches that are
> > submitted to stable@ but don't apply directly?
>
On Thu, Mar 21, 2019 at 04:14:14PM +0100, David Sterba wrote:
> Hi,
>
> would it be possible to have a git repository with all patches that are
> submitted to stable@ but don't apply directly?
>
> I get notified by mail, that's fine though it's not that convenient to
>
Hi,
would it be possible to have a git repository with all patches that are
submitted to stable@ but don't apply directly?
I get notified by mail, that's fine though it's not that convenient to
see all the pending patches for backport to a given version.
My proposal:
- create a separate stable
Firstly, introduce two new flags MM_CP_UFFD_WP[_RESOLVE] for
change_protection() when used with uffd-wp and make sure the two new
flags are exclusively used. Then,
- For MM_CP_UFFD_WP: apply the _PAGE_UFFD_WP bit and remove _PAGE_RW
when a range of memory is write protected by uffd
CPU isn't allowed to touch secure registers while running under secure
monitor. Hence skip applying of CPU erratas in the reset handler if
Trusted Foundations firmware presents.
Partially based on work done by Michał Mirosław [1].
[1] https://www.spinics.net/lists/arm-kernel/msg594768.html
501 - 600 of 4625 matches
Mail list logo
