* [PATCH v2 for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0
From: Tamas K Lengyel @ 2020-05-29 16:22 UTC (permalink / raw)
To: xen-devel
Cc: Anthony PERARD, Andrew Cooper, Tamas K Lengyel, Ian Jackson,
Wei Liu
The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
boolean. This is incorrect and breaks external-only usecases of altp2m that
is set with a value of 2.
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
---
v2: just convert bool to unsigned int
---
tools/libxl/libxl_x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index f8bc828e62..e57f63282e 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -391,7 +391,7 @@ static int hvm_set_conf_params(libxl__gc *gc, uint32_t domid,
libxl_ctx *ctx = libxl__gc_owner(gc);
xc_interface *xch = ctx->xch;
int ret = ERROR_FAIL;
- bool altp2m = info->altp2m;
+ unsigned int altp2m = info->altp2m;
switch(info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
--
2.26.2
^ permalink raw reply related
* Re: almost no CIFS stats?
From: Pavel Shilovsky @ 2020-05-29 16:22 UTC (permalink / raw)
To: Matthias Leopold, ronnie sahlberg; +Cc: Steve French, CIFS
In-Reply-To: <ad562231-c263-aebf-e1bb-a055c3aea211@meduniwien.ac.at>
HI Matthias,
I remember Stats not working on CentOS 7 - showing zeros as you reported.
Adding Ronnie to comment.
--
Best regards,
Pavel Shilovsky
пт, 29 мая 2020 г. в 01:18, Matthias Leopold
<matthias.leopold@meduniwien.ac.at>:
>
> CentOS 7 has kernel 3.10 (modified by Red Hat)
>
> Am 28.05.20 um 23:31 schrieb Steve French:
> > Stats should show counters for most rows. See example below:
> >
> > # cat /proc/fs/cifs/Stats
> > Resources in use
> > CIFS Session: 1
> > Share (unique mount targets): 2
> > SMB Request/Response Buffer: 1 Pool size: 5
> > SMB Small Req/Resp Buffer: 1 Pool size: 30
> > Operations (MIDs): 0
> >
> > 0 session 0 share reconnects
> > Total vfs operations: 36 maximum at one time: 2
> >
> > Max requests in flight: 3
> > 1) \\localhost\test
> > SMBs: 67
> > Bytes read: 90177536 Bytes written: 2
> > Open files: 0 total (local), 0 open on server
> > TreeConnects: 1 total 0 failed
> > TreeDisconnects: 0 total 0 failed
> > Creates: 12 total 0 failed
> > Closes: 13 total 1 failed
> > Flushes: 1 total 0 failed
> > Reads: 22 total 0 failed
> > Writes: 1 total 0 failed
> > Locks: 0 total 0 failed
> > IOCTLs: 1 total 1 failed
> > QueryDirectories: 2 total 0 failed
> > ChangeNotifies: 0 total 0 failed
> > QueryInfos: 12 total 0 failed
> > SetInfos: 2 total 0 failed
> > OplockBreaks: 0 sent 0 failed
> >
> >
> > Are you running an old kernel (pre-5.0 e.g.)?
> >
> > On Thu, May 28, 2020 at 3:39 PM Matthias Leopold
> > <matthias.leopold@meduniwien.ac.at> wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to debug the performance of rsync reading from a Windows 2012
> >> R2 share mounted readonly in CentOS 7. I tried to use cifsiostat, which
> >> doesn't print any stats. I looked into /proc/fs/cifs/Stats and saw that
> >> it contains mostly "0" for counters (I would expect to see some numbers
> >> for eg "Reads"). What am I doing wrong?
> >>
> >> options from /proc/mounts are
> >> ro,relatime,vers=3.0,cache=strict,username=foo,domain=xxx,uid=1706,forceuid,gid=1676,forcegid,addr=10.110.81.122,file_mode=0660,dir_mode=0770,soft,nounix,serverino,mapposix,rsize=61440,wsize=1048576,echo_interval=60,actimeo=1
> >>
> >> thx
> >> Matthias
> >
> >
> >
>
> --
> Matthias Leopold
> IT Systems & Communications
> Medizinische Universität Wien
> Spitalgasse 23 / BT 88 /Ebene 00
> A-1090 Wien
> Tel: +43 1 40160-21241
> Fax: +43 1 40160-921200
^ permalink raw reply
* Re: [PATCHv4 1/2] blk-mq: blk-mq: provide forced completion method
From: Jens Axboe @ 2020-05-29 16:22 UTC (permalink / raw)
To: Keith Busch, linux-nvme, hch, sagi, linux-block; +Cc: alan.adamson
In-Reply-To: <20200529145200.3545747-1-kbusch@kernel.org>
On 5/29/20 8:51 AM, Keith Busch wrote:
> Drivers may need to bypass error injection for error recovery. Rename
> __blk_mq_complete_request() to blk_mq_force_complete_rq() and export
> that function so drivers may skip potential fake timeouts after they've
> reclaimed lost requests.
Applied 1-2, thanks Keith.
--
Jens Axboe
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCHv4 1/2] blk-mq: blk-mq: provide forced completion method
From: Jens Axboe @ 2020-05-29 16:22 UTC (permalink / raw)
To: Keith Busch, linux-nvme, hch, sagi, linux-block; +Cc: alan.adamson
In-Reply-To: <20200529145200.3545747-1-kbusch@kernel.org>
On 5/29/20 8:51 AM, Keith Busch wrote:
> Drivers may need to bypass error injection for error recovery. Rename
> __blk_mq_complete_request() to blk_mq_force_complete_rq() and export
> that function so drivers may skip potential fake timeouts after they've
> reclaimed lost requests.
Applied 1-2, thanks Keith.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-05-29 16:21 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, linux-kernel, Serge Semin, linux-spi, SoC Team,
Mark Brown, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513140031.25633-1-lars.povlsen@microchip.com>
Hello Lars,
On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> This is an add-on series to the main SoC Sparx5 series
> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
>
> The series add support for Sparx5 on top of the existing
> ocelot/jaguar2 spi driver.
>
> It spins off the existing support for the MSCC platforms into a
> separate driver, as adding new platforms from the MSCC/Microchip
> product lines will further complicate (clutter) the original driver.
>
> New YAML dt-bindings are provided for the resulting driver.
>
> It is expected that the DT patches are to be taken directly by the arm-soc
> maintainers.
Regarding our cooperation. It can be implemented as follows. Since your patchset
is less cumbersome than mine and is more ready to be integrated into the generic DW
APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
to be further merged into the kernel version of the driver. After that I'll have
my code altered so it could be applied on top of your patches. When everything
is done we'll have a more comprehensive DW APB SSI driver with poll-based
PIO operations support, new features like rx-delay, etc.
Thank you one more time for the series you've shared with us. Let's see what can
be done to improve it...
-Sergey
>
> Lars Povlsen (10):
> spi: dw: Add support for polled operation via no IRQ specified in DT
> spi: dw: Add support for RX sample delay register
> spi: dw: Add support for client driver memory operations
> dt-bindings: spi: Add bindings for spi-dw-mchp
> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> spi: spi-dw-mchp: Add Sparx5 support
> arm64: dts: sparx5: Add SPI controller
> arm64: dts: sparx5: Add spi-nor support
> arm64: dts: sparx5: Add spi-nand devices
>
> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
> MAINTAINERS | 2 +
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
> arch/mips/configs/generic/board-ocelot.config | 2 +-
> drivers/spi/Kconfig | 7 +
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
> drivers/spi/spi-dw-mmio.c | 93 ----
> drivers/spi/spi-dw.c | 31 +-
> drivers/spi/spi-dw.h | 4 +
> 16 files changed, 644 insertions(+), 107 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> create mode 100644 drivers/spi/spi-dw-mchp.c
>
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-05-29 16:21 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, linux-kernel,
linux-spi, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513140031.25633-1-lars.povlsen@microchip.com>
Hello Lars,
On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> This is an add-on series to the main SoC Sparx5 series
> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
>
> The series add support for Sparx5 on top of the existing
> ocelot/jaguar2 spi driver.
>
> It spins off the existing support for the MSCC platforms into a
> separate driver, as adding new platforms from the MSCC/Microchip
> product lines will further complicate (clutter) the original driver.
>
> New YAML dt-bindings are provided for the resulting driver.
>
> It is expected that the DT patches are to be taken directly by the arm-soc
> maintainers.
Regarding our cooperation. It can be implemented as follows. Since your patchset
is less cumbersome than mine and is more ready to be integrated into the generic DW
APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
to be further merged into the kernel version of the driver. After that I'll have
my code altered so it could be applied on top of your patches. When everything
is done we'll have a more comprehensive DW APB SSI driver with poll-based
PIO operations support, new features like rx-delay, etc.
Thank you one more time for the series you've shared with us. Let's see what can
be done to improve it...
-Sergey
>
> Lars Povlsen (10):
> spi: dw: Add support for polled operation via no IRQ specified in DT
> spi: dw: Add support for RX sample delay register
> spi: dw: Add support for client driver memory operations
> dt-bindings: spi: Add bindings for spi-dw-mchp
> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> spi: spi-dw-mchp: Add Sparx5 support
> arm64: dts: sparx5: Add SPI controller
> arm64: dts: sparx5: Add spi-nor support
> arm64: dts: sparx5: Add spi-nand devices
>
> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
> MAINTAINERS | 2 +
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
> arch/mips/configs/generic/board-ocelot.config | 2 +-
> drivers/spi/Kconfig | 7 +
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
> drivers/spi/spi-dw-mmio.c | 93 ----
> drivers/spi/spi-dw.c | 31 +-
> drivers/spi/spi-dw.h | 4 +
> 16 files changed, 644 insertions(+), 107 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> create mode 100644 drivers/spi/spi-dw-mchp.c
>
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 69/75] x86/realmode: Setup AP jump table
From: Tom Lendacky @ 2020-05-29 16:21 UTC (permalink / raw)
To: Borislav Petkov, Joerg Roedel
Cc: x86, hpa, Andy Lutomirski, Dave Hansen, Peter Zijlstra,
Jiri Slaby, Dan Williams, Juergen Gross, Kees Cook,
David Rientjes, Cfir Cohen, Erdem Aktas, Masami Hiramatsu,
Mike Stunes, Joerg Roedel, linux-kernel, kvm, virtualization
In-Reply-To: <20200529090222.GA9011@zn.tnic>
On 5/29/20 4:02 AM, Borislav Petkov wrote:
> On Tue, Apr 28, 2020 at 05:17:19PM +0200, Joerg Roedel wrote:
>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>
>> Setup the AP jump table to point to the SEV-ES trampoline code so that
>> the APs can boot.
>
> Tom, in his laconic way, doesn't want to explain to us why is this even
> needed...
>
> :)
Looks like some of the detail was lost during the patch shuffling.
Originally (on GitHub) this was the text:
As part of the GHCB specification, the booting of APs under SEV-ES
requires an AP jump table when transitioning from one layer of code to
another (e.g. when going from UEFI to the OS). As a result, each layer
that parks an AP must provide the physical address of an AP jump table
to the next layer using the GHCB MSR.
Upon booting of the kernel, read the GHCB MSR and save the address of
the AP jump table. Under SEV-ES, APs are started using the INIT-SIPI-SIPI
sequence. Before issuing the first SIPI request for an AP, the start eip
is programmed into the AP jump table. Upon issuing the SIPI request, the
AP will awaken and jump to the start eip address programmed into the AP
jump table.
It needs to change "GHCB MSR" to "VMGEXIT MSR protocol", but should cover
what you're looking for.
Thanks,
Tom
>
> /me reads the code
>
> /me reads the GHCB spec
>
> aha, it gets it from the HV. And it can be set by the guest too...
>
> So how about expanding that commit message as to why this is done, why
> needed, etc?
>
> Thx.
>
>> diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
>> index 262f83cad355..1c5cbfd102d5 100644
>> --- a/arch/x86/realmode/init.c
>> +++ b/arch/x86/realmode/init.c
>> @@ -9,6 +9,7 @@
>> #include <asm/realmode.h>
>> #include <asm/tlbflush.h>
>> #include <asm/crash.h>
>> +#include <asm/sev-es.h>
>>
>> struct real_mode_header *real_mode_header;
>> u32 *trampoline_cr4_features;
>> @@ -107,6 +108,11 @@ static void __init setup_real_mode(void)
>> if (sme_active())
>> trampoline_header->flags |= TH_FLAGS_SME_ACTIVE;
>>
>> + if (sev_es_active()) {
>> + if (sev_es_setup_ap_jump_table(real_mode_header))
>> + panic("Failed to update SEV-ES AP Jump Table");
>> + }
>> +
>
> So this function gets slowly sprinkled with
>
> if (sev-something)
> bla
>
> Please wrap at least those last two into a
>
> sev_setup_real_mode()
>
> or so.
>
^ permalink raw reply
* Re: linux-next: Tree for May 14 (objtool 2/2)
From: Randy Dunlap @ 2020-05-29 16:20 UTC (permalink / raw)
To: Kees Cook, Josh Poimboeuf
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, Peter Zijlstra
In-Reply-To: <202005282258.94570AF@keescook>
On 5/28/20 11:06 PM, Kees Cook wrote:
> On Thu, May 28, 2020 at 10:44:04AM -0500, Josh Poimboeuf wrote:
>> On Thu, May 14, 2020 at 09:04:36AM -0700, Randy Dunlap wrote:
>>> On 5/14/20 4:07 AM, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20200512:
>>>>
>>>
>>> on x86_64:
>>>
>>> drivers/ide/ide-tape.o: warning: objtool: ide_tape_discard_merge_buffer.constprop.7()+0x4e: unreachable instruction
>>> drivers/scsi/sd.o: warning: objtool: sd_pr_clear()+0x1e: unreachable instruction
>>> drivers/scsi/sd_zbc.o: warning: objtool: sd_zbc_update_wp_offset_workfn()+0xec: unreachable instruction
>>> drivers/target/target_core_xcopy.o: warning: objtool: target_xcopy_do_work()+0xdd6: unreachable instruction
>>>
>>>
>>> randconfig file is attached.
>>
>> Kees,
>>
>> More UBSAN_TRAP fun. This randconfig has:
>>
>> CONFIG_UBSAN_TRAP=y
>> CONFIG_UBSAN_ALIGNMENT=y
>> # CONFIG_COMPILE_TEST is not set
>
> Ugh, I thought CONFIG_COMPILE_TEST always gets set for randconfig and
> the all*config choices, but now I see that CONFIG_COMPILE_TEST is
> enabled due to the "all" part of the all*config choices. Okay. Big
> hammer:
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 929211039bac..27bcc2568c95 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -63,7 +63,7 @@ config UBSAN_SANITIZE_ALL
> config UBSAN_ALIGNMENT
> bool "Enable checks for pointers alignment"
> default !HAVE_EFFICIENT_UNALIGNED_ACCESS
> - depends on !X86 || !COMPILE_TEST
> + depends on !UBSAN_TRAP
> help
> This option enables the check of unaligned memory accesses.
> Enabling this option on architectures that support unaligned
>
> How about that?
>
Sure, that works. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
--
~Randy
^ permalink raw reply
* Re: [RFC 2/2] io_uring: mark REQ_NOWAIT for a non-mq queue as unspported
From: Jens Axboe @ 2020-05-29 16:20 UTC (permalink / raw)
To: Jeff Moyer; +Cc: Bijan Mottahedeh, io-uring
In-Reply-To: <x49h7vyzsvu.fsf@segfault.boston.devel.redhat.com>
On 5/29/20 9:02 AM, Jeff Moyer wrote:
> Jens Axboe <axboe@kernel.dk> writes:
>
>> On 5/28/20 4:12 PM, Jeff Moyer wrote:
>>> Jens Axboe <axboe@kernel.dk> writes:
>>>
>>>>> poll won't work over dm, so that looks correct. What happens if you edit
>>>>> it and disable poll? Would be curious to see both buffered = 0 and
>>>>> buffered = 1 runs with that.
>>>>>
>>>>> I'll try this here too.
>>>>
>>>> I checked, and with the offending commit reverted, it behaves exactly
>>>> like it should - io_uring doesn't hit endless retries, and we still
>>>> return -EAGAIN to userspace for preadv2(..., RFW_NOWAIT) if not supported.
>>>> I've queued up the revert.
>>>
>>> With that revert, I now see an issue with an xfs file system on top of
>>> an nvme device when running the liburing test suite:
>>>
>>> Running test 500f9fbadef8-test
>>> Test 500f9fbadef8-test failed with ret 130
>>>
>>> That means the test harness timed out, so we never received a
>>> completion.
>>
>> I can't reproduce this. Can you try again, and enable io_uring tracing?
>>
>> # echo 1 > /sys/kernel/debug/tracing/events/io_uring/enable
>>
>> run test
>>
>> send the 'trace' file, or take a look and see what is going on.
>
> I took a look, and it appeared as though the issue was not in the
> kernel. My liburing was not uptodate, and after grabbing the latest,
> the test runs to completion.
OK good, that's a relief!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] block: improve discard bio alignment in __blkdev_issue_discard()
From: Coly Li @ 2020-05-29 16:20 UTC (permalink / raw)
To: Bart Van Assche, linux-block
Cc: Acshai Manoj, Christoph Hellwig, Enzo Matsumiya, Hannes Reinecke,
Jens Axboe, Ming Lei, Xiao Ni
In-Reply-To: <d5d8af86-659f-d2cb-06e7-876c9481f73d@acm.org>
On 2020/5/30 00:17, Bart Van Assche wrote:
> On 2020-05-29 09:03, Coly Li wrote:
>> +static inline unsigned int bio_aligned_discard_max_sectors(
>> + struct request_queue *q)
>> +{
>> + return round_down(UINT_MAX, (q->limits.max_discard_sectors << 9)) >> 9;
>> +}
>
> How about changing '9' into 'SECTOR_SHIFT'?
Sure, I do it in v2. Thanks.
Coly Li
^ permalink raw reply
* Re: [PATCH 1/1] libdmmp: Add support for upcoming json-c 0.14.0.
From: Benjamin Marzinski @ 2020-05-29 16:19 UTC (permalink / raw)
To: Martin Wilck
Cc: dm-devel@redhat.com, xose.vazquez@gmail.com,
besser82@fedoraproject.org, mail@eworm.de
In-Reply-To: <d092428a245e0b5d88b70f03a473d7df7b95cd27.camel@suse.com>
On Fri, May 29, 2020 at 09:12:30AM +0000, Martin Wilck wrote:
> Hi Ben,
>
> On Thu, 2020-05-28 at 23:10 -0500, Benjamin Marzinski wrote:
> > From: Björn Esser <besser82@fedoraproject.org>
> >
> > TRUE/FALSE are not defined anymore. 1 and 0 are used instead.
> > This is backwards compatible, as earlier versions of json-c are
> > using the same integer values in their present definitions.
> >
> > Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
> > ---
> > libdmmp/libdmmp_private.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libdmmp/libdmmp_private.h b/libdmmp/libdmmp_private.h
> > index ac85b63f..4378962b 100644
> > --- a/libdmmp/libdmmp_private.h
> > +++ b/libdmmp/libdmmp_private.h
> > @@ -82,7 +82,7 @@ static out_type func_name(struct dmmp_context *ctx,
> > const char *var_name) { \
> > do { \
> > json_type j_type = json_type_null; \
> > json_object *j_obj_tmp = NULL; \
> > - if (json_object_object_get_ex(j_obj, key, &j_obj_tmp) != TRUE)
> > { \
> > + if (json_object_object_get_ex(j_obj, key, &j_obj_tmp) != 1) { \
> > _error(ctx, "Invalid JSON output from multipathd IPC: "
> > \
> > "key '%s' not found", key); \
> > rc = DMMP_ERR_IPC_ERROR; \
>
> Did you see
> https://www.redhat.com/archives/dm-devel/2020-May/msg00261.html ?
Nope. Overlooked it. My bad. I'm fine with any version that compiles.
Either stdbool or int is fine.
-Ben
>
> This has first been reported to the list by Christian (
> https://www.redhat.com/archives/dm-devel/2020-April/msg00261.html), and
> brought to my attention later by Xose. I personally thought the change
> from boolean to int is a step in the wrong direction, therefore I
> submitted my modified version using stdboolh. If everyone else is fine
> with the int, it's not worth arguing about it.
>
> Regards,
> Martin
>
> PS: Can anyone explain why json-c did this? Looks like a "cause hassle
> for downstream devs and users for no good reason" kind of thing to
> me...
>
> --
> Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
> SUSE Software Solutions Germany GmbH
> HRB 36809, AG Nürnberg GF: Felix
> Imendörffer
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC
From: Paauwe, Bob J @ 2020-05-29 16:19 UTC (permalink / raw)
To: Dhanavanthri, Swathi, intel-gfx@lists.freedesktop.org
In-Reply-To: <20200521064448.29522-1-swathi.dhanavanthri@intel.com>
We've tried this on EHL and it doesn't work.
The intent of the workaround is that the bit must be toggled after all south display registers are
accessed before entering a S0ix state. If any south display register is accessed after this bit is
toggled, it resets things and the bit needs to be toggled again.
When we test this on EHL, the workaround isn't working. Based on some additional testing
It appears that something is accessing a south display register after this point. We need to
find the correct location such that this is the last thing that accesses a south display register.
I suspect that this is also not working for ICL
Bob
--
Bob Paauwe
Bob.J.Paauwe@intel.com
IOTG / Platform Software Engineering
Intel Corp. Folsom, CA
(916) 356-6193
(530) 409-0831 (cell)
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Swathi
> Dhanavanthri
> Sent: Wednesday, May 20, 2020 11:45 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to
> JSP/MCC
>
> This is a permanent w/a for JSL/EHL.This is to be applied to the
> PCH types on JSL/EHL ie JSP/MCC
> Bspec: 52888
>
> v2: Fixed the wrong usage of logical OR(ville)
> v3: Removed extra braces, changed the check(jose)
>
> Signed-off-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 4dc601dffc08..bc82d0d8ad5b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2902,8 +2902,10 @@ static void gen11_display_irq_reset(struct
> drm_i915_private *dev_priv)
> if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> GEN3_IRQ_RESET(uncore, SDE);
>
> - /* Wa_14010685332:icl */
> - if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP) {
> + /* Wa_14010685332:icl,jsl,ehl */
> + if (INTEL_PCH_TYPE(dev_priv) == PCH_ICP ||
> + INTEL_PCH_TYPE(dev_priv) == PCH_JSP ||
> + INTEL_PCH_TYPE(dev_priv) == PCH_MCC) {
> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
> SBCLK_RUN_REFCLK_DIS,
> SBCLK_RUN_REFCLK_DIS);
> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 1/3] dt-bindings: net: wireless: mt76: add power-limits node
From: Felix Fietkau @ 2020-05-29 16:19 UTC (permalink / raw)
To: linux-wireless; +Cc: devicetree
This subnode can be used to set per-rate tx power limits either per
country code / regdomain or globally.
These limits are typically provided by the device manufacturers and are
used to limit sideband emissions and stay within regulatory limits
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
.../bindings/net/wireless/mediatek,mt76.txt | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
index ab7e7a00e534..9d9ace0cfbf9 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
@@ -36,6 +36,7 @@ Optional nodes:
- led: Properties for a connected LED
Optional properties:
- led-sources: See Documentation/devicetree/bindings/leds/common.txt
+- power-limits: contains per-regdomain/channel rate power limit subnodes
&pcie {
pcie0 {
@@ -76,3 +77,49 @@ wmac: wmac@18000000 {
power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
};
+
+
+Subnodes of power-limits:
+
+Properties:
+- country: One or more country codes, as used by the cfg80211 regdomain code
+- regdomain: "FCC", "ETSI" or "JP"
+
+If neither country, nor regdomain is specified, the power limits node is used
+as a fallback when no other subnode matches.
+
+Subnodes txpower-2g, txpower-5g:
+
+Properties:
+- channels: pairs of first and last channel number
+- cck: 4 half-dBm per-rate power limit values
+- ofdm: 8 half-dBm per-rate power limit values
+- mcs:
+ sets of per-rate power limit values for 802.11n/802.11ac rates for
+ multiple channel bandwidth settings.
+ Each set starts with the number of channel bandwidth settings for
+ which the rate set applies, followed by either 8 (MT7603/MT7628) or
+ 10 (all other chips) power limit values.
+ The order of the channel bandwidth settings is: 20, 40, 80, 160 MHz.
+
+
+power-limit example:
+
+power-limits {
+ r0 {
+ regdomain = "FCC";
+ txpower-5g {
+ r1 {
+ channels = <36 48>;
+ ofdm = <23 23 23 23 23 23 23 23>;
+ mcs = <1 23 23 23 23 23 23 23 23 23 23>,
+ <3 22 22 22 22 22 22 22 22 22 22>;
+ };
+ r2 {
+ channels = <100 181>;
+ ofdm = <14 14 14 14 14 14 14 14>;
+ mcs = <4 14 14 14 14 14 14 14 14 14 14>;
+ };
+ };
+ };
+};
--
2.24.0
^ permalink raw reply related
* [PATCH 2/3] mt76: add functions for parsing rate power limits from DT
From: Felix Fietkau @ 2020-05-29 16:19 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20200529161929.24751-1-nbd@nbd.name>
This subnode can be used to set per-rate tx power limits either per
country code / regdomain or globally.
These limits are typically provided by the device manufacturers and are
used to limit sideband emissions and stay within regulatory limits
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 203 ++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76.h | 13 ++
2 files changed, 216 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index c236e303ccfd..334606b07693 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -104,6 +104,209 @@ mt76_eeprom_override(struct mt76_dev *dev)
}
EXPORT_SYMBOL_GPL(mt76_eeprom_override);
+static bool mt76_string_prop_find(struct property *prop, const char *str)
+{
+ const char *cp = NULL;
+
+ if (!prop || !str || !str[0])
+ return false;
+
+ while ((cp = of_prop_next_string(prop, cp)) != NULL)
+ if (!strcasecmp(cp, str))
+ return true;
+
+ return false;
+}
+
+static struct device_node *
+mt76_find_power_limits_node(struct mt76_dev *dev)
+{
+ struct device_node *np = dev->dev->of_node;
+ const char *const region_names[] = {
+ [NL80211_DFS_ETSI] = "etsi",
+ [NL80211_DFS_FCC] = "fcc",
+ [NL80211_DFS_JP] = "jp",
+ };
+ struct device_node *cur, *fallback = NULL;
+ const char *region_name = NULL;
+
+ if (dev->region < ARRAY_SIZE(region_names))
+ region_name = region_names[dev->region];
+
+ np = of_get_child_by_name(np, "power-limits");
+ if (!np)
+ return NULL;
+
+ for_each_child_of_node(np, cur) {
+ struct property *country = of_find_property(cur, "country", NULL);
+ struct property *regd = of_find_property(cur, "regdomain", NULL);
+
+ if (!country && !regd) {
+ fallback = cur;
+ continue;
+ }
+
+ if (mt76_string_prop_find(country, dev->alpha2) ||
+ mt76_string_prop_find(regd, region_name))
+ return cur;
+ }
+
+ return fallback;
+}
+
+static const __be32 *
+mt76_get_of_array(struct device_node *np, char *name, size_t *len, int min)
+{
+ struct property *prop = of_find_property(np, name, NULL);
+
+ if (!prop || !prop->value || prop->length < min * 4)
+ return NULL;
+
+ *len = prop->length;
+
+ return prop->value;
+}
+
+static struct device_node *
+mt76_find_channel_node(struct device_node *np, struct ieee80211_channel *chan)
+{
+ struct device_node *cur;
+ const __be32 *val;
+ size_t len;
+
+ for_each_child_of_node(np, cur) {
+ val = mt76_get_of_array(cur, "channels", &len, 2);
+ if (!val)
+ continue;
+
+ while (len >= 2 * sizeof(*val)) {
+ if (chan->hw_value >= be32_to_cpu(val[0]) &&
+ chan->hw_value <= be32_to_cpu(val[1]))
+ return cur;
+
+ val += 2;
+ len -= 2 * sizeof(*val);
+ }
+ }
+
+ return NULL;
+}
+
+static s8
+mt76_get_txs_delta(struct device_node *np, u8 nss)
+{
+ const __be32 *val;
+ size_t len;
+
+ if (nss >= 4)
+ return 0;
+
+ val = mt76_get_of_array(np, "txs_delta", &len, 3);
+ return be32_to_cpu(val[3 - nss]);
+}
+
+static void
+mt76_apply_array_limit(s8 *pwr, size_t pwr_len, const __be32 *data,
+ s8 target_power, s8 nss_delta, s8 *max_power)
+{
+ int i;
+
+ if (!data)
+ return;
+
+ for (i = 0; i < pwr_len; i++) {
+ pwr[i] = min_t(s8, target_power,
+ be32_to_cpu(data[i]) + nss_delta);
+ *max_power = max(*max_power, pwr[i]);
+ }
+}
+
+s8 mt76_get_rate_power_limits(struct mt76_phy *phy,
+ struct ieee80211_channel *chan,
+ struct mt76_power_limits *dest,
+ s8 target_power)
+{
+ struct mt76_dev *dev = phy->dev;
+ struct device_node *np;
+ const __be32 *val;
+ char name[16];
+ u32 mcs_rates = dev->drv->mcs_rates;
+ char band;
+ size_t len;
+ int i, cur;
+ s8 max_power = 0;
+ s8 txs_delta;
+
+ if (!mcs_rates)
+ mcs_rates = 10;
+
+ memset(dest, target_power, sizeof(*dest));
+
+ if (!IS_ENABLED(CONFIG_OF))
+ return target_power;
+
+ np = mt76_find_power_limits_node(dev);
+ if (!np)
+ return target_power;
+
+ switch (chan->band) {
+ case NL80211_BAND_2GHZ:
+ band = '2';
+ break;
+ case NL80211_BAND_5GHZ:
+ band = '5';
+ break;
+ default:
+ return target_power;
+ }
+
+ snprintf(name, sizeof(name), "txpower-%cg", band);
+ np = of_get_child_by_name(np, name);
+ if (!np)
+ return target_power;
+
+ np = mt76_find_channel_node(np, chan);
+ if (!np)
+ return target_power;
+
+ txs_delta = mt76_get_txs_delta(np, hweight8(phy->antenna_mask));
+
+ val = mt76_get_of_array(np, "cck", &len, ARRAY_SIZE(dest->cck));
+ mt76_apply_array_limit(dest->cck, ARRAY_SIZE(dest->cck), val,
+ target_power, txs_delta, &max_power);
+
+ val = mt76_get_of_array(np, "ofdm", &len, ARRAY_SIZE(dest->ofdm));
+ mt76_apply_array_limit(dest->ofdm, ARRAY_SIZE(dest->ofdm), val,
+ target_power, txs_delta, &max_power);
+
+ val = mt76_get_of_array(np, "mcs", &len, mcs_rates + 1);
+ if (!val)
+ return max_power;
+
+ len /= 4;
+ cur = be32_to_cpu(val[0]);
+ for (i = 0; i < ARRAY_SIZE(dest->mcs); i++) {
+ if (len < mcs_rates + 1)
+ break;
+
+ mt76_apply_array_limit(dest->mcs[i], ARRAY_SIZE(dest->mcs[i]),
+ val + 1, target_power, txs_delta,
+ &max_power);
+ if (--cur > 0)
+ continue;
+
+ val += mcs_rates + 1;
+ len -= mcs_rates + 1;
+ if (!len)
+ break;
+
+ cur = be32_to_cpu(val[0]);
+ }
+
+ return max_power;
+}
+EXPORT_SYMBOL_GPL(mt76_get_rate_power_limits);
+
int
mt76_eeprom_init(struct mt76_dev *dev, int len)
{
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index dfe625a53c63..64cafc0caa33 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -306,6 +306,7 @@ struct mt76_driver_ops {
u32 drv_flags;
u32 survey_flags;
u16 txwi_size;
+ u8 mcs_rates;
void (*update_survey)(struct mt76_dev *dev);
@@ -558,6 +559,7 @@ struct mt76_dev {
struct mt76_rate_power rate_power;
+ char alpha2[3];
enum nl80211_dfs_regions region;
u32 debugfs_reg;
@@ -577,6 +579,12 @@ struct mt76_dev {
};
};
+struct mt76_power_limits {
+ s8 cck[4];
+ s8 ofdm[8];
+ s8 mcs[4][10];
+};
+
enum mt76_phy_type {
MT_PHY_TYPE_CCK,
MT_PHY_TYPE_OFDM,
@@ -959,4 +967,9 @@ struct sk_buff *mt76_mcu_get_response(struct mt76_dev *dev,
void mt76_set_irq_mask(struct mt76_dev *dev, u32 addr, u32 clear, u32 set);
+s8 mt76_get_rate_power_limits(struct mt76_phy *phy,
+ struct ieee80211_channel *chan,
+ struct mt76_power_limits *dest,
+ s8 target_power);
+
#endif
--
2.24.0
^ permalink raw reply related
* [PATCH 3/3] mt76: mt7615: implement support for using DT rate power limits
From: Felix Fietkau @ 2020-05-29 16:19 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20200529161929.24751-1-nbd@nbd.name>
Limits are used to update the channel max_power settings and also passed
to the firmware on channel changes
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
.../net/wireless/mediatek/mt76/mt7615/init.c | 11 +++-
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 61 ++++++++++++++++++-
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index e2d80518e5af..04a32123e7fe 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -234,6 +234,7 @@ void mt7615_init_txpower(struct mt7615_dev *dev,
int delta_idx, delta = mt76_tx_power_nss_delta(n_chains);
u8 *eep = (u8 *)dev->mt76.eeprom.data;
enum nl80211_band band = sband->band;
+ struct mt76_power_limits limits;
u8 rate_val;
delta_idx = mt7615_eeprom_get_power_delta_index(dev, band);
@@ -262,7 +263,11 @@ void mt7615_init_txpower(struct mt7615_dev *dev,
target_power = max(target_power, eep[index]);
}
- target_power = DIV_ROUND_UP(target_power + delta, 2);
+ target_power += delta;
+ target_power = mt76_get_rate_power_limits(&dev->mphy, chan,
+ &limits,
+ target_power);
+ target_power = DIV_ROUND_UP(target_power, 2);
chan->max_power = min_t(int, chan->max_reg_power,
target_power);
chan->orig_mpwr = target_power;
@@ -280,8 +285,12 @@ mt7615_regd_notifier(struct wiphy *wiphy,
struct mt7615_phy *phy = mphy->priv;
struct cfg80211_chan_def *chandef = &mphy->chandef;
+ memcpy(dev->mt76.alpha2, request->alpha2, sizeof(dev->mt76.alpha2));
dev->mt76.region = request->dfs_region;
+ mt7615_init_txpower(dev, &mphy->sband_2g.sband);
+ mt7615_init_txpower(dev, &mphy->sband_5g.sband);
+
if (!(chandef->chan->flags & IEEE80211_CHAN_RADAR))
return;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 6e869b8c5e26..0b1933111004 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -2654,16 +2654,75 @@ static void mt7615_mcu_set_txpower_sku(struct mt7615_phy *phy, u8 *sku)
{
struct mt76_phy *mphy = phy->mt76;
struct ieee80211_hw *hw = mphy->hw;
+ struct mt76_power_limits limits;
+ s8 *limits_array = (s8 *)&limits;
int n_chains = hweight8(mphy->antenna_mask);
int tx_power;
int i;
+ static const u8 sku_mapping[] = {
+#define SKU_FIELD(_type, _field) \
+ [MT_SKU_##_type] = offsetof(struct mt76_power_limits, _field)
+ SKU_FIELD(CCK_1_2, cck[0]),
+ SKU_FIELD(CCK_55_11, cck[2]),
+ SKU_FIELD(OFDM_6_9, ofdm[0]),
+ SKU_FIELD(OFDM_12_18, ofdm[2]),
+ SKU_FIELD(OFDM_24_36, ofdm[4]),
+ SKU_FIELD(OFDM_48, ofdm[6]),
+ SKU_FIELD(OFDM_54, ofdm[7]),
+ SKU_FIELD(HT20_0_8, mcs[0][0]),
+ SKU_FIELD(HT20_32, ofdm[0]),
+ SKU_FIELD(HT20_1_2_9_10, mcs[0][1]),
+ SKU_FIELD(HT20_3_4_11_12, mcs[0][3]),
+ SKU_FIELD(HT20_5_13, mcs[0][5]),
+ SKU_FIELD(HT20_6_14, mcs[0][6]),
+ SKU_FIELD(HT20_7_15, mcs[0][7]),
+ SKU_FIELD(HT40_0_8, mcs[1][0]),
+ SKU_FIELD(HT40_32, ofdm[0]),
+ SKU_FIELD(HT40_1_2_9_10, mcs[1][1]),
+ SKU_FIELD(HT40_3_4_11_12, mcs[1][3]),
+ SKU_FIELD(HT40_5_13, mcs[1][5]),
+ SKU_FIELD(HT40_6_14, mcs[1][6]),
+ SKU_FIELD(HT40_7_15, mcs[1][7]),
+ SKU_FIELD(VHT20_0, mcs[0][0]),
+ SKU_FIELD(VHT20_1_2, mcs[0][1]),
+ SKU_FIELD(VHT20_3_4, mcs[0][3]),
+ SKU_FIELD(VHT20_5_6, mcs[0][5]),
+ SKU_FIELD(VHT20_7, mcs[0][7]),
+ SKU_FIELD(VHT20_8, mcs[0][8]),
+ SKU_FIELD(VHT20_9, mcs[0][9]),
+ SKU_FIELD(VHT40_0, mcs[1][0]),
+ SKU_FIELD(VHT40_1_2, mcs[1][1]),
+ SKU_FIELD(VHT40_3_4, mcs[1][3]),
+ SKU_FIELD(VHT40_5_6, mcs[1][5]),
+ SKU_FIELD(VHT40_7, mcs[1][7]),
+ SKU_FIELD(VHT40_8, mcs[1][8]),
+ SKU_FIELD(VHT40_9, mcs[1][9]),
+ SKU_FIELD(VHT80_0, mcs[2][0]),
+ SKU_FIELD(VHT80_1_2, mcs[2][1]),
+ SKU_FIELD(VHT80_3_4, mcs[2][3]),
+ SKU_FIELD(VHT80_5_6, mcs[2][5]),
+ SKU_FIELD(VHT80_7, mcs[2][7]),
+ SKU_FIELD(VHT80_8, mcs[2][8]),
+ SKU_FIELD(VHT80_9, mcs[2][9]),
+ SKU_FIELD(VHT160_0, mcs[3][0]),
+ SKU_FIELD(VHT160_1_2, mcs[3][1]),
+ SKU_FIELD(VHT160_3_4, mcs[3][3]),
+ SKU_FIELD(VHT160_5_6, mcs[3][5]),
+ SKU_FIELD(VHT160_7, mcs[3][7]),
+ SKU_FIELD(VHT160_8, mcs[3][8]),
+ SKU_FIELD(VHT160_9, mcs[3][9]),
+#undef SKU_FIELD
+ };
tx_power = hw->conf.power_level * 2 -
mt76_tx_power_nss_delta(n_chains);
+
+ tx_power = mt76_get_rate_power_limits(mphy, mphy->chandef.chan,
+ &limits, tx_power);
mphy->txpower_cur = tx_power;
for (i = 0; i < MT_SKU_1SS_DELTA; i++)
- sku[i] = tx_power;
+ sku[i] = limits_array[sku_mapping[i]];
for (i = 0; i < 4; i++) {
int delta = 0;
--
2.24.0
^ permalink raw reply related
* Re: [PATCH 1/2] anqp: refactor to use frame-xchg
From: James Prestwood @ 2020-05-29 16:19 UTC (permalink / raw)
To: iwd
In-Reply-To: <8995436a-a96b-ef56-b99a-0e2ac6f8d00a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]
On Tue, 2020-05-26 at 19:10 -0500, Denis Kenzior wrote:
> Hi James,
>
> <snip>
>
> > > >
> > > > -uint32_t anqp_request(uint32_t ifindex, const uint8_t *addr,
> > > > +bool anqp_request(uint64_t wdev_id, const uint8_t *addr,
> > >
> > > See above for the likely reason why we had this return a uint32_t
> > > originally.
> >
> > I am kinda thinking this should be implemented in frame-xchg since
> > cancellation doesn't even exist at this point. Then we can just
> > give
> > that ID directly to station and ANQP doesnt need to track it.
> >
>
> I'm fine either way. You could in theory do this in anqp.c for now
> and
> just use frame_xchg_stop for the ongoing operation. But adding this
> directly too frame-xchg would be fine as well.
Ok, I put it back in (properly, with a cancel API) to ANQP. I didn't
think about the fact that frame-xchg only handles single requests at a
time, so there isn't a point keeping IDs for requests in frame-xchg.
>
> > > Do we currently send a single ANQP request per network? If so,
> > > maybe
> > > we
> > > can drop this structure completely, by:
> > >
> > > 1. Adding network_get_station() getter if necessary
> > > 2. Using the network object itself as the user_data for
> > > station_anqp_response_cb
> > > 3. Maybe storing pending inside network itself?
> > >
> > > The above would also make it easier to solve the issue of the
> > > user
> > > triggering Connect just when ANQP hasn't been done yet...
> >
> > The tricky part is that ANQP is directly tied to the scan results,
> > so
>
> Hm, how so?
>
> > putting anything in network is difficult. We could have
> > network_set_anqp_pending (or a better name), then if that was set
> > and
> > Connect() came in we would know to wait. But that would get ugly as
> > station would need to detect that a Connect() came in (so another
> > flag
> > in network + getter) while waiting for ANQP and to re-issue the
> > Connect() once ANQP completed.
>
> Well, can't we just check if anqp is pending for the network inside
> network_connect() or so, and if it is, defer taking any action until
> anqp succeeds / fails?
Checking for pending is easy, defering is the hard part. We could set a
flag in network if ANQP is pending, then if/when the network info gets
set by station we could attempt a connect then (basically from inside
network_set_info). But I have a feeling you wont like this, it just
feels wrong.
Then a further issue is how do we ultimately decide when to fail with
NotConfigured if ANQP fails or there is an error? Unless we add some
other mechanism for station to signal that ANQP failed like
network_set_info_failed(). Again doesn't really feel right.
Maybe a per-station watch for ANQP that network can subscribe to?
Network could get notified both if ANQP is being performed and when it
finished.
>
> If that is too complicated, then I guess we have to document that
> .Connect shouldn't be called until KnownNetwork property has been
> signaled and make our auto tests do this as well.
>
> Regards,
> -Denis
^ permalink raw reply
* Re: [PATCH 1/2] ext4: mballoc - prefetching for bitmaps
From: Благодаренко Артём @ 2020-05-29 16:19 UTC (permalink / raw)
To: Alex Zhuravlev; +Cc: linux-ext4@vger.kernel.org
In-Reply-To: <262A2973-9B2D-4DBE-8752-67E91D52C632@whamcloud.com>
Hello Alex,
Some remarks bellow, after code quote.
Also, we have encountered directory creating rate drop with this (not exact this, but Lustre FS version) patch. From 70-80K to 30-40K.
Excluding this patch restore rates to the original values.
I am investigating it now. Alex, do you expect this optimisation has impact to names creation?
Is plenty of files and directories creation corner case for this optimisation?
Thanks,
Best regards,
Artem Blagodarenko.
> On 15 May 2020, at 13:07, Alex Zhuravlev <azhuravlev@whamcloud.com> wrote:
>
> This should significantly improve bitmap loading, especially for flex
> groups as it tries to load all bitmaps within a flex.group instead of
> one by one synchronously.
>
> Prefetching is done in 8 * flex_bg groups, so it should be 8 read-ahead
> reads for a single allocating thread. At the end of allocation the
> thread waits for read-ahead completion and initializes buddy information
> so that read-aheads are not lost in case of memory pressure.
>
> At cr=0 the number of prefetching IOs is limited per allocation context
> to prevent a situation when mballoc loads thousands of bitmaps looking
> for a perfect group and ignoring groups with good chunks.
>
> Together with the patch "ext4: limit scanning of uninitialized groups"
> the mount time (which includes few tiny allocations) of a 1PB filesystem
> is reduced significantly:
>
> 0% full 50%-full unpatched patched
> mount time 33s 9279s 563s
>
> Signed-off-by: Alex Zhuravlev <bzzz@whamcloud.com>
> Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
> ---
> fs/ext4/balloc.c | 12 ++++-
> fs/ext4/ext4.h | 8 +++-
> fs/ext4/mballoc.c | 116 +++++++++++++++++++++++++++++++++++++++++++++-
> fs/ext4/mballoc.h | 2 +
> fs/ext4/sysfs.c | 4 ++
> 5 files changed, 138 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index a32e5f7b5385..6712146195ed 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -413,7 +413,8 @@ static int ext4_validate_block_bitmap(struct super_block *sb,
> * Return buffer_head on success or an ERR_PTR in case of failure.
> */
> struct buffer_head *
> -ext4_read_block_bitmap_nowait(struct super_block *sb, ext4_group_t block_group)
> +ext4_read_block_bitmap_nowait(struct super_block *sb, ext4_group_t block_group,
> + bool ignore_locked)
> {
> struct ext4_group_desc *desc;
> struct ext4_sb_info *sbi = EXT4_SB(sb);
> @@ -444,6 +445,13 @@ ext4_read_block_bitmap_nowait(struct super_block *sb, ext4_group_t block_group)
> if (bitmap_uptodate(bh))
> goto verify;
>
> + if (ignore_locked && buffer_locked(bh)) {
> + /* buffer under IO already, do not wait
> + * if called for prefetching */
> + put_bh(bh);
> + return NULL;
> + }
> +
> lock_buffer(bh);
> if (bitmap_uptodate(bh)) {
> unlock_buffer(bh);
> @@ -534,7 +542,7 @@ ext4_read_block_bitmap(struct super_block *sb, ext4_group_t block_group)
> struct buffer_head *bh;
> int err;
>
> - bh = ext4_read_block_bitmap_nowait(sb, block_group);
> + bh = ext4_read_block_bitmap_nowait(sb, block_group, false);
> if (IS_ERR(bh))
> return bh;
> err = ext4_wait_block_bitmap(sb, block_group, bh);
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 91eb4381cae5..521fbcd8efc7 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1483,6 +1483,8 @@ struct ext4_sb_info {
> /* where last allocation was done - for stream allocation */
> unsigned long s_mb_last_group;
> unsigned long s_mb_last_start;
> + unsigned int s_mb_prefetch;
> + unsigned int s_mb_prefetch_limit;
>
> /* stats for buddy allocator */
> atomic_t s_bal_reqs; /* number of reqs with len > 1 */
> @@ -2420,7 +2422,8 @@ extern struct ext4_group_desc * ext4_get_group_desc(struct super_block * sb,
> extern int ext4_should_retry_alloc(struct super_block *sb, int *retries);
>
> extern struct buffer_head *ext4_read_block_bitmap_nowait(struct super_block *sb,
> - ext4_group_t block_group);
> + ext4_group_t block_group,
> + bool ignore_locked);
> extern int ext4_wait_block_bitmap(struct super_block *sb,
> ext4_group_t block_group,
> struct buffer_head *bh);
> @@ -3119,6 +3122,7 @@ struct ext4_group_info {
> (1 << EXT4_GROUP_INFO_BBITMAP_CORRUPT_BIT)
> #define EXT4_GROUP_INFO_IBITMAP_CORRUPT \
> (1 << EXT4_GROUP_INFO_IBITMAP_CORRUPT_BIT)
> +#define EXT4_GROUP_INFO_BBITMAP_READ_BIT 4
>
> #define EXT4_MB_GRP_NEED_INIT(grp) \
> (test_bit(EXT4_GROUP_INFO_NEED_INIT_BIT, &((grp)->bb_state)))
> @@ -3133,6 +3137,8 @@ struct ext4_group_info {
> (set_bit(EXT4_GROUP_INFO_WAS_TRIMMED_BIT, &((grp)->bb_state)))
> #define EXT4_MB_GRP_CLEAR_TRIMMED(grp) \
> (clear_bit(EXT4_GROUP_INFO_WAS_TRIMMED_BIT, &((grp)->bb_state)))
> +#define EXT4_MB_GRP_TEST_AND_SET_READ(grp) \
> + (test_and_set_bit(EXT4_GROUP_INFO_BBITMAP_READ_BIT, &((grp)->bb_state)))
>
> #define EXT4_MAX_CONTENTION 8
> #define EXT4_CONTENTION_THRESHOLD 2
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index afb8bd9a10e9..ebfe258bfd0f 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -861,7 +861,7 @@ static int ext4_mb_init_cache(struct page *page, char *incore, gfp_t gfp)
> bh[i] = NULL;
> continue;
> }
> - bh[i] = ext4_read_block_bitmap_nowait(sb, group);
> + bh[i] = ext4_read_block_bitmap_nowait(sb, group, false);
> if (IS_ERR(bh[i])) {
> err = PTR_ERR(bh[i]);
> bh[i] = NULL;
> @@ -2127,6 +2127,96 @@ static int ext4_mb_good_group(struct ext4_allocation_context *ac,
> return 0;
> }
>
> +/*
> + * each allocation context (i.e. a thread doing allocation) has own
> + * sliding prefetch window of @s_mb_prefetch size which starts at the
> + * very first goal and moves ahead of scaning.
> + * a side effect is that subsequent allocations will likely find
> + * the bitmaps in cache or at least in-flight.
> + */
> +static void
> +ext4_mb_prefetch(struct ext4_allocation_context *ac,
> + ext4_group_t start)
> +{
> + struct super_block *sb = ac->ac_sb;
> + ext4_group_t ngroups = ext4_get_groups_count(sb);
> + struct ext4_sb_info *sbi = EXT4_SB(sb);
> + struct ext4_group_info *grp;
> + ext4_group_t nr, group = start;
> + struct buffer_head *bh;
> +
Can be useful giving an ability to disable this optimisation? As option, by setting s_mb_prefetch to zero.
Now 0 at s_mb_prefetch allows to skip the optimisation for cr=0 and cr=1.
Something like.
If (sbi->s_mb_prefetch == 0)
return;
Some changes in ext4_mb_prefetch_fini() are also probably required.
> + /* limit prefetching at cr=0, otherwise mballoc can
> + * spend a lot of time loading imperfect groups */
> + if (ac->ac_criteria < 2 && ac->ac_prefetch_ios >= sbi->s_mb_prefetch_limit)
> + return;
A comment above says prefetching is limited for cr=0 but code limit it for cr=0 and cr=1.
Do you need change the comment or code?
> +
> + /* batch prefetching to get few READs in flight */
> + nr = ac->ac_prefetch - group;
> + if (ac->ac_prefetch < group)
> + /* wrapped to the first groups */
> + nr += ngroups;
> + if (nr > 0)
> + return;
> + BUG_ON(nr < 0);
> +
> + nr = sbi->s_mb_prefetch;
> + if (ext4_has_feature_flex_bg(sb)) {
> + /* align to flex_bg to get more bitmas with a single IO */
> + nr = (group / sbi->s_mb_prefetch) * sbi->s_mb_prefetch;
> + nr = nr + sbi->s_mb_prefetch - group;
> + }
> + while (nr-- > 0) {
> + grp = ext4_get_group_info(sb, group);
> +
> + /* prevent expensive getblk() on groups w/ IO in progress */
> + if (EXT4_MB_GRP_TEST_AND_SET_READ(grp))
> + goto next;
> +
> + /* ignore empty groups - those will be skipped
> + * during the scanning as well */
> + if (grp->bb_free > 0 && EXT4_MB_GRP_NEED_INIT(grp)) {
> + bh = ext4_read_block_bitmap_nowait(sb, group, true);
> + if (bh && !IS_ERR(bh)) {
> + if (!buffer_uptodate(bh))
> + ac->ac_prefetch_ios++;
> + brelse(bh);
> + }
> + }
> +next:
> + if (++group >= ngroups)
> + group = 0;
> + }
> + ac->ac_prefetch = group;
> +}
> +
> +static void
> +ext4_mb_prefetch_fini(struct ext4_allocation_context *ac)
> +{
> + struct ext4_group_info *grp;
> + ext4_group_t group;
> + int nr, rc;
> +
> + /* initialize last window of prefetched groups */
> + nr = ac->ac_prefetch_ios;
> + if (nr > EXT4_SB(ac->ac_sb)->s_mb_prefetch)
> + nr = EXT4_SB(ac->ac_sb)->s_mb_prefetch;
> + group = ac->ac_prefetch;
> + if (!group)
> + group = ext4_get_groups_count(ac->ac_sb);
> + group--;
> + while (nr-- > 0) {
> + grp = ext4_get_group_info(ac->ac_sb, group);
> + if (grp->bb_free > 0 && EXT4_MB_GRP_NEED_INIT(grp)) {
> + rc = ext4_mb_init_group(ac->ac_sb, group, GFP_NOFS);
> + if (rc)
> + break;
> + }
> + if (!group)
> + group = ext4_get_groups_count(ac->ac_sb);
> + group--;
> + }
> +}
> +
> static noinline_for_stack int
> ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> {
> @@ -2200,6 +2290,7 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> * from the goal value specified
> */
> group = ac->ac_g_ex.fe_group;
> + ac->ac_prefetch = group;
>
> for (i = 0; i < ngroups; group++, i++) {
> int ret = 0;
> @@ -2211,6 +2302,8 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> if (group >= ngroups)
> group = 0;
>
> + ext4_mb_prefetch(ac, group);
> +
> /* This now checks without needing the buddy page */
> ret = ext4_mb_good_group(ac, group, cr);
> if (ret <= 0) {
> @@ -2283,6 +2376,8 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
> out:
> if (!err && ac->ac_status != AC_STATUS_FOUND && first_err)
> err = first_err;
> + /* use prefetched bitmaps to init buddy so that read info is not lost */
> + ext4_mb_prefetch_fini(ac);
> return err;
> }
>
> @@ -2542,6 +2637,25 @@ static int ext4_mb_init_backend(struct super_block *sb)
> goto err_freebuddy;
> }
>
> + if (ext4_has_feature_flex_bg(sb)) {
> + /* a single flex group is supposed to be read by a single IO */
> + sbi->s_mb_prefetch = 1 << sbi->s_es->s_log_groups_per_flex;
> + sbi->s_mb_prefetch *= 8; /* 8 prefetch IOs in flight at most */
> + } else {
> + sbi->s_mb_prefetch = 32;
> + }
> + if (sbi->s_mb_prefetch > ext4_get_groups_count(sb))
> + sbi->s_mb_prefetch = ext4_get_groups_count(sb);
> + /* now many real IOs to prefetch within a single allocation at cr=0
Do you mean “how many” here? At cr=0 and cr=1?
> + * given cr=0 is an CPU-related optimization we shouldn't try to
> + * load too many groups, at some point we should start to use what
> + * we've got in memory.
> + * with an average random access time 5ms, it'd take a second to get
> + * 200 groups (* N with flex_bg), so let's make this limit 4 */
> + sbi->s_mb_prefetch_limit = sbi->s_mb_prefetch * 4;
> + if (sbi->s_mb_prefetch_limit > ext4_get_groups_count(sb))
> + sbi->s_mb_prefetch_limit = ext4_get_groups_count(sb);
> +
> return 0;
>
> err_freebuddy:
> diff --git a/fs/ext4/mballoc.h b/fs/ext4/mballoc.h
> index 88c98f17e3d9..c96a2bd81f72 100644
> --- a/fs/ext4/mballoc.h
> +++ b/fs/ext4/mballoc.h
> @@ -175,6 +175,8 @@ struct ext4_allocation_context {
> struct page *ac_buddy_page;
> struct ext4_prealloc_space *ac_pa;
> struct ext4_locality_group *ac_lg;
> + ext4_group_t ac_prefetch;
> + int ac_prefetch_ios; /* number of initialied prefetch IO */
> };
>
> #define AC_STATUS_CONTINUE 1
> diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c
> index 04bfaf63752c..5f443f9d54b8 100644
> --- a/fs/ext4/sysfs.c
> +++ b/fs/ext4/sysfs.c
> @@ -240,6 +240,8 @@ EXT4_RO_ATTR_ES_STRING(last_error_func, s_last_error_func, 32);
> EXT4_ATTR(first_error_time, 0444, first_error_time);
> EXT4_ATTR(last_error_time, 0444, last_error_time);
> EXT4_ATTR(journal_task, 0444, journal_task);
> +EXT4_RW_ATTR_SBI_UI(mb_prefetch, s_mb_prefetch);
> +EXT4_RW_ATTR_SBI_UI(mb_prefetch_limit, s_mb_prefetch_limit);
>
> static unsigned int old_bump_val = 128;
> EXT4_ATTR_PTR(max_writeback_mb_bump, 0444, pointer_ui, &old_bump_val);
> @@ -283,6 +285,8 @@ static struct attribute *ext4_attrs[] = {
> #ifdef CONFIG_EXT4_DEBUG
> ATTR_LIST(simulate_fail),
> #endif
> + ATTR_LIST(mb_prefetch),
> + ATTR_LIST(mb_prefetch_limit),
> NULL,
> };
> ATTRIBUTE_GROUPS(ext4);
> --
> 2.21.3
>
^ permalink raw reply
* Re: [PATCH v2 3/6] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables
From: Peter Zijlstra @ 2020-05-29 16:16 UTC (permalink / raw)
To: mingo, will, tglx; +Cc: x86, linux-kernel, a.darwish, rostedt, bigeasy
In-Reply-To: <20200528140946.831087909@infradead.org>
On Thu, May 28, 2020 at 04:05:38PM +0200, Peter Zijlstra wrote:
> +#include <asm/percpu.h>
> +#include <asm/percpu.h>
If we change those to <linux/percpu-defs.h>, in direct conflict with
what the header says about itself, all builds seem to be good again.
s390, sparc64, power64 all build again.
^ permalink raw reply
* Re: [PATCH for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0
From: Tamas K Lengyel @ 2020-05-29 16:17 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Anthony PERARD, Xen-devel, Ian Jackson, Wei Liu
In-Reply-To: <69225f69-3ca0-c759-03a5-60d6464a7eb4@citrix.com>
On Fri, May 29, 2020 at 10:15 AM Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>
> On 29/05/2020 17:06, Tamas K Lengyel wrote:
> > The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> > boolean. This is incorrect and breaks external-only usecases of altp2m that
> > is set with a value of 2.
> >
> > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
>
> Urg yes. Sorry.
>
> However, this doesn't build because there is another use of the altp2m
> variable between the two hunks below, for compatiblity with the older
> altp2mhvm option.
Eh, so much for hastily sending a patch with last minute changes.
>
> I think changing its type just to int out to suffice?
Indeed, that would work as well. Let me just resend with that.
Tamas
^ permalink raw reply
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Rafael J. Wysocki @ 2020-05-29 16:18 UTC (permalink / raw)
To: Lukasz Luba
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Fabio Estevam, Matthias Kaehlcke, Rob Herring,
Amit Kucheria, Lorenzo Pieralisi, Vincent Guittot, Kevin Hilman,
Andy Gross, Daniel Lezcano, steven.price, Chanwoo Choi,
Ingo Molnar, dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide,
Daniel Vetter, Linux PM, linux-arm-msm, Sascha Hauer,
Steven Rostedt, moderated list:ARM/Mediatek SoC...,
Matthias Brugger, Linux OMAP Mailing List, Dietmar Eggemann,
Linux ARM, David Airlie, Tomeu Vizoso, Quentin Perret,
Stephen Boyd, Randy Dunlap, Rafael J. Wysocki,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
Sascha Hauer, Sudeep Holla, patrick.bellasi, Shawn Guo
In-Reply-To: <8fca24a1-93f7-f859-bd1f-b7bf484737f4@arm.com>
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due to devfreq
> > dependencies. The patches from v7 9-14 which change devfreq cooling are
> > going to be sent in separate patch series, just after this set get merged
> > into mainline. These patches related to EM got acks and hopefully can go
> > through linux-pm tree. The later thermal patches will go through thermal
> > tree.
> >
> > The idea and purpose of the Energy Model framework changes:
> > This patch set introduces support for devices in the Energy Model (EM)
> > framework. It will unify the power model for thermal subsystem. It will
> > make simpler to add support for new devices willing to use more
> > advanced features (like Intelligent Power Allocation). Now it should
> > require less knowledge and effort for driver developer to add e.g.
> > GPU driver with simple energy model. A more sophisticated energy model
> > in the thermal framework is also possible, driver needs to provide
> > a dedicated callback function. More information can be found in the
> > updated documentation file.
> >
> > First 7 patches are refactoring Energy Model framework to add support
> > of other devices that CPUs. They change:
> > - naming convention from 'capacity' to 'performance' state,
> > - API arguments adding device pointer and not rely only on cpumask,
> > - change naming when 'cpu' was used, now it's a 'device'
> > - internal structure to maintain registered devices
> > - update users to the new API
> > Patch 8 updates OPP framework helper function to be more generic, not
> > CPU specific.
> >
> > The patch set is based on linux-pm branch linux-next 813946019dfd.
> >
>
> Could you take the patch set via your linux-pm?
I can do that, but I didn't realize that it was targeted at me, so I
need some more time to review the patches.
Thanks!
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v7 0/3] perf arm-spe: Add support for synthetic events
From: Arnaldo Carvalho de Melo @ 2020-05-29 16:18 UTC (permalink / raw)
To: Leo Yan
Cc: Mark Rutland, Al Grant, Mathieu Poirier, Peter Zijlstra,
Will Deacon, linux-kernel, Alexander Shishkin, Ingo Molnar,
James Clark, Namhyung Kim, Jiri Olsa, linux-arm-kernel,
Mike Leach
In-Reply-To: <20200529152800.GB21552@leoy-ThinkPad-X240s>
Em Fri, May 29, 2020 at 11:28:01PM +0800, Leo Yan escreveu:
> Hi James,
>
> On Fri, May 29, 2020 at 03:58:23PM +0100, James Clark wrote:
> > Hi Will and Leo,
> >
> > I've tested this on an Arm N1 machine and it looks good to me.
>
> This is great! Will respin the new patch set with adding your test tag
> and send to ML. Thanks a lot for the effort.
>
> Hi Will, Arnaldo, sorry for late replying you due to other works and
> thanks for suggestions in other emails.
Np, please do it on top of my tmp.perf/core branch, it'll become
perf/core as soon as testing that is ongoing finishes.
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/3] perf arm-spe: Add support for synthetic events
From: Arnaldo Carvalho de Melo @ 2020-05-29 16:18 UTC (permalink / raw)
To: Leo Yan
Cc: James Clark, Will Deacon, Jiri Olsa, Mark Rutland, Peter Zijlstra,
Ingo Molnar, Alexander Shishkin, Al Grant, Namhyung Kim,
linux-arm-kernel, linux-kernel, Mathieu Poirier, Mike Leach
In-Reply-To: <20200529152800.GB21552@leoy-ThinkPad-X240s>
Em Fri, May 29, 2020 at 11:28:01PM +0800, Leo Yan escreveu:
> Hi James,
>
> On Fri, May 29, 2020 at 03:58:23PM +0100, James Clark wrote:
> > Hi Will and Leo,
> >
> > I've tested this on an Arm N1 machine and it looks good to me.
>
> This is great! Will respin the new patch set with adding your test tag
> and send to ML. Thanks a lot for the effort.
>
> Hi Will, Arnaldo, sorry for late replying you due to other works and
> thanks for suggestions in other emails.
Np, please do it on top of my tmp.perf/core branch, it'll become
perf/core as soon as testing that is ongoing finishes.
- Arnaldo
^ permalink raw reply
* Re: [PATCH v3 1/2] PCI: vmd: Filter resource type bits from shadow register
From: Lorenzo Pieralisi @ 2020-05-29 16:18 UTC (permalink / raw)
To: Derrick, Jonathan
Cc: hch@lst.de, linux-pci@vger.kernel.org,
virtualization@lists.linux-foundation.org, helgaas@kernel.org,
andrzej.jakowski@linux.intel.com, qemu-devel@nongnu.org,
alex.williamson@redhat.com
In-Reply-To: <163e8cb37ece0c8daa6d6e5fd7fcae47ba4fa437.camel@intel.com>
On Fri, May 29, 2020 at 03:53:37PM +0000, Derrick, Jonathan wrote:
> On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> > On Wed, May 27, 2020 at 11:02:39PM -0400, Jon Derrick wrote:
> > > Versions of VMD with the Host Physical Address shadow register use this
> > > register to calculate the bus address offset needed to do guest
> > > passthrough of the domain. This register shadows the Host Physical
> > > Address registers including the resource type bits. After calculating
> > > the offset, the extra resource type bits lead to the VMD resources being
> > > over-provisioned at the front and under-provisioned at the back.
> > >
> > > Example:
> > > pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]
> > >
> > > Expected:
> > > pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]
> > >
> > > If other devices are mapped in the over-provisioned front, it could lead
> > > to resource conflict issues with VMD or those devices.
> > >
> > > Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
> > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > > ---
> > > drivers/pci/controller/vmd.c | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > Hi Jon,
> >
> > it looks like I can take this patch for v5.8 whereas patch 2 depends
> > on the QEMU changes acceptance and should probably wait.
> >
> > Please let me know your thoughts asap and I will try to at least
> > squeeze this patch in.
> >
> > Lorenzo
>
> Hi Lorenzo,
>
> This is fine. Please take Patch 1.
> Patch 2 is harmless without the QEMU changes, but may always need a
> different approach.
Pulled patch 1 into pci/vmd, thanks.
Lorenzo
^ permalink raw reply
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Rafael J. Wysocki @ 2020-05-29 16:18 UTC (permalink / raw)
To: Lukasz Luba
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Fabio Estevam, Matthias Kaehlcke, Rob Herring,
Amit Kucheria, Lorenzo Pieralisi, Kevin Hilman, Andy Gross,
Daniel Lezcano, steven.price, Chanwoo Choi, Ingo Molnar,
dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide, Daniel Vetter,
Linux PM, linux-arm-msm, Sascha Hauer, Steven Rostedt,
moderated list:ARM/Mediatek SoC..., Matthias Brugger,
Linux OMAP Mailing List, Dietmar Eggemann, Linux ARM,
David Airlie, Tomeu Vizoso, Quentin Perret, Stephen Boyd,
Randy Dunlap, Rafael J. Wysocki, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz, Sascha Hauer, Sudeep Holla,
patrick.bellasi, Shawn Guo
In-Reply-To: <8fca24a1-93f7-f859-bd1f-b7bf484737f4@arm.com>
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due to devfreq
> > dependencies. The patches from v7 9-14 which change devfreq cooling are
> > going to be sent in separate patch series, just after this set get merged
> > into mainline. These patches related to EM got acks and hopefully can go
> > through linux-pm tree. The later thermal patches will go through thermal
> > tree.
> >
> > The idea and purpose of the Energy Model framework changes:
> > This patch set introduces support for devices in the Energy Model (EM)
> > framework. It will unify the power model for thermal subsystem. It will
> > make simpler to add support for new devices willing to use more
> > advanced features (like Intelligent Power Allocation). Now it should
> > require less knowledge and effort for driver developer to add e.g.
> > GPU driver with simple energy model. A more sophisticated energy model
> > in the thermal framework is also possible, driver needs to provide
> > a dedicated callback function. More information can be found in the
> > updated documentation file.
> >
> > First 7 patches are refactoring Energy Model framework to add support
> > of other devices that CPUs. They change:
> > - naming convention from 'capacity' to 'performance' state,
> > - API arguments adding device pointer and not rely only on cpumask,
> > - change naming when 'cpu' was used, now it's a 'device'
> > - internal structure to maintain registered devices
> > - update users to the new API
> > Patch 8 updates OPP framework helper function to be more generic, not
> > CPU specific.
> >
> > The patch set is based on linux-pm branch linux-next 813946019dfd.
> >
>
> Could you take the patch set via your linux-pm?
I can do that, but I didn't realize that it was targeted at me, so I
need some more time to review the patches.
Thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2] fpga: stratix10-soc: remove the pre-set reconfiguration condition
From: Russ Weight @ 2020-05-29 16:18 UTC (permalink / raw)
To: Richard Gong, mdf; +Cc: linux-fpga, linux-kernel, dinguyen, Richard Gong
In-Reply-To: <1d9b21df-7421-b25e-5139-f297e24d99d4@linux.intel.com>
Minor comment below.
- Russ
On 5/29/20 6:15 AM, Richard Gong wrote:
> Hi Moritz,
>
> Sorry for asking.
>
> When you get chance, can you review my version 2 patch submitted on
> 05/15/20?
>
> Regards,
> Richard
>
> On 5/15/20 9:35 AM, richard.gong@linux.intel.com wrote:
>> From: Richard Gong <richard.gong@intel.com>
>>
>> The reconfiguration mode is pre-set by driver as the full
>> reconfiguration.
>> As a result, user have to change code and recompile the drivers if he or
>> she wants to perform a partial reconfiguration. Removing the pre-set
>> reconfiguration condition so that user can select full or partial
>> reconfiguration via overlay device tree without recompiling the drivers.
>>
>> Also add an error message if the configuration request is failure.
s/is failure/fails/
>>
>> Signed-off-by: Richard Gong <richard.gong@intel.com>
>> ---
>> v2: define and use constant values
>> ---
>> drivers/fpga/stratix10-soc.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
>> index 44b7c56..4d52a80 100644
>> --- a/drivers/fpga/stratix10-soc.c
>> +++ b/drivers/fpga/stratix10-soc.c
>> @@ -14,9 +14,13 @@
>> /*
>> * FPGA programming requires a higher level of privilege (EL3), per
>> the SoC
>> * design.
>> + * SoC firmware supports full and partial reconfiguration.
>> */
>> #define NUM_SVC_BUFS 4
>> #define SVC_BUF_SIZE SZ_512K
>> +#define FULL_RECONFIG_FLAG 0
>> +#define PARTIAL_RECONFIG_FLAG 1
>> +
>> /* Indicates buffer is in use if set */
>> #define SVC_BUF_LOCK 0
>> @@ -182,12 +186,12 @@ static int s10_ops_write_init(struct
>> fpga_manager *mgr,
>> uint i;
>> int ret;
>> - ctype.flags = 0;
>> if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> dev_dbg(dev, "Requesting partial reconfiguration.\n");
>> - ctype.flags |= BIT(COMMAND_RECONFIG_FLAG_PARTIAL);
>> + ctype.flags = PARTIAL_RECONFIG_FLAG;
>> } else {
>> dev_dbg(dev, "Requesting full reconfiguration.\n");
>> + ctype.flags = FULL_RECONFIG_FLAG;
>> }
>> reinit_completion(&priv->status_return_completion);
>> @@ -210,6 +214,7 @@ static int s10_ops_write_init(struct fpga_manager
>> *mgr,
>> ret = 0;
>> if (!test_and_clear_bit(SVC_STATUS_OK, &priv->status)) {
>> + dev_err(dev, "RECONFIG_REQUEST failed\n");
>> ret = -ETIMEDOUT;
>> goto init_done;
>> }
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.