Re: [PATCH v2 8/9] ocxl: Use pci core's DVSEC functionality
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 implementation. As that change is less trivial it is reserved for later. Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan Acked-by: Frederic Barrat (v1) Signed-off-by: Ben Widawsky Looks fine, but we should clean up find_dvsec_from_pos() afterwards. Reviewed-by: Andrew Donnellan -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH v2 6/9] PCI: Add pci_find_dvsec_capability to find designated VSEC
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 ID of the PCI component. DVSEC is critical for both the Compute Express Link (CXL) driver as well as the driver for OpenCAPI coherent accelerator (OCXL). Cc: David E. Box Cc: Jonathan Cameron Cc: Bjorn Helgaas Cc: Dan Williams Cc: linux-...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan Cc: Lu Baolu Reviewed-by: Frederic Barrat Signed-off-by: Ben Widawsky Looks good to me, it's essentially identical to the existing implementation in ocxl. Reviewed-by: Andrew Donnellan -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH] powerpc: don't select KFENCE on platform PPC_FSL_BOOK3E
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 following panic:
>
> Could you please explain a bit more what the problem is ?
>
> KFENCE has been implemented with the same logic as DEBUG_PAGEALLOC.
>
> DEBUG_PAGEALLOC is enabled on FSL_BOOK3E.
>
> In MMU_setup(), __map_without_ltlbs is set to 1 when KFENCE is enabled.
>
> __map_without_ltlbs should disable the use of tlbcam.
>
>
> So what's wrong really ?
>
> Does DEBUG_PAGEALLOC work on FSL_BOOK3E ?
>
> Thanks
> Christophe
hi Christophe,
In the last e-mail I have said that DEBUG_PAGEALLOC works well on FSL_BOOK3E,
that is wrong.
Actually, I add some printed information and find DEBUG_PAGEALLOC Skip all
pages.
So neither DEBUG_PAGEALLOC nor kfence is really working.
diff --git a/mm/memory.c b/mm/memory.c
index 25fc46e87214..37fb1b14bc3f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2564,8 +2564,10 @@ static int apply_to_pmd_range(struct mm_struct *mm,
pud_t *pud,
}
do {
next = pmd_addr_end(addr, end);
- if (pmd_none(*pmd) && !create)
+ if (pmd_none(*pmd) && !create) {
+ pr_info("-pmd_none--\n");
continue;
+ }
if (WARN_ON_ONCE(pmd_leaf(*pmd)))
return -EINVAL;
if (!pmd_none(*pmd) && WARN_ON_ONCE(pmd_bad(*pmd))) {
>
>>
>> BUG: Kernel NULL pointer dereference on read at 0x
>> Faulting instruction address: 0xc01de598
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> BE PAGE_SIZE=4K SMP NR_CPUS=4 MPC8544 DS
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc3+ #298
>> NIP: c01de598 LR: c08ae9c4 CTR:
>> REGS: c0b4bea0 TRAP: 0300 Not tainted (5.12.0-rc3+)
>> MSR: 00021000 CR: 24000228 XER: 2000
>> DEAR: ESR:
>> GPR00: c08ae9c4 c0b4bf60 c0ad64e0 ef72 00021000
>> 0200
>> GPR08: c0ad5000 0004 008fbb30
>>
>> GPR16: c000
>>
>> GPR24: c08ca004 c08ca004 c0b6a0e0 c0b6 c0b58f00 c085 c08ca000
>> ef72
>> NIP [c01de598] kfence_protect+0x44/0x6c
>> LR [c08ae9c4] kfence_init+0xfc/0x2a4
>> Call Trace:
>> [c0b4bf60] [efffe160] 0xefffe160 (unreliable)
>> [c0b4bf70] [c08ae9c4] kfence_init+0xfc/0x2a4
>> [c0b4bfb0] [c0894d3c] start_kernel+0x3bc/0x574
>> [c0b4bff0] [c470] set_ivor+0x14c/0x188
>> Instruction dump:
>> 7c0802a6 8109d594 546a653a 90010014 54630026 3920 7d48502e 2c0a
>> 41820010 554a0026 5469b53a 7d295214 <8149> 38831000 554a003c
>> 9149
>> random: get_random_bytes called from print_oops_end_marker+0x40/0x78
>> with crng_init=0
>> ---[ end trace ]---
>>
>> Signed-off-by: Liu Shixin
>> ---
>> arch/powerpc/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index d46db0bfb998..cffd57bcb5e4 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -185,7 +185,7 @@ config PPC
>> select HAVE_ARCH_KASANif PPC32 && PPC_PAGE_SHIFT <= 14
>> select HAVE_ARCH_KASAN_VMALLOCif PPC32 && PPC_PAGE_SHIFT <= 14
>> select HAVE_ARCH_KGDB
>> -select HAVE_ARCH_KFENCEif PPC32
>> +select HAVE_ARCH_KFENCEif PPC32 && !PPC_FSL_BOOK3E
>> select HAVE_ARCH_MMAP_RND_BITS
>> select HAVE_ARCH_MMAP_RND_COMPAT_BITSif COMPAT
>> select HAVE_ARCH_NVRAM_OPS
>>
> .
>
Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
> 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 case) - then cuboot copies the kernel to 0x0090., and appends the flat device tree to the end of kernel - then cuboot copies again the kernel to 0x., and invokes head.S at this point head.S needs to initialize the virtual memory, and needs to have 32MB mapped in order to correctly gets the flat device tree if the kernel is smaller than 8MB, then cuboot copies it to 0x0080., and head.S only need to have 16MB mapped in order to gets the flat device tree Cheers
Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
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 a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S > index 7d72ee5ab387..5fce4680d2d3 100644 > --- a/arch/powerpc/kernel/head_40x.S > +++ b/arch/powerpc/kernel/head_40x.S > @@ -650,7 +650,7 @@ start_here: > b . /* prevent prefetch past rfi */ > > /* Set up the initial MMU state so we can do the first level of > - * kernel initialization. This maps the first 16 MBytes of memory 1:1 > + * kernel initialization. This maps the first 32 MBytes of memory 1:1 > * virtual to physical and more importantly sets the cache mode. > */ > initial_mmu: > @@ -687,6 +687,12 @@ initial_mmu: > tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ > tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ > > + li r0,62 /* TLB slot 62 */ > + addis r4,r4,SZ_16M > + addis r3,r3,SZ_16M > + tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ > + tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ > + > isync > > /* Establish the exception vector base > -- > 2.31.1
Re: [RFC PATCH 4/8] powerpc: add CPU field to struct thread_info
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. >>> >>> Signed-off-by: Ard Biesheuvel >> >> Michael, >> >> Do you have any objections or issues with this patch or the subsequent >> ones cleaning up the task CPU kludge for ppc32? Christophe indicated >> that he was happy with it. > > No objections, it looks good to me, thanks for cleaning up that horror :) > > It didn't apply cleanly to master so I haven't tested it at all, if you can > point me at a > git tree with the dependencies I'd be happy to run some tests over it. Actually I realised I can just drop the last patch. So that looks fine, passes my standard quick build & boot on qemu tests, and builds with/without stack protector enabled. cheers
Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
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 Point was always 0x00901b00 used toolchain: - powerpc-unknown-linux-gnu-binutiles-v2.34 - powerpc-unknown-linux-gnu-gcc-v9.3.0 host: - macmini-intel, Gentoo cross-compiler, 32bit userland target: - AMCC PPC405GP wrapper: - cuboot Applied to - kernel-v5.2.1-vanilla - kernel-v5.7.19-vanilla Attached I report here is the difference between the original file and mine. Thanks guys! Carlo --- map 32MB of ram rather than 16MB --- arch/powerpc/kernel/head_40x.S.original 2021-09-28 00:07:27.76800 - +++ arch/powerpc/kernel/head_40x.S 2021-09-28 00:07:27.76000 - @@ -25,6 +25,7 @@ * Kernel execution entry point code. */ + #include #include #include @@ -842,17 +843,33 @@ mtspr SPRN_PID,r0 sync - /* Configure and load one entry into TLB slots 63 */ - clrrwi r4,r4,10/* Mask off the real page number */ - ori r4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */ - - clrrwi r3,r3,10/* Mask off the effective page number */ - ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M)) - -li r0,63/* TLB slot 63 */ - - tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ - tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ +/* + * Configure and load two entries into TLB slots 62 and 63. + * TLB 62 is used for first 16M page + * TLB 63 is for the second 16M page + * In case we are pinning TLBs, these are reserved in by + * the other TLB functions. + * If not reserved, then it doesn't matter where they are loaded. + */ +clrrwi r4,r4,10 /* Mask off the real page number */ +orir4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */ + +clrrwi r3,r3,10 /* Mask off the effective page number */ +orir3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M)) + +li r0,62/* TLB slot 62 */ + +tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ +tlbwe r3,r0,TLB_TAG/* Load the tag portion of the entry */ + +addis r4, r4, 0x0100 /* Map next 16 Mentries */ +addis r3, r3, 0x0100 + +li r0,63 /* TLB slot 63 */ + +/* Load up the kernel context */ +tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ +tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ isync On Mon, 27 Sept 2021 at 12:35, Christophe Leroy wrote: > > 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.
Re: [PATCH v2 1/9] cxl: Convert "RBI" to enum
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 enum so that the > interface can use a well defined type checked parameter. C wouldn't type check this unless it failed an integer conversion, right? It would need to be a struct to get useful type checking. I don't mind this for the self documenting properties it has for the functions that will take this as a parameter, but maybe clarify what you mean by type checked parameter? > > As a result of this change, should future versions of the spec add > sparsely defined identifiers, it could become a problem if checking for > invalid identifiers since the code currently checks for the max > identifier. This is not an issue with current spec, and the algorithm to > obtain the register blocks will change before those possible additions > are made. In general let's not spend changelog space trying to guess what future specs may or may not do. I.e. I think this text can be dropped, especially because enums can support sparse number spaces.
Re: [RFC PATCH 4/8] powerpc: add CPU field to struct thread_info
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, > > Do you have any objections or issues with this patch or the subsequent > ones cleaning up the task CPU kludge for ppc32? Christophe indicated > that he was happy with it. No objections, it looks good to me, thanks for cleaning up that horror :) It didn't apply cleanly to master so I haven't tested it at all, if you can point me at a git tree with the dependencies I'd be happy to run some tests over it. cheers
Re: [PATCH v2 00/10] block: fourth batch of add_disk() error handling conversions
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, thanks. -- Jens Axboe
[PATCH v2 08/10] block/sx8: add error handling support for add_disk()
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 shared cleanup
function.
The tags are shared and so are hanlded later for the
driver already.
Signed-off-by: Luis Chamberlain
---
drivers/block/sx8.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/block/sx8.c b/drivers/block/sx8.c
index 420cd952ddc4..1c79248c4826 100644
--- a/drivers/block/sx8.c
+++ b/drivers/block/sx8.c
@@ -297,6 +297,7 @@ struct carm_host {
struct work_struct fsm_task;
+ int probe_err;
struct completion probe_comp;
};
@@ -1181,8 +1182,11 @@ static void carm_fsm_task (struct work_struct *work)
struct gendisk *disk = port->disk;
set_capacity(disk, port->capacity);
- add_disk(disk);
- activated++;
+ host->probe_err = add_disk(disk);
+ if (!host->probe_err)
+ activated++;
+ else
+ break;
}
printk(KERN_INFO DRV_NAME "(%s): %d ports activated\n",
@@ -1192,11 +1196,9 @@ static void carm_fsm_task (struct work_struct *work)
reschedule = 1;
break;
}
-
case HST_PROBE_FINISHED:
complete(>probe_comp);
break;
-
case HST_ERROR:
/* FIXME: TODO */
break;
@@ -1507,7 +1509,10 @@ static int carm_init_one (struct pci_dev *pdev, const
struct pci_device_id *ent)
goto err_out_free_irq;
DPRINTK("waiting for probe_comp\n");
+ host->probe_err = -ENODEV;
wait_for_completion(>probe_comp);
+ if (host->probe_err)
+ goto err_out_free_irq;
printk(KERN_INFO "%s: pci %s, ports %d, io %llx, irq %u, major %d\n",
host->name, pci_name(pdev), (int) CARM_MAX_PORTS,
--
2.30.2
[PATCH v2 02/10] pktcdvd: add error handling support for add_disk()
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 insertions(+), 1 deletion(-) diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c index 0f26b2510a75..415248962e67 100644 --- a/drivers/block/pktcdvd.c +++ b/drivers/block/pktcdvd.c @@ -2729,7 +2729,9 @@ static int pkt_setup_dev(dev_t dev, dev_t* pkt_dev) /* inherit events of the host device */ disk->events = pd->bdev->bd_disk->events; - add_disk(disk); + ret = add_disk(disk); + if (ret) + goto out_mem2; pkt_sysfs_dev_new(pd); pkt_debugfs_dev_new(pd); -- 2.30.2
[PATCH v2 07/10] block/sunvdc: add error handling support for add_disk()
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 changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c
index 4d4bb810c2ae..6f45a53f7cbf 100644
--- a/drivers/block/sunvdc.c
+++ b/drivers/block/sunvdc.c
@@ -826,8 +826,8 @@ static int probe_disk(struct vdc_port *port)
if (IS_ERR(g)) {
printk(KERN_ERR PFX "%s: Could not allocate gendisk.\n",
port->vio.name);
- blk_mq_free_tag_set(>tag_set);
- return PTR_ERR(g);
+ err = PTR_ERR(g);
+ goto out_free_tag;
}
port->disk = g;
@@ -879,9 +879,17 @@ static int probe_disk(struct vdc_port *port)
port->vdisk_size, (port->vdisk_size >> (20 - 9)),
port->vio.ver.major, port->vio.ver.minor);
- device_add_disk(>vio.vdev->dev, g, NULL);
+ err = device_add_disk(>vio.vdev->dev, g, NULL);
+ if (err)
+ goto out_cleanup_disk;
return 0;
+
+out_cleanup_disk:
+ blk_cleanup_disk(g);
+out_free_tag:
+ blk_mq_free_tag_set(>tag_set);
+ return err;
}
static struct ldc_channel_config vdc_ldc_cfg = {
--
2.30.2
[PATCH v2 04/10] ps3vram: add error handling support for add_disk()
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 b/drivers/block/ps3vram.c index c7b19e128b03..af2a0d09c598 100644 --- a/drivers/block/ps3vram.c +++ b/drivers/block/ps3vram.c @@ -755,9 +755,14 @@ static int ps3vram_probe(struct ps3_system_bus_device *dev) dev_info(>core, "%s: Using %llu MiB of GPU memory\n", gendisk->disk_name, get_capacity(gendisk) >> 11); - device_add_disk(>core, gendisk, NULL); + error = device_add_disk(>core, gendisk, NULL); + if (error) + goto out_cleanup_disk; + return 0; +out_cleanup_disk: + blk_cleanup_disk(gendisk); out_cache_cleanup: remove_proc_entry(DEVICE_NAME, NULL); ps3vram_cache_cleanup(dev); -- 2.30.2
[PATCH v2 01/10] mtip32xx: add error handling support for add_disk()
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 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 901855717cb5..d0b40309f47e 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3633,7 +3633,9 @@ static int mtip_block_initialize(struct driver_data *dd)
set_capacity(dd->disk, capacity);
/* Enable the block device and add it to /dev */
- device_add_disk(>pdev->dev, dd->disk, mtip_disk_attr_groups);
+ rv = device_add_disk(>pdev->dev, dd->disk, mtip_disk_attr_groups);
+ if (rv)
+ goto read_capacity_error;
if (dd->mtip_svc_handler) {
set_bit(MTIP_DDF_INIT_DONE_BIT, >dd_flag);
--
2.30.2
[PATCH v2 09/10] pf: add error handling support for add_disk()
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 b/drivers/block/paride/pf.c index f471d48a87bc..380d80e507c7 100644 --- a/drivers/block/paride/pf.c +++ b/drivers/block/paride/pf.c @@ -962,7 +962,9 @@ static int __init pf_init_unit(struct pf_unit *pf, bool autoprobe, int port, if (pf_probe(pf)) goto out_pi_release; - add_disk(disk); + ret = add_disk(disk); + if (ret) + goto out_pi_release; pf->present = 1; return 0; -- 2.30.2
[PATCH v2 06/10] block/rsxx: add error handling support for add_disk()
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 deletions(-)
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 83636714b8d7..8d9d69f5dfbc 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -935,7 +935,9 @@ static int rsxx_pci_probe(struct pci_dev *dev,
card->size8 = 0;
}
- rsxx_attach_dev(card);
+ st = rsxx_attach_dev(card);
+ if (st)
+ goto failed_create_dev;
/* Setup Debugfs */
rsxx_debugfs_dev_new(card);
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index 1cc40b0ea761..b2d3ac3efce2 100644
--- a/drivers/block/rsxx/dev.c
+++ b/drivers/block/rsxx/dev.c
@@ -192,6 +192,8 @@ static bool rsxx_discard_supported(struct rsxx_cardinfo
*card)
int rsxx_attach_dev(struct rsxx_cardinfo *card)
{
+ int err = 0;
+
mutex_lock(>dev_lock);
/* The block device requires the stripe size from the config. */
@@ -200,13 +202,17 @@ int rsxx_attach_dev(struct rsxx_cardinfo *card)
set_capacity(card->gendisk, card->size8 >> 9);
else
set_capacity(card->gendisk, 0);
- device_add_disk(CARD_TO_DEV(card), card->gendisk, NULL);
- card->bdev_attached = 1;
+ err = device_add_disk(CARD_TO_DEV(card), card->gendisk, NULL);
+ if (err == 0)
+ card->bdev_attached = 1;
}
mutex_unlock(>dev_lock);
- return 0;
+ if (err)
+ blk_cleanup_disk(card->gendisk);
+
+ return err;
}
void rsxx_detach_dev(struct rsxx_cardinfo *card)
--
2.30.2
[PATCH v2 00/10] block: fourth batch of add_disk() error handling conversions
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 of this patch set: - rebased onto linux-next tag 20210927 - added the only reviewed-by tag for this series for rnbd Jack Wang [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20210927-for-axboe-add-disk-error-handling Luis Chamberlain (10): mtip32xx: add error handling support for add_disk() pktcdvd: add error handling support for add_disk() ps3disk: add error handling support for add_disk() ps3vram: add error handling support for add_disk() rnbd: add error handling support for add_disk() block/rsxx: add error handling support for add_disk() block/sunvdc: add error handling support for add_disk() block/sx8: add error handling support for add_disk() pf: add error handling support for add_disk() mtd/ubi/block: add error handling support for add_disk() drivers/block/mtip32xx/mtip32xx.c | 4 +++- drivers/block/paride/pf.c | 4 +++- drivers/block/pktcdvd.c | 4 +++- drivers/block/ps3disk.c | 8 ++-- drivers/block/ps3vram.c | 7 ++- drivers/block/rnbd/rnbd-clt.c | 13 + drivers/block/rsxx/core.c | 4 +++- drivers/block/rsxx/dev.c | 12 +--- drivers/block/sunvdc.c| 14 +++--- drivers/block/sx8.c | 13 + drivers/mtd/ubi/block.c | 8 +++- 11 files changed, 69 insertions(+), 22 deletions(-) -- 2.30.2
[PATCH v2 05/10] rnbd: add error handling support for add_disk()
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 --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
index bd4a41afbbfc..1ba1c868535a 100644
--- a/drivers/block/rnbd/rnbd-clt.c
+++ b/drivers/block/rnbd/rnbd-clt.c
@@ -1384,8 +1384,10 @@ static void setup_request_queue(struct rnbd_clt_dev *dev)
blk_queue_write_cache(dev->queue, dev->wc, dev->fua);
}
-static void rnbd_clt_setup_gen_disk(struct rnbd_clt_dev *dev, int idx)
+static int rnbd_clt_setup_gen_disk(struct rnbd_clt_dev *dev, int idx)
{
+ int err;
+
dev->gd->major = rnbd_client_major;
dev->gd->first_minor= idx << RNBD_PART_BITS;
dev->gd->minors = 1 << RNBD_PART_BITS;
@@ -1410,7 +1412,11 @@ static void rnbd_clt_setup_gen_disk(struct rnbd_clt_dev
*dev, int idx)
if (!dev->rotational)
blk_queue_flag_set(QUEUE_FLAG_NONROT, dev->queue);
- add_disk(dev->gd);
+ err = add_disk(dev->gd);
+ if (err)
+ blk_cleanup_disk(dev->gd);
+
+ return err;
}
static int rnbd_client_setup_device(struct rnbd_clt_dev *dev)
@@ -1426,8 +1432,7 @@ static int rnbd_client_setup_device(struct rnbd_clt_dev
*dev)
rnbd_init_mq_hw_queues(dev);
setup_request_queue(dev);
- rnbd_clt_setup_gen_disk(dev, idx);
- return 0;
+ return rnbd_clt_setup_gen_disk(dev, idx);
}
static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess,
--
2.30.2
[PATCH v2 10/10] mtd/ubi/block: add error handling support for add_disk()
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 b/drivers/mtd/ubi/block.c index e003b4b44ffa..062e6c2c45f5 100644 --- a/drivers/mtd/ubi/block.c +++ b/drivers/mtd/ubi/block.c @@ -447,12 +447,18 @@ int ubiblock_create(struct ubi_volume_info *vi) list_add_tail(>list, _devices); /* Must be the last step: anyone can call file ops from now on */ - add_disk(dev->gd); + ret = add_disk(dev->gd); + if (ret) + goto out_destroy_wq; + dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)", dev->ubi_num, dev->vol_id, vi->name); mutex_unlock(_mutex); return 0; +out_destroy_wq: + list_del(>list); + destroy_workqueue(dev->wq); out_remove_minor: idr_remove(_minor_idr, gd->first_minor); out_cleanup_disk: -- 2.30.2
[PATCH v2 03/10] ps3disk: add error handling support for add_disk()
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 b/drivers/block/ps3disk.c index 8d51efbe045d..3054adf77460 100644 --- a/drivers/block/ps3disk.c +++ b/drivers/block/ps3disk.c @@ -467,9 +467,13 @@ static int ps3disk_probe(struct ps3_system_bus_device *_dev) gendisk->disk_name, priv->model, priv->raw_capacity >> 11, get_capacity(gendisk) >> 11); - device_add_disk(>sbd.core, gendisk, NULL); - return 0; + error = device_add_disk(>sbd.core, gendisk, NULL); + if (error) + goto fail_cleanup_disk; + return 0; +fail_cleanup_disk: + blk_cleanup_disk(gendisk); fail_free_tag_set: blk_mq_free_tag_set(>tag_set); fail_teardown: -- 2.30.2
Re: [PATCH v4 0/8] PCI: Drop duplicated tracking of a pci_dev's bound driver
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 v5, but I will wait a bit until the build bots are done with this series. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH v4 0/8] PCI: Drop duplicated tracking of a pci_dev's bound driver
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 #4 addressing review comments by Christoph Hellwig I didn't do extensive build tests, so I might have missed a build problem. I have some builds running, but want to get some feedback on the changes suggested by Christoph. Best regards Uwe Uwe Kleine-König (8): PCI: Simplify pci_device_remove() PCI: Drop useless check from pci_device_probe() xen/pci: Drop some checks that are always true PCI: replace pci_dev::driver usage that gets the driver name scsi: message: fusion: Remove unused parameter of mpt_pci driver's probe() crypto: qat - simplify adf_enable_aer() PCI: Replace pci_dev::driver usage by pci_dev::dev.driver PCI: Drop duplicated tracking of a pci_dev's bound driver arch/powerpc/include/asm/ppc-pci.h| 9 ++- arch/powerpc/kernel/eeh_driver.c | 10 +-- arch/x86/events/intel/uncore.c| 2 +- arch/x86/kernel/probe_roms.c | 2 +- drivers/bcma/host_pci.c | 7 ++- drivers/crypto/hisilicon/qm.c | 2 +- drivers/crypto/qat/qat_4xxx/adf_drv.c | 7 +-- drivers/crypto/qat/qat_c3xxx/adf_drv.c| 7 +-- drivers/crypto/qat/qat_c62x/adf_drv.c | 7 +-- drivers/crypto/qat/qat_common/adf_aer.c | 10 +-- .../crypto/qat/qat_common/adf_common_drv.h| 2 +- drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 7 +-- drivers/message/fusion/mptbase.c | 7 +-- drivers/message/fusion/mptbase.h | 2 +- drivers/message/fusion/mptctl.c | 4 +- drivers/message/fusion/mptlan.c | 2 +- drivers/misc/cxl/guest.c | 24 --- drivers/misc/cxl/pci.c| 30 + .../ethernet/hisilicon/hns3/hns3_ethtool.c| 2 +- .../ethernet/marvell/prestera/prestera_pci.c | 2 +- drivers/net/ethernet/mellanox/mlxsw/pci.c | 2 +- .../ethernet/netronome/nfp/nfp_net_ethtool.c | 2 +- drivers/pci/iov.c | 25 +--- drivers/pci/pci-driver.c | 45 ++--- drivers/pci/pci.c | 4 +- drivers/pci/pcie/err.c| 36 ++- drivers/pci/xen-pcifront.c| 63 +-- drivers/ssb/pcihost_wrapper.c | 8 ++- drivers/usb/host/xhci-pci.c | 2 +- include/linux/pci.h | 1 - 30 files changed, 166 insertions(+), 167 deletions(-) base-commit: 5816b3e6577eaa676ceb00a848f0fd65fe2adc29 -- 2.30.2
[PATCH v4 7/8] PCI: Replace pci_dev::driver usage by pci_dev::dev.driver
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
---
arch/powerpc/kernel/eeh_driver.c | 10 -
arch/x86/events/intel/uncore.c | 2 +-
arch/x86/kernel/probe_roms.c | 2 +-
drivers/misc/cxl/guest.c | 24 -
drivers/misc/cxl/pci.c | 30 --
drivers/pci/iov.c| 25 ++
drivers/pci/pci-driver.c | 25 +++---
drivers/pci/pci.c| 4 ++--
drivers/pci/pcie/err.c | 36 ++--
drivers/pci/xen-pcifront.c | 4 ++--
drivers/usb/host/xhci-pci.c | 2 +-
11 files changed, 93 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 3eff6a4888e7..350dab18e137 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -104,13 +104,13 @@ static bool eeh_edev_actionable(struct eeh_dev *edev)
*/
static inline struct pci_driver *eeh_pcid_get(struct pci_dev *pdev)
{
- if (!pdev || !pdev->driver)
+ if (!pdev || !pdev->dev.driver)
return NULL;
- if (!try_module_get(pdev->driver->driver.owner))
+ if (!try_module_get(pdev->dev.driver->owner))
return NULL;
- return pdev->driver;
+ return to_pci_driver(pdev->dev.driver);
}
/**
@@ -122,10 +122,10 @@ static inline struct pci_driver *eeh_pcid_get(struct
pci_dev *pdev)
*/
static inline void eeh_pcid_put(struct pci_dev *pdev)
{
- if (!pdev || !pdev->driver)
+ if (!pdev || !pdev->dev.driver)
return;
- module_put(pdev->driver->driver.owner);
+ module_put(pdev->dev.driver->owner);
}
/**
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index c72e368dd164..f1ba6ab2e97e 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -1187,7 +1187,7 @@ static int uncore_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id
* PCI slot and func to indicate the uncore box.
*/
if (id->driver_data & ~0x) {
- struct pci_driver *pci_drv = pdev->driver;
+ struct pci_driver *pci_drv = to_pci_driver(pdev->dev.driver);
pmu = uncore_pci_find_dev_pmu(pdev, pci_drv->id_table);
if (pmu == NULL)
diff --git a/arch/x86/kernel/probe_roms.c b/arch/x86/kernel/probe_roms.c
index 9e1def3744f2..36e84d904260 100644
--- a/arch/x86/kernel/probe_roms.c
+++ b/arch/x86/kernel/probe_roms.c
@@ -80,7 +80,7 @@ static struct resource video_rom_resource = {
*/
static bool match_id(struct pci_dev *pdev, unsigned short vendor, unsigned
short device)
{
- struct pci_driver *drv = pdev->driver;
+ struct pci_driver *drv = to_pci_driver(pdev->dev.driver);
const struct pci_device_id *id;
if (pdev->vendor == vendor && pdev->device == device)
diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
index 186308f1f8eb..d997c9c3ebb5 100644
--- a/drivers/misc/cxl/guest.c
+++ b/drivers/misc/cxl/guest.c
@@ -25,28 +25,32 @@ static void pci_error_handlers(struct cxl_afu *afu,
return;
list_for_each_entry(afu_dev, >phb->bus->devices, bus_list) {
- if (!afu_dev->driver)
+ struct pci_driver *afu_drv;
+
+ if (!afu_dev->dev.driver)
continue;
+ afu_drv = to_pci_driver(afu_dev->dev.driver);
+
switch (bus_error_event) {
case CXL_ERROR_DETECTED_EVENT:
afu_dev->error_state = state;
- if (afu_dev->driver->err_handler &&
- afu_dev->driver->err_handler->error_detected)
-
afu_dev->driver->err_handler->error_detected(afu_dev, state);
+ if (afu_drv->err_handler &&
+ afu_drv->err_handler->error_detected)
+ afu_drv->err_handler->error_detected(afu_dev,
state);
break;
case CXL_SLOT_RESET_EVENT:
afu_dev->error_state = state;
- if (afu_dev->driver->err_handler &&
- afu_dev->driver->err_handler->slot_reset)
-
afu_dev->driver->err_handler->slot_reset(afu_dev);
+ if (afu_drv->err_handler &&
+ afu_drv->err_handler->slot_reset)
+ afu_drv->err_handler->slot_reset(afu_dev);
break;
case CXL_RESUME_EVENT:
- if (afu_dev->driver->err_handler &&
-
[PATCH v4 4/8] PCI: replace pci_dev::driver usage that gets the driver name
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 struct
pci_dev::dev->driver.
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/include/asm/ppc-pci.h | 9 -
drivers/bcma/host_pci.c | 7 ---
drivers/crypto/hisilicon/qm.c| 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
drivers/net/ethernet/marvell/prestera/prestera_pci.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/pci.c| 2 +-
drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 2 +-
drivers/ssb/pcihost_wrapper.c| 8 +---
8 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-pci.h
b/arch/powerpc/include/asm/ppc-pci.h
index 2b9edbf6e929..e8f1795a2acf 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -57,7 +57,14 @@ void eeh_sysfs_remove_device(struct pci_dev *pdev);
static inline const char *eeh_driver_name(struct pci_dev *pdev)
{
- return (pdev && pdev->driver) ? pdev->driver->name : "";
+ if (pdev) {
+ const char *drvstr = dev_driver_string(>dev);
+
+ if (strcmp(drvstr, ""))
+ return drvstr;
+ }
+
+ return "";
}
#endif /* CONFIG_EEH */
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index 69c10a7b7c61..0973022d4b13 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -175,9 +175,10 @@ static int bcma_host_pci_probe(struct pci_dev *dev,
if (err)
goto err_kfree_bus;
- name = dev_name(>dev);
- if (dev->driver && dev->driver->name)
- name = dev->driver->name;
+ name = dev_driver_string(>dev);
+ if (!strcmp(name, ""))
+ name = dev_name(>dev);
+
err = pci_request_regions(dev, name);
if (err)
goto err_pci_disable;
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 369562d34d66..8f361e54e524 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -3085,7 +3085,7 @@ static int qm_alloc_uacce(struct hisi_qm *qm)
};
int ret;
- ret = strscpy(interface.name, pdev->driver->name,
+ ret = strscpy(interface.name, dev_driver_string(>dev),
sizeof(interface.name));
if (ret < 0)
return -ENAMETOOLONG;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 7ea511d59e91..f279edfce3f1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -606,7 +606,7 @@ static void hns3_get_drvinfo(struct net_device *netdev,
return;
}
- strncpy(drvinfo->driver, h->pdev->driver->name,
+ strncpy(drvinfo->driver, dev_driver_string(>pdev->dev),
sizeof(drvinfo->driver));
drvinfo->driver[sizeof(drvinfo->driver) - 1] = '\0';
diff --git a/drivers/net/ethernet/marvell/prestera/prestera_pci.c
b/drivers/net/ethernet/marvell/prestera/prestera_pci.c
index a250d394da38..a8f007f6dad2 100644
--- a/drivers/net/ethernet/marvell/prestera/prestera_pci.c
+++ b/drivers/net/ethernet/marvell/prestera/prestera_pci.c
@@ -720,7 +720,7 @@ static int prestera_fw_load(struct prestera_fw *fw)
static int prestera_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
- const char *driver_name = pdev->driver->name;
+ const char *driver_name = dev_driver_string(>dev);
struct prestera_fw *fw;
int err;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c
b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 13b0259f7ea6..8f306364f7bf 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -1876,7 +1876,7 @@ static void mlxsw_pci_cmd_fini(struct mlxsw_pci
*mlxsw_pci)
static int mlxsw_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*id)
{
- const char *driver_name = pdev->driver->name;
+ const char *driver_name = dev_driver_string(>dev);
struct mlxsw_pci *mlxsw_pci;
int err;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
index 0685ece1f155..23dfb599c828 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
@@ -202,7 +202,7 @@ nfp_get_drvinfo(struct nfp_app *app, struct pci_dev *pdev,
{
char nsp_version[ETHTOOL_FWVERS_LEN] = {};
- strlcpy(drvinfo->driver, pdev->driver->name,
[PATCH v2 2/4] powerpc/cpuhp: BUG -> WARN conversion in offline path
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 changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index defecb3b1b15..08d8072d6e7a 100644 --- a/arch/powerpc/kernel/sysfs.c +++ b/arch/powerpc/kernel/sysfs.c @@ -928,7 +928,8 @@ static int unregister_cpu_online(unsigned int cpu) struct device_attribute *attrs, *pmc_attrs; int i, nattrs; - BUG_ON(!c->hotpluggable); + if (WARN_RATELIMIT(!c->hotpluggable, "cpu %d can't be offlined\n", cpu)) + return -EBUSY; #ifdef CONFIG_PPC64 if (cpu_has_feature(CPU_FTR_SMT)) -- 2.31.1
[PATCH v2 4/4] powerpc/pseries/cpuhp: remove obsolete comment from pseries_cpu_die
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 all to the code that follows. Remove it to prevent confusion. Signed-off-by: Nathan Lynch --- arch/powerpc/platforms/pseries/hotplug-cpu.c | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c index b50f3e9aa259..5ab44600c8d3 100644 --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -137,11 +137,6 @@ static void pseries_cpu_die(unsigned int cpu) cpu, pcpu); } - /* Isolation and deallocation are definitely done by -* drslot_chrp_cpu. If they were not they would be -* done here. Change isolate state to Isolate and -* change allocation-state to Unusable. -*/ paca_ptrs[cpu]->cpu_start = 0; } -- 2.31.1
[PATCH v2 3/4] powerpc/pseries/cpuhp: delete add/remove_by_count code
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 index. This is implemented only by the memory
DLPAR code.
* By count: the lower layer (CPU or memory) is responsible for locating the
specified number of resources to which the action can be applied.
I cannot find any evidence of the "by count" subtype being used by drmgr or
qemu for processors. And when I try to exercise this code, the add case
does not work:
$ ppc64_cpu --smt ; nproc
SMT=8
24
$ printf "cpu remove count 2" > /sys/kernel/dlpar
$ nproc
8
$ printf "cpu add count 2" > /sys/kernel/dlpar
-bash: printf: write error: Invalid argument
$ dmesg | tail -2
pseries-hotplug-cpu: Failed to find enough CPUs (1 of 2) to add
dlpar: Could not handle DLPAR request "cpu add count 2"
$ nproc
8
$ drmgr -c cpu -a -q 2 # this uses the by-index method
Validating CPU DLPAR capability...yes.
CPU 1
CPU 17
$ nproc
24
This is because find_drc_info_cpus_to_add() does not increment drc_index
appropriately during its search.
This is not hard to fix. But the _by_count() functions also have the
property that they attempt to roll back all prior operations if the entire
request cannot be satisfied, even though the rollback itself can encounter
errors. It's not possible to provide transaction-like behavior at this
level, and it's undesirable to have code that can only pretend to do that.
Any users of these functions cannot know what the state of the system is in
the error case. And the error paths are, to my knowledge, impossible to
test without adding custom error injection code.
Summary:
* This code has not worked reliably since its introduction.
* There is no evidence that it is used.
* It contains questionable rollback behaviors in error paths which are
difficult to test.
So let's remove it.
Signed-off-by: Nathan Lynch
Fixes: ac71380071d1 ("powerpc/pseries: Add CPU dlpar remove functionality")
Fixes: 90edf184b9b7 ("powerpc/pseries: Add CPU dlpar add functionality")
Fixes: b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR support for drc-info
property")
Reviewed-by: Daniel Henrique Barboza
Tested-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 218 +--
1 file changed, 2 insertions(+), 216 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 00ac7d7e63e5..b50f3e9aa259 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -741,216 +741,6 @@ static int dlpar_cpu_remove_by_index(u32 drc_index)
return rc;
}
-static int find_dlpar_cpus_to_remove(u32 *cpu_drcs, int cpus_to_remove)
-{
- struct device_node *dn;
- int cpus_found = 0;
- int rc;
-
- /* We want to find cpus_to_remove + 1 CPUs to ensure we do not
-* remove the last CPU.
-*/
- for_each_node_by_type(dn, "cpu") {
- cpus_found++;
-
- if (cpus_found > cpus_to_remove) {
- of_node_put(dn);
- break;
- }
-
- /* Note that cpus_found is always 1 ahead of the index
-* into the cpu_drcs array, so we use cpus_found - 1
-*/
- rc = of_property_read_u32(dn, "ibm,my-drc-index",
- _drcs[cpus_found - 1]);
- if (rc) {
- pr_warn("Error occurred getting drc-index for %pOFn\n",
- dn);
- of_node_put(dn);
- return -1;
- }
- }
-
- if (cpus_found < cpus_to_remove) {
- pr_warn("Failed to find enough CPUs (%d of %d) to remove\n",
- cpus_found, cpus_to_remove);
- } else if (cpus_found == cpus_to_remove) {
- pr_warn("Cannot remove all CPUs\n");
- }
-
- return cpus_found;
-}
-
-static int dlpar_cpu_remove_by_count(u32 cpus_to_remove)
-{
- u32 *cpu_drcs;
- int cpus_found;
- int cpus_removed = 0;
- int i, rc;
-
- pr_debug("Attempting to hot-remove %d CPUs\n", cpus_to_remove);
-
- cpu_drcs = kcalloc(cpus_to_remove, sizeof(*cpu_drcs), GFP_KERNEL);
- if (!cpu_drcs)
- return -EINVAL;
-
- cpus_found = find_dlpar_cpus_to_remove(cpu_drcs, cpus_to_remove);
- if (cpus_found <= cpus_to_remove) {
- kfree(cpu_drcs);
- return -EINVAL;
- }
-
- for (i = 0; i < cpus_to_remove; i++) {
- rc = dlpar_cpu_remove_by_index(cpu_drcs[i]);
- if (rc)
- break;
-
- cpus_removed++;
- }
-
-
[PATCH v2 0/4] CPU DLPAR/hotplug for v5.16
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 Nathan Lynch (4): powerpc/pseries/cpuhp: cache node corrections powerpc/cpuhp: BUG -> WARN conversion in offline path powerpc/pseries/cpuhp: delete add/remove_by_count code powerpc/pseries/cpuhp: remove obsolete comment from pseries_cpu_die arch/powerpc/kernel/sysfs.c | 3 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 298 +-- 2 files changed, 75 insertions(+), 226 deletions(-) -- 2.31.1
[PATCH v2 1/4] powerpc/pseries/cpuhp: cache node corrections
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 returned as siblings of a new CPU node by
ibm,configure-connector are silently discarded; only the CPU node is
added to the device tree.
* Cache nodes which become unreferenced in the processor removal path are
not removed from the device tree. This can lead to duplicate nodes when
the post-migration device tree update code replaces cache nodes.
This is long-standing behavior. Presumably it has gone mostly unnoticed
because the two bugs have the property of obscuring each other in common
simple scenarios (e.g. remove a CPU and add it back). Likely you'd notice
only if you cared to inspect the device tree or the sysfs cacheinfo
information.
Booted with two processors:
$ pwd
/sys/firmware/devicetree/base/cpus
$ ls -1d */
l2-cache@2010/
l2-cache@2011/
l3-cache@3110/
l3-cache@3111/
PowerPC,POWER9@0/
PowerPC,POWER9@8/
$ lsprop */l2-cache
l2-cache@2010/l2-cache
3110 (12560)
l2-cache@2011/l2-cache
3111 (12561)
PowerPC,POWER9@0/l2-cache
2010 (8208)
PowerPC,POWER9@8/l2-cache
2011 (8209)
$ ls /sys/devices/system/cpu/cpu0/cache/
index0 index1 index2 index3
After DLPAR-adding PowerPC,POWER9@10, we see that its associated cache
nodes are absent, its threads' L2+L3 cacheinfo is unpopulated, and it is
missing a cache level in its sched domain hierarchy:
$ ls -1d */
l2-cache@2010/
l2-cache@2011/
l3-cache@3110/
l3-cache@3111/
PowerPC,POWER9@0/
PowerPC,POWER9@10/
PowerPC,POWER9@8/
$ lsprop PowerPC\,POWER9@10/l2-cache
PowerPC,POWER9@10/l2-cache
2012 (8210)
$ ls /sys/devices/system/cpu/cpu16/cache/
index0 index1
$ grep . /sys/kernel/debug/sched/domains/cpu{0,8,16}/domain*/name
/sys/kernel/debug/sched/domains/cpu0/domain0/name:SMT
/sys/kernel/debug/sched/domains/cpu0/domain1/name:CACHE
/sys/kernel/debug/sched/domains/cpu0/domain2/name:DIE
/sys/kernel/debug/sched/domains/cpu8/domain0/name:SMT
/sys/kernel/debug/sched/domains/cpu8/domain1/name:CACHE
/sys/kernel/debug/sched/domains/cpu8/domain2/name:DIE
/sys/kernel/debug/sched/domains/cpu16/domain0/name:SMT
/sys/kernel/debug/sched/domains/cpu16/domain1/name:DIE
When removing PowerPC,POWER9@8, we see that its cache nodes are left
behind:
$ ls -1d */
l2-cache@2010/
l2-cache@2011/
l3-cache@3110/
l3-cache@3111/
PowerPC,POWER9@0/
When DLPAR is combined with VM migration, we can get duplicate nodes. E.g.
removing one processor, then migrating, adding a processor, and then
migrating again can result in warnings from the OF core during
post-migration device tree updates:
Duplicate name in cpus, renamed to "l2-cache@2011#1"
Duplicate name in cpus, renamed to "l3-cache@3111#1"
and nodes with duplicated phandles in the tree, making lookup behavior
unpredictable:
$ lsprop l[23]-cache@*/ibm,phandle
l2-cache@2010/ibm,phandle
2010 (8208)
l2-cache@2011#1/ibm,phandle
2011 (8209)
l2-cache@2011/ibm,phandle
2011 (8209)
l3-cache@3110/ibm,phandle
3110 (12560)
l3-cache@3111#1/ibm,phandle
3111 (12561)
l3-cache@3111/ibm,phandle
3111 (12561)
Address these issues by:
* Correctly processing siblings of the node returned from
dlpar_configure_connector().
* Removing cache nodes in the CPU remove path when it can be determined
that they are not associated with other CPUs or caches.
Use the of_changeset API in both cases, which allows us to keep the error
handling in this code from becoming more complex while ensuring that the
device tree cannot become inconsistent.
Signed-off-by: Nathan Lynch
Fixes: ac71380 ("powerpc/pseries: Add CPU dlpar remove functionality")
Fixes: 90edf18 ("powerpc/pseries: Add CPU dlpar add functionality")
Reviewed-by: Daniel Henrique Barboza
Tested-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 75 ++--
1 file changed, 71 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index d646c22e94ab..00ac7d7e63e5 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -521,6 +521,27 @@ static bool valid_cpu_drc_index(struct device_node
*parent, u32 drc_index)
return found;
}
+static int pseries_cpuhp_attach_nodes(struct device_node *dn)
+{
+ struct of_changeset cs;
+ int ret;
+
+ /*
+* This device node is unattached but may have siblings; open-code the
+* traversal.
+*/
+ for
Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
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: - macmini-intel, Gentoo cross-compiler target: - AMCC PPC405GP wrapper: - cuboot Applied to kernel-v5.2.1-vanilla Attached I report here is the difference between the original file and mine. Thanks guys! Carlo Map 32Mbytes rather than 16MB of memory at startup --- arch/powerpc/kernel/head_40x.S.original 2021-09-27 16:32:04.53600 - +++ arch/powerpc/kernel/head_40x.S 2021-09-27 16:32:04.53200 - @@ -38,6 +38,8 @@ #include #include +#include /* hack, include/linux/sizes.h defines "SZ_16M" */ + #include "head_32.h" /* As with the other PowerPC ports, it is expected that when code @@ -839,18 +841,25 @@ mtspr SPRN_PID,r0 sync - /* Configure and load one entry into TLB slots 63 */ + /* Configure and load one entry into TLB slots 62/63 */ /* hacked */ clrrwi r4,r4,10/* Mask off the real page number */ ori r4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */ clrrwi r3,r3,10/* Mask off the effective page number */ ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M)) -li r0,63/* TLB slot 63 */ - +//-- hack begin - +// TLB 63 is used for first 16M page +// TLB 62 is for the second 16M page +//li r0,63/* TLB slot 63 */ /* original */ +li r0,62/* TLB slot 62 */ /* hacked */ +// -- tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ - +// -- +addis r4,r4,SZ_16M@h /* added, hacked */ +addis r3,r3,SZ_16M@h /* added, hacked */ +//-- hack end - isync /* Establish the exception vector base
Re: [PATCH 2/4] dt-bindings: nintendo-aes: Document the Wii and Wii U AES support
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 +++ > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/crypto/nintendo-aes.yaml > > diff --git a/Documentation/devicetree/bindings/crypto/nintendo-aes.yaml > b/Documentation/devicetree/bindings/crypto/nintendo-aes.yaml > new file mode 100644 > index ..e62a2bfc571c > --- /dev/null > +++ b/Documentation/devicetree/bindings/crypto/nintendo-aes.yaml > @@ -0,0 +1,34 @@ > +# SPDX-License-Identifier: GPL-2.0 Dual license new bindings. checkpatch.pl will tell you this. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/crypto/nintendo-aes.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Nintendo Wii and Wii U AES engine > + > +maintainers: > + - Emmanuel Gil Peyrot > + > +description: |+ > + The AES engine in the Nintendo Wii and Wii U supports the following: > + -- Advanced Encryption Standard (AES) in CBC mode, with 128-bit keys > + > +properties: > + compatible: > +items: > + - const: nintendo,hollywood-aes > + - const: nintendo,latte-aes > + > + reg: > +maxItems: 1 > + > + interrupts: > +description: Not supported yet. > +maxItems: 1 > + > +required: > + - compatible > + - reg > + - interrupts > + > +additionalProperties: false > -- > 2.33.0 > >
Re: [PATCH v2 6/9] PCI: Add pci_find_dvsec_capability to find designated VSEC
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 Capability ID".
> The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
> more vendor specific capabilities that aren't tied to the vendor ID of
> the PCI component.
>
> DVSEC is critical for both the Compute Express Link (CXL) driver as well
> as the driver for OpenCAPI coherent accelerator (OCXL).
Strictly speaking, not really relevant for the commit log.
> Cc: David E. Box
> Cc: Jonathan Cameron
> Cc: Bjorn Helgaas
> Cc: Dan Williams
> Cc: linux-...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andrew Donnellan
> Cc: Lu Baolu
> Reviewed-by: Frederic Barrat
> Signed-off-by: Ben Widawsky
If you want to merge this with the series,
Acked-by: Bjorn Helgaas
Or if you want me to merge this on a branch, let me know.
> ---
> drivers/pci/pci.c | 32
> include/linux/pci.h | 1 +
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ce2ab62b64cf..94ac86ff28b0 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -732,6 +732,38 @@ u16 pci_find_vsec_capability(struct pci_dev *dev, u16
> vendor, int cap)
> }
> EXPORT_SYMBOL_GPL(pci_find_vsec_capability);
>
> +/**
> + * pci_find_dvsec_capability - Find DVSEC for vendor
> + * @dev: PCI device to query
> + * @vendor: Vendor ID to match for the DVSEC
> + * @dvsec: Designated Vendor-specific capability ID
> + *
> + * If DVSEC has Vendor ID @vendor and DVSEC ID @dvsec return the capability
> + * offset in config space; otherwise return 0.
> + */
> +u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
> +{
> + int pos;
> +
> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DVSEC);
> + if (!pos)
> + return 0;
> +
> + while (pos) {
> + u16 v, id;
> +
> + pci_read_config_word(dev, pos + PCI_DVSEC_HEADER1, );
> + pci_read_config_word(dev, pos + PCI_DVSEC_HEADER2, );
> + if (vendor == v && dvsec == id)
> + return pos;
> +
> + pos = pci_find_next_ext_capability(dev, pos,
> PCI_EXT_CAP_ID_DVSEC);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
> +
> /**
> * pci_find_parent_resource - return resource region of parent bus of given
> * region
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cd8aa6fce204..c93ccfa4571b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1130,6 +1130,7 @@ u16 pci_find_ext_capability(struct pci_dev *dev, int
> cap);
> u16 pci_find_next_ext_capability(struct pci_dev *dev, u16 pos, int cap);
> struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
> u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap);
> +u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec);
>
> u64 pci_get_dsn(struct pci_dev *dev);
>
> --
> 2.33.0
>
Re: [RFC PATCH 4/8] powerpc: add CPU field to struct thread_info
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 with this patch or the subsequent
ones cleaning up the task CPU kludge for ppc32? Christophe indicated
that he was happy with it.
Thanks,
Ard.
> ---
> arch/powerpc/include/asm/thread_info.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/thread_info.h
> b/arch/powerpc/include/asm/thread_info.h
> index b4ec6c7dd72e..5725029aaa29 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -47,6 +47,9 @@
> struct thread_info {
> int preempt_count; /* 0 => preemptable,
><0 => BUG */
> +#ifdef CONFIG_SMP
> + unsigned intcpu;
> +#endif
> unsigned long local_flags;/* private flags for thread */
> #ifdef CONFIG_LIVEPATCH
> unsigned long *livepatch_sp;
> --
> 2.30.2
>
[PATCH v2] powerpc/40x: Map 32Mbytes of memory at startup
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 deletion(-) diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index 7d72ee5ab387..e783860bea83 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -650,7 +651,7 @@ start_here: b . /* prevent prefetch past rfi */ /* Set up the initial MMU state so we can do the first level of - * kernel initialization. This maps the first 16 MBytes of memory 1:1 + * kernel initialization. This maps the first 32 MBytes of memory 1:1 * virtual to physical and more importantly sets the cache mode. */ initial_mmu: @@ -687,6 +688,12 @@ initial_mmu: tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ + li r0,62 /* TLB slot 62 */ + addis r4,r4,SZ_16M@h + addis r3,r3,SZ_16M@h + tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ + tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ + isync /* Establish the exception vector base -- 2.31.1
Re: Add Apple M1 support to PASemi i2c driver
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: https://patchwork.ozlabs.org/series/264134/mbox/ Save that to a file and apply with `git am`. eg: $ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/ $ git am mbox It applies cleanly on v5.15-rc3. cheers I was able to patch it with the instructions above. Thanks! I will compile and test the RC3 as soon as possible. -- Christian
Re: [PATCH 1/3] mm: Make generic arch_is_kernel_initmem_freed() do what it says
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 being, the generic version of arch_is_kernel_initmem_freed()
always reports 'false', allthough free_initmem() is generically called
on all architectures.
Therefore, change the generic version of arch_is_kernel_initmem_freed()
to check whether free_initmem() has been called. If so, then check
if a given address falls into init memory.
In order to use function init_section_contains(), the fonction is
moved at the end of asm-generic/section.h
Cc: Gerald Schaefer
Signed-off-by: Christophe Leroy
---
include/asm-generic/sections.h | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index d16302d3eb59..d1e5bb2c6b72 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -172,4 +158,21 @@ static inline bool is_kernel_rodata(unsigned long addr)
addr < (unsigned long)__end_rodata;
}
+/*
+ * Check if an address is part of freed initmem. This is needed on
architectures
+ * with virt == phys kernel mapping, for code that wants to check if an address
+ * is part of a static object within [_stext, _end]. After initmem is freed,
+ * memory can be allocated from it, and such allocations would then have
+ * addresses within the range [_stext, _end].
+ */
+#ifndef arch_is_kernel_initmem_freed
+static inline int arch_is_kernel_initmem_freed(unsigned long addr)
+{
+ if (system_state < SYSTEM_RUNNING)
+ return 0;
+
+ return init_section_contains((void *)addr, 1);
+}
+#endif
This will return an incorrect result for a short period during boot
won't it?
See init/main.c:
static int __ref kernel_init(void *unused)
{
...
free_initmem(); <- memory is freed here
mark_readonly();
/*
* Kernel mappings are now finalized - update the userspace page-table
* to finalize PTI.
*/
pti_finalize();
system_state = SYSTEM_RUNNING;
After free_initmem() we have address ranges that are now freed initmem,
but arch_is_kernel_initmem_freed() continues to return 0 (false) for all
addresses, until we update system_state.
Possibly that doesn't matter for any of the current callers, but it
seems pretty dicey to me.
Yes I saw it but as function core_kernel_text() uses that criteria for
deciding whether a given init text address is valid or not, I thought it
was just ok.
Should we add an intermediate state called for exemple
SYSTEM_FREEING_INIT just before SYSTEM_RUNNING ?
Christophe
Re: [PATCH 1/3] mm: Make generic arch_is_kernel_initmem_freed() do what it says
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 arch_is_kernel_initmem_freed()
> always reports 'false', allthough free_initmem() is generically called
> on all architectures.
>
> Therefore, change the generic version of arch_is_kernel_initmem_freed()
> to check whether free_initmem() has been called. If so, then check
> if a given address falls into init memory.
>
> In order to use function init_section_contains(), the fonction is
> moved at the end of asm-generic/section.h
>
> Cc: Gerald Schaefer
> Signed-off-by: Christophe Leroy
> ---
> include/asm-generic/sections.h | 31 +--
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index d16302d3eb59..d1e5bb2c6b72 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -172,4 +158,21 @@ static inline bool is_kernel_rodata(unsigned long addr)
> addr < (unsigned long)__end_rodata;
> }
>
> +/*
> + * Check if an address is part of freed initmem. This is needed on
> architectures
> + * with virt == phys kernel mapping, for code that wants to check if an
> address
> + * is part of a static object within [_stext, _end]. After initmem is freed,
> + * memory can be allocated from it, and such allocations would then have
> + * addresses within the range [_stext, _end].
> + */
> +#ifndef arch_is_kernel_initmem_freed
> +static inline int arch_is_kernel_initmem_freed(unsigned long addr)
> +{
> + if (system_state < SYSTEM_RUNNING)
> + return 0;
> +
> + return init_section_contains((void *)addr, 1);
> +}
> +#endif
This will return an incorrect result for a short period during boot
won't it?
See init/main.c:
static int __ref kernel_init(void *unused)
{
...
free_initmem(); <- memory is freed here
mark_readonly();
/*
* Kernel mappings are now finalized - update the userspace page-table
* to finalize PTI.
*/
pti_finalize();
system_state = SYSTEM_RUNNING;
After free_initmem() we have address ranges that are now freed initmem,
but arch_is_kernel_initmem_freed() continues to return 0 (false) for all
addresses, until we update system_state.
Possibly that doesn't matter for any of the current callers, but it
seems pretty dicey to me.
cheers
Re: [PATCH v2] ibmveth: Use dma_alloc_coherent() instead of kmalloc/dma_map_single()
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 will not > clear the cache every time. > > Signed-off-by: Cai Huoqing > > [...] Here is the summary with links: - [v2] ibmveth: Use dma_alloc_coherent() instead of kmalloc/dma_map_single() https://git.kernel.org/netdev/net-next/c/4247ef026937 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] Revert "ibmvnic: check failover_pending in login response"
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" > > Signed-off-by: Desnes A. Nunes do Rosario > > [...] Here is the summary with links: - Revert "ibmvnic: check failover_pending in login response" https://git.kernel.org/netdev/net/c/2974b8a691a9 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH] powerpc/40x: Map 32Mbytes of memory at startup
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 a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index 7d72ee5ab387..5fce4680d2d3 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -650,7 +650,7 @@ start_here: b . /* prevent prefetch past rfi */ /* Set up the initial MMU state so we can do the first level of - * kernel initialization. This maps the first 16 MBytes of memory 1:1 + * kernel initialization. This maps the first 32 MBytes of memory 1:1 * virtual to physical and more importantly sets the cache mode. */ initial_mmu: @@ -687,6 +687,12 @@ initial_mmu: tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ + li r0,62 /* TLB slot 62 */ + addis r4,r4,SZ_16M + addis r3,r3,SZ_16M + tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */ + tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */ + isync /* Establish the exception vector base -- 2.31.1
Re: Add Apple M1 support to PASemi i2c driver
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 today to see if I messed up while sending this. > > Error message: > > patching file b/drivers/i2c/busses/i2c-pasemi-core.c (renamed from > a/drivers/i2c/busses/i2c-pasemi.c) > Hunk #3 FAILED at 344. > 1 out of 3 hunks FAILED -- saving rejects to file > b/drivers/i2c/busses/i2c-pasemi-core.c.rej > patching file b/drivers/i2c/busses/i2c-pasemi-core.h > patching file b/drivers/i2c/busses/i2c-pasemi-pci.c > > Please post one patch with all your modifications. > Sure, will do that later as well! Best, Sven
Re: Add Apple M1 support to PASemi i2c driver
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 that to a file and apply with `git am`. eg: $ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/ $ git am mbox It applies cleanly on v5.15-rc3. cheers
Re: [PATCH 00/10] Add Apple M1 support to PASemi i2c driver
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 actually been used since at least > the > iPhone 4S and hasn't changed much since then. > Essentially, there are only a few differences that matter: > > - The controller no longer is a PCI device > - Starting at some iPhone an additional bit in one register > must be set in order to start transmissions. > - The reference clock and hence the clock dividers are different > > In order to add support for a platform device I first replaced PCI-specific > bits and split out the PCI driver to its own file. Then I added support > to make the clock divider configurable and converted the driver to use > managed device resources to make it a bit simpler. > > The Apple and PASemi driver will never be compiled in the same kernel > since the Apple one will run on arm64 while the original PASemi driver > will only be useful on powerpc. > I've thus followed the octeon (mips)/thunderx(arm64) approach to do the > split: I created a -core.c file which contains the shared logic and just > compile that one for both the PASemi and the new Apple driver. This looks all very good to me, I had one very minor comment. Whole series Reviewed-by: Arnd Bergmann
Re: [PATCH 02/10] i2c: pasemi: Use io{read,write}32
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, smbus->size);
> + if (!smbus->ioaddr) {
> + error = -EBUSY;
> + goto out_release_region;
> + }
While this works, I would suggest using the more regular pci_iomap()
or pcim_iomap() helper to turn the port number into an __iomem token.
Arnd
Re: Add Apple M1 support to PASemi i2c driver
> 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
Re: ppc32 doesn't boot when linkaddr=0x00900000
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 straightforward question, but extensive experiments from kernel 4.11 to kernel 5.7.19 haven't shown a really clear, up-to-date answer. In k4.11 .. k5.7.19, when the kernel size is bigger than 8 MB, the final kernel doesn't boot but rather arch/powerpc/boot/main.c dies before the first message from the kernel shows up. Why? ... The following is the same kernel, compiled with the same .config, but with two link_addr values A) with link_addr=0x0080. ... Finalizing device tree... flat tree at 0xf23b80 ... B) with link_addr=0x0080. ... Finalizing device tree... flat tree at 0x1023b80 ... Any ideas? I am lost ... As you can see above, when it works you have "flat tree at 0xf23b80", when it fails you have "flat tree at 0x1023b80". The reason for the failure is likely that ppc 40x only maps 16 Mbytes at startup, so when your device tree is outside that map if fails. See https://elixir.bootlin.com/linux/v5.15-rc2/source/arch/powerpc/kernel/head_40x.S#L656 Called from https://elixir.bootlin.com/linux/v5.15-rc2/source/arch/powerpc/kernel/head_40x.S#L56 As you can see it maps one 16Mbytes page. Allthough I'm not an expert on 40x I think it should be easy to map a second 16Mbytes page to get 32Mbytes mapped. I will send a patch later today for you to test. Christophe
