+cc linux-api, FYI - apologies I intended to cc from the start, was simply
an oversight. All future respins will cc.
This series changes mremap() semantics (I will update the manpage
accordingly of course).
Cheers, Lorenzo
On Mon, Jul 07, 2025 at 06:27:43AM +0100, Lorenzo Stoakes wrote:
> Histor
On Sun, Jul 06, 2025 at 11:12:35PM -0700, Hugh Dickins wrote:
> Applause!
>
> No way shall I review this, but each time I've seen an mremap series
> from Lorenzo go by, I've wanted to say "but wouldn't it be better to...";
> but it felt too impertinent to prod you in a direction I'd never dare
> ta
On Mon, 7 Jul 2025, Lorenzo Stoakes wrote:
> Historically we've made it a uAPI requirement that mremap() may only
> operate on a single VMA at a time.
>
> For instances where VMAs need to be resized, this makes sense, as it
> becomes very difficult to determine what a user actually wants should t
Historically we've made it a uAPI requirement that mremap() may only
operate on a single VMA at a time.
For instances where VMAs need to be resized, this makes sense, as it
becomes very difficult to determine what a user actually wants should they
indicate a desire to expand or shrink the size of
On 01-Jul-25 15:42, Luca Weiss wrote:
> On Tue Jul 1, 2025 at 1:16 PM CEST, Dmitry Baryshkov wrote:
>> On Mon, Jun 30, 2025 at 10:01:35AM +0200, Luca Weiss wrote:
>>> Hi Konrad,
>>>
>>> On Fri Jun 27, 2025 at 5:14 PM CEST, Luca Weiss wrote:
On Fri Jun 27, 2025 at 5:10 PM CEST, Konrad Dybcio
On Tue Jul 1, 2025 at 1:16 PM CEST, Dmitry Baryshkov wrote:
> On Mon, Jun 30, 2025 at 10:01:35AM +0200, Luca Weiss wrote:
>> Hi Konrad,
>>
>> On Fri Jun 27, 2025 at 5:14 PM CEST, Luca Weiss wrote:
>> > On Fri Jun 27, 2025 at 5:10 PM CEST, Konrad Dybcio wrote:
>> >> On 6/25/25 11:12 AM, Luca Weiss
On Mon, Jun 30, 2025 at 10:01:35AM +0200, Luca Weiss wrote:
> Hi Konrad,
>
> On Fri Jun 27, 2025 at 5:14 PM CEST, Luca Weiss wrote:
> > On Fri Jun 27, 2025 at 5:10 PM CEST, Konrad Dybcio wrote:
> >> On 6/25/25 11:12 AM, Luca Weiss wrote:
> >>> Document and add the clock drivers for GCC, CAMCC, DIS
Hi Konrad,
On Fri Jun 27, 2025 at 5:14 PM CEST, Luca Weiss wrote:
> On Fri Jun 27, 2025 at 5:10 PM CEST, Konrad Dybcio wrote:
>> On 6/25/25 11:12 AM, Luca Weiss wrote:
>>> Document and add the clock drivers for GCC, CAMCC, DISPCC, GPUCC and
>>> VIDEOCC on the SM7635 SoC.
>>>
>>> Signed-off-by: Lu
On Fri Jun 27, 2025 at 5:10 PM CEST, Konrad Dybcio wrote:
> On 6/25/25 11:12 AM, Luca Weiss wrote:
>> Document and add the clock drivers for GCC, CAMCC, DISPCC, GPUCC and
>> VIDEOCC on the SM7635 SoC.
>>
>> Signed-off-by: Luca Weiss
>> ---
>> Luca Weiss (10):
>> dt-bindings: clock: qcom: do
On 6/25/25 11:12 AM, Luca Weiss wrote:
> Document and add the clock drivers for GCC, CAMCC, DISPCC, GPUCC and
> VIDEOCC on the SM7635 SoC.
>
> Signed-off-by: Luca Weiss
> ---
> Luca Weiss (10):
> dt-bindings: clock: qcom: document the SM7635 Global Clock Controller
> clk: qcom: Add Gl
Document and add the clock drivers for GCC, CAMCC, DISPCC, GPUCC and
VIDEOCC on the SM7635 SoC.
Signed-off-by: Luca Weiss
---
Luca Weiss (10):
dt-bindings: clock: qcom: document the SM7635 Global Clock Controller
clk: qcom: Add Global Clock controller (GCC) driver for SM7635
dt-
This patch series fixes a number of bugs in the cpuset partition code as
well as improvement in remote partition handling. The test_cpuset_prs.sh
is also enhanced to allow more vigorous remote partition testing.
Waiman Long (10):
cgroup/cpuset: Fix race between newly created partition and dying
On Fri, Oct 11, 2024 at 03:09:08PM +0200, Krzysztof Kozlowski wrote:
> Simplify drivers in few places around probe function.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (10):
> remoteproc: da8xx: Handle deferred probe
> remoteproc: da8xx: Simplify with dev_err_probe()
Simplify drivers in few places around probe function.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (10):
remoteproc: da8xx: Handle deferred probe
remoteproc: da8xx: Simplify with dev_err_probe()
remoteproc: ti_k3_r5: Simplify with dev_err_probe()
remoteproc: ti_k3_r5: S
This is a preliminary clean up for TDX which complicates KVM page fault
execution path. simplify those execution path as preparation.
The current kvm page fault handlers passes around many arguments to the
functions.
To simplify those arguments and local variables, introduce data structure,
struct
Some Acks from RT people are still missing that I'd like to have before
trying to merge this via Andrew's tree and there is an open question is
whether the last path in this series is worthwhile. It embeds local_lock
within the per_cpu_pages structure to clarify the scope but it increases
complexit
On Fri 16-04-21 07:26:43, Dave Hansen wrote:
> On 4/16/21 5:35 AM, Michal Hocko wrote:
> > I have to confess that I haven't grasped the initialization
> > completely. There is a nice comment explaining a 2 socket system with
> > 3 different NUMA nodes attached to it with one node being termin
On 4/16/21 5:35 AM, Michal Hocko wrote:
> I have to confess that I haven't grasped the initialization
> completely. There is a nice comment explaining a 2 socket system with
> 3 different NUMA nodes attached to it with one node being terminal.
> This is OK if the terminal node is PMEM but h
Hi,
I am really sorry to jump into this train sooo late. I have quickly
glanced through the series and I have some questions/concerns. Let me
express them here rather than in specific patches.
First of all I do think that demotion is a useful way to balance the
memory in general. And that is not r
On Fri, 19 Mar 2021 11:06:49 + (UTC), Christophe Leroy wrote:
> Similarly to the work done earlier with writes, this series
> converts signal32 to using user_read_access_begin/end and
> unsafe_get_user() and friends.
>
> Applies on to of the signal64 series, ie on merge-test (ca6e327fefb2)
>
Hi folks!
This is the spiritual successor to [1], which was over 6 years ago (!).
Background
==
GIC mechanics
+
There are three IRQ operations:
o Acknowledge. This gives us the IRQ number that interrupted us, and also
- raises the running priority of the CPU interface to t
This patchset removes all RT_TRACE usages left and definitions
The whole private tracing system is not tied to a configuration
symbol and the default behaviour is _trace nothing_. It's verbose
and relies on a private log level tracing doomed to be
removed.
The patchset consist on a first patch ap
Fix some issues reported by checkpatch.pl. All of them are
coding style issues, no function changes.
Xiaofei Tan (10):
tty/sysrq: Add a blank line after declarations
tty/sysrq: Fix issues of code indent should use tabs
tty: tty_jobctrl: Add a blank line after declarations
tty: tty_jobctrl:
I'm resending this because I forgot to cc the mailing lists on the
post yesterday. Sorry for the noise. Please reply to this series.
The full series is also available here:
https://github.com/hansendc/linux/tree/automigrate-20210331
which also inclues some vm.zone_reclaim_mode sysctl A
Hi Greg,
Here are some nvmem patches for 5.13 which includes
- adding support to new Broadcom NVRAM, MediaTek mt8192,
Qualcomm sc7280 nvmem provider
- Add new function to make numbers reading easy
- Update qfprom to support fuse blowing!
- few minor fixes.
Can you please queue them up for 5.13.
Hi,
On 3/30/21 11:22 AM, Alexandru Ardelean wrote:
> On Tue, Mar 30, 2021 at 11:21 AM Hans de Goede wrote:
>>
>> Hi Alexadru, Jonathan,
>>
>> On 3/24/21 1:55 PM, Alexandru Ardelean wrote:
>>> This changeset tries to do a conversion of the toshiba_acpi driver to use
>>> only device-managed routine
On Tue, Mar 30, 2021 at 11:21 AM Hans de Goede wrote:
>
> Hi Alexadru, Jonathan,
>
> On 3/24/21 1:55 PM, Alexandru Ardelean wrote:
> > This changeset tries to do a conversion of the toshiba_acpi driver to use
> > only device-managed routines. The driver registers as a singleton, so no
> > more tha
Hi Alexadru, Jonathan,
On 3/24/21 1:55 PM, Alexandru Ardelean wrote:
> This changeset tries to do a conversion of the toshiba_acpi driver to use
> only device-managed routines. The driver registers as a singleton, so no
> more than one device can be registered at a time.
>
> My main intent here i
From: Gao Xiang
Hi folks,
This is the formal version of EROFS big pcluster support, which means
EROFS can compress data into more than 1 fs block after this patchset.
{p,l}cluster are EROFS-specific concepts, standing for `logical cluster'
and `physical cluster' correspondingly. Logical cluster
On Mon, 29 Mar 2021 at 15:38, Jonathan Cameron wrote:
>
> On Wed, 24 Mar 2021 14:55:38 +0200
> Alexandru Ardelean wrote:
>
> > This changeset tries to do a conversion of the toshiba_acpi driver to use
> > only device-managed routines. The driver registers as a singleton, so no
> > more than one d
On Wed, 24 Mar 2021 14:55:38 +0200
Alexandru Ardelean wrote:
> This changeset tries to do a conversion of the toshiba_acpi driver to use
> only device-managed routines. The driver registers as a singleton, so no
> more than one device can be registered at a time.
>
> My main intent here is to tr
This patch series fixes trivial typos as they appear in the files.
Bhaskar Chowdhury (10):
extent-map-tests.c: A typo fix
dev-replace.c: A typo fix
ioctl.c: A typo fix
zoned.c: A typo fix
inode.c: Couple of typo fixes
scrub.c: Fix a typo
locking.c: Fix same typo in couple of places
This changeset tries to do a conversion of the toshiba_acpi driver to use
only device-managed routines. The driver registers as a singleton, so no
more than one device can be registered at a time.
My main intent here is to try to convert the iio_device_alloc() and
iio_device_register() to their de
Similarly to the work done earlier with writes, this series
converts signal32 to using user_read_access_begin/end and
unsafe_get_user() and friends.
Applies on to of the signal64 series, ie on merge-test (ca6e327fefb2)
Christophe Leroy (10):
signal: Add unsafe_get_compat_sigset()
powerpc/uacc
On Tue, 16 Mar 2021 19:14:33 +0800, Seiya Wang wrote:
> MT8195 is a SoC based on 64bit ARMv8 architecture.
> It contains 4 CA55 and 4 CA78 cores.
> MT8195 share many HW IP with MT65xx series.
> This patchset was tested on MT8195 evaluation board to shell.
>
> Based on v5.12-rc2
>
> [...]
Applied
MT8195 is a SoC based on 64bit ARMv8 architecture.
It contains 4 CA55 and 4 CA78 cores.
MT8195 share many HW IP with MT65xx series.
This patchset was tested on MT8195 evaluation board to shell.
Based on v5.12-rc2
Seiya Wang (10):
dt-bindings: timer: Add compatible for Mediatek MT8195
dt-bin
On 15/3/21 2:11 pm, Kalle Valo wrote:
> Lukas Bulwahn writes:
>
>> On Sun, Mar 14, 2021 at 9:18 PM Aditya Srivastava
>> wrote:
>>>
>>> The opening comment mark '/**' is used for highlighting the beginning of
>>> kernel-doc comments.
>>> There are files in drivers/net/wireless/rsi which follow t
Lukas Bulwahn writes:
> On Sun, Mar 14, 2021 at 9:18 PM Aditya Srivastava
> wrote:
>>
>> The opening comment mark '/**' is used for highlighting the beginning of
>> kernel-doc comments.
>> There are files in drivers/net/wireless/rsi which follow this syntax in
>> their file headers, i.e. start
On Sun, Mar 14, 2021 at 9:18 PM Aditya Srivastava wrote:
>
> The opening comment mark '/**' is used for highlighting the beginning of
> kernel-doc comments.
> There are files in drivers/net/wireless/rsi which follow this syntax in
> their file headers, i.e. start with '/**' like comments, which ca
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
There are files in drivers/net/wireless/rsi which follow this syntax in
their file headers, i.e. start with '/**' like comments, which causes
unexpected warnings from kernel-doc.
E.g., running scripts/ker
On Mon, 8 Mar 2021 16:54:52 +0200, Alexandru Ardelean wrote:
> A while back I started the introduction of the 'spi_delay' data type:
>
> https://lore.kernel.org/linux-spi/20190926105147.7839-1-alexandru.ardel...@analog.com/
>
> Users of the 'delay_usecs' were removed from drivers.
>
> Now it's
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (10):
of: device: Fix function name in header and demote kernel-doc abuse
of: dynamic: Fix incorrect parameter name and demote kernel-
Various updates for the timer/nohz side.
* Two fixes (maybe 01/10 deserves a stable tag, I should check)
* A Kconfig help change
* A debug check while enqueuing timers when the tick is stopped in idle.
* The rest is noise reduction for full nohz ("tick/nohz: Kick only
_queued_ task whose tic
Current version of the driver fails to pass v4l2-compliance v1.20.0,
lets patch it it so some million cameras are compliant.
Ricardo Ribalda (10):
media: uvcvideo: Return -EINVAL for REQUEST API
media: uvcvideo: Set capability in s_param
media: uvcvideo: Return -EIO for control errors
medi
...
>> == Open Issues ==
>>
>> * For cpusets and memory policies that restrict allocations
>>to PMEM, is it OK to demote to PMEM? Do we need a cgroup-
>>level API to opt-in or opt-out of these migrations?
>
> I'm wondering if such usecases, which don't want to have memory
> allocate on p
On Thu, Mar 4, 2021 at 4:00 PM Dave Hansen wrote:
>
>
> The full series is also available here:
>
> https://github.com/hansendc/linux/tree/automigrate-20210304
>
> which also inclues some vm.zone_reclaim_mode sysctl ABI fixup
> prerequisites.
>
> The meat of this patch is in:
>
> [
From: Krzysztof Kozlowski
Hi Dinh, Arnd and Olof,
This is just a resend of previous patch.
Best regards,
Krzysztof
Krzysztof Kozlowski (10):
dt-bindings: arm: intel,keembay: limit the dtschema to root node
arm64: dts: intel: socfpga: override clocks by label
arm64: dts: intel: socfpga_ag
On Mon, Mar 08, 2021 at 05:22:18PM +0100, Krzysztof Kozlowski wrote:
> Hi Arnd and Olof,
>
> This is just a resend of previous patch. Since I did not get replies
> from Intel maintainers, I assume this could go via soc tree directly.
Actually it is my bad because I think I skipped Dinh Nguyen. Le
On Mon, 2021-03-08 at 17:22 +0100, Krzysztof Kozlowski wrote:
> Hi Arnd and Olof,
>
> This is just a resend of previous patch. Since I did not get replies
> from Intel maintainers, I assume this could go via soc tree directly.
I think the to/cc list is missing Dinh, the socfpga maintainer:
Dinh N
A while back I started the introduction of the 'spi_delay' data type:
https://lore.kernel.org/linux-spi/20190926105147.7839-1-alexandru.ardel...@analog.com/
Users of the 'delay_usecs' were removed from drivers.
Now it's time to remove the 'delay_usecs' from the SPI subsystem and use
only the '
The full series is also available here:
https://github.com/hansendc/linux/tree/automigrate-20210304
which also inclues some vm.zone_reclaim_mode sysctl ABI fixup
prerequisites.
The meat of this patch is in:
[PATCH 05/10] mm/migrate: demote pages during reclaim
Which also has
nice ping :-)
On Tue, Feb 16, 2021 at 10:44:44AM +0100, Stefano Garzarella wrote:
Following the discussion with Michael and Jason [1], I reworked a bit
get/set_config() in vdpa.
I changed vdpa_get_config() to check the boundaries and added vdpa_set_config().
When 'offset' or 'len' parameters ex
On Mon, Feb 22, 2021 at 09:50:22AM -0700, Alex Williamson wrote:
> This is a re-implementation of [1] following suggestions and code from
> Jason Gunthorpe. This is lightly tested but seems functional and
> throws no lockdep warnings. In this series we tremendously simplify
> zapping of vmas mapp
This is a re-implementation of [1] following suggestions and code from
Jason Gunthorpe. This is lightly tested but seems functional and
throws no lockdep warnings. In this series we tremendously simplify
zapping of vmas mapping device memory using unmap_mapping_range(), we
create a protocol for l
Following the discussion with Michael and Jason [1], I reworked a bit
get/set_config() in vdpa.
I changed vdpa_get_config() to check the boundaries and added vdpa_set_config().
When 'offset' or 'len' parameters exceed boundaries, we limit the reading to
the available configuration space in the dev
To support Linux guests on Hyper-V on multiple architectures, the original
approach factored out all differences between Hyper-V on x86/x64 and
Hyper-V on ARM64 into functions or #defines under arch/x86 and
arch/arm64. Some of these differences are truly related to the
architecture, but others are
On Thu, Jan 21, 2021 at 11:29:11AM +0100, Johan Hovold wrote:
> This series fixes the remaining issues in the new MaxLinear driver that
> were pointed out here:
>
> https://lore.kernel.org/r/yalvloqzx8otp...@hovoldconsulting.com
> Johan Hovold (10):
> USB: serial: xr: fix NULL-deref at pr
This series fixes the remaining issues in the new MaxLinear driver that
were pointed out here:
https://lore.kernel.org/r/yalvloqzx8otp...@hovoldconsulting.com
Johan
Johan Hovold (10):
USB: serial: xr: fix NULL-deref at probe
USB: serial: xr: fix interface leak at disconnect
USB: s
On 1/19/21 11:41 AM, Jonathan Cameron wrote:
> On Tue, 19 Jan 2021 18:17:05 +0900
> William Breathitt Gray wrote:
>
>> On Sun, Jan 17, 2021 at 03:42:18PM +, Jonathan Cameron wrote:
>>> On Fri, 15 Jan 2021 13:47:20 +
>>> Jonathan Cameron wrote:
>>>
On Fri, 15 Jan 2021 10:49:47 +01
On Tue, 19 Jan 2021 18:17:05 +0900
William Breathitt Gray wrote:
> On Sun, Jan 17, 2021 at 03:42:18PM +, Jonathan Cameron wrote:
> > On Fri, 15 Jan 2021 13:47:20 +
> > Jonathan Cameron wrote:
> >
> > > On Fri, 15 Jan 2021 10:49:47 +0100
> > > Mauro Carvalho Chehab wrote:
> > >
> >
On Sun, Jan 17, 2021 at 03:42:18PM +, Jonathan Cameron wrote:
> On Fri, 15 Jan 2021 13:47:20 +
> Jonathan Cameron wrote:
>
> > On Fri, 15 Jan 2021 10:49:47 +0100
> > Mauro Carvalho Chehab wrote:
> >
> > > Hi Lukas,
> > >
> > > Em Fri, 15 Jan 2021 07:12:38 +0100
> > > Lukas Bulwahn esc
On Fri, 15 Jan 2021 13:47:20 +
Jonathan Cameron wrote:
> On Fri, 15 Jan 2021 10:49:47 +0100
> Mauro Carvalho Chehab wrote:
>
> > Hi Lukas,
> >
> > Em Fri, 15 Jan 2021 07:12:38 +0100
> > Lukas Bulwahn escreveu:
> >
> > > [reduced the recipient list to the main responsible ones and list]
On Fri, 15 Jan 2021 07:12:38 +0100
Lukas Bulwahn wrote:
> We both, Mauro and I, have been submitting patches to address the
> documentation warnings on linux-next. If it is okay with you, Mauro, I
> would like to take responsibility for the task to send out the patches
> to address all warnings o
On Fri, 15 Jan 2021 10:49:47 +0100
Mauro Carvalho Chehab wrote:
> Hi Lukas,
>
> Em Fri, 15 Jan 2021 07:12:38 +0100
> Lukas Bulwahn escreveu:
>
> > [reduced the recipient list to the main responsible ones and list]
> >
> > Hi Mauro, hi Jonathan,
> >
> > We both, Mauro and I, have been submitt
Em Fri, 15 Jan 2021 13:05:56 +0100
Lukas Bulwahn escreveu:
> On Fri, Jan 15, 2021 at 10:49 AM Mauro Carvalho Chehab
> wrote:
> >
> > Hi Lukas,
> >
> > Em Fri, 15 Jan 2021 07:12:38 +0100
> > Lukas Bulwahn escreveu:
> >
> > > [reduced the recipient list to the main responsible ones and list]
>
Em Fri, 15 Jan 2021 13:36:23 +0100
Mauro Carvalho Chehab escreveu:
> Em Fri, 15 Jan 2021 13:05:56 +0100
> Lukas Bulwahn escreveu:
>
> > On Fri, Jan 15, 2021 at 10:49 AM Mauro Carvalho Chehab
> > wrote:
> > >
> > > Hi Lukas,
> > >
> > > Em Fri, 15 Jan 2021 07:12:38 +0100
> > > Lukas Bulwahn
On Fri, Jan 15, 2021 at 10:49 AM Mauro Carvalho Chehab
wrote:
>
> Hi Lukas,
>
> Em Fri, 15 Jan 2021 07:12:38 +0100
> Lukas Bulwahn escreveu:
>
> > [reduced the recipient list to the main responsible ones and list]
> >
> > Hi Mauro, hi Jonathan,
> >
> > We both, Mauro and I, have been submitting p
Hi Lukas,
Em Fri, 15 Jan 2021 07:12:38 +0100
Lukas Bulwahn escreveu:
> [reduced the recipient list to the main responsible ones and list]
>
> Hi Mauro, hi Jonathan,
>
> We both, Mauro and I, have been submitting patches to address the
> documentation warnings on linux-next. If it is okay with
[reduced the recipient list to the main responsible ones and list]
Hi Mauro, hi Jonathan,
We both, Mauro and I, have been submitting patches to address the
documentation warnings on linux-next. If it is okay with you, Mauro, I
would like to take responsibility for the task to send out the patches
This series fixes the documentation warnings found at next-20210114.
Most of the changes here are trivial.
While those patches could be merged via the docs tree during
the next merge window, It sounds better to have those patches
merged directly via each maintainer's tree, where the new
warning
On Tue, 5 Jan 2021 15:02:45 +0100, Thomas Bogendoerfer wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
>
> I've split up the removal into seperate parts for different
Hi Nemoto-san,
On Thu, Jan 7, 2021 at 2:18 AM Atsushi Nemoto wrote:
> On Wed, 6 Jan 2021 21:41:24 +0100, Geert Uytterhoeven
> wrote:
> >> > Is that sufficient to keep it?
> >>
> >> for me it is. But now we probaly need some reverts then...
> >
> > Indeed. Fortunately not all of it, as some remo
On Wed, 6 Jan 2021 21:41:24 +0100, Geert Uytterhoeven
wrote:
>> > Is that sufficient to keep it?
>>
>> for me it is. But now we probaly need some reverts then...
>
> Indeed. Fortunately not all of it, as some removals were TX4938-only.
These patches should not break RBTX4927:
net: tc35815: D
Hi Thomas,
On Wed, Jan 6, 2021 at 7:49 PM Thomas Bogendoerfer
wrote:
> On Wed, Jan 06, 2021 at 09:37:11AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> > wrote:
> > > I couldn't find any buyable product other than reference boards using
> > > TX49xx CP
On Wed, Jan 06, 2021 at 09:37:11AM +0100, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> CC Nemoto-san (de-facto TX49XX maintainer)
>
> On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> wrote:
> > I couldn't find any buyable product other than reference boards using
> > TX49xx CPUs. And since nob
Hi Geert!
On Wed, 6 Jan 2021 09:37:11 +0100, Geert Uytterhoeven
wrote:
> Hi Thomas,
>
> CC Nemoto-san (de-facto TX49XX maintainer)
>
> On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> wrote:
>> I couldn't find any buyable product other than reference boards using
>> TX49xx CPUs. And since
On Tue, 5 Jan 2021 15:02:45 +0100, Thomas Bogendoerfer wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
>
> I've split up the removal into seperate parts for different
Hi Thomas,
CC Nemoto-san (de-facto TX49XX maintainer)
On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
I have an
On Tue, 5 Jan 2021 15:02:45 +0100, Thomas Bogendoerfer wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
>
> I've split up the removal into seperate parts for different
I couldn't find any buyable product other than reference boards using
TX49xx CPUs. And since nobody showed interest in keeping support for
it, it's time to remove it.
I've split up the removal into seperate parts for different maintainers.
So if the patch fits your needs, please take it via your t
在 2020/12/31 下午5:22, Greg Kroah-Hartman 写道:
On Thu, Dec 17, 2020 at 10:26:23AM +0800, Wen Yang wrote:
在 2020/12/4 上午2:31, Wen Yang 写道:
The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag, they
should be deleted when the process exits.
Suppose the following race appears：
releas
On Thu, Dec 17, 2020 at 10:26:23AM +0800, Wen Yang wrote:
>
>
> 在 2020/12/4 上午2:31, Wen Yang 写道:
> > The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag, they
> > should be deleted when the process exits.
> >
> > Suppose the following race appears：
> >
> > release_task
This patchset is aimed to support shared pages tracking for fsdax.
Change from RFC v3:
- Do not lock dax entry in memory failure handler
- Add a helper function for corrupted_range
- Add restrictions in xfs code
- Fix code style
- remove the useless association and lock in fsdax
Change
在 2020/12/4 上午2:31, Wen Yang 写道:
The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag, they
should be deleted when the process exits.
Suppose the following race appears：
release_task dput
-> proc_flush_task
-> dentry->d_op->d_delete(den
On Mon, Dec 14, 2020 at 11:54:47PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan
>
> 06249738a41a ("workqueue: Manually break affinity on hotplug")
> said that scheduler will not force break affinity for us.
>
> But workqueue highly depends on the old behavior. Many parts of the codes
> reli
On Tue, Dec 15, 2020 at 4:49 PM Peter Zijlstra wrote:
>
> On Tue, Dec 15, 2020 at 04:14:26PM +0800, Lai Jiangshan wrote:
> > On Tue, Dec 15, 2020 at 3:50 PM Peter Zijlstra wrote:
> > >
> > > On Tue, Dec 15, 2020 at 01:44:53PM +0800, Lai Jiangshan wrote:
> > > > I don't know how the scheduler dist
On Tue, Dec 15, 2020 at 04:14:26PM +0800, Lai Jiangshan wrote:
> On Tue, Dec 15, 2020 at 3:50 PM Peter Zijlstra wrote:
> >
> > On Tue, Dec 15, 2020 at 01:44:53PM +0800, Lai Jiangshan wrote:
> > > I don't know how the scheduler distinguishes all these
> > > different cases under the "new assumption
On Tue, Dec 15, 2020 at 3:50 PM Peter Zijlstra wrote:
>
> On Tue, Dec 15, 2020 at 01:44:53PM +0800, Lai Jiangshan wrote:
> > I don't know how the scheduler distinguishes all these
> > different cases under the "new assumption".
>
> The special case is:
>
> (p->flags & PF_KTHREAD) && p->nr_cpus_a
On Tue, Dec 15, 2020 at 01:44:53PM +0800, Lai Jiangshan wrote:
> I don't know how the scheduler distinguishes all these
> different cases under the "new assumption".
The special case is:
(p->flags & PF_KTHREAD) && p->nr_cpus_allowed == 1
On Tue, Dec 15, 2020 at 1:36 AM Peter Zijlstra wrote:
>
> On Mon, Dec 14, 2020 at 11:54:47PM +0800, Lai Jiangshan wrote:
> > From: Lai Jiangshan
> >
> > 06249738a41a ("workqueue: Manually break affinity on hotplug")
> > said that scheduler will not force break affinity for us.
> >
> > But workque
On Mon, Dec 14, 2020 at 11:54:47PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan
>
> 06249738a41a ("workqueue: Manually break affinity on hotplug")
> said that scheduler will not force break affinity for us.
>
> But workqueue highly depends on the old behavior. Many parts of the codes
> reli
From: Lai Jiangshan
06249738a41a ("workqueue: Manually break affinity on hotplug")
said that scheduler will not force break affinity for us.
But workqueue highly depends on the old behavior. Many parts of the codes
relies on it, 06249738a41a ("workqueue: Manually break affinity on hotplug")
is n
The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag, they
should be deleted when the process exits.
Suppose the following race appears???
release_task?? dput
-> proc_flush_task
->??dentry->d_op->d
This is an early prototype that has not been tested heavily. While parts
of it may stand on its own, the motivation to release early is Aubrey
Li's series on using an idle cpumask to optimise the search and Barry
Song's series on representing clusters on die. The series is based on
tip/sched/core r
This is the initial series to support Engicam i.Core MX8M Mini SOM
and it's associated carrier board dts(i) support.
Add minimal changes to access and boot SD, eMMC, and the rest of
the changes added in the coming days.
i.Core MX8M Mini is an EDIMM SOM based on NXP i.MX8MM from Engicam.
i.Core
This patchset introduces the devm_fpga_mgr_register API,
a devres managed version of fpga_mgr_register().
It reduces boilerplate being repeated literally in every
single driver by moving it to the fpga-mgr core.
Moritz Fischer (10):
fpga: fpga-mgr: Add devm_fpga_mgr_register() API
fpga: fpga-
On Fri, Nov 13 2020 at 22:29, Gabriel Krisman Bertazi wrote:
> This a refactor work moving the work done by features like seccomp,
> ptrace, audit and tracepoints out of the TI flags. The reasons are:
>
>1) Scarcity of TI flags in x86 32-bit.
>
>2) TI flags are defined by the architecture,
Thomas,
This a refactor work moving the work done by features like seccomp,
ptrace, audit and tracepoints out of the TI flags. The reasons are:
1) Scarcity of TI flags in x86 32-bit.
2) TI flags are defined by the architecture, while these features are
arch-independent.
3) Communit
Hi,
This patch series fixes the various Broadcom SoCs DTS files and the
existing YAML binding for missing properties before adding a proper b53
switch YAML binding from Kurt.
If this all looks good, given that there are quite a few changes to the
DTS files, it might be best if I take them through
Here's a set of fixes for AFS:
(1) Fix copy_file_range() to an afs file now returning EINVAL if the
splice_write file op isn't supplied.
(2) Fix a deref-before-check in afs_unuse_cell().
(3) Fix a use-after-free in afs_xattr_get_acl().
(4) Fix afs to not try to clear PG_writeback whe
1 - 100 of 1136 matches
Mail list logo
