Hi,
On Mon, Aug 10, 2020 at 4:21 AM Maulik Shah wrote:
>
> From: Douglas Anderson
>
> This goes with the new irq_suspend_one() and irq_resume_one()
> callbacks and allow us to easily pass things up to our parent.
>
> Signed-off-by: Douglas Anderson
> Signed-off-by: Maulik Shah
> ---
> include
On Tue, Aug 11, 2020 at 11:12:36AM -0700, Josh Triplett wrote:
> As far as I can tell, O_NONBLOCK has no effect on a pidfd. When calling
> waitid on a pidfd for a running process, it always blocks unless you
> provide WNOHANG.
>
> I don't think anything depends on that behavior. Would it be possib
Hi,
On 8/8/2020 3:14 AM, Stephen Boyd wrote:
Quoting Stephen Boyd (2020-06-11 15:46:58)
Quoting Sandeep Maheswaram (2020-06-11 07:28:02)
From: Taniya Das
The USB client requires the usb30_prim gdsc to be kept active for
certain use cases, thus add the GENPD_FLAG_ACTIVE_WAKEUP flag.
Can you
Hi,
On Mon, Aug 10, 2020 at 4:21 AM Maulik Shah wrote:
>
> From: Douglas Anderson
>
> The "struct irq_chip" has two callbacks in it: irq_suspend() and
> irq_resume(). These two callbacks are interesting because sometimes
> an irq chip needs to know about suspend/resume, but they are a bit
> awk
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
;
On Tue, Aug 11, 2020 at 12:24 PM Linus Torvalds
wrote:
>
> Now I wonder if there's any other case of FOLL_WRITE that is missing.
Actually, now I wonder if we really should have tried to handle the
wrong-way cow reuse case some other way entirely.
When discussing this wrong-way-COW issue origi
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 20
drivers/gpu/
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional changes
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 22 ++
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d701f09aea645..bb85d81c25244 100644
--- a/drivers/gpu/drm/nou
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/drivers/gpu/drm/nouveau/nouve
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
Hi,
On Mon, Aug 10, 2020 at 4:21 AM Maulik Shah wrote:
>
> Add irqchip specific flags for msmgpio irqchip to mask non wakeirqs
> during suspend and mask before setting irq type.
>
> Masking before changing type should make sure any spurious interrupt
> is not detected during this operation.
>
> F
Mickaël Salaün writes:
> Allow for the enforcement of the O_MAYEXEC openat2(2) flag. Thanks to
> the noexec option from the underlying VFS mount, or to the file execute
> permission, userspace can enforce these execution policies. This may
> allow script interpreters to check execution permissi
Hi Felipe,
On 7/28/2020 12:50 AM, Matthias Kaehlcke wrote:
On Mon, Jul 27, 2020 at 10:36:36PM +0530, Sandeep Maheswaram wrote:
Add interconnect support in dwc3-qcom driver to vote for bus
bandwidth.
This requires for two different paths - from USB to
DDR. The other is from APPS to USB.
Signed
On Tue, Aug 11, 2020 at 12:56 PM Bird, Tim wrote:
>
>
>
> > -Original Message-
> > From: Brendan Higgins
> > Sent: Friday, August 7, 2020 7:17 PM
> >
> > From: Heidi Fahim
> >
> > Add a --json flag, which when specified when kunit_tool is run,
> > generates JSON formatted test results con
>From the spec:
"7.1.5 Response to Hard Resets
Hard Reset Signaling indicates a communication failure has occurred and
the Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin
and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB connection
May reset during a Hard Reset sin
On Tue, Aug 11, 2020 at 10:00 AM Saravana Kannan wrote:
>
> On Mon, Aug 10, 2020 at 7:50 PM John Stultz wrote:
> >
> > When booting with heavily modularized config, the serial console
> > may not be able to load until after init when modules that
> > satisfy needed dependencies have time to load.
On Tue, Aug 11, 2020 at 09:07:17PM +0200, Jann Horn wrote:
> On Tue, Aug 11, 2020 at 8:39 PM Peter Xu wrote:
> > Starting from commit 17839856fd58 ("gup: document and work around "COW can
> > break either way" issue", 2020-06-02), explicit copy-on-write behavior is
> > enforced for private gup pag
Hi Venkateshwar
On Tue, Aug 11, 2020 at 06:16:15AM +0530, Venkateshwar Rao Gannavarapu wrote:
> Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar
> and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes
> upto 4, RGB color formats, video mode and command modes.
> -Original Message-
> From: Brendan Higgins
> Sent: Friday, August 7, 2020 7:17 PM
>
> From: Heidi Fahim
>
> Add a --json flag, which when specified when kunit_tool is run,
> generates JSON formatted test results conforming to the KernelCI API
> test_group spec[1]. The user can the ne
On Fri, Jul 24, 2020 at 04:08:05PM +0800, Peng Fan wrote:
> It is using devm_ioremap, so not devm_ioremap_resource. Correct
> the error message and print out sa/size.
>
> Signed-off-by: Peng Fan
> ---
> drivers/remoteproc/imx_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
Mickaël Salaün writes:
> When the O_MAYEXEC flag is passed, openat2(2) may be subject to
> additional restrictions depending on a security policy managed by the
> kernel through a sysctl or implemented by an LSM thanks to the
> inode_permission hook. This new flag is ignored by open(2) and
> ope
On Tue, 11 Aug 2020, Sumera Priyadarsini wrote:
> Modify coccinelle documentation to further clarify
> the usage of the makefile C variable by coccicheck.
>
> Signed-off-by: Sumera Priyadarsini
Acked-by: Julia Lawall
Thanks.
>
> ---
> Changes in v4:
> - Modify commit message to cl
--
Hello Darling,
I am happy to have you here as a friend, i hope all is well with you,
and how are you enjoying your day over there in your country?
My name is Sergeant ,Shannon Mccraney. I’m 29 years an orphan my
parents died when I was five years old nobody to help me,I send you my
business
On Tue, Aug 11, 2020 at 09:31:05PM +0200, Lennart Poettering wrote:
> On Di, 11.08.20 20:49, Miklos Szeredi (mik...@szeredi.hu) wrote:
>
> > On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
> > wrote:
> >
> > > and then people do "$(srctree)/". If you haven't seen that kind of
> > > pattern where t
From: Michael Jeanson
The objective is to check that the incoming vrf routing table is selected
to send an ICMP error back to the source when the ttl of a packet reaches 1
while it is forwarded between different vrfs.
The first test sends a ping with a ttl of 1 from h1 to h2 and parses the
outpu
Hi,
Here is a series of fixes for ipv4 and ipv6 which which ensure the route
lookup is performed on the right routing table in VRF configurations.
It includes a test for both ipv4 and ipv6.
The series has been rebased on the net tree.
Thanks,
Mathieu
Mathieu Desnoyers (2):
ipv4/icmp: l3mdev
As per RFC4443, the destination address field for ICMPv6 error messages
is copied from the source address field of the invoking packet.
In configurations with Virtual Routing and Forwarding tables, looking up
which routing table to use for sending ICMPv6 error messages is
currently done by using t
As per RFC792, ICMP errors should be sent to the source host.
However, in configurations with Virtual Routing and Forwarding tables,
looking up which routing table to use is currently done by using the
destination net_device.
commit 9d1a6c4ea43e ("net: icmp_route_lookup should use rt dev to
deter
On 2020-08-07 13:28, Randy Dunlap wrote:
On 8/7/20 1:24 PM, Stephen Boyd wrote:
Quoting Rob Clark (2020-08-07 08:51:48)
On Fri, Aug 7, 2020 at 8:27 AM Randy Dunlap
wrote:
On 8/7/20 12:17 AM, Tanmay Shah wrote:
diff --git a/drivers/gpu/drm/msm/Kconfig
b/drivers/gpu/drm/msm/Kconfig
index ea3
ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko]
undefined!
ARM64 tegra194-cpufreq driver use cpu_logical_map, export
__cpu_logical_map to fix build issue.
I wonder why like other instances in the drivers, the mpidr is not get
directly from the cpu. The cpufreq_dr
On Tue, Aug 11, 2020 at 11:54:28AM -0700, Tom Rix wrote:
>
> On 8/11/20 10:53 AM, Alan Stern wrote:
> >>> Instead of changing all these call sites, wouldn't it be a lot easier
> >>> just to change rts51x_read_mem() to make it always return a negative
> >>> value (such as -EIO) when there's an e
Commit eaecca9e7710 ("arm64: Fix __cpu_logical_map undefined issue")
fixes the issue with building tegra194 cpufreq driver as module. But
the fix might cause problem while supporting physical cpu hotplug[1].
This patch fixes the original problem by avoiding use of cpu_logical_map().
Instead callin
Mickaël Salaün writes:
> From: Kees Cook
>
> The path_noexec() check, like the regular file check, was happening too
> late, letting LSMs see impossible execve()s. Check it earlier as well
> in may_open() and collect the redundant fs/exec.c path_noexec() test
> under the same robustness comment
On Tue, Aug 11, 2020 at 11:45 AM Guenter Roeck wrote:
>
> On Tue, Aug 11, 2020 at 11:24:07AM -0700, Badhri Jagan Sridharan wrote:
> > On Mon, Aug 10, 2020 at 6:51 PM Guenter Roeck wrote:
> > >
> > > On 8/10/20 6:11 PM, Badhri Jagan Sridharan wrote:
> > > >>From the spec:
> > > > "7.1.5 Response t
Hi,
> -Original Message-
> From: Heikki Krogerus
> Sent: Tuesday, August 11, 2020 6:07 AM
> To: Prashant Malani ; Shaikh, Azhar
>
> Cc: ble...@chromium.org; enric.balle...@collabora.com;
> gro...@chromium.org; linux-kernel@vger.kernel.org; Patel, Utkarsh H
> ; Bowman, Casey G
> ; Mani, R
Thomas Gleixner writes:
> "Paul E. McKenney" writes:
>> On Tue, Aug 11, 2020 at 04:44:21PM +0200, Thomas Gleixner wrote:
>>> Now RCU creates a new thing which enforces to make page allocation in
>>> atomic context possible on RT. What for?
>>>
>>> What's the actual use case in truly atomic conte
On Tue, Aug 11, 2020 at 09:05:22AM -0700, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 8:30 AM Miklos Szeredi wrote:
> >
> > What's the disadvantage of doing it with a single lookup WITH an enabling
> > flag?
> >
> > It's definitely not going to break anything, so no backward
> > compatibility
Changes in v3:
* Patch 1: "platform/chrome: cros_ec_typec: Send enum values to
usb_role_switch_set_role()"
- No change
* Patch 2: "platform/chrome: cros_ec_typec: Avoid setting usb role twice
during disconnect"
- Move the location of calling usb_role_switch_set_role() to
usb_role_switch_set_role() has the second argument as enum for usb_role.
Currently depending upon the data role i.e. UFP(0) or DFP(1) is sent.
This eventually translates to USB_ROLE_NONE in case of UFP and
USB_ROLE_DEVICE in case of DFP. Correct this by sending correct enum
values as USB_ROLE_DEVIC
As per USB Type-C Spec R2.0 section 4.5.1.2 (Connecting Sources and Sinks)
and section 4.5.2.2 (Connection State Machine Requirements), the typical
flow for configuring a device connected to a typeC port is as below:
1. Source/sink detection
2. Orientation
3. Data role
4. VCONN
5. VBUS (USB Type-C
On disconnect port partner is removed and usb role is set to NONE.
But then in cros_typec_port_update() the role is set again.
Avoid this by moving usb_role_switch_set_role() to
cros_typec_configure_mux().
Signed-off-by: Azhar Shaikh
---
Changes in v3:
- Move the location of calling usb_role_swi
On Tue, Aug 11, 2020 at 08:32:25PM +0200, Michal Koutny wrote:
> On Tue, Aug 11, 2020 at 09:55:27AM -0700, Roman Gushchin wrote:
> > As I said, there are 2 problems with charging systemd (or a similar daemon):
> > 1) It often belongs to the root cgroup.
> This doesn't hold for systemd (if we agree
Can the subject be more specific? "pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED
flag"?
Quoting Maulik Shah (2020-08-10 04:20:54)
> Add irqchip specific flags for msmgpio irqchip to mask non wakeirqs
> during suspend and mask before setting irq type.
>
> Masking before changing type should make sur
Mickaël Salaün writes:
> From: Kees Cook
>
> The execve(2)/uselib(2) syscalls have always rejected non-regular
> files. Recently, it was noticed that a deadlock was introduced when trying
> to execute pipes, as the S_ISREG() test was happening too late. This was
> fixed in commit 73601ea5b7b1 ("
Quoting Maulik Shah (2020-08-10 04:20:55)
> msmgpio irqchip is not using return value of irq_set_wake call.
> Start using it.
Does this work when the irq parent isn't setup in a hierarchy? I seem to
recall that this was written this way because sometimes
irq_set_irq_wake() would fail for the summa
On Tue, Aug 11, 2020 at 01:39:24PM -0400, Qian Cai wrote:
> On Tue, Aug 11, 2020 at 03:11:40AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> > I'm still not sure why the test succeeded by reverting these because
> > current mainline kernel provides similar mechanism to prevent reuse of
> > soft offlined p
On Di, 11.08.20 20:49, Miklos Szeredi (mik...@szeredi.hu) wrote:
> On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
> wrote:
>
> > and then people do "$(srctree)/". If you haven't seen that kind of
> > pattern where the pathname has two (or sometimes more!) slashes in the
> > middle, you've led a v
Quoting Tanmay Shah (2020-08-10 19:15:53)
> @@ -2440,6 +2447,71 @@ dsi_phy: dsi-phy@ae94400 {
>
> status = "disabled";
> };
> +
> + msm_dp: displayport-controller@ae9 {
> + status = "di
Hi!
> > > > (eg, a specification) will be critical for remote filesystems.
> > > >
> > > > If any of this is to be supported by a remote filesystem, then we
> > > > need an unencumbered description of the new metadata format
> > > > rather than code. GPL-encumbered formats cannot be contributed t
- On Aug 11, 2020, at 3:14 PM, David Ahern dsah...@gmail.com wrote:
> On 8/11/20 1:11 PM, Mathieu Desnoyers wrote:
>> One thing I am missing before this series can be considered for upstreaming
>> is an Acked-by of the 2 fixes for ipv4 and ipv6 from you, as maintainer
>> of l3mdev, if you thin
Measuring keys is currently only supported for asymmetric keys. In the
future, this might change.
For now, the "func=KEY_CHECK" and "keyrings=" options are only
appropriate when CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS is enabled. Make
this clear at policy load so that IMA policy authors don't assume th
v2:
- Always return an ERR_PTR from ima_alloc_rule_opt_list() (Nayna)
- Add Lakshmi's Reviewed-by to both patches
- Rebased on commit 3db0d0c276a7 ("integrity: remove redundant
initialization of variable ret") of next-integrity
v1:
https://lore.kernel.org/lkml/20200727140831.64251-1-tyhi...@
The ima_keyrings buffer was used as a work buffer for strsep()-based
parsing of the "keyrings=" option of an IMA policy rule. This parsing
was re-performed each time an asymmetric key was added to a kernel
keyring for each loaded policy rule that contained a "keyrings=" option.
An example rule spe
On Tue, Aug 11, 2020 at 11:40 AM Peter Xu wrote:
>
> index 206f52b36ffb..c88f773d03af 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1296,7 +1296,17 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf,
> pmd_t orig_pmd)
> if (reuse_swap_page(page, NULL)) {
>
On Tue, Aug 11, 2020 at 6:48 PM Philippe Mathieu-Daudé wrote:
> On Tue, Aug 11, 2020 at 5:01 PM Álvaro Fernández Rojas
> wrote:
> >
> > Current board declarations are a mess. Let's put some order and make them
> > follow the same structure. Also board declarations tabs.
> > Switch to SPDX license
The number of interrupt cells for the mdss interrupt controller is 1,
meaning there should only be one cell for the interrupt number, not two
where the second cell is the irq flags. Drop the second cell to match
the binding.
Cc: Kalyan Thota
Cc: Harigovindan P
---
arch/arm64/boot/dts/qcom/sc718
On 8/11/2020 8:00 PM, Guenter Roeck wrote:
rearm_wake_irq() does not unlock the irq descriptor if the interrupt
is not suspended or if wakeup is not enabled on it. Fix it.
Fixes: 3a79bc63d9075 ("PCI: irq: Introduce rearm_wake_irq()")
Cc: Rafael J. Wysocki
Signed-off-by: Guenter Roeck
Acked-b
Hi Vinay.
> >
> > If Laurent or others identify further things to improve we can take
> > it in-tree.
>
> Just one thing, please see below.
>
> > > > >> + d2l_write(tc->i2c, VTIM1, vtime1);
> > > > >> + d2l_write(tc->i2c, HTIM2, htime2);
> > > > >> + d2l_write(tc->i2c, VTIM2,
ebied...@xmission.com (Eric W. Biederman) writes:
> Mickaël Salaün writes:
>
>> From: Kees Cook
>>
>> Change uselib(2)' S_ISREG() error return to EACCES instead of EINVAL so
>> the behavior matches execve(2), and the seemingly documented value.
>> The "not a regular file" failure mode of execve(
On 8/11/20 1:11 PM, Mathieu Desnoyers wrote:
> One thing I am missing before this series can be considered for upstreaming
> is an Acked-by of the 2 fixes for ipv4 and ipv6 from you, as maintainer
> of l3mdev, if you think the approach I am taking with those fixes makes sense.
Send the set, and I
On Sun, Aug 9, 2020 at 3:26 PM Kent Gibson wrote:
>
> Add a new version of the uAPI to address existing 32/64-bit alignment
> issues, add support for debounce and event sequence numbers, allow
> requested lines with different configurations, and provide some future
> proofing by adding padding res
- On Aug 11, 2020, at 2:57 PM, David Ahern dsah...@gmail.com wrote:
> On 8/11/20 11:28 AM, David Miller wrote:
>> From: Michael Jeanson
>> Date: Thu, 6 Aug 2020 14:51:21 -0400
>>
>>> The objective is to check that the incoming vrf routing table is selected
>>> to send an ICMP error back to
On Tue, Aug 11, 2020 at 8:39 PM Peter Xu wrote:
> Starting from commit 17839856fd58 ("gup: document and work around "COW can
> break either way" issue", 2020-06-02), explicit copy-on-write behavior is
> enforced for private gup pages even if it's a read-only. It is achieved by
> always passing FO
On Tue, Aug 11, 2020 at 12:03:51PM -0500, Uriel Guajardo wrote:
> On Mon, Aug 10, 2020 at 4:43 PM Peter Zijlstra wrote:
> >
> > On Mon, Aug 10, 2020 at 09:32:57PM +, Uriel Guajardo wrote:
> > > +static inline void kunit_check_locking_bugs(struct kunit *test,
> > > +
All the power domains exposed as part of AOSS QMP driver require to stay
powered on for suspend. They are powered on when the remote processors
boots up and powered off on remote processor crash/shutdown. Mark the
power domains with GENPD_FLAG_SUSPEND_ON to model this behavior.
Signed-off-by: Sibi
Mickaël Salaün writes:
> From: Kees Cook
>
> Change uselib(2)' S_ISREG() error return to EACCES instead of EINVAL so
> the behavior matches execve(2), and the seemingly documented value.
> The "not a regular file" failure mode of execve(2) is explicitly
> documented[1], but it is not mentioned i
This is for power domains which needs to stay powered on for suspend
but can be powered on/off as part of runtime PM. This flag is aimed at
power domains coupled to remote processors which enter suspend states
independent to that of the application processor. Such power domains
are turned off only
On 8/11/20 10:53 AM, Alan Stern wrote:
> On Tue, Aug 11, 2020 at 10:29:29AM -0700, Tom Rix wrote:
>> On 8/11/20 9:03 AM, Alan Stern wrote:
>>> On Tue, Aug 11, 2020 at 08:15:05AM -0700, t...@redhat.com wrote:
From: Tom Rix
clang static analysis reports this representative problem
>
On 8/11/20 11:28 AM, David Miller wrote:
> From: Michael Jeanson
> Date: Thu, 6 Aug 2020 14:51:21 -0400
>
>> The objective is to check that the incoming vrf routing table is selected
>> to send an ICMP error back to the source when the ttl of a packet reaches 1
>> while it is forwarded between d
On Mon, Aug 10, 2020 at 4:26 PM Gabriel Krisman Bertazi
wrote:
>
> Syscall user redirection requires the signal trampoline code to not be
> captured, in order to support returning with a locked selector while
> avoiding recursion back into the signal handler. For ia-32, which has
> the trampoline
On Tue, Aug 11, 2020 at 6:05 PM Linus Torvalds
wrote:
> and then people do "$(srctree)/". If you haven't seen that kind of
> pattern where the pathname has two (or sometimes more!) slashes in the
> middle, you've led a very sheltered life.
Oh, I have. That's why I opted for triple slashes, sin
06.08.2020 22:01, Sowjanya Komatineni пишет:
...
> + err = tegra_mipi_finish_calibration(csi_chan->mipi);
> +
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + goto err_disable_csi_stream;
> +
> + if (err < 0)
> + dev_warn(csi_chan->csi->dev,
> + "
On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
> Attached.
ssdt6.dsl:
| ThermalZone (TZ10)
| {
…
| Method (_TSP, 0, Serialized) // _TSP: Thermal Sampling Period
| {
| Return (0x0A)
| }
|
| Method (_TZP, 0, Serialized) // _TZP: Thermal Zone Polling
| {
|
On Tue, Aug 11, 2020 at 1:41 AM Anup Patel wrote:
>
> On Tue, Aug 11, 2020 at 12:07 PM Qiu Wenbo wrote:
> >
> > Exception vector is missing on nommu platform and it is a big issue.
> > This patch is tested in Sipeed MAIX Bit Dev Board.
> >
> > Fixes: 79b1feba5455 ("RISC-V: Setup exception vector
Hi Thomas,
On 8/11/2020 2:53 AM, Thomas Gleixner wrote:
Thomas Gleixner writes:
CC+: XEN folks
Thomas Gleixner writes:
The infrastructure itself is not more than a thin wrapper around the
existing msi domain infrastructure and might even share code with
platform-msi.
And the annoying fact
On Tue, Aug 11, 2020 at 11:24:07AM -0700, Badhri Jagan Sridharan wrote:
> On Mon, Aug 10, 2020 at 6:51 PM Guenter Roeck wrote:
> >
> > On 8/10/20 6:11 PM, Badhri Jagan Sridharan wrote:
> > >>From the spec:
> > > "7.1.5 Response to Hard Resets
> > > Hard Reset Signaling indicates a communication fa
Starting from commit 17839856fd58 ("gup: document and work around "COW can
break either way" issue", 2020-06-02), explicit copy-on-write behavior is
enforced for private gup pages even if it's a read-only. It is achieved by
always passing FOLL_WRITE to emulate a write.
That should fix the COW iss
Hi Thomas,
On 8/8/2020 12:47 PM, Thomas Gleixner wrote:
Megha,
"Dey, Megha" writes:
On 8/7/2020 9:47 AM, Thomas Gleixner wrote:
I'm all for sharing code and making the life of driver writers simple
because that makes my life simple as well, but not by creating a layer
at the wrong level and
> -Original Message-
> From: linux-arch-ow...@vger.kernel.org
> On Behalf Of Al Viro
Acked-by: Brian Cain
> From: Al Viro
>
> Signed-off-by: Al Viro
> ---
> arch/hexagon/kernel/ptrace.c | 62
+++-
> 1 file changed, 21 insertions(+), 41 delet
> -Original Message-
> From: linux-arch-ow...@vger.kernel.org
> On Behalf Of Nicholas Piggin
Acked-by: Brian Cain
> Cc: Brian Cain
> Cc: linux-hexa...@vger.kernel.org
> Signed-off-by: Nicholas Piggin
> ---
> arch/hexagon/include/asm/mmu_context.h | 33 --
>
On Tue, 2020-08-11 at 07:57 -0500, Benoit Parrot wrote:
> Daniel W. S. Almeida wrote on Fri [2020-Aug-07
> 05:35:46 -0300]:
> > From: "Daniel W. S. Almeida"
> >
> > Fix the following coccinelle report:
> >
> > drivers/media/platform/ti-vpe/vpdma.c:946:5-26: WARNING:
> > Comparison to bool
> >
In the case of TPROXY, bind_conflict optimizations for SO_REUSEADDR or
SO_REUSEPORT are broken, possibly resulting in O(n) instead of O(1) bind
behaviour or in the incorrect reuse of a bind.
the kernel keeps track for each bind_bucket if all sockets in the
bind_bucket support SO_REUSEADDR or SO_RE
Refactor the fastreuse update code in inet_csk_get_port into a small
helper function that can be called from other places.
Acked-by: Matthieu Baerts
Signed-off-by: Tim Froidcoeur
---
include/net/inet_connection_sock.h | 4 ++
net/ipv4/inet_connection_sock.c| 97
In the case of TPROXY, bind_conflict optimizations for SO_REUSEADDR or
SO_REUSEPORT are broken, possibly resulting in O(n) instead of O(1) bind
behaviour or in the incorrect reuse of a bind.
the kernel keeps track for each bind_bucket if all sockets in the
bind_bucket support SO_REUSEADDR or SO_RE
On Tue, Aug 11, 2020 at 09:55:27AM -0700, Roman Gushchin wrote:
> As I said, there are 2 problems with charging systemd (or a similar daemon):
> 1) It often belongs to the root cgroup.
This doesn't hold for systemd (if we agree that systemd is the most
common case).
> 2) OOMing or failing some ra
301 - 400 of 1030 matches
Mail list logo
