Hi Laurent,
Thanks for the comment.
>-Original Message-
>From: Laurent Pinchart
>Sent: Wednesday, June 17, 2020 3:18 AM
>To: Venkateshwar Rao Gannavarapu
>Cc: Hyun Kwon ; dri-de...@lists.freedesktop.org;
>airl...@linux.ie; dan...@ffwll.ch; linux-kernel@vger.kernel.org; Sandip Kothari
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2020年6月22日 週一 下午1:32寫道：
>
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
Except the Fixes tag,
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Hsin-Yi Wang
> ---
>
Flavio Suligoi writes:
> Fix typo: "EZUSB_REQUEST_TRIGER" --> "EZUSB_REQUEST_TRIGGER"
>
> Signed-off-by: Flavio Suligoi
> ---
> drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
The prefix should be "orinoco_usb: ", but I can fix
Em Mon, Jun 22, 2020 at 03:04:07PM +0200, Borislav Petkov escreveu:
> On Mon, Jun 22, 2020 at 11:38:24AM +1000, Stephen Rothwell wrote:
> > I applied that patch to the tip tree merge today.
> >
> > Tested-by: Stephen Rothwell # build tested
>
> Here's v2 instead, addressing acme's request. I
Good day
Is this email private for discussion and personal to you?
On 22.06.20 11:22, Wei Yang wrote:
> On Mon, Jun 22, 2020 at 10:43:11AM +0200, David Hildenbrand wrote:
>> On 22.06.20 10:26, Wei Yang wrote:
>>> On Fri, Jun 19, 2020 at 02:59:20PM +0200, David Hildenbrand wrote:
Especially with memory hotplug, we can have offline sections (with a
If the UVC_QUIRK_IGNORE_SELECTOR_UNIT flag is set, then there is a
problem that the code uses "iterm" after the end of the
list_for_each_entry() loop. It should only be used when the
UVC_ENTITY_IS_ITERM() condition is true and we break from the loop.
Fixes: d5e90b7a6cd1 ("[media] uvcvideo: Move
Hello, I have sent you this message earlier, but your failure to
respond, Please get back to me.Best Regard,Mr.David Keller.
+ linux-wireless
kernel test robot writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5e857ce6eae7ca21b2055cca4885545e29228fe2
> commit: 9c29da3f4e7ef9810bdfaf3d8aa5e6d2e33136f8 brcmfmac: Fix P2P
> Group Formation failure via Go-neg method
>
On 6/21/20 2:53 PM, William Breathitt Gray wrote:
Synapses simply indicate a change in a Count value
Ah, ok. I understand now that synapse is the wrong term for things like
the change in direction event or error events.
For example, in the dual-axes positioning table scenario, a user
On 22.06.20 15:10, Wei Yang wrote:
> On Mon, Jun 22, 2020 at 11:51:34AM +0200, David Hildenbrand wrote:
>> On 22.06.20 11:22, Wei Yang wrote:
>>> On Mon, Jun 22, 2020 at 10:43:11AM +0200, David Hildenbrand wrote:
On 22.06.20 10:26, Wei Yang wrote:
> On Fri, Jun 19, 2020 at 02:59:20PM
On 22.06.2020 15:11, Jiri Olsa wrote:
> On Mon, Jun 22, 2020 at 01:50:03PM +0300, Alexey Budankov wrote:
>>
>> On 22.06.2020 13:21, Jiri Olsa wrote:
>>> On Mon, Jun 22, 2020 at 12:47:19PM +0300, Alexey Budankov wrote:
>>>
>>> SNIP
>>>
>> fdarray__del(array, fdkey);
>
> I
Ping
On 6/5/20 5:39 PM, Tony Krowiak wrote:
Note: Patch 1 - s390/ap: introduce new ap function ap_get_qdev() - is not
a part of this series. It is a forthcoming patch that is a
prerequisite to this series and is being provided so this series
will compile.
The current
From: "Rafael J. Wysocki"
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock
Hi All,
This series is to address the problem with RCU synchronization occurring,
possibly relatively often, inside of acpi_ex_system_memory_space_handler(),
when the namespace and interpreter mutexes are held.
Like I said before, I had decided to change the approach used in the previous
From: "Rafael J. Wysocki"
Add acpi_os_map_memory_fast_path() and set ACPI_USE_FAST_PATH_MAPPING
to allow acpi_ex_system_memory_space_handler() to avoid unnecessary
memory mapping and unmapping overhead by retaining all memory
mappings created by it until the memory opregions associated with
them
> On 22 June 2020 at 14:30 Federico Vaga wrote:
>
>
> On Mon, Jun 22, 2020 at 02:01:12PM +0200, Thomas Ruf wrote:
> >> On 22 June 2020 at 06:47 Vinod Koul wrote:
> >>
> >> On 21-06-20, 22:36, Federico Vaga wrote:
> >> > On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote:
> >> > > On
From: "Rafael J. Wysocki"
The ACPICA's strategy with respect to the handling of memory mappings
associated with memory operation regions is to avoid mapping the
entire region at once which may be problematic at least in principle
(for example, it may lead to conflicts with overlapping mappings
From: "Rafael J. Wysocki"
Implement acpi_os_unmap_deferred() and
acpi_os_release_unused_mappings() and set ACPI_USE_DEFERRED_UNMAPPING
to allow ACPICA to use deferred unmapping of memory in
acpi_ex_system_memory_space_handler() so as to avoid RCU-related
performance issues with memory opregions.
On 2020-06-21 17:49, Frank Rowand wrote:
> On 2020-06-21 17:45, Frank Rowand wrote:
>> Tim Bird started a thread [1] proposing that he document the selftest result
>> format used by Linux kernel tests.
>>
>> [1]
>>
> On 22 June 2020 at 14:27 Richard Weinberger
> wrote:
>
>
> On Mon, Jun 22, 2020 at 2:02 PM Thomas Ruf wrote:
> > > more the reason not do do so, why cant a kernel driver be added for your
> > > usage?
> >
> > by chance i have written a driver allowing dma from user space using a
> > memcpy
On 20/06/20 00:45, Jim Mattson wrote:
>> + /*
>> +* TODO: if both L0 and L1 need the same MASK and MATCH,
>> +* go ahead and use it?
>> +*/
> I'm not sure there's much "TODO", since L0's MASK and MATCH are both
> 0. So, if L1's MASK and
Hi Marc,
Am Montag, 22. Juni 2020, 15:31:55 CEST schrieb Marc Zyngier:
> On Sat, 13 Jun 2020 11:24:35 +0100
> Marc Zyngier wrote:
>
> > Booting a recent kernel on a rk3399-based system (nanopc-t4),
> > equipped with a recent u-boot and ATF results in the following:
> >
> > [5.607431]
On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote:
> The PHY subsystem cannot be the first to run into this problem, that
> you need a device structure to make use of the regulator API, but you
> need the regulator API to probe the device. How do other subsystems
> work around this?
If
Florinel Iordache would like to recall the message, "[PATCH net-next v2 0/9]
net: ethernet backplane support on DPAA1".
: 6 weeks ago
config: x86_64-randconfig-a003-20200622 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
git checkout 49e649c3e0a6ec8a12976e331a2c1f29dc7dd3a9
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
On 6/22/20 12:34 AM, Vinod Koul wrote:
On 19-06-20, 09:27, Pierre-Louis Bossart wrote:
+For Gapless, we move from running state to partial drain and back, along
+with setting of meta_data and signalling for next track ::
+
+
++--+
+
On Mon, 22 Jun 2020 10:30:18 +0200
Peter Enderborg wrote:
> This is a preparation for debugfs restricted mode.
> We don't need debugfs to trace, the removed check stop tracefs to work
> if debugfs is not initialised. We instead tries to automount within
> debugfs and relay on it's handling. The
On 6/22/20 1:58 AM, Vinod Koul wrote:
So we had some discussions of the stream states, so I thought it is a
good idea to document the state transitions, so add it documentation
Signed-off-by: Vinod Koul
---
.../sound/designs/compress-offload.rst| 52 +++
1 file
On 6/22/20 3:26 PM, Kurt Van Dijck wrote:
> On ma, 22 jun 2020 14:54:15 +0200, Marc Kleine-Budde wrote:
>> On 6/22/20 2:43 PM, Kurt Van Dijck wrote:
>>> I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of
>>> the single other node).
>>
>> Single other node? Who's ACKing the CAN
On Wed, 17 Jun 2020 11:54:56 +0100, Steven Price wrote:
> If SVE is enabled then 'ret' can be assigned the return value of
> kvm_vcpu_enable_sve() which may be 0 causing future "goto out" sites to
> erroneously return 0 on failure rather than -EINVAL as expected.
>
> Remove the initialisation of
22.06.2020 01:29, Laurent Pinchart пишет:
> Hi Dmitry,
>
> Thank you for the patch.
>
> On Mon, Jun 22, 2020 at 01:27:41AM +0300, Dmitry Osipenko wrote:
>> The EDT ET057090DHU panel has a DPI connector and not LVDS. This patch
>> corrects the panel's description.
>>
>> Reported-by: Laurent
On Mon, Jun 22, 2020 at 11:37:38AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Currently the PHY ID is read without taking the PHY out of reset. This
> can only work if no resets are defined. This change delays the ID read
> until we're actually registering the PHY device -
Commit ed318a6cc0b6 ("fscrypt: support test_dummy_encryption=v2") added an
entry to the massive option table in Documentation/filesystems/f2fs.txt.
The option was too wide for the formatting of the table, though, leading to
a verbose and ugly docs-build warning starting with:
Add support for Ethernet Backplane KR driver only on DPAA1 devices.
Ethernet Backplane KR generic driver is using link training
(ieee802.3ap/ba standards), equalization algorithms (bee, fixed) and
enable qoriq family of devices.
This driver is dependent on uboot Backplane KR support:
On Sun, Jun 21, 2020 at 08:50:09PM -0700, Linus Torvalds wrote:
> On Sun, Jun 21, 2020 at 8:02 PM Jason A. Donenfeld wrote:
> >
> > This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809.
> >
> > This commit broke userspace. Bash uses ESPIPE to determine whether or
> > not the file should
The INIT_B is used by the 6 and 7 series to report the programming status,
providing more control and information about programming errors.
Signed-off-by: Luca Ceresoli
---
Changes in v2:
- rename init_b-gpios to init-b-gpios (Rob Herring suggested to not use '_'
in property names)
---
The INIT_B pin reports the status during startup and after the end of the
programming process. However the current driver completely ignores it.
Check the pin status during startup to make sure programming is never
started too early and also to detect any hardware issues in the FPGA
connection.
Add support for backplane kr generic driver including link training
(ieee802.3ap/ba) and fixed equalization algorithm
Signed-off-by: Florinel Iordache
---
drivers/net/phy/Kconfig |2 +
drivers/net/phy/Makefile |1 +
drivers/net/phy/backplane/Kconfig
Enable backplane support for qoriq family of devices
Signed-off-by: Florinel Iordache
---
drivers/net/phy/backplane/Kconfig| 11 +-
drivers/net/phy/backplane/Makefile | 2 +
drivers/net/phy/backplane/qoriq_backplane.c | 473 ++
Add kr support in mac driver for dpaa1
Signed-off-by: Florinel Iordache
---
drivers/net/ethernet/freescale/fman/mac.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c
b/drivers/net/ethernet/freescale/fman/mac.c
index
Add dt nodes with serdes, lanes, mdio generic description for supported
platform: ls1046. This is a prerequisite to enable backplane on device
tree for these platforms.
Signed-off-by: Florinel Iordache
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 33 +-
Add ethernet backplane device tree bindings
Signed-off-by: Florinel Iordache
---
.../bindings/net/ethernet-controller.yaml | 7 ++-
.../devicetree/bindings/net/ethernet-phy.yaml | 50 ++
.../devicetree/bindings/net/serdes-lane.yaml | 49
Add support for bee equalization algorithm used by kr training:
3-Taps Bit Edge Equalization (BEE) algorithm
Signed-off-by: Florinel Iordache
---
drivers/net/phy/backplane/Kconfig | 11 +
drivers/net/phy/backplane/Makefile |1 +
drivers/net/phy/backplane/eq_bee.c | 1076
Add ethernet backplane documentation
Signed-off-by: Florinel Iordache
---
Documentation/networking/backplane.rst | 159 +
Documentation/networking/phy.rst | 9 +-
2 files changed, 165 insertions(+), 3 deletions(-)
create mode 100644
Add support for Ethernet Backplane KR driver only on DPAA1 devices.
Ethernet Backplane KR generic driver is using link training
(ieee802.3ap/ba standards), equalization algorithms (bee, fixed) and
enable qoriq family of devices.
This driver is dependent on uboot Backplane KR support:
Hi Heiko,
On Sat, 13 Jun 2020 11:24:35 +0100
Marc Zyngier wrote:
> Booting a recent kernel on a rk3399-based system (nanopc-t4),
> equipped with a recent u-boot and ATF results in the following:
>
> [5.607431] Unable to handle kernel NULL pointer dereference at virtual
> address
On Mon, Jun 22, 2020 at 02:40:49PM +0800, Wen Su wrote:
> From: "Wen Su"
>
> The MT6359 is a regulator found on boards based on MediaTek MT6779 and
> probably other SoCs. It is a so called pmic and connects as a slave to
> SoC using SPI, wrapped inside the pmic-wrapper.
Acked-by: Mark Brown
On Tue, Jun 16, 2020 at 10:22:11AM -0700, Peter Oskolkov wrote:
> From 7b091e46de4f9227b5a943e6d78283564e8c1c72 Mon Sep 17 00:00:00 2001
> From: Peter Oskolkov
> Date: Tue, 16 Jun 2020 10:13:58 -0700
> Subject: [RFC PATCH 0/3 v2] futex: introduce FUTEX_SWAP operation
>
> This is an RFC!
>
> As
Hi Andrew,
Quoting Andrew Lunn (2020-06-20 17:21:42)
> > + /* Retrieve the shared load/save GPIO. Request it as non exclusive as
> > + * the same GPIO can be requested by all the PHYs of the same package.
> > + * Ths GPIO must be used with the phc_lock taken (the lock is shared
> >
On Mon, Jun 22, 2020 at 11:37:43AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The MDIO sub-system now supports PHY regulators. Let's reuse the code
> to extend this support over to the PHY device.
>
> Signed-off-by: Bartosz Golaszewski
> ---
>
On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote:
> On Mon, Jun 22, 2020 at 12:23:21PM +0100, Mark Brown wrote:
> > That's concerning - please don't do this. It's not what stable is
> > expected to be and there's no guarantee that you're getting all the
> > changes required to
Am 19.06.20 um 12:36 schrieb Marek Szyprowski:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
On ma, 22 jun 2020 14:54:15 +0200, Marc Kleine-Budde wrote:
> On 6/22/20 2:43 PM, Kurt Van Dijck wrote:
> > I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of
> > the single other node).
>
> Single other node? Who's ACKing the CAN frames?
hence the back-to-back burst.
>
> >
Hi Andrew,
Quoting Andrew Lunn (2020-06-20 17:40:08)
> On Fri, Jun 19, 2020 at 02:22:58PM +0200, Antoine Tenart wrote:
> > To get and set the PHC time, a GPIO has to be used and changes are only
> > retrieved or committed when on a rising edge. The same GPIO is shared by
> > all PHYs, so the
On Mon, Jun 22, 2020 at 11:37:42AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Currently many MAC drivers control the regulator supplying the PHY but
> this is conceptually wrong. The regulator should be defined as a property
> of the PHY node on the MDIO bus and controlled
Hi Adam,
Thanks for your patch!
On Wed, Jun 17, 2020 at 2:05 PM Adam Ford wrote:
> Beacon EmebddedWorks, formerly Logic PD is introducing a new
EmbeddedWorks
> SOM and development kit based on the RZ/G2M SoC from Renesas.
>
> The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
>
On Mon, Jun 22, 2020 at 11:37:35AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Similarily to PHY drivers - there's no reason to require probe() to be
> implemented in order to call mdio_device_reset(). MDIO devices can have
> resets defined without needing to do anything in
On Sun, 7 Jun 2020 10:43:48 +0100
Marc Zyngier wrote:
Hi Bjorn,
> On a system that creates VFs for multiple PFs in parallel (in
> this case, network bringup at boot time), and when these VFs
> end-up on the same bus, bad things sometimes happen:
>
> [ 12.755534] sysfs: cannot create
On Mon, Jun 22, 2020 at 11:37:34AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Currently we only call phy_device_reset() if the PHY driver implements
> the probe() callback. This is not mandatory and many drivers (e.g.
> realtek) don't need probe() for most devices but
On Mon, 22 Jun 2020 00:04:32 +0200
Pavel Machek wrote:
> > Rationale:
> > Reduces attack surface on kernel devs opening the links for MITM
> > as HTTPS traffic is much harder to manipulate.
>
> > +++ b/Documentation/admin-guide/README.rst
> > @@ -1,6 +1,6 @@
> > .. _readme:
> >
> > -Linux
On Mon, Jun 22, 2020 at 11:37:33AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This header refers to struct reset_control but doesn't include any reset
> header. The structure definition is probably somehow indirectly pulled in
> since no warnings are reported but for the
> > > HEAD commit:27f11fea Add linux-next specific files for 20200622
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=138dc74310
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=41c659db5cada6f4
On Mon, Jun 22, 2020 at 11:37:30AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Keeping the headers in alphabetical order is better for readability and
> allows to easily see if given header is already included.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew
On Mon, Jun 22, 2020 at 11:37:32AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Keeping the headers in alphabetical order is better for readability and
> allows to easily see if given header is already included.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew
On Mon, Jun 22, 2020 at 11:37:31AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Keeping the headers in alphabetical order is better for readability and
> allows to easily see if given header is already included.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew
The kernel module may sleep with holding a spinlock.
The function call paths (from bottom to top) are:
[FUNC] zalloc_cpumask_var(GFP_KERNEL)
drivers/net/ethernet/cisco/enic/enic_main.c, 125: zalloc_cpumask_var in
enic_init_affinity_hint
drivers/net/ethernet/cisco/enic/enic_main.c, 1918:
On Fri, Jun 19, 2020 at 3:59 PM Tiffany Lin wrote:
>
> On Wed, 2020-05-20 at 17:27 +0900, Alexandre Courbot wrote:
> > vidioc_try_fmt() does clamp height and width when called on the OUTPUT
> > queue, so clamping them prior to calling this function is redundant. Set
> > the queue's parameters
On Mon, Jun 22, 2020 at 11:51:34AM +0200, David Hildenbrand wrote:
>On 22.06.20 11:22, Wei Yang wrote:
>> On Mon, Jun 22, 2020 at 10:43:11AM +0200, David Hildenbrand wrote:
>>> On 22.06.20 10:26, Wei Yang wrote:
On Fri, Jun 19, 2020 at 02:59:20PM +0200, David Hildenbrand wrote:
>
The machine hosting lists.infradead.org and git.infradead.org suffered
a complete disk failure over the weekend; sadly the last backup of the
mailman config was fairly old (May 2018) so the subscriber lists and
archives have been reset to that date, but the lists should be running
again.
I've
Hello Richard,
Quoting Richard Cochran (2020-06-20 17:00:45)
> On Fri, Jun 19, 2020 at 02:22:58PM +0200, Antoine Tenart wrote:
>
> > +static void vsc85xx_dequeue_skb(struct vsc85xx_ptp *ptp)
> > +{
> > + struct skb_shared_hwtstamps shhwtstamps;
> > + struct vsc85xx_ts_fifo fifo;
> > +
On Sat, 20 Jun 2020 15:21:05 -0600
Jens Axboe wrote:
> On 6/19/20 6:20 PM, André Almeida wrote:
> > Create a documentation providing a background and explanation around the
> > operation of the Multi-Queue Block IO Queueing Mechanism (blk-mq).
> >
> > The reference for writing this
Hi Andrew,
Quoting Andrew Lunn (2020-06-20 17:10:01)
> On Fri, Jun 19, 2020 at 02:22:57PM +0200, Antoine Tenart wrote:
> > From: Quentin Schulz
> >
> > This patch adds the first parts of the 1588 support in the MSCC PHY,
> > with registers definition and the 1588 block initialization.
> >
> >
On Mon, 22 Jun 2020 01:43:12 +0200
Miguel Ojeda wrote:
> > * The script should not be neccessary once all of my changes[1] arrive
> > in torvalds/master. Instead reviewers should say like C'mon dude, what's
> > this new plain-HTTP link doing in your patch? We have 2020! Look at e.g.
> >
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 625d3449788f85569096780592549d0340e9c0c7
commit: 80591e61a0f7e88deaada69844e4a31280c4a38f kbuild: tell sparse about the
$ARCH
date: 7 months ago
config: s390-randconfig-s032-20200622 (attached as .config
Jacek
On 6/21/20 3:24 PM, Jacek Anaszewski wrote:
Dan,
On 6/21/20 4:12 PM, Dan Murphy wrote:
Jacek
On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
Dan,
On 6/19/20 6:35 PM, Dan Murphy wrote:
Jacek
On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
Dan,
On Mon, Jun 22, 2020 at 11:38:24AM +1000, Stephen Rothwell wrote:
> I applied that patch to the tip tree merge today.
>
> Tested-by: Stephen Rothwell # build tested
Here's v2 instead, addressing acme's request. I didn't rebase the
x86/cleanups branch because I'd like to have this case
On Mon, Jun 22, 2020 at 03:01:55PM +0200, Oleg Nesterov wrote:
> On 06/22, Christian Brauner wrote:
> >
> > It is a supported case however unlikely. I just tried to answer
> > Dominique's specific question pointing out that even in that unlikely
> > case sighand_struct is stable.
>
> I too tried
On 06/22, Christian Brauner wrote:
>
> It is a supported case however unlikely. I just tried to answer
> Dominique's specific question pointing out that even in that unlikely
> case sighand_struct is stable.
I too tried to say this, but apparently just added more confusion ;)
> Just as an fyi,
On Mon, 22 Jun 2020 08:27:53 +0800
Ming Lei wrote:
> Can you kprobe guys improve the implementation for covering this case?
> For example, put probe on 3) in case the above situation is recognized.
To do so would require solving the halting problem.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 625d3449788f85569096780592549d0340e9c0c7
commit: f566e1fbadb686e28f1c307e356114b2865ef588 kbuild: make multiple
directory targets work
date: 5 months ago
config: openrisc-randconfig-s031-20200622
*sigh*, this one should actually build and I got a smatch report that
there's an uninitizlied usage of @cpu, so I shuffled that around a bit.
---
Subject: sched: Fix ttwu() race
From: Peter Zijlstra
Date: Mon, 22 Jun 2020 12:01:23 +0200
Paul reported rcutorture occasionally hitting a NULL
Hi Prabhakar,
On Sun, Jun 7, 2020 at 8:42 PM Lad Prabhakar
wrote:
> The HiHope RZ/G2N variants are advertised as compatible with panel
> idk-1110wr from Advantech, however the panel isn't sold alongside the
> board. New dts's, enabling the lvds node to get the panel to work with
> all the HiHope
Hi Jisheng,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc2 next-20200622]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git
On 6/22/20 2:43 PM, Kurt Van Dijck wrote:
> I get RX-0: FIFO overflows in listen-only mode (back-to-back burst of
> the single other node).
Single other node? Who's ACKing the CAN frames?
> The SPI peripheral does not use DMA :-(.
The SPI messages are quite small, so DMA wont help either.
Hi Prabhakar,
On Sun, Jun 7, 2020 at 8:42 PM Lad Prabhakar
wrote:
> The HiHope RZ/G2N sub board sits below the HiHope RZ/G2N Rev.3.0/4.0 main
> board.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
One minor comment below.
Apart from that:
Reviewed-by: Geert
On Wed, Jun 17, 2020 at 06:27:27AM +, Liu, Yi L wrote:
> > From: Stefan Hajnoczi
> > Sent: Monday, June 15, 2020 5:41 PM
> > On Thu, Jun 11, 2020 at 05:15:33AM -0700, Liu Yi L wrote:
> >
> > > From: Eric Auger
> > >
> > > The VFIO API was enhanced to support nested stage control: a bunch of
On Sun, Jun 7, 2020 at 8:42 PM Lad Prabhakar
wrote:
> Add support for HiHope RZ/G2N Rev.3.0/4.0 main board support based on
> r8a774b1 SoC.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
On Tue, Jun 16, 2020 at 12:09:16PM -0400, Peter Xu wrote:
> On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote:
> > Isolation between applications is preserved but there is no isolation
> > between the device and the application itself. The application needs to
> > trust the device.
>
Hello Andrew,
Quoting Andrew Lunn (2020-06-20 16:52:52)
> On Fri, Jun 19, 2020 at 02:22:55PM +0200, Antoine Tenart wrote:
> > From: Quentin Schulz
> >
> > This patch adds a define for the 0x8000 magic value used to perform
> > enable/disable actions on the "token ring clock". The patch is only
On Mon, Jun 22, 2020 at 01:05:25PM +0100, Shiju Jose wrote:
> CPER records describing a firmware-first error are identified by GUID.
> The ghes driver currently logs, but ignores any unknown CPER records.
> This prevents describing errors that can't be represented by a standard
> entry, that would
On Tue, Jun 16, 2020 at 10:00:16AM -0700, Raj, Ashok wrote:
> On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote:
> > On Tue, Jun 16, 2020 at 02:26:38AM +, Tian, Kevin wrote:
> > > > From: Stefan Hajnoczi
> > > > Sent: Monday, June 15, 2020 6:02 PM
> > > >
> > > > On Thu, Jun
On Sun, Jun 7, 2020 at 8:42 PM Lad Prabhakar
wrote:
> Add support for idk-1110wr display as similarly done for Rev.2.0
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert
On Sun, Jun 7, 2020 at 8:42 PM Lad Prabhakar
wrote:
> Separate out LVDS specific nodes into common file
> hihope-rzg2-ex-lvds.dtsi so that this can be re-used by RZ/G2M[N]
> variants.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Geert Uytterhoeven
Hi,
On Mon, Jun 22, 2020 at 10:22:48AM +0200, Krzysztof Kozlowski wrote:
> On Fri, Jun 19, 2020 at 07:55:21PM +0200, Sebastian Reichel wrote:
> > On Wed, May 27, 2020 at 09:42:54AM +0200, Pali Rohár wrote:
> > > On Tuesday 26 May 2020 21:16:28 Andrew F. Davis wrote:
> > > > On 5/25/20 7:32 AM,
Hi Martin,
On Sat, 20 Jun 2020 at 22:07, Martin Blumenstingl
wrote:
>
> Meson6, Meson8, Meson8b and Meson8m2 are using a similar SDHC controller
> IP which typically connects to an eMMC chip (because unlike the SDIO
> controller the SDHC controller has an 8-bit bus interface).
>
> On Meson8,
Hi Martin,
On Sat, 20 Jun 2020 at 22:08, Martin Blumenstingl
wrote:
>
> Odroid-C1 has an eMMC connector where users can optionally install an
> eMMC module. The eMMC modules run off a 1.8V VQMMC supply which means
> that HS-200 mode can be used (this is the highest mode that the SDHC
>
+ Robin
Robin, any idea on this?
On Thu, Jun 18, 2020 at 10:40:26PM -0400, Andrea Arcangeli wrote:
> Hello,
>
> On Thu, Jun 18, 2020 at 06:14:49PM -0700, Roman Gushchin wrote:
> > I agree. The whole
> >
> > page = alloc_pages_node(nid, alloc_flags, order);
> > if (!page)
> >
Jacek
On 6/22/20 7:42 AM, Jacek Anaszewski wrote:
Dan,
On 6/21/20 10:24 PM, Jacek Anaszewski wrote:
Dan,
On 6/21/20 4:12 PM, Dan Murphy wrote:
Jacek
On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
Dan,
On 6/19/20 6:35 PM, Dan Murphy wrote:
Jacek
On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
On Fri, Jun 19, 2020 at 4:26 PM Tiffany Lin wrote:
>
> On Wed, 2020-05-20 at 17:27 +0900, Alexandre Courbot wrote:
> > Different chips have different supported bitrate ranges. Move the list
> > of supported formats to the platform data, and split the output and
> > capture formats into two lists
1201 - 1300 of 1749 matches
Mail list logo
