On Mon, Aug 04, 2025 at 04:37:56AM +0100, Matthew Wilcox wrote:
> On Sun, Aug 03, 2025 at 12:59:06PM -0300, Jason Gunthorpe wrote:
> > Matthew, do you think it makes sense to introduce types to make this
> > clearer? We have two kinds of values that a phys_addr_t can store -
> > something compatibl
On Sun, Aug 03, 2025 at 12:59:06PM -0300, Jason Gunthorpe wrote:
> Matthew, do you think it makes sense to introduce types to make this
> clearer? We have two kinds of values that a phys_addr_t can store -
> something compatible with kmap_XX_phys(), and something that isn't.
I was with you up unti
On Thu, Jul 31, 2025 at 06:37:11PM +0100, Matthew Wilcox wrote:
> The replacement for kmap_atomic() is already here -- it's
> kmap_(atomic|local)_pfn(). If a simple wrapper like kmap_local_phys()
> would make this more palatable, that would be fine by me. Might save
> a bit of messing around wit
Hi Robin,
I don't know the DMA mapping code well and haven't reviewed this
patch set in particular, but I wanted to comment on some of the things
you say here.
> Marek, I'm surprised that even you aren't seeing why that would at best be
> pointless churn. The fundamental design of dma_map_page()
On Wed, Jul 30, 2025 at 11:28:18AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 30, 2025 at 04:40:26PM +0300, Leon Romanovsky wrote:
<...>
> > The most reasonable way to prevent DMA_ATTR_SKIP_CPU_SYNC leakage is to
> > introduce new DMA attribute (let's call it DMA_ATTR_MMIO for now) and
> > pass
On 30.07.2025 13:11, Robin Murphy wrote:
> On 2025-07-08 11:27 am, Marek Szyprowski wrote:
>> On 30.06.2025 15:38, Christoph Hellwig wrote:
>>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> Thanks for this rework! I assume that the next step is to add
> map_phys
>
On Wed, Jul 30, 2025 at 04:40:26PM +0300, Leon Romanovsky wrote:
> > The natural working unit for whatever replaces dma_map_page() will be
> > whatever the replacement for alloc_pages() returns, and the replacement for
> > kmap_atomic() operates on. Until that exists (and I simply cannot believe i
On Wed, Jul 30, 2025 at 12:11:32PM +0100, Robin Murphy wrote:
> On 2025-07-08 11:27 am, Marek Szyprowski wrote:
> > On 30.06.2025 15:38, Christoph Hellwig wrote:
> > > On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> > > > > Thanks for this rework! I assume that the next step is t
On 2025-07-08 11:27 am, Marek Szyprowski wrote:
On 30.06.2025 15:38, Christoph Hellwig wrote:
On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
Thanks for this rework! I assume that the next step is to add map_phys
callback also to the dma_map_ops and teach various dma-mapping pr
On Fri, Jul 25, 2025 at 09:05:46PM +0100, Robin Murphy wrote:
> But given what we do already know of from decades of experience, obvious
> question: For the tiny minority of users who know full well when they're
> dealing with a non-page-backed physical address, what's wrong with using
> dma_map_r
On 2025-06-25 2:18 pm, Leon Romanovsky wrote:
This series refactors the DMA mapping to use physical addresses
as the primary interface instead of page+offset parameters. This
change aligns the DMA API with the underlying hardware reality where
DMA operations work with physical addresses, not page
On 08.07.2025 14:56, Marek Szyprowski wrote:
> On 08.07.2025 14:06, Leon Romanovsky wrote:
>> On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote:
>>> On 08.07.2025 13:00, Leon Romanovsky wrote:
On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
> On 30.06.2025
On 08.07.2025 14:06, Leon Romanovsky wrote:
> On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote:
>> On 08.07.2025 13:00, Leon Romanovsky wrote:
>>> On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
On 30.06.2025 15:38, Christoph Hellwig wrote:
> On Fri, Jun 2
On Tue, Jul 08, 2025 at 01:45:20PM +0200, Marek Szyprowski wrote:
> On 08.07.2025 13:00, Leon Romanovsky wrote:
> > On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
> >> On 30.06.2025 15:38, Christoph Hellwig wrote:
> >>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wr
On 08.07.2025 13:00, Leon Romanovsky wrote:
> On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
>> On 30.06.2025 15:38, Christoph Hellwig wrote:
>>> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> Thanks for this rework! I assume that the next step is to add m
On Tue, Jul 08, 2025 at 12:27:09PM +0200, Marek Szyprowski wrote:
> On 30.06.2025 15:38, Christoph Hellwig wrote:
> > On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> >>> Thanks for this rework! I assume that the next step is to add map_phys
> >>> callback also to the dma_map_ops
On 30.06.2025 15:38, Christoph Hellwig wrote:
> On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
>>> Thanks for this rework! I assume that the next step is to add map_phys
>>> callback also to the dma_map_ops and teach various dma-mapping providers
>>> to use it to avoid more phys-t
On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> On Fri, Jun 27, 2025 at 03:44:10PM +0200, Marek Szyprowski wrote:
> > On 25.06.2025 15:18, Leon Romanovsky wrote:
> > > This series refactors the DMA mapping to use physical addresses
> > > as the primary interface instead of page+o
On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote:
> > Thanks for this rework! I assume that the next step is to add map_phys
> > callback also to the dma_map_ops and teach various dma-mapping providers
> > to use it to avoid more phys-to-page-to-phys conversions.
>
> Probably Chri
On Fri, Jun 27, 2025 at 03:44:10PM +0200, Marek Szyprowski wrote:
> On 25.06.2025 15:18, Leon Romanovsky wrote:
> > This series refactors the DMA mapping to use physical addresses
> > as the primary interface instead of page+offset parameters. This
> > change aligns the DMA API with the underlying
On 25.06.2025 15:18, Leon Romanovsky wrote:
> This series refactors the DMA mapping to use physical addresses
> as the primary interface instead of page+offset parameters. This
> change aligns the DMA API with the underlying hardware reality where
> DMA operations work with physical addresses, not
On Thu, Jun 12, 2025 at 06:56:53AM +0200, Paolo Bonzini wrote:
> On 6/11/25 02:10, Sean Christopherson wrote:
> > Kill off include/kvm (through file moves/renames), and standardize the set
> > of
> > KVM includes across all architectures.
> >
> > This conflicts with Colton's partioned PMU series[
On 6/11/25 02:10, Sean Christopherson wrote:
Kill off include/kvm (through file moves/renames), and standardize the set of
KVM includes across all architectures.
This conflicts with Colton's partioned PMU series[1], but this should work as
a nice prepatory cleanup for the partitioned PMU work (a
On Wed, 28 May 2025 21:59:54 +0200, Krzysztof Kozlowski wrote:
> Make static data const for code safety and drop some unused fields in
> structs.
>
> This is based on for-v6.16 branch in ASoC tree for context in wcd938x
> driver.
>
> Best regards,
> Krzysztof
>
> [...]
Applied to
https://gi
On 5/28/25 8:59 PM, Krzysztof Kozlowski wrote:
> Make static data const for code safety and drop some unused fields in
> structs.
>
> This is based on for-v6.16 branch in ASoC tree for context in wcd938x
> driver.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (8):
> ASoC:
On 29/05/2025 11:33, Srinivas Kandagatla wrote:
>
>
> On 5/28/25 8:59 PM, Krzysztof Kozlowski wrote:
>> Make static data const for code safety and drop some unused fields in
>> structs.
>>
>> This is based on for-v6.16 branch in ASoC tree for context in wcd938x
>> driver.
>>
>> Best regards,
>> K
On Sat, Nov 25, 2023 at 03:47:41AM +0300, George Stark wrote:
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> > > Lots of drivers use devm_led_classdev_register() to register their led
> > > objects
> > > and let the kernel free those
On Sat, 25 Nov 2023 03:47:41 +0300
George Stark wrote:
> Hello Andy
>
> Thanks for the review.
>
> On 11/24/23 18:28, Andy Shevchenko wrote:
> > On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> >> Lots of drivers use devm_led_classdev_register() to register their led
> >> obje
Hello Andy
Thanks for the review.
On 11/24/23 18:28, Andy Shevchenko wrote:
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the kernel free those leds at the driver's remove stage.
It can lead
On Wed, Oct 25, 2023 at 04:07:29PM +0300, George Stark wrote:
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_se
On Sat, Nov 4, 2023 at 9:17 AM George Stark wrote:
>
> Hello Andy
>
> Could you please take a look at this patch series?
>
> I've just found your post on habr about devres API misusing and I think
> this is just another case.
Just had a look, sorry for the delay.
By quickly reading it seems to be
Le 10/11/2023 à 02:38, Daniel Walker a écrit :
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a number of peop
On Fri, 10 Nov 2023 02:22:27 + "Daniel Walker (danielwa)"
wrote:
> On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> > On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> >
> > > This release is an up-rev of the v5 patches. No additional features have
> > > been added.
On Thu, Nov 09, 2023 at 05:51:42PM -0800, Andrew Morton wrote:
> On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
>
> > This release is an up-rev of the v5 patches. No additional features have
> > been added. Some changes were mode to function names and some changes to
> > Kconfig dependen
On Thu, 9 Nov 2023 17:38:04 -0800 Daniel Walker wrote:
> This release is an up-rev of the v5 patches. No additional features have
> been added. Some changes were mode to function names and some changes to
> Kconfig dependencies. Also updated the config conversion for mips.
>
> There are a numbe
Le 25/10/2023 à 15:07, George Stark a écrit :
> Lots of drivers use devm_led_classdev_register() to register their led objects
> and let the kernel free those leds at the driver's remove stage.
> It can lead to a problem due to led_classdev_unregister()
> implementation calls led_set_brightness()
Hello Andy
Could you please take a look at this patch series?
I've just found your post on habr about devres API misusing and I think
this is just another case.
On 10/25/23 16:07, George Stark wrote:
Lots of drivers use devm_led_classdev_register() to register their led objects
and let the k
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change sy
On Mon, Sep 26, 2022 at 05:52:18PM -0500, Rob Herring wrote:
> On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
> wrote:
> >
> > On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> > [snip]
> > > > As recently as last mon
On Thu, Sep 22, 2022 at 02:15:44PM -0700, Daniel Gimpelevich wrote:
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this
On Thu, Sep 22, 2022 at 4:15 PM Daniel Gimpelevich
wrote:
>
> On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
> [snip]
> > > As recently as last month, someone's patch to add such support was
> > > rejected for this reason
On Thu, 2022-09-22 at 14:10 -0700, Daniel Walker wrote:
> On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
[snip]
> > As recently as last month, someone's patch to add such support was
> > rejected for this reason [1].
> >
> > --Sean
> >
> > [1]
> > https://lore.kernel.org/linux-ar
On Thu, Sep 22, 2022 at 05:03:46PM -0400, Sean Anderson wrote:
>
>
>
> On 9/22/22 4:53 PM, Daniel Walker wrote:
> > On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
> >>
> >>
> >>
> >> For an arm64 platform (after rebasing):
> >>
> >> Tested-by: Sean Anderson
> >
> > Maybe I'
On 9/22/22 4:53 PM, Daniel Walker wrote:
> On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
>>
>>
>>
>> For an arm64 platform (after rebasing):
>>
>> Tested-by: Sean Anderson
>
> Maybe I'll re-submit it.
>
> Daniel
>
There's still no way to extend the command line on ARM6
On Thu, Sep 22, 2022 at 04:45:01PM -0400, Sean Anderson wrote:
>
>
>
> For an arm64 platform (after rebasing):
>
> Tested-by: Sean Anderson
Maybe I'll re-submit it.
Daniel
On 4/16/21 12:09 AM, Daniel Walker wrote:
>
> v4 release changes
>
> * Updated insert-sys-cert tool to change command line symbols after
> compilation.
>
> This tool is used to release binary kernels internally to companies
> and then later insert certificates for each product b
Le 24/11/2021 à 14:40, Christophe Leroy a écrit :
Le 24/11/2021 à 14:21, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only whe
Le 24/11/2021 à 14:21, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
This series converts powerpc to default topdown mmap layout.
powerpc provides its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. Fir
Excerpts from Christophe Leroy's message of November 22, 2021 6:48 pm:
> This series converts powerpc to default topdown mmap layout.
>
> powerpc provides its own arch_get_unmapped_area() only when
> slices are needed, which is only for book3s/64. First part of
> the series moves slices into book3
On Thu, May 13, 2021 at 12:02:54PM +0200, Juergen Gross wrote:
> Xen backends of para-virtualized devices can live in dom0 kernel, dom0
> user land, or in a driver domain. This means that a backend might
> reside in a less trusted environment than the Xen core components, so
> a backend should not
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
>
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
>
On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
>
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
>
On Thu, 26 Nov 2020 13:38:45 + Lee Jones wrote:
> Resending the stragglers.
>
> 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.
This set doesn't apply to net-next, please rebase.
> > > >
> > > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > > API")' introduced a new tasklet initialization API. This series
> > > > converts all the scsi drivers to use the new tasklet_setup() API
> > >
> > > I've got to say I agree with Jens, this was a silly obfuscation:
>
On Mon, 2020-08-17 at 12:28 -0700, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > > From: Allen Pais
> > >
> > > Commit 12cc923f1ccc ("tasklet: Introduce new initialization
> > > API")' introduced a
On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> From: Allen Pais
>
> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> introduced a new tasklet initialization API. This series converts
> all the scsi drivers to use the new tasklet_setup() API
I've got to say I agree wi
On Mon, Aug 17, 2020 at 07:41:58AM -0700, James Bottomley wrote:
> On Mon, 2020-08-17 at 14:24 +0530, Allen Pais wrote:
> > From: Allen Pais
> >
> > Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")'
> > introduced a new tasklet initialization API. This series converts
> > all th
On Sun, 31 May 2020 09:17:03 +1000, Finn Thain wrote:
> The adb-iop driver was never finished. Some deficiencies have become
> apparent over the years. For example,
>
> - Mouse and/or keyboard may stop working if used together
>
> - SRQ autopoll list cannot be changed
>
> [...]
Applied to pow
Gentle ping.
On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> Bolarinwa Olayemi Saheed (8):
> IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors
> IB/hfi1: Convert PCIBIOS_* errors to generic -E* errors
Applied to rdma for-next thanks
Jason
On Sat, Jun 27, 2020 at 5:35 PM Mike Rapoport wrote:
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
> and enable use of the generic functions where
> appropri
On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote:
> Most architectures have very similar versions of pXd_alloc_one() and
> pXd_free_one() for intermediate levels of page table.
> These patches add generic versions of these functions in
> and enable use of the generic functions where
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> From: Bolarinwa Olayemi Saheed
>
>
> PATCH 1/8 to 7/8:
> PCIBIOS_ error codes have positive values and they are passed down the
> call heirarchy from accessors. For functions which are meant to return
> only a negative v
On Mon, Jun 15, 2020 at 09:32:17AM +0200, refactormys...@gmail.com wrote:
> From: Bolarinwa Olayemi Saheed
>
>
> PATCH 1/8 to 7/8:
> PCIBIOS_ error codes have positive values and they are passed down the
> call heirarchy from accessors. For functions which are meant to return
> only a negative v
On 4/16/20 8:59 AM, Luis Chamberlain wrote:
On Tue, Apr 14, 2020 at 02:42:54PM +0200, Emanuele Giuseppe Esposito wrote:
This series of patches introduce wrappers for functions,
arguments simplification in functions calls and most importantly
groups duplicated code in a single header, simplefs
On Tue, Apr 14, 2020 at 02:42:54PM +0200, Emanuele Giuseppe Esposito wrote:
> This series of patches introduce wrappers for functions,
> arguments simplification in functions calls and most importantly
> groups duplicated code in a single header, simplefs, to avoid redundancy
> in the linux fs, esp
On 04/14/2019 08:41 PM, Sam Bobroff wrote:
> On Thu, Apr 11, 2019 at 05:55:33PM -0700, Tyrel Datwyler wrote:
>> On 03/19/2019 07:58 PM, Sam Bobroff wrote:
>>> Hi all,
>>>
>>> This patch set adds support for EEH recovery of hot plugged devices on
>>> pSeries
>>> machines. Specifically, devices disc
On Thu, Apr 11, 2019 at 05:55:33PM -0700, Tyrel Datwyler wrote:
> On 03/19/2019 07:58 PM, Sam Bobroff wrote:
> > Hi all,
> >
> > This patch set adds support for EEH recovery of hot plugged devices on
> > pSeries
> > machines. Specifically, devices discovered by PCI rescanning using
> > /sys/bus/p
On 03/19/2019 07:58 PM, Sam Bobroff wrote:
> Hi all,
>
> This patch set adds support for EEH recovery of hot plugged devices on pSeries
> machines. Specifically, devices discovered by PCI rescanning using
> /sys/bus/pci/rescan, which includes devices hotplugged by QEMU's device_add
> command. (pSe
On Fri, 2018-12-07 at 14:43 +1100, Suraj Jitindar Singh wrote:
> This patch series allows for emulated devices to be passed through to
> nested
> guests, irrespective of at which level the device is being emulated.
>
> Note that the emulated device must be using dma, not virtio.
>
> For example,
On Mon, Oct 29, 2018 at 10:29:15AM +, Will Deacon wrote:
> On Wed, Oct 24, 2018 at 10:07:32AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote:
> > > Do you mean, that you haven't seen patch for ARM, which I sent on
> > > September 27 alon
On Wed, Oct 24, 2018 at 10:07:32AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote:
> > Do you mean, that you haven't seen patch for ARM, which I sent on
> > September 27 along with cover and patch 1? It is strange, because
> > you was the one
On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote:
> Do you mean, that you haven't seen patch for ARM, which I sent on
> September 27 along with cover and patch 1? It is strange, because
> you was the one from recipients. If so, you can see this patch here:
> https://lore.kernel.org/pat
Do you mean, that you haven't seen patch for ARM, which I sent on
September 27 along with cover and patch 1? It is strange, because
you was the one from recipients. If so, you can see this patch here:
https://lore.kernel.org/patchwork/patch/992779/
On Tue, Oct 23, 2018 at 5:48 PM Russell King - ARM
On Tue, Oct 23, 2018 at 05:43:18PM +0300, Maksym Kokhan wrote:
> We still have no response to patches for x86, arm, arm64 and powerpc.
> Is current generic command line implementation appropriate for these
> architectures?
> Is it possible to merge these patches in the current form (for x86,
> arm,
On Mon, Oct 8, 2018 at 9:01 PM Maksym Kokhan
wrote:
>
> Hi, Daniel
>
> On Sat, Sep 29, 2018 at 9:17 PM wrote:
> >
> > On Thu, Sep 27, 2018 at 07:55:08PM +0300, Maksym Kokhan wrote:
> > > Daniel Walker (7):
> > > add generic builtin command line
> > > drivers: of: ifdef out cmdline section
> >
Hi, Daniel
On Sat, Sep 29, 2018 at 9:17 PM wrote:
>
> On Thu, Sep 27, 2018 at 07:55:08PM +0300, Maksym Kokhan wrote:
> > Daniel Walker (7):
> > add generic builtin command line
> > drivers: of: ifdef out cmdline section
> > x86: convert to generic builtin command line
> > arm: convert to
On Thu, Sep 27, 2018 at 07:55:08PM +0300, Maksym Kokhan wrote:
> Daniel Walker (7):
> add generic builtin command line
> drivers: of: ifdef out cmdline section
> x86: convert to generic builtin command line
> arm: convert to generic builtin command line
> arm64: convert to generic builtin
On 09/27/2018 10:05 AM, Ard Biesheuvel wrote:
On 27 September 2018 at 18:55, Maksym Kokhan
wrote:
There were series of patches [1] for 4.3.0-rc3, that allowed
architectures to use a generic builtin command line. I have rebased
these patches on kernel 4.19.0-rc4.
Could you please elaborate on
On 27 September 2018 at 18:55, Maksym Kokhan
wrote:
> There were series of patches [1] for 4.3.0-rc3, that allowed
> architectures to use a generic builtin command line. I have rebased
> these patches on kernel 4.19.0-rc4.
>
Could you please elaborate on the purpose of this series? Is it simply
t
Thiago Jung Bauermann writes:
> Michael Ellerman writes:
>> Thiago Jung Bauermann writes:
>>> The hypervisor interface to access 24x7 performance counters (which collect
>>> performance information from system power on to system power off) has been
>>> extended in POWER9 adding new fields to th
Michael Ellerman writes:
> Thiago Jung Bauermann writes:
>> The hypervisor interface to access 24x7 performance counters (which collect
>> performance information from system power on to system power off) has been
>> extended in POWER9 adding new fields to the request and result element
>> struc
Thiago Jung Bauermann writes:
> Hello,
>
> The hypervisor interface to access 24x7 performance counters (which collect
> performance information from system power on to system power off) has been
> extended in POWER9 adding new fields to the request and result element
> structures.
>
> Also, resu
Thiago Jung Bauermann [bauer...@linux.vnet.ibm.com] wrote:
> Hello,
>
> The hypervisor interface to access 24x7 performance counters (which collect
> performance information from system power on to system power off) has been
> extended in POWER9 adding new fields to the request and result element
On 04/21/2017 05:14 PM, Shuah Khan wrote:
> This patch series consists of changes to lib.mk to allow overriding
> common clean target from Makefiles. This fixes warnings when clean
> overriding and ignoring warnings. Also fixes splice clean target
> removing a script that runs the test from its cle
On Tue, Jun 07, 2016 at 06:38:33PM +0100, Peter Griffin wrote:
> Hi Vinod,
>
> This series is a bunch of cleanup updates to various
> dmaengine drivers, based on some of the review feeback to my fdma series.
Good cleanup, Applied, thanks
--
~Vinod
___
On 06/12/16 at 12:10am, Thiago Jung Bauermann wrote:
> Hello,
>
> This patch series implements the kexec_file_load system call on PowerPC.
>
> It starts by removing an x86 assumption from kexec_file: kexec_add_buffer uses
> iomem to find reserved memory ranges, but PowerPC uses the memblock subsy
On Wed, 18 Nov 2015 14:51:25 +
David Laight wrote:
> From: Cyril Bur
> > Sent: 18 November 2015 03:27
> ...
> > The goal of these patches is to rework how the 'math' registers (FP, VEC
> > and VSX) are context switched. Currently the kernel adopts a lazy approach,
> > always switching users
From: Cyril Bur
> Sent: 18 November 2015 03:27
...
> The goal of these patches is to rework how the 'math' registers (FP, VEC
> and VSX) are context switched. Currently the kernel adopts a lazy approach,
> always switching userspace tasks with all three facilities disabled and
> loads in each set o
On Thu, 2015-08-27 at 13:31 +0200, Martin Schwidefsky wrote:
> On Thu, 27 Aug 2015 13:12:05 +1000
> Michael Ellerman wrote:
> > On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote:
> > > On Thu, 20 Aug 2015, Michael Ellerman wrote:
> > > > I'm reluctant to proceed with merging them though until
On Thu, 27 Aug 2015 13:12:05 +1000
Michael Ellerman wrote:
> On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote:
> > On Thu, 20 Aug 2015, Michael Ellerman wrote:
> >
> > > On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
> > > > I'd like to ping this patch series, not having seen any co
On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote:
> On Thu, 20 Aug 2015, Michael Ellerman wrote:
>
> > On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
> > > I'd like to ping this patch series, not having seen any comments on it.
> > >
> > > [PATCH 0/8] math-emu: Update kernel math-emu
On 08/26/2015 07:44 AM, Joseph Myers wrote:
On Thu, 20 Aug 2015, Michael Ellerman wrote:
On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
I'd like to ping this patch series, not having seen any comments on it.
[PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
On Wed, Aug 26, 2015 at 4:44 PM, Joseph Myers wrote:
> Ping again for the other-architecture maintainers (alpha, s390, sh,
> sparc)
sh is orphaned, cfr. MAINTAINERS.
Perhaps the J2/J4 people are interested in maintainership?
Gr{oetje,eeting}s,
Geert
--
Geert Uytter
On Thu, 20 Aug 2015, Michael Ellerman wrote:
> On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
> > I'd like to ping this patch series, not having seen any comments on it.
> >
> > [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
> > https://lkml.org/lkml/2015/7/2
On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
> I'd like to ping this patch series, not having seen any comments on it.
>
> [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
> https://lkml.org/lkml/2015/7/2/394
>
> [PATCH 1/8] math-emu: Move math-emu to math-em
I'd like to ping this patch series, not having seen any comments on it.
[PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
https://lkml.org/lkml/2015/7/2/394
[PATCH 1/8] math-emu: Move math-emu to math-emu-old
https://lkml.org/lkml/2015/7/2/395
[PATCH 2/8] math-emu: Imp
On Sat, Aug 08, 2015 at 03:51:54PM +0300, Vladimir Zapolskiy wrote:
> Hi Wolfram,
>
> On 08.08.2015 01:34, Wolfram Sang wrote:
> >
> >> if we're talking about this particular series, you should have them in
> >> your mailbox, since you have them applied in wsa/i2c/for-next:
> >
> > Those are alr
Hi Wolfram,
On 08.08.2015 01:34, Wolfram Sang wrote:
>
>> if we're talking about this particular series, you should have them in
>> your mailbox, since you have them applied in wsa/i2c/for-next:
>
> Those are already in linus tree. I mean all drivers which use struct
> i2c_driver. Or do you pref
> if we're talking about this particular series, you should have them in
> your mailbox, since you have them applied in wsa/i2c/for-next:
Those are already in linus tree. I mean all drivers which use struct
i2c_driver. Or do you prefer they go via Greg? I am fine with both.
signature.asc
Descr
1 - 100 of 246 matches
Mail list logo
