On 24/9/21 3:26 am, Ben Widawsky wrote:
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core
On 24/9/21 3:26 am, Ben Widawsky wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor
On 2021/9/24 14:41, Christophe Leroy wrote:
>
>
> Le 24/09/2021 à 08:39, Liu Shixin a écrit :
>> On platform PPC_FSL_BOOK3E, all lowmem is managed by tlbcam. That means
>> we didn't really map the kfence pool with page granularity. Therefore,
>> if KFENCE is enabled, the system will hit the
> I guess we're not expecting systems with less than 32MB, so making it
> unconditional is OK?
hi
it's not 32MB of total physical ram, but rather using 32MB of the
total physical ram to correctly boot a kernel bigger than 8MB.
The problem is complex:
- u-boot loads things at 0x0200. (in my
Christophe Leroy writes:
> As reported by Carlo, 16Mbytes is not enough with modern kernels
> that tend to be a bit big, so map another 16M page at boot.
I guess we're not expecting systems with less than 32MB, so making it
unconditional is OK?
cheers
> diff --git
Michael Ellerman writes:
> Ard Biesheuvel writes:
>> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
>>>
>>> The CPU field will be moved back into thread_info even when
>>> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
>>> of struct thread_info.
>>>
>>>
hi,
this is my second patch-test report.
Today I have successfully tested Christophe Leroy's patch.
Attached a cleaned patch. With the previous one the kernel booted, but
there was a line missing.
I have also tested two different kernels with success
both kernel sizes were ~9.4MB
the Entry
Please spell out "register block indicator" in the subject so that the
shortlog remains somewhat readable.
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote:
>
> In preparation for passing around the Register Block Indicator (RBI) as
> a parameter, it is desirable to convert the type to an
Ard Biesheuvel writes:
> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
>>
>> The CPU field will be moved back into thread_info even when
>> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
>> of struct thread_info.
>>
>> Signed-off-by: Ard Biesheuvel
>
> Michael,
>
On 9/27/21 4:01 PM, Luis Chamberlain wrote:
> This is the fourth batch of add_disk() error handling driver
> conversions. This set along with the entire 7 set of driver conversions
> can be found on my 20210927-for-axboe-add-disk-error-handling branch
> [0].
Applied 1-2, 6, 8-9, thank
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
A completion is used to notify the initial probe what is
happening and so we must defer error handling on completion.
Do this by remembering the error and using the
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
The out_mem2 error label already does what we need so
re-use that.
Signed-off-by: Luis Chamberlain
---
drivers/block/pktcdvd.c | 4 +++-
1 file changed, 3
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
We re-use the same free tag call, so we also add a label for
that as well.
Signed-off-by: Luis Chamberlain
---
drivers/block/sunvdc.c | 14 +++---
1 file
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain
---
drivers/block/ps3vram.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/block/ps3vram.c
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
The read_capacity_error error label already does what we need,
so just re-use that.
Signed-off-by: Luis Chamberlain
---
drivers/block/mtip32xx/mtip32xx.c | 4 +++-
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain
---
drivers/block/paride/pf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/paride/pf.c
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain
---
drivers/block/rsxx/core.c | 4 +++-
drivers/block/rsxx/dev.c | 12 +---
2 files changed, 12 insertions(+), 4
This is the fourth batch of add_disk() error handling driver
conversions. This set along with the entire 7 set of driver conversions
can be found on my 20210927-for-axboe-add-disk-error-handling branch
[0].
On this v2 series the following modifications have been made since the
last v1 series
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Acked-by: Jack Wang
Signed-off-by: Luis Chamberlain
---
drivers/block/rnbd/rnbd-clt.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain
---
drivers/mtd/ubi/block.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/block.c
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain
---
drivers/block/ps3disk.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/block/ps3disk.c
Hello,
On Mon, Sep 27, 2021 at 10:43:18PM +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
I sent the series from the wrong email address :-\ I should have used
the above address as sender. Also I failed to add Christoph Hellwig to
Cc: (fixed for this mail). I guess I'll have to send a
From: Uwe Kleine-König
Hello,
this is v4 of the quest to drop the "driver" member from struct pci_dev
which tracks the same data (apart from a constant offset) as dev.driver.
Changes since v3:
- Add some Reviewed-by and Acked-by tags
- Rebase to v5.15-rc3 (no conflicts)
- Changes in patch
From: Uwe Kleine-König
struct pci_dev::driver contains (apart from a constant offset) the same
data as struct pci_dev::dev->driver. Replace all remaining users of the
former pointer by the latter to allow removing the former.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Uwe Kleine-König
---
From: Uwe Kleine-König
struct pci_dev::driver holds (apart from a constant offset) the same
data as struct pci_dev::dev->driver. With the goal to remove struct
pci_dev::driver to get rid of data duplication replace getting the
driver name by dev_driver_string() which implicitly makes use of
If, due to bugs elsewhere, we get into unregister_cpu_online() with a CPU
that isn't marked hotpluggable, we can emit a warning and return an
appropriate error instead of crashing.
Signed-off-by: Nathan Lynch
Reviewed-by: Daniel Henrique Barboza
---
arch/powerpc/kernel/sysfs.c | 3 ++-
1 file
This comment likely refers to the obsolete DLPAR workflow where some
resource state transitions were driven more directly from user space
utilities, but it also seems to contradict itself: "Change isolate state to
Isolate [...]" is at odds with the preceding sentences, and it does not
relate at
The core DLPAR code supports two actions (add and remove) and three
subtypes of action:
* By DRC index: the action is attempted on a single specified resource.
This is the usual case for processors.
* By indexed count: the action is attempted on a range of resources
beginning at the specified
Fixes for some vintage bugs in handling cache node addition and removal, a
miscellaneous BUG->WARN conversion, and removal of the fragile "by count"
CPU DLPAR code that probably has no users.
Changes since v1:
* Remove set but unused local variable (0day)
* Additional comment cleanup patch
On pseries, cache nodes in the device tree can be added and removed by the
CPU DLPAR code as well as the partition migration (mobility) code. PowerVM
partitions in dedicated processor mode typically have L2 and L3 cache
nodes.
The CPU DLPAR code has the following shortcomings:
* Cache nodes
hi,
this is my first patch-test report.
Today I have successfully tested Christophe Leroy's patch.
I had to manually edit lines, but it worked with a kernel sized 9.1MByte :D
used toolchain:
- powerpc-unknown-linux-gnu-binutiles-v2.34
- powerpc-unknown-linux-gnu-gcc-v9.3.0
host:
-
On Tue, Sep 21, 2021 at 11:39:28PM +0200, Emmanuel Gil Peyrot wrote:
> Both of these consoles use the exact same AES engine, which only
> supports CBC mode with 128-bit keys.
>
> Signed-off-by: Emmanuel Gil Peyrot
> ---
> .../bindings/crypto/nintendo-aes.yaml | 34 +++
>
s/pci_find_dvsec_capability/pci_find_dvsec_capability()/ in subject
and commit log.
On Thu, Sep 23, 2021 at 10:26:44AM -0700, Ben Widawsky wrote:
> Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
> Extended Capability with the specified DVSEC ID.
"specified Vendor ID and
On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
>
> The CPU field will be moved back into thread_info even when
> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
> of struct thread_info.
>
> Signed-off-by: Ard Biesheuvel
Michael,
Do you have any objections or issues
As reported by Carlo, 16Mbytes is not enough with modern kernels
that tend to be a bit big, so map another 16M page at boot.
Cc: cp
Signed-off-by: Christophe Leroy
---
v2: Add missing header and missing @h
---
arch/powerpc/kernel/head_40x.S | 9 -
1 file changed, 8 insertions(+), 1
On 27 September 2021 at 09:58 am, Michael Ellerman wrote:
Wolfram Sang writes:
Sure, will do that later as well!
But please do it privately. For upstreaming, the patch series you sent
is way better than a single patch.
Christian, the whole series is downloadable as a single mbox here:
Le 27/09/2021 à 15:11, Michael Ellerman a écrit :
Christophe Leroy writes:
Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
static_obj()") added arch_is_kernel_initmem_freed() which is supposed
to report whether an object is part of already freed init memory.
For the time
Christophe Leroy writes:
> Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
> static_obj()") added arch_is_kernel_initmem_freed() which is supposed
> to report whether an object is part of already freed init memory.
>
> For the time being, the generic version of
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sun, 26 Sep 2021 14:52:14 +0800 you wrote:
> Replacing kmalloc/kfree/dma_map_single/dma_unmap_single()
> with dma_alloc_coherent/dma_free_coherent() helps to reduce
> code size, and simplify the code, and coherent DMA
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Sat, 25 Sep 2021 12:14:18 -0300 you wrote:
> This reverts commit d437f5aa23aa2b7bd07cd44b839d7546cc17166f.
>
> Code has been duplicated through commit <273c29e944bd> "ibmvnic: check
> failover_pending in login response"
>
As reported by Carlo, 16Mbytes is not enough with modern kernels
that tend to be a bit big, so map another 16M page at boot.
Cc: cp
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
Hi Christian,
Thanks already for volunteering to test this!
On Sun, Sep 26, 2021, at 22:27, Christian Zigotzky wrote:
> Hi Sven,
>
> I can't apply your patch 5 (i2c: pasemi: Split pci driver to its own
> file). [1]
That's strange because it should apply cleanly. I'll double check
after to work
Wolfram Sang writes:
>> Sure, will do that later as well!
>
> But please do it privately. For upstreaming, the patch series you sent
> is way better than a single patch.
Christian, the whole series is downloadable as a single mbox here:
https://patchwork.ozlabs.org/series/264134/mbox/
Save
On Sun, Sep 26, 2021 at 12:00 PM Sven Peter wrote:
>
> This series adds support for the I2C controller found on Apple Silicon Macs
> which has quite a bit of history:
>
> Apple bought P.A. Semi in 2008 and it looks like a part of its legacy
> continues
> to live on in the M1. This controller has
On Sun, Sep 26, 2021 at 12:00 PM Sven Peter wrote:
>
> In preparation for splitting this driver up into a platform_driver
> and a pci_driver, replace outl/inl usage with ioport_map and
> ioread32/iowrite32.
>
> Signed-off-by: Sven Peter
>
> + smbus->ioaddr = ioport_map(smbus->base,
> Sure, will do that later as well!
But please do it privately. For upstreaming, the patch series you sent
is way better than a single patch.
signature.asc
Description: PGP signature
Hi,
Le 25/09/2021 à 11:49, cp a écrit :
hi
I am new to this list. Hope this is the right place to ask.
I am working with a PPC405GP board, and as far as I understand, the
support for ppc40x platforms like Acadia and Walnut were dropped with
kernel 5.8.0, so this seems like a pretty
47 matches
Mail list logo
