Re: [PATCH] can: mcp251xfd: fix wrong check in mcp251xfd_handle_rxif_one
On 1/13/21 8:31 AM, Qinglang Miao wrote:
> If alloc_canfd_skb returns NULL, 'cfg' is an uninitialized
> variable, so we should check 'skb' rather than 'cfd' after
> calling alloc_canfd_skb(priv->ndev, ).
>
> Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI
> CAN")
> Signed-off-by: Qinglang Miao
applied to linux-can/testing
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: OpenPGP digital signature
Re: Old platforms: bring out your dead
On 1/12/21 4:46 PM, Linus Walleij wrote: > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz > wrote: > >> Yeah, I have the same impression that's the strong commercial interest pushes >> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like >> they're motivated by corporate decisions. >> >> There has to be a healthy balance between hobbyist and commercial use. I >> understand >> that from a commercial point of view, it doesn't make much sense to run Linux >> on a 30-year-old computer. But it's a hobbyist project for many people and >> hacking >> Linux stuff for these old machines has a very entertaining and educational >> factor. > > This is actually one of the most interesting things written in this > discussion. > > I have both revamped and deleted subarchitectures in the ARM tree. We > never deleted anyone's pet project *unless* they were clearly unwilling to > work on it (such as simply testning new patches) and agreed that it will > not go on. Another fun aspect of old hardware is it serves as prior art for patents. The j-core hardware implementation schedule has in part been driven by specific patents expiring, as in "we can't do $FEATURE until $DATE". It's much easier to nip a patent suit in the bud if you can go "here is functionally equivalent hardware from the past, dates the specifications were published, and the specific patents on the technology which have now expired". We're a little overscheduled and not always _prompt_ about it, but for example the reason we couldn't do full 6-wire sd 1.0 in the first j-core SOC release (and had to implement a painfully slow mmc bus instead) is the patents hadn't expired yet. > That said there are a three things that people should really be doing if they > want to keep their pet archs/subarchs around as good community > members, and they are in essence to: > > 1. Test and review/ack patches that others make I'm trying. :) > 2. Migrate existing drivers to newly appeared and > appropriate subsystems (I think there are some hacky heartbeat LED > drivers down in arch/* for example) there is also the feature matrix > core maintainers like and which appears if you type > Documentation/features/list-arch.sh > would be nice if you work on them if you can support them! > Or at least take a look. For 3 years in the 1990's SuperH was the best-selling processor in the world, and that's left the architecture with a bunch of legacy boards that aren't easily available to us. I regression test a current kernel build under qemu every month or two, and have portable USB-powered boards for the j-core stuff. When I did an sh4 porting contract in 2018 I got that board updated to a current-ish kernel (3 versions back from then-current it hit some intermittent nor flash filesystem corruption that only occurred intermittently under sustained load; had to ship so I backed off one version and never tracked it down). But these days I'm not always on the same continent as my two actual sh4 hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is all j-core stuff not sh4. Testing that a basic superh system still builds and boots under qemu and j-core I can commit to doing regularly. Testing specific hardware devices on boards I don't regularly use is a lot harder. > 3. Migrate old systems to use the >contemporary hardware descriptions (such as device tree or ACPI) >because it makes things so much easier to maintain. Some >upfront work, but a great win for everyone. Especially for >subsystem maintainers. We did that one for our SOC. We haven't ported a lot of legacy boards because we can't easily test most of them. > And if your arch uses highmem then please get rid of highmem. I'm > trying to do this a bit right now for ARM let's see how it goes. I don't believe it does? (We haven't got any configs using it, anyway...) > I understand that for some maintainers time is a factor and this list > feels stressful. I'd say relax, but it'd be nice if you have a TODO that > you cross items off of. My todo list runneth over. One of our perpetual todo list items is "collate todo lists"... > Just my €0.01 > Linus Walleij Rob
[git pull] habanalabs fixes for 5.11-rc4
Hi Greg, This pull request contains three important bug fixes for 5.11-rc4. Basically the driver won't work without the dma address fix, and IMO the two other fixes are also improtant enough to be included at this stage. Thanks, Oded The following changes since commit f970d1d01af8606233f47901c1cf39f3ae21fd74: Merge tag 'phy-fixes-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next (2021-01-11 15:37:40 +0100) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git tags/misc-habanalabs-fixes-2021-01-13 for you to fetch changes up to 9488307a5559255f2fc9a3ab61e1c31e243ca7c6: habanalabs: prevent soft lockup during unmap (2021-01-12 15:00:10 +0200) This tag contains the following bug fixes: - Fix the dma address that is passed to dma_mmap_coherent. We passed an address that includes an offset that is needed by our device and that caused dma_mmap_coherent to do an errounous mapping. - Fix the reset process in case failures happen during the reset process. Without this fix, if the user would have asked to perform reset after the previous reset failed he would get a kernel panic - WA to prevent soft lockup BUG during unmap of host memory. In case of tens of thousands of mappings, the unmapping can take a long time that exceeds the soft lockup timeout. This WA adds a small sleep every 32K page unmappings to prevent that. Oded Gabbay (3): habanalabs: fix dma_addr passed to dma_mmap_coherent habanalabs: fix reset process in case of failures habanalabs: prevent soft lockup during unmap drivers/misc/habanalabs/common/device.c | 2 +- drivers/misc/habanalabs/common/habanalabs.h | 1 + drivers/misc/habanalabs/common/memory.c | 10 -- drivers/misc/habanalabs/common/mmu.c| 6 +++--- drivers/misc/habanalabs/common/mmu_v1.c | 12 ++-- drivers/misc/habanalabs/gaudi/gaudi.c | 3 ++- drivers/misc/habanalabs/goya/goya.c | 3 ++- 7 files changed, 27 insertions(+), 10 deletions(-)
Re: "UBSAN: shift-out-of-bounds in mceusb_dev_recv" should share the same root cause with "UBSAN: shift-out-of-bounds in mceusb_dev_printdata"
On Wed, Jan 13, 2021 at 01:04:44PM +0800, 慕冬亮 wrote:
> Hi developers,
>
> I found that "UBSAN: shift-out-of-bounds in mceusb_dev_recv" and
> "UBSAN: shift-out-of-bounds in mceusb_dev_printdata" should share the
> same root cause.
> The reason is that the PoCs after minimization has a high similarity
> with the other. And their stack trace only diverges at the last
> function call. The following is some analysis for this bug.
>
> The following code in the mceusb_process_ir_data is the vulnerable
> --
> for (; i < buf_len; i++) {
> switch (ir->parser_state) {
> case SUBCMD:
> ir->rem = mceusb_cmd_datasize(ir->cmd, ir->buf_in[i]);
> mceusb_dev_printdata(ir, ir->buf_in, buf_len, i - 1,
>ir->rem + 2, false);
> if (i + ir->rem < buf_len)
> mceusb_handle_command(ir, >buf_in[i - 1]);
> --
>
> The first report crashes at a shift operation(1<<*hi) in
> mceusb_handle_command.
> --
> static void mceusb_handle_command(struct mceusb_dev *ir, u8 *buf_in)
> {
> u8 *hi = _in[2]; /* read only when required */
> if (cmd == MCE_CMD_PORT_SYS) {
> switch (subcmd) {
> case MCE_RSP_GETPORTSTATUS:
> if (buf_in[5] == 0)
> ir->txports_cabled |= 1 << *hi;
> --
>
> The second report crashes at another shift operation (1U << data[0])
> in mceusb_dev_printdata.
> --
> static void mceusb_dev_printdata(struct mceusb_dev *ir, u8 *buf, int buf_len,
> int offset, int len, bool out)
> {
> data = [offset] + 2;
>
> period = DIV_ROUND_CLOSEST((1U << data[0] * 2) *
> (data[1] + 1), 10);
> --
>
> >From the analysis, we can know the data[0] and *hi access the same
> memory cell - ``ir->buf_in[i+1]``. So the root cause should be that it
> misses the check of ir->buf_in[i+1].
>
> For the patch of this bug, there is one from anant.thazhema...@gmail.com:
> --
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index f1dbd059ed08..79de721b1c4a 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -1169,7 +1169,7 @@ static void mceusb_handle_command(struct
> mceusb_dev *ir, u8 *buf_in)
> switch (subcmd) {
> /* the one and only 5-byte return value command */
> case MCE_RSP_GETPORTSTATUS:
> - if (buf_in[5] == 0)
> + if ((buf_in[5] == 0) && (*hi <= 32))
> ir->txports_cabled |= 1 << *hi;
> break;
> --
> I tried this patch in the second crash report and found it does not
> work. I think we should add another filter for the value in
> ``ir->buf_in[i+1]``.
>
> With this grouping, I think developers can take into consideration the
> issue in mceusb_dev_printdata and generate a complete patch for this
> bug.
Why not create a patch yourself and submit it? That way you get the
correct credit for solving the problem.
thanks,
greg k-h
Re: [RFC 1/1] s390/pci: expose UID checking state in sysfs
On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>> We use the UID of a zPCI adapter, or the UID of the function zero if
>> there are multiple functions in an adapter, as PCI domain if and only if
>> UID Checking is turned on.
>> Otherwise we automatically generate domains as devices appear.
>>
>> The state of UID Checking is thus essential to know if the PCI domain
>> will be stable, yet currently there is no way to access this information
>> from userspace.
>> So let's solve this by showing the state of UID checking as a sysfs
>> attribute in /sys/bus/pci/uid_checking
>
> Cosmetic: can't tell if the above is two paragraphs separated by blank
> lines or four separated by either blank lines or short last lines.
> Please separate or reflow to avoid the ambiguity.
Thanks, you're right I split it in 3 proper paragraphs now.
Also the commit message was out of sync with the documentation,
cover letter and code. This version actually uses
/sys/bus/pci/zpci/uid_checking sorry about that.
>
> I don't have any input on the s390 issues, and I assume this will go
> via the s390 tree.
>
>> Signed-off-by: Niklas Schnelle
>> ---
>> Documentation/ABI/testing/sysfs-bus-pci | 11
>> arch/s390/include/asm/pci.h | 3 +++
>> arch/s390/pci/pci.c | 4 +++
>> arch/s390/pci/pci_sysfs.c | 34 +
>> 4 files changed, 52 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-pci
>> b/Documentation/ABI/testing/sysfs-bus-pci
>> index 25c9c39770c6..a174aac0ebb0 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-pci
>> +++ b/Documentation/ABI/testing/sysfs-bus-pci
>> @@ -375,3 +375,14 @@ Description:
>> The value comes from the PCI kernel device state and can be one
>> of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold".
>> The file is read only.
>> +What: /sys/bus/pci/zpci/uid_checking
>> +Date: December 2020
>> +Contact:Niklas Schnelle
>> +Description:
>> +This attribute exposes the global state of UID Checking on
>> +an s390 Linux system. If UID Checking is on this file
>> +contains '1' otherwise '0'. If UID Checking is on the UID of
>> +a zPCI device, or the UID of function zero for a multi-function
>> +device will be used as its PCI Domain number. If UID Checking
>> +is off PCI Domain numbers are generated automatically and
>> +are not stable across reboots.
>> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
>> index 212628932ddc..3cfa6cc701ba 100644
>> --- a/arch/s390/include/asm/pci.h
>> +++ b/arch/s390/include/asm/pci.h
>> @@ -285,6 +285,9 @@ void zpci_debug_exit_device(struct zpci_dev *);
>> /* Error reporting */
>> int zpci_report_error(struct pci_dev *, struct zpci_report_error_header *);
... snip ...
>> +
>> +/* Global zPCI attributes */
>> +static ssize_t uid_checking_show(struct kobject *kobj,
>> + struct kobj_attribute *attr, char *buf)
>> +{
>> +return sprintf(buf, "%i\n", zpci_unique_uid);
>> +}
>> +
>> +static struct kobj_attribute sys_zpci_uid_checking_attr =
>> +__ATTR(uid_checking, 0444, uid_checking_show, NULL);
>
> Use DEVICE_ATTR_RO instead of __ATTR.
It's my understanding that DEVICE_ATTR_* is only for
per device attributes. This one is global for the entire
Z PCI. I just tried with BUS_ATTR_RO instead
and that works but only if I put the attribute at
/sys/bus/pci/uid_checking instead of with a zpci
subfolder. This path would work for us too, we
currently don't have any other global attributes
that we are planning to expose but those could of
course come up in the future.
>
... snip ...
>>
Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller
On 2021/1/12 21:55, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown)
> wrote:
>> On 2021/1/12 16:46, Arnd Bergmann wrote:
>>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei wrote:
>>>
+---
+$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon L3 cache controller
+
+maintainers:
+ - Wei Xu
+
+description: |
+ The Hisilicon L3 outer cache controller supports a maximum of 36-bit
physical
+ addresses. The data cached in the L3 outer cache can be operated based
on the
+ physical address range or the entire cache.
+
+properties:
+ compatible:
+items:
+ - const: hisilicon,l3cache
+
>>>
>>> The compatible string needs to be a little more specific, I'm sure
>>> you cannot guarantee that this is the only L3 cache controller ever
>>> designed in the past or future by HiSilicon.
>>>
>>> Normally when you have an IP block that is itself unnamed but that is
>>> specific
>>> to one or a few SoCs but that has no na, the convention is to include the
>>> name
>>> of the first SoC that contained it.
>>
>> Right, thanks for your suggestion, I will rename it to
>> "hisilicon,hi1381-l3cache"
>> and "hisilicon,hi1215-l3cache".
Sorry, Just received a response from the hardware developers, the SoC names
need to
be changed:
hi1381 --> kunpeng509
hi1215 --> kunpeng506
So I want to rename the compatible string to "hisilicon,kunpeng-l3v1", Kunpeng
L3
cache controller version 1. This is enough to distinguish other versions of
cache
controller. It also facilitates the naming of the config option and files.
>
> Sounds good.
>
>>> Can you share which products actually use this L3 cache controller?
>>
>> This L3 cache controller is used on Hi1381 and Hi1215 board. I don't know
>> where
>> these two boards are used. Our company is too large. Software is delivered
>> level
>> by level. I'm only involved in the Kernel-related part.
>>
>>>
>>> On a related note, what does the memory map look like on this chip?
>>
>> memory@a0 {
>> device_type = "memory";
>> reg = <0x0 0xa0 0x0 0x1aa0>, <0x1 0xe000 0x0 0x1d00>,
>> <0x0 0x1f40 0x0 0xb5c0>;
>> };
>>
>> Currently, the DTS is being maintained by ourselves, I'll try to upstream it
>> later.
>>
>>> Do you support more than 4GB of total installed memory? If you
>>
>> Currently, the total size does not exceed 4 GB. However, the physical
>> address is wider than 32 bits.
>
> Ok, so it appears that the memory is actually contiguous in the first
> 3.5GB (with a few holes), plus the remaining 0.5GB being offset in
> the physical memory by 4GB (starting at 0x1e000 instead of
> 0xe000), presumably to allow the use of 32-bit DMA addresses.
>
> This works fine for the moment, but it does require support for
> a nonlinear virt_to_phys()/phys_to_virt() translation after highmem
> gets removed, and you would get at most 3.75GB anyway, so it
> might be easier at that point to just drop the entire last block at
> 0x1e000, but this will depend on how well we get the 4G:4G
> code to work, and whether the users will still need kernel updates for
> this platform then.>
> Arnd
>
> .
>
Re: [PATCH] module: invoke kobject uevent before sending LIVE notification
On Wed, Jan 13, 2021 at 01:33:10AM +0100, Adam Zabrocki wrote:
> The recent change "module: delay kobject uevent until after module init
> call", while helping avoid a race between udev/systemd and the module
> loader, made it unnecessarily more difficult to monitor kernel module
> integrity by out-of-tree projects such as Linux Kernel Runtime Guard.
We don't support out-of-tree kernel code, sorry.
> Specifically, that change delayed the kobject uevent unnecessarily too far,
> to until after sending a MODULE_STATE_LIVE notification. As the uevent
> modifies internal state of the KOBJ itself, this violated the assumption
> (non-guaranteed yet handy while we can maintain it) that the KOBJ remains
> consistent and can be integrity-checked as soon as the module is LIVE.
>
> To make all of these projects happy at once, move the kobject KOBJ_ADD
> uevent to just before sending the MODULE_STATE_LIVE notification.
>
> Fixes: 38dc717e9715 ("module: delay kobject uevent until after module init
> call")
> Signed-off-by: Adam Zabrocki
> ---
> kernel/module.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 4bf30e4b3eaa..7d56b1b07237 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3681,14 +3681,14 @@ static noinline int do_init_module(struct module *mod)
> dump_stack();
> }
>
> + /* Delay uevent until module has finished its init routine */
> + kobject_uevent(>mkobj.kobj, KOBJ_ADD);
> +
> /* Now it's a first class citizen! */
> mod->state = MODULE_STATE_LIVE;
> blocking_notifier_call_chain(_notify_list,
> MODULE_STATE_LIVE, mod);
>
> - /* Delay uevent until module has finished its init routine */
> - kobject_uevent(>mkobj.kobj, KOBJ_ADD);
> -
No, the code is correct as-is, userspace should be told _after_ the
kernel itself has handled all of the needed housekeeping of the module
being added.
so consider this:
Nacked-by: Greg Kroah-Hartman
Re: [patch 1/4] sparc/mm/highmem: Flush cache and TLB
On 2021-01-12 18:01, Thomas Gleixner wrote:
The recent conversion to the generic kmap_local infrastructure failed to
assign the proper pre/post map/unmap flush operations for sparc.
Sparc requires cache flush before map/unmap and tlb flush afterwards.
Fixes: 3293efa97807 ("sparc/mm/highmem: Switch to generic kmap atomic")
Reported-by: Andreas Larsson
Signed-off-by: Thomas Gleixner
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
---
arch/sparc/include/asm/highmem.h |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/sparc/include/asm/highmem.h
+++ b/arch/sparc/include/asm/highmem.h
@@ -50,10 +50,11 @@ extern pte_t *pkmap_page_table;
#define flush_cache_kmaps() flush_cache_all()
-/* FIXME: Use __flush_tlb_one(vaddr) instead of flush_cache_all() -- Anton */
-#define arch_kmap_local_post_map(vaddr, pteval)flush_cache_all()
-#define arch_kmap_local_post_unmap(vaddr) flush_cache_all()
-
+/* FIXME: Use __flush_*_one(vaddr) instead of flush_*_all() -- Anton */
+#define arch_kmap_local_pre_map(vaddr, pteval) flush_cache_all()
+#define arch_kmap_local_pre_unmap(vaddr) flush_cache_all()
+#define arch_kmap_local_post_map(vaddr, pteval)flush_tlb_all()
+#define arch_kmap_local_post_unmap(vaddr) flush_tlb_all()
#endif /* __KERNEL__ */
Yes! I found, just an hour before your patched was posted, that an
equivalent fix helped back where the switch-to-generic patch first
occurred. This patch was successfully tested on master.
Tested-by: Andreas Larsson
--
Andreas Larsson
Cobham Gaisler
Re: [PATCH 3/6] KVM: selftests: Convert iterations to int in dirty_log_perf_test
On 12/01/2021 22.42, Ben Gardon wrote: In order to add an iteration -1 to indicate that the memory population phase has not yet completed, convert the interations counters to ints. No functional change intended. Reviewed-by: Jacob Xu Signed-off-by: Ben Gardon --- .../selftests/kvm/dirty_log_perf_test.c | 26 +-- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/tools/testing/selftests/kvm/dirty_log_perf_test.c b/tools/testing/selftests/kvm/dirty_log_perf_test.c index 15a9c45bdb5f..3875f22d7283 100644 --- a/tools/testing/selftests/kvm/dirty_log_perf_test.c +++ b/tools/testing/selftests/kvm/dirty_log_perf_test.c @@ -28,8 +28,8 @@ static uint64_t guest_percpu_mem_size = DEFAULT_PER_VCPU_MEM_SIZE; /* Host variables */ static u64 dirty_log_manual_caps; static bool host_quit; -static uint64_t iteration; -static uint64_t vcpu_last_completed_iteration[KVM_MAX_VCPUS]; +static int iteration; +static int vcpu_last_completed_iteration[KVM_MAX_VCPUS]; Wouldn't it be better to use signed 64-bit variables instead? I.e. "int64_t" ? Thomas
Re: [PATCH v3] mhi: use irq_flags if controller driver configures it
Manivannan Sadhasivam writes: > On Mon, Jan 04, 2021 at 06:11:28PM +0800, Carl Huang wrote: >> If controller driver has specified the irq_flags, mhi uses this specified >> irq_flags. Otherwise, mhi uses default irq_flags. >> >> The purpose of this change is to support one MSI vector for QCA6390. >> MHI will use one same MSI vector too in this scenario. >> >> In case of one MSI vector, IRQ_NO_BALANCING is needed when irq handler >> is requested. The reason is if irq migration happens, the msi_data may >> change too. However, the msi_data is already programmed to QCA6390 >> hardware during initialization phase. This msi_data inconsistence will >> result in crash in kernel. >> >> Another issue is in case of one MSI vector, IRQF_NO_SUSPEND will trigger >> WARNINGS because QCA6390 wants to disable the IRQ during the suspend. >> >> To avoid above two issues, QCA6390 driver specifies the irq_flags in case >> of one MSI vector when mhi_register_controller is called. >> >> Signed-off-by: Carl Huang >> Reviewed-by: Manivannan Sadhasivam > > Applied to mhi-next! Would it be possible again to have an immutable branch for this commit? We need it for implementing one MHI support to ath11k[1] required by Dell XPS 13 9310 laptops, which a lot of people are waiting. Otherwise I can only apply the feature for v5.13, which will be released on July. [1] https://patchwork.kernel.org/project/linux-wireless/list/?series=405591=* -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/6] KVM: selftests: Avoid flooding debug log while populating memory
On 12/01/2021 22.42, Ben Gardon wrote:
Peter Xu pointed out that a log message printed while waiting for the
memory population phase of the dirty_log_perf_test will flood the debug
logs as there is no delay after printing the message. Since the message
does not provide much value anyway, remove it.
Reviewed-by: Jacob Xu
Signed-off-by: Ben Gardon
---
tools/testing/selftests/kvm/dirty_log_perf_test.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/kvm/dirty_log_perf_test.c
b/tools/testing/selftests/kvm/dirty_log_perf_test.c
index 16efe6589b43..15a9c45bdb5f 100644
--- a/tools/testing/selftests/kvm/dirty_log_perf_test.c
+++ b/tools/testing/selftests/kvm/dirty_log_perf_test.c
@@ -146,8 +146,7 @@ static void run_test(enum vm_guest_mode mode, void *arg)
/* Allow the vCPU to populate memory */
pr_debug("Starting iteration %lu - Populating\n", iteration);
while (READ_ONCE(vcpu_last_completed_iteration[vcpu_id]) != iteration)
- pr_debug("Waiting for vcpu_last_completed_iteration == %lu\n",
- iteration);
+ ;
ts_diff = timespec_elapsed(start);
pr_info("Populate memory time: %ld.%.9lds\n",
@@ -171,9 +170,9 @@ static void run_test(enum vm_guest_mode mode, void *arg)
pr_debug("Starting iteration %lu\n", iteration);
for (vcpu_id = 0; vcpu_id < nr_vcpus; vcpu_id++) {
- while
(READ_ONCE(vcpu_last_completed_iteration[vcpu_id]) != iteration)
- pr_debug("Waiting for vCPU %d
vcpu_last_completed_iteration == %lu\n",
-vcpu_id, iteration);
+ while (READ_ONCE(vcpu_last_completed_iteration[vcpu_id])
+ != iteration)
+ ;
}
ts_diff = timespec_elapsed(start);
Reviewed-by: Thomas Huth
Re: [PATCH v2 4/5] clk: qcom: Add A7 PLL support
Quoting Manivannan Sadhasivam (2021-01-08 03:32:32) > Add support for PLL found in Qualcomm SDX55 platforms which is used to > provide clock to the Cortex A7 CPU via a mux. This PLL can provide high > frequency clock to the CPU above 1GHz as compared to the other sources > like GPLL0. > > In this driver, the power domain is attached to the cpudev. This is > required for CPUFreq functionality and there seems to be no better place > to do other than this driver (no dedicated CPUFreq driver). > > Signed-off-by: Manivannan Sadhasivam > --- Looks good to me.
Re: [PATCH 2/2] dmaengine: ti: k3-udma: Add support for burst_size configuration for mem2mem
Hi Vinod,
On 1/12/21 12:16 PM, Vinod Koul wrote:
> On 14-12-20, 10:13, Peter Ujfalusi wrote:
>> The UDMA and BCDMA can provide higher throughput if the burst_size of the
>> channel is changed from it's default (which is 64 bytes) for Ultra-high
>> and high capacity channels.
>>
>> This performance benefit is even more visible when the buffers are aligned
>> with the burst_size configuration.
>>
>> The am654 does not have a way to change the burst size, but it is using
>> 64 bytes burst, so increasing the copy_align from 8 bytes to 64 (and
>> clients taking that into account) can increase the throughput as well.
>>
>> Numbers gathered on j721e:
>> echo 800 > /sys/module/dmatest/parameters/test_buf_size
>> echo 2000 > /sys/module/dmatest/parameters/timeout
>> echo 50 > /sys/module/dmatest/parameters/iterations
>> echo 1 > /sys/module/dmatest/parameters/max_channels
>>
>> Prior this patch: ~1.3 GB/s
>> After this patch: ~1.8 GB/s
>> with 1 byte alignment: ~1.7 GB/s
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> drivers/dma/ti/k3-udma.c | 115 +--
>> 1 file changed, 110 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
>> index 87157cbae1b8..54e4ccb1b37e 100644
>> --- a/drivers/dma/ti/k3-udma.c
>> +++ b/drivers/dma/ti/k3-udma.c
>> @@ -121,6 +121,11 @@ struct udma_oes_offsets {
>> #define UDMA_FLAG_PDMA_ACC32BIT(0)
>> #define UDMA_FLAG_PDMA_BURSTBIT(1)
>> #define UDMA_FLAG_TDTYPEBIT(2)
>> +#define UDMA_FLAG_BURST_SIZEBIT(3)
>> +#define UDMA_FLAGS_J7_CLASS (UDMA_FLAG_PDMA_ACC32 | \
>> + UDMA_FLAG_PDMA_BURST | \
>> + UDMA_FLAG_TDTYPE | \
>> + UDMA_FLAG_BURST_SIZE)
>>
>> struct udma_match_data {
>> enum k3_dma_type type;
>> @@ -128,6 +133,7 @@ struct udma_match_data {
>> bool enable_memcpy_support;
>> u32 flags;
>> u32 statictr_z_mask;
>> +u8 burst_size[3];
>> };
>>
>> struct udma_soc_data {
>> @@ -436,6 +442,18 @@ static void k3_configure_chan_coherency(struct dma_chan
>> *chan, u32 asel)
>> }
>> }
>>
>> +static u8 udma_get_chan_tpl_index(struct udma_tpl *tpl_map, int chan_id)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < tpl_map->levels; i++) {
>> +if (chan_id >= tpl_map->start_idx[i])
>> +return i;
>> +}
>
> Braces seem not required
True, they are not strictly needed but I prefer to have them when I have
any condition in the loop.
>> +
>> +return 0;
>> +}
>> +
>> static void udma_reset_uchan(struct udma_chan *uc)
>> {
>> memset(>config, 0, sizeof(uc->config));
>> @@ -1811,6 +1829,7 @@ static int udma_tisci_m2m_channel_config(struct
>> udma_chan *uc)
>> const struct ti_sci_rm_udmap_ops *tisci_ops = tisci_rm->tisci_udmap_ops;
>> struct udma_tchan *tchan = uc->tchan;
>> struct udma_rchan *rchan = uc->rchan;
>> +u8 burst_size = 0;
>> int ret = 0;
>>
>> /* Non synchronized - mem to mem type of transfer */
>> @@ -1818,6 +1837,12 @@ static int udma_tisci_m2m_channel_config(struct
>> udma_chan *uc)
>> struct ti_sci_msg_rm_udmap_tx_ch_cfg req_tx = { 0 };
>> struct ti_sci_msg_rm_udmap_rx_ch_cfg req_rx = { 0 };
>>
>> +if (ud->match_data->flags & UDMA_FLAG_BURST_SIZE) {
>> +u8 tpl = udma_get_chan_tpl_index(>tchan_tpl, tchan->id);
>
> Can we define variable at function start please
The 'tpl' is only used within this if branch, it looks a bit cleaner
imho, but if you insist, I can move the definition.
...
>> +static enum dmaengine_alignment udma_get_copy_align(struct udma_dev *ud)
>> +{
>> +const struct udma_match_data *match_data = ud->match_data;
>> +u8 tpl;
>> +
>> +if (!match_data->enable_memcpy_support)
>> +return DMAENGINE_ALIGN_8_BYTES;
>> +
>> +/* Get the highest TPL level the device supports for memcpy */
>> +if (ud->bchan_cnt) {
>> +tpl = udma_get_chan_tpl_index(>bchan_tpl, 0);
>> +} else if (ud->tchan_cnt) {
>> +tpl = udma_get_chan_tpl_index(>tchan_tpl, 0);
>> +} else {
>> +return DMAENGINE_ALIGN_8_BYTES;
>> +}
>
> Braces seem not required
Very true.
>
>> +
>> +switch (match_data->burst_size[tpl]) {
>> +case TI_SCI_RM_UDMAP_CHAN_BURST_SIZE_256_BYTES:
>> +return DMAENGINE_ALIGN_256_BYTES;
>> +case TI_SCI_RM_UDMAP_CHAN_BURST_SIZE_128_BYTES:
>> +return DMAENGINE_ALIGN_128_BYTES;
>> +case TI_SCI_RM_UDMAP_CHAN_BURST_SIZE_64_BYTES:
>> +fallthrough;
>> +default:
>> +return DMAENGINE_ALIGN_64_BYTES;
>
> ah, we are supposed to have case at same indent as switch, pls run
> checkpatch to have these flagged off
Yes, they should be.
The other me did a sloppy job for sure, this should
Re: [PATCH v2 5/5] clk: qcom: Add SDX55 APCS clock controller support
Quoting Manivannan Sadhasivam (2021-01-08 03:32:33)
> Add a driver for the SDX55 APCS clock controller. It is part of the APCS
> hardware block, which among other things implements also a combined mux
> and half integer divider functionality. The APCS clock controller has 3
> parent clocks:
>
> 1. Board XO
> 2. Fixed rate GPLL0
> 3. A7 PLL
>
> The source and the divider can be set both at the same time.
I don't understand what that means. Presumably it's a mux/divider
combined?
>
> This is required for enabling CPU frequency scaling on SDX55-based
> platforms.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/clk/qcom/Kconfig | 9 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/apcs-sdx55.c | 149 ++
> 3 files changed, 159 insertions(+)
> create mode 100644 drivers/clk/qcom/apcs-sdx55.c
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index d6f4aee4427a..2c67fdfae913 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -45,6 +45,15 @@ config QCOM_CLK_APCS_MSM8916
> Say Y if you want to support CPU frequency scaling on devices
> such as msm8916.
>
> +config QCOM_CLK_APCS_SDX55
APCC comes before APCS
> + tristate "SDX55 APCS Clock Controller"
> + depends on QCOM_APCS_IPC || COMPILE_TEST
> + help
> + Support for the APCS Clock Controller on SDX55 platform. The
> + APCS is managing the mux and divider which feeds the CPUs.
> + Say Y if you want to support CPU frequency scaling on devices
> + such as SDX55.
> +
> config QCOM_CLK_APCC_MSM8996
> tristate "MSM8996 CPU Clock Controller"
> select QCOM_KRYO_L2_ACCESSORS
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index e7e0ac382176..a9271f40916c 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_MSM_MMCC_8998) += mmcc-msm8998.o
> obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
> obj-$(CONFIG_QCOM_A7PLL) += a7-pll.o
> obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
> +obj-$(CONFIG_QCOM_CLK_APCS_SDX55) += apcs-sdx55.o
> obj-$(CONFIG_QCOM_CLK_APCC_MSM8996) += clk-cpu-8996.o
> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
> obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o
> diff --git a/drivers/clk/qcom/apcs-sdx55.c b/drivers/clk/qcom/apcs-sdx55.c
> new file mode 100644
> index ..14413c957d83
> --- /dev/null
> +++ b/drivers/clk/qcom/apcs-sdx55.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Qualcomm SDX55 APCS clock controller driver
> + *
> + * Copyright (c) 2020, Linaro Limited
> + * Author: Manivannan Sadhasivam
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-regmap.h"
> +#include "clk-regmap-mux-div.h"
> +#include "common.h"
Curious what common is needed for?
> +
> +static const u32 apcs_mux_clk_parent_map[] = { 0, 1, 5 };
> +
> +static const struct clk_parent_data pdata[] = {
> + { .fw_name = "ref", .name = "bi_tcxo", },
> + { .fw_name = "aux", .name = "gpll0", },
> + { .fw_name = "pll", .name = "a7pll", },
Please remove name from here. It shouldn't be necessary if the DT
describes things properly. Or there isn't DT for this device?
> +};
> +
> +/*
> + * We use the notifier function for switching to a temporary safe
> configuration
> + * (mux and divider), while the A7 PLL is reconfigured.
> + */
> +static int a7cc_notifier_cb(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> + int ret = 0;
> + struct clk_regmap_mux_div *md = container_of(nb,
> +struct
> clk_regmap_mux_div,
> +clk_nb);
> + if (event == PRE_RATE_CHANGE)
> + /* set the mux and divider to safe frequency (400mhz) */
> + ret = mux_div_set_src_div(md, 1, 2);
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static int qcom_apcs_sdx55_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct device *parent = dev->parent;
> + struct device *cpu_dev;
> + struct clk_regmap_mux_div *a7cc;
> + struct regmap *regmap;
> + struct clk_init_data init = { };
> + int ret = -ENODEV;
Drop assignement..
> +
> + regmap = dev_get_regmap(parent, NULL);
> + if (!regmap) {
> + dev_err(dev, "Failed to get parent regmap: %d\n", ret);
> + return ret;
.. and Just return -ENODEV?
> + }
> +
> + a7cc = devm_kzalloc(dev, sizeof(*a7cc), GFP_KERNEL);
> + if (!a7cc)
> + return -ENOMEM;
> +
> + init.name = "a7mux";
> + init.parent_data = pdata;
> + init.num_parents = ARRAY_SIZE(pdata);
> + init.ops = _regmap_mux_div_ops;
> +
> +
[PATCH v3 1/6] mm: Move pfn_to_online_page() out of line
pfn_to_online_page() is already too large to be a macro or an inline
function. In anticipation of further logic changes / growth, move it out
of line.
No functional change, just code movement.
Reported-by: Michal Hocko
Reviewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Dan Williams
---
include/linux/memory_hotplug.h | 17 +
mm/memory_hotplug.c| 16
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 15acce5ab106..3d99de0db2dd 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -16,22 +16,7 @@ struct resource;
struct vmem_altmap;
#ifdef CONFIG_MEMORY_HOTPLUG
-/*
- * Return page for the valid pfn only if the page is online. All pfn
- * walkers which rely on the fully initialized page->flags and others
- * should use this rather than pfn_valid && pfn_to_page
- */
-#define pfn_to_online_page(pfn) \
-({\
- struct page *___page = NULL; \
- unsigned long ___pfn = pfn;\
- unsigned long ___nr = pfn_to_section_nr(___pfn); \
- \
- if (___nr < NR_MEM_SECTIONS && online_section_nr(___nr) && \
- pfn_valid_within(___pfn)) \
- ___page = pfn_to_page(___pfn); \
- ___page; \
-})
+struct page *pfn_to_online_page(unsigned long pfn);
/*
* Types for free bootmem stored in page->lru.next. These have to be in
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f9d57b9be8c7..55a69d4396e7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -300,6 +300,22 @@ static int check_hotplug_memory_addressable(unsigned long
pfn,
return 0;
}
+/*
+ * Return page for the valid pfn only if the page is online. All pfn
+ * walkers which rely on the fully initialized page->flags and others
+ * should use this rather than pfn_valid && pfn_to_page
+ */
+struct page *pfn_to_online_page(unsigned long pfn)
+{
+ unsigned long nr = pfn_to_section_nr(pfn);
+
+ if (nr < NR_MEM_SECTIONS && online_section_nr(nr) &&
+ pfn_valid_within(pfn))
+ return pfn_to_page(pfn);
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(pfn_to_online_page);
+
/*
* Reasonably generic function for adding memory. It is
* expected that archs that support memory hotplug will
[PATCH v3 5/6] mm: Fix memory_failure() handling of dax-namespace metadata
Given 'struct dev_pagemap' spans both data pages and metadata pages be
careful to consult the altmap if present to delineate metadata. In fact
the pfn_first() helper already identifies the first valid data pfn, so
export that helper for other code paths via pgmap_pfn_valid().
Other usage of get_dev_pagemap() are not a concern because those are
operating on known data pfns having been looking up by get_user_pages().
I.e. metadata pfns are never user mapped.
Cc: Naoya Horiguchi
Cc: Andrew Morton
Reported-by: David Hildenbrand
Signed-off-by: Dan Williams
---
include/linux/memremap.h |6 ++
mm/memory-failure.c |6 ++
mm/memremap.c| 15 +++
3 files changed, 27 insertions(+)
diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 79c49e7f5c30..f5b464daeeca 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -137,6 +137,7 @@ void *devm_memremap_pages(struct device *dev, struct
dev_pagemap *pgmap);
void devm_memunmap_pages(struct device *dev, struct dev_pagemap *pgmap);
struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
struct dev_pagemap *pgmap);
+bool pgmap_pfn_valid(struct dev_pagemap *pgmap, unsigned long pfn);
unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
void vmem_altmap_free(struct vmem_altmap *altmap, unsigned long nr_pfns);
@@ -165,6 +166,11 @@ static inline struct dev_pagemap *get_dev_pagemap(unsigned
long pfn,
return NULL;
}
+static inline bool pgmap_pfn_valid(struct dev_pagemap *pgmap, unsigned long
pfn)
+{
+ return false;
+}
+
static inline unsigned long vmem_altmap_offset(struct vmem_altmap *altmap)
{
return 0;
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 78b173c7190c..541569cb4a99 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1308,6 +1308,12 @@ static int memory_failure_dev_pagemap(unsigned long pfn,
int flags,
*/
put_page(page);
+ /* device metadata space is not recoverable */
+ if (!pgmap_pfn_valid(pgmap, pfn)) {
+ rc = -ENXIO;
+ goto out;
+ }
+
/*
* Prevent the inode from being freed while we are interrogating
* the address_space, typically this would be handled by
diff --git a/mm/memremap.c b/mm/memremap.c
index 16b2fb482da1..2455bac89506 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -80,6 +80,21 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap,
int range_id)
return pfn + vmem_altmap_offset(pgmap_altmap(pgmap));
}
+bool pgmap_pfn_valid(struct dev_pagemap *pgmap, unsigned long pfn)
+{
+ int i;
+
+ for (i = 0; i < pgmap->nr_range; i++) {
+ struct range *range = >ranges[i];
+
+ if (pfn >= PHYS_PFN(range->start) &&
+ pfn <= PHYS_PFN(range->end))
+ return pfn >= pfn_first(pgmap, i);
+ }
+
+ return false;
+}
+
static unsigned long pfn_end(struct dev_pagemap *pgmap, int range_id)
{
const struct range *range = >ranges[range_id];
[PATCH v3 6/6] libnvdimm/namespace: Fix visibility of namespace resource attribute
Legacy pmem namespaces lost support for the "resource" attribute when
the code was cleaned up to put the permission visibility in the
declaration. Restore this by listing 'resource' in the default
attributes.
A new ndctl regression test for pfn_to_online_page() corner cases builds
on this fix.
Fixes: bfd2e9140656 ("libnvdimm: Simplify root read-only definition for the
'resource' attribute")
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc:
Signed-off-by: Dan Williams
---
drivers/nvdimm/namespace_devs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 6da67f4d641a..2403b71b601e 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1635,11 +1635,11 @@ static umode_t namespace_visible(struct kobject *kobj,
return a->mode;
}
- if (a == _attr_nstype.attr || a == _attr_size.attr
- || a == _attr_holder.attr
- || a == _attr_holder_class.attr
- || a == _attr_force_raw.attr
- || a == _attr_mode.attr)
+ /* base is_namespace_io() attributes */
+ if (a == _attr_nstype.attr || a == _attr_size.attr ||
+ a == _attr_holder.attr || a == _attr_holder_class.attr ||
+ a == _attr_force_raw.attr || a == _attr_mode.attr ||
+ a == _attr_resource.attr)
return a->mode;
return 0;
[PATCH v3 3/6] mm: Teach pfn_to_online_page() about ZONE_DEVICE section collisions
While pfn_to_online_page() is able to determine pfn_valid() at
subsection granularity it is not able to reliably determine if a given
pfn is also online if the section is mixes ZONE_{NORMAL,MOVABLE} with
ZONE_DEVICE. This means that pfn_to_online_page() may return invalid
@page objects. For example with a memory map like:
1-1fbff : System RAM
14200-143002e16 : Kernel code
14320-143713fff : Kernel rodata
14380-143b15b7f : Kernel data
144227000-144ff : Kernel bss
1fc00-2fbff : Persistent Memory (legacy)
1fc00-2fbff : namespace0.0
This command:
echo 0x1fc00 > /sys/devices/system/memory/soft_offline_page
...succeeds when it should fail. When it succeeds it touches
an uninitialized page and may crash or cause other damage (see
dissolve_free_huge_page()).
While the memory map above is contrived via the memmap=ss!nn kernel
command line option, the collision happens in practice on shipping
platforms. The memory controller resources that decode spans of
physical address space are a limited resource. One technique
platform-firmware uses to conserve those resources is to share a decoder
across 2 devices to keep the address range contiguous. Unfortunately the
unit of operation of a decoder is 64MiB while the Linux section size is
128MiB. This results in situations where, without subsection hotplug
memory mappings with different lifetimes collide into one object that
can only express one lifetime.
Update move_pfn_range_to_zone() to flag (SECTION_TAINT_ZONE_DEVICE) a
section that mixes ZONE_DEVICE pfns with other online pfns. With
SECTION_TAINT_ZONE_DEVICE to delineate, pfn_to_online_page() can fall
back to a slow-path check for ZONE_DEVICE pfns in an online section. In
the fast path online_section() for a full ZONE_DEVICE section returns
false.
Because the collision case is rare, and for simplicity, the
SECTION_TAINT_ZONE_DEVICE flag is never cleared once set.
Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug")
Cc: Andrew Morton
Reported-by: Michal Hocko
Reported-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Dan Williams
---
include/linux/mmzone.h | 22 +++---
mm/memory_hotplug.c| 38 ++
2 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index b593316bff3d..0b5c44f730b4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1273,13 +1273,14 @@ extern size_t mem_section_usage_size(void);
* which results in PFN_SECTION_SHIFT equal 6.
* To sum it up, at least 6 bits are available.
*/
-#defineSECTION_MARKED_PRESENT (1UL<<0)
-#define SECTION_HAS_MEM_MAP(1UL<<1)
-#define SECTION_IS_ONLINE (1UL<<2)
-#define SECTION_IS_EARLY (1UL<<3)
-#define SECTION_MAP_LAST_BIT (1UL<<4)
-#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
-#define SECTION_NID_SHIFT 3
+#define SECTION_MARKED_PRESENT (1UL<<0)
+#define SECTION_HAS_MEM_MAP(1UL<<1)
+#define SECTION_IS_ONLINE (1UL<<2)
+#define SECTION_IS_EARLY (1UL<<3)
+#define SECTION_TAINT_ZONE_DEVICE (1UL<<4)
+#define SECTION_MAP_LAST_BIT (1UL<<5)
+#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
+#define SECTION_NID_SHIFT 3
static inline struct page *__section_mem_map_addr(struct mem_section *section)
{
@@ -1318,6 +1319,13 @@ static inline int online_section(struct mem_section
*section)
return (section && (section->section_mem_map & SECTION_IS_ONLINE));
}
+static inline int online_device_section(struct mem_section *section)
+{
+ unsigned long flags = SECTION_IS_ONLINE | SECTION_TAINT_ZONE_DEVICE;
+
+ return section && ((section->section_mem_map & flags) == flags);
+}
+
static inline int online_section_nr(unsigned long nr)
{
return online_section(__nr_to_section(nr));
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 9f37f8a68da4..889d58523fa1 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -308,6 +308,7 @@ static int check_hotplug_memory_addressable(unsigned long
pfn,
struct page *pfn_to_online_page(unsigned long pfn)
{
unsigned long nr = pfn_to_section_nr(pfn);
+ struct dev_pagemap *pgmap;
struct mem_section *ms;
if (nr >= NR_MEM_SECTIONS)
@@ -328,6 +329,22 @@ struct page *pfn_to_online_page(unsigned long pfn)
if (!pfn_section_valid(ms, pfn))
return NULL;
+ if (!online_device_section(ms))
+ return pfn_to_page(pfn);
+
+ /*
+* Slowpath: when ZONE_DEVICE collides with
+* ZONE_{NORMAL,MOVABLE} within the same section some pfns in
+* the section may be 'offline' but 'valid'. Only
+* get_dev_pagemap() can determine sub-section online status.
+*/
+ pgmap = get_dev_pagemap(pfn, NULL);
+
[PATCH v3 4/6] mm: Fix page reference leak in soft_offline_page()
The conversion to move pfn_to_online_page() internal to
soft_offline_page() missed that the get_user_pages() reference taken by
the madvise() path needs to be dropped when pfn_to_online_page() fails.
Note the direct sysfs-path to soft_offline_page() does not perform a
get_user_pages() lookup.
When soft_offline_page() is handed a pfn_valid() &&
!pfn_to_online_page() pfn the kernel hangs at dax-device shutdown due to
a leaked reference.
Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn")
Cc: Andrew Morton
Cc: Naoya Horiguchi
Cc: Michal Hocko
Reviewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Cc:
Signed-off-by: Dan Williams
---
mm/memory-failure.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 5a38e9eade94..78b173c7190c 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1885,6 +1885,12 @@ static int soft_offline_free_page(struct page *page)
return rc;
}
+static void put_ref_page(struct page *page)
+{
+ if (page)
+ put_page(page);
+}
+
/**
* soft_offline_page - Soft offline a page.
* @pfn: pfn to soft-offline
@@ -1910,20 +1916,26 @@ static int soft_offline_free_page(struct page *page)
int soft_offline_page(unsigned long pfn, int flags)
{
int ret;
- struct page *page;
bool try_again = true;
+ struct page *page, *ref_page = NULL;
+
+ WARN_ON_ONCE(!pfn_valid(pfn) && (flags & MF_COUNT_INCREASED));
if (!pfn_valid(pfn))
return -ENXIO;
+ if (flags & MF_COUNT_INCREASED)
+ ref_page = pfn_to_page(pfn);
+
/* Only online pages can be soft-offlined (esp., not ZONE_DEVICE). */
page = pfn_to_online_page(pfn);
- if (!page)
+ if (!page) {
+ put_ref_page(ref_page);
return -EIO;
+ }
if (PageHWPoison(page)) {
pr_info("%s: %#lx page already poisoned\n", __func__, pfn);
- if (flags & MF_COUNT_INCREASED)
- put_page(page);
+ put_ref_page(ref_page);
return 0;
}
[PATCH v3 2/6] mm: Teach pfn_to_online_page() to consider subsection validity
pfn_section_valid() determines pfn validity on subsection granularity
where pfn_valid() may be limited to coarse section granularity.
Explicitly validate subsections after pfn_valid() succeeds.
Fixes: b13bc35193d9 ("mm/hotplug: invalid PFNs from pfn_to_online_page()")
Cc: Qian Cai
Cc: Michal Hocko
Cc: Oscar Salvador
Reported-by: David Hildenbrand
Signed-off-by: Dan Williams
---
mm/memory_hotplug.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 55a69d4396e7..9f37f8a68da4 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -308,11 +308,27 @@ static int check_hotplug_memory_addressable(unsigned long
pfn,
struct page *pfn_to_online_page(unsigned long pfn)
{
unsigned long nr = pfn_to_section_nr(pfn);
+ struct mem_section *ms;
+
+ if (nr >= NR_MEM_SECTIONS)
+ return NULL;
+
+ ms = __nr_to_section(nr);
+ if (!online_section(ms))
+ return NULL;
+
+ /*
+* Save some code text when online_section() +
+* pfn_section_valid() are sufficient.
+*/
+ if (IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
+ if (!pfn_valid(pfn))
+ return NULL;
+
+ if (!pfn_section_valid(ms, pfn))
+ return NULL;
- if (nr < NR_MEM_SECTIONS && online_section_nr(nr) &&
- pfn_valid_within(pfn))
- return pfn_to_page(pfn);
- return NULL;
+ return pfn_to_page(pfn);
}
EXPORT_SYMBOL_GPL(pfn_to_online_page);
[PATCH v3 0/6] mm: Fix pfn_to_online_page() with respect to ZONE_DEVICE
Changes since v2 [1]:
- Collect some reviewed-by's from David and Oscar
- Rework subsection validity to include pfn_valid() gated by
CONFIG_HAVE_ARCH_PFN_VALID (David, Oscar)
- Introduce pgmap_pfn_valid() to validate metadata vs data in a pgmap (David)
! Kill put_ref_page(): the extra "if (ref_page) put_page(ref_page)" still
feels more cluttered than adding a tiny helper. (Oscar)
[1]:
http://lore.kernel.org/r/161044407603.1482714.16630477578392768273.st...@dwillia2-desk3.amr.corp.intel.com
---
Michal reminds that the discussion about how to ensure pfn-walkers do
not get confused by ZONE_DEVICE pages never resolved. A pfn-walker that
uses pfn_to_online_page() may inadvertently translate a pfn as online
and in the page allocator, when it is offline managed by a ZONE_DEVICE
mapping (details in Patch 3: ("mm: Teach pfn_to_online_page() about
ZONE_DEVICE section collisions")).
The 2 proposals under consideration are teach pfn_to_online_page() to be
precise in the presence of mixed-zone sections, or teach the memory-add
code to drop the System RAM associated with ZONE_DEVICE collisions. In
order to not regress memory capacity by a few 10s to 100s of MiB the
approach taken in this set is to add precision to pfn_to_online_page().
In the course of validating pfn_to_online_page() a couple other fixes
fell out:
1/ soft_offline_page() fails to drop the reference taken in the
madvise(..., MADV_SOFT_OFFLINE) case.
2/ The libnvdimm sysfs attribute visibility code was failing to publish
the resource base for memmap=ss!nn defined namespaces. This is needed
for the regression test for soft_offline_page().
3/ memory_failure() uses get_dev_pagemap() to lookup ZONE_DEVICE pages,
however that mapping may contain data pages and metadata raw pfns.
Introduce pgmap_pfn_valid() to delineate the 2 types and fail the
handling of raw metadata pfns.
---
Dan Williams (6):
mm: Move pfn_to_online_page() out of line
mm: Teach pfn_to_online_page() to consider subsection validity
mm: Teach pfn_to_online_page() about ZONE_DEVICE section collisions
mm: Fix page reference leak in soft_offline_page()
mm: Fix memory_failure() handling of dax-namespace metadata
libnvdimm/namespace: Fix visibility of namespace resource attribute
drivers/nvdimm/namespace_devs.c | 10 +++---
include/linux/memory_hotplug.h | 17 +
include/linux/memremap.h|6 +++
include/linux/mmzone.h | 22
mm/memory-failure.c | 26 --
mm/memory_hotplug.c | 70 +++
mm/memremap.c | 15
7 files changed, 134 insertions(+), 32 deletions(-)
Re: [PATCH for doc-next] doc/zh_CN: adjust table markup in mips/ingenic-tcu.rst
Reviewed-by: Alex Shi
在 2021/1/13 下午3:00, Lukas Bulwahn 写道:
> Commit 419b1d4ed1cb ("doc/zh_CN: add mips ingenic-tcu.rst translation")
> introduces a warning with make htmldocs:
>
> ./Documentation/translations/zh_CN/mips/ingenic-tcu.rst:
> 61: WARNING: Malformed table. Text in column margin in table line 6.
>
> Adjust the table markup to address this warning.
>
> Signed-off-by: Lukas Bulwahn
> ---
> applies cleanly on next-20210113
>
> Yanteng, please ack.
>
> Jonathan, please pick this doc warning fixup on your -next tree.
>
> Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
> b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
> index 72b5d409ed89..9324a0a26430 100644
> --- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
> +++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
> @@ -53,14 +53,14 @@
>
> TCU硬件的功能分布在多个驱动程序：
>
> -=== =
> +== ===
> 时钟drivers/clk/ingenic/tcu.c
> 中断drivers/irqchip/irq-ingenic-tcu.c
> 定时器 drivers/clocksource/ingenic-timer.c
> OST drivers/clocksource/ingenic-ost.c
> 脉冲宽度调制器 drivers/pwm/pwm-jz4740.c
> 看门狗 drivers/watchdog/jz4740_wdt.c
> -=== =
> +== ===
>
> 因为可以从相同的寄存器控制属于不同驱动程序和框架的TCU的各种功能，所以
> 所有这些驱动程序都通过相同的控制总线通用接口访问它们的寄存器。
>
drivers/spi/spi-lp8841-rtc.c:63:28: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: e609571b5ffa3528bf85292de1ceaddac342bc1c commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX() iomem argument (as in generic implementation) date: 5 months ago config: alpha-randconfig-s032-20210113 (attached as .config) compiler: alpha-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f28ca6bd8211214faf717677bbffe375c2a6072 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 8f28ca6bd8211214faf717677bbffe375c2a6072 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=alpha If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/spi/spi-lp8841-rtc.c:112:41: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:112:41: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:112:41: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:121:41: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:121:41: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:121:41: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:143:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:143:33: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:143:33: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:147:41: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:147:41: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:147:41: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:209:21: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *iomem @@ got void [noderef] __iomem * @@ drivers/spi/spi-lp8841-rtc.c:209:21: sparse: expected void *iomem drivers/spi/spi-lp8841-rtc.c:209:21: sparse: got void [noderef] __iomem * drivers/spi/spi-lp8841-rtc.c:57:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:57:33: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:57:33: sparse: got void *iomem >> drivers/spi/spi-lp8841-rtc.c:63:28: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void const [noderef] >> __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:63:28: sparse: expected void const [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:63:28: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:47:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:47:33: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:47:33: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:47:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:47:33: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:47:33: sparse: got void *iomem drivers/spi/spi-lp8841-rtc.c:57:33: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *iomem @@ drivers/spi/spi-lp8841-rtc.c:57:33: sparse: expected void volatile [noderef] __iomem *addr drivers/spi/spi-lp8841-rtc.c:57:33: sparse: got void *iomem >> drivers/spi/spi-lp8841-rtc.c:63:28: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void const
[PATCH] can: mcp251xfd: fix wrong check in mcp251xfd_handle_rxif_one
If alloc_canfd_skb returns NULL, 'cfg' is an uninitialized
variable, so we should check 'skb' rather than 'cfd' after
calling alloc_canfd_skb(priv->ndev, ).
Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI
CAN")
Signed-off-by: Qinglang Miao
---
drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
index 77129d5f4..792d55ba4 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
@@ -1492,7 +1492,7 @@ mcp251xfd_handle_rxif_one(struct mcp251xfd_priv *priv,
else
skb = alloc_can_skb(priv->ndev, (struct can_frame **));
- if (!cfd) {
+ if (!skb) {
stats->rx_dropped++;
return 0;
}
--
2.23.0
[PATCH] ACPI: configfs: add missing check after configfs_register_default_group
A list_add corruption is reported by Hulk Robot like this:
==
list_add corruption.
Call Trace:
link_obj+0xc0/0x1c0
link_group+0x21/0x140
configfs_register_subsystem+0xdb/0x380
acpi_configfs_init+0x25/0x1000 [acpi_configfs]
do_one_initcall+0x149/0x820
do_init_module+0x1ef/0x720
load_module+0x35c8/0x4380
__do_sys_finit_module+0x10d/0x1a0
do_syscall_64+0x34/0x80
It's because of the missing check after configfs_register_default_group,
where configfs_unregister_subsystem should be called once failure.
Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs")
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
drivers/acpi/acpi_configfs.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index cf91f4910..25512ab0e 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -268,7 +268,12 @@ static int __init acpi_configfs_init(void)
acpi_table_group = configfs_register_default_group(root, "table",
_tables_type);
- return PTR_ERR_OR_ZERO(acpi_table_group);
+ if (IS_ERR(acpi_table_group)) {
+ configfs_register_subsystem(_configfs);
+ return PTR_ERR(acpi_table_group);
+ }
+
+ return 0;
}
module_init(acpi_configfs_init);
--
2.23.0
Re: [RFC 2/2] clk: vc5: Add support for optional load capacitance
Quoting Adam Ford (2021-01-06 09:39:00)
> There are two registers which can set the load capacitance for
> XTAL1 and XTAL2. These are optional registers when using an
> external crystal. Parse the device tree and set the
> corresponding registers accordingly.
>
> Signed-off-by: Adam Ford
> ---
> drivers/clk/clk-versaclock5.c | 64 +++
> 1 file changed, 64 insertions(+)
>
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index 43db67337bc0..445abc3731fb 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -759,6 +759,63 @@ static int vc5_update_power(struct device_node
> *np_output,
> return 0;
> }
>
> +static int vc5_map_cap_value(u32 femtofarads)
> +{
> + int mapped_value;
> +
> + /* The datasheet explicitly states 9000 - 25000 */
> + if ((femtofarads < 9000) || (femtofarads > 25000))
Please remove useless parenthesis.
> + return -EINVAL;
> +
> + /* The lowest target we can hit is 9430, so exit if it's less */
> + if (femtofarads < 9430)
> + return 0;
> +
> + /*
> +* According to VersaClock 6E Programming Guide, there are 6
> +* bits which translate to 64 entries in XTAL registers 12 and
> +* 13. Because bits 0 and 1 increase the capacitance the
> +* same, some of the values can be repeated. Plugging this
> +* into a spreadsheet and generating a trendline, the output
> +* equation becomes x = (y-9098.29) / 216.44, where 'y' is
> +* the desired capacitance in femtofarads, and x is the value
> +* of XTAL[5:0].
> +* To help with rounding, do fixed point math
> +*/
> + femtofarads *= 100;
> + mapped_value = (femtofarads - 909829) / 21644;
> +
> + /*
> +* The datasheet states, the maximum capacitance is 25000,
> +* but the programmer guide shows a max value is 22832,
> +* so values higher values could overflow, so cap it.
> +*/
> + mapped_value = max(mapped_value/100, 0x3f);
> +
> + return mapped_value;
> +}
> +static int vc5_update_cap_load(struct device_node *node, struct
> vc5_driver_data *vc5)
> +{
> + u32 value, mapped_value;
> +
> + if (!of_property_read_u32(node, "idt,xtal1-load-femtofarads",
> )) {
> + mapped_value = vc5_map_cap_value(value);
> + if (mapped_value < 0)
How can it be less than 0? It's unsigned.
> + return mapped_value;
> +
> + regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, (mapped_value
> << 2));
> + }
> +
> + if (!of_property_read_u32(node, "idt,xtal2-load-femtofarads",
> )) {
> + mapped_value = vc5_map_cap_value(value);
> + if (mapped_value < 0)
Same!
> + return mapped_value;
> + regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, (mapped_value
> << 2));
> + }
> +
> + return 0;
> +}
> +
> static int vc5_update_slew(struct device_node *np_output,
>struct vc5_out_data *clk_out)
> {
Re: [PATCH v4] PCI: endpoint: Fix NULL pointer dereference for ->get_features()
On Tue, Jan 12, 2021 at 07:32:25PM +0530, Shradha Todi wrote: > get_features ops of pci_epc_ops may return NULL, causing NULL pointer > dereference in pci_epf_test_bind function. Let us add a check for > pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid > any such NULL pointer dereference and return -ENOTSUPP in case > pci_epc_feature is not found. > > When the patch is not applied and EPC features is not implemented in the > platform driver, we see the following dump due to kernel NULL pointer > dereference. > > [ 105.135936] Call trace: > [ 105.138363] pci_epf_test_bind+0xf4/0x388 > [ 105.142354] pci_epf_bind+0x3c/0x80 > [ 105.145817] pci_epc_epf_link+0xa8/0xcc > [ 105.149632] configfs_symlink+0x1a4/0x48c > [ 105.153616] vfs_symlink+0x104/0x184 > [ 105.157169] do_symlinkat+0x80/0xd4 > [ 105.160636] __arm64_sys_symlinkat+0x1c/0x24 > [ 105.164885] el0_svc_common.constprop.3+0xb8/0x170 > [ 105.169649] el0_svc_handler+0x70/0x88 > [ 105.173377] el0_svc+0x8/0x640 > [ 105.176411] Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) > [ 105.182478] ---[ end trace a438e3c5a24f9df0 ]--- Description and call trace don't correlate with the proposed code change. The code in pci_epf_test_bind() doesn't dereference epc_features, at least in direct manner. Thanks
[PATCH 2/2] CREDITS: update email address and home address
Update my email address to kernel.org account and my home address to my new house. Signed-off-by: Oded Gabbay --- CREDITS | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CREDITS b/CREDITS index 090ed4b004a5..ebd00ca9515b 100644 --- a/CREDITS +++ b/CREDITS @@ -1240,10 +1240,10 @@ S: 80050-430 - Curitiba - Paraná S: Brazil N: Oded Gabbay -E: oded.gab...@gmail.com -D: HabanaLabs and AMD KFD maintainer -S: 12 Shraga Raphaeli -S: Petah-Tikva, 4906418 +E: ogab...@kernel.org +D: HabanaLabs maintainer +S: 29 Duchifat St. +S: Ra'anana 4372029 S: Israel N: Kumar Gala -- 2.25.1
Re: [PATCH v6 00/22] Mediatek MT8192 clock support
On Tue, 2020-12-22 at 21:09 +0800, Weiyi Lu wrote: > This series is based on v5.10-rc1. > > change since v5: > - remove unused clocks by rolling Tinghan's patches[1][2] into series > [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=398781 > [2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=405143 > - remove dts related patches from series > > change since v4: > - merge some subsystem into same driver > - add a generic probe function to reduce duplicated code > > changes since v3: > - add critical clocks > - split large patches into small ones > > changes since v2: > - update and split dt-binding documents by functionalities > - add error checking in probe() function > - fix incorrect clock relation and add critical clocks > - update license identifier and minor fix of coding style > > changes since v1: > - fix asymmetrical control of PLL > - have en_mask used as divider enable mask on all MediaTek SoC > > Weiyi Lu (22): > dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c > wrapper controller > dt-bindings: ARM: Mediatek: Add new document bindings of mdpsys > controller > dt-bindings: ARM: Mediatek: Add new document bindings of msdc > controller > dt-bindings: ARM: Mediatek: Add new document bindings of scp adsp > controller > dt-bindings: ARM: Mediatek: Document bindings of MT8192 clock > controllers > clk: mediatek: Add dt-bindings of MT8192 clocks > clk: mediatek: Fix asymmetrical PLL enable and disable control > clk: mediatek: Add configurable enable control to mtk_pll_data > clk: mediatek: Add mtk_clk_simple_probe() to simplify clock providers > clk: mediatek: Add MT8192 basic clocks support > clk: mediatek: Add MT8192 audio clock support > clk: mediatek: Add MT8192 camsys clock support > clk: mediatek: Add MT8192 imgsys clock support > clk: mediatek: Add MT8192 imp i2c wrapper clock support > clk: mediatek: Add MT8192 ipesys clock support > clk: mediatek: Add MT8192 mdpsys clock support > clk: mediatek: Add MT8192 mfgcfg clock support > clk: mediatek: Add MT8192 mmsys clock support > clk: mediatek: Add MT8192 msdc clock support > clk: mediatek: Add MT8192 scp adsp clock support > clk: mediatek: Add MT8192 vdecsys clock support > clk: mediatek: Add MT8192 vencsys clock support > > .../arm/mediatek/mediatek,apmixedsys.txt |1 + > .../bindings/arm/mediatek/mediatek,audsys.txt |1 + > .../bindings/arm/mediatek/mediatek,camsys.txt | 22 + > .../bindings/arm/mediatek/mediatek,imgsys.txt |2 + > .../arm/mediatek/mediatek,imp_iic_wrap.yaml | 78 + > .../arm/mediatek/mediatek,infracfg.txt|1 + > .../bindings/arm/mediatek/mediatek,ipesys.txt |1 + > .../arm/mediatek/mediatek,mdpsys.yaml | 38 + > .../bindings/arm/mediatek/mediatek,mfgcfg.txt |1 + > .../bindings/arm/mediatek/mediatek,mmsys.txt |1 + > .../bindings/arm/mediatek/mediatek,msdc.yaml | 46 + > .../arm/mediatek/mediatek,pericfg.yaml|1 + > .../arm/mediatek/mediatek,scp-adsp.yaml | 38 + > .../arm/mediatek/mediatek,topckgen.txt|1 + > .../arm/mediatek/mediatek,vdecsys.txt |8 + > .../arm/mediatek/mediatek,vencsys.txt |1 + > drivers/clk/mediatek/Kconfig | 80 + > drivers/clk/mediatek/Makefile | 13 + > drivers/clk/mediatek/clk-mt8192-aud.c | 118 ++ > drivers/clk/mediatek/clk-mt8192-cam.c | 107 ++ > drivers/clk/mediatek/clk-mt8192-img.c | 70 + > .../clk/mediatek/clk-mt8192-imp_iic_wrap.c| 119 ++ > drivers/clk/mediatek/clk-mt8192-ipe.c | 57 + > drivers/clk/mediatek/clk-mt8192-mdp.c | 82 + > drivers/clk/mediatek/clk-mt8192-mfg.c | 50 + > drivers/clk/mediatek/clk-mt8192-mm.c | 108 ++ > drivers/clk/mediatek/clk-mt8192-msdc.c| 85 ++ > drivers/clk/mediatek/clk-mt8192-scp_adsp.c| 50 + > drivers/clk/mediatek/clk-mt8192-vdec.c| 94 ++ > drivers/clk/mediatek/clk-mt8192-venc.c| 53 + > drivers/clk/mediatek/clk-mt8192.c | 1326 + > drivers/clk/mediatek/clk-mtk.c| 23 + > drivers/clk/mediatek/clk-mtk.h| 10 + > drivers/clk/mediatek/clk-mux.h| 15 + > drivers/clk/mediatek/clk-pll.c| 31 +- > include/dt-bindings/clock/mt8192-clk.h| 585 > 36 files changed, 3310 insertions(+), 7 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml > create mode 100644 drivers/clk/mediatek/clk-mt8192-aud.c > create mode 100644
[PATCH 1/2] habanalabs: update email address in sysfs/debugfs docs
Use my kernel.org address for contact point instead of my private email address. Signed-off-by: Oded Gabbay --- .../ABI/testing/debugfs-driver-habanalabs | 44 +++--- .../ABI/testing/sysfs-driver-habanalabs | 58 +-- 2 files changed, 51 insertions(+), 51 deletions(-) diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 3979bfdaa080..d447a611c41b 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -1,7 +1,7 @@ What: /sys/kernel/debug/habanalabs/hl/addr Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Sets the device address to be used for read or write through PCI bar, or the device VA of a host mapped memory to be read or written directly from the host. The latter option is allowed @@ -11,7 +11,7 @@ Description:Sets the device address to be used for read or write through What: /sys/kernel/debug/habanalabs/hl/clk_gate Date: May 2020 KernelVersion: 5.8 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Allow the root user to disable/enable in runtime the clock gating mechanism in Gaudi. Due to how Gaudi is built, the clock gating needs to be disabled in order to access the @@ -34,28 +34,28 @@ Description:Allow the root user to disable/enable in runtime the clock What: /sys/kernel/debug/habanalabs/hl/command_buffers Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Displays a list with information about the currently allocated command buffers What: /sys/kernel/debug/habanalabs/hl/command_submission Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Displays a list with information about the currently active command submissions What: /sys/kernel/debug/habanalabs/hl/command_submission_jobs Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Displays a list with detailed information about each JOB (CB) of each active command submission What: /sys/kernel/debug/habanalabs/hl/data32 Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Allows the root user to read or write directly through the device's PCI bar. Writing to this file generates a write transaction while reading from the file generates a read @@ -70,7 +70,7 @@ Description:Allows the root user to read or write directly through the What: /sys/kernel/debug/habanalabs/hl/data64 Date: Jan 2020 KernelVersion: 5.6 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Allows the root user to read or write 64 bit data directly through the device's PCI bar. Writing to this file generates a write transaction while reading from the file generates a read @@ -85,7 +85,7 @@ Description:Allows the root user to read or write 64 bit data directly What: /sys/kernel/debug/habanalabs/hl/device Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Enables the root user to set the device to specific state. Valid values are "disable", "enable", "suspend", "resume". User can read this property to see the valid values @@ -93,28 +93,28 @@ Description:Enables the root user to set the device to specific state. What: /sys/kernel/debug/habanalabs/hl/engines Date: Jul 2019 KernelVersion: 5.3 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Displays the status registers values of the device engines and their derived idle status What: /sys/kernel/debug/habanalabs/hl/i2c_addr Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Sets I2C device address for I2C transaction that is generated by the device's CPU What: /sys/kernel/debug/habanalabs/hl/i2c_bus Date: Jan 2019 KernelVersion: 5.1 -Contact:oded.gab...@gmail.com +Contact:ogab...@kernel.org Description:Sets I2C bus address for I2C transaction that is generated by the device's CPU What: /sys/kernel/debug/habanalabs/hl/i2c_data
Re: [PATCH v10 0/4] drm/panfrost: Add support for mt8183 GPU
On 1/13/21 7:06 AM, Nicolas Boichat wrote: Hi! Follow-up on the v5 [1], things have gotten significantly better in the last 9 months, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). Btw, don't know if you plan to retest with a newer Mesa, but a recent master should have pretty good ES 3.0 compliance on the Duet. Cheers, Tomeu devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ [2] https://crrev.com/c/2608070 Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml| 28 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 6 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 6 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 6 files changed, 164 insertions(+)
Re: [btrfs] e86bb85b1f: stress-ng.utime.ops_per_sec -70.1% regression
On 2021/1/12 下午11:24, kernel test robot wrote:
Greeting,
FYI, we noticed a -70.1% regression of stress-ng.utime.ops_per_sec due to
commit:
commit: e86bb85b1fec48bcb8dfb79ec9f104d1a38fda78 ("[PATCH] btrfs: make
btrfs_dirty_inode() to always reserve metadata space")
url:
https://github.com/0day-ci/linux/commits/Qu-Wenruo/btrfs-make-btrfs_dirty_inode-to-always-reserve-metadata-space/20210108-134133
base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
in testcase: stress-ng
on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G
memory
with following parameters:
nr_threads: 10%
disk: 1HDD
testtime: 30s
class: filesystem
cpufreq_governor: performance
ucode: 0x5003003
fs: btrfs
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
Details are as below:
-->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
=
class/compiler/cpufreq_governor/disk/fs/kconfig/nr_threads/rootfs/tbox_group/testcase/testtime/ucode:
filesystem/gcc-9/performance/1HDD/btrfs/x86_64-rhel-8.3/10%/debian-10.4-x86_64-20200603.cgz/lkp-csl-2sp7/stress-ng/30s/0x5003003
commit:
97847e0652 ("Merge branch 'for-next-next-v5.10-20201211' into
for-next-20201211")
e86bb85b1f ("btrfs: make btrfs_dirty_inode() to always reserve metadata
space")
97847e06525b51ea e86bb85b1fec48bcb8dfb79ec9f
---
%stddev %change %stddev
\ |\
1098218 -40.4% 654054stress-ng.access.ops
36607 -40.4% 21801stress-ng.access.ops_per_sec
This is a little interesting.
Although accessing an inode will update its atime, but don't we have
lazy_atime mount option?
92962 ± 2% -44.1% 51992 ± 3% stress-ng.chmod.ops
3098 ± 2% -44.1% 1733 ± 3% stress-ng.chmod.ops_per_sec
936128 ± 6% -41.0% 552284stress-ng.chown.ops
31204 ± 6% -41.0% 18409stress-ng.chown.ops_per_sec
1939514 -18.5%1580533stress-ng.fcntl.ops
64650 -18.5% 52684stress-ng.fcntl.ops_per_sec
3705607 ± 2% -70.1%1109769stress-ng.utime.ops
123519 ± 2% -70.1% 36992stress-ng.utime.ops_per_sec
Another interesting part is, only stress-ng is reporting such
regressioin on the commit?
No other report on the commit with different test env? E.g. NVME SSD?
Above operations is affected by such commit, but I'm a little surprised
only one report here.
Just because flushing on HDD is more expensive? If no other test suite
is fine, I would prefer to accept the drop, as it really streamline the
operations.
Thanks,
Qu
381.20 ± 6% +12.3% 428.27 ± 9% sched_debug.cfs_rq:/.load_avg.avg
6316 ± 57% -79.8% 1278 ± 68% softirqs.CPU77.BLOCK
10488 ±101% -89.5% 1100 ±124% softirqs.CPU78.BLOCK
5605 ± 92% -82.3% 990.50 ± 32% softirqs.CPU80.BLOCK
6094 ±128% -89.9% 614.50 ± 44% softirqs.CPU92.BLOCK
4921 ± 9% +20.5% 5931 ± 5%
slabinfo.dmaengine-unmap-16.active_objs
4922 ± 9% +20.5% 5933 ± 5%
slabinfo.dmaengine-unmap-16.num_objs
9818 ± 5% -6.9% 9139 ± 3%
slabinfo.kmalloc-rcl-256.active_objs
49223 ± 3% -18.4% 40177 ± 3%
slabinfo.radix_tree_node.active_objs
903.25 ± 3% -18.0% 740.50 ± 3%
slabinfo.radix_tree_node.active_slabs
50620 ± 3% -18.0% 41505 ± 3% slabinfo.radix_tree_node.num_objs
903.25 ± 3% -18.0% 740.50 ± 3%
slabinfo.radix_tree_node.num_slabs
9927 ± 3% +5.8% 10504proc-vmstat.nr_active_anon
6043459 ± 2% -2.2%5911900proc-vmstat.nr_dirtied
1125-6.1% 1056 ± 4% proc-vmstat.nr_dirty
20361 ± 2% +4.7% 21309proc-vmstat.nr_shmem
66221-4.3% 63404 ± 2% proc-vmstat.nr_slab_reclaimable
9927 ± 3% +5.8% 10504proc-vmstat.nr_zone_active_anon
1225-5.8% 1154 ± 3% proc-vmstat.nr_zone_write_pending
11313111-2.1% 11072335proc-vmstat.pgfault
0.00 +125.0% 0.00 ± 19%
perf-sched.sch_delay.avg.ms.preempt_schedule_common._cond_resched.kmem_cache_alloc.start_transaction.btrfs_dirty_inode
0.01 ± 13% -24.5% 0.01 ± 15%
perf-sched.sch_delay.max.ms.do_wait.kernel_wait4.__do_sys_wait4.do_syscall_64
3.26 ±
Re: [PATCH] bio: limit bio max size.
On 2021/01/13 15:54, Changheun Lee wrote: >> On 2021/01/13 13:01, Changheun Lee wrote: On 2021/01/12 21:14, Changheun Lee wrote: >> On 2021/01/12 17:52, Changheun Lee wrote: >>> From: "Changheun Lee" >>> >>> bio size can grow up to 4GB when muli-page bvec is enabled. >>> but sometimes it would lead to inefficient behaviors. >>> in case of large chunk direct I/O, - 64MB chunk read in user space - >>> all pages for 64MB would be merged to a bio structure if memory address >>> is >>> continued phsycally. it makes some delay to submit until merge complete. >>> bio max size should be limited as a proper size. >> >> But merging physically contiguous pages into the same bvec + later >> automatic bio >> split on submit should give you better throughput for large IOs compared >> to >> having to issue a bio chain of smaller BIOs that are arbitrarily sized >> and will >> likely need splitting anyway (because of DMA boundaries etc). >> >> Do you have a specific case where you see higher performance with this >> patch >> applied ? On Intel, BIO_MAX_SIZE would be 1MB... That is arbitrary and >> too small >> considering that many hardware can execute larger IOs than that. >> > > When I tested 32MB chunk read with O_DIRECT in android, all pages of 32MB > is merged into a bio structure. > And elapsed time to merge complete was about 2ms. > It means first bio-submit is after 2ms. > If bio size is limited with 1MB with this patch, first bio-submit is about > 100us by bio_full operation. bio_submit() will split the large BIO case into multiple requests while the small BIO case will likely result one or two requests only. That likely explain the time difference here. However, for the large case, the 2ms will issue ALL requests needed for processing the entire 32MB user IO while the 1MB bio case will need 32 different bio_submit() calls. So what is the actual total latency difference for the entire 32MB user IO ? That is I think what needs to be compared here. Also, what is your device max_sectors_kb and max queue depth ? >>> >>> 32MB total latency is about 19ms including merge time without this patch. >>> But with this patch, total latency is about 17ms including merge time too. >>> Actually 32MB read time from device is same - about 16.7ms - in driver >>> layer. >>> No need to hold more I/O than max_sectors_kb during bio merge. >>> My device is UFS. and max_sectors_kb is 1MB, queue depth is 32. >> >> This may be due to the CPU being slow: it takes time to build the 32MB BIO, >> during which the device is idling. With the 1MB BIO limit, the first BIO hits >> the drive much more quickly, reducing idle time of the device and leading to >> higher throughput. But there are 31 more BIOs to build and issue after the >> first >> one... That does create a pipeline of requests keeping the device busy, but >> that >> also likely keeps your CPU a lot more busy building these additional BIOs. >> Overall, do you see a difference in CPU load for the 32MB BIO case vs the 1MB >> max BIO case ? Any increase in CPU load with the lower BIO size limit ? >> > > CPU load is more than 32MB bio size. Because bio_sumbit progress is doing in > parallel. > But I tested it same CPU operation frequency, So there are no difference of > CPU speed. > Logically, bio max size is 4GB now. it's not realistic I know, but 4GB merge > to a bio > will takes much time even if CPU works fast. > This is why I think bio max size should be limited. I do not think that the page merging code is the real root cause here. That is fast and does not depend on the current size of the BIO. This is essentially an O(1) operation. The root cause of your performance drop is most likely the fact that your device is kept idle while the large BIO is being built, adding the 8192 pages of the large 32MB user IO. Building that large BIO is a lot more efficient, CPU wise, than building and issuing a lot of small BIOs. That gives a lot of benefits on high-end desktops and servers with fast CPUs, but is counter productive in your case with a slower CPU. I wonder: what is the user IO size when you start seeing a performance drop without the patch ? It is clear that limiting the BIO size does imporve things for the 32MB IO size you tested, but what about more realistic workloads with 128K or so IO sizes (typical IO size for an FS using the page cache) ? > >>> > It's not large delay and can't be observed with low speed device. > But it's needed to reduce merge delay for high speed device. > I improved 512MB sequential read performance from 1900MB/s to 2000MB/s > with this patch on android platform. > As you said, 1MB might be small for some device. > But method is needed to re-size, or select the bio max size. At the very least, I
[PATCH for 4.9/4.14] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
From: Mathieu Desnoyers
Backport for 4.9 and 4.14
(cherry picked from commit d85be8a49e733dcd23674aa6202870d54bf5600d)
The placeholder for instruction selection should use the second
argument's operand, which is %1, not %0. This could generate incorrect
assembly code if the memory addressing of operand %0 is a different
form from that of operand %1.
Also remove the %Un placeholder because having %Un placeholders
for two operands which are based on the same local var (ptep) doesn't
make much sense. By the way, it doesn't change the current behaviour
because "<>" constraint is missing for the associated "=m".
[chleroy: revised commit log iaw segher's comments and removed %U0]
Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
Cc: # v2.6.28+
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Christophe Leroy
Acked-by: Segher Boessenkool
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/96354bd77977a6a933fe9020da57629007fdb920.1603358942.git.christophe.le...@csgroup.eu
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 4 ++--
arch/powerpc/include/asm/nohash/pgtable.h| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 016579ef16d3..ec98abca0df0 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -414,9 +414,9 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
if (pte_val(*ptep) & _PAGE_HASHPTE)
flush_hash_entry(mm, ptep, addr);
__asm__ __volatile__("\
- stw%U0%X0 %2,%0\n\
+ stw%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index 5c68f4a59f75..e9171b8242e4 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -157,9 +157,9 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
flush_hash_entry(mm, ptep, addr);
#endif
__asm__ __volatile__("\
- stw%U0%X0 %2,%0\n\
+ stw%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
--
2.25.0
[PATCH for 4.4] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
From: Mathieu Desnoyers
Backport for 4.4
(cherry picked from commit d85be8a49e733dcd23674aa6202870d54bf5600d)
The placeholder for instruction selection should use the second
argument's operand, which is %1, not %0. This could generate incorrect
assembly code if the memory addressing of operand %0 is a different
form from that of operand %1.
Also remove the %Un placeholder because having %Un placeholders
for two operands which are based on the same local var (ptep) doesn't
make much sense. By the way, it doesn't change the current behaviour
because "<>" constraint is missing for the associated "=m".
[chleroy: revised commit log iaw segher's comments and removed %U0]
Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
Cc: # v2.6.28+
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Christophe Leroy
Acked-by: Segher Boessenkool
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/96354bd77977a6a933fe9020da57629007fdb920.1603358942.git.christophe.le...@csgroup.eu
---
arch/powerpc/include/asm/pgtable.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index b64b4212b71f..408f9e1fa24a 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -149,9 +149,9 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
flush_hash_entry(mm, ptep, addr);
#endif
__asm__ __volatile__("\
- stw%U0%X0 %2,%0\n\
+ stw%X0 %2,%0\n\
eieio\n\
- stw%U0%X0 %L2,%1"
+ stw%X1 %L2,%1"
: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
: "r" (pte) : "memory");
--
2.25.0
[PATCH v2 2/4] hwmon: Add Aspeed AST2600 support
Updating index.rst and adding aspeed2600-pwm-tachometer.rst to address the driver. Changes since v1: - rename to aspeed2600-pwm-tachometer.rst - add license identifier Signed-off-by: Troy Lee --- .../hwmon/aspeed2600-pwm-tachometer.rst | 27 +++ Documentation/hwmon/index.rst | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/hwmon/aspeed2600-pwm-tachometer.rst diff --git a/Documentation/hwmon/aspeed2600-pwm-tachometer.rst b/Documentation/hwmon/aspeed2600-pwm-tachometer.rst new file mode 100644 index ..cf0d31a19597 --- /dev/null +++ b/Documentation/hwmon/aspeed2600-pwm-tachometer.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Kernel driver aspeed2600-pwm-tachometer +=== + +Supported chips: + ASPEED AST2600 + +Authors: + Ryan Chen + +Description: + +This driver implements support for ASPEED AST2600 PWM and Fan Tacho +controller. The PWM controller supports upto 16 PWM outputs. The Fan tacho +controller supports up to 16 tachometer inputs. + +The driver provides the following sensor accesses in sysfs: + +=== === = +fanX_input ro provide current fan rotation value in RPM as reported + by the fan to the device. + +pwmX rw get or set PWM fan control value. This is an integer + value between 0(off) and 255(full speed). +=== === = diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index fcb870ce6286..02020c282549 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -44,6 +44,7 @@ Hardware Monitoring Kernel Drivers asb100 asc7621 aspeed-pwm-tacho + aspeed2600-pwm-tachometer bcm54140 bel-pfe bt1-pvt -- 2.25.1
[PATCH v2 1/4] dt-bindings: hwmon: Add Aspeed AST2600 PWM/Fan
We add binding for supporting a new AST2600 PWM/Fan hwmon driver.
Changes since v1:
- dt binding with DT schema format
Signed-off-by: Troy Lee
---
.../hwmon/aspeed,ast2600-pwm-tachometer.yaml | 137 ++
1 file changed, 137 insertions(+)
create mode 100644
Documentation/devicetree/bindings/hwmon/aspeed,ast2600-pwm-tachometer.yaml
diff --git
a/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-pwm-tachometer.yaml
b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-pwm-tachometer.yaml
new file mode 100644
index ..b84076a4a338
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed,ast2600-pwm-tachometer.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/aspeed,ast2600-pwm-tachometer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 PWM and Fan Tacho controller device driver
+
+maintainers:
+ - Ryan Chen
+
+description: |
+ The ASPEED PWM controller can support upto 16 PWM outputs. The ASPEED Fan
Tacho
+ controller can support upto 16 Fan tachometer inputs.
+ There can be upto 16 fans supported. Each fan can have one PWM output and
+ one Fan tach inputs.
+
+properties:
+ compatible:
+const: aspeed,ast2600-pwm-tachometer
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ "#cooling-cells":
+const: 2
+
+ reg:
+description:
+ Address and length of the register set for the device.
+
+ clocks:
+description:
+ phandle to clock provider with the clock number in the second cell
+
+ resets:
+description:
+ phandle to reset controller with the reset number in the second cell
+
+patternProperties:
+ "@[0-9]+$":
+type: object
+description:
+ Under fan subnode there can upto 16 child nodes, with each child node
+ representing a fan. There are 16 fans each fan can have one PWM port and
one
+ Fan tach inputs.
+ For PWM port can be configured cooling-levels to create cooling device.
+ Cooling device could be bound to a thermal zone for the thermal control.
+
+properties:
+ reg:
+minimum: 0
+maximum: 15
+description:
+ This property identify the PWM control channel of this fan.
+
+ fan-tach-ch:
+$ref: /schemas/types.yaml#/definitions/uint8
+minimum: 0
+maximum: 15
+description:
+ This property identify the fan tach input channel.
+
+ pulses-per-revolution:
+$ref: /schemas/types.yaml#/definitions/uint32
+default: 2
+minimum: 1
+description:
+ Specify tacho pulse per revolution of the fan.
+
+ cooling-levels:
+description:
+ PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states.
+
+ aspeed,pwm-freq:
+$ref: /schemas/types.yaml#/definitions/uint32
+default: 25000
+minimum: 24
+maximum: 78
+description:
+ Specify the frequency of PWM.
+
+ aspeed,inverse-pin:
+type: boolean
+description:
+ Inverse PWM output signal.
+
+ aspeed,falling-point:
+$ref: /schemas/types.yaml#/definitions/uint8
+default: 10
+minimum: 0
+maximum: 255
+description:
+ Initialize the pulse width.
+
+required:
+ - fan-tach-ch
+ - reg
+
+additionalProperties: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+pwm_tacho: pwm-tacho-controller@1e61 {
+compatible = "aspeed,ast2600-pwm-tachometer";
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x1e61 0x100>;
+
+fan@1 {
+reg = <0x00>;
+aspeed,pwm-freq = <25000>;
+cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+fan-tach-ch = /bits/ 8 <0x00>;
+pulses-per-revolution = <2>;
+};
+
+fan@2 {
+reg = <0x01>;
+aspeed,pwm-freq = <25000>;
+cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+fan-tach-ch = /bits/ 8 <0x01>;
+pulses-per-revolution = <2>;
+};
+};
+...
--
2.25.1
[PATCH v2 3/4] ARM: dts: aspeed: Add Aspeed AST2600 PWM/Fan node in devicetree
Create a common node in aspeed-g6.dtsi and add fan nodes for
aspeed-ast2600-evb.dts file.
Changes since v1:
- rename properties name in child node
Signed-off-by: Troy Lee
---
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 152 +++
arch/arm/boot/dts/aspeed-g6.dtsi | 10 ++
2 files changed, 162 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
index 89be13197780..d94e70b957fb 100644
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -23,6 +23,158 @@ memory@8000 {
};
};
+_tacho {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm0_default _tach0_default
+ _pwm1_default _tach1_default
+ _pwm2_default _tach2_default
+ _pwm3_default _tach3_default
+ _pwm4_default _tach4_default
+ _pwm5_default _tach5_default
+ _pwm6_default _tach6_default
+ _pwm7_default _tach7_default
+ _pwm8g1_default _tach8_default
+ _pwm9g1_default _tach9_default
+ _pwm10g1_default _tach10_default
+ _pwm11g1_default _tach11_default
+ _pwm12g1_default _tach12_default
+ _pwm13g1_default _tach13_default
+ _pwm14g1_default _tach14_default
+ _pwm15g1_default _tach15_default>;
+
+ fan@1 {
+ reg = <0x00>;
+ aspeed,pwm-freq = <25000>;
+ aspeed,falling-point = /bits/ 8 <100>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x00>;
+ aspeed,tacho-div = <3>;
+ pulses-per-revolution = <1>;
+ };
+
+ fan@2 {
+ reg = <0x01>;
+ aspeed,pwm-freq = <25000>;
+ aspeed,falling-point = /bits/ 8 <100>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x01>;
+ pulses-per-revolution = <1>;
+ };
+
+ fan@3 {
+ reg = <0x02>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x02>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@4 {
+ reg = <0x03>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x03>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@5 {
+ reg = <0x04>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x04>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@6 {
+ reg = <0x05>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x05>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@7 {
+ reg = <0x06>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x06>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@8 {
+ reg = <0x07>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x07>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@9 {
+ reg = <0x08>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x08>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@10 {
+ reg = <0x09>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x09>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@11 {
+ reg = <0x0a>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x0a>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@12 {
+ reg = <0x0b>;
+ aspeed,pwm-freq = <25000>;
+ cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
+ fan-tach-ch = /bits/ 8 <0x0b>;
+ pulses-per-revolution = <2>;
+ };
+
+ fan@13 {
+ reg = <0x0c>;
+ aspeed,pwm-freq = <25000>;
+
[PATCH v2 4/4] hwmon: Support Aspeed AST2600 PWM/Fan tachometer
Add Aspeed AST2600 PWM/Fan tacho driver. AST2600 has 16 PWM channel and 16 FAN tacho channel. Changes since v1: - fixed review comments - fixed double-looped calculation of div_h and div_l - moving configuration to device tree - register hwmon driver with devm_hwmon_device_register_with_info() Signed-off-by: Troy Lee --- drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile | 1 + drivers/hwmon/aspeed2600-pwm-tacho.c | 756 +++ 3 files changed, 767 insertions(+) create mode 100644 drivers/hwmon/aspeed2600-pwm-tacho.c diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 1ecf697d8d99..98f89f703161 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -400,6 +400,16 @@ config SENSORS_ASPEED This driver can also be built as a module. If so, the module will be called aspeed_pwm_tacho. +config SENSORS_ASPEED2600_PWM_TACHO + tristate "ASPEED AST2600 PWM and Fan Tachometer" + depends on THERMAL || THERMAL=n + help + This driver provides support for ASPEED AST2600 PWM + and Fan Tacho controllers. + + This driver can also be built as a module. If so, the module + will be called aspeed2600-pwm-tacho. + config SENSORS_ATXP1 tristate "Attansic ATXP1 VID controller" depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 09a86c5e1d29..1a415d493ffc 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_SENSORS_ARM_SCPI)+= scpi-hwmon.o obj-$(CONFIG_SENSORS_AS370)+= as370-hwmon.o obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o +obj-$(CONFIG_SENSORS_ASPEED2600_PWM_TACHO) += aspeed2600-pwm-tacho.o obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o obj-$(CONFIG_SENSORS_BT1_PVT) += bt1-pvt.o diff --git a/drivers/hwmon/aspeed2600-pwm-tacho.c b/drivers/hwmon/aspeed2600-pwm-tacho.c new file mode 100644 index ..150cf65243ee --- /dev/null +++ b/drivers/hwmon/aspeed2600-pwm-tacho.c @@ -0,0 +1,756 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Copyright (C) ASPEED Technology Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 or later as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +/** + * PWM HW register offset define + */ +/* PWM Control Register */ +#define ASPEED_PWM_CTRL_CH(ch) (((ch) * 0x10) + 0x00) +/* PWM Duty Cycle Register */ +#define ASPEED_PWM_DUTY_CYCLE_CH(ch) (((ch) * 0x10) + 0x04) +/* TACH Control Register */ +#define ASPEED_TACHO_CTRL_CH(ch) (((ch) * 0x10) + 0x08) +/* TACH Status Register */ +#define ASPEED_TACHO_STS_CH(x) (((x) * 0x10) + 0x0C) + +/** + * PWM register Bit field + */ +/*PWM_CTRL */ +#define PWM_LOAD_SEL_AS_WDT_BIT(19)/* load selection as WDT */ +#define PWM_DUTY_LOAD_AS_WDT_ENBIT(18) /* enable PWM duty load as WDT */ +#define PWM_DUTY_SYNC_DIS BIT(17) /* disable PWM duty sync */ +#define PWM_CLK_ENABLE BIT(16) /* enable PWM clock */ +#define PWM_LEVEL_OUTPUT BIT(15) /* output PWM level */ +#define PWM_INVERSEBIT(14) /* inverse PWM pin */ +#define PWM_OPEN_DRAIN_EN BIT(13) /* enable open-drain */ +#define PWM_PIN_EN BIT(12) /* enable PWM pin */ +#define PWM_CLK_DIV_H_MASK (0xf << 8) /* PWM clock division H bit [3:0] */ +#define PWM_CLK_DIV_L_MASK (0xff) /* PWM clock division H bit [3:0] */ +/* [19] */ +#define LOAD_SEL_FALLING 0 +#define LOAD_SEL_RIGING 1 + +/*PWM_DUTY_CYCLE */ +#define PWM_PERIOD_BIT (24)/* pwm period bit [7:0] */ +#define PWM_PERIOD_BIT_MASK(0xff << 24)/* pwm period bit [7:0] */ +#define PWM_RISING_FALLING_AS_WDT_BIT (16) +#define PWM_RISING_FALLING_AS_WDT_MASK (0xff << 16)/* rising/falling point bit [7:0] as WDT */ +#define PWM_RISING_FALLING_MASK(0x) +#define PWM_FALLING_POINT_BIT (8) /* pwm falling point bit [7:0] */ +#define PWM_RISING_POINT_BIT (0) /* pwm rising point bit [7:0] */ +/* [31:24] */ +#define DEFAULT_PWM_PERIOD 0xff + +/*PWM_TACHO_CTRL */ +#define TACHO_IER BIT(31) /* enable tacho interrupt */ +#define TACHO_INVERS_LIMIT
[PATCH v2 0/4] hwmon: aspeed2600-pwm-tacho: Add driver support
Aspeed AST2600 is a server management SoC which has 16 PWM channels and 16 fan tacho channel. This series of patch provides AST2600 PWM/Fan tacho support in hwmon class. The driver provides a sysfs interface, and user can configure PWM duty cycle and read current FAN speed in RPM. Change since v1: - dt-binding rewrote with dt schema format - register hwmon driver with devm_hwmon_device_register_with_info() - moving default configurations to device tree *** BLURB HERE *** Troy Lee (4): dt-bindings: hwmon: Add Aspeed AST2600 PWM/Fan hwmon: Add Aspeed AST2600 support ARM: dts: aspeed: Add Aspeed AST2600 PWM/Fan node in devicetree hwmon: Support Aspeed AST2600 PWM/Fan tachometer .../hwmon/aspeed,ast2600-pwm-tachometer.yaml | 137 .../hwmon/aspeed2600-pwm-tachometer.rst | 27 + Documentation/hwmon/index.rst | 1 + arch/arm/boot/dts/aspeed-ast2600-evb.dts | 152 arch/arm/boot/dts/aspeed-g6.dtsi | 10 + drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile| 1 + drivers/hwmon/aspeed2600-pwm-tacho.c | 756 ++ 8 files changed, 1094 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed,ast2600-pwm-tachometer.yaml create mode 100644 Documentation/hwmon/aspeed2600-pwm-tachometer.rst create mode 100644 drivers/hwmon/aspeed2600-pwm-tacho.c -- 2.25.1
[PATCH for doc-next] doc/zh_CN: mips: use doc references instead
The Chinese mips translations refer to non-existing labels in the original documentation. Hence, make htmldocs warns about those undefined labels on all files in ./Documentation/translations/zh_CN/mips/. Replace the references to non-existing labels with suitable doc references. Signed-off-by: Lukas Bulwahn --- applies cleanly on next-20210113 Yanteng, please ack. Jonathan, please pick this doc warning fixup on your -next tree. Documentation/translations/zh_CN/mips/booting.rst | 2 +- Documentation/translations/zh_CN/mips/features.rst| 2 +- Documentation/translations/zh_CN/mips/index.rst | 2 +- Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/translations/zh_CN/mips/booting.rst b/Documentation/translations/zh_CN/mips/booting.rst index 3099d0fff7a6..96453e1b962e 100644 --- a/Documentation/translations/zh_CN/mips/booting.rst +++ b/Documentation/translations/zh_CN/mips/booting.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/booting.rst ` +:Original: :doc:`../../../mips/booting` :Translator: Yanteng Si .. _cn_booting: diff --git a/Documentation/translations/zh_CN/mips/features.rst b/Documentation/translations/zh_CN/mips/features.rst index 7e67f81a0982..93d93d06b1b3 100644 --- a/Documentation/translations/zh_CN/mips/features.rst +++ b/Documentation/translations/zh_CN/mips/features.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/features.rst ` +:Original: :doc:`../../../mips/features` :Translator: Yanteng Si .. _cn_features: diff --git a/Documentation/translations/zh_CN/mips/index.rst b/Documentation/translations/zh_CN/mips/index.rst index 2c7b836a3da5..27a2eae8484a 100644 --- a/Documentation/translations/zh_CN/mips/index.rst +++ b/Documentation/translations/zh_CN/mips/index.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/index.rst ` +:Original: :doc:`../../../mips/index` :Translator: Yanteng Si .. _cn_index: diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst index 9324a0a26430..f04ba407384a 100644 --- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst +++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/ingenic-tcu.rst ` +:Original: :doc:`../../../mips/ingenic-tcu` :Translator: Yanteng Si .. _cn_ingenic-tcu: -- 2.17.1
Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default
Hi Saravana,
On 12.01.2021 21:51, Saravana Kannan wrote:
> On Mon, Jan 11, 2021 at 11:11 PM Marek Szyprowski
> wrote:
>> On 11.01.2021 22:47, Saravana Kannan wrote:
>>> On Mon, Jan 11, 2021 at 6:18 AM Marek Szyprowski
>>> wrote:
On 11.01.2021 12:12, Marek Szyprowski wrote:
> On 18.12.2020 04:17, Saravana Kannan wrote:
>> Cyclic dependencies in some firmware was one of the last remaining
>> reasons fw_devlink=on couldn't be set by default. Now that cyclic
>> dependencies don't block probing, set fw_devlink=on by default.
>>
>> Setting fw_devlink=on by default brings a bunch of benefits (currently,
>> only for systems with device tree firmware):
>> * Significantly cuts down deferred probes.
>> * Device probe is effectively attempted in graph order.
>> * Makes it much easier to load drivers as modules without having to
>> worry about functional dependencies between modules (depmod is still
>> needed for symbol dependencies).
>>
>> If this patch prevents some devices from probing, it's very likely due
>> to the system having one or more device drivers that "probe"/set up a
>> device (DT node with compatible property) without creating a struct
>> device for it. If we hit such cases, the device drivers need to be
>> fixed so that they populate struct devices and probe them like normal
>> device drivers so that the driver core is aware of the devices and their
>> status. See [1] for an example of such a case.
>>
>> [1] -
>> https://lore.kernel.org/lkml/CAGETcx9PiX==mlxb9po8myyk6u2vhpvwtmsa5nkd-ywh5xh...@mail.gmail.com/
>> Signed-off-by: Saravana Kannan
> This patch landed recently in linux next-20210111 as commit
> e590474768f1 ("driver core: Set fw_devlink=on by default"). Sadly it
> breaks Exynos IOMMU operation, what causes lots of devices being
> deferred and not probed at all. I've briefly checked and noticed that
> exynos_sysmmu_probe() is never called after this patch. This is really
> strange for me, as the SYSMMU controllers on Exynos platform are
> regular platform devices registered by the OF code. The driver code is
> here: drivers/iommu/exynos-iommu.c, example dts:
> arch/arm/boot/dts/exynos3250.dtsi (compatible = "samsung,exynos-sysmmu").
Okay, I found the source of this problem. It is caused by Exynos power
domain driver, which is not platform driver yet. I will post a patch,
which converts it to the platform driver.
>>> Thanks Marek! Hopefully the debug logs I added were sufficient to
>>> figure out the reason.
>> Frankly, it took me a while to figure out that device core waits for the
>> power domain devices. Maybe it would be possible to add some more debug
>> messages or hints? Like the reason of the deferred probe in
>> /sys/kernel/debug/devices_deferred ?
> There's already a /sys/devices/...//waiting_for_supplier file
> that tells you if the device is waiting for a supplier device to be
> added. That file goes away once the device probes. If the file has 1,
> then it's waiting for the supplier device to be added (like your
> case). If it's 0, then the device is just waiting on one of the
> existing suppliers to probe. You can find the existing suppliers
> through /sys/devices/...//supplier:*/supplier. Also, flip
> these dev_dbg() to dev_info() if you need more details about deferred
> probing.
Frankly speaking I doubt that anyone will find those. Even experienced
developer might need some time to figure it out.
I expect that such information will be at least in the mentioned
/sys/kernel/debug/devices_deferred file. We already have infrastructure
for putting the deferred probe reason there, see dev_err_probe()
function. Even such a simple change makes the debugging this issue much
easier:
diff --git a/drivers/base/core.c b/drivers/base/core.c
index cd8e518fadd6..ceb5aed5a84c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -937,12 +937,13 @@ int device_links_check_suppliers(struct device *dev)
mutex_lock(_link_lock);
if (dev->fwnode && !list_empty(>fwnode->suppliers) &&
!fw_devlink_is_permissive()) {
- dev_dbg(dev, "probe deferral - wait for supplier %pfwP\n",
+ ret = dev_err_probe(dev, -EPROBE_DEFER,
+ "probe deferral - wait for supplier %pfwP\n",
list_first_entry(>fwnode->suppliers,
struct fwnode_link,
c_hook)->supplier);
mutex_unlock(_link_lock);
- return -EPROBE_DEFER;
+ return ret;
}
mutex_unlock(_link_lock);
@@ -955,9 +956,9 @@ int device_links_check_suppliers(struct device *dev)
if (link->status != DL_STATE_AVAILABLE &&
!(link->flags & DL_FLAG_SYNC_STATE_ONLY)) {
device_links_missing_supplier(dev);
- dev_dbg(dev, "probe
Re: [PATCH V2 3/3] s390/mm: Define arch_get_mappable_range()
On 1/11/21 4:10 PM, David Hildenbrand wrote:
> On 17.12.20 16:28, Anshuman Khandual wrote:
>> This overrides arch_get_mappabble_range() on s390 platform which will be
>> used with recently added generic framework. It modifies the existing range
>> check in vmem_add_mapping() using arch_get_mappable_range(). It also adds a
>> VM_BUG_ON() check that would ensure that memhp_range_allowed() has already
>> been called on the hotplug path.
>>
>> Cc: Heiko Carstens
>> Cc: Vasily Gorbik
>> Cc: David Hildenbrand
>> Cc: linux-s...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Acked-by: Heiko Carstens
>> Signed-off-by: Anshuman Khandual
>> ---
>> arch/s390/mm/init.c | 1 +
>> arch/s390/mm/vmem.c | 15 ++-
>> 2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
>> index 77767850d0d0..e0e78234ae57 100644
>> --- a/arch/s390/mm/init.c
>> +++ b/arch/s390/mm/init.c
>> @@ -291,6 +291,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
>> if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot))
>> return -EINVAL;
>>
>> +VM_BUG_ON(!memhp_range_allowed(start, size, 1));
>
> s/1/true/
Sure, will do.
>
>> rc = vmem_add_mapping(start, size);
>> if (rc)
>> return rc;
>> diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
>> index b239f2ba93b0..e10e563ad2b4 100644
>> --- a/arch/s390/mm/vmem.c
>> +++ b/arch/s390/mm/vmem.c
>> @@ -4,6 +4,7 @@
>> *Author(s): Heiko Carstens
>> */
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -532,11 +533,23 @@ void vmem_remove_mapping(unsigned long start, unsigned
>> long size)
>> mutex_unlock(_mutex);
>> }
>>
>> +struct range arch_get_mappable_range(void)
>> +{
>> +struct range memhp_range;
>> +
>> +memhp_range.start = 0;
>> +memhp_range.end = VMEM_MAX_PHYS;
>
> s/ / /
>
> IIRC, the range is inclusive? "VMEM_MAX_PHYS - 1" then, and adjust the
> check below.
Right, the memory range is inclusive at both ends. Hence will update the
code here.
diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
index 21cabe3473d7..afc39ff1cc8d 100644
--- a/arch/s390/mm/vmem.c
+++ b/arch/s390/mm/vmem.c
@@ -538,7 +538,7 @@ struct range arch_get_mappable_range(void)
struct range memhp_range;
memhp_range.start = 0;
- memhp_range.end = VMEM_MAX_PHYS;
+ memhp_range.end = VMEM_MAX_PHYS - 1;
return memhp_range;
}
@@ -549,7 +549,7 @@ int vmem_add_mapping(unsigned long start, unsigned long
size)
range = arch_get_mappable_range();
if (start < range.start ||
- start + size > range.end ||
+ start + size > range.end + 1 ||
start + size < start)
return -ERANGE;
(start + size - 1) is valid only when it is upto the inclusive range.end value.
[PATCH for doc-next] doc/zh_CN: adjust table markup in mips/ingenic-tcu.rst
Commit 419b1d4ed1cb ("doc/zh_CN: add mips ingenic-tcu.rst translation")
introduces a warning with make htmldocs:
./Documentation/translations/zh_CN/mips/ingenic-tcu.rst:
61: WARNING: Malformed table. Text in column margin in table line 6.
Adjust the table markup to address this warning.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20210113
Yanteng, please ack.
Jonathan, please pick this doc warning fixup on your -next tree.
Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
index 72b5d409ed89..9324a0a26430 100644
--- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
+++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
@@ -53,14 +53,14 @@
TCU硬件的功能分布在多个驱动程序：
-=== =
+== ===
时钟drivers/clk/ingenic/tcu.c
中断drivers/irqchip/irq-ingenic-tcu.c
定时器 drivers/clocksource/ingenic-timer.c
OST drivers/clocksource/ingenic-ost.c
脉冲宽度调制器 drivers/pwm/pwm-jz4740.c
看门狗 drivers/watchdog/jz4740_wdt.c
-=== =
+== ===
因为可以从相同的寄存器控制属于不同驱动程序和框架的TCU的各种功能，所以
所有这些驱动程序都通过相同的控制总线通用接口访问它们的寄存器。
--
2.17.1
Re: [PATCH 2/2] ASoC: cros_ec_codec: Reset I2S RX when probing
Enric Balletbo i Serra 於 2021年1月13日 週三 上午12:34寫道： > > Hi Yu-Hsuan, > > Thank you for the patch. > > On 7/1/21 9:59, Yu-Hsuan Hsu wrote: > > It is not guaranteed that I2S RX is disabled when the kernel booting. > > For example, if the kernel crashes while it is enabled, it will keep > > enabled until the next time EC reboots. Reset I2S RX when probing to > > fix this issue. > > > > Signed-off-by: Yu-Hsuan Hsu > > If I am not mistaken this is the four version of this patchset (see [1]). > Please > prefix your patches with the proper version and maintain a changelog for them, > otherwise makes difficult to follow all the discussions already done. > > [1] > v1: https://lkml.org/lkml/2020/7/8/173 > v2: > https://mailman.alsa-project.org/pipermail/alsa-devel/2020-July/170933.html > v3: > https://patchwork.kernel.org/project/alsa-devel/patch/20210106050559.1459027-1-yuhs...@chromium.org/ > v4: https://patchwork.kernel.org/project/alsa-devel/list/?series=410441 Sorry that I forgot to add version. Will add v5 in the next patch. Thanks! > > > --- > > sound/soc/codecs/cros_ec_codec.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/sound/soc/codecs/cros_ec_codec.c > > b/sound/soc/codecs/cros_ec_codec.c > > index f33a2a9654e7..28b3e2c48c86 100644 > > --- a/sound/soc/codecs/cros_ec_codec.c > > +++ b/sound/soc/codecs/cros_ec_codec.c > > @@ -1011,6 +1011,13 @@ static int cros_ec_codec_platform_probe(struct > > platform_device *pdev) > > } > > priv->ec_capabilities = r.capabilities; > > > > + /* Reset EC codec i2s rx. */ > > + p.cmd = EC_CODEC_I2S_RX_RESET; > > + ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX, > > +(uint8_t *), sizeof(p), NULL, 0); > > + if (ret) > > + dev_warn(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret); > > + > > My comment in the first version is still valid, I guess. This command was > introduced later and with an old firmware I suspect this message will appear > on > every boot, right? So, to solve the issue and get rid of this warn you're > forced > to upgrade the firmware. Would make sense to handle returned error value to > warn > when the firmware needs to be updated and error and break when is really an > error? > > We have mapped ec error codes to linux error codes. So, it should be possible > now. Oh, I didn't notice it. Thanks for the remind. I will work on it. > > Thanks, > Enric > > > platform_set_drvdata(pdev, priv); > > > > ret = devm_snd_soc_register_component(dev, _rx_component_driver, > >
Re: regression in iwlwifi: page fault in iwl_dbg_tlv_alloc_region() (commit ba8f6f4ae254)
Takashi Iwai writes:
> On Tue, 12 Jan 2021 16:46:21 +0100,
> Kalle Valo wrote:
>>
>> Takashi Iwai writes:
>>
>> > On Tue, 12 Jan 2021 13:45:33 +0100,
>> > Kalle Valo wrote:
>> >>
>> >> Takashi Iwai writes:
>> >>
>> >> > On Tue, 12 Jan 2021 12:33:14 +0100,
>> >> > Kalle Valo wrote:
>> >> >>
>> >> >> (adding luca)
>> >> >>
>> >> >> Michal Kubecek writes:
>> >> >>
>> >> >> > FYI, there is a regression in iwlwifi driver caused by commit
>> >> >> > ba8f6f4ae254 ("iwlwifi: dbg: add dumping special device memory")
>> >> >> > reported at
>> >> >> >
>> >> >> > https://bugzilla.kernel.org/show_bug.cgi?id=210733
>> >> >> > https://bugzilla.suse.com/show_bug.cgi?id=1180344
>> >> >> >
>> >> >> > The problem seems to be an attempt to write terminating null
>> >> >> > character
>> >> >> > into a string which may be read only. There is also a proposed fix.
>> >> >>
>> >> >> Can someone submit a proper patch, please? See instructions below how
>> >> >> to
>> >> >> submit.
>> >> >>
>> >> >> And please add Fixes tag to the commit log:
>> >> >>
>> >> >> Fixes: ba8f6f4ae254 ("iwlwifi: dbg: add dumping special device memory")
>> >> >
>> >> > OK, I'll do it for my own
>> >>
>> >> Thanks.
>> >>
>> >> > but really I hoped that someone would have reacted on the bugzilla
>> >> > report before the official patch submission. So far no one from the
>> >> > upstream devs showed interest in the bug at all, unfortunately.
>> >>
>> >> Bugzilla is problematic as I don't know if anyone tracks it actively, at
>> >> least I don't have time for that. I recommend reporting all wireless
>> >> issues to mailing lists to make sure everyone see it.
>> >
>> > I share your feeling as a subsystem maintainer, but at the same time,
>> > I see it's a big problem if the whole bugzilla reports are just
>> > silently ignored. If it's a void, shouldn't we rather shut it down?
>>
>> I'm all for shutting down bugzilla.kernel.org as silent bug reports are
>> frustrating the users. But I don't know what others would think about
>> that, maybe some subsystems use it actively?
>
> Yes, I'm still checking bugzilla.kernel.org for sound bug reports.
> Not always promptly reacting like the distro bugzilla, but it's
> regularly scanned and covered in the best effort basis.
>
> Graphics people already moved out of bugzilla to gitlab Issues in
> their own gitlab.freedesktop.org. Not sure about others.
>
>> At least there should be a big warning for wireless bugs.
>
> Maybe we can ask Konstantin about that at least for wireless
> components?
Yeah, that would be a good idea. Can someone ask that?
BTW, I checked our wiki and it states[1] that bug reports should be sent
to the mailing list. But of course that information is pretty well
hidden within the wiki so I doubt anyone sees it. Also there should be a
big warning about bugzilla bugs. Any volunteers to improve our wiki? :)
[1]
https://wireless.wiki.kernel.org/en/users/documentation/reporting_bugs#drivers_mac80211_cfg80211_--_kernel_wireless_bugs
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: Re: [PATCH] bio: limit bio max size.
>On 2021/01/13 13:01, Changheun Lee wrote:
>>> On 2021/01/12 21:14, Changheun Lee wrote:
> On 2021/01/12 17:52, Changheun Lee wrote:
>> From: "Changheun Lee"
>>
>> bio size can grow up to 4GB when muli-page bvec is enabled.
>> but sometimes it would lead to inefficient behaviors.
>> in case of large chunk direct I/O, - 64MB chunk read in user space -
>> all pages for 64MB would be merged to a bio structure if memory address
>> is
>> continued phsycally. it makes some delay to submit until merge complete.
>> bio max size should be limited as a proper size.
>
> But merging physically contiguous pages into the same bvec + later
> automatic bio
> split on submit should give you better throughput for large IOs compared
> to
> having to issue a bio chain of smaller BIOs that are arbitrarily sized
> and will
> likely need splitting anyway (because of DMA boundaries etc).
>
> Do you have a specific case where you see higher performance with this
> patch
> applied ? On Intel, BIO_MAX_SIZE would be 1MB... That is arbitrary and
> too small
> considering that many hardware can execute larger IOs than that.
>
When I tested 32MB chunk read with O_DIRECT in android, all pages of 32MB
is merged into a bio structure.
And elapsed time to merge complete was about 2ms.
It means first bio-submit is after 2ms.
If bio size is limited with 1MB with this patch, first bio-submit is about
100us by bio_full operation.
>>>
>>> bio_submit() will split the large BIO case into multiple requests while the
>>> small BIO case will likely result one or two requests only. That likely
>>> explain
>>> the time difference here. However, for the large case, the 2ms will issue
>>> ALL
>>> requests needed for processing the entire 32MB user IO while the 1MB bio
>>> case
>>> will need 32 different bio_submit() calls. So what is the actual total
>>> latency
>>> difference for the entire 32MB user IO ? That is I think what needs to be
>>> compared here.
>>>
>>> Also, what is your device max_sectors_kb and max queue depth ?
>>>
>>
>> 32MB total latency is about 19ms including merge time without this patch.
>> But with this patch, total latency is about 17ms including merge time too.
>> Actually 32MB read time from device is same - about 16.7ms - in driver layer.
>> No need to hold more I/O than max_sectors_kb during bio merge.
>> My device is UFS. and max_sectors_kb is 1MB, queue depth is 32.
>
>This may be due to the CPU being slow: it takes time to build the 32MB BIO,
>during which the device is idling. With the 1MB BIO limit, the first BIO hits
>the drive much more quickly, reducing idle time of the device and leading to
>higher throughput. But there are 31 more BIOs to build and issue after the
>first
>one... That does create a pipeline of requests keeping the device busy, but
>that
>also likely keeps your CPU a lot more busy building these additional BIOs.
>Overall, do you see a difference in CPU load for the 32MB BIO case vs the 1MB
>max BIO case ? Any increase in CPU load with the lower BIO size limit ?
>
CPU load is more than 32MB bio size. Because bio_sumbit progress is doing in
parallel.
But I tested it same CPU operation frequency, So there are no difference of CPU
speed.
Logically, bio max size is 4GB now. it's not realistic I know, but 4GB merge to
a bio
will takes much time even if CPU works fast.
This is why I think bio max size should be limited.
>>
It's not large delay and can't be observed with low speed device.
But it's needed to reduce merge delay for high speed device.
I improved 512MB sequential read performance from 1900MB/s to 2000MB/s
with this patch on android platform.
As you said, 1MB might be small for some device.
But method is needed to re-size, or select the bio max size.
>>>
>>> At the very least, I think that such limit should not be arbitrary as your
>>> patch
>>> proposes but rely on the device characteristics (e.g.
>>> max_hw_sectors_kb/max_sectors_kb and queue depth).
>>>
>>
>> I agree with your opinion, I thought same as your idea. For that, deep
>> research
>> is needed, proper timing to set and bio structure modification, etc ...
>
>Why would you need any BIO structure modifications ? Your patch is on the right
>track if limiting the BIO size is the right solution (I am not still completely
>convinced). E.g., the code:
>
>if (page_is_mergeable(bv, page, len, off, same_page)) {
>if (bio->bi_iter.bi_size > BIO_MAX_SIZE - len) {
>*same_page = false;
>return false;
>}
>
>could just become:
>
>if (page_is_mergeable(bv, page, len, off, same_page)) {
>if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
>*same_page = false;
>return false;
>}
>
>With bio_max_size() being something like:
>
>static inline size_t bio_max_size(struct bio *bio)
>{
>sector_t max_sectors = blk_queue_get_max_sectors(bio->bi_disk->queue,
>bio_op(bio));
>
Re: [PATCH V8 1/1] i2c: i2c-qcom-geni: Add shutdown callback for i2c
Quoting Roja Rani Yarubandi (2021-01-08 07:05:45)
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 214b4c913a13..c3f584795911 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -375,6 +375,32 @@ static void geni_i2c_tx_msg_cleanup(struct geni_i2c_dev
> *gi2c,
> }
> }
>
> +static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
> +{
> + int ret;
> + u32 geni_status;
> + struct i2c_msg *cur;
> +
> + /* Resume device, as runtime suspend can happen anytime during
> transfer */
> + ret = pm_runtime_get_sync(gi2c->se.dev);
> + if (ret < 0) {
> + dev_err(gi2c->se.dev, "Failed to resume device: %d\n", ret);
> + return;
> + }
> +
> + geni_status = readl_relaxed(gi2c->se.base + SE_GENI_STATUS);
> + if (geni_status & M_GENI_CMD_ACTIVE) {
> + cur = gi2c->cur;
Why don't we need to hold the spinlock gi2c::lock here?
> + geni_i2c_abort_xfer(gi2c);
> + if (cur->flags & I2C_M_RD)
> + geni_i2c_rx_msg_cleanup(gi2c, cur);
> + else
> + geni_i2c_tx_msg_cleanup(gi2c, cur);
> + }
> +
> + pm_runtime_put_sync_suspend(gi2c->se.dev);
> +}
> +
> static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg
> *msg,
> u32 m_param)
> {
[rcu:dev.2021.01.11b] BUILD SUCCESS 3f91ff7fd4f76e7eb48bad79666c466bc3530324
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2021.01.11b branch HEAD: 3f91ff7fd4f76e7eb48bad79666c466bc3530324 rcu: Remove spurious instrumentation_end() in rcu_nmi_enter() elapsed time: 722m configs tested: 142 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm colibri_pxa300_defconfig sh se7206_defconfig arc nsimosci_hs_smp_defconfig powerpc lite5200b_defconfig sh sh7785lcr_32bit_defconfig mips lemote2f_defconfig arm tct_hammer_defconfig c6x defconfig riscvnommu_virt_defconfig xtensa alldefconfig armtrizeps4_defconfig mips decstation_defconfig sh sh7770_generic_defconfig armhisi_defconfig c6xevmc6472_defconfig microblaze defconfig xtensa cadence_csp_defconfig arm sama5_defconfig powerpcmpc7448_hpc2_defconfig arm shannon_defconfig m68k amiga_defconfig mipsqi_lb60_defconfig ia64 bigsur_defconfig powerpc mpc836x_mds_defconfig sh se7780_defconfig arm moxart_defconfig powerpc arches_defconfig arm rpc_defconfig arcnsimosci_defconfig m68k multi_defconfig mips cavium_octeon_defconfig riscvalldefconfig archsdk_defconfig armxcep_defconfig powerpc ksi8560_defconfig arm corgi_defconfig sh r7785rp_defconfig powerpc eiger_defconfig m68kmac_defconfig powerpc tqm8548_defconfig arm spear13xx_defconfig powerpc ep88xc_defconfig sh rsk7264_defconfig shapsh4ad0a_defconfig mips rbtx49xx_defconfig armqcom_defconfig shecovec24-romimage_defconfig arm tango4_defconfig mips ath25_defconfig sh sh2007_defconfig powerpc rainier_defconfig m68k amcore_defconfig arm lubbock_defconfig h8300alldefconfig arm orion5x_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20210112 i386 randconfig-a005-20210112 i386 randconfig-a006-20210112 i386 randconfig-a003-20210112 i386 randconfig-a001-20210112 i386 randconfig-a004-20210112 i386 randconfig-a002
[PATCH] of: property: add port base loop
From: Kuninori Morimoto
We have endpoint base functions
- of_graph_get_next_endpoint()
- of_graph_get_endpoint_count()
- for_each_endpoint_of_node()
Here, for_each_endpoint_of_node() loop finds endpoint
ports {
port@0 {
(1) endpoint {...};
};
port@1 {
(2) endpoint {...};
};
...
};
In above case, for_each_endpoint_of_node() loop
finds endpoint as (1) -> (2) -> ...
We can check endpoint parent to get its port
if user want to do something to it.
But port can have multi endpoints.
In such case, it is difficult to find
port@0 -> port@1 -> ...
ports {
port@0 {
(1) endpoint@0 {...};
(2) endpoint@1 {...};
};
port@1 {
(3) endpoint {...};
};
...
};
In such case, people want to have port base loop
instead of endpoints base loop.
This patch adds such functions/macros.
Signed-off-by: Kuninori Morimoto
---
drivers/of/property.c| 69 ++--
include/linux/of_graph.h | 14
2 files changed, 73 insertions(+), 10 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 5f9eed79a8aa..9b511cfe97b3 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -631,15 +631,7 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
* parent port node.
*/
if (!prev) {
- struct device_node *node;
-
- node = of_get_child_by_name(parent, "ports");
- if (node)
- parent = node;
-
- port = of_get_child_by_name(parent, "port");
- of_node_put(node);
-
+ port = of_graph_get_next_port(parent, NULL);
if (!port) {
pr_err("graph: no port node found in %pOF\n", parent);
return NULL;
@@ -666,14 +658,59 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
/* No more endpoints under this port, try the next one. */
prev = NULL;
+ port = of_graph_get_next_port(parent, port);
+ if (!port)
+ return NULL;
+ }
+}
+EXPORT_SYMBOL(of_graph_get_next_endpoint);
+
+/**
+ * of_graph_get_next_port() - get next port node
+ * @parent: pointer to the parent device node
+ * @prev: previous port node, or NULL to get first
+ *
+ * Return: An 'port' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *port = prev;
+
+ if (!parent)
+ return NULL;
+
+ /*
+* Start by locating the port node. If no previous endpoint is specified
+* search for the first port node, otherwise get the previous endpoint
+* parent port node.
+*/
+ if (!port) {
+ struct device_node *node;
+
+ node = of_get_child_by_name(parent, "ports");
+ if (node)
+ parent = node;
+
+ port = of_get_child_by_name(parent, "port");
+ of_node_put(node);
+
+ if (!port) {
+ pr_err("graph: no port node found in %pOF\n", parent);
+ return NULL;
+ }
+ } else {
do {
port = of_get_next_child(parent, port);
if (!port)
return NULL;
} while (!of_node_name_eq(port, "port"));
}
+
+ return port;
}
-EXPORT_SYMBOL(of_graph_get_next_endpoint);
+EXPORT_SYMBOL(of_graph_get_next_port);
/**
* of_graph_get_endpoint_by_regs() - get endpoint node of specific identifiers
@@ -800,6 +837,18 @@ int of_graph_get_endpoint_count(const struct device_node
*np)
}
EXPORT_SYMBOL(of_graph_get_endpoint_count);
+int of_graph_get_port_count(const struct device_node *np)
+{
+ struct device_node *port;
+ int num = 0;
+
+ for_each_port_of_node(np, port)
+ num++;
+
+ return num;
+}
+EXPORT_SYMBOL(of_graph_get_port_count);
+
/**
* of_graph_get_remote_node() - get remote parent device_node for given
port/endpoint
* @node: pointer to parent device_node containing graph port/endpoint
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 4d7756087b6b..8cd3bd674ebd 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -26,6 +26,17 @@ struct of_endpoint {
const struct device_node *local_node;
};
+/**
+ * for_each_port_of_node - iterate over every port in a
Re: [PATCH v4 1/2] dt-bindings: input: cros-ec-keyb: Add a new property
Quoting Philip Chen (2021-01-12 15:29:11) > On Mon, Jan 11, 2021 at 6:10 PM Stephen Boyd wrote: > > Quoting Philip Chen (2021-01-07 15:42:08) > > > --- > > > diff --git > > > a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > > b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > > index 8e50c14a9d778..7acdb33781d30 100644 > > > --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > > +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > > @@ -31,6 +31,16 @@ properties: > > >if the EC does not have its own logic or hardware for this. > > > type: boolean > > > > > > + function-row-physmap: > > > > Is there any minimum/maximum number of elements possible? > The maximum is 15. > There is no definition for the minimum - we can probably say the minimum is 1. Ok cool. Please add min/max of 1 to 15 to the binding. > > > > > +$ref: '/schemas/types.yaml#/definitions/uint32-array' > > > +description: | > > > + An ordered u32 array describing the rows/columns (in the scan > > > matrix) > > > + of top row keys from physical left (KEY_F1) to right. Each entry > > > + encodes the row/column as: > > > + (((row) & 0xFF) << 24) | (((column) & 0xFF) << 16) > > > + where the lower 16 bits are reserved. This property is specified > > > only > > > + when the keyboard has a custom design for the top row keys. > > > +
Re: [PATCH v4 2/2] Input: cros-ec-keyb - Expose function row physical map to userspace
Quoting Philip Chen (2021-01-12 15:55:28)
> On Mon, Jan 11, 2021 at 6:24 PM Stephen Boyd wrote:
> >
> > Quoting Philip Chen (2021-01-07 15:42:09)
> > > The top-row keys in a keyboard usually have dual functionalities.
> > > E.g. A function key "F1" is also an action key "Browser back".
> > >
> > > Therefore, when an application receives an action key code from
> > > a top-row key press, the application needs to know how to correlate
> > > the action key code with the function key code and do the conversion
> > > whenever necessary.
> > >
> > > Since the userpace already knows the key scanlines (row/column)
> > > associated with a received key code. Essentially, the userspace only
> > > needs a mapping between the key row/column and the matching physical
> > > location in the top row.
> > >
> > > This patch enhances the cros-ec-keyb driver to create such a mapping
> > > and expose it to userspace in the form of a function-row-physmap
> > > attribute. The attribute would be a space separated ordered list of
> > > row/column codes, for the keys in the function row, in a left-to-right
> > > order.
> > >
> > > The attribute will only be present when the device has a custom design
> > > for the top-row keys.
> >
> > Is it documented in Documentation/ABI/?
> Not yet.
> Is it proper to add the documentation to
> `testing/sysfs-driver-input-keyboard`?
Somewhere in testing is fine. I'm not sure if it is a generic proprty
for all keyboards though? What's the path in sysfs?
> >
> > >
> > > /**
> > > * struct cros_ec_keyb - Structure representing EC keyboard device
> > > *
> > > @@ -42,6 +44,9 @@
> > > * @idev: The input device for the matrix keys.
> > > * @bs_idev: The input device for non-matrix buttons and switches (or
> > > NULL).
> > > * @notifier: interrupt event notifier for transport devices
> > > + * @function_row_physmap: An array of the encoded rows/columns for the
> > > top
> > > + *row function keys, in an order from left to
> > > right
> > > + * @num_function_row_keys: The number of top row keys in a custom
> > > keyboard
> > > */
> > > struct cros_ec_keyb {
> > > unsigned int rows;
> > > @@ -58,6 +63,9 @@ struct cros_ec_keyb {
> > > struct input_dev *idev;
> > > struct input_dev *bs_idev;
> > > struct notifier_block notifier;
> > > +
> > > + u16 function_row_physmap[MAX_NUM_TOP_ROW_KEYS];
> > > + u8 num_function_row_keys;
> >
> > Why not size_t?
> I usually try to use the minimal required bytes for variables, even
> for local ones.
> In this case, we only need one byte for num_function_row_keys.
> Are there any reasons why size_t is better?
I suppose to indicate that it's an array size. It's not a super strong
argument but the usage of u8 looks like we're trying to save space in a
single structure instance (or maybe a couple if there are a few
keyboards), when for all I know it actually generates worse code because
it has to do some masking operation on the load from memory when it
could just load the value directly into a register.
> >
> > > };
> > >
> > > /**
> > > @@ -587,6 +613,52 @@ static int cros_ec_keyb_register_matrix(struct
> > > cros_ec_keyb *ckdev)
> > > return 0;
> > > }
> > >
> > > +static ssize_t function_row_physmap_show(struct device *dev,
> > > +struct device_attribute *attr,
> > > +char *buf)
> > > +{
> > > + ssize_t size = 0;
> > > + u8 i;
> >
> > int i? Why u8? Surely the size of a local variable isn't important.
> The same reason as "u8 num_function_row_keys".
> Is int better in this case?
Yeah int is better because it's a local variable and nobody cares about
those extra few bytes.
> >
> > > + struct cros_ec_keyb *ckdev = dev_get_drvdata(dev);
> > > +
> > > + if (!ckdev->num_function_row_keys)
> > > + return 0;
> > > +
> > > + for (i = 0; i < ckdev->num_function_row_keys; i++)
> > > + size += scnprintf(buf + size, PAGE_SIZE - size, "%02X ",
> > > + ckdev->function_row_physmap[i]);
> > > + size += scnprintf(buf + size, PAGE_SIZE - size, "\n");
> > > +
> > > + return size;
> >
> > I'd rather see
> >
> > ssize_t size = 0;
> > int i;
> > struct cros_ec_keyb *ckdev = dev_get_drvdata(dev);
> > u16 *physmap = ckdev->function_row_physmap;
> >
> > for (i = 0; i < ckdev->num_function_row_keys; i++)
> > size += scnprintf(buf + size, PAGE_SIZE - size,
> > "%s%02X", size ? " " : "", physmap[i]);
> >
> > if (size)
> > size += scnprintf(buf + size, PAGE_SIZE - size, "\n");
> >
> > return size;
> >
> > And I wonder if hex_dump_to_buffer() works for this?
> It seems to work? I'll give it a try.
> If hex_dump_to_buffer() doesn't work, I'll fall back to the
> implementation you suggested above.
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote: > > > > This patch adds decriptions for mt8192 IOMMU and SMI. > > > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor > > > > translation > > > > table format. The M4U-SMI HW diagram is as below: > > > > > > > > EMI > > > >| > > > > M4U > > > >| > > > > > > > >SMI Common > > > > > > > >| > > > > +---+--+--+--+---+ > > > > | | | | .. | | > > > > | | | | | | > > > > larb0 larb1 larb2 larb4 .. larb19 larb20 > > > > disp0 disp1 mdpvdec IPE IPE > > > > > > > > All the connections are HW fixed, SW can NOT adjust it. > > > > > > > > mt8192 M4U support 0~16GB iova range. we preassign different engines > > > > into different iova ranges: > > > > > > > > domain-id module iova-range larbs > > > >0 disp0 ~ 4G larb0/1 > > > >1 vcodec 4G ~ 8G larb4/5/7 > > > >2 cam/mdp 8G ~ 12G > > > > larb2/9/11/13/14/16/17/18/19/20 > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or > > > integrator's decision to split the 16 GB address range into sub-ranges > > > and define which larbs those sub-ranges are shared with? > > > > The problem is that we can't split the 16GB range with the larb as unit. > > The example is the below ccu0(larb13 port9/10) is a independent > > range(domain), the others ports in larb13 is in another domain. > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could > > access any range. vcodec also can locate 8G~12G. it don't care about > > where its iova locate. here I preassign like this following with our > > internal project setting. > > Let me try to understand this a bit more. Given the split you're > proposing, is there actually any isolation enforced between particular > domains? For example, if I program vcodec to with a DMA address from > the 0-4G range, would the IOMMU actually generate a fault, even if > disp had some memory mapped at that address? In this case. we will get fault in current SW setting. > > > > > Why set this in DT?, this is only for simplifying the code. Assume we > > put it in the platform data. We have up to 32 larbs, each larb has up to > > 32 ports, each port may be in different iommu domains. we should have a > > big array for this..however we only use a macro to get the domain in the > > DT method. > > > > When replying this mail, I happen to see there is a "dev->dev_range_map" > > which has "dma-range" information, I think I could use this value to get > > which domain the device belong to. then no need put domid in DT. I will > > test this. > > My feeling is that the only part that needs to be enforced statically > is the reserved IOVA range for CCUs. The other ranges should be > determined dynamically, although I think I need to understand better > how the hardware and your proposed design work to tell what would be > likely the best choice here. I have removed the domid patch in v6. and get the domain id in [27/33] in v6.. About the other ranges should be dynamical, the commit message [30/33] of v6 should be helpful. the problem is that we have a bank_sel setting for the iova[32:33]. currently we preassign this value. thus, all the ranges are fixed. If you adjust this setting, you can let vcodec access 0~4G. Currently we have no interface to adjust this setting. Suppose we add a new interface for this. It would be something like: int mtk_smi_larb_config_banksel(struct device *larb, int banksel) Then, all the MM drivers should call it before the HW works every time, and its implement will be a bit complex since we aren't sure if the larb has power at that time. the important thing is that the MM devices have already not known which larb it connects with as we plan to delete "mediatek,larb" in their dtsi nodes. In current design, the MM device don't need care about it and 4GB range is enough for them. > > Best regards, > Tomasz > > > > > Thanks. > > > > > > Best regards, > > > Tomasz > > > > > > >3 CCU00x4000_ ~ 0x43ff_ larb13: port 9/10 > > > >4 CCU10x4400_ ~ 0x47ff_ larb14: port 4/5 > > > > > > > > The iova range for CCU0/1(camera control unit) is HW requirement. > > > > > > > > Signed-off-by: Yong Wu > > > > Reviewed-by: Rob Herring > > > > --- > > > >
[PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available
SCSI device has max_xfer_size and opt_xfer_size,
but current kernel uses only opt_xfer_size.
It causes the limitation on setting IO chunk size,
although it can support larger one.
So, I propose this patch to use max_xfer_size in case it has valid value.
It can support to use the larger chunk IO on SCSI device.
For example,
This patch is effective in case of some SCSI device like UFS
with opt_xfer_size 512KB, queue depth 32 and max_xfer_size over 512KB.
I expect both the performance improvement
and the efficiency use of smaller command queue depth.
Signed-off-by: Manjong Lee
---
drivers/scsi/sd.c | 56 +++
1 file changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 679c2c025047..de59f01c1304 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3108,6 +3108,53 @@ static void sd_read_security(struct scsi_disk *sdkp,
unsigned char *buffer)
sdkp->security = 1;
}
+static bool sd_validate_max_xfer_size(struct scsi_disk *sdkp,
+ unsigned int dev_max)
+{
+ struct scsi_device *sdp = sdkp->device;
+ unsigned int max_xfer_bytes =
+ logical_to_bytes(sdp, sdkp->max_xfer_blocks);
+
+ if (sdkp->max_xfer_blocks == 0)
+ return false;
+
+ if (sdkp->max_xfer_blocks > SD_MAX_XFER_BLOCKS) {
+ sd_first_printk(KERN_WARNING, sdkp,
+ "Maximal transfer size %u logical blocks " \
+ "> sd driver limit (%u logical blocks)\n",
+ sdkp->max_xfer_blocks, SD_DEF_XFER_BLOCKS);
+ return false;
+ }
+
+ if (sdkp->max_xfer_blocks > dev_max) {
+ sd_first_printk(KERN_WARNING, sdkp,
+ "Maximal transfer size %u logical blocks "
+ "> dev_max (%u logical blocks)\n",
+ sdkp->max_xfer_blocks, dev_max);
+ return false;
+ }
+
+ if (max_xfer_bytes < PAGE_SIZE) {
+ sd_first_printk(KERN_WARNING, sdkp,
+ "Maximal transfer size %u bytes < " \
+ "PAGE_SIZE (%u bytes)\n",
+ max_xfer_bytes, (unsigned int)PAGE_SIZE);
+ return false;
+ }
+
+ if (max_xfer_bytes & (sdkp->physical_block_size - 1)) {
+ sd_first_printk(KERN_WARNING, sdkp,
+ "Maximal transfer size %u bytes not a " \
+ "multiple of physical block size (%u bytes)\n",
+ max_xfer_bytes, sdkp->physical_block_size);
+ return false;
+ }
+
+ sd_first_printk(KERN_INFO, sdkp, "Maximal transfer size %u bytes\n",
+ max_xfer_bytes);
+ return true;
+}
+
/*
* Determine the device's preferred I/O size for reads and writes
* unless the reported value is unreasonably small, large, not a
@@ -3233,12 +3280,13 @@ static int sd_revalidate_disk(struct gendisk *disk)
/* Initial block count limit based on CDB TRANSFER LENGTH field size. */
dev_max = sdp->use_16_for_rw ? SD_MAX_XFER_BLOCKS : SD_DEF_XFER_BLOCKS;
-
- /* Some devices report a maximum block count for READ/WRITE requests. */
- dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks);
q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
- if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
+ if (sd_validate_max_xfer_size(sdkp, dev_max)) {
+ q->limits.io_opt = 0;
+ rw_max = logical_to_sectors(sdp, sdkp->max_xfer_blocks);
+ q->limits.max_dev_sectors = rw_max;
+ } else if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks);
} else {
--
2.29.0
[PATCH] drivers: add new VID/PID for supporting Teraoka AD2000
Best Regards, Jin Chen-Xin Software Development Dept. Shanghai Teraoka Electronic Co., Ltd. * The information contained in this message is intended for the use of the individuals to whom it is addressed and may contain information that is privileged and confidential. If you have received this email by mistake, please discard this email immediately. Do not disclose, forward or copy. * 信息安全声明：本邮件(包括其任何附件）的信息，仅用于邮件列出的接收者使用，并且可能包含有特许和机密的信息。如果您误收到这封电子邮件，请通知发件人，并立即删除它，请勿透露、转发或复制。 0001-drivers-add-new-VID-PID-for-supporting-Teraoka-AD200.patch Description: 0001-drivers-add-new-VID-PID-for-supporting-Teraoka-AD200.patch
[PATCH for 5.10] powerpc/32s: Fix RTAS machine check with VMAP stack
This is backport for 5.10
(cherry picked from commit 98bf2d3f4970179c702ef64db658e0553bc6ef3a)
When we have VMAP stack, exception prolog 1 sets r1, not r11.
When it is not an RTAS machine check, don't trash r1 because it is
needed by prolog 1.
Fixes: da7bb43ab9da ("powerpc/32: Fix vmap stack - Properly set r1 before
activating MMU")
Cc: sta...@vger.kernel.org # v5.10+
Signed-off-by: Christophe Leroy
[mpe: Squash in fixup for RTAS machine check from Christophe]
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/bc77d61d1c18940e456a2dee464f1e2eda65a3f0.1608621048.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/head_book3s_32.S | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/head_book3s_32.S
b/arch/powerpc/kernel/head_book3s_32.S
index a0dda2a1f2df..d66da35f2e8d 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -262,10 +262,19 @@ __secondary_hold_acknowledge:
MachineCheck:
EXCEPTION_PROLOG_0
#ifdef CONFIG_PPC_CHRP
+#ifdef CONFIG_VMAP_STACK
+ mr r11, r1
+ mfspr r1, SPRN_SPRG_THREAD
+ lwz r1, RTAS_SP(r1)
+ cmpwi cr1, r1, 0
+ bne cr1, 7f
+ mr r1, r11
+#else
mfspr r11, SPRN_SPRG_THREAD
lwz r11, RTAS_SP(r11)
cmpwi cr1, r11, 0
bne cr1, 7f
+#endif
#endif /* CONFIG_PPC_CHRP */
EXCEPTION_PROLOG_1 for_rtas=1
7: EXCEPTION_PROLOG_2
--
2.25.0
[PATCH] cgroup: Remove stale comments
The function "cgroup_mount" had beed removed, remove related comments to prevent confusion. Related commit:90129625d9203a917f(cgroup: start switching to fs_context) Signed-off-by: Li Feng --- kernel/cgroup/cgroup.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 613845769103..493547b4941c 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -2139,7 +2139,6 @@ static void cgroup_kill_sb(struct super_block *sb) /* * If @root doesn't have any children, start killing it. * This prevents new mounts by disabling percpu_ref_tryget_live(). -* cgroup_mount() may wait for @root's release. * * And don't kill the default root. */ -- 2.25.1
RE: [PATCH v2 2/2] ASoC: rt715:add Mic Mute LED control support
> -Original Message-
> From: Pierre-Louis Bossart
> Sent: 2021年1月13日 10:42
> To: Yuan, Perry; Limonciello, Mario; oder_ch...@realtek.com;
> pe...@perex.cz; ti...@suse.com
> Cc: alsa-de...@alsa-project.org; broo...@kernel.org; lgirdw...@gmail.com;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/2] ASoC: rt715:add Mic Mute LED control support
>
>
> [EXTERNAL EMAIL]
>
>
> > +#if IS_ENABLED(CONFIG_DELL_PRIVACY)
> > + /* Privacy LED Trigger State Changed by muted/unmute switch */
> > + if (mc->invert) {
> > + val0 = ucontrol->value.integer.value[0];
> > + val1 = ucontrol->value.integer.value[1];
> > + if (val0 == 1 && val1 == 1) {
> > + rt715->micmute_led = LED_OFF;
> > + ledtrig_audio_set(LED_AUDIO_MICMUTE,
> > + rt715->micmute_led ? LED_ON :
> LED_OFF);
> > + } else if (val0 == 0 && val1 == 0) {
> > + rt715->micmute_led = LED_ON;
> > + ledtrig_audio_set(LED_AUDIO_MICMUTE,
> > + rt715->micmute_led ? LED_ON :
> LED_OFF);
> > + }
> > + }
> > +#endif
>
> Should this be activated for specific DMI quirks? This driver is
> used in
> >>> non-Dell
> platforms (I am thinking of Intel RVPs or Realtek daughterboards),
> I am not sure if a build-time behavior change makes sense.
>
> Or conversely could we just set the LEDs unconditionally if doing
> so is harmless?
> >>>
> >>> The current mic mute led setting path is not common used for other
> >>> vendors, just Dell platform support this mic mute led set operation.
> >>>
> >>> Do you think that I need to add one DMI quirk in the next version ?
> >>> If so, I can add that.
> >>>
> >>>
> >>
> >>
> >> In the HDA audio case this is modeled off of, the code runs whether
> >> or not a vendor has support for a mic mute LED. The calls to
> >> ledtrig_audio_set should be a no-op. I agree with @Pierre-Louis
> >> Bossart in this case, we should just be running it whether or not
> >> dell-privacy is compiled in. If another vendor chooses to add LED
> >> support they'll just need to set up their ledtrig supported backend and not
> change codec code.
> >
> > Hi @Pierre-Louis Bossart
> > Seems like that we have two way to go.
> > * DMI quirks,seems like that it needs to maintain the quirk list when
> > vendors
> have new system to support.
> > * We just set the mic mute led state unconditionally .
> >
> > Which way would you prefer for next patch review?
>
> Maintaining quirks is a hassle, it's much simpler and consistent with HDaudio
> if the leds are set unconditionally. Thanks!
Thank you for your confirm.
I will take this to next patch V4.
Perry Yuan
Dell | Client Software Group | CDC Linux OS
[PATCH v3 2/2] arm64: dts: mt8183: Add krane-sku0 board.
Similar to krane-sku176 but using a different panel source.
Signed-off-by: Hsin-Yi Wang
---
change:
v3: fix yaml
---
.../devicetree/bindings/arm/mediatek.yaml | 4 +++-
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../dts/mediatek/mt8183-kukui-krane-sku0.dts | 23 +++
3 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 53f0d4e3ea982..93b3bdf6eaeb7 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -120,7 +120,9 @@ properties:
- const: mediatek,mt8183
- description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
items:
- - const: google,krane-sku176
+ - enum:
+ - google,krane-sku0
+ - google,krane-sku176
- const: google,krane
- const: mediatek,mt8183
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 18f7b46c4095b..deba27ab76574 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
new file mode 100644
index 0..fb5ee91b6fe0e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2019 Google LLC
+ *
+ * Device-tree for Krane sku0.
+ *
+ * SKU is a 8-bit value (0x00 == 0):
+ * - Bits 7..4: Panel ID: 0x0 (AUO)
+ * - Bits 3..0: SKU ID: 0x0 (default)
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-krane.dtsi"
+
+/ {
+ model = "MediaTek krane sku0 board";
+ compatible = "google,krane-sku0", "google,krane", "mediatek,mt8183";
+};
+
+ {
+ status = "okay";
+ compatible = "auo,kd101n80-45na";
+};
--
2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v3 1/2] arm64: dts: mt8183: config dsi node
Config dsi node for mt8183 kukui. Set panel and ports.
Several kukui boards share the same panel property and only compatible
is different. So compatible will be set in board dts for comparison
convenience.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Nicolas Boichat
---
.../mediatek/mt8183-kukui-krane-sku176.dts| 5 +++
.../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 37 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
index 47113e275cb52..721d16f9c3b4f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
@@ -16,3 +16,8 @@ / {
model = "MediaTek krane sku176 board";
compatible = "google,krane-sku176", "google,krane", "mediatek,mt8183";
};
+
+ {
+status = "okay";
+compatible = "boe,tv101wum-nl6";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index bf2ad1294dd30..c5f41b94f154e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -249,6 +249,35 @@ {
proc-supply = <_vproc11_reg>;
};
+ {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel: panel@0 {
+ /* compatible will be set in board dts */
+ reg = <0>;
+ enable-gpios = < 45 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+ avdd-supply = <_lcd>;
+ avee-supply = <_lcd>;
+ pp1800-supply = <_lcd>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ ports {
+ port {
+ dsi_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -547,6 +576,14 @@ pins_clk {
};
};
+ panel_pins_default: panel_pins_default {
+ panel_reset {
+ pinmux = ;
+ output-low;
+ bias-pull-up;
+ };
+ };
+
pwm0_pin_default: pwm0_pin_default {
pins1 {
pinmux = ;
--
2.30.0.284.gd98b1dd5eaa7-goog
Re: [PATCH v3 4/4] dma-buf: heaps: add chunk heap to dmabuf heaps
Hi Minchan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210112]
[cannot apply to s390/features robh/for-next linux/master linus/master
hnaz-linux-mm/master v5.11-rc3 v5.11-rc2 v5.11-rc1 v5.11-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Minchan-Kim/Chunk-Heap-Support-on-DMA-HEAP/20210113-092747
base:df869cab4b3519d603806234861aa0a39df479c0
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/531ebc21d3c2584784d44714e3b4f1df46b80eee
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Minchan-Kim/Chunk-Heap-Support-on-DMA-HEAP/20210113-092747
git checkout 531ebc21d3c2584784d44714e3b4f1df46b80eee
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/dma-buf/heaps/chunk_heap.c: In function 'chunk_heap_do_vmap':
>> drivers/dma-buf/heaps/chunk_heap.c:215:24: error: implicit declaration of
>> function 'vmalloc'; did you mean 'kvmalloc'?
>> [-Werror=implicit-function-declaration]
215 | struct page **pages = vmalloc(sizeof(struct page *) * npages);
|^~~
|kvmalloc
drivers/dma-buf/heaps/chunk_heap.c:215:24: warning: initialization of
'struct page **' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
>> drivers/dma-buf/heaps/chunk_heap.c:228:10: error: implicit declaration of
>> function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration]
228 | vaddr = vmap(pages, npages, VM_MAP, PAGE_KERNEL);
| ^~~~
| kmap
>> drivers/dma-buf/heaps/chunk_heap.c:228:30: error: 'VM_MAP' undeclared (first
>> use in this function); did you mean 'VM_MTE'?
228 | vaddr = vmap(pages, npages, VM_MAP, PAGE_KERNEL);
| ^~
| VM_MTE
drivers/dma-buf/heaps/chunk_heap.c:228:30: note: each undeclared identifier
is reported only once for each function it appears in
>> drivers/dma-buf/heaps/chunk_heap.c:229:2: error: implicit declaration of
>> function 'vfree'; did you mean 'kvfree'?
>> [-Werror=implicit-function-declaration]
229 | vfree(pages);
| ^
| kvfree
drivers/dma-buf/heaps/chunk_heap.c: In function 'chunk_heap_vunmap':
>> drivers/dma-buf/heaps/chunk_heap.c:268:3: error: implicit declaration of
>> function 'vunmap'; did you mean 'kunmap'?
>> [-Werror=implicit-function-declaration]
268 | vunmap(buffer->vaddr);
| ^~
| kunmap
cc1: some warnings being treated as errors
vim +215 drivers/dma-buf/heaps/chunk_heap.c
210
211 static void *chunk_heap_do_vmap(struct chunk_heap_buffer *buffer)
212 {
213 struct sg_table *table = >sg_table;
214 int npages = PAGE_ALIGN(buffer->len) / PAGE_SIZE;
> 215 struct page **pages = vmalloc(sizeof(struct page *) * npages);
216 struct page **tmp = pages;
217 struct sg_page_iter piter;
218 void *vaddr;
219
220 if (!pages)
221 return ERR_PTR(-ENOMEM);
222
223 for_each_sgtable_page(table, , 0) {
224 WARN_ON(tmp - pages >= npages);
225 *tmp++ = sg_page_iter_page();
226 }
227
> 228 vaddr = vmap(pages, npages, VM_MAP, PAGE_KERNEL);
> 229 vfree(pages);
230
231 if (!vaddr)
232 return ERR_PTR(-ENOMEM);
233
234 return vaddr;
235 }
236
237 static int chunk_heap_vmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
238 {
239 struct chunk_heap_buffer *buffer = dmabuf->priv;
240 void *vaddr;
241
242 mutex_lock(>lock);
243 if (buffer->vmap_cnt) {
244 vaddr = buffer->vaddr;
245 } else {
246 vaddr = chunk_heap_do_vmap(buffer);
247 if (IS_ERR(vaddr)) {
248 mutex_unlock(>lock);
249
250 return PTR_ERR(vaddr);
251 }
252
[PATH v2] scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach
We get follow BUG_ON when rdac scan:
[595952.944297] kernel BUG at drivers/scsi/device_handler/scsi_dh_rdac.c:427!
[595952.951143] Internal error: Oops - BUG: 0 [#1] SMP
..
[595953.251065] Call trace:
[595953.259054] check_ownership+0xb0/0x118
[595953.269794] rdac_bus_attach+0x1f0/0x4b0
[595953.273787] scsi_dh_handler_attach+0x3c/0xe8
[595953.278211] scsi_dh_add_device+0xc4/0xe8
[595953.282291] scsi_sysfs_add_sdev+0x8c/0x2a8
[595953.286544] scsi_probe_and_add_lun+0x9fc/0xd00
[595953.291142] __scsi_scan_target+0x598/0x630
[595953.295395] scsi_scan_target+0x120/0x130
[595953.299481] fc_user_scan+0x1a0/0x1c0 [scsi_transport_fc]
[595953.304944] store_scan+0xb0/0x108
[595953.308420] dev_attr_store+0x44/0x60
[595953.312160] sysfs_kf_write+0x58/0x80
[595953.315893] kernfs_fop_write+0xe8/0x1f0
[595953.319888] __vfs_write+0x60/0x190
[595953.323448] vfs_write+0xac/0x1c0
[595953.326836] ksys_write+0x74/0xf0
[595953.330221] __arm64_sys_write+0x24/0x30
BUG_ON code is in check_ownership:
list_for_each_entry_rcu(tmp, >ctlr->dh_list, node) {
/* h->sdev should always be valid */
BUG_ON(!tmp->sdev);
tmp->sdev->access_state = access_state;
}
rdac_bus_attach
initialize_controller
list_add_rcu(>node, >ctlr->dh_list);
h->sdev = sdev;
rdac_bus_detach
list_del_rcu(>node);
h->sdev = NULL;
Test as follow steps:
(1) Find IO error, remove disk;
(2) Insert disk back;
(3) trigger scan disk;
There is race between rdac_bus_attach and rdac_bus_detach, maybe access
rdac_dh_data which h->sdev has been set NULL when process rdac attach. And also
find that "h->sdev" set value after add list, this may lead to reference NULL
ptr.
Signed-off-by: Ye Bin
---
drivers/scsi/device_handler/scsi_dh_rdac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_rdac.c
b/drivers/scsi/device_handler/scsi_dh_rdac.c
index 5efc959493ec..85a71bafaea7 100644
--- a/drivers/scsi/device_handler/scsi_dh_rdac.c
+++ b/drivers/scsi/device_handler/scsi_dh_rdac.c
@@ -453,8 +453,8 @@ static int initialize_controller(struct scsi_device *sdev,
if (!h->ctlr)
err = SCSI_DH_RES_TEMP_UNAVAIL;
else {
- list_add_rcu(>node, >ctlr->dh_list);
h->sdev = sdev;
+ list_add_rcu(>node, >ctlr->dh_list);
}
spin_unlock(_lock);
err = SCSI_DH_OK;
@@ -778,11 +778,11 @@ static void rdac_bus_detach( struct scsi_device *sdev )
spin_lock(_lock);
if (h->ctlr) {
list_del_rcu(>node);
- h->sdev = NULL;
kref_put(>ctlr->kref, release_controller);
}
spin_unlock(_lock);
sdev->handler_data = NULL;
+ synchronize_rcu();
kfree(h);
}
--
2.25.4
Re: [PATCH v2 2/2] arm64: dts: mt8183: Add krane-sku0 board.
On Wed, Jan 13, 2021 at 11:20 AM Rob Herring wrote: > > On Thu, Jan 07, 2021 at 01:22:06PM +0800, Hsin-Yi Wang wrote: > > Similar to krane-sku176 but using a different panel source. > > > > Signed-off-by: Hsin-Yi Wang > > --- > > Change: > > v2: move compatible to board dts > > --- > > .../devicetree/bindings/arm/mediatek.yaml | 1 + > > arch/arm64/boot/dts/mediatek/Makefile | 1 + > > .../dts/mediatek/mt8183-kukui-krane-sku0.dts | 23 +++ > > 3 files changed, 25 insertions(+) > > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts > > > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > > b/Documentation/devicetree/bindings/arm/mediatek.yaml > > index 53f0d4e3ea982..3276f7a2ce672 100644 > > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > > @@ -120,6 +120,7 @@ properties: > >- const: mediatek,mt8183 > >- description: Google Krane (Lenovo IdeaPad Duet, 10e,...) > > items: > > + - const: google,krane-sku0 > >- const: google,krane-sku176 > >- const: google,krane > >- const: mediatek,mt8183 > > This says you must have all 4 compatible strings in the order listed. > That doesn't match your dts. I assume you want the first 2 under an > 'enum' so there's 3 strings with the first one being sku0 or sku176? > Right. I'll fix in the next version. Thanks > Rob
[PATCH v4] pgo: add clang's Profile Guided Optimization infrastructure
From: Sami Tolvanen Enable the use of clang's Profile-Guided Optimization[1]. To generate a profile, the kernel is instrumented with PGO counters, a representative workload is run, and the raw profile data is collected from /sys/kernel/debug/pgo/profraw. The raw profile data must be processed by clang's "llvm-profdata" tool before it can be used during recompilation: $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw Multiple raw profiles may be merged during this step. The data can now be used by the compiler: $ make LLVM=1 KCFLAGS=-fprofile-use=vmlinux.profdata ... This initial submission is restricted to x86, as that's the platform we know works. This restriction can be lifted once other platforms have been verified to work with PGO. Note that this method of profiling the kernel is clang-native, unlike the clang support in kernel/gcov. [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization Signed-off-by: Sami Tolvanen Co-developed-by: Bill Wendling Signed-off-by: Bill Wendling Change-Id: Ic78e69c682286d3a44c4549a0138578c98138b77 --- v2: - Added "__llvm_profile_instrument_memop" based on Nathan Chancellor's testing. - Corrected documentation, re PGO flags when using LTO, based on Fangrui Song's comments. v3: - Added change log section based on Sedat Dilek's comments. v4: - Remove non-x86 Makfile changes and se "hweight64" instead of using our own popcount implementation, based on Nick Desaulniers's comment. --- Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/pgo.rst | 127 + MAINTAINERS | 9 + Makefile | 3 + arch/Kconfig | 1 + arch/x86/Kconfig | 1 + arch/x86/boot/Makefile| 1 + arch/x86/boot/compressed/Makefile | 1 + arch/x86/entry/vdso/Makefile | 1 + arch/x86/kernel/vmlinux.lds.S | 2 + arch/x86/platform/efi/Makefile| 1 + arch/x86/purgatory/Makefile | 1 + arch/x86/realmode/rm/Makefile | 1 + arch/x86/um/vdso/Makefile | 1 + drivers/firmware/efi/libstub/Makefile | 1 + include/asm-generic/vmlinux.lds.h | 44 +++ kernel/Makefile | 1 + kernel/pgo/Kconfig| 34 +++ kernel/pgo/Makefile | 5 + kernel/pgo/fs.c | 382 ++ kernel/pgo/instrument.c | 185 + kernel/pgo/pgo.h | 206 ++ scripts/Makefile.lib | 10 + 23 files changed, 1019 insertions(+) create mode 100644 Documentation/dev-tools/pgo.rst create mode 100644 kernel/pgo/Kconfig create mode 100644 kernel/pgo/Makefile create mode 100644 kernel/pgo/fs.c create mode 100644 kernel/pgo/instrument.c create mode 100644 kernel/pgo/pgo.h diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index f7809c7b1ba9e..8d6418e858062 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -26,6 +26,7 @@ whole; patches welcome! kgdb kselftest kunit/index + pgo .. only:: subproject and html diff --git a/Documentation/dev-tools/pgo.rst b/Documentation/dev-tools/pgo.rst new file mode 100644 index 0..b7f11d8405b73 --- /dev/null +++ b/Documentation/dev-tools/pgo.rst @@ -0,0 +1,127 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Using PGO with the Linux kernel +=== + +Clang's profiling kernel support (PGO_) enables profiling of the Linux kernel +when building with Clang. The profiling data is exported via the ``pgo`` +debugfs directory. + +.. _PGO: https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization + + +Preparation +=== + +Configure the kernel with: + +.. code-block:: make + + CONFIG_DEBUG_FS=y + CONFIG_PGO_CLANG=y + +Note that kernels compiled with profiling flags will be significantly larger +and run slower. + +Profiling data will only become accessible once debugfs has been mounted: + +.. code-block:: sh + + mount -t debugfs none /sys/kernel/debug + + +Customization += + +You can enable or disable profiling for individual file and directories by +adding a line similar to the following to the respective kernel Makefile: + +- For a single file (e.g. main.o) + + .. code-block:: make + + PGO_PROFILE_main.o := y + +- For all files in one directory + + .. code-block:: make + + PGO_PROFILE := y + +To exclude files from being profiled use + + .. code-block:: make + + PGO_PROFILE_main.o := n + +and + + .. code-block:: make + + PGO_PROFILE := n + +Only files which are linked to the main kernel image or are compiled as kernel +modules are supported by this mechanism. + + +Files += + +The PGO kernel
Re: [PATCH v5 1/3] usb: typec: tcpm: AMS and Collision Avoidance
Hi Kyle,
Do you want to handle the FAST_ROLE_SWAP case as well ?
You would have to fix up in two places:
#1
- if (port->state == SNK_READY)
- tcpm_set_state(port, FR_SWAP_SEND, 0);
- else
+ if (port->state == SNK_READY) {
+ int ret;
+
+ port->upcoming_state = FR_SWAP_SEND;
+ ret = tcpm_ams_start(port, FAST_ROLE_SWAP);
+ if (ret == -EAGAIN)
+ port->upcoming_state = INVALID_STATE;
+ } else {
tcpm_log(port, "Discarding FRS_SIGNAL!
Not in sink ready");
+ }
#2
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -4449,9 +4449,14 @@ static void tcpm_enable_frs_work(struct
kthread_work *work)
if (port->state != SNK_READY || port->vdm_state !=
VDM_STATE_DONE || port->send_discover)
goto resched;
- tcpm_set_state(port, GET_SINK_CAP, 0);
- port->sink_cap_done = true;
-
+ port->upcoming_state = GET_SINK_CAP;
+ ret = tcpm_ams_start(port, GET_SINK_CAPABILITIES);
+ if (ret == -EAGAIN) {
+ port->upcoming_state = INVALID_STATE;
+ } else {
+ port->sink_cap_done = true;
+ goto unlock;
+ }
Thanks,
Badhri
On Tue, Jan 12, 2021 at 5:29 AM Heikki Krogerus
wrote:
>
> On Wed, Jan 06, 2021 at 12:39:25AM +0800, Kyle Tso wrote:
> > This patch provides the implementation of Collision Avoidance introduced
> > in PD3.0. The start of each Atomic Message Sequence (AMS) initiated by
> > the port will be denied if the current AMS is not interruptible. The
> > Source port will set the CC to SinkTxNG if it is going to initiate an
> > AMS, and SinkTxOk otherwise. Meanwhile, any AMS initiated by a Sink port
> > will be denied in TCPM if the port partner (Source) sets SinkTxNG except
> > for HARD_RESET and SOFT_RESET.
> >
> > Signed-off-by: Kyle Tso
> > Signed-off-by: Will McVicker
>
> So did you and Will develop this patch together?
>
> Few nitpicks below.
>
> > ---
> > Changelog since v4:
> > - rebased to ToT
> >
> > drivers/usb/typec/tcpm/tcpm.c | 533 ++
> > include/linux/usb/pd.h| 1 +
> > include/linux/usb/tcpm.h | 4 +
> > 3 files changed, 479 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> > index 22a85b396f69..9fb3ec176f42 100644
> > --- a/drivers/usb/typec/tcpm/tcpm.c
> > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > @@ -76,6 +76,8 @@
> > S(SNK_HARD_RESET_SINK_ON), \
> > \
> > S(SOFT_RESET), \
> > + S(SRC_SOFT_RESET_WAIT_SNK_TX), \
> > + S(SNK_SOFT_RESET), \
> > S(SOFT_RESET_SEND), \
> > \
> > S(DR_SWAP_ACCEPT), \
> > @@ -139,7 +141,45 @@
> > \
> > S(ERROR_RECOVERY), \
> > S(PORT_RESET), \
> > - S(PORT_RESET_WAIT_OFF)
> > + S(PORT_RESET_WAIT_OFF), \
> > + \
> > + S(AMS_START)
> > +
> > +#define FOREACH_AMS(S) \
> > + S(NONE_AMS),\
> > + S(POWER_NEGOTIATION), \
> > + S(GOTOMIN), \
> > + S(SOFT_RESET_AMS), \
> > + S(HARD_RESET), \
> > + S(CABLE_RESET), \
> > + S(GET_SOURCE_CAPABILITIES), \
> > + S(GET_SINK_CAPABILITIES), \
> > + S(POWER_ROLE_SWAP), \
> > + S(FAST_ROLE_SWAP), \
> > + S(DATA_ROLE_SWAP), \
> > + S(VCONN_SWAP), \
> > + S(SOURCE_ALERT),\
> > + S(GETTING_SOURCE_EXTENDED_CAPABILITIES),\
> > + S(GETTING_SOURCE_SINK_STATUS), \
> > + S(GETTING_BATTERY_CAPABILITIES),\
> > + S(GETTING_BATTERY_STATUS), \
> > + S(GETTING_MANUFACTURER_INFORMATION),\
> > + S(SECURITY),\
> > + S(FIRMWARE_UPDATE), \
> > + S(DISCOVER_IDENTITY), \
> > + S(SOURCE_STARTUP_CABLE_PLUG_DISCOVER_IDENTITY), \
> > + S(DISCOVER_SVIDS), \
> > + S(DISCOVER_MODES), \
> > + S(DFP_TO_UFP_ENTER_MODE), \
> > + S(DFP_TO_UFP_EXIT_MODE),\
> > + S(DFP_TO_CABLE_PLUG_ENTER_MODE),\
> > +
[PATCH v10 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling for devfreq, for 2 reasons:
1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
does not support multiple regulators, so we'll need custom
handlers.
2. Generally, platforms with 2 regulators have platform-specific
constraints on how the voltages should be set (e.g.
minimum/maximum voltage difference between them), so we
should not just create generic handlers that simply
change the voltages without taking care of those constraints.
Disable devfreq for now on those GPUs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
---
(no changes since v9)
Changes in v9:
- Explain why devfreq needs to be disabled for GPUs with >1
regulators.
Changes in v8:
- Use DRM_DEV_INFO instead of ERROR
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- New change
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index f44d28fad085..812cfecdee3b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -92,6 +92,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
+ if (pfdev->comp->num_supplies > 1) {
+ /*
+* GPUs with more than 1 supply require platform-specific
handling:
+* continue without devfreq
+*/
+ DRM_DEV_INFO(dev, "More than 1 supply is not supported yet\n");
+ return 0;
+ }
+
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
pfdev->comp->num_supplies);
if (IS_ERR(opp_table)) {
--
2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v10 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat --- Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v6: - Rebased, actually tested with recent mesa driver. - No change Changes in v5: - Rename "2d" power domain to "core2" Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) Changes in v3: - No change .../bindings/gpu/arm,mali-bifrost.yaml| 28 +++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 184492162e7e..eac561582063 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -41,6 +42,8 @@ properties: mali-supply: true + sram-supply: true + operating-points-v2: true power-domains: @@ -87,6 +90,31 @@ allOf: then: required: - resets + - if: + properties: +compatible: + contains: +const: mediatek,mt8183-mali +then: + properties: +power-domains: + description: +List of phandle and PM domain specifier as documented in +Documentation/devicetree/bindings/power/power_domain.txt + minItems: 3 + maxItems: 3 +power-domain-names: + items: +- const: core0 +- const: core1 +- const: core2 + required: +- sram-supply +- power-domains +- power-domains-names +else: + properties: +sram-supply: false examples: - | -- 2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v10 4/4] drm/panfrost: Add mt8183-mali compatible string
Add support for MT8183's G72 Bifrost.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
---
(no changes since v7)
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- Context conflicts, reflow the code.
- Use ARRAY_SIZE for power domains too.
Changes in v5:
- Change power domain name from 2d to core2.
Changes in v4:
- Add power domain names.
Changes in v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.
drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..ca07098a6141 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
.vendor_quirk = panfrost_gpu_amlogic_quirk,
};
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2"
};
+static const struct panfrost_compatible mediatek_mt8183_data = {
+ .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+ .supply_names = mediatek_mt8183_supplies,
+ .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
+ .pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
static const struct of_device_id dt_match[] = {
/* Set first to probe before the generic compatibles */
{ .compatible = "amlogic,meson-gxm-mali",
@@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = _data, },
{ .compatible = "arm,mali-t880", .data = _data, },
{ .compatible = "arm,mali-bifrost", .data = _data, },
+ { .compatible = "mediatek,mt8183-mali", .data = _mt8183_data },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v10 0/4] drm/panfrost: Add support for mt8183 GPU
Hi! Follow-up on the v5 [1], things have gotten significantly better in the last 9 months, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ [2] https://crrev.com/c/2608070 Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml| 28 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 6 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 6 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 6 files changed, 164 insertions(+) -- 2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v10 2/4] arm64: dts: mt8183: Add node for the Mali GPU
Add a basic GPU node for mt8183.
Signed-off-by: Nicolas Boichat
---
The binding we use with out-of-tree Mali drivers includes more
clocks, this is used for devfreq: the out-of-tree driver switches
clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
switches clk_mux back to clk_main_parent:
(see
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
clocks =
< CLK_TOP_MFGPLL_CK>,
< CLK_TOP_MUX_MFG>,
<>,
< CLK_MFG_BG3D>;
clock-names =
"clk_main_parent",
"clk_mux",
"clk_sub_parent",
"subsys_mfg_cg";
(based on discussions, this probably belongs in the clock core)
This only matters for devfreq, that is disabled anyway as we don't
have platform-specific code to handle >1 supplies.
(no changes since v6)
Changes in v6:
- Add gpu regulators to kukui dtsi as well.
- Power domains are now attached to spm, not scpsys
- Drop R-B.
Changes in v5:
- Rename "2d" power domain to "core2" (keep R-B again).
Changes in v4:
- Add power-domain-names to describe the 3 domains.
(kept Alyssa's reviewed-by as the change is minor)
Changes in v3:
- No changes
Changes in v2:
- Use sram instead of mali_sram as SRAM supply name.
- Rename mali@ to gpu@.
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 6 +
.../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 6 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++
3 files changed, 117 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index cba2d8933e79..0a8c2fad8e16 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -42,6 +42,12 @@ {
status = "okay";
};
+ {
+ supply-names = "mali", "sram";
+ mali-supply = <_vgpu_reg>;
+ sram-supply = <_vsram_gpu_reg>;
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index bf2ad1294dd3..00d8e112cab9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -249,6 +249,12 @@ {
proc-supply = <_vproc11_reg>;
};
+ {
+ supply-names = "mali", "sram";
+ mali-supply = <_vgpu_reg>;
+ sram-supply = <_vsram_gpu_reg>;
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5b782a4769e7..5430e05e18a0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -964,6 +964,111 @@ mfgcfg: syscon@1300 {
#clock-cells = <1>;
};
+ gpu: gpu@1304 {
+ compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
+ reg = <0 0x1304 0 0x4000>;
+ interrupts =
+ ,
+ ,
+ ;
+ interrupt-names = "job", "mmu", "gpu";
+
+ clocks = < CLK_TOP_MFGPLL_CK>;
+
+ power-domains =
+ < MT8183_POWER_DOMAIN_MFG_CORE0>,
+ < MT8183_POWER_DOMAIN_MFG_CORE1>,
+ < MT8183_POWER_DOMAIN_MFG_2D>;
+ power-domain-names = "core0", "core1", "core2";
+
+ operating-points-v2 = <_opp_table>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <625000>, <85>;
+ };
+
+ opp-32000 {
+ opp-hz = /bits/ 64 <32000>;
+ opp-microvolt = <631250>, <85>;
+ };
+
+ opp-34000 {
+ opp-hz = /bits/ 64 <34000>;
+ opp-microvolt = <637500>, <85>;
+ };
+
+ opp-36000 {
+ opp-hz = /bits/ 64 <36000>;
+ opp-microvolt = <643750>, <85>;
+ };
+
+ opp-38000 {
+ opp-hz = /bits/ 64 <38000>;
+ opp-microvolt = <65>, <85>;
+ };
+
+ opp-4 {
+ opp-hz = /bits/ 64 <4>;
+
[PATCH v2 7/7] arm64: dts: allwinner: pinephone: Set audio card name
From: Arnaud Ferraris
Add the "PinePhone" name to the sound card: this will make
upstreaming an ALSA UCM config easier as we can use a unique name.
It also avoids an issue where the default card name is truncated.
Signed-off-by: Arnaud Ferraris
[Samuel: Split out change, updated commit message]
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index e0db2f1373bc..cf6dcdd135b5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -425,6 +425,7 @@ _rtc_ldo {
{
status = "okay";
+ simple-audio-card,name = "PinePhone";
simple-audio-card,aux-devs = <_analog>, <_amp>;
simple-audio-card,widgets = "Microphone", "Headset Microphone",
"Microphone", "Internal Microphone",
--
2.26.2
[PATCH v2 6/7] arm64: dts: allwinner: pinephone: Add support for Bluetooth audio
The PinePhone has a Bluetooth chip with its PCM interface connected to
AIF3. Add the DAI link so headeset audio can be routed in hardware.
Even though the link is 16 bit PCM, configuring the link a 32-bit slot
is required for compatibility with AIF2, which also uses a 32-bit slot,
and which shares clock dividers with AIF3. Using equal clock frequencies
allows the modem and headset to be used at the same time.
Signed-off-by: Samuel Holland
---
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 2dfe9bae8c67..e0db2f1373bc 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -24,6 +24,11 @@ backlight: backlight {
/* Backlight configuration differs per PinePhone revision. */
};
+ bt_sco_codec: bt-sco-codec {
+ #sound-dai-cells = <1>;
+ compatible = "linux,bt-sco";
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -82,6 +87,8 @@ vibrator {
};
{
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
status = "okay";
};
@@ -439,6 +446,23 @@ {
"MIC1", "Internal Microphone",
"Headset Microphone", "HBIAS",
"MIC2", "Headset Microphone";
+
+ simple-audio-card,dai-link@2 {
+ format = "dsp_a";
+ frame-master = <_codec>;
+ bitclock-master = <_codec>;
+ bitclock-inversion;
+
+ link2_cpu: cpu {
+ sound-dai = <_sco_codec 0>;
+ };
+
+ link2_codec: codec {
+ sound-dai = < 2>;
+ dai-tdm-slot-num = <1>;
+ dai-tdm-slot-width = <32>;
+ };
+ };
};
{
--
2.26.2
[PATCH v2 5/7] arm64: dts: allwinner: a64: Allow multiple DAI links
simple-audio-card supports either a single DAI link at the top level, or
subnodes with one or more DAI links. To use the secondary AIFs on the
codec, we need to add additional DAI links to the same sound card, so we
need to use the other binding.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 4bba468d8ec2..fd9a278f014a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -131,12 +131,10 @@ psci {
};
sound: sound {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "simple-audio-card";
simple-audio-card,name = "sun50i-a64-audio";
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <>;
- simple-audio-card,bitclock-master = <>;
- simple-audio-card,mclk-fs = <128>;
simple-audio-card,aux-devs = <_analog>;
simple-audio-card,routing =
"Left DAC", "DACL",
@@ -145,12 +143,19 @@ sound: sound {
"ADCR", "Right ADC";
status = "disabled";
- cpudai: simple-audio-card,cpu {
- sound-dai = <>;
- };
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+ frame-master = <_cpu>;
+ bitclock-master = <_cpu>;
+ mclk-fs = <128>;
- link_codec: simple-audio-card,codec {
- sound-dai = < 0>;
+ link0_cpu: cpu {
+ sound-dai = <>;
+ };
+
+ link0_codec: codec {
+ sound-dai = < 0>;
+ };
};
};
--
2.26.2
[PATCH v2 2/7] ARM: dts: sun8i-a33: Allow using multiple codec DAIs
Increase #sound-dai-cells on the digital codec to allow using the other
DAIs provided by the codec for AIF2 and AIF3.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun8i-a33.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index c458f5fb124f..0b38f9f35074 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -198,7 +198,7 @@ simple-audio-card,cpu {
};
link_codec: simple-audio-card,codec {
- sound-dai = <>;
+ sound-dai = < 0>;
};
};
@@ -238,7 +238,7 @@ dai: dai@1c22c00 {
};
codec: codec@1c22e00 {
- #sound-dai-cells = <0>;
+ #sound-dai-cells = <1>;
compatible = "allwinner,sun8i-a33-codec";
reg = <0x01c22e00 0x400>;
interrupts = ;
--
2.26.2
[PATCH v2 0/7] PinePhone BT audio bringup
This series makes use of the additional DAIs recently added to the sun8i-codec driver to add hardware routing for BT SCO (headset) audio on the PinePhone. The BT audio connection is represented by the "dummy" bt-sco codec. The connection to the Quectel EG-25G modem via AIF2 works as well, but I do not include it here because there is no appropriate codec driver in tree. We have been using an out-of-tree "dummy" codec driver for the modem similar to bt-sco, and I'm not sure if such a driver would be desired upstream. Changes from v1: - Fixed DT binding example to follow new binding Arnaud Ferraris (1): arm64: dts: allwinner: pinephone: Set audio card name Samuel Holland (6): ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells ARM: dts: sun8i-a33: Allow using multiple codec DAIs arm64: dts: allwinner: a64: Allow using multiple codec DAIs arm64: dts: allwinner: a64: Add pinmux nodes for AIF2/AIF3 arm64: dts: allwinner: a64: Allow multiple DAI links arm64: dts: allwinner: pinephone: Add support for Bluetooth audio .../sound/allwinner,sun8i-a33-codec.yaml | 4 +- arch/arm/boot/dts/sun8i-a33.dtsi | 4 +- .../dts/allwinner/sun50i-a64-pinephone.dtsi | 25 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 ++- 4 files changed, 56 insertions(+), 14 deletions(-) -- 2.26.2
[PATCH v2 1/7] ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells
Increase sound-dai-cells to 1 to allow using the DAIs in the codec
corresponding to AIF2 and AIF3.
The generic ASoC OF code supports a #sound-dai-cells value of 0 or 1
with no impact to the driver, so this is a backward-compatible change.
Signed-off-by: Samuel Holland
---
.../devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
index 67405e6d8168..3e02baa1d9ce 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
@@ -12,7 +12,7 @@ maintainers:
properties:
"#sound-dai-cells":
-const: 0
+const: 1
compatible:
oneOf:
@@ -50,7 +50,7 @@ additionalProperties: false
examples:
- |
audio-codec@1c22e00 {
- #sound-dai-cells = <0>;
+ #sound-dai-cells = <1>;
compatible = "allwinner,sun8i-a33-codec";
reg = <0x01c22e00 0x400>;
interrupts = <0 29 4>;
--
2.26.2
[PATCH v2 3/7] arm64: dts: allwinner: a64: Allow using multiple codec DAIs
Increase #sound-dai-cells on the digital codec to allow using the other
DAIs provided by the codec for AIF2 and AIF3.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 51cc30e84e26..e788251e582f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -150,7 +150,7 @@ cpudai: simple-audio-card,cpu {
};
link_codec: simple-audio-card,codec {
- sound-dai = <>;
+ sound-dai = < 0>;
};
};
@@ -874,7 +874,7 @@ dai: dai@1c22c00 {
};
codec: codec@1c22e00 {
- #sound-dai-cells = <0>;
+ #sound-dai-cells = <1>;
compatible = "allwinner,sun50i-a64-codec",
"allwinner,sun8i-a33-codec";
reg = <0x01c22e00 0x600>;
--
2.26.2
[PATCH v2 4/7] arm64: dts: allwinner: a64: Add pinmux nodes for AIF2/AIF3
Now that the sun8i-codec driver supports AIF2 and AIF3, boards can use
them in DAI links. Add the necessary pinmux nodes.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e788251e582f..4bba468d8ec2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -654,6 +654,18 @@ pio: pinctrl@1c20800 {
interrupt-controller;
#interrupt-cells = <3>;
+ /omit-if-no-ref/
+ aif2_pins: aif2-pins {
+ pins = "PB4", "PB5", "PB6", "PB7";
+ function = "aif2";
+ };
+
+ /omit-if-no-ref/
+ aif3_pins: aif3-pins {
+ pins = "PG10", "PG11", "PG12", "PG13";
+ function = "aif3";
+ };
+
csi_pins: csi-pins {
pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
"PE7", "PE8", "PE9", "PE10", "PE11";
--
2.26.2
Re: [PATCH] arm64: dts: imx8mn-beacon-som: Configure RTC aliases
On Sun, Jan 10, 2021 at 05:53:53AM -0600, Adam Ford wrote: > On the i.MX8MN Beacon SOM, there is an RTC chip which is fed power > from the baseboard during power off. The SNVS RTC integrated into > the SoC is not fed power. Depending on the order the modules are > loaded, this can be a problem if the external RTC isn't rtc0. > > Make the alias for rtc0 point to the external RTC all the time and > rtc1 point to the SVNS in order to correctly hold date/time over > a power-cycle. > > Signed-off-by: Adam Ford Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] arm64: dts: imx8mm-beacon: add more pinctrl states for usdhc1
On Sun, Jan 10, 2021 at 05:38:26AM -0600, Adam Ford wrote: > The WiFi chip is capable of communication at SDR104 speeds. > Enable 100Mhz and 200MHz pinmux to support this. > > Signed-off-by: Adam Ford > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [kbuild-all] Re: fs/f2fs/gc.c:622:12: warning: stack frame size of 3056 bytes in function 'get_victim_by_default'
On 1/11/21 4:23 PM, Chao Yu wrote: Hello, Thanks for the report. I replied for your previous report [1], could you please check that? [1] https://lore.kernel.org/lkml/8a8ef6b8-84c2-abfe-e758-2fa52a989...@huawei.com/ That says, in my environment, get_victim_by_default()'s frame size is less than 512 bytes, and also after going through related code, I don't see any obvious large stack size usage. Is that issue a powerpc specified issue? Hi Chao, The issue can be found on arch mips too: fs/f2fs/gc.c:622:12: warning: stack frame size of 1672 bytes in function 'get_victim_by_default' [-Wframe-larger-than=] static int get_victim_by_default(struct f2fs_sb_info *sbi, ^ 1 warning generated. Could you help to verify powerpc compiling with -Wframe-larger-than=512 after reverting that atgc patch? I mean whether get_victim_by_default() already have large frame size before applying atgc patch (commit 093749e296e2)? After reverting commit 093749e29 and set -Wframe-larger-than=512, the warning is fs/f2fs/gc.c:325:12: warning: stack frame size of 912 bytes in function 'get_victim_by_default' [-Wframe-larger-than=] static int get_victim_by_default(struct f2fs_sb_info *sbi, Best Regards, Rong Chen On 2021/1/9 21:18, kernel test robot wrote: Hi Chao, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 996e435fd401de35df62ac943ab9402cfe85c430 commit: 093749e296e29a4b0162eb925a6701a01e8c9a98 f2fs: support age threshold based garbage collection date: 4 months ago config: powerpc-randconfig-r033-20210109 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bc556e5685c0f97e79fb7b3c6f15cc5062db8e36) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=093749e296e29a4b0162eb925a6701a01e8c9a98 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 093749e296e29a4b0162eb925a6701a01e8c9a98 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :182:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :184:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:10: In file included from
linux-next: Signed-off-by missing for commit in the devicetree-fixes tree
Hi all,
Commit
79aae8a66926 ("WIP dt-bindings: cleanups")
is missing a Signed-off-by from its author and comitter.
--
Cheers,
Stephen Rothwell
pgp53xghhIS6i.pgp
Description: OpenPGP digital signature
Re: [PATCH v9 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Tue, Jan 12, 2021 at 11:07 PM Rob Herring wrote: > > On Fri, Jan 08, 2021 at 09:10:08AM +0800, Nicolas Boichat wrote: > > Define a compatible string for the Mali Bifrost GPU found in > > Mediatek's MT8183 SoCs. > > > > Signed-off-by: Nicolas Boichat > > Reviewed-by: Alyssa Rosenzweig > > --- > > > > (no changes since v6) > > > > Changes in v6: > > - Rebased, actually tested with recent mesa driver. > > - No change > > > > Changes in v5: > > - Rename "2d" power domain to "core2" > > > > Changes in v4: > > - Add power-domain-names description > >(kept Alyssa's reviewed-by as the change is minor) > > > > Changes in v3: > > - No change > > > > .../bindings/gpu/arm,mali-bifrost.yaml| 25 +++ > > 1 file changed, 25 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > index 184492162e7e..71b613ee5bd7 100644 > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > @@ -17,6 +17,7 @@ properties: > > items: > >- enum: > >- amlogic,meson-g12a-mali > > + - mediatek,mt8183-mali > >- realtek,rtd1619-mali > >- rockchip,px30-mali > >- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully > > discoverable > > @@ -87,6 +88,30 @@ allOf: > > then: > >required: > > - resets > > + - if: > > + properties: > > +compatible: > > + contains: > > +const: mediatek,mt8183-mali > > +then: > > + properties: > > +sram-supply: true > > This has to be defined at the top-level or there will be an error when > it is present (due to additionalProperties). > > In this if/then you can do: > > else: > sram-supply: false > > to disallow it if not 'mediatek,mt8183-mali' I see. Thanks Rob, will send a v10. > > > +power-domains: > > + description: > > +List of phandle and PM domain specifier as documented in > > +Documentation/devicetree/bindings/power/power_domain.txt > > + minItems: 3 > > + maxItems: 3 > > +power-domain-names: > > + items: > > +- const: core0 > > +- const: core1 > > +- const: core2 > > + > > + required: > > +- sram-supply > > +- power-domains > > +- power-domains-names > > > > examples: > >- | > > -- > > 2.29.2.729.g45daf8777d-goog > >
Re: [LKP] Re: [btrfs] e076ab2a2c: fio.write_iops -18.3% regression
On 1/12/2021 11:45 PM, David Sterba wrote:
On Tue, Jan 12, 2021 at 11:36:14PM +0800, kernel test robot wrote:
Greeting,
FYI, we noticed a -18.3% regression of fio.write_iops due to commit:
commit: e076ab2a2ca70a0270232067cd49f76cd92efe64 ("btrfs: shrink delalloc pages
instead of full inodes")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: fio-basic
on test machine: 192 threads Intel(R) Xeon(R) CPU @ 2.20GHz with 192G memory
with following parameters:
disk: 1SSD
fs: btrfs
runtime: 300s
nr_task: 8
rw: randwrite
bs: 4k
ioengine: sync
test_size: 256g
Though I do a similar test (emulating bit torrent workload), it's a bit
extreme as it's 4k synchronous on a huge file. It always takes a lot of
time but could point out some concurrency issues namely on faster
devices. There are 8 threads possibly competing for the same inode lock
or other locks related to it.
The mentioned commit fixed another perf regression on a much more common
workload (untgrring files), so at this point drop in this fio workload
is inevitable.
Do you have a plan to fix it? Thanks.
___
LKP mailing list -- l...@lists.01.org
To unsubscribe send an email to lkp-le...@lists.01.org
--
Zhengjun Xing
Re: [PATCH] bio: limit bio max size.
On 2021/01/13 13:01, Changheun Lee wrote:
>> On 2021/01/12 21:14, Changheun Lee wrote:
On 2021/01/12 17:52, Changheun Lee wrote:
> From: "Changheun Lee"
>
> bio size can grow up to 4GB when muli-page bvec is enabled.
> but sometimes it would lead to inefficient behaviors.
> in case of large chunk direct I/O, - 64MB chunk read in user space -
> all pages for 64MB would be merged to a bio structure if memory address is
> continued phsycally. it makes some delay to submit until merge complete.
> bio max size should be limited as a proper size.
But merging physically contiguous pages into the same bvec + later
automatic bio
split on submit should give you better throughput for large IOs compared to
having to issue a bio chain of smaller BIOs that are arbitrarily sized and
will
likely need splitting anyway (because of DMA boundaries etc).
Do you have a specific case where you see higher performance with this
patch
applied ? On Intel, BIO_MAX_SIZE would be 1MB... That is arbitrary and too
small
considering that many hardware can execute larger IOs than that.
>>>
>>> When I tested 32MB chunk read with O_DIRECT in android, all pages of 32MB
>>> is merged into a bio structure.
>>> And elapsed time to merge complete was about 2ms.
>>> It means first bio-submit is after 2ms.
>>> If bio size is limited with 1MB with this patch, first bio-submit is about
>>> 100us by bio_full operation.
>>
>> bio_submit() will split the large BIO case into multiple requests while the
>> small BIO case will likely result one or two requests only. That likely
>> explain
>> the time difference here. However, for the large case, the 2ms will issue ALL
>> requests needed for processing the entire 32MB user IO while the 1MB bio case
>> will need 32 different bio_submit() calls. So what is the actual total
>> latency
>> difference for the entire 32MB user IO ? That is I think what needs to be
>> compared here.
>>
>> Also, what is your device max_sectors_kb and max queue depth ?
>>
>
> 32MB total latency is about 19ms including merge time without this patch.
> But with this patch, total latency is about 17ms including merge time too.
> Actually 32MB read time from device is same - about 16.7ms - in driver layer.
> No need to hold more I/O than max_sectors_kb during bio merge.
> My device is UFS. and max_sectors_kb is 1MB, queue depth is 32.
This may be due to the CPU being slow: it takes time to build the 32MB BIO,
during which the device is idling. With the 1MB BIO limit, the first BIO hits
the drive much more quickly, reducing idle time of the device and leading to
higher throughput. But there are 31 more BIOs to build and issue after the first
one... That does create a pipeline of requests keeping the device busy, but that
also likely keeps your CPU a lot more busy building these additional BIOs.
Overall, do you see a difference in CPU load for the 32MB BIO case vs the 1MB
max BIO case ? Any increase in CPU load with the lower BIO size limit ?
>
>>> It's not large delay and can't be observed with low speed device.
>>> But it's needed to reduce merge delay for high speed device.
>>> I improved 512MB sequential read performance from 1900MB/s to 2000MB/s
>>> with this patch on android platform.
>>> As you said, 1MB might be small for some device.
>>> But method is needed to re-size, or select the bio max size.
>>
>> At the very least, I think that such limit should not be arbitrary as your
>> patch
>> proposes but rely on the device characteristics (e.g.
>> max_hw_sectors_kb/max_sectors_kb and queue depth).
>>
>
> I agree with your opinion, I thought same as your idea. For that, deep
> research
> is needed, proper timing to set and bio structure modification, etc ...
Why would you need any BIO structure modifications ? Your patch is on the right
track if limiting the BIO size is the right solution (I am not still completely
convinced). E.g., the code:
if (page_is_mergeable(bv, page, len, off, same_page)) {
if (bio->bi_iter.bi_size > BIO_MAX_SIZE - len) {
*same_page = false;
return false;
}
could just become:
if (page_is_mergeable(bv, page, len, off, same_page)) {
if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
*same_page = false;
return false;
}
With bio_max_size() being something like:
static inline size_t bio_max_size(struct bio *bio)
{
sector_t max_sectors = blk_queue_get_max_sectors(bio->bi_disk->queue,
bio_op(bio));
return max_sectors << SECTOR_SHIFT;
}
Note that this is not super efficient as a BIO maximum size depends on the BIO
offset too (its start sector). So writing something similar to
blk_rq_get_max_sectors() would probably be better.
> Current is simple patch for
Re: [PATCH v3] scsi: ufs: Replace sprintf and snprintf with sysfs_emit
On Wed, 6 Jan 2021 22:15:41 +0100, Bean Huo wrote: > sprintf and snprintf may cause output defect in sysfs content, it is > better to use new added sysfs_emit function which knows the size of the > temporary buffer. Applied to 5.12/scsi-queue, thanks! [1/1] scsi: ufs: Replace sprintf and snprintf with sysfs_emit https://git.kernel.org/mkp/scsi/c/d9edeb8b4768 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: fnic: Fix memleak in vnic_dev_init_devcmd2
On Fri, 25 Dec 2020 16:35:20 +0800, Dinghao Liu wrote: > When ioread32() returns 0x, we should execute > cleanup functions like other error handling paths before > returning. Applied to 5.11/scsi-fixes, thanks! [1/1] scsi: fnic: Fix memleak in vnic_dev_init_devcmd2 https://git.kernel.org/mkp/scsi/c/d6e3ae76728c -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2 0/5] ibmvfc: MQ preparatory locking work
On Wed, 6 Jan 2021 14:18:30 -0600, Tyrel Datwyler wrote: > The ibmvfc driver in its current form relies heavily on the host_lock. This > patchset introduces a genric queue with its own queue lock and sent/free event > list locks. This generic queue allows the driver to decouple the primary queue > and future subordinate queues from the host lock reducing lock contention > while > also relaxing locking for submissions and completions to simply the list lock > of > the queue in question. > > [...] Applied to 5.12/scsi-queue, thanks! [1/5] ibmvfc: define generic queue structure for CRQs https://git.kernel.org/mkp/scsi/c/f8968665af28 [2/5] ibmvfc: make command event pool queue specific https://git.kernel.org/mkp/scsi/c/e4b26f3db864 [3/5] ibmvfc: define per-queue state/list locks https://git.kernel.org/mkp/scsi/c/57e80e0bc108 [4/5] ibmvfc: complete commands outside the host/queue lock https://git.kernel.org/mkp/scsi/c/1f4a4a19508d [5/5] ibmvfc: relax locking around ibmvfc_queuecommand https://git.kernel.org/mkp/scsi/c/654080d02edb -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v4 0/6] Several changes for the UPIU trace
On Tue, 5 Jan 2021 12:34:40 +0100, Bean Huo wrote: > Changelog: > > V3--v4: > 1. Rebase patch onto 5.12/scsi-queue > 2. Incorporate Avri's suggestion in patch 2/6 > > V2--V3: > 1. Fix a typo in patch 1/6 (Reported-by: Joe Perches ) > > [...] Applied to 5.12/scsi-queue, thanks! [1/6] scsi: ufs: Remove stringize operator '#' restriction https://git.kernel.org/mkp/scsi/c/c7c730ac6a88 [2/6] scsi: ufs: Use __print_symbolic() for UFS trace string print https://git.kernel.org/mkp/scsi/c/28fa68fc557a [3/6] scsi: ufs: Don't call trace_ufshcd_upiu() in case trace poit is disabled https://git.kernel.org/mkp/scsi/c/9d5095e74c83 [4/6] scsi: ufs: Distinguish between query REQ and query RSP in query trace https://git.kernel.org/mkp/scsi/c/be20b51cfd85 [5/6] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace https://git.kernel.org/mkp/scsi/c/0ed083e91662 [6/6] scsi: ufs: Make UPIU trace easier differentiate among CDB, OSF, and TM https://git.kernel.org/mkp/scsi/c/867fdc2d6e34 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: docs: ABI: sysfs-driver-ufs: rectify table formatting
On Mon, 11 Jan 2021 11:22:12 +0100, Lukas Bulwahn wrote:
> Commit 0b2894cd0fdf ("scsi: docs: ABI: sysfs-driver-ufs: Add DeepSleep
> power mode") adds new entries in tables of sysfs-driver-ufs ABI
> documentation, but formatted the table incorrectly.
>
> Hence, make htmldocs warns:
>
> ./Documentation/ABI/testing/sysfs-driver-ufs:{915,956}:
> WARNING: Malformed table. Text in column margin in table line 15.
>
> [...]
Applied to 5.11/scsi-fixes, thanks!
[1/1] scsi: docs: ABI: sysfs-driver-ufs: rectify table formatting
https://git.kernel.org/mkp/scsi/c/f2cb4b2397ca
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/2] hisi_sas: Expose hw queues for v2 hw and remove unused code
On Mon, 4 Jan 2021 20:33:40 +0800, John Garry wrote: > Patch "scsi: hisi_sas: Expose HW queues for v2 hw" was not merged for > v5.11, so resending for v5.12. > > Unused module param auto_affine_msi_experimental for v3 hw is also > removed in the other patch. > > John Garry (2): > scsi: hisi_sas: Remove auto_affine_msi_experimental module_param > scsi: hisi_sas: Expose HW queues for v2 hw > > [...] Applied to 5.12/scsi-queue, thanks! [1/2] scsi: hisi_sas: Remove auto_affine_msi_experimental module_param https://git.kernel.org/mkp/scsi/c/3997e0fdd587 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/3] scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback() -- Take 2
On Thu, 17 Dec 2020 21:33:18 +0100, Andrea Parri (Microsoft) wrote:
> This series is to address the problems mentioned in:
>
> 4da3a54f5a0258 ("Revert "scsi: storvsc: Validate length of incoming packet
> in storvsc_on_channel_callback()"")
>
> (cf., in particular, patch 2/3) and to re-introduce the validation in
> question (patch 3/3); patch 1/3 emerged from internal review of these
> two patches and is a related fix.
>
> [...]
Applied to 5.12/scsi-queue, thanks!
[1/3] scsi: storvsc: Fix max_outstanding_req_per_channel for Win8 and newer
https://git.kernel.org/mkp/scsi/c/ab548fd21e1c
[2/3] scsi: storvsc: Resolve data race in storvsc_probe()
https://git.kernel.org/mkp/scsi/c/244808e03029
[3/3] scsi: storvsc: Validate length of incoming packet in
storvsc_on_channel_callback()
https://git.kernel.org/mkp/scsi/c/91b1b640b834
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] scsi: ufs: fix all Kconfig help text indentation
On Wed, 6 Jan 2021 12:55:54 -0800, Randy Dunlap wrote: > Use consistent and expected indentation for all Kconfig text. Applied to 5.12/scsi-queue, thanks! [1/1] scsi: ufs: fix all Kconfig help text indentation https://git.kernel.org/mkp/scsi/c/aaac0ea98390 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] mm: slub: Convert sys slab alloc_calls, free_calls to bin attribute
On 1/12/2021 5:52 PM, Matthew Wilcox wrote:
> On Tue, Jan 12, 2021 at 02:51:27PM +0530, Faiyaz Mohammed wrote:
>> @@ -5180,6 +5187,7 @@ static int any_slab_objects(struct kmem_cache *s)
>>
>> struct slab_attribute {
>> struct attribute attr;
>> +struct bin_attribute bin_attr;
>> ssize_t (*show)(struct kmem_cache *s, char *buf);
>> ssize_t (*store)(struct kmem_cache *s, const char *x, size_t count);
>> };
>
> I'd rather you added a struct slab_bin_attribute. If that's even
> needed .. I think you could just use the bin_attribute directly instead
> of embedding it in this struct.
>
Okay, I will use bin_attribute directly, but I added the bin_attribute
inside the slab_attribute to maintain similar code like sysfs attribute
and slab_attribute is embedded with it's all slab attributes.
linux-next: Tree for Jan 13
Hi all,
Changes since 20210112:
New tree: iomem-mmap-vs-gup
The drm tree still had its build failure so I used the version from
next-20210107.
The drm-intel tree gained a build failure from merging the drm tree,
so I have used the version from next-20210108.
The drm-misc tree still had its build failure from merging the drm tree,
so I have used the version from next-20210107.
I reverted a commit from the iomem-mmap-vs-gup tree that caused a boot
failure on PowerPC.
Non-merge commits (relative to Linus' tree): 2333
2515 files changed, 106801 insertions(+), 36883 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 331 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (e609571b5ffa Merge tag 'nfs-for-5.11-2' of
git://git.linux-nfs.org/projects/trondmy/linux-nfs)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (5625dcfbbcf8 Documentation: kbuild: Fix section
reference)
Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (d78050ee3544 arm64: Remove
arm64_dma32_phys_limit and its uses)
Merging arm-soc-fixes/arm/fixes (bac717171971 ARM: picoxcell: fix missing
interrupt-parent properties)
Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (3ce47d95b734 powerpc: Handle
.text.{hot,unlikely}.* in linker script)
Merging s390-fixes/fixes (a1a322a62dba s390/vfio-ap: clean up vfio_ap resources
when KVM pointer invalidated)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (1ee527a79fa6 Merge branch 'skb-frag-kmap_atomic-fixes')
Merging bpf/master (b8d52264df85 libbpf: Allow loading empty BTFs)
Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in
xfrm_policy_addr_delta())
Merging netfilter/master (869f4fdaf4ca netfilter: nf_nat: Fix memleak in
nf_nat_init)
Merging ipvs/master (869f4fdaf4ca netfilter: nf_nat: Fix memleak in nf_nat_init)
Merging wireless-drivers/master (6279d812eab6 Merge tag 'net-5.11-rc3-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging mac80211/master (51d62f2f2c50 cfg80211: Save the regulatory domain with
a lock)
Merging rdma-fixes/for-rc (f2bc3af6353c RDMA/ocrdma: Fix use after free in
ocrdma_dealloc_ucontext_pd())
Merging sound-current/for-linus (20c7842ed837 ALSA: hda/hdmi - enable runtime
pm for CI AMD display audio)
Merging sound-asoc-fixes/for-linus (d82284841e36 Merge remote-tracking branch
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (72962ebcdd45 Merge remote-tracking branch
'regmap/for-5.11' into regmap-linus)
Merging regulator-fixes/for-linus (14da16efa6f9 Merge remote-tracking branch
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (7c53f6b671f4 Linux 5.11-rc3)
Merging pci-current/for-linus (7c53f6b671f4 Linux 5.11-rc3)
Merging driver-core.current/driver-core-linus (895bee270863 Revert "driv
Re: [PATCH] usb: dwc3: qcom: Add shutdown callback for dwc3
On 2020-11-12 12:00, Sandeep Maheswaram wrote:
This patch adds a shutdown callback to USB DWC QCOM driver to ensure
that
it is properly shutdown in reboot/shutdown path. This is required
where SMMU address translation is enabled like on SC7180
SoC and few others. If the hardware is still accessing memory after
SMMU translation is disabled as part of SMMU shutdown callback in
system reboot or shutdown path, then IOVAs(I/O virtual address)
which it was using will go on the bus as the physical addresses which
might result in unknown crashes (NoC/interconnect errors).
Signed-off-by: Sandeep Maheswaram
---
drivers/usb/dwc3/dwc3-qcom.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c
b/drivers/usb/dwc3/dwc3-qcom.c
index c703d55..a930e06 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -790,13 +790,11 @@ static int dwc3_qcom_probe(struct platform_device
*pdev)
return ret;
}
-static int dwc3_qcom_remove(struct platform_device *pdev)
+static void __dwc3_qcom_teardown(struct dwc3_qcom *qcom)
{
- struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
- struct device *dev = >dev;
int i;
- of_platform_depopulate(dev);
+ of_platform_depopulate(qcom->dev);
for (i = qcom->num_clocks - 1; i >= 0; i--) {
clk_disable_unprepare(qcom->clks[i]);
@@ -807,12 +805,27 @@ static int dwc3_qcom_remove(struct
platform_device *pdev)
dwc3_qcom_interconnect_exit(qcom);
reset_control_assert(qcom->resets);
- pm_runtime_allow(dev);
- pm_runtime_disable(dev);
+ pm_runtime_allow(qcom->dev);
+ pm_runtime_disable(qcom->dev);
+}
+
+static int dwc3_qcom_remove(struct platform_device *pdev)
+{
+ struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
+
+ __dwc3_qcom_teardown(qcom);
return 0;
}
+static void dwc3_qcom_shutdown(struct platform_device *pdev)
+{
+ struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
+
+ __dwc3_qcom_teardown(qcom);
+
+}
+
static int __maybe_unused dwc3_qcom_pm_suspend(struct device *dev)
{
struct dwc3_qcom *qcom = dev_get_drvdata(dev);
@@ -887,6 +900,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_qcom_acpi_match);
static struct platform_driver dwc3_qcom_driver = {
.probe = dwc3_qcom_probe,
.remove = dwc3_qcom_remove,
+ .shutdown = dwc3_qcom_shutdown,
.driver = {
.name = "dwc3-qcom",
.pm = _qcom_dev_pm_ops,
Hi Felipe,
Can you please review this patch.
Regards
Sandeep
Re: [PATCH v4 3/3] scsi: 3w-9xxx: Fix endianness issues in command packets
On 9/2/20 10:44 PM, Samuel Holland wrote: > The controller expects all data it sends/receives to be little-endian. > Therefore, the packet struct definitions should use the __le16/32/64 > types. Once those are correct, sparse reports several issues with the > driver code, which are fixed here as well. > > The main issue observed was at the call to scsi_set_resid, where the > byteswapped parameter would eventually trigger the alignment check at > drivers/scsi/sd.c:2009. At that point, the kernel would continuously > complain about an "Unaligned partial completion", and no further I/O > could occur. > > This gets the controller working on big endian powerpc64. > > Signed-off-by: Samuel Holland I believe I addressed all previous comments to this series in v4. Is there anything preventing it from being merged? Do I need to resend it? Regards, Samuel
[PATCH bpf v2 2/2] selftests/bpf: add verifier test for PTR_TO_MEM spill
Add a test to check that the verifier is able to recognize spilling of
PTR_TO_MEM registers, by reserving a ringbuf buffer, forcing the spill
of a pointer holding the buffer address to the stack, filling it back
in from the stack and writing to the memory area pointed by it.
The patch was partially contributed by CyberArk Software, Inc.
Signed-off-by: Gilad Reti
---
tools/testing/selftests/bpf/test_verifier.c | 12 +++-
.../selftests/bpf/verifier/spill_fill.c | 30 +++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_verifier.c
b/tools/testing/selftests/bpf/test_verifier.c
index 777a81404fdb..f8569f04064b 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -50,7 +50,7 @@
#define MAX_INSNS BPF_MAXINSNS
#define MAX_TEST_INSNS 100
#define MAX_FIXUPS 8
-#define MAX_NR_MAPS20
+#define MAX_NR_MAPS21
#define MAX_TEST_RUNS 8
#define POINTER_VALUE 0xcafe4all
#define TEST_DATA_LEN 64
@@ -87,6 +87,7 @@ struct bpf_test {
int fixup_sk_storage_map[MAX_FIXUPS];
int fixup_map_event_output[MAX_FIXUPS];
int fixup_map_reuseport_array[MAX_FIXUPS];
+ int fixup_map_ringbuf[MAX_FIXUPS];
const char *errstr;
const char *errstr_unpriv;
uint32_t insn_processed;
@@ -640,6 +641,7 @@ static void do_test_fixup(struct bpf_test *test, enum
bpf_prog_type prog_type,
int *fixup_sk_storage_map = test->fixup_sk_storage_map;
int *fixup_map_event_output = test->fixup_map_event_output;
int *fixup_map_reuseport_array = test->fixup_map_reuseport_array;
+ int *fixup_map_ringbuf = test->fixup_map_ringbuf;
if (test->fill_helper) {
test->fill_insns = calloc(MAX_TEST_INSNS, sizeof(struct
bpf_insn));
@@ -817,6 +819,14 @@ static void do_test_fixup(struct bpf_test *test, enum
bpf_prog_type prog_type,
fixup_map_reuseport_array++;
} while (*fixup_map_reuseport_array);
}
+ if (*fixup_map_ringbuf) {
+ map_fds[20] = create_map(BPF_MAP_TYPE_RINGBUF, 0,
+ 0, 4096);
+ do {
+ prog[*fixup_map_ringbuf].imm = map_fds[20];
+ fixup_map_ringbuf++;
+ } while (*fixup_map_ringbuf);
+ }
}
struct libcap {
diff --git a/tools/testing/selftests/bpf/verifier/spill_fill.c
b/tools/testing/selftests/bpf/verifier/spill_fill.c
index 45d43bf82f26..0b943897aaf6 100644
--- a/tools/testing/selftests/bpf/verifier/spill_fill.c
+++ b/tools/testing/selftests/bpf/verifier/spill_fill.c
@@ -28,6 +28,36 @@
.result = ACCEPT,
.result_unpriv = ACCEPT,
},
+{
+ "check valid spill/fill, ptr to mem",
+ .insns = {
+ /* reserve 8 byte ringbuf memory */
+ BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
+ BPF_LD_MAP_FD(BPF_REG_1, 0),
+ BPF_MOV64_IMM(BPF_REG_2, 8),
+ BPF_MOV64_IMM(BPF_REG_3, 0),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_reserve),
+ /* store a pointer to the reserved memory in R6 */
+ BPF_MOV64_REG(BPF_REG_6, BPF_REG_0),
+ /* check whether the reservation was successful */
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 6),
+ /* spill R6(mem) into the stack */
+ BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_6, -8),
+ /* fill it back in R7 */
+ BPF_LDX_MEM(BPF_DW, BPF_REG_7, BPF_REG_10, -8),
+ /* should be able to access *(R7) = 0 */
+ BPF_ST_MEM(BPF_DW, BPF_REG_7, 0, 0),
+ /* submit the reserved ringbuf memory */
+ BPF_MOV64_REG(BPF_REG_1, BPF_REG_7),
+ BPF_MOV64_IMM(BPF_REG_2, 0),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_ringbuf_submit),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .fixup_map_ringbuf = { 1 },
+ .result = ACCEPT,
+ .result_unpriv = ACCEPT,
+},
{
"check corrupted spill/fill",
.insns = {
--
2.27.0
[PATCH bpf v2 1/2] bpf: support PTR_TO_MEM{,_OR_NULL} register spilling
Add support for pointer to mem register spilling, to allow the verifier
to track pointers to valid memory addresses. Such pointers are returned
for example by a successful call of the bpf_ringbuf_reserve helper.
The patch was partially contributed by CyberArk Software, Inc.
Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for
it")
Suggested-by: Yonghong Song
Signed-off-by: Gilad Reti
---
kernel/bpf/verifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 17270b8404f1..36af69fac591 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2217,6 +2217,8 @@ static bool is_spillable_regtype(enum bpf_reg_type type)
case PTR_TO_RDWR_BUF:
case PTR_TO_RDWR_BUF_OR_NULL:
case PTR_TO_PERCPU_BTF_ID:
+ case PTR_TO_MEM:
+ case PTR_TO_MEM_OR_NULL:
return true;
default:
return false;
--
2.27.0
Re: [PATCH] scsi: qedf: style: Simplify bool comparison
Yang, > Fix the following coccicheck warning: > ./drivers/scsi/qedf/qedf_main.c:3716:5-31: WARNING: Comparison to bool Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
