[PATCH 1/1] iommu/vt-d: Fix NULL pointer dereference in dev_iommu_priv_set()
The dev_iommu_priv_set() must be called after probe_device(). This fixes
a NULL pointer deference bug when booting a system with kernel cmdline
"intel_iommu=on,igfx_off", where the dev_iommu_priv_set() is abused.
The following stacktrace was produced:
[0.00] Command line: BOOT_IMAGE=/isolinux/bzImage console=tty1
intel_iommu=on,igfx_off
...
[3.341682] DMAR: Host address width 39
[3.341684] DMAR: DRHD base: 0x00fed9 flags: 0x0
[3.341702] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap 1cc40660462
ecap 19e2ff0505e
[3.341705] DMAR: DRHD base: 0x00fed91000 flags: 0x1
[3.341711] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c40660462
ecap f050da
[3.341713] DMAR: RMRR base: 0x009aa9f000 end: 0x009aabefff
[3.341716] DMAR: RMRR base: 0x009d00 end: 0x009f7f
[3.341726] DMAR: No ATSR found
[3.341772] BUG: kernel NULL pointer dereference, address: 0038
[3.341774] #PF: supervisor write access in kernel mode
[3.341776] #PF: error_code(0x0002) - not-present page
[3.341777] PGD 0 P4D 0
[3.341780] Oops: 0002 [#1] SMP PTI
[3.341783] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.9.0-devel+ #2
[3.341785] Hardware name: LENOVO 20HGS0TW00/20HGS0TW00, BIOS N1WET46S
(1.25s ) 03/30/2018
[3.341790] RIP: 0010:intel_iommu_init+0xed0/0x1136
[3.341792] Code: fe e9 61 02 00 00 bb f4 ff ff ff e9 57 02 00 00 48 63 d1
48 c1 e2 04 48
03 50 20 48 8b 12 48 85 d2 74 0b 48 8b 92 d0 02 00 00 48
89 7a 38 ff c1
e9 15 f5 ff ff 48 c7 c7 60 99 ac a7 49 c7 c7 a0
[3.341796] RSP: :96d180073dd0 EFLAGS: 00010282
[3.341798] RAX: 8c91037a7d20 RBX: RCX:
[3.341800] RDX: RSI: RDI:
[3.341802] RBP: 96d180073e90 R08: 0001 R09: 8c91039fe3c0
[3.341804] R10: 0226 R11: 0226 R12: 000b
[3.341806] R13: 8c910367c650 R14: a8426d60 R15:
[3.341808] FS: () GS:8c910748()
knlGS:
[3.341810] CS: 0010 DS: ES: CR0: 80050033
[3.341812] CR2: 0038 CR3: 0004b100a001 CR4: 003706e0
[3.341814] Call Trace:
[3.341820] ? _raw_spin_unlock_irqrestore+0x1f/0x30
[3.341824] ? call_rcu+0x10e/0x320
[3.341828] ? trace_hardirqs_on+0x2c/0xd0
[3.341831] ? rdinit_setup+0x2c/0x2c
[3.341834] ? e820__memblock_setup+0x8b/0x8b
[3.341836] pci_iommu_init+0x16/0x3f
[3.341839] do_one_initcall+0x46/0x1e4
[3.341842] kernel_init_freeable+0x169/0x1b2
[3.341845] ? rest_init+0x9f/0x9f
[3.341847] kernel_init+0xa/0x101
[3.341849] ret_from_fork+0x22/0x30
[3.341851] Modules linked in:
[3.341854] CR2: 0038
[3.341860] ---[ end trace 3653722a6f936f18 ]---
Fixes: 01b9d4e21148c ("iommu/vt-d: Use dev_iommu_priv_get/set()")
Reported-by: Torsten Hilbrich
Reported-by: Wendy Wang
Link:
https://lore.kernel.org/linux-iommu/96717683-70be-7388-3d2f-61131070a...@secunet.com/
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 100
1 file changed, 55 insertions(+), 45 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 50431c7b2e71..777b9be60a0e 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -366,7 +366,6 @@ static int iommu_skip_te_disable;
int intel_iommu_gfx_mapped;
EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
-#define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
#define DEFER_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-2))
struct device_domain_info *get_domain_info(struct device *dev)
{
@@ -376,8 +375,7 @@ struct device_domain_info *get_domain_info(struct device
*dev)
return NULL;
info = dev_iommu_priv_get(dev);
- if (unlikely(info == DUMMY_DEVICE_DOMAIN_INFO ||
-info == DEFER_DEVICE_DOMAIN_INFO))
+ if (unlikely(info == DEFER_DEVICE_DOMAIN_INFO))
return NULL;
return info;
@@ -773,11 +771,6 @@ struct context_entry *iommu_context_addr(struct
intel_iommu *iommu, u8 bus,
return &context[devfn];
}
-static int iommu_dummy(struct device *dev)
-{
- return dev_iommu_priv_get(dev) == DUMMY_DEVICE_DOMAIN_INFO;
-}
-
static bool attach_deferred(struct device *dev)
{
return dev_iommu_priv_get(dev) == DEFER_DEVICE_DOMAIN_INFO;
@@ -810,6 +803,53 @@ is_downstream_to_pci_bridge(struct device *dev, struct
device *bridge)
return false;
}
+static bool quirk_ioat_snb_local_iommu(struct pci_dev *pdev)
+{
+ struct dmar_drhd_unit *drhd;
+ u32 vtbar;
+ int rc;
+
+ /* We know that this device on this chipset has its own IOMMU.
+* If we find it under a different IOMMU, then the BIOS is lying
+
[Linux-kernel-mentees] [PATCH] block: Fix use-after-free in bdev_del_partition()
In bdev_del_partition(), `part` is being looked up outside the critical
section. This is causing bdev_del_partition() to delete the same partition
more than once. Fix it by reverting commit cddae808aeb7.
Fixes: cddae808aeb7 ("block: pass a hd_struct to delete_partition")
Reported-and-tested-by: syzbot+6448f3c229bc52b82...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Cc: Hillf Danton
Link:
https://syzkaller.appspot.com/bug?id=09fc5ec437ea150f28e8a19f5011c08ee73381af
Signed-off-by: Peilin Ye
---
block/blk.h | 2 +-
block/genhd.c | 2 +-
block/partitions/core.c | 22 ++
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/block/blk.h b/block/blk.h
index 49e2928a1632..f5a46d0020fb 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -350,7 +350,7 @@ char *disk_name(struct gendisk *hd, int partno, char *buf);
#define ADDPART_FLAG_NONE 0
#define ADDPART_FLAG_RAID 1
#define ADDPART_FLAG_WHOLEDISK 2
-void delete_partition(struct gendisk *disk, struct hd_struct *part);
+void delete_partition(struct gendisk *disk, int partno);
int bdev_add_partition(struct block_device *bdev, int partno,
sector_t start, sector_t length);
int bdev_del_partition(struct block_device *bdev, int partno);
diff --git a/block/genhd.c b/block/genhd.c
index 99c64641c314..40abc70b92ab 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -913,7 +913,7 @@ void del_gendisk(struct gendisk *disk)
DISK_PITER_INCL_EMPTY | DISK_PITER_REVERSE);
while ((part = disk_part_iter_next(&piter))) {
invalidate_partition(disk, part->partno);
- delete_partition(disk, part);
+ delete_partition(disk, part->partno);
}
disk_part_iter_exit(&piter);
diff --git a/block/partitions/core.c b/block/partitions/core.c
index e62a98a8eeb7..1fe1fe593423 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -310,17 +310,25 @@ int hd_ref_init(struct hd_struct *part)
* Must be called either with bd_mutex held, before a disk can be opened or
* after all disk users are gone.
*/
-void delete_partition(struct gendisk *disk, struct hd_struct *part)
+void delete_partition(struct gendisk *disk, int partno)
{
struct disk_part_tbl *ptbl =
rcu_dereference_protected(disk->part_tbl, 1);
+ struct hd_struct *part;
+
+ if (partno >= ptbl->len)
+ return;
+
+ part = rcu_dereference_protected(ptbl->part[partno], 1);
+ if (!part)
+ return;
/*
* ->part_tbl is referenced in this part's release handler, so
* we have to hold the disk device
*/
get_device(disk_to_dev(part_to_disk(part)));
- rcu_assign_pointer(ptbl->part[part->partno], NULL);
+ rcu_assign_pointer(ptbl->part[partno], NULL);
kobject_put(part->holder_dir);
device_del(part_to_dev(part));
@@ -531,10 +539,10 @@ int bdev_del_partition(struct block_device *bdev, int
partno)
if (!part)
return -ENXIO;
- ret = -ENOMEM;
bdevp = bdget(part_devt(part));
+ disk_put_part(part);
if (!bdevp)
- goto out_put_part;
+ return -ENOMEM;
mutex_lock(&bdevp->bd_mutex);
@@ -546,15 +554,13 @@ int bdev_del_partition(struct block_device *bdev, int
partno)
invalidate_bdev(bdevp);
mutex_lock_nested(&bdev->bd_mutex, 1);
- delete_partition(bdev->bd_disk, part);
+ delete_partition(bdev->bd_disk, partno);
mutex_unlock(&bdev->bd_mutex);
ret = 0;
out_unlock:
mutex_unlock(&bdevp->bd_mutex);
bdput(bdevp);
-out_put_part:
- disk_put_part(part);
return ret;
}
@@ -627,7 +633,7 @@ int blk_drop_partitions(struct block_device *bdev)
disk_part_iter_init(&piter, bdev->bd_disk, DISK_PITER_INCL_EMPTY);
while ((part = disk_part_iter_next(&piter)))
- delete_partition(bdev->bd_disk, part);
+ delete_partition(bdev->bd_disk, part->partno);
disk_part_iter_exit(&piter);
return 0;
--
2.25.1
Re: [PATCH] x86/uaccess: Use pointer masking to limit uaccess speculation
On Wed, Sep 02, 2020 at 06:23:30PM +0100, Mark Rutland wrote: > I've pushed an initial/incomplete/WIP stab (just the kernel accessors) > to: > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/set_fs-removal Thanks! > ... and doing that made it clear that the necessary arm64 rework is a > bit more fractal than I thought (e.g. SDEI bits), so it might be a short > while before I post a series. SDEI is just forcing back a KERNEL_DS to a normal USER_DS, isn't it? > > It might be handy to have a stable branch with the common bits so that > the arm64 rework could go via the arm64 tree in case there's any > fallout. The series will need at least one more repost, but hopefully I'll have s stable branch soon.
Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support
On 31-08-20, 09:41, ansuels...@gmail.com wrote: > On 31-08-20, Sibi wrote: > > On 2020-08-24 16:10, Viresh Kumar wrote: > > > +Vincent/Saravana/Sibi > > > > > > On 21-08-20, 16:00, Ansuel Smith wrote: > > >> This adds Krait Cache scaling support using the cpufreq notifier. > > >> I have some doubt about where this should be actually placed (clk or > > >> cpufreq)? > > >> Also the original idea was to create a dedicated cpufreq driver (like > > >> it's done in > > >> the codeaurora qcom repo) by copying the cpufreq-dt driver and adding > > >> the cache > > >> scaling logic but i still don't know what is better. Have a very > > >> similar driver or > > >> add a dedicated driver only for the cache using the cpufreq notifier > > >> and do the > > >> scale on every freq transition. > > >> Thanks to everyone who will review or answer these questions. > > > > > > Saravana was doing something with devfreq to solve such issues if I > > > wasn't mistaken. > > > > > > Sibi ? > > > > IIRC the final plan was to create a devfreq device > > and devfreq-cpufreq based governor to scale them, this > > way one can switch to a different governor if required. > > So in this case I should convert this patch to a devfreq driver- I think this should happen nevertheless. You are doing DVFS for a device which isn't a CPU and devfreq looks to be the right place of doing so. > Isn't overkill to use a governor for such a task? > (3 range based on the cpufreq?) I am not sure about the governor part here, maybe it won't be required ? -- viresh
Re: [PATCH] dmaengine: Mark dma_request_slave_channel() deprecated
On 28-08-20, 14:05, Peter Ujfalusi wrote: > New drivers should use dma_request_chan() instead > dma_request_slave_channel() > > dma_request_slave_channel() is a simple wrapper for dma_request_chan() > eating up the error code for channel request failure and makes deferred > probing impossible. > > Move the dma_request_slave_channel() into the header as inline function, > mark it as deprecated. Applied, thanks -- ~Vinod
Re: [PATCH v3 3/3] mm/armv6: work around armv6 cmpxchg support issue
在 2020/9/1 下午9:17, Matthew Wilcox 写道: > On Tue, Sep 01, 2020 at 02:30:51PM +0800, Alex Shi wrote: >> seems there are couples archs can not do cmpxchg1 >> So update the patch here. And it's easy to fix if more arch issue find here. > >> +/* >> + * cmpxchg only support 32-bits operands on the following archs ARMv6, >> SPARC32 >> + * sh2, XTENSA. >> + */ >> +#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_SH2) || \ >> +defined(CONFIG_SPARC32) || defined(CONFIG_XTENSA) > > Looks like we need a HAVE_CMPXCHG_BYTE in Kconfig to parallel > HAVE_CMPXCHG_DOUBLE. > Thanks for reminder! Compare the HAVE_CMPXCHG_BYTE, NO_CMPXCHG_BYTE would be better for less code change. I will send the v4 for a bit more change on patch 2. Thanks! Alex
Re: [PATCH v3 1/3] mm/pageblock: mitigation cmpxchg false sharing in pageblock flags
在 2020/9/2 上午1:06, Vlastimil Babka 写道:
>>
>>pageblock pageblock pageblockrc2 rc2
>>rc2
>> 1616-216-3 a b
>> c
>> Duration User 14.81 15.24 14.55 14.76 14.97
>> 14.38
>> Duration System84.44 88.38 90.64 100.43 89.15
>> 88.89
>> Duration Elapsed 98.83 99.06 99.81 100.30 99.24
>> 99.14
> The large variance in these numbers suggest that 3 iterations are not enough
> to
> conclude a statistically significant difference. You'd need more iterations
> and
> calculate at least mean+variance.
>
on the machine I did seeing much variation more on Amean. but the trace event
would
be more straight. It could reduce the hit_cmpxchg from thousand time to
hundreds or less.
Thanks
Alex
diff --git a/include/trace/events/pageblock.h b/include/trace/events/pageblock.h
new file mode 100644
index ..003c2d716f82
--- /dev/null
+++ b/include/trace/events/pageblock.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM pageblock
+
+#if !defined(_TRACE_PAGEBLOCK_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_PAGEBLOCK_H
+
+#include
+
+TRACE_EVENT(hit_cmpxchg,
+
+ TP_PROTO(char byte),
+
+ TP_ARGS(byte),
+
+ TP_STRUCT__entry(
+ __field(char, byte)
+ ),
+
+ TP_fast_assign(
+ __entry->byte = byte;
+ ),
+
+ TP_printk("%d", __entry->byte)
+);
+
+#endif /* _TRACE_PAGE_ISOLATION_H */
+
+/* This part must be outside protection */
+#include
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 60342e764090..2422dec00484 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -509,6 +509,9 @@ static __always_inline int get_pfnblock_migratetype(struct
page *page, unsigned
* @pfn: The target page frame number
* @mask: mask of bits that the caller is interested in
*/
+#define CREATE_TRACE_POINTS
+#include
+
void set_pfnblock_flags_mask(struct page *page, unsigned long flags,
unsigned long pfn,
unsigned long mask)
@@ -536,6 +539,7 @@ void set_pfnblock_flags_mask(struct page *page, unsigned
long flags,
if (byte == old_byte)
break;
byte = old_byte;
+ trace_hit_cmpxchg(byte);
}
}
Re: [PATCH 01/10] USB: move snd_usb_pipe_sanity_check into the USB core
On Thu, 03 Sep 2020 02:45:53 +0200,
Alan Stern wrote:
>
> In a few places here this check is completely unnecessary. All it does
> is verify that the device does have an endpoint 0 and the the type of
> the endpoint matches the type of the pipe. Well, every USB device
> always has an endpoint 0, and it is always a bidirectional control
> endpoint. Therefore a simple static check is all you need: There's no
> point calling usb_pipe_type_check() when the pipe is of the form
> usb_{snd|rcv}ctrlpipe(dev, 0).
>
> In short, this check should be removed completely; it does nothing.
Fair enough, but I think those removals should be in another patch.
thanks,
Takashi
[PATCH] cypto: mediatek - fix leaks in mtk_desc_ring_alloc
In the init loop, if an error occurs in function 'dma_alloc_coherent',
then goto the err_cleanup section,
in the cleanup loop, after run i--,
the struct mtk_ring rising[i] will not be released,
causing a memory leak
Signed-off-by: Xiaoliang Pang
---
drivers/crypto/mediatek/mtk-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/mediatek/mtk-platform.c
b/drivers/crypto/mediatek/mtk-platform.c
index 7e3ad085b5bd..05d341e4a696 100644
--- a/drivers/crypto/mediatek/mtk-platform.c
+++ b/drivers/crypto/mediatek/mtk-platform.c
@@ -469,7 +469,7 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
return 0;
err_cleanup:
- for (; i--; ) {
+ for (; i >= 0; --i) {
dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
ring[i]->res_base, ring[i]->res_dma);
dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
--
2.17.1
Re: [PATCH] mm/memory_hotplug: drain per-cpu pages again during memory offline
On Wed 02-09-20 19:51:45, Vlastimil Babka wrote: > On 9/2/20 5:13 PM, Michal Hocko wrote: > > On Wed 02-09-20 16:55:05, Vlastimil Babka wrote: > >> On 9/2/20 4:26 PM, Pavel Tatashin wrote: > >> > On Wed, Sep 2, 2020 at 10:08 AM Michal Hocko wrote: > >> >> > >> >> > > >> >> > Thread#1 - continue > >> >> > free_unref_page_commit > >> >> >migratetype = get_pcppage_migratetype(page); > >> >> > // get old migration type > >> >> >list_add(&page->lru, &pcp->lists[migratetype]); > >> >> > // add new page to already drained pcp list > >> >> > > >> >> > Thread#2 > >> >> > Never drains pcp again, and therefore gets stuck in the loop. > >> >> > > >> >> > The fix is to try to drain per-cpu lists again after > >> >> > check_pages_isolated_cb() fails. > >> >> > >> >> But this means that the page is not isolated and so it could be reused > >> >> for something else. No? > >> > > >> > The page is in a movable zone, has zero references, and the section is > >> > isolated (i.e. set_pageblock_migratetype(page, MIGRATE_ISOLATE);) is > >> > set. The page should be offlinable, but it is lost in a pcp list as > >> > that list is never drained again after the first failure to migrate > >> > all pages in the range. > >> > >> Yeah. To answer Michal's "it could be reused for something else" - yes, > >> somebody > >> could allocate it from the pcplist before we do the extra drain. But then > >> it > >> becomes "visible again" and the loop in __offline_pages() should catch it > >> by > >> scan_movable_pages() - do_migrate_range(). And this time the pageblock is > >> already marked as isolated, so the page (freed by migration) won't end up > >> on the > >> pcplist again. > > > > So the page block is marked MIGRATE_ISOLATE but the allocation itself > > could be used for non migrateable objects. Or does anything prevent that > > from happening? > > In a movable zone, the allocation should not be used for non migrateable > objects. E.g. if the zone was not ZONE_MOVABLE, the offlining could fail > regardless of this race (analogically for migrating away from CMA pageblocks). > > > We really do depend on isolation to not allow reuse when offlining. > > This is not really different than if the page on pcplist was allocated just a > moment before the offlining, thus isolation started. We ultimately rely on > being > able to migrate any allocated pages away during the isolation. This "freeing > to > pcplists" race doesn't fundamentally change anything in this regard. We just > have to guarantee that pages on pcplists will be eventually flushed, to make > forward progress, and there was a bug in this aspect. You are right. I managed to confuse myself yesterday. The race is impossible for !ZONE_MOVABLE because we do PageBuddy check there. And on the movable zone we are not losing the migrateability property. Pavel I think this will be a useful information to add to the changelog. We should also document this in the code to prevent from further confusion. I would suggest something like the following: diff --git a/mm/page_isolation.c b/mm/page_isolation.c index 242c03121d73..56d4892bceb8 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -170,6 +170,14 @@ __first_valid_page(unsigned long pfn, unsigned long nr_pages) * pageblocks we may have modified and return -EBUSY to caller. This * prevents two threads from simultaneously working on overlapping ranges. * + * Please note that there is no strong synchronization with the page allocator + * either. Pages might be freed while their page blocks are marked ISOLATED. + * In some cases pages might still end up on pcp lists and that would allow + * for their allocation even when they are in fact isolated already. Depending on + * how strong of a guarantee the caller needs drain_all_pages might be needed + * (e.g. __offline_pages will need to call it after check for isolated range for + * a next retry). + * * Return: the number of isolated pageblocks on success and -EBUSY if any part * of range cannot be isolated. */ -- Michal Hocko SUSE Labs
Re: [PATCH v2 1/2] cper, apei, mce: Pass x86 CPER through the MCA handling chain
Hi Smita,
Smita Koralahalli Channabasappa writes:
> On 8/31/20 12:05 AM, Punit Agrawal wrote:
>
>> Hi Smita,
>>
>> A couple of comments below -
>>
>> Smita Koralahalli writes:
>>
>> [...]
>>
>>
>>> diff --git a/drivers/firmware/efi/cper-x86.c
>>> b/drivers/firmware/efi/cper-x86.c
>>> index 2531de49f56c..374b8e18552a 100644
>>> --- a/drivers/firmware/efi/cper-x86.c
>>> +++ b/drivers/firmware/efi/cper-x86.c
>>> @@ -1,7 +1,7 @@
>>> // SPDX-License-Identifier: GPL-2.0
>>> // Copyright (C) 2018, Advanced Micro Devices, Inc.
>>> -#include
>> Why is the include dropped? AFAICT, the definitions from there are still
>> being used after this patch.
>
> Dropped because already includes
Generally, you want to follow the rule that if a declaration from a
header file is being used, it should show up in the includes. The same
applies to both source as well as header files.
It doesn't matter if another include in the source file in turn ends up
including the same header again; the #ifdef guards are there to prevent
duplicate declarations.
The rationale is that if future changes remove the usage of
, the C file can still be compiled after dropping the
include; there should be no need to then re-introduce at
that point.
Hope that makes sense.
Thanks,
Punit
>>> +#include
>
> [...]
>
>>> diff --git a/include/acpi/apei.h b/include/acpi/apei.h
>>> index 680f80960c3d..44d4d08acce0 100644
>>> --- a/include/acpi/apei.h
>>> +++ b/include/acpi/apei.h
>>> @@ -33,8 +33,15 @@ extern bool ghes_disable;
>>> #ifdef CONFIG_ACPI_APEI
>>> void __init acpi_hest_init(void);
>>> +int arch_apei_report_x86_error(struct cper_ia_proc_ctx *ctx_info,
>>> + u64 lapic_id);
>>> #else
>>> static inline void acpi_hest_init(void) { return; }
>>> +static inline int arch_apei_report_x86_error(struct cper_ia_proc_ctx
>>> *ctx_info,
>>> +u64 lapic_id)
>>> +{
>>> + return -EINVAL;
>>> +}
>>> #endif
>> Adding the declaration to this include violates the separation of
>> generic and architecture specific code.
>>
>> Can this be moved to the appropriate architecture specific header?
>> Perhaps arch/x86/include/asm/apei.h.
>
> Yes, I have fixed this and moved into arch/x86/include/asm/acpi.h.
>
>>> typedef int (*apei_hest_func_t)(struct acpi_hest_header *hest_hdr, void
>>> *data);
>>> @@ -51,6 +58,8 @@ int erst_clear(u64 record_id);
>>> int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr,
>>> void *data);
>>> void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err
>>> *mem_err);
>>> +int arch_apei_report_x86_error(struct cper_ia_proc_ctx *ctx_info,
>>> + u64 lapic_id);
>>
>> Why is the additional declaration needed?
>
> Will fix in the next revision.
>
> Thanks,
> Smita
>
> [...]
[PATCH v2 3/6] clk: rockchip: Export rockchip_register_softrst()
This is used by the Rockchip clk driver, export it to allow that
driver to be compiled as a module..
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/softrst.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/rockchip/softrst.c b/drivers/clk/rockchip/softrst.c
index 5f1ff5e47c4f..caba9055090b 100644
--- a/drivers/clk/rockchip/softrst.c
+++ b/drivers/clk/rockchip/softrst.c
@@ -77,9 +77,9 @@ static const struct reset_control_ops rockchip_softrst_ops = {
.deassert = rockchip_softrst_deassert,
};
-void __init rockchip_register_softrst(struct device_node *np,
- unsigned int num_regs,
- void __iomem *base, u8 flags)
+void rockchip_register_softrst(struct device_node *np,
+ unsigned int num_regs,
+ void __iomem *base, u8 flags)
{
struct rockchip_softrst *softrst;
int ret;
@@ -107,3 +107,4 @@ void __init rockchip_register_softrst(struct device_node
*np,
kfree(softrst);
}
};
+EXPORT_SYMBOL(rockchip_register_softrst);
--
2.17.1
[PATCH v2 4/6] clk: rockchip: Export some clock common APIs for module drivers
This is used by the Rockchip clk driver, export it to allow that
driver to be compiled as a module.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk.c | 52 ++
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index b51f320e5733..b7664224e64a 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -359,8 +359,9 @@ static struct clk
*rockchip_clk_register_factor_branch(const char *name,
return hw->clk;
}
-struct rockchip_clk_provider * __init rockchip_clk_init(struct device_node *np,
- void __iomem *base, unsigned long nr_clks)
+struct rockchip_clk_provider *rockchip_clk_init(struct device_node *np,
+ void __iomem *base,
+ unsigned long nr_clks)
{
struct rockchip_clk_provider *ctx;
struct clk **clk_table;
@@ -392,14 +393,16 @@ struct rockchip_clk_provider * __init
rockchip_clk_init(struct device_node *np,
kfree(ctx);
return ERR_PTR(-ENOMEM);
}
+EXPORT_SYMBOL(rockchip_clk_init);
-void __init rockchip_clk_of_add_provider(struct device_node *np,
- struct rockchip_clk_provider *ctx)
+void rockchip_clk_of_add_provider(struct device_node *np,
+ struct rockchip_clk_provider *ctx)
{
if (of_clk_add_provider(np, of_clk_src_onecell_get,
&ctx->clk_data))
pr_err("%s: could not register clk provider\n", __func__);
}
+EXPORT_SYMBOL(rockchip_clk_of_add_provider);
void rockchip_clk_add_lookup(struct rockchip_clk_provider *ctx,
struct clk *clk, unsigned int id)
@@ -407,8 +410,9 @@ void rockchip_clk_add_lookup(struct rockchip_clk_provider
*ctx,
if (ctx->clk_data.clks && id)
ctx->clk_data.clks[id] = clk;
}
+EXPORT_SYMBOL(rockchip_clk_add_lookup);
-void __init rockchip_clk_register_plls(struct rockchip_clk_provider *ctx,
+void rockchip_clk_register_plls(struct rockchip_clk_provider *ctx,
struct rockchip_pll_clock *list,
unsigned int nr_pll, int grf_lock_offset)
{
@@ -431,11 +435,11 @@ void __init rockchip_clk_register_plls(struct
rockchip_clk_provider *ctx,
rockchip_clk_add_lookup(ctx, clk, list->id);
}
}
+EXPORT_SYMBOL(rockchip_clk_register_plls);
-void __init rockchip_clk_register_branches(
- struct rockchip_clk_provider *ctx,
- struct rockchip_clk_branch *list,
- unsigned int nr_clk)
+void rockchip_clk_register_branches(struct rockchip_clk_provider *ctx,
+ struct rockchip_clk_branch *list,
+ unsigned int nr_clk)
{
struct clk *clk = NULL;
unsigned int idx;
@@ -564,14 +568,15 @@ void __init rockchip_clk_register_branches(
rockchip_clk_add_lookup(ctx, clk, list->id);
}
}
-
-void __init rockchip_clk_register_armclk(struct rockchip_clk_provider *ctx,
- unsigned int lookup_id,
- const char *name, const char *const *parent_names,
- u8 num_parents,
- const struct rockchip_cpuclk_reg_data *reg_data,
- const struct rockchip_cpuclk_rate_table *rates,
- int nrates)
+EXPORT_SYMBOL(rockchip_clk_register_branches);
+
+void rockchip_clk_register_armclk(struct rockchip_clk_provider *ctx,
+ unsigned int lookup_id,
+ const char *name, const char *const
*parent_names,
+ u8 num_parents,
+ const struct rockchip_cpuclk_reg_data
*reg_data,
+ const struct rockchip_cpuclk_rate_table
*rates,
+ int nrates)
{
struct clk *clk;
@@ -586,9 +591,10 @@ void __init rockchip_clk_register_armclk(struct
rockchip_clk_provider *ctx,
rockchip_clk_add_lookup(ctx, clk, lookup_id);
}
+EXPORT_SYMBOL(rockchip_clk_register_armclk);
-void __init rockchip_clk_protect_critical(const char *const clocks[],
- int nclocks)
+void rockchip_clk_protect_critical(const char *const clocks[],
+ int nclocks)
{
int i;
@@ -600,6 +606,7 @@ void __init rockchip_clk_protect_critical(const char *const
clocks[],
clk_prepare_enable(clk);
}
}
+EXPORT_SYMBOL(rockchip_clk_protect_critical);
static void __iomem *rst_base;
static unsigned int reg_restart;
@@ -619,10 +626,10 @@ static struct notifier_block rockchip_restart_handler = {
.priority = 128,
[PATCH v2 1/6] clk: rockchip: Use clk_hw_register_composite instead of clk_register_composite calls
clk_hw_register_composite it's already exported.
Preparation for compilation of rK common clock drivers into modules.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-half-divider.c | 18
drivers/clk/rockchip/clk.c | 58 -
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/clk/rockchip/clk-half-divider.c
b/drivers/clk/rockchip/clk-half-divider.c
index b333fc28c94b..e97fd3dfbae7 100644
--- a/drivers/clk/rockchip/clk-half-divider.c
+++ b/drivers/clk/rockchip/clk-half-divider.c
@@ -166,7 +166,7 @@ struct clk *rockchip_clk_register_halfdiv(const char *name,
unsigned long flags,
spinlock_t *lock)
{
- struct clk *clk;
+ struct clk_hw *hw;
struct clk_mux *mux = NULL;
struct clk_gate *gate = NULL;
struct clk_divider *div = NULL;
@@ -212,16 +212,18 @@ struct clk *rockchip_clk_register_halfdiv(const char
*name,
div_ops = &clk_half_divider_ops;
}
- clk = clk_register_composite(NULL, name, parent_names, num_parents,
-mux ? &mux->hw : NULL, mux_ops,
-div ? &div->hw : NULL, div_ops,
-gate ? &gate->hw : NULL, gate_ops,
-flags);
+ hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
+ mux ? &mux->hw : NULL, mux_ops,
+ div ? &div->hw : NULL, div_ops,
+ gate ? &gate->hw : NULL, gate_ops,
+ flags);
+ if (IS_ERR(hw))
+ goto err_div;
- return clk;
+ return hw->clk;
err_div:
kfree(gate);
err_gate:
kfree(mux);
- return ERR_PTR(-ENOMEM);
+ return ERR_CAST(hw);
}
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 546e810c3560..b51f320e5733 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -43,7 +43,7 @@ static struct clk *rockchip_clk_register_branch(const char
*name,
u8 gate_shift, u8 gate_flags, unsigned long flags,
spinlock_t *lock)
{
- struct clk *clk;
+ struct clk_hw *hw;
struct clk_mux *mux = NULL;
struct clk_gate *gate = NULL;
struct clk_divider *div = NULL;
@@ -100,25 +100,22 @@ static struct clk *rockchip_clk_register_branch(const
char *name,
: &clk_divider_ops;
}
- clk = clk_register_composite(NULL, name, parent_names, num_parents,
-mux ? &mux->hw : NULL, mux_ops,
-div ? &div->hw : NULL, div_ops,
-gate ? &gate->hw : NULL, gate_ops,
-flags);
-
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
+ mux ? &mux->hw : NULL, mux_ops,
+ div ? &div->hw : NULL, div_ops,
+ gate ? &gate->hw : NULL, gate_ops,
+ flags);
+ if (IS_ERR(hw))
goto err_composite;
- }
- return clk;
+ return hw->clk;
err_composite:
kfree(div);
err_div:
kfree(gate);
err_gate:
kfree(mux);
- return ERR_PTR(ret);
+ return ERR_CAST(hw);
}
struct rockchip_clk_frac {
@@ -214,8 +211,8 @@ static struct clk *rockchip_clk_register_frac_branch(
unsigned long flags, struct rockchip_clk_branch *child,
spinlock_t *lock)
{
+ struct clk_hw *hw;
struct rockchip_clk_frac *frac;
- struct clk *clk;
struct clk_gate *gate = NULL;
struct clk_fractional_divider *div = NULL;
const struct clk_ops *div_ops = NULL, *gate_ops = NULL;
@@ -255,14 +252,14 @@ static struct clk *rockchip_clk_register_frac_branch(
div->approximation = rockchip_fractional_approximation;
div_ops = &clk_fractional_divider_ops;
- clk = clk_register_composite(NULL, name, parent_names, num_parents,
-NULL, NULL,
-&div->hw, div_ops,
-gate ? &gate->hw : NULL, gate_ops,
-flags | CLK_SET_RATE_UNGATE);
- if (IS_ERR(clk)) {
+ hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
+ NULL, NULL,
+ &div->hw, div_ops,
+ gate ? &gate->hw : NULL, gate_ops,
+ flags | CLK_SET_RAT
[PATCH v2 6/6] clk: rockchip: rk3399: Support module build
support CLK_OF_DECLARE and builtin_platform_driver_probe
double clk init method.
add module author, description and license to support building
Soc Rk3399 clock driver as module.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rk3399.c | 55 +++
1 file changed, 55 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index ce1d2446f142..40ff17aee5b6 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -5,9 +5,11 @@
*/
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -1600,3 +1602,56 @@ static void __init rk3399_pmu_clk_init(struct
device_node *np)
rockchip_clk_of_add_provider(np, ctx);
}
CLK_OF_DECLARE(rk3399_cru_pmu, "rockchip,rk3399-pmucru", rk3399_pmu_clk_init);
+
+struct clk_rk3399_inits {
+ void (*inits)(struct device_node *np);
+};
+
+static const struct clk_rk3399_inits clk_rk3399_pmucru_init = {
+ .inits = rk3399_pmu_clk_init,
+};
+
+static const struct clk_rk3399_inits clk_rk3399_cru_init = {
+ .inits = rk3399_clk_init,
+};
+
+static const struct of_device_id clk_rk3399_match_table[] = {
+ {
+ .compatible = "rockchip,rk3399-cru",
+ .data = &clk_rk3399_cru_init,
+ }, {
+ .compatible = "rockchip,rk3399-pmucru",
+ .data = &clk_rk3399_pmucru_init,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, clk_rk3399_match_table);
+
+static int __init clk_rk3399_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ const struct clk_rk3399_inits *init_data;
+
+ match = of_match_device(clk_rk3399_match_table, &pdev->dev);
+ if (!match || !match->data)
+ return -EINVAL;
+
+ init_data = match->data;
+ if (init_data->inits)
+ init_data->inits(np);
+
+ return 0;
+}
+
+static struct platform_driver clk_rk3399_driver = {
+ .driver = {
+ .name = "clk-rk3399",
+ .of_match_table = clk_rk3399_match_table,
+ },
+};
+builtin_platform_driver_probe(clk_rk3399_driver, clk_rk3399_probe);
+
+MODULE_DESCRIPTION("Rockchip RK3399 Clock Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:clk-rk3399");
--
2.17.1
[PATCH v2 2/6] clk: rockchip: Export rockchip_clk_register_ddrclk()
This is used by the Rockchip clk driver, export it to allow that driver to be compiled as a module.. Signed-off-by: Elaine Zhang --- drivers/clk/rockchip/clk-ddr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c index 9273bce4d7b6..282b6f22eb22 100644 --- a/drivers/clk/rockchip/clk-ddr.c +++ b/drivers/clk/rockchip/clk-ddr.c @@ -136,3 +136,4 @@ struct clk *rockchip_clk_register_ddrclk(const char *name, int flags, return clk; } +EXPORT_SYMBOL(rockchip_clk_register_ddrclk); -- 2.17.1
[PATCH v2 0/6] clk: rockchip: Support module build
Export some APIs for module drivers. Fix the clock config to support module build. Fix the clk driver init, add module author, description and license to support building RK3399 SoC clock driver as module. Change in V2: [PATCH v2 1/6]: remove "clk",and check "hw" isn't an error value. [PATCH v2 6/6]: store a function pointer in the match data. Elaine Zhang (6): clk: rockchip: Use clk_hw_register_composite instead of clk_register_composite calls clk: rockchip: Export rockchip_clk_register_ddrclk() clk: rockchip: Export rockchip_register_softrst() clk: rockchip: Export some clock common APIs for module drivers clk: rockchip: fix the clk config to support module build clk: rockchip: rk3399: Support module build drivers/clk/Kconfig | 1 + drivers/clk/rockchip/Kconfig| 78 + drivers/clk/rockchip/Makefile | 42 - drivers/clk/rockchip/clk-ddr.c | 1 + drivers/clk/rockchip/clk-half-divider.c | 18 ++-- drivers/clk/rockchip/clk-rk3399.c | 55 drivers/clk/rockchip/clk.c | 110 +--- drivers/clk/rockchip/softrst.c | 7 +- 8 files changed, 229 insertions(+), 83 deletions(-) create mode 100644 drivers/clk/rockchip/Kconfig -- 2.17.1
[PATCH v2 5/6] clk: rockchip: fix the clk config to support module build
use CONFIG_COMMON_CLK_ROCKCHIP for Rk common clk drivers. use CONFIG_CLK_RKXX for Rk soc clk driver. Mark configuration to "tristate", to support building Rk SoCs clock driver as module. Signed-off-by: Elaine Zhang --- drivers/clk/Kconfig | 1 + drivers/clk/rockchip/Kconfig | 78 +++ drivers/clk/rockchip/Makefile | 42 ++- 3 files changed, 101 insertions(+), 20 deletions(-) create mode 100644 drivers/clk/rockchip/Kconfig diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 4026fac9fac3..b41aaed9bd51 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -373,6 +373,7 @@ source "drivers/clk/meson/Kconfig" source "drivers/clk/mvebu/Kconfig" source "drivers/clk/qcom/Kconfig" source "drivers/clk/renesas/Kconfig" +source "drivers/clk/rockchip/Kconfig" source "drivers/clk/samsung/Kconfig" source "drivers/clk/sifive/Kconfig" source "drivers/clk/sprd/Kconfig" diff --git a/drivers/clk/rockchip/Kconfig b/drivers/clk/rockchip/Kconfig new file mode 100644 index ..53a44396bc35 --- /dev/null +++ b/drivers/clk/rockchip/Kconfig @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 +# common clock support for ROCKCHIP SoC family. + +config COMMON_CLK_ROCKCHIP + tristate "Rockchip clock controller common support" + depends on ARCH_ROCKCHIP + default ARCH_ROCKCHIP + help + Say y here to enable common clock controller. + +if COMMON_CLK_ROCKCHIP +config CLK_PX30 + tristate "Rockchip Px30 clock controller support" + default y + help + Build the driver for Px30 Clock Driver. + +config CLK_RV110X + tristate "Rockchip Rv110x clock controller support" + default y + help + Build the driver for Rv110x Clock Driver. + +config CLK_RK3036 + tristate "Rockchip Rk3036 clock controller support" + default y + help + Build the driver for Rk3036 Clock Driver. + +config CLK_RK312X + tristate "Rockchip Rk312x clock controller support" + default y + help + Build the driver for Rk312x Clock Driver. + +config CLK_RK3188 + tristate "Rockchip Rk3188 clock controller support" + default y + help + Build the driver for Rk3188 Clock Driver. + +config CLK_RK322X + tristate "Rockchip Rk322x clock controller support" + default y + help + Build the driver for Rk322x Clock Driver. + +config CLK_RK3288 + tristate "Rockchip Rk3288 clock controller support" + depends on ARM + default y + help + Build the driver for Rk3288 Clock Driver. + +config CLK_RK3308 + tristate "Rockchip Rk3308 clock controller support" + default y + help + Build the driver for Rk3308 Clock Driver. + +config CLK_RK3328 + tristate "Rockchip Rk3328 clock controller support" + default y + help + Build the driver for Rk3328 Clock Driver. + +config CLK_RK3368 + tristate "Rockchip Rk3368 clock controller support" + default y + help + Build the driver for Rk3368 Clock Driver. + +config CLK_RK3399 + tristate "Rockchip Rk3399 clock controller support" + default y + help + Build the driver for Rk3399 Clock Driver. +endif diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile index 7c5b5813a87c..a99e4d9bbae1 100644 --- a/drivers/clk/rockchip/Makefile +++ b/drivers/clk/rockchip/Makefile @@ -3,24 +3,26 @@ # Rockchip Clock specific Makefile # -obj-y += clk.o -obj-y += clk-pll.o -obj-y += clk-cpu.o -obj-y += clk-half-divider.o -obj-y += clk-inverter.o -obj-y += clk-mmc-phase.o -obj-y += clk-muxgrf.o -obj-y += clk-ddr.o -obj-$(CONFIG_RESET_CONTROLLER) += softrst.o +obj-$(CONFIG_COMMON_CLK_ROCKCHIP) += clk-rockchip.o -obj-y += clk-px30.o -obj-y += clk-rv1108.o -obj-y += clk-rk3036.o -obj-y += clk-rk3128.o -obj-y += clk-rk3188.o -obj-y += clk-rk3228.o -obj-y += clk-rk3288.o -obj-y += clk-rk3308.o -obj-y += clk-rk3328.o -obj-y += clk-rk3368.o -obj-y += clk-rk3399.o +clk-rockchip-y += clk.o +clk-rockchip-y += clk-pll.o +clk-rockchip-y += clk-cpu.o +clk-rockchip-y += clk-half-divider.o +clk-rockchip-y += clk-inverter.o +clk-rockchip-y += clk-mmc-phase.o +clk-rockchip-y += clk-muxgrf.o +clk-rockchip-y += clk-ddr.o +clk-rockchip-$(CONFIG_RESET_CONTROLLER) += softrst.o + +obj-$(CONFIG_CLK_PX30) += clk-px30.o +obj-$(CONFIG_CLK_RV110X)+= clk-rv1108.o +obj-$(CONFIG_CLK_RK3036)+= clk-rk3036.o +obj-$(CONFIG_CLK_RK312X)+= clk-rk3128.o +obj-$(CONFIG_CLK_RK3188)+= clk-rk3188.o +obj-$(CONFIG_CLK_RK322X)+= clk-rk3228.o +obj-$(CONFIG_CLK_RK3288)+= clk-rk3288.o +obj-$(CONFIG_CLK_RK3308)+= clk-rk3308.o +obj-$(CONFIG_CLK_RK3328)+= clk-rk3328.o +obj-$(CONFIG_CLK_RK3368)+= clk-rk3368.o +obj-$(CONFIG_CLK_RK3399)+= clk-rk3399.o -- 2.17.1
Re: [PATCH V3 3/3] media: i2c: gc5035: Add GC5035 image sensor driver
Hi Tomasz,
On Thu, Sep 03, 2020 at 12:59:20AM +0200, Tomasz Figa wrote:
> Hi Sakari,
>
> On Mon, Aug 31, 2020 at 7:41 PM Sakari Ailus
> wrote:
> >
> > Hi Xingyu,
> >
> > Thanks for the update. I've got a few more comments below.
> >
> > Do you happen to have some insight on what the OTP data contains and what
> > does the driver do with it?
> >
> > At least in principle the OTP data may be programmed for the customer so
> > the same sensor could contain something else what the driver expects to
> > find there.
> >
>
> Thanks for the review. For anything without my reply, assume fixed. :)
>
> As far as I can see, the data is being read from an area that is
> supposed to be reserved for Galaxycore, so I'd assume it doesn't
> depend on the customer.
Sounds good.
>
> [snip]
> > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > index da11036..aeaf594 100644
> > > --- a/drivers/media/i2c/Kconfig
> > > +++ b/drivers/media/i2c/Kconfig
> > > @@ -712,6 +712,18 @@ config VIDEO_APTINA_PLL
> > > config VIDEO_SMIAPP_PLL
> > > tristate
> > >
> > > +config VIDEO_GC5035
> > > + tristate "Galaxycore GC5035 sensor support"
> > > + depends on I2C && VIDEO_V4L2
> > > + select MEDIA_CONTROLLER
> > > + select VIDEO_V4L2_SUBDEV_API
> >
> > Add:
> >
> > V4L2_FWNODE
> > OF
>
> This driver doesn't depend on OF. It uses the firmware-independent
> property access API. (v4 I sent actually uses device_property_*()).
Yes, this is even better.
>
> [snip]
> > > +static int __gc5035_power_on(struct gc5035 *gc5035)
> > > +{
> > > + struct device *dev = &gc5035->client->dev;
> > > + int i, ret;
> > > +
> > > + ret = clk_prepare_enable(gc5035->xvclk);
> > > + if (ret < 0) {
> > > + dev_err(dev, "Failed to enable xvclk\n");
> > > + return ret;
> > > + }
> > > +
> > > + gpiod_set_value_cansleep(gc5035->reset_gpio, 1);
> > > +
> > > + for (i = 0; i < GC5035_NUM_SUPPLIES; i++) {
> > > + ret = regulator_enable(gc5035->supplies[i].consumer);
> > > + if (ret) {
> > > + dev_err(dev, "Failed to enable %s: %d\n",
> > > + gc5035->supplies[i].supply, ret);
> > > + goto disable_reg_clk;
> >
> > Please use regulator_bulk_enable() here, and regulator_bulk_disable()
> > below.
> >
>
> This actually needs to have one of the regulators (iovdd) enabled
> before the other ones, but regulator_bulk_enable() is async. In v4 I
> used regulator_enable() for iovdd and regulator_bulk_enable() for the
> other two for optimal sequencing.
Ack.
--
Sakari Ailus
RE: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Tomi, >-Original Message- >From: Tomi Valkeinen >Sent: Tuesday, September 1, 2020 2:05 PM >To: Swapnil Kashinath Jakhade ; airl...@linux.ie; >dan...@ffwll.ch; laurent.pinch...@ideasonboard.com; robh...@kernel.org; >a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se; >jernej.skra...@siol.net; dri-de...@lists.freedesktop.org; >devicet...@vger.kernel.org; linux-kernel@vger.kernel.org >Cc: Milind Parab ; Yuti Suresh Amonkar >; jsa...@ti.com; nsek...@ti.com; >prane...@ti.com; nikhil...@ti.com >Subject: Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 >DPI/DP bridge > >EXTERNAL MAIL > > >Hi Swapnil, > >On 31/08/2020 11:23, Swapnil Jakhade wrote: > >> +line_thresh1 = ((vs + 1) << 5) * 8 / bpp; >> +line_thresh2 = (pxlclock << 5) / 1000 / rate * (vs + 1) - (1 << 5); >> +line_thresh = line_thresh1 - line_thresh2 / mhdp->link.num_lanes; >> +line_thresh = (line_thresh >> 5) + 2; > >These calculations do not seem to go correctly. There's no comment what's >the logic here, but e.g. >for 640x480 (pxlclock 31500) with 1.62Gbps link, I get vs=4, and then the >second line above comes to: > >(31500 << 5) / 1000 / 162 * (4+1) - (1<<5) = -0.8893 > >The result is line_thresh of 100663299. > Yes, there is a mistake in the above equations. I will detailed it here Before that there are other related issues which also needs clarification First is about the TU_SIZE. The DP spec says, in SST mode the TU_SIZE can take any even value from 32 to 64. The advantages of having a smaller TU size is not explicitly mentioned, however logically it helps stream down-spreading and would be beneficial in low bandwidth low buffer applications. Hence, we can consider that selecting a lower TU size is an optimization we can consider implementing later. For now let us fix TU_SIZE = 64 Second, is Valid Symbol Length "vs" For a fixed TU valid symbol length will depend in the Ratio or Pixel clock and Link symbol Rate (lanes * rate) vs = 64 * required_bandwidth / available_bandwidth Where, required_bandwidth = pxlclock * (bpp/8) available_bandwidth = mhdp->link.num_lanes * mhdp->link.rate Also, note that CDNS MHDP implements DP_FRAMER_TU_p where bits 5:0 is tu_valid_symbols. So max programmable value is 63. Register document gives following explanation "Number of valid symbols per Transfer Unit (TU). Rounded down to lower integer value (Allowed values are 1 to (TU_size-1)" So, it says in case vs calculates to 64 (where Avail BW and Req BW are same) we program tu_valid_symbols = 63 Third, is about the line_threshold calculation Unlike TU_SIZE and Valid_Symbols, line_threshold is implementation dependent CDNS MHDP register specs gives the definition as " Video FIFO latency threshold" Bits 5:0, Name "cfg_active_line_tresh", Description "Video Fifo Latency threshold. Defines the number of FIFO rows before reading starts. This setting depends on the transmitted video format and link rate." This parameter is the Threshold of the FIFO. For optimal performance (considering equal write and read clock) we normally put the threshold in the mid of the FIFO. Hence the reset value is fixed as 32. Since symbol FIFO is accessed by Pxl clock and Symbol Link Clock the Threshold is set to a value which is dependent on the ratio of these clocks line_threshold = full_fifo - fifo_ratio_due_to_clock_diff + 2 where, full_fifo = (vs+1) * (8/bpp) fifo_ratio_due_to_clock_diff = ((vs+1) * pxlclock/mhdp->link.rate - 1) / mhdp->link.num_lanes Note that line_threshold can take a max value of 63 > Tomi > >-- >Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 4/4] perf vendor events amd: Enable Family 19h users by matching Zen2 events
On Tue, Sep 1, 2020 at 3:10 PM Kim Phillips wrote: > > This enables zen3 users by reusing mostly-compatible zen2 events > until the official public list of zen3 events is published in a > future PPR. > > Signed-off-by: Kim Phillips Acked-by: Ian Rogers Thanks! Ian > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Arnaldo Carvalho de Melo > Cc: Mark Rutland > Cc: Alexander Shishkin > Cc: Jiri Olsa > Cc: Namhyung Kim > Cc: Vijay Thakkar > Cc: Andi Kleen > Cc: John Garry > Cc: Kan Liang > Cc: Yunfeng Ye > Cc: Jin Yao > Cc: "Martin Liška" > Cc: Borislav Petkov > Cc: Jon Grimm > Cc: Martin Jambor > Cc: Michael Petlan > Cc: William Cohen > Cc: Stephane Eranian > Cc: Ian Rogers > Cc: linux-perf-us...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > tools/perf/pmu-events/arch/x86/mapfile.csv | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv > b/tools/perf/pmu-events/arch/x86/mapfile.csv > index 25b06cf98747..2f2a209e87e1 100644 > --- a/tools/perf/pmu-events/arch/x86/mapfile.csv > +++ b/tools/perf/pmu-events/arch/x86/mapfile.csv > @@ -38,3 +38,4 @@ GenuineIntel-6-7E,v1,icelake,core > GenuineIntel-6-86,v1,tremontx,core > AuthenticAMD-23-([12][0-9A-F]|[0-9A-F]),v2,amdzen1,core > AuthenticAMD-23-[[:xdigit:]]+,v1,amdzen2,core > +AuthenticAMD-25-[[:xdigit:]]+,v1,amdzen2,core > -- > 2.27.0 >
Re: [PATCH 3/4] perf vendor events amd: Add recommended events
On Tue, Sep 1, 2020 at 3:10 PM Kim Phillips wrote:
>
> Add support for events listed in Section 2.1.15.2 "Performance
> Measurement" of "PPR for AMD Family 17h Model 31h B0 - 55803
> Rev 0.54 - Sep 12, 2019".
>
> perf now supports these new events (-e):
>
> all_dc_accesses
> all_tlbs_flushed
> l1_dtlb_misses
> l2_cache_accesses_from_dc_misses
> l2_cache_accesses_from_ic_misses
> l2_cache_hits_from_dc_misses
> l2_cache_hits_from_ic_misses
> l2_cache_misses_from_dc_misses
> l2_cache_misses_from_ic_miss
> l2_dtlb_misses
> l2_itlb_misses
> sse_avx_stalls
> uops_dispatched
> uops_retired
> l3_accesses
> l3_misses
>
> and these metrics (-M):
>
> branch_misprediction_ratio
> all_l2_cache_accesses
> all_l2_cache_hits
> all_l2_cache_misses
> ic_fetch_miss_ratio
> l2_cache_accesses_from_l2_hwpf
> l2_cache_hits_from_l2_hwpf
> l2_cache_misses_from_l2_hwpf
> l3_read_miss_latency
> l1_itlb_misses
> all_remote_links_outbound
> nps1_die_to_dram
>
> The nps1_die_to_dram event may need perf stat's --metric-no-group
> switch if the number of available data fabric counters is less
> than the number it uses (8).
These are really excellent additions! Does:
"MetricConstraint": "NO_NMI_WATCHDOG"
solve the grouping issue? Perhaps the MetricConstraint needs to be
named more generically to cover this case as it seems sub-optimal to
require the use of --metric-no-group.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
> Signed-off-by: Kim Phillips
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Mark Rutland
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Vijay Thakkar
> Cc: Andi Kleen
> Cc: John Garry
> Cc: Kan Liang
> Cc: Yunfeng Ye
> Cc: Jin Yao
> Cc: "Martin Liška"
> Cc: Borislav Petkov
> Cc: Jon Grimm
> Cc: Martin Jambor
> Cc: Michael Petlan
> Cc: William Cohen
> Cc: Stephane Eranian
> Cc: Ian Rogers
> Cc: linux-perf-us...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> .../pmu-events/arch/x86/amdzen1/cache.json| 23 +++
> .../arch/x86/amdzen1/data-fabric.json | 98 ++
> .../arch/x86/amdzen1/recommended.json | 178 ++
> .../pmu-events/arch/x86/amdzen2/cache.json| 23 +++
> .../arch/x86/amdzen2/data-fabric.json | 98 ++
> .../arch/x86/amdzen2/recommended.json | 178 ++
> tools/perf/pmu-events/jevents.c | 1 +
> 7 files changed, 599 insertions(+)
> create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
> create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/recommended.json
> create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/data-fabric.json
> create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/recommended.json
>
> diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> index 695ed3ffa3a6..4ea7ec4f496e 100644
> --- a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> +++ b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> @@ -117,6 +117,11 @@
> "BriefDescription": "Miscellaneous events covered in more detail by
> l2_request_g2 (PMCx061).",
> "UMask": "0x1"
>},
> + {
> +"EventName": "l2_request_g1.all_no_prefetch",
> +"EventCode": "0x60",
> +"UMask": "0xf9"
> + },
Would it be possible to have a BriefDescription here?
>{
> "EventName": "l2_request_g2.group1",
> "EventCode": "0x61",
> @@ -243,6 +248,24 @@
> "BriefDescription": "Core to L2 cacheable request access status (not
> including L2 Prefetch). Instruction cache request miss in L2.",
> "UMask": "0x1"
>},
> + {
> +"EventName": "l2_cache_req_stat.ic_access_in_l2",
> +"EventCode": "0x64",
> +"BriefDescription": "Core to L2 cacheable request access status (not
> including L2 Prefetch). Instruction cache requests in L2.",
> +"UMask": "0x7"
> + },
> + {
> +"EventName": "l2_cache_req_stat.ic_dc_miss_in_l2",
> +"EventCode": "0x64",
> +"BriefDescription": "Core to L2 cacheable request access status (not
> including L2 Prefetch). Instruction cache request miss in L2 and Data cache
> request miss in L2 (all types).",
> +"UMask": "0x9"
> + },
> + {
> +"EventName": "l2_cache_req_stat.ic_dc_hit_in_l2",
> +"EventCode": "0x64",
> +"BriefDescription": "Core to L2 cacheable request access status (not
> including L2 Prefetch). Instruction cache request hit in L2 and Data cache
> request hit in L2 (all types).",
> +"UMask": "0xf6"
> + },
>{
> "EventName": "l2_fill_pending.l2_fill_busy",
> "EventCode": "0x6d",
> diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
> b/tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
> new file mode 100644
> index ..40271df40015
> --- /dev/null
> +++ b/tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
> @@ -0,0 +1,98 @@
> +[
> + {
>
Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
On Thu, Sep 03, 2020 at 08:04:44AM +0200, John Paul Adrian Glaubitz wrote: > On 9/3/20 7:46 AM, Rich Felker wrote: > > > > OK, I think I have an explanation for the mechanism of the bug, and it > > really is a combination of the 2008 bug (confusion of r0 vs r3) and > > the SECCOMP_FILTER commit. When the syscall_trace_entry code path is > > in use, a syscall with argument 5 having value -1 causes > > do_syscall_trace_enter to return -1 (because it returns regs[0], which > > contains argument 5), which the change in entry-common.S interprets as > > a sign to skip the syscall and jump to syscall_exit, and things blow > > up from there. In particular, SYS_mmap2 is almost always called with > > -1 as the 5th argument (fd), and this is even more common on nommu > > where SYS_brk does not work. > > > > I'll follow up with a new proposed patch. > > I'm not sure whether we need another revision of your first patch. Your > previous analysis was at least right regarding the tests 51 and 58 > but those have been fixed now. > > But there were two other tests failing, weren't there? > > I have to recheck later, I just got up (it's 8 AM CEST). The first patch was surely not right; setting syscall_nr to -1 and letting it -ENOSYS clobbered any return value set by the seccomp filters. The one I've sent now should be right. I'll follow up after testing with libseccomp test cases. Rich
Re: [PATCH] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/3 下午1:34, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the i2c msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
May I know the reason why don't you use i2c or virtio directly?
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Is there a link to the spec patch?
Thanks
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed-by: Shuo Liu
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 276
include/uapi/linux/virtio_ids.h | 1 +
4 files changed, 291 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0..70c8e30 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ depends on VIRTIO
+ help
+ If you say yes to this option, support will be included for the virtio
+ i2c adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 19aff0e..821acfa 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI)+= i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..47f9fd1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define VIRTIO_I2C_MSG_OK 0
+#define VIRTIO_I2C_MSG_ERR 1
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __virtio16 addr;
+ __virtio16 flags;
+ __virtio16 len;
+} __packed;
+
+/**
+ * struct virtio_i2c_msg - the virtio I2C message structure
+ * @hdr: the virtio I2C message header
+ * @buf: virtio I2C message data buffer
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_msg {
+ struct virtio_i2c_hdr hdr;
+ char *buf;
+ u8 status;
+};
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(&vi->completion);
+}
+
+static int virtio_i2c_add_msg(struct virtqueue *vq,
+ struct virtio_i2c_msg *vmsg,
+ struct i2c_msg *msg)
+{
+ struct scatterlist *sgs[3], hdr, bout, bin, status;
+ int outcnt = 0, incnt = 0;
+
+ if (!msg->len)
+ return -EINVAL;
+
+ vmsg->hdr.addr = msg->addr;
+ vmsg->hdr.flags = msg->flags;
+ vmsg->hdr.len = msg->len;
+
+ vmsg->buf = kzalloc(vmsg->hdr.len, GFP_KERNEL);
+ if (!vmsg->buf)
+ return
[GIT PULL for v5.9-rc4] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.9-2 For: - a compilation fix issue with ti-vpe on arm 32 bits; - two Kconfig fixes for imx214 and max9286 drivers; - a kernel information leak at v4l2-core on time32 compat ioctls; - some fixes at rc core unbind logic; - a fix at mceusb driver for it to not use GFP_ATOMIC; - fixes at cedrus and vicodec drivers at the control handling logic; - a fix at gpio-ir-tx to avoid disabling interruts on a spinlock. Thanks! Mauro The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v5.9-2 for you to fetch changes up to ddecfc76979d5585847c76c4c489dcac389f86dd: media: mceusb: Avoid GFP_ATOMIC where it is not needed (2020-08-28 14:06:36 +0200) media fixes for v5.9-rc4 Christophe JAILLET (1): media: mceusb: Avoid GFP_ATOMIC where it is not needed Ezequiel Garcia (1): media: cedrus: Add missing v4l2_ctrl_request_hdl_put() Hans Verkuil (1): media: vicodec: add missing v4l2_ctrl_request_hdl_put() Jacopo Mondi (1): media: i2c: imx214: select V4L2_FWNODE Laurent Pinchart (1): media: ti-vpe: cal: Fix compilation on 32-bit ARM Peilin Ye (1): media: media/v4l2-core: Fix kernel-infoleak in video_put_user() Sakari Ailus (1): media: max9286: Depend on OF_GPIO Sean Young (3): media: rc: uevent sysfs file races with rc_unregister_device() media: rc: do not access device via sysfs after rc_unregister_device() media: gpio-ir-tx: spinlock is not needed to disable interrupts drivers/media/i2c/Kconfig | 4 +- drivers/media/platform/ti-vpe/cal.h | 2 +- drivers/media/rc/gpio-ir-tx.c | 16 +++- drivers/media/rc/mceusb.c | 2 +- drivers/media/rc/rc-main.c| 44 drivers/media/test-drivers/vicodec/vicodec-core.c | 1 + drivers/media/v4l2-core/v4l2-ioctl.c | 50 --- drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++- 8 files changed, 71 insertions(+), 55 deletions(-)
Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
On 9/3/20 7:46 AM, Rich Felker wrote: > > OK, I think I have an explanation for the mechanism of the bug, and it > really is a combination of the 2008 bug (confusion of r0 vs r3) and > the SECCOMP_FILTER commit. When the syscall_trace_entry code path is > in use, a syscall with argument 5 having value -1 causes > do_syscall_trace_enter to return -1 (because it returns regs[0], which > contains argument 5), which the change in entry-common.S interprets as > a sign to skip the syscall and jump to syscall_exit, and things blow > up from there. In particular, SYS_mmap2 is almost always called with > -1 as the 5th argument (fd), and this is even more common on nommu > where SYS_brk does not work. > > I'll follow up with a new proposed patch. I'm not sure whether we need another revision of your first patch. Your previous analysis was at least right regarding the tests 51 and 58 but those have been fixed now. But there were two other tests failing, weren't there? I have to recheck later, I just got up (it's 8 AM CEST). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 2/4] perf vendor events amd: Add ITLB Instruction Fetch Hits event for zen1
On Tue, Sep 1, 2020 at 3:10 PM Kim Phillips wrote:
>
> The ITLB Instruction Fetch Hits event isn't documented even in
> later zen1 PPRs, but it seems to count correctly on zen1 hardware.
>
> Add it to zen1 group so zen1 users can use the upcoming IC Fetch Miss
> Ratio Metric.
>
> The IF1G, 1IF2M, IF4K (Instruction fetches to a 1 GB, 2 MB, and 4K page)
> unit masks are not added because unlike zen2 hardware, zen1 hardware
> counts all its unit masks with a 0 unit mask according to the old
> convention:
>
> zen1$ perf stat -e cpu/event=0x94/,cpu/event=0x94,umask=0xff/ sleep 1
>
> Performance counter stats for 'sleep 1':
>
>211,318 cpu/event=0x94/u
>211,318 cpu/event=0x94,umask=0xff/u
>
> Rome/zen2:
>
> zen2$ perf stat -e cpu/event=0x94/,cpu/event=0x94,umask=0xff/ sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 0 cpu/event=0x94/u
>190,744 cpu/event=0x94,umask=0xff/u
>
> Signed-off-by: Kim Phillips
Acked-by: Ian Rogers
Thanks,
Ian
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Mark Rutland
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Vijay Thakkar
> Cc: Andi Kleen
> Cc: John Garry
> Cc: Kan Liang
> Cc: Yunfeng Ye
> Cc: Jin Yao
> Cc: "Martin Liška"
> Cc: Borislav Petkov
> Cc: Jon Grimm
> Cc: Martin Jambor
> Cc: Michael Petlan
> Cc: William Cohen
> Cc: Stephane Eranian
> Cc: Ian Rogers
> Cc: linux-perf-us...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> tools/perf/pmu-events/arch/x86/amdzen1/branch.json | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
> b/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
> index a9943eeb8d6b..4ceb67a0db21 100644
> --- a/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
> +++ b/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
> @@ -19,5 +19,10 @@
> "EventName": "bp_de_redirect",
> "EventCode": "0x91",
> "BriefDescription": "Decoder Overrides Existing Branch Prediction
> (speculative)."
> + },
> + {
> +"EventName": "bp_l1_tlb_fetch_hit",
> +"EventCode": "0x94",
> +"BriefDescription": "The number of instruction fetches that hit in the
> L1 ITLB."
>}
> ]
> --
> 2.27.0
>
Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
Hi Richi! On 9/3/20 5:56 AM, Rich Felker wrote: >> Test 51-live-user_notification%%001-1 result: FAILURE >> 51-live-user_notification 5 ALLOW rc=14 > > AFAICT, this test is buggy and cannot possibly work. It attempts to > have SYS_getpid return a 64-bit value and check that the returned > value matches. On 32-bit archs this will be truncated to 32 bits, but > the comparison in the caller still compares against the full 64-bit > value. I have no idea how this seemed to work before. You're actually right, I forgot about that. Michael discovered this bug as well and it was consequently fixed: > https://github.com/seccomp/libseccomp/commit/bee43d3e884788569860a384e6a38357785a3995 >> Test 58-live-tsync_notify%%001-1 result: FAILURE 58-live-tsync_notify >> 6 ALLOW rc=14 > > This is similar to 51. > > I think the commonality of all the failures is that they deal with > return values set by seccomp filters for blocked syscalls, which are > getting clobbered by ENOSYS from the failed syscall here. So I do need > to keep the code path that jumps over the actual syscall if > do_syscall_trace_enter returns -1, but that means > do_syscall_trace_enter must now be responsible for setting the return > value in non-seccomp failure paths. Same here: > https://github.com/seccomp/libseccomp/commit/f0686d9de911e7ffcdc7364566c1d146e44657c2 Not sure about the other two tests. I can re-base and re-test. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 02/38] media: v4l2-ioctl: avoid memory leaks on some time32 compat functions
Em Wed, 2 Sep 2020 20:45:53 +0200
Arnd Bergmann escreveu:
> On Wed, Sep 2, 2020 at 6:10 PM Mauro Carvalho Chehab
> wrote:
> >
> > There are some reports about possible memory leaks:
> >
> > drivers/media/v4l2-core//v4l2-ioctl.c:3203 video_put_user() warn:
> > check that 'ev32' doesn't leak information (struct has a hole after 'type')
> > drivers/media/v4l2-core//v4l2-ioctl.c:3230 video_put_user() warn:
> > check that 'vb32' doesn't leak information (struct has a hole after
> > 'memory')
> >
> > While smatch seems to be reporting a false positive (line 3203),
> > there's indeed a possible leak with reserved2 at vb32.
> >
> > We might have fixed just that one, but smatch checks won't
> > be able to check leaks at ev32. So, re-work the code in a way
> > that will ensure that the var contents will be zeroed before
> > filling it.
> >
> > With that, we don't need anymore to touch reserved fields.
> >
> > Signed-off-by: Mauro Carvalho Chehab
>
> Isn't this the same as commit 4ffb879ea648 ("media: media/v4l2-core:
> Fix kernel-infoleak
> in video_put_user()") that you already applied (aside from the issue
> that Laurent
> pointed out)?
Oh! I completely forgot about that one which is at the fixes branch.
Yeah, you're right! I'll drop this one from the series.
Thanks!
Mauro
[PATCH v2] ASoC: fsl_sai: Set SAI Channel Mode to Output Mode
Transmit data pins will output zero when slots are masked or channels
are disabled. In CHMOD TDM mode, transmit data pins are tri-stated when
slots are masked or channels are disabled. When data pins are tri-stated,
there is noise on some channels when FS clock value is high and data is
read while fsclk is transitioning from high to low.
Signed-off-by: Cosmin-Gabriel Samoila
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
changes in v2
- update note
- add acked-by Nicolin
sound/soc/fsl/fsl_sai.c | 10 --
sound/soc/fsl/fsl_sai.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 38c7bcbb361d..b2d65e53dbc4 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -489,6 +489,10 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
*substream,
val_cr4 |= FSL_SAI_CR4_FRSZ(slots);
+ /* Set to output mode to avoid tri-stated data pins */
+ if (tx)
+ val_cr4 |= FSL_SAI_CR4_CHMOD;
+
/*
* For SAI master mode, when Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will
* generate bclk and frame clock for Tx(Rx), we should set RCR4(TCR4),
@@ -497,7 +501,8 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
*substream,
if (!sai->is_slave_mode && fsl_sai_dir_is_synced(sai, adir)) {
regmap_update_bits(sai->regmap, FSL_SAI_xCR4(!tx, ofs),
- FSL_SAI_CR4_SYWD_MASK |
FSL_SAI_CR4_FRSZ_MASK,
+ FSL_SAI_CR4_SYWD_MASK |
FSL_SAI_CR4_FRSZ_MASK |
+ FSL_SAI_CR4_CHMOD_MASK,
val_cr4);
regmap_update_bits(sai->regmap, FSL_SAI_xCR5(!tx, ofs),
FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
@@ -508,7 +513,8 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
*substream,
FSL_SAI_CR3_TRCE_MASK,
FSL_SAI_CR3_TRCE((1 << pins) - 1));
regmap_update_bits(sai->regmap, FSL_SAI_xCR4(tx, ofs),
- FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK,
+ FSL_SAI_CR4_SYWD_MASK | FSL_SAI_CR4_FRSZ_MASK |
+ FSL_SAI_CR4_CHMOD_MASK,
val_cr4);
regmap_update_bits(sai->regmap, FSL_SAI_xCR5(tx, ofs),
FSL_SAI_CR5_WNW_MASK | FSL_SAI_CR5_W0W_MASK |
diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
index 5f630be74853..736a437450c8 100644
--- a/sound/soc/fsl/fsl_sai.h
+++ b/sound/soc/fsl/fsl_sai.h
@@ -119,6 +119,8 @@
#define FSL_SAI_CR4_FRSZ_MASK (0x1f << 16)
#define FSL_SAI_CR4_SYWD(x)(((x) - 1) << 8)
#define FSL_SAI_CR4_SYWD_MASK (0x1f << 8)
+#define FSL_SAI_CR4_CHMOD BIT(5)
+#define FSL_SAI_CR4_CHMOD_MASK BIT(5)
#define FSL_SAI_CR4_MF BIT(4)
#define FSL_SAI_CR4_FSEBIT(3)
#define FSL_SAI_CR4_FSPBIT(1)
--
2.27.0
Re: [PATCH net-next RFC v3 01/14] devlink: Add reload action option to devlink reload command
Wed, Sep 02, 2020 at 05:30:25PM CEST, k...@kernel.org wrote: >On Wed, 2 Sep 2020 11:46:27 +0200 Jiri Pirko wrote: >> >? Do we need such change there too or keep it as is, each action by itself >> >and return what was performed ? >> >> Well, I don't know. User asks for X, X should be performed, not Y or Z. >> So perhaps the return value is not needed. >> Just driver advertizes it supports X, Y, Z and the users says: >> 1) do X, driver does X >> 2) do Y, driver does Y >> 3) do Z, driver does Z >> [ >> I think this kindof circles back to the original proposal... > >Why? User does not care if you activate new devlink params when >activating new firmware. Trust me. So why make the user figure out >which of all possible reset option they should select? If there is >a legitimate use case to limit what is reset - it should be handled >by a separate negative attribute, like --live which says don't reset >anything. I see. Okay. Could you please sum-up the interface as you propose it? Thanks!
Re: [PATCH v3 19/23] sh: use asm-generic/mmu_context.h for no-op implementations
On Wed, Sep 02, 2020 at 12:15:35AM +1000, Nicholas Piggin wrote:
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: linux...@vger.kernel.org
> Signed-off-by: Nicholas Piggin
> ---
>
> Please ack or nack if you object to this being mered via
> Arnd's tree.
Acked-by: Rich Felker
>
> arch/sh/include/asm/mmu_context.h| 5 ++---
> arch/sh/include/asm/mmu_context_32.h | 9 -
> 2 files changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/arch/sh/include/asm/mmu_context.h
> b/arch/sh/include/asm/mmu_context.h
> index 461b1304580b..78eef4e7d5df 100644
> --- a/arch/sh/include/asm/mmu_context.h
> +++ b/arch/sh/include/asm/mmu_context.h
> @@ -84,6 +84,7 @@ static inline void get_mmu_context(struct mm_struct *mm,
> unsigned int cpu)
> * Initialize the context related info for a new mm_struct
> * instance.
> */
> +#define init_new_context init_new_context
> static inline int init_new_context(struct task_struct *tsk,
> struct mm_struct *mm)
> {
> @@ -120,9 +121,7 @@ static inline void switch_mm(struct mm_struct *prev,
> activate_context(next, cpu);
> }
>
> -#define activate_mm(prev, next) switch_mm((prev),(next),NULL)
> -#define deactivate_mm(tsk,mm)do { } while (0)
> -#define enter_lazy_tlb(mm,tsk) do { } while (0)
> +#include
>
> #else
>
> diff --git a/arch/sh/include/asm/mmu_context_32.h
> b/arch/sh/include/asm/mmu_context_32.h
> index 71bf12ef1f65..bc5034fa6249 100644
> --- a/arch/sh/include/asm/mmu_context_32.h
> +++ b/arch/sh/include/asm/mmu_context_32.h
> @@ -2,15 +2,6 @@
> #ifndef __ASM_SH_MMU_CONTEXT_32_H
> #define __ASM_SH_MMU_CONTEXT_32_H
>
> -/*
> - * Destroy context related info for an mm_struct that is about
> - * to be put to rest.
> - */
> -static inline void destroy_context(struct mm_struct *mm)
> -{
> - /* Do nothing */
> -}
> -
> #ifdef CONFIG_CPU_HAS_PTEAEX
> static inline void set_asid(unsigned long asid)
> {
> --
> 2.23.0
[PATCH] media: mtk-vcodec: remove allocated dma_parms
9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform
devices") included dma_parms in platform_device. There's no need to
allocate again.
Fixes: 13483fc2f20f0e2db7ba9c39b095ac7ea46f8de8 ("media: mtk-vcodec: set dma
max segment size")
Suggested-by: Robin Murphy
Signed-off-by: Hsin-Yi Wang
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 9 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 9 +
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 3bbd0bac56d69..76ee0cb5a7094 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -242,14 +242,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
mtk_v4l2_err("[VPU] vpu device in not ready");
return -EPROBE_DEFER;
}
- if (!pdev->dev.dma_parms) {
- pdev->dev.dma_parms = devm_kzalloc(&pdev->dev,
- sizeof(*pdev->dev.dma_parms),
- GFP_KERNEL);
- if (!pdev->dev.dma_parms)
- return -ENOMEM;
- }
- dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
+ dma_set_max_seg_size(&pdev->dev, UINT_MAX);
vpu_wdt_reg_handler(dev->vpu_plat_dev, mtk_vcodec_dec_reset_handler,
dev, VPU_RST_DEC);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index ff4a87485d690..c18e58c71d4a4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -249,14 +249,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
mtk_v4l2_err("[VPU] vpu device in not ready");
return -EPROBE_DEFER;
}
- if (!pdev->dev.dma_parms) {
- pdev->dev.dma_parms = devm_kzalloc(&pdev->dev,
- sizeof(*pdev->dev.dma_parms),
- GFP_KERNEL);
- if (!pdev->dev.dma_parms)
- return -ENOMEM;
- }
- dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
+ dma_set_max_seg_size(&pdev->dev, UINT_MAX);
vpu_wdt_reg_handler(dev->vpu_plat_dev, mtk_vcodec_enc_reset_handler,
dev, VPU_RST_ENC);
--
2.28.0.402.g5ffc5be6b7-goog
[PATCH] sh: fix syscall tracing
Addition of SECCOMP_FILTER exposed a longstanding bug in
do_syscall_trace_enter, whereby r0 (the 5th argument register) was
mistakenly used where r3 (syscall_nr) was intended. By overwriting r0
rather than r3 with -1 when attempting to block a syscall, the
existing code would instead have caused the syscall to execute with an
argument clobbered.
Commit 0bb605c2c7f2b4b3 then introduced skipping of the syscall when
do_syscall_trace_enter returns -1, so that the return value set by
seccomp filters would not be clobbered by -ENOSYS. This eliminated the
clobbering of the 5th argument register, but instead caused syscalls
made with a 5th argument of -1 to be misinterpreted as a request by
do_syscall_trace_enter to suppress the syscall.
Fixes: 0bb605c2c7f2b4b3 ("sh: Add SECCOMP_FILTER")
Fixes: ab99c733ae73cce3 ("sh: Make syscall tracer use tracehook notifiers, add
TIF_NOTIFY_RESUME.")
Signed-off-by: Rich Felker
---
arch/sh/kernel/entry-common.S | 1 -
arch/sh/kernel/ptrace_32.c| 15 +--
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/sh/kernel/entry-common.S b/arch/sh/kernel/entry-common.S
index ad963104d22d..91ab2607a1ff 100644
--- a/arch/sh/kernel/entry-common.S
+++ b/arch/sh/kernel/entry-common.S
@@ -370,7 +370,6 @@ syscall_trace_entry:
nop
cmp/eq #-1, r0
bt syscall_exit
- mov.l r0, @(OFF_R0,r15) ! Save return value
! Reload R0-R4 from kernel stack, where the
! parent may have modified them using
! ptrace(POKEUSR). (Note that R0-R2 are
diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
index b05bf92f9c32..5281685f6ad1 100644
--- a/arch/sh/kernel/ptrace_32.c
+++ b/arch/sh/kernel/ptrace_32.c
@@ -455,16 +455,11 @@ long arch_ptrace(struct task_struct *child, long request,
asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
{
- long ret = 0;
-
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
- tracehook_report_syscall_entry(regs))
- /*
-* Tracing decided this syscall should not happen.
-* We'll return a bogus call number to get an ENOSYS
-* error, but leave the original number in regs->regs[0].
-*/
- ret = -1L;
+ tracehook_report_syscall_entry(regs)) {
+ regs->regs[0] = -ENOSYS;
+ return -1;
+ }
if (secure_computing() == -1)
return -1;
@@ -475,7 +470,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
audit_syscall_entry(regs->regs[3], regs->regs[4], regs->regs[5],
regs->regs[6], regs->regs[7]);
- return ret ?: regs->regs[0];
+ return 0;
}
asmlinkage void do_syscall_trace_leave(struct pt_regs *regs)
--
2.21.0
Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
On Wed, Sep 02, 2020 at 11:56:04PM -0400, Rich Felker wrote: > On Sat, Aug 29, 2020 at 01:09:43PM +0200, John Paul Adrian Glaubitz wrote: > > Hi! > > > > On 8/29/20 2:49 AM, Rich Felker wrote: > > > This restored my ability to use strace > > > > I can confirm that. However ... > > > > > and I've written and tested a minimal strace-like hack using > > > SECCOMP_RET_USER_NOTIF that works as > > > expected on both j2 and qemu-system-sh4, so I think the above is > > > correct. > > > > The seccomp live testsuite has regressed. > > > > [...] > > Test 58-live-tsync_notify%%001-1 result: FAILURE 58-live-tsync_notify > > 6 ALLOW rc=14 > > This is similar to 51. > > I think the commonality of all the failures is that they deal with > return values set by seccomp filters for blocked syscalls, which are > getting clobbered by ENOSYS from the failed syscall here. So I do need > to keep the code path that jumps over the actual syscall if > do_syscall_trace_enter returns -1, but that means > do_syscall_trace_enter must now be responsible for setting the return > value in non-seccomp failure paths. > > I'll experiment to see what's still needed if that change is made. OK, I think I have an explanation for the mechanism of the bug, and it really is a combination of the 2008 bug (confusion of r0 vs r3) and the SECCOMP_FILTER commit. When the syscall_trace_entry code path is in use, a syscall with argument 5 having value -1 causes do_syscall_trace_enter to return -1 (because it returns regs[0], which contains argument 5), which the change in entry-common.S interprets as a sign to skip the syscall and jump to syscall_exit, and things blow up from there. In particular, SYS_mmap2 is almost always called with -1 as the 5th argument (fd), and this is even more common on nommu where SYS_brk does not work. I'll follow up with a new proposed patch. Rich
[PATCH] mmc: s3cmci: Drop unused variables in dbg_dumpregs
The 'imask' and 'bsize' are not used in dbg_dumpregs:
drivers/mmc/host/s3cmci.c:149:36: warning: variable 'imask' set but not used
[-Wunused-but-set-variable]
drivers/mmc/host/s3cmci.c:148:63: warning: variable 'bsize' set but not used
[-Wunused-but-set-variable]
Reported-by: kernel test robot
Signed-off-by: Krzysztof Kozlowski
---
drivers/mmc/host/s3cmci.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index ac94f926624d..40329aeacfdf 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -145,8 +145,8 @@ static void s3cmci_reset(struct s3cmci_host *host);
static void dbg_dumpregs(struct s3cmci_host *host, char *prefix)
{
- u32 con, pre, cmdarg, cmdcon, cmdsta, r0, r1, r2, r3, timer, bsize;
- u32 datcon, datcnt, datsta, fsta, imask;
+ u32 con, pre, cmdarg, cmdcon, cmdsta, r0, r1, r2, r3, timer;
+ u32 datcon, datcnt, datsta, fsta;
con = readl(host->base + S3C2410_SDICON);
pre = readl(host->base + S3C2410_SDIPRE);
@@ -158,12 +158,10 @@ static void dbg_dumpregs(struct s3cmci_host *host, char
*prefix)
r2 = readl(host->base + S3C2410_SDIRSP2);
r3 = readl(host->base + S3C2410_SDIRSP3);
timer = readl(host->base + S3C2410_SDITIMER);
- bsize = readl(host->base + S3C2410_SDIBSIZE);
datcon = readl(host->base + S3C2410_SDIDCON);
datcnt = readl(host->base + S3C2410_SDIDCNT);
datsta = readl(host->base + S3C2410_SDIDSTA);
fsta= readl(host->base + S3C2410_SDIFSTA);
- imask = readl(host->base + host->sdiimsk);
dbg(host, dbg_debug, "%s CON:[%08x] PRE:[%08x] TMR:[%08x]\n",
prefix, con, pre, timer);
--
2.17.1
[PATCH 2/9] block: add a bdev_is_partition helper
Add a littler helper to make the somewhat arcane bd_contains checks a
little more obvious.
Signed-off-by: Christoph Hellwig
---
block/blk-lib.c | 2 +-
block/ioctl.c | 4 ++--
block/scsi_ioctl.c | 2 +-
drivers/ide/ide-ioctls.c| 4 ++--
drivers/md/dm-table.c | 2 +-
drivers/mmc/core/block.c| 2 +-
drivers/s390/block/dasd_ioctl.c | 8
fs/nfsd/blocklayout.c | 4 ++--
include/linux/blkdev.h | 9 +++--
kernel/trace/blktrace.c | 2 +-
10 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/block/blk-lib.c b/block/blk-lib.c
index 0d1811e57ac704..e90614fd8d6a42 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -64,7 +64,7 @@ int __blkdev_issue_discard(struct block_device *bdev,
sector_t sector,
return -EINVAL;
/* In case the discard request is in a partition */
- if (bdev->bd_partno)
+ if (bdev_is_partition(bdev))
part_offset = bdev->bd_part->start_sect;
while (nr_sects) {
diff --git a/block/ioctl.c b/block/ioctl.c
index bdb3bbb253d9f8..e4af3df9d28a68 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -23,7 +23,7 @@ static int blkpg_do_ioctl(struct block_device *bdev,
return -EACCES;
if (copy_from_user(&p, upart, sizeof(struct blkpg_partition)))
return -EFAULT;
- if (bdev != bdev->bd_contains)
+ if (bdev_is_partition(bdev))
return -EINVAL;
if (p.pno <= 0)
@@ -94,7 +94,7 @@ static int blkdev_reread_part(struct block_device *bdev)
{
int ret;
- if (!disk_part_scan_enabled(bdev->bd_disk) || bdev != bdev->bd_contains)
+ if (!disk_part_scan_enabled(bdev->bd_disk) || bdev_is_partition(bdev))
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index ef722f04f88a93..3bb4571385ce21 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -854,7 +854,7 @@ EXPORT_SYMBOL(scsi_cmd_ioctl);
int scsi_verify_blk_ioctl(struct block_device *bd, unsigned int cmd)
{
- if (bd && bd == bd->bd_contains)
+ if (bd && !bdev_is_partition(bd))
return 0;
if (capable(CAP_SYS_RAWIO))
diff --git a/drivers/ide/ide-ioctls.c b/drivers/ide/ide-ioctls.c
index 09491098047bff..58994da10c0664 100644
--- a/drivers/ide/ide-ioctls.c
+++ b/drivers/ide/ide-ioctls.c
@@ -49,7 +49,7 @@ int ide_setting_ioctl(ide_drive_t *drive, struct block_device
*bdev,
return err >= 0 ? put_user_long(err, arg) : err;
set_val:
- if (bdev != bdev->bd_contains)
+ if (bdev_is_partition(bdev))
err = -EINVAL;
else {
if (!capable(CAP_SYS_ADMIN))
@@ -257,7 +257,7 @@ int generic_ide_ioctl(ide_drive_t *drive, struct
block_device *bdev,
switch (cmd) {
case HDIO_OBSOLETE_IDENTITY:
case HDIO_GET_IDENTITY:
- if (bdev != bdev->bd_contains)
+ if (bdev_is_partition(bdev))
return -EINVAL;
return ide_get_identity_ioctl(drive, cmd, argp);
case HDIO_GET_NICE:
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 5edc3079e7c199..af156256e511ff 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -903,7 +903,7 @@ static int device_is_rq_stackable(struct dm_target *ti,
struct dm_dev *dev,
struct request_queue *q = bdev_get_queue(bdev);
/* request-based cannot stack on partitions! */
- if (bdev != bdev->bd_contains)
+ if (bdev_is_partition(bdev))
return false;
return queue_is_mq(q);
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index fa313b63413547..8d3df0be0355ce 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -723,7 +723,7 @@ static int mmc_blk_check_blkdev(struct block_device *bdev)
* whole block device, not on a partition. This prevents overspray
* between sibling partitions.
*/
- if ((!capable(CAP_SYS_RAWIO)) || (bdev != bdev->bd_contains))
+ if (!capable(CAP_SYS_RAWIO) || bdev_is_partition(bdev))
return -EPERM;
return 0;
}
diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c
index faaf5596e31c12..cb6427fb9f3d16 100644
--- a/drivers/s390/block/dasd_ioctl.c
+++ b/drivers/s390/block/dasd_ioctl.c
@@ -277,7 +277,7 @@ dasd_ioctl_format(struct block_device *bdev, void __user
*argp)
dasd_put_device(base);
return -EFAULT;
}
- if (bdev != bdev->bd_contains) {
+ if (bdev_is_partition(bdev)) {
pr_warn("%s: The specified DASD is a partition and cannot be
formatted\n",
dev_name(&base->cdev->dev));
dasd_put_device(base);
@@ -304,7 +304,7 @@ static int dasd_ioctl_check_format(struct block_device
*
[PATCH 5/9] drbd: don't detour through bd_contains for the gendisk
bd_disk is set on all block devices, including those for partitions.
Signed-off-by: Christoph Hellwig
---
drivers/block/drbd/drbd_receiver.c | 2 +-
drivers/block/drbd/drbd_worker.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/drbd/drbd_receiver.c
b/drivers/block/drbd/drbd_receiver.c
index 422363daa6180b..2d16fb0905999d 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -2789,7 +2789,7 @@ bool drbd_rs_should_slow_down(struct drbd_device *device,
sector_t sector,
bool drbd_rs_c_min_rate_throttle(struct drbd_device *device)
{
- struct gendisk *disk = device->ldev->backing_bdev->bd_contains->bd_disk;
+ struct gendisk *disk = device->ldev->backing_bdev->bd_disk;
unsigned long db, dt, dbdt;
unsigned int c_min_rate;
int curr_events;
diff --git a/drivers/block/drbd/drbd_worker.c b/drivers/block/drbd/drbd_worker.c
index 7c903de5c4e103..9107b109ba7bcb 100644
--- a/drivers/block/drbd/drbd_worker.c
+++ b/drivers/block/drbd/drbd_worker.c
@@ -1672,7 +1672,7 @@ void drbd_resync_after_changed(struct drbd_device *device)
void drbd_rs_controller_reset(struct drbd_device *device)
{
- struct gendisk *disk = device->ldev->backing_bdev->bd_contains->bd_disk;
+ struct gendisk *disk = device->ldev->backing_bdev->bd_disk;
struct fifo_buffer *plan;
atomic_set(&device->rs_sect_in, 0);
--
2.28.0
[PATCH 4/9] md: don't detour through bd_contains for the gendisk
bd_disk is set on all block devices, including those for partitions.
Signed-off-by: Christoph Hellwig
---
drivers/md/md.c | 2 +-
drivers/md/md.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3f33562d10d6f5..5a0fd93769a70e 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8444,7 +8444,7 @@ static int is_mddev_idle(struct mddev *mddev, int init)
idle = 1;
rcu_read_lock();
rdev_for_each_rcu(rdev, mddev) {
- struct gendisk *disk = rdev->bdev->bd_contains->bd_disk;
+ struct gendisk *disk = rdev->bdev->bd_disk;
curr_events = (int)part_stat_read_accum(&disk->part0, sectors) -
atomic_read(&disk->sync_io);
/* sync IO will cause sync_io to increase before the disk_stats
diff --git a/drivers/md/md.h b/drivers/md/md.h
index f9e2ccdd22c478..2175a5ac4f7c68 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -551,7 +551,7 @@ extern void mddev_unlock(struct mddev *mddev);
static inline void md_sync_acct(struct block_device *bdev, unsigned long
nr_sectors)
{
- atomic_add(nr_sectors, &bdev->bd_contains->bd_disk->sync_io);
+ atomic_add(nr_sectors, &bdev->bd_disk->sync_io);
}
static inline void md_sync_acct_bio(struct bio *bio, unsigned long nr_sectors)
--
2.28.0
[PATCH 7/9] target/iblock: fix holder printing in iblock_show_configfs_dev_params
bd_contains is never NULL for an open block device. In addition ibd_bd
is always set to a block device that was exclusively opened by the
target code, so the holder is guranteed to be ib_dev as well.
Signed-off-by: Christoph Hellwig
---
drivers/target/target_core_iblock.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index 1c181d31f4c872..f2bd2e207e0b36 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -611,9 +611,8 @@ static ssize_t iblock_show_configfs_dev_params(struct
se_device *dev, char *b)
bl += sprintf(b + bl, "");
if (bd) {
bl += sprintf(b + bl, "Major: %d Minor: %d %s\n",
- MAJOR(bd->bd_dev), MINOR(bd->bd_dev),
(!bd->bd_contains) ?
- "" : (bd->bd_holder == ib_dev) ?
- "CLAIMED: IBLOCK" : "CLAIMED: OS");
+ MAJOR(bd->bd_dev), MINOR(bd->bd_dev),
+ "CLAIMED: IBLOCK");
} else {
bl += sprintf(b + bl, "Major: 0 Minor: 0\n");
}
--
2.28.0
[PATCH 3/9] md: compare bd_disk instead of bd_contains
To check for partitions of the same disk bd_contains works as well, but
bd_disk is way more obvious.
Signed-off-by: Christoph Hellwig
---
drivers/md/md.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 9562ef598ae1f4..3f33562d10d6f5 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2322,8 +2322,7 @@ static int match_mddev_units(struct mddev *mddev1, struct
mddev *mddev2)
test_bit(Journal, &rdev2->flags) ||
rdev2->raid_disk == -1)
continue;
- if (rdev->bdev->bd_contains ==
- rdev2->bdev->bd_contains) {
+ if (rdev->bdev->bd_disk == rdev2->bdev->bd_disk) {
rcu_read_unlock();
return 1;
}
@@ -5944,8 +5943,8 @@ int md_run(struct mddev *mddev)
rdev_for_each(rdev, mddev)
rdev_for_each(rdev2, mddev) {
if (rdev < rdev2 &&
- rdev->bdev->bd_contains ==
- rdev2->bdev->bd_contains) {
+ rdev->bdev->bd_disk ==
+ rdev2->bdev->bd_disk) {
pr_warn("%s: WARNING: %s appears to be
on the same physical disk as %s.\n",
mdname(mddev),
bdevname(rdev->bdev,b),
--
2.28.0
clean up is partition checks
Hi Jens, this series add a new helepr to check if a struct block_device represents a parition, and removes most direct access to ->bd_contained from drivers. Diffstat: Documentation/userspace-api/ioctl/hdio.rst | 24 block/blk-lib.c|2 +- block/genhd.c |2 +- block/ioctl.c |4 ++-- block/scsi_ioctl.c |2 +- drivers/block/drbd/drbd_main.c |2 -- drivers/block/drbd/drbd_receiver.c |2 +- drivers/block/drbd/drbd_worker.c |2 +- drivers/ide/ide-ioctls.c |4 ++-- drivers/md/dm-table.c |2 +- drivers/md/md.c|9 - drivers/md/md.h|2 +- drivers/mmc/core/block.c |2 +- drivers/s390/block/dasd_ioctl.c|8 drivers/target/target_core_iblock.c|5 ++--- fs/nfsd/blocklayout.c |4 ++-- include/linux/blkdev.h |9 +++-- kernel/trace/blktrace.c|2 +- lib/vsprintf.c |4 ++-- 19 files changed, 46 insertions(+), 45 deletions(-)
[PATCH 9/9] vsprintf: use bd_partno in bdev_name
No need to go through the hd_struct to find the partition number.
Signed-off-by: Christoph Hellwig
---
lib/vsprintf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index afb9521ddf9197..14c9a6af1b239a 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -940,13 +940,13 @@ char *bdev_name(char *buf, char *end, struct block_device
*bdev,
hd = bdev->bd_disk;
buf = string(buf, end, hd->disk_name, spec);
- if (bdev->bd_part->partno) {
+ if (bdev->bd_partno) {
if (isdigit(hd->disk_name[strlen(hd->disk_name)-1])) {
if (buf < end)
*buf = 'p';
buf++;
}
- buf = number(buf, end, bdev->bd_part->partno, spec);
+ buf = number(buf, end, bdev->bd_partno, spec);
}
return buf;
}
--
2.28.0
[PATCH 6/9] drbd: don't set ->bd_contains
The ->bd_contains field is set by __blkdev_get and drivers have no business manipulating it. Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index 04b6bde9419d2a..bd8b129196d49a 100644 --- a/drivers/block/drbd/drbd_main.c +++ b/drivers/block/drbd/drbd_main.c @@ -2766,8 +2766,6 @@ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsig disk->private_data = device; device->this_bdev = bdget(MKDEV(DRBD_MAJOR, minor)); - /* we have no partitions. we contain only ourselves. */ - device->this_bdev->bd_contains = device->this_bdev; blk_queue_write_cache(q, true, true); /* Setting the max_hw_sectors to an odd value of 8kibyte here -- 2.28.0
[PATCH 8/9] block: use bd_partno in bdevname
No need to go through the hd_struct to find the partition number.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index 081f1039d9367f..771aa56b1a8c3d 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -85,7 +85,7 @@ char *disk_name(struct gendisk *hd, int partno, char *buf)
const char *bdevname(struct block_device *bdev, char *buf)
{
- return disk_name(bdev->bd_disk, bdev->bd_part->partno, buf);
+ return disk_name(bdev->bd_disk, bdev->bd_partno, buf);
}
EXPORT_SYMBOL(bdevname);
--
2.28.0
[PATCH 1/9] Documentation/hdio: fix up obscure bd_contains references
bd_contains is an implementation detail and should not be mentioned in a userspace API documentation. Signed-off-by: Christoph Hellwig --- Documentation/userspace-api/ioctl/hdio.rst | 24 +++--- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/userspace-api/ioctl/hdio.rst b/Documentation/userspace-api/ioctl/hdio.rst index e822e3dff1769b..817371bf94e948 100644 --- a/Documentation/userspace-api/ioctl/hdio.rst +++ b/Documentation/userspace-api/ioctl/hdio.rst @@ -181,7 +181,7 @@ HDIO_SET_UNMASKINTR error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 1] - EBUSY Controller busy @@ -231,7 +231,7 @@ HDIO_SET_MULTCOUNT error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range supported by disk. - EBUSY Controller busy or blockmode already set. @@ -295,7 +295,7 @@ HDIO_GET_IDENTITY the ATA specification. error returns: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - ENOMSG IDENTIFY DEVICE information not available notes: @@ -355,7 +355,7 @@ HDIO_SET_KEEPSETTINGS error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 1] - EBUSY Controller busy @@ -1055,7 +1055,7 @@ HDIO_SET_32BIT error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 3] - EBUSY Controller busy @@ -1085,7 +1085,7 @@ HDIO_SET_NOWERR error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 1] - EBUSY Controller busy @@ -1113,7 +1113,7 @@ HDIO_SET_DMA error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 1] - EBUSY Controller busy @@ -1141,7 +1141,7 @@ HDIO_SET_PIO_MODE error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 255] - EBUSY Controller busy @@ -1237,7 +1237,7 @@ HDIO_SET_WCACHE error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 1] - EBUSY Controller busy @@ -1265,7 +1265,7 @@ HDIO_SET_ACOUSTIC error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 254] - EBUSY Controller busy @@ -1305,7 +1305,7 @@ HDIO_SET_ADDRESS error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0 2] - EBUSY Controller busy @@ -1331,7 +1331,7 @@ HDIO_SET_IDE_SCSI error return: - - EINVAL (bdev != bdev->bd_contains) (not sure what this means) + - EINVAL Called on a partition instead of the whole disk device - EACCES Access denied: requires CAP_SYS_ADMIN - EINVAL value out of range [0
Re: [PATCH 1/4] perf vendor events amd: Add L2 Prefetch events for zen1
On Tue, Sep 1, 2020 at 3:10 PM Kim Phillips wrote:
>
> Later revisions of PPRs that post-date the original Family 17h events
> submission patch add these events.
>
> Specifically, they were not in this 2017 revision of the F17h PPR:
>
> Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision
> B1 Processors Rev 1.14 - April 15, 2017
>
> But e.g., are included in this 2019 version of the PPR:
>
> Processor Programming Reference (PPR) for AMD Family 17h Model 18h, Revision
> B1 Processors Rev. 3.14 - Sep 26, 2019
>
> Signed-off-by: Kim Phillips
Reviewed-by: Ian Rogers
Sanity checked manual and ran tests. Thanks,
Ian
> Fixes: 98c07a8f74f8 ("perf vendor events amd: perf PMU events for AMD Family
> 17h")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Mark Rutland
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Vijay Thakkar
> Cc: Andi Kleen
> Cc: John Garry
> Cc: Kan Liang
> Cc: Yunfeng Ye
> Cc: Jin Yao
> Cc: "Martin Liška"
> Cc: Borislav Petkov
> Cc: Jon Grimm
> Cc: Martin Jambor
> Cc: Michael Petlan
> Cc: William Cohen
> Cc: Stephane Eranian
> Cc: Ian Rogers
> Cc: linux-perf-us...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> ---
> .../pmu-events/arch/x86/amdzen1/cache.json | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> index 404d4c569c01..695ed3ffa3a6 100644
> --- a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> +++ b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
> @@ -249,6 +249,24 @@
> "BriefDescription": "Cycles with fill pending from L2. Total cycles
> spent with one or more fill requests in flight from L2.",
> "UMask": "0x1"
>},
> + {
> +"EventName": "l2_pf_hit_l2",
> +"EventCode": "0x70",
> +"BriefDescription": "L2 prefetch hit in L2.",
> +"UMask": "0xff"
> + },
> + {
> +"EventName": "l2_pf_miss_l2_hit_l3",
> +"EventCode": "0x71",
> +"BriefDescription": "L2 prefetcher hits in L3. Counts all L2 prefetches
> accepted by the L2 pipeline which miss the L2 cache and hit the L3.",
> +"UMask": "0xff"
> + },
> + {
> +"EventName": "l2_pf_miss_l2_l3",
> +"EventCode": "0x72",
> +"BriefDescription": "L2 prefetcher misses in L3. All L2 prefetches
> accepted by the L2 pipeline which miss the L2 and the L3 caches.",
> +"UMask": "0xff"
> + },
>{
> "EventName": "l3_request_g1.caching_l3_cache_accesses",
> "EventCode": "0x01",
> --
> 2.27.0
>
Re: [PATCH v2] ARM: davinci: use simple i2c probe function
On 10/08/20 3:07 PM, Wolfram Sang wrote:
> On Sun, Aug 09, 2020 at 07:24:44PM +0200, Stephen Kitt wrote:
>> The i2c probe functions here don't use the id information provided in
>> their second argument, so the single-parameter i2c probe function
>> ("probe_new") can be used instead.
>>
>> This avoids scanning the identifier tables during probes.
>>
>> Signed-off-by: Stephen Kitt
>
> This is useful, helps deprecating the old probe method:
>
> Acked-by: Wolfram Sang
Queued for v5.10.
Thanks,
Sekhar
Re: [PATCH 11/11] mmc: host: Enable compile testing of multiple drivers
On Wed, Sep 02, 2020 at 11:32:27PM +0200, Michał Mirosław wrote: > On Wed, Sep 02, 2020 at 09:36:58PM +0200, Krzysztof Kozlowski wrote: > > Multiple MMC host controller driver can be compile tested as they do not > > depend on architecture specific headers. > [...] > > --- a/drivers/mmc/host/Kconfig > > +++ b/drivers/mmc/host/Kconfig > > @@ -178,7 +178,7 @@ config MMC_SDHCI_OF_AT91 > [...] > > config MMC_MESON_GX > > tristate "Amlogic S905/GX*/AXG SD/MMC Host Controller support" > > - depends on ARCH_MESON && MMC > > + depends on MMC > > + depends on ARCH_MESON|| COMPILE_TEST > [...] > > config MMC_MOXART > > tristate "MOXART SD/MMC Host Controller support" > > - depends on ARCH_MOXART && MMC > > + depends on MMC > > + depends on ARCH_MOXART || COMPILE_TEST > [...] > > You can drop 'MMC' from depends as the whole tree is under 'if MMC' already. Right, thanks for feedback. Best regards, Krzysztof
Re: [PATCH] ASoC: fsl_sai: Set SAI Channel Mode to Output Mode
On Thu, Sep 3, 2020 at 11:42 AM Nicolin Chen wrote: > > On Thu, Sep 03, 2020 at 11:09:15AM +0800, Shengjiu Wang wrote: > > Transmit data pins will output zero when slots are masked or channels > > are disabled. In CHMOD TDM mode, transmit data pins are tri-stated when > > slots are masked or channels are disabled. When data pins are tri-stated, > > there is noise on some channels when FS clock value is high and data is > > read while fsclk is transitioning from high to low. > > > > Signed-off-by: Cosmin-Gabriel Samoila > > Signed-off-by: Shengjiu Wang > > Acked-by: Nicolin Chen > > Though one nit inline: > > > --- > > sound/soc/fsl/fsl_sai.c | 12 ++-- > > sound/soc/fsl/fsl_sai.h | 2 ++ > > 2 files changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c > > index 62c5fdb678fc..33b194a5c1dc 100644 > > --- a/sound/soc/fsl/fsl_sai.c > > +++ b/sound/soc/fsl/fsl_sai.c > > @@ -486,6 +486,12 @@ static int fsl_sai_hw_params(struct snd_pcm_substream > > *substream, > > > > val_cr4 |= FSL_SAI_CR4_FRSZ(slots); > > > > + /* Output Mode - data pins transmit 0 when slots are masked > > + * or channels are disabled > > + */ > > Coding style for multi-line comments. Yet, probably can simplify? > > /* Set to output mode to avoid tri-stated data pins */ Ok, will update in v2. best regards wang shengjiu
Re: [PATCH 6/9] i2c: imx: Simplify with dev_err_probe()
On Wed, Sep 02, 2020 at 05:06:40PM +0200, Krzysztof Kozlowski wrote:
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and the error value gets printed.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Oleksij Rempel
> ---
> drivers/i2c/busses/i2c-imx.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 0ab5381aa012..63f4367c312b 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1159,11 +1159,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(i2c_imx->clk)) {
> - if (PTR_ERR(i2c_imx->clk) != -EPROBE_DEFER)
> - dev_err(&pdev->dev, "can't get I2C clock\n");
> - return PTR_ERR(i2c_imx->clk);
> - }
> + if (IS_ERR(i2c_imx->clk))
> + return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
> + "can't get I2C clock\n");
>
> ret = clk_prepare_enable(i2c_imx->clk);
> if (ret) {
> --
> 2.17.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [RFC PATCH 0/7] Trace events to pstore
On 2020-09-03 03:17, Joel Fernandes wrote: On Wed, Sep 2, 2020 at 4:01 PM Nachammai Karuppiah wrote: Hi, This patch series adds support to store trace events in pstore. Storing trace entries in persistent RAM would help in understanding what happened just before the system went down. The trace events that led to the crash can be retrieved from the pstore after a warm reboot. This will help debug what happened before machine’s last breath. This has to be done in a scalable way so that tracing a live system does not impact the performance of the system. Just to add, Nachammai was my intern in the recent outreachy program and we designed together a way for trace events to be written to pstore backed memory directory instead of regular memory. The basic idea is to allocate frace's ring buffer on pstore memory and have it right there. Then recover it on reboot. Nachammai wrote the code with some guidance :) . I talked to Steve as well in the past about the basic of idea of this. Steve is on vacation this week though. This is similar to what +Sai Prakash Ranjan was trying to do sometime ago: https://lkml.org/lkml/2018/9/8/221 . But that approach involved higher overhead due to synchronization of writing to the otherwise lockless ring buffer. +Brian Norris has also expressed interest for this feature. Great work Nachammai and Joel, I have few boards with warm reboot support and will test this series in coming days. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH] i2c: virtio: add a virtio i2c frontend driver
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the i2c msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed-by: Shuo Liu
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 276
include/uapi/linux/virtio_ids.h | 1 +
4 files changed, 291 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0..70c8e30 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ depends on VIRTIO
+ help
+ If you say yes to this option, support will be included for the virtio
+ i2c adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 19aff0e..821acfa 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..47f9fd1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define VIRTIO_I2C_MSG_OK 0
+#define VIRTIO_I2C_MSG_ERR 1
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __virtio16 addr;
+ __virtio16 flags;
+ __virtio16 len;
+} __packed;
+
+/**
+ * struct virtio_i2c_msg - the virtio I2C message structure
+ * @hdr: the virtio I2C message header
+ * @buf: virtio I2C message data buffer
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_msg {
+ struct virtio_i2c_hdr hdr;
+ char *buf;
+ u8 status;
+};
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(&vi->completion);
+}
+
+static int virtio_i2c_add_msg(struct virtqueue *vq,
+ struct virtio_i2c_msg *vmsg,
+ struct i2c_msg *msg)
+{
+ struct scatterlist *sgs[3], hdr, bout, bin, status;
+ int outcnt = 0, incnt = 0;
+
+ if (!msg->len)
+ return -EINVAL;
+
+ vmsg->hdr.addr = msg->addr;
+ vmsg->hdr.flags = msg->flags;
+ vmsg->hdr.len = msg->len;
+
+ vmsg->buf = kzalloc(vmsg->hdr.len, GFP_KERNEL);
+ if (!vmsg->buf)
+ return -ENOMEM;
+
+ sg_init_one(&hdr, &vmsg->hdr, sizeof(struct virtio_i2c_hdr));
+ sgs[outcnt++] = &hdr;
+ if (vmsg->hdr.flags & I2C_M_RD) {
+ sg_init_on
Re: [PATCH v2 2/2] mm/pageblock: remove false sharing in pageblock_flags
在 2020/8/31 上午4:32, Alexander Duyck 写道: >> Right that the different level to fix this problem, but narrow the cmpxchg >> comparsion is still needed and helpful. > What I was getting at though is that I am not sure that is the case. > Normally I believe we are always holding the zone lock when updating > the migrate type. The skip flag is a one-off operation that could > easily be addressed by changing the logic to use atomic_and or > atomic_or for the cases where we are updating single bit flags and > setting the mask value to all 1's or all 0's. So adding this extra > complexity which only really applies to the skip bit may not provide > much value, especially as there are a number of possible paths that > don't use the skip bit anyway. Using atomic bit set is only helpful for skip bit. but migrate bits are still do the false sharing sync large. And actully, for this issue on cmpxchg, it's cross arch issue which it's better addressed in kernel. I see much of cmpxchg is using in kernel, but no one mentioned the shortage on this. On this pointer, this problem should be resovled in kernel. Thanks Alex
Re: [PATCH] arm64: dts: qcom: sc7180: Add 'sustainable_power' for CPU thermal zones
On 9/3/2020 10:14 AM, Rajendra Nayak wrote: On 9/2/2020 9:02 PM, Doug Anderson wrote: Hi, On Tue, Sep 1, 2020 at 10:36 PM Rajendra Nayak wrote: * In terms of the numbers here, I believe that you're claiming that we can dissipate 768 mW * 6 + 1202 mW * 2 = ~7 Watts of power. My memory of how much power we could dissipate in previous laptops I worked on is a little fuzzy, but that doesn't seem insane for a passively-cooled laptop. However, I think someone could conceivably put this chip in a smaller form factor. In such a case, it seems like we'd want these things to sum up to ~2000 (if it would ever make sense for someone to put this chip in a phone) or ~4000 (if it would ever make sense for someone to put this chip in a small tablet). It seems possible that, to achieve this, we might have to tweak the "dynamic-power-coefficient". DPC values are calculated (at a SoC) by actually measuring max power at various frequency/voltage combinations by running things like dhrystone. How would the max power a SoC can generate depend on form factors? How much it can dissipate sure is, but then I am not super familiar how thermal frameworks end up using DPC for calculating power dissipated, I am guessing they don't. I don't know how much thought was put into those numbers, but the fact that the little cores have a super round 100 for their dynamic-power-coefficient makes me feel like they might have been more schwags than anything. Rajendra maybe knows? FWIK, the values are always scaled and normalized to 100 for silver and then used to derive the relative DPC number for gold. If you see the DPC for silver cores even on sdm845 is a 100. Again these are not estimations but based on actual power measurements. The scaling to 100 doesn't seem to match how the thermal framework is using them. Take a look at of_cpufreq_cooling_register(). It takes the "dynamic-power-coefficient" and passes it as "capacitance" into __cpufreq_cooling_register(). That's eventually used to compute power, which is documented in the code to be in mW. power = (u64)capacitance * freq_mhz * voltage_mv * voltage_mv; do_div(power, 10); /* power is stored in mW */ freq_table[i].power = power; That's used together with "sustainable-power", which is the attribute that Matthias is trying to set. That value is documented to be in mW as well. ...so if the silver cores are always scaled to 100 regardless of how much power they actually draw then it'll be impossible to actually think about "sustainable-power" as a mW value. Presumably we either need to accept that fact (and ideally document it) or we need to change the values for silver / gold cores (we could still keep the relative values the same and just scale them). That sounds reasonable (still keep the relative values and scale them) I'll get back on what those scaled numbers would look like, and try to get some sense of why this scaling to 100 was done (like you said I don't see any documentation on this), but I see atleast a few other non-qcom SoCs doing this too in mainline (like rockchip/rk3399) On second thoughts, why wouldn't a relative 'sustainable-power' value work? On every device, one would need to do the exercise that Matthias did to come up with the OPP at which we can sustain max CPU/GPU loads anyway. I mean even if we do change the DPC values to match actual power, Matthias would still observe that we can sustain at the very same OPP and not any different. Its just that the mW values that are passed to kernel are relative and not absolute. My worry is that perhaps no SoC vendor wants to put these absolute numbers out. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v3] x86/asm: Replace __force_order with memory clobber
On Thu, Sep 3, 2020 at 1:21 AM Arvind Sankar wrote: > > Changes from v2: > - Clarify commit log and source comment some more Much better now, thanks! Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH v2] scsi: ibmvfc: interface updates for future FPIN and MQ support
On 9/2/20 7:11 PM, Martin K. Petersen wrote: > > Tyrel, > >> Fixup complier errors from neglected commit --amend > > Bunch of formatting-related checkpatch warnings. Please fix. > > Thanks! > So, I stuck to the existing style already in that header. If I'm going to fixup to make checkpatch happy I imagine it makes sense to send a prerequisite patch that fixes up the rest of the header. -Tyrel
Re: [RFC PATCH] libbpf: Support setting map max_entries at runtime
On Mon, Aug 31, 2020 at 4:03 PM Barret Rhoden wrote:
>
> The max_entries for a BPF map may depend on runtime parameters.
> Currently, we need to know the maximum value at BPF compile time. For
> instance, if you want an array map with NR_CPUS entries, you would hard
> code your architecture's largest value for CONFIG_NR_CPUS. This wastes
> memory at runtime.
>
> For the NR_CPU case, one could use a PERCPU map type, but those maps are
> limited in functionality. For instance, BPF programs can only access
> their own PERCPU part of the map, and the maps are not mmappable.
>
> This commit allows the use of sentinel values in BPF map definitions,
> which libbpf patches at runtime.
>
> For starters, we support NUM_POSSIBLE_CPUS: e.g.
>
> struct {
> __uint(type, BPF_MAP_TYPE_ARRAY);
> __uint(max_entries, NUM_POSSIBLE_CPUS);
> __type(key, u32);
> __type(value, struct cpu_data);
> } cpu_blobs SEC(".maps");
>
> This can be extended to other runtime dependent values, such as the
> maximum number of threads (/proc/sys/kernel/threads-max).
>
> Signed-off-by: Barret Rhoden
> ---
libbpf provides bpf_map__set_max_entries() API exactly for such use
cases, please use that.
> tools/lib/bpf/bpf_helpers.h | 4
> tools/lib/bpf/libbpf.c | 40 ++---
> tools/lib/bpf/libbpf.h | 4
> 3 files changed, 41 insertions(+), 7 deletions(-)
>
[...]
Re: [PATCH 6/7] arm64: dts: ti: k3-*: Use generic adc for node names
Hi Nishanth,
On 9/2/20 11:48 PM, Nishanth Menon wrote:
> On 11:51-20200902, Suman Anna wrote:
>> On 9/1/20 5:30 PM, Nishanth Menon wrote:
>>> Use adc@ naming for nodes following standard conventions of device
>>> tree (section 2.2.2 Generic Names recommendation in [1]).
>>>
>>> [1] https://github.com/devicetree-org/devicetree-specification/tree/v0.3
>>>
>>> Suggested-by: Suman Anna
>>> Signed-off-by: Nishanth Menon
>>> ---
>>> arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 4 ++--
>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> index 51ca4b4d4c21..6dfec68ac865 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>>> @@ -80,7 +80,7 @@
>>> #size-cells = <0>;
>>> };
>>>
>>> - tscadc0: tscadc@4020 {
>>> + tscadc0: adc@4020 {
>>
>> OK with these changes, since these seem to be only have the adc child nodes.
>> This node is essentially a parent node for touchscreen and adc child nodes.
>> The
>> driver is currently looking for "tsc" on touchscreen child nodes, but none of
>> the K3 SoCs have them atm.
>>
>
>
> Vignesh: are you ok with this, care to comment?
>
On K3 SoCs, ADC IP is reuse from AM335x but just lacks resistive
touchscreen interfaces. So, existing AM335x ADC driver is being reused
for K3 devices as well. Unfortunately, ADC driver cannot be used as
standalone and is dependent on MFD parent to be present...
Above node represents the MFD parent and ADC itself is the child node
(see arch/arm64/boot/dts/ti/k3-am654-base-board.dts). So, I recommend
that we keep this node's name as tscadc in order to avoid having same
name for parent and child node which will be quite confusing.
Regards
Vignesh
linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/ufs/ufshcd.c
between commit:
b10178ee7fa8 ("scsi: ufs: Clean up completed request without interrupt
notification")
from Linus' tree and commit:
307348f6ab14 ("scsi: ufs: Abort tasks before clearing them from doorbell")
from the scsi-mkp tree.
I fixed it up (I thnink - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/ufs/ufshcd.c
index 3abc5b65e21c,05716f62febe..
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@@ -6587,65 -6745,10 +6749,11 @@@ static int ufshcd_abort(struct scsi_cmn
goto out;
}
- for (poll_cnt = 100; poll_cnt; poll_cnt--) {
- err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp->task_tag,
- UFS_QUERY_TASK, &resp);
- if (!err && resp == UPIU_TASK_MANAGEMENT_FUNC_SUCCEEDED) {
- /* cmd pending in the device */
- dev_err(hba->dev, "%s: cmd pending in the device. tag =
%d\n",
- __func__, tag);
- break;
- } else if (!err && resp == UPIU_TASK_MANAGEMENT_FUNC_COMPL) {
- /*
-* cmd not pending in the device, check if it is
-* in transition.
-*/
- dev_err(hba->dev, "%s: cmd at tag %d not pending in the
device.\n",
- __func__, tag);
- reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
- if (reg & (1 << tag)) {
- /* sleep for max. 200us to stabilize */
- usleep_range(100, 200);
- continue;
- }
- /* command completed already */
- dev_err(hba->dev, "%s: cmd at tag %d successfully
cleared from DB.\n",
- __func__, tag);
- goto cleanup;
- } else {
- dev_err(hba->dev,
- "%s: no response from device. tag = %d, err
%d\n",
- __func__, tag, err);
- if (!err)
- err = resp; /* service response error */
- goto out;
- }
- }
-
- if (!poll_cnt) {
- err = -EBUSY;
- goto out;
- }
-
- err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp->task_tag,
- UFS_ABORT_TASK, &resp);
- if (err || resp != UPIU_TASK_MANAGEMENT_FUNC_COMPL) {
- if (!err) {
- err = resp; /* service response error */
- dev_err(hba->dev, "%s: issued. tag = %d, err %d\n",
- __func__, tag, err);
- }
- goto out;
- }
-
- err = ufshcd_clear_cmd(hba, tag);
- if (err) {
- dev_err(hba->dev, "%s: Failed clearing cmd at tag %d, err %d\n",
- __func__, tag, err);
+ err = ufshcd_try_to_abort_task(hba, tag);
+ if (err)
goto out;
- }
+cleanup:
spin_lock_irqsave(host->host_lock, flags);
__ufshcd_transfer_req_compl(hba, (1UL << tag));
spin_unlock_irqrestore(host->host_lock, flags);
pgpzCIYQzTesr.pgp
Description: OpenPGP digital signature
Re: [Nouveau] [PATCH v2] nouveau: fix the start/end range for migration
On Tue, 1 Sep 2020 at 06:31, Ralph Campbell wrote:
>
> The user level OpenCL code shouldn't have to align start and end
> addresses to a page boundary. That is better handled in the nouveau
> driver. The npages field is also redundant since it can be computed
> from the start and end addresses.
>
> Signed-off-by: Ralph Campbell
Thanks Ralph,
Queued in my tree.
Ben.
> ---
>
> This is for Ben Skegg's nouveau tree.
>
> I have been working with Karol Herbst on the OpenCL mesa changes for
> nouveau which will be merged upstream soon.
> With or without those changes, the user visible effect of this patch
> only extends the range by one page (round up vs. round down to page
> boundary).
>
> Changes in v2:
> I changed the start/end check to require a size so start has to be less
> than end.
>
> drivers/gpu/drm/nouveau/nouveau_svm.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
> b/drivers/gpu/drm/nouveau/nouveau_svm.c
> index 2df1c0460559..4f69e4c3dafd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_svm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
> @@ -105,11 +105,11 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
> struct nouveau_cli *cli = nouveau_cli(file_priv);
> struct drm_nouveau_svm_bind *args = data;
> unsigned target, cmd, priority;
> - unsigned long addr, end, size;
> + unsigned long addr, end;
> struct mm_struct *mm;
>
> args->va_start &= PAGE_MASK;
> - args->va_end &= PAGE_MASK;
> + args->va_end = ALIGN(args->va_end, PAGE_SIZE);
>
> /* Sanity check arguments */
> if (args->reserved0 || args->reserved1)
> @@ -118,8 +118,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
> return -EINVAL;
> if (args->va_start >= args->va_end)
> return -EINVAL;
> - if (!args->npages)
> - return -EINVAL;
>
> cmd = args->header >> NOUVEAU_SVM_BIND_COMMAND_SHIFT;
> cmd &= NOUVEAU_SVM_BIND_COMMAND_MASK;
> @@ -151,12 +149,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
> if (args->stride)
> return -EINVAL;
>
> - size = ((unsigned long)args->npages) << PAGE_SHIFT;
> - if ((args->va_start + size) <= args->va_start)
> - return -EINVAL;
> - if ((args->va_start + size) > args->va_end)
> - return -EINVAL;
> -
> /*
> * Ok we are ask to do something sane, for now we only support migrate
> * commands but we will add things like memory policy (what to do on
> @@ -171,7 +163,7 @@ nouveau_svmm_bind(struct drm_device *dev, void *data,
> return -EINVAL;
> }
>
> - for (addr = args->va_start, end = args->va_start + size; addr < end;)
> {
> + for (addr = args->va_start, end = args->va_end; addr < end;) {
> struct vm_area_struct *vma;
> unsigned long next;
>
> --
> 2.20.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
On Wed, 2 Sep 2020 at 09:43, Lyude Paul wrote:
>
> Not entirely sure why this never came up when I originally tested this
> (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> appears to cause the display engine to throw an exception on driver
> init, at least on my ThinkPad P72:
>
> nouveau :01:00.0: disp: chid 0 mthd 008c data 508c 102b
>
> This is magic nvidia speak for "You need to have the DMA notifier offset
> programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> this by doing that, and also perform an update afterwards to prevent
> racing with the GPU when reading capabilities.
>
> v2:
> * Don't just program the DMA notifier offset, make sure to actually
> perform an update
> v3:
> * Don't call UPDATE()
> * Actually read the correct notifier fields, as apparently the
> CAPABILITIES_DONE field lives in a different location than the main
> NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
> CAPABILITIES_DONE field then pre-907d cards.
> v4:
> * Don't forget to check the return value of core507d_read_caps()
>
> Signed-off-by: Lyude Paul
> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP
> interlacing support")
> Cc: # v5.8+
> ---
> drivers/gpu/drm/nouveau/dispnv50/core.h | 2 +
> drivers/gpu/drm/nouveau/dispnv50/core507d.c | 37 ++-
> drivers/gpu/drm/nouveau/dispnv50/core907d.c | 36 +-
> drivers/gpu/drm/nouveau/dispnv50/core917d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
> .../drm/nouveau/include/nvhw/class/cl507d.h | 5 ++-
> .../drm/nouveau/include/nvhw/class/cl907d.h | 4 ++
> 7 files changed, 83 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h
> b/drivers/gpu/drm/nouveau/dispnv50/core.h
> index 498622c0c670d..b789139e5fff6 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
> @@ -44,6 +44,7 @@ int core507d_new_(const struct nv50_core_func *, struct
> nouveau_drm *, s32,
> struct nv50_core **);
> int core507d_init(struct nv50_core *);
> void core507d_ntfy_init(struct nouveau_bo *, u32);
> +int core507d_read_caps(struct nv50_disp *disp, u32 offset);
> int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
> int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
> int core507d_update(struct nv50_core *, u32 *, bool);
> @@ -55,6 +56,7 @@ extern const struct nv50_outp_func pior507d;
> int core827d_new(struct nouveau_drm *, s32, struct nv50_core **);
>
> int core907d_new(struct nouveau_drm *, s32, struct nv50_core **);
> +int core907d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp);
> extern const struct nv50_outp_func dac907d;
> extern const struct nv50_outp_func sor907d;
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> index ad1f09a143aa4..d0f2b80a32103 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> @@ -75,18 +75,51 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
> }
>
> int
> -core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> +core507d_read_caps(struct nv50_disp *disp, u32 offset)
> {
> struct nvif_push *push = disp->core->chan.push;
> int ret;
>
> - if ((ret = PUSH_WAIT(push, 2)))
> + ret = PUSH_WAIT(push, 4);
> + if (ret)
> return ret;
>
> + PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL,
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, MODE, WRITE) |
> + NVVAL(NV507D, SET_NOTIFIER_CONTROL, OFFSET, offset >> 2) |
> + NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, ENABLE));
> PUSH_MTHD(push, NV507D, GET_CAPABILITIES, 0x);
Can you send a SET_NOTIFIER_CONTROL_NOTIFY_DISABLE after
GET_CAPABILITIES() too please :)
> +
> return PUSH_KICK(push);
> }
>
> +int
> +core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> +{
> + struct nv50_core *core = disp->core;
> + struct nouveau_bo *bo = disp->sync;
> + s64 time;
> + int ret;
> +
> + NVBO_WR32(bo, NV50_DISP_CAPS_NTFY1, NV_DISP_CORE_NOTIFIER_1,
> CAPABILITIES_1,
> + NVDEF(NV_DISP_CORE_NOTIFIER_1,
> CAPABILITIES_1, DONE, FALSE));
You don't need these NV50_DISP_CAPS_NTFYx thingies. These offsets are
already encoded in NVIDIA's headers
(NV_DISP_CORE_NOTIFIER_1_CAPABILITIES_1 is an offset), you're adding
an additional offset by doing this. Just use NV50_DISP_CORE_NTFY in
all these places, and let NVIDIA's headers do the rest.
The additional offset in these macros are meant for when there's
multiple structures packed into a single nouveau_bo at different
offsets.
It doesn't actually matter here, because it gets divided away. But
for core907d, you're actually rea
Re: [RFC PATCH v7 06/23] bitops: Introduce find_next_or_bit
On 8/28/20 12:51 PM, Julien Desfossez wrote: > +#ifndef find_next_or_bit > +/** > + * find_next_or_bit - find the next set bit in any memory regions > + * @addr1: The first address to base the search on > + * @addr2: The second address to base the search on > + * @offset: The bitnumber to start searching at preferably bit number > + * @size: The bitmap size in bits > + * > + * Returns the bit number for the next set bit * Return: the bit number for the next set bit for kernel-doc syntax. > + * If no bits are set, returns @size. > + */ > +extern unsigned long find_next_or_bit(const unsigned long *addr1, > + const unsigned long *addr2, unsigned long size, > + unsigned long offset); > +#endif thanks. -- ~Randy
Re: [PATCH 4.4 00/61] 4.4.235-rc2 review
On Wed, 2 Sep 2020 at 13:18, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.235 release. > There are 61 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri, 04 Sep 2020 07:47:57 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.235-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.4.235-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 279089e8e4d583d11574ccfa4a5ded543cba96cd git describe: v4.4.234-62-g279089e8e4d5 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.234-62-g279089e8e4d5 No regressions (compared to build v4.4.234) No fixes (compared to build v4.4.234) Ran 17120 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * kselftest * kselftest/drivers * kselftest/filesystems * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * v4l2-compliance * install-android-platform-tools-r2600 * kselftest/net * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * ssuite Summary kernel: 4.4.235-rc2 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.235-rc2-hikey-20200902-803 git commit: 4e984a08e49b4aa772d7681bfaeb091bd7a7b4b9 git describe: 4.4.235-rc2-hikey-20200902-803 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.235-rc2-hikey-20200902-803 No regressions (compared to build 4.4.235-rc1-hikey-20200901-802) No fixes (compared to build 4.4.235-rc1-hikey-20200901-802) Ran 1822 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: Packet gets stuck in NOLOCK pfifo_fast qdisc
Hello, Kehuan
Can you test the attached one-line fix? I think we are overthinking,
probably all
we need here is a busy wait.
Thanks.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index d60e7c39d60c..fc1bacdb102b 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -156,8 +156,7 @@ static inline bool qdisc_is_empty(const struct Qdisc *qdisc)
static inline bool qdisc_run_begin(struct Qdisc *qdisc)
{
if (qdisc->flags & TCQ_F_NOLOCK) {
- if (!spin_trylock(&qdisc->seqlock))
- return false;
+ spin_lock(&qdisc->seqlock);
WRITE_ONCE(qdisc->empty, false);
} else if (qdisc_is_running(qdisc)) {
return false;
Re: linux-next: build failure after merge of the tip tree
Hi Ingo, On Thu, 3 Sep 2020 05:51:08 +0200 Ingo Molnar wrote: > > I've merged the old commit by mistake - it's removed now. Ah, OK, thanks. -- Cheers, Stephen Rothwell pgpqbzuw8G3mY.pgp Description: OpenPGP digital signature
Re: [PATCH] arm64: dts: qcom: sc7180: Add 'sustainable_power' for CPU thermal zones
On 9/2/2020 9:02 PM, Doug Anderson wrote: Hi, On Tue, Sep 1, 2020 at 10:36 PM Rajendra Nayak wrote: * In terms of the numbers here, I believe that you're claiming that we can dissipate 768 mW * 6 + 1202 mW * 2 = ~7 Watts of power. My memory of how much power we could dissipate in previous laptops I worked on is a little fuzzy, but that doesn't seem insane for a passively-cooled laptop. However, I think someone could conceivably put this chip in a smaller form factor. In such a case, it seems like we'd want these things to sum up to ~2000 (if it would ever make sense for someone to put this chip in a phone) or ~4000 (if it would ever make sense for someone to put this chip in a small tablet). It seems possible that, to achieve this, we might have to tweak the "dynamic-power-coefficient". DPC values are calculated (at a SoC) by actually measuring max power at various frequency/voltage combinations by running things like dhrystone. How would the max power a SoC can generate depend on form factors? How much it can dissipate sure is, but then I am not super familiar how thermal frameworks end up using DPC for calculating power dissipated, I am guessing they don't. I don't know how much thought was put into those numbers, but the fact that the little cores have a super round 100 for their dynamic-power-coefficient makes me feel like they might have been more schwags than anything. Rajendra maybe knows? FWIK, the values are always scaled and normalized to 100 for silver and then used to derive the relative DPC number for gold. If you see the DPC for silver cores even on sdm845 is a 100. Again these are not estimations but based on actual power measurements. The scaling to 100 doesn't seem to match how the thermal framework is using them. Take a look at of_cpufreq_cooling_register(). It takes the "dynamic-power-coefficient" and passes it as "capacitance" into __cpufreq_cooling_register(). That's eventually used to compute power, which is documented in the code to be in mW. power = (u64)capacitance * freq_mhz * voltage_mv * voltage_mv; do_div(power, 10); /* power is stored in mW */ freq_table[i].power = power; That's used together with "sustainable-power", which is the attribute that Matthias is trying to set. That value is documented to be in mW as well. ...so if the silver cores are always scaled to 100 regardless of how much power they actually draw then it'll be impossible to actually think about "sustainable-power" as a mW value. Presumably we either need to accept that fact (and ideally document it) or we need to change the values for silver / gold cores (we could still keep the relative values the same and just scale them). That sounds reasonable (still keep the relative values and scale them) I'll get back on what those scaled numbers would look like, and try to get some sense of why this scaling to 100 was done (like you said I don't see any documentation on this), but I see atleast a few other non-qcom SoCs doing this too in mainline (like rockchip/rk3399) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH] HID: i2c-hid: Prefer asynchronous probe
Adding printouts to the i2c_hid_probe() function shows that it takes
quite some time. It used to take about 70 ms, but after commit
eef4016243e9 ("HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON
commands") it takes about 190 ms. This is not tons of time but it's
not trivial. Because we haven't yet specified that we'd prefer
asynchronous probe for this driver then, if the driver is builtin to
the kernel, we'll wait for this driver to finish before we start
probes for more drivers. Let's set the flag to enable asynchronous
for this driver so that other drivers aren't blocked from probing
until we finish.
Since this driver can be configured as a module and modules are
always asynchronously probed this is quite a safe change and will
benefit anyone who has a reason to build this driver into the kernel
instead of using it as a module.
Signed-off-by: Douglas Anderson
---
drivers/hid/i2c-hid/i2c-hid-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 87ff93bf76ba..c898bd8617f9 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -1280,8 +1280,10 @@ static struct i2c_driver i2c_hid_driver = {
.driver = {
.name = "i2c_hid",
.pm = &i2c_hid_pm,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
.acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
.of_match_table = of_match_ptr(i2c_hid_of_match),
+
},
.probe = i2c_hid_probe,
--
2.28.0.402.g5ffc5be6b7-goog
Re: [PATCH v1 02/10] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE on iommu_*_coherent()
On 02/09/2020 08:34, Leonardo Bras wrote: On Mon, 2020-08-31 at 10:47 +1000, Alexey Kardashevskiy wrote: Maybe testing with host 64k pagesize and IOMMU 16MB pagesize in qemu should be enough, is there any chance to get indirect mapping in qemu like this? (DDW but with smaller DMA window available) You will have to hack the guest kernel to always do indirect mapping or hack QEMU's rtas_ibm_query_pe_dma_window() to return a small number of available TCEs. But you will be testing QEMU/KVM which behave quite differently to pHyp in this particular case. As you suggested before, building for 4k cpu pagesize should be the best approach. It would allow testing for both pHyp and qemu scenarios. Because if we want the former (==support), then we'll have to align the size up to the bigger page size when allocating/zeroing system pages, etc. This part I don't understand. Why do we need to align everything to the bigger pagesize? I mean, is not that enough that the range [ret, ret + size[ is both allocated by mm and mapped on a iommu range? Suppose a iommu_alloc_coherent() of 16kB on PAGESIZE = 4k and IOMMU_PAGE_SIZE() == 64k. Why 4 * cpu_pages mapped by a 64k IOMMU page is not enough? All the space the user asked for is allocated and mapped for DMA. The user asked to map 16K, the rest - 48K - is used for something else (may be even mapped to another device) but you are making all 64K accessible by the device which only should be able to access 16K. In practice, if this happens, H_PUT_TCE will simply fail. I have noticed mlx5 driver getting a few bytes in a buffer, and using iommu_map_page(). It does map a whole page for as few bytes as the user Whole 4K system page or whole 64K iommu page? I tested it in 64k system page + 64k iommu page. The 64K system page may be used for anything, and a small portion of it (say 128 bytes) needs to be used for DMA. The whole page is mapped by IOMMU, and the driver gets info of the memory range it should access / modify. This works because the whole system page belongs to the same memory context and IOMMU allows a device to access that page. You can still have problems if there is a bug within the page but it will go mostly unnoticed as it will be memory corruption. If you system page is smaller (4K) than IOMMU page (64K), then the device gets wider access than it should but it is still going to be silent memory corruption. wants mapped, and the other bytes get used for something else, or just mapped on another DMA page. It seems to work fine. With 4K system page and 64K IOMMU page? In practice it would take an effort or/and bad luck to see it crashing. Thanks, I haven't tested it yet. On a 64k system page and 4k/64k iommu page, it works as described above. I am new to this, so I am trying to understand how a memory page mapped as DMA, and used for something else could be a problem. From the device prospective, there is PCI space and everything from 0 till 1<<64 is accessible and what is that mapped to - the device does not know. PHB's IOMMU is the thing to notice invalid access and raise EEH but PHB only knows about PCI->physical memory mapping (with IOMMU pages) but nothing about the host kernel pages. Does this help? Thanks, Thanks! Bigger pages are not the case here as I understand it. I did not get this part, what do you mean? Possible IOMMU page sizes are 4K, 64K, 2M, 16M, 256M, 1GB, and the supported set of sizes is different for P8/P9 and type of IO (PHB, NVLink/CAPI). Update those functions to guarantee alignment with requested size using IOMMU_PAGE_ALIGN() before doing iommu_alloc() / iommu_free(). Also, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift) with IOMMU_PAGE_ALIGN(n, tbl), which seems easier to read. Signed-off-by: Leonardo Bras --- arch/powerpc/kernel/iommu.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index 9704f3f76e63..d7086087830f 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -237,10 +237,9 @@ static unsigned long iommu_range_alloc(struct device *dev, } if (dev) - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, - 1 << tbl->it_page_shift); + boundary_size = IOMMU_PAGE_ALIGN(dma_get_seg_boundary(dev) + 1, tbl); Run checkpatch.pl, should complain about a long line. It's 86 columns long, which is less than the new limit of 100 columns Linus announced a few weeks ago. checkpatch.pl was updated too: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Deprecates-80-Col Yay finally :) Thanks, :) else - boundary_size = ALIGN(1UL << 32, 1 << tbl->it_page_shift); + boundary_size = IOMMU_PAGE_ALIGN(1UL << 32, tbl); /* 4GB boundary for iseries_hv_alloc and iseries_hv_map */ n = iommu_area_
Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET
> On Sep 2, 2020, at 7:53 PM, Yu, Yu-cheng wrote:
>
> On 9/2/2020 4:50 PM, Andy Lutomirski wrote:
On Sep 2, 2020, at 3:13 PM, Yu, Yu-cheng wrote:
>>>
>>> On 9/2/2020 1:03 PM, Jann Horn wrote:
> On Tue, Aug 25, 2020 at 2:30 AM Yu-cheng Yu wrote:
> Add REGSET_CET64/REGSET_CET32 to get/set CET MSRs:
>
> IA32_U_CET (user-mode CET settings) and
> IA32_PL3_SSP (user-mode Shadow Stack)
[...]
> diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c
[...]
> +int cetregs_get(struct task_struct *target, const struct user_regset
> *regset,
> + struct membuf to)
> +{
> + struct fpu *fpu = &target->thread.fpu;
> + struct cet_user_state *cetregs;
> +
> + if (!boot_cpu_has(X86_FEATURE_SHSTK))
> + return -ENODEV;
> +
> + fpu__prepare_read(fpu);
> + cetregs = get_xsave_addr(&fpu->state.xsave, XFEATURE_CET_USER);
> + if (!cetregs)
> + return -EFAULT;
Can this branch ever be hit without a kernel bug? If yes, I think
-EFAULT is probably a weird error code to choose here. If no, this
should probably use WARN_ON(). Same thing in cetregs_set().
>>>
>>> When a thread is not CET-enabled, its CET state does not exist. I looked
>>> at EFAULT, and it means "Bad address". Maybe this can be ENODEV, which
>>> means "No such device"?
Having read the code, I’m unconvinced. It looks like a get_xsave_addr() failure
means “state not saved; task sees INIT state”. So *maybe* it’s reasonable
-ENODEV this, but I’m not really convinced. I tend to think we should return
the actual INIT state and that we should permit writes and handle them
correctly.
Dave, what do you think?
>>>
>>> [...]
>>>
> @@ -1284,6 +1293,13 @@ static struct user_regset x86_32_regsets[]
> __ro_after_init = {
[...]
> + [REGSET_CET32] = {
> + .core_note_type = NT_X86_CET,
> + .n = sizeof(struct cet_user_state) / sizeof(u64),
> + .size = sizeof(u64), .align = sizeof(u64),
> + .active = cetregs_active, .regset_get = cetregs_get,
> + .set = cetregs_set
> + },
> };
Why are there different identifiers for 32-bit CET and 64-bit CET when
they operate on the same structs and have the same handlers? If
there's a good reason for that, the commit message should probably
point that out.
>>>
>>> Yes, the reason for two regsets is that fill_note_info() does not expect
>>> any holes in a regsets. I will put this in the commit log.
>>>
>>>
>> Perhaps we could fix that instead?
>
> As long as we understand the root cause, leaving it as-is may be OK.
The regset mechanism’s interactions with compat are awful. Let’s please not
make it worse. One CET regret is good; two is not good.
>
> I had a patch in the past, but did not follow up on it.
>
> https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng...@intel.com/
>
> Yu-cheng
Re: [RFC PATCH v7 17/23] kernel/entry: Add support for core-wide protection of kernel-mode
On Wed, Sep 2, 2020 at 12:57 PM Dario Faggioli wrote: > > On Wed, 2020-09-02 at 09:53 +0200, Thomas Gleixner wrote: > > On Tue, Sep 01 2020 at 21:29, Joel Fernandes wrote: > > > On Tue, Sep 01, 2020 at 10:02:10PM +0200, Thomas Gleixner wrote: > > > > > > > Or, are you saying users may want 'core scheduling' enabled but may > > > want to > > > leave out the kernel protection? > > > > Core scheduling per se without all the protection muck, i.e. a > > relaxed > > version which tries to gang schedule threads of a process on a core > > if > > feasible has advantages to some workloads. > > > Indeed! For at least two reasons, IMO: > > 1) what Thomas is saying already. I.e., even on a CPU which has HT but > is not affected by any of the (known!) speculation issues, one may want > to use Core Scheduling _as_a_feature_. For instance, for avoiding > threads from different processes, or vCPUs from different VMs, sharing > cores (e.g., for better managing their behavior/performance, or for > improved fairness of billing/accounting). And in this case, this > mechanism for protecting the kernel from the userspace on the other > thread may not be necessary or interesting; Agreed. So then I should really make this configurable and behind a sysctl then. I'll do that. > 2) protection of the kernel from the other thread running in userspace > may be achieved in different ways. This is one, sure. ASI will probably > be another. Hence if/when we'll have both, this and ASI, it would be > cool to be able to configure the system in such a way that there is > only one active, to avoid paying the price of both! :-) Actually, no. Part of ASI will involve exactly what this patch does - IPI-pausing siblings but ASI does so when they have no choice but to switch away from the "limited kernel" mapping, into the full host kernel mapping. I am not sure if they have yet implemented that part but they do talk of it in [1] and in their pretty LPC slides. It is just that ASI tries to avoid that scenario of kicking all siblings out of guest mode. So, maybe this patch can be a stepping stone to ASI. At least I got the entry hooks right, and the algorithm is efficient IMO (useless IPIs are avoided). ASI can then come in and avoid sending IPIs even more by doing their limited-kernel-mapping things if needed. So, it does not need to be this vs ASI, both may be needed. Why do you feel that ASI on its own offers some magical protection that eliminates the need for this patch? thanks, - Joel [1] The link https://lkml.org/lkml/2019/5/13/515 mentions "note that kicking all sibling hyperthreads is not implemented in this serie"
Re: [PATCH v1 01/10] powerpc/pseries/iommu: Replace hard-coded page shift
On 02/09/2020 07:38, Leonardo Bras wrote: On Mon, 2020-08-31 at 13:48 +1000, Alexey Kardashevskiy wrote: Well, I created this TCE_RPN_BITS = 52 because the previous mask was a hardcoded 40-bit mask (0xfful), for hard-coded 12-bit (4k) pagesize, and on PAPR+/LoPAR also defines TCE as having bits 0-51 described as RPN, as described before. IODA3 Revision 3.0_prd1 (OpenPowerFoundation), Figure 3.4 and 3.5. shows system memory mapping into a TCE, and the TCE also has bits 0-51 for the RPN (52 bits). "Table 3.6. TCE Definition" also shows it. In fact, by the looks of those figures, the RPN_MASK should always be a 52-bit mask, and RPN = (page >> tceshift) & RPN_MASK. I suspect the mask is there in the first place for extra protection against too big addresses going to the TCE table (or/and for virtial vs physical addresses). Using 52bit mask makes no sense for anything, you could just drop the mask and let c compiler deal with 64bit "uint" as it is basically a 4K page address anywhere in the 64bit space. Thanks, Assuming 4K pages you need 52 RPN bits to cover the whole 64bit physical address space. The IODA3 spec does explicitly say the upper bits are optional and the implementation only needs to support enough to cover up to the physical address limit, which is 56bits of P9 / PHB4. If you want to validate that the address will fit inside of MAX_PHYSMEM_BITS then fine, but I think that should be done as a WARN_ON or similar rather than just silently masking off the bits. We can do this and probably should anyway but I am also pretty sure we can just ditch the mask and have the hypervisor return an error which will show up in dmesg. Ok then, ditching the mask. Well, you could run a little experiment and set some bits above that old mask and see how phyp reacts :) Thanks! -- Alexey
Re: [PATCH net-next v2 3/3] net: dp83869: Add speed optimization feature
Hi Dan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/DP83869-Feature-additions/20200903-043618
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
dc1a9bf2c8169d9f607502162af1858a73a18cb8
config: i386-randconfig-m021-20200902 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/net/phy/dp83869.c:669 dp83869_config_init() warn: inconsistent indenting
#
https://github.com/0day-ci/linux/commit/307ae0a0e8406ceadb72d448df96322bbd23aa92
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dan-Murphy/DP83869-Feature-additions/20200903-043618
git checkout 307ae0a0e8406ceadb72d448df96322bbd23aa92
vim +669 drivers/net/phy/dp83869.c
662
663 static int dp83869_config_init(struct phy_device *phydev)
664 {
665 struct dp83869_private *dp83869 = phydev->priv;
666 int ret, val;
667
668 /* Force speed optimization for the PHY even if it strapped */
> 669 ret = phy_modify(phydev, DP83869_CFG2, DP83869_DOWNSHIFT_EN,
670 DP83869_DOWNSHIFT_EN);
671 if (ret)
672 return ret;
673
674 ret = dp83869_configure_mode(phydev, dp83869);
675 if (ret)
676 return ret;
677
678 /* Enable Interrupt output INT_OE in CFG4 register */
679 if (phy_interrupt_is_valid(phydev)) {
680 val = phy_read(phydev, DP83869_CFG4);
681 val |= DP83869_INT_OE;
682 phy_write(phydev, DP83869_CFG4, val);
683 }
684
685 if (dp83869->port_mirroring != DP83869_PORT_MIRRORING_KEEP)
686 dp83869_config_port_mirroring(phydev);
687
688 /* Clock output selection if muxing property is set */
689 if (dp83869->clk_output_sel != DP83869_CLK_O_SEL_REF_CLK)
690 ret = phy_modify_mmd(phydev,
691 DP83869_DEVADDR,
DP83869_IO_MUX_CFG,
692 DP83869_IO_MUX_CFG_CLK_O_SEL_MASK,
693 dp83869->clk_output_sel <<
694
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
695
696 if (phy_interface_is_rgmii(phydev)) {
697 ret = phy_write_mmd(phydev, DP83869_DEVADDR,
DP83869_RGMIIDCTL,
698 dp83869->rx_int_delay |
699 dp83869->tx_int_delay <<
DP83869_RGMII_CLK_DELAY_SHIFT);
700 if (ret)
701 return ret;
702
703 val = phy_read_mmd(phydev, DP83869_DEVADDR,
DP83869_RGMIICTL);
704 val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN |
705 DP83869_RGMII_RX_CLK_DELAY_EN);
706
707 if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
708 val |= (DP83869_RGMII_TX_CLK_DELAY_EN |
709 DP83869_RGMII_RX_CLK_DELAY_EN);
710
711 if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
712 val |= DP83869_RGMII_TX_CLK_DELAY_EN;
713
714 if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
715 val |= DP83869_RGMII_RX_CLK_DELAY_EN;
716
717 ret = phy_write_mmd(phydev, DP83869_DEVADDR,
DP83869_RGMIICTL,
718 val);
719 }
720
721 return ret;
722 }
723
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH RESEND 2/2] Revert "clk: qcom: Support 'protected-clocks' property"
Now that protected-clocks is handled in the clk core, this
driver-specific implementation is redundant.
This reverts commit b181b3b801da8893c8eb706e448dd5111b02de60.
Signed-off-by: Samuel Holland
---
drivers/clk/qcom/common.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index 60d2a78d1395..6e150fd32dbe 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -194,22 +194,6 @@ int qcom_cc_register_sleep_clk(struct device *dev)
}
EXPORT_SYMBOL_GPL(qcom_cc_register_sleep_clk);
-/* Drop 'protected-clocks' from the list of clocks to register */
-static void qcom_cc_drop_protected(struct device *dev, struct qcom_cc *cc)
-{
- struct device_node *np = dev->of_node;
- struct property *prop;
- const __be32 *p;
- u32 i;
-
- of_property_for_each_u32(np, "protected-clocks", prop, p, i) {
- if (i >= cc->num_rclks)
- continue;
-
- cc->rclks[i] = NULL;
- }
-}
-
static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec,
void *data)
{
@@ -272,8 +256,6 @@ int qcom_cc_really_probe(struct platform_device *pdev,
cc->rclks = rclks;
cc->num_rclks = num_clks;
- qcom_cc_drop_protected(dev, cc);
-
for (i = 0; i < num_clk_hws; i++) {
ret = devm_clk_hw_register(dev, clk_hws[i]);
if (ret)
--
2.26.2
[PATCH RESEND 0/2] Common protected-clocks implementation
Stephen, Maxime, You previously asked me to implement the protected-clocks property in a driver-independent way: https://www.spinics.net/lists/arm-kernel/msg753832.html I provided an implementation 6 months ago, which I am resending now: https://patchwork.kernel.org/patch/11398629/ Do you have any comments on it? Thanks, Samuel Samuel Holland (2): clk: Implement protected-clocks for all OF clock providers Revert "clk: qcom: Support 'protected-clocks' property" drivers/clk/clk-conf.c| 54 +++ drivers/clk/clk.c | 31 ++ drivers/clk/clk.h | 2 ++ drivers/clk/qcom/common.c | 18 - 4 files changed, 87 insertions(+), 18 deletions(-) -- 2.26.2
[PATCH RESEND 1/2] clk: Implement protected-clocks for all OF clock providers
This is a generic implementation of the "protected-clocks" property from
the common clock binding. It allows firmware to inform the OS about
clocks that must not be disabled while the OS is running.
This implementation comes with some caveats:
1) Clocks that have CLK_IS_CRITICAL in their init data are prepared/
enabled before they are attached to the clock tree. protected-clocks are
only protected once the clock provider is added, which is generally
after all of the clocks it provides have been registered. This leaves a
window of opportunity where something could disable or modify the clock,
such as a driver running on another CPU, or the clock core itself. There
is a comment to this effect in __clk_core_init():
/*
* Enable CLK_IS_CRITICAL clocks so newly added critical clocks
* don't get accidentally disabled when walking the orphan tree and
* reparenting clocks
*/
Similarly, these clocks will be enabled after they are first reparented,
unlike other CLK_IS_CRITICAL clocks. See the comment in
clk_core_reparent_orphans_nolock():
/*
* We need to use __clk_set_parent_before() and _after() to
* to properly migrate any prepare/enable count of the orphan
* clock. This is important for CLK_IS_CRITICAL clocks, which
* are enabled during init but might not have a parent yet.
*/
Ideally we could detect protected clocks before they are reparented, but
there are two problems with that:
a) From the clock core's perspective, hw->init is const.
b) The clock core doesn't see the device_node until __clk_register is
called on the first clock.
So the only "race-free" way to detect protected-clocks is to do it in
the middle of __clk_register, between when core->flags is initialized
and calling __clk_core_init(). That requires scanning the device tree
again for each clock, which is part of why I didn't do it that way.
2) __clk_protect needs to be idempotent, for two reasons:
a) Clocks with CLK_IS_CRITICAL in their init data are already
prepared/enabled, and we don't want to prepare/enable them again.
b) of_clk_set_defaults() is called twice for (at least some) clock
controllers registered with CLK_OF_DECLARE. It is called first in
of_clk_add_provider()/of_clk_add_hw_provider() inside clk_init_cb,
and again afterward in of_clk_init(). The second call in
of_clk_init() may be unnecessary, but verifying that would require
auditing all users of CLK_OF_DECLARE to ensure they called one of
the of_clk_add{,_hw}_provider functions.
Signed-off-by: Samuel Holland
---
drivers/clk/clk-conf.c | 54 ++
drivers/clk/clk.c | 31
drivers/clk/clk.h | 2 ++
3 files changed, 87 insertions(+)
diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c
index 2ef819606c41..a57d28b0f397 100644
--- a/drivers/clk/clk-conf.c
+++ b/drivers/clk/clk-conf.c
@@ -11,6 +11,54 @@
#include
#include
+#include "clk.h"
+
+static int __set_clk_flags(struct device_node *node)
+{
+ struct of_phandle_args clkspec;
+ struct property *prop;
+ int i, index = 0, rc;
+ const __be32 *cur;
+ struct clk *clk;
+ u32 nr_cells;
+
+ rc = of_property_read_u32(node, "#clock-cells", &nr_cells);
+ if (rc < 0) {
+ pr_err("clk: missing #clock-cells property on %pOF\n", node);
+ return rc;
+ }
+
+ clkspec.np = node;
+ clkspec.args_count = nr_cells;
+
+ of_property_for_each_u32(node, "protected-clocks", prop, cur,
clkspec.args[0]) {
+ /* read the remainder of the clock specifier */
+ for (i = 1; i < nr_cells; ++i) {
+ cur = of_prop_next_u32(prop, cur, &clkspec.args[i]);
+ if (!cur) {
+ pr_err("clk: invalid value of protected-clocks"
+ " property at %pOF\n", node);
+ return -EINVAL;
+ }
+ }
+ clk = of_clk_get_from_provider(&clkspec);
+ if (IS_ERR(clk)) {
+ if (PTR_ERR(clk) != -EPROBE_DEFER)
+ pr_err("clk: couldn't get protected clock"
+ " %u for %pOF\n", index, node);
+ return PTR_ERR(clk);
+ }
+
+ rc = __clk_protect(clk);
+ if (rc < 0)
+ pr_warn("clk: failed to protect %s: %d\n",
+ __clk_get_name(clk), rc);
+ clk_put(clk);
+ index++;
+ }
+ return 0;
+}
+
static int __set_clk_parents(struct device_node *node, bool clk_supplier)
{
struct of_phandle_args clkspec;
@@ -135,6 +183,12 @@ int of_clk_set_defaults(struct device_node *node, bool
clk_supplier)
if (!node)
return 0;
+ if (clk_supplier) {
+
Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
On Sat, Aug 29, 2020 at 01:09:43PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 8/29/20 2:49 AM, Rich Felker wrote:
> > This restored my ability to use strace
>
> I can confirm that. However ...
>
> > and I've written and tested a minimal strace-like hack using
> > SECCOMP_RET_USER_NOTIF that works as
> > expected on both j2 and qemu-system-sh4, so I think the above is
> > correct.
>
> The seccomp live testsuite has regressed.
>
> With your patch:
>
> === Sat 29 Aug 2020 12:35:52 PM CEST ===
> Regression Test Report ("regression -T live")
> batch name: 01-sim-allow
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 02-sim-basic
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 03-sim-basic_chains
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 04-sim-multilevel_chains
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 05-sim-long_jumps
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 06-sim-actions
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 07-sim-db_bug_looping
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 08-sim-subtree_checks
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 09-sim-syscall_priority_pre
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 10-sim-syscall_priority_post
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 11-basic-basic_errors
> test mode: c
> test type: basic
> batch name: 12-sim-basic_masked_ops
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 13-basic-attrs
> test mode: c
> test type: basic
> batch name: 14-sim-reset
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 15-basic-resolver
> test mode: c
> test type: basic
> batch name: 16-sim-arch_basic
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 17-sim-arch_merge
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 18-sim-basic_allowlist
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 19-sim-missing_syscalls
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 20-live-basic_die
> test mode: c
> test type: live
> Test 20-live-basic_die%%001-1 result: SUCCESS
> Test 20-live-basic_die%%002-1 result: SUCCESS
> Test 20-live-basic_die%%003-1 result: FAILURE 20-live-basic_die 1 ERRNO
> rc=38
> batch name: 21-live-basic_allow
> test mode: c
> test type: live
> Test 21-live-basic_allow%%001-1 result: SUCCESS
> batch name: 22-sim-basic_chains_array
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 23-sim-arch_all_le_basic
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 24-live-arg_allow
> test mode: c
> test type: live
> Test 24-live-arg_allow%%001-1 result: SUCCESS
> batch name: 25-sim-multilevel_chains_adv
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 26-sim-arch_all_be_basic
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 27-sim-bpf_blk_state
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-sim-fuzz
> test mode: c
> test type: bpf-valgrind
> batch name: 28-sim-arch_x86
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 29-sim-pseudo_syscall
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 30-sim-socket_syscalls
> test mode: c
> test type: bpf-sim
> test mode: c
> test type: bpf-valgrind
> batch name: 31-basic-version_check
> test mode:
Re: linux-next: build failure after merge of the tip tree
* Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
>
> Caused by commit
>
> f670269a42bf ("x86: Fix early boot crash on gcc-10, next try")
>
> interacting with commit
>
> a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
>
> from Linus' tree (v5.7-rc6) - the automatic merge did not go well.
>
> I have added this patch for today (it removes the older version).
>
> From: Stephen Rothwell
> Date: Thu, 3 Sep 2020 12:31:13 +1000
> Subject: [PATCH] merge fix for compiler.h
I've merged the old commit by mistake - it's removed now.
Thanks,
Ingo
Re: [PATCH v3] staging: qlge: fix build breakage with dumping enabled
On 2020-09-02 22:00 +0800, Coiby Xu wrote:
> This fixes commit 0107635e15ac
> ("staging: qlge: replace pr_err with netdev_err") which introduced an
> build breakage of missing `struct ql_adapter *qdev` for some functions
> and a warning of type mismatch with dumping enabled, i.e.,
>
> $ make CFLAGS_MODULE="QL_ALL_DUMP=1 QL_OB_DUMP=1 QL_CB_DUMP=1 \
> QL_IB_DUMP=1 QL_REG_DUMP=1 QL_DEV_DUMP=1" M=drivers/staging/qlge
>
> qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’:
> qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this function);
> did you mean ‘cdev’?
> 2051 | netdev_err(qdev->ndev, "%s\n", __func__);
> | ^~~~
> qlge_dbg.c: In function ‘ql_dump_routing_entries’:
> qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char *’,
> but argument 3 has type ‘int’ [-Wformat=]
> 1435 |"%s: Routing Mask %d = 0x%.08x\n",
> | ~^
> | |
> | char *
> | %d
> 1436 |i, value);
> |~
> ||
> |int
> qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned int’
> argument [-Wformat=]
> 1435 |"%s: Routing Mask %d = 0x%.08x\n",
> | ^
> | |
> | unsigned int
>
> Fixes: 0107635e15ac ("staging: qlge: replace pr_err with netdev_err")
> Reported-by: Benjamin Poirier
> Suggested-by: Benjamin Poirier
> Signed-off-by: Coiby Xu
> ---
Thanks for following up on this issue.
[...]
> @@ -1632,8 +1635,8 @@ void ql_dump_wqicb(struct wqicb *wqicb)
>
> void ql_dump_tx_ring(struct tx_ring *tx_ring)
> {
> - if (!tx_ring)
> - return;
> + struct ql_adapter *qdev = tx_ring->qdev;
> +
> netdev_err(qdev->ndev, "= Dumping tx_ring %d
> ===\n",
> tx_ring->wq_id);
> netdev_err(qdev->ndev, "tx_ring->base = %p\n", tx_ring->wq_base);
Did you actually check to confirm that the test can be removed?
This is something that you should mention in the changelog at the very
least since that change is not directly about fixing the build breakage
and if it's wrong, it can lead to null pointer deref.
Re: Boot failure on gru-scarlet-inx with 5.9-rc2
On Wed, 2 Sep 2020 17:01:19 +0100
Lorenzo Pieralisi wrote:
> On Tue, Sep 01, 2020 at 02:33:56PM -0400, Samuel Dionne-Riel wrote:
>
> Please print a pointer as a pointer and print both bus and
> bus->parent.
Hopefully pointer as a pointer is %px. Not sure what else, if that's
wrong please tell.
---
@@ -79,6 +79,8 @@ static int rockchip_pcie_valid_device(struct rockchip_pcie
*rockchip,
* do not read more than one device on the bus directly attached
* to RC's downstream side.
*/
+ printk("[!!] // bus (%px) bus->parent (%px)\n", bus, bus->parent);
+ printk("[!!] bus->primary (%d) == rockchip->root_bus_nr (%d) && dev
(%d) > 0\n", bus->primary, rockchip->root_bus_nr, dev);
if (bus->primary == rockchip->root_bus_nr && dev > 0)
return 0;
--
Again, two values, verified with a bit of set and `sort -u`.
[1.691266] [!!] // bus (ef9ab800) bus->parent ()
[1.691271] [!!] bus->primary (0) == rockchip->root_bus_nr (0) && dev (0) > 0
and
[1.697156] [!!] // bus (ef9ac000) bus->parent (ef9ab800)
[1.697160] [!!] bus->primary (0) == rockchip->root_bus_nr (0) && dev (0) > 0
First instance of each shown here. Last time I don't think it was.
> > + printk("[!!] bus->primary (%d) == rockchip->root_bus_nr
> > (%d) && dev (%d) > 0\n", bus->primary, rockchip->root_bus_nr, dev);
> > if (bus->primary == rockchip->root_bus_nr && dev > 0) return 0;
> >
> > --
> >
> > I get two kind of results
> >
> > [1.692913] [!!] // bus->parent (0)
> > [1.692917] [!!] bus->primary (0) == rockchip->root_bus_nr (0)
> > && dev (0) > 0
> >
> > and
> >
> > [1.693055] [!!] // bus->parent (-256794624)
> > [1.693058] [!!] bus->primary (0) == rockchip->root_bus_nr (0)
> > && dev (0) > 0
>
> Looks like this is the condition that pci_is_root_bus(bus->parent) is
> not hitting.
>
> You are accessing a resource IORESOURCE_MEM that has nothing to do
> with bus numbers.
>
> s/IORESOURCE_MEM/IORESOURCE_BUS
>
> should be better ;-)
At least correct, rather than luckily working.
Thanks, as always, anything I missed, or need more precisions, do ask.
--
Samuel Dionne-Riel
Re: [PATCH 1/2] dma-mapping: introduce dma_get_seg_boundary_nr_pages()
Nicolin Chen writes: > diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c > index 9704f3f76e63..cbc2e62db597 100644 > --- a/arch/powerpc/kernel/iommu.c > +++ b/arch/powerpc/kernel/iommu.c > @@ -236,15 +236,10 @@ static unsigned long iommu_range_alloc(struct device > *dev, > } > } > > - if (dev) > - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, > - 1 << tbl->it_page_shift); > - else > - boundary_size = ALIGN(1UL << 32, 1 << tbl->it_page_shift); > - /* 4GB boundary for iseries_hv_alloc and iseries_hv_map */ > + boundary_size = dma_get_seg_boundary_nr_pages(dev, tbl->it_page_shift); > > n = iommu_area_alloc(tbl->it_map, limit, start, npages, tbl->it_offset, > - boundary_size >> tbl->it_page_shift, align_mask); > + boundary_size, align_mask); This has changed the units of boundary_size, but it's unused elsewhere in the function so that's OK. If you need to do a v2 for any other reason, then I'd just drop boundary_size and call dma_get_seg_boundary_nr_pages() directly in the function call. Acked-by: Michael Ellerman (powerpc) cheers
[PATCH v4 2/3] scsi: 3w-9xxx: Reduce scope of structure packing
Currently, all command packet structs used by this driver are packed.
However, only one (TW_SG_Entry) actually needs to be packed, because it
uses 64-bit addresses at 32-bit alignment. To improve the quality of
generated code, stop packing all of the other command packet structs.
This requires adjusting the type of one misaligned "reserved" member.
After this change, pahole reports that only one type had its layout
change: the tw_compat_info member of TW_Device_Extension is now
naturally aligned.
Signed-off-by: Samuel Holland
---
Changes since v3: None.
---
drivers/scsi/3w-9xxx.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h
index e65dafda2e3e..36b865eca67d 100644
--- a/drivers/scsi/3w-9xxx.h
+++ b/drivers/scsi/3w-9xxx.h
@@ -471,13 +471,17 @@ printk(KERN_WARNING "3w-9xxx: ERROR: (0x%02X:0x%04X):
%s.\n",a,b,c); \
#define TW_PADDING_LENGTH (sizeof(dma_addr_t) > 4 ? 8 : 0)
#define TW_CPU_TO_SGL(x) (sizeof(dma_addr_t) > 4 ? cpu_to_le64(x) :
cpu_to_le32(x))
-#pragma pack(1)
+#if IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT)
+typedef u64 twa_addr_t;
+#else
+typedef u32 twa_addr_t;
+#endif
/* Scatter Gather List Entry */
typedef struct TAG_TW_SG_Entry {
- dma_addr_t address;
+ twa_addr_t address;
u32 length;
-} TW_SG_Entry;
+} __packed TW_SG_Entry;
/* Command Packet */
typedef struct TW_Command {
@@ -496,12 +500,12 @@ typedef struct TW_Command {
struct {
u32 lba;
TW_SG_Entry sgl[TW_ESCALADE_MAX_SGL_LENGTH];
- dma_addr_t padding;
+ twa_addr_t padding;
} io;
struct {
TW_SG_Entry sgl[TW_ESCALADE_MAX_SGL_LENGTH];
u32 padding;
- dma_addr_t padding2;
+ twa_addr_t padding2;
} param;
} byte8_offset;
} TW_Command;
@@ -531,7 +535,7 @@ typedef struct TAG_TW_Command_Apache_Header {
unsigned char err_specific_desc[98];
struct {
unsigned char size_header;
- unsigned short reserved;
+ unsigned char reserved[2];
unsigned char size_sense;
} header_desc;
} TW_Command_Apache_Header;
@@ -631,8 +635,6 @@ typedef struct TAG_TW_Compatibility_Info
unsigned short fw_on_ctlr_build;
} TW_Compatibility_Info;
-#pragma pack()
-
typedef struct TAG_TW_Device_Extension {
u32 __iomem *base_addr;
unsigned long *generic_buffer_virt[TW_Q_LENGTH];
--
2.26.2
[PATCH v4 3/3] scsi: 3w-9xxx: Fix endianness issues in command packets
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
---
Changes since v3: None.
---
drivers/scsi/3w-9xxx.c | 56 ++---
drivers/scsi/3w-9xxx.h | 111 +
2 files changed, 81 insertions(+), 86 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index aad9b3b73e15..593863317dc7 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -303,10 +303,10 @@ static int twa_aen_drain_queue(TW_Device_Extension
*tw_dev, int no_check_reset)
/* Initialize sglist */
memset(&sglist, 0, sizeof(TW_SG_Entry));
- sglist[0].length = TW_SECTOR_SIZE;
- sglist[0].address = tw_dev->generic_buffer_phys[request_id];
+ sglist[0].length = cpu_to_le32(TW_SECTOR_SIZE);
+ sglist[0].address =
TW_CPU_TO_SGL(tw_dev->generic_buffer_phys[request_id]);
- if (sglist[0].address & TW_ALIGNMENT_9000_SGL) {
+ if (tw_dev->generic_buffer_phys[request_id] & TW_ALIGNMENT_9000_SGL) {
TW_PRINTK(tw_dev->host, TW_DRIVER, 0x1, "Found unaligned
address during AEN drain");
goto out;
}
@@ -440,8 +440,8 @@ static int twa_aen_read_queue(TW_Device_Extension *tw_dev,
int request_id)
/* Initialize sglist */
memset(&sglist, 0, sizeof(TW_SG_Entry));
- sglist[0].length = TW_SECTOR_SIZE;
- sglist[0].address = tw_dev->generic_buffer_phys[request_id];
+ sglist[0].length = cpu_to_le32(TW_SECTOR_SIZE);
+ sglist[0].address =
TW_CPU_TO_SGL(tw_dev->generic_buffer_phys[request_id]);
/* Mark internal command */
tw_dev->srb[request_id] = NULL;
@@ -501,9 +501,8 @@ static void twa_aen_sync_time(TW_Device_Extension *tw_dev,
int request_id)
Sunday 12:00AM */
local_time = (ktime_get_real_seconds() - (sys_tz.tz_minuteswest * 60));
div_u64_rem(local_time - (3 * 86400), 604800, &schedulertime);
- schedulertime = cpu_to_le32(schedulertime % 604800);
- memcpy(param->data, &schedulertime, sizeof(u32));
+ memcpy(param->data, &(__le32){cpu_to_le32(schedulertime)},
sizeof(__le32));
/* Mark internal command */
tw_dev->srb[request_id] = NULL;
@@ -1004,19 +1003,13 @@ static int twa_fill_sense(TW_Device_Extension *tw_dev,
int request_id, int copy_
if (print_host)
printk(KERN_WARNING "3w-9xxx: scsi%d: ERROR:
(0x%02X:0x%04X): %s:%s.\n",
tw_dev->host->host_no,
- TW_MESSAGE_SOURCE_CONTROLLER_ERROR,
- full_command_packet->header.status_block.error,
- error_str[0] == '\0' ?
- twa_string_lookup(twa_error_table,
-
full_command_packet->header.status_block.error) : error_str,
+ TW_MESSAGE_SOURCE_CONTROLLER_ERROR, error,
+ error_str[0] ? error_str :
twa_string_lookup(twa_error_table, error),
full_command_packet->header.err_specific_desc);
else
printk(KERN_WARNING "3w-9xxx: ERROR: (0x%02X:0x%04X):
%s:%s.\n",
- TW_MESSAGE_SOURCE_CONTROLLER_ERROR,
- full_command_packet->header.status_block.error,
- error_str[0] == '\0' ?
- twa_string_lookup(twa_error_table,
-
full_command_packet->header.status_block.error) : error_str,
+ TW_MESSAGE_SOURCE_CONTROLLER_ERROR, error,
+ error_str[0] ? error_str :
twa_string_lookup(twa_error_table, error),
full_command_packet->header.err_specific_desc);
}
@@ -1133,12 +1126,11 @@ static int twa_initconnection(TW_Device_Extension
*tw_dev, int message_credits,
tw_initconnect->opcode__reserved = TW_OPRES_IN(0,
TW_OP_INIT_CONNECTION);
tw_initconnect->request_id = request_id;
tw_initconnect->message_credits = cpu_to_le16(message_credits);
- tw_initconnect->features = set_features;
/* Turn on 64-bit sgl support if we need to */
- tw_initconnect->features |= sizeof(dma_addr_t) > 4 ? 1 : 0;
+ set_features |= sizeof(dma_addr_t) > 4 ?
[PATCH v4 1/3] scsi: 3w-9xxx: Use flexible array members to avoid struct padding
In preparation for removing the "#pragma pack(1)" from the driver, fix
all instances where a trailing array member could be replaced by a
flexible array member. Since a flexible array member has zero size, it
introduces no padding, whether or not the struct is packed.
Signed-off-by: Samuel Holland
---
Changes since v3:
- Consistently put sizeof(TW_Ioctl_Buf_Apache) before buffer_length.
---
drivers/scsi/3w-9xxx.c | 16 ++--
drivers/scsi/3w-9xxx.h | 4 ++--
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index 3337b1e80412..aad9b3b73e15 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -676,7 +676,9 @@ static long twa_chrdev_ioctl(struct file *file, unsigned
int cmd, unsigned long
data_buffer_length_adjusted = (driver_command.buffer_length + 511) &
~511;
/* Now allocate ioctl buf memory */
- cpu_addr = dma_alloc_coherent(&tw_dev->tw_pci_dev->dev,
data_buffer_length_adjusted+sizeof(TW_Ioctl_Buf_Apache) - 1, &dma_handle,
GFP_KERNEL);
+ cpu_addr = dma_alloc_coherent(&tw_dev->tw_pci_dev->dev,
+ sizeof(TW_Ioctl_Buf_Apache) +
data_buffer_length_adjusted,
+ &dma_handle, GFP_KERNEL);
if (!cpu_addr) {
retval = TW_IOCTL_ERROR_OS_ENOMEM;
goto out2;
@@ -685,7 +687,7 @@ static long twa_chrdev_ioctl(struct file *file, unsigned
int cmd, unsigned long
tw_ioctl = (TW_Ioctl_Buf_Apache *)cpu_addr;
/* Now copy down the entire ioctl */
- if (copy_from_user(tw_ioctl, argp, driver_command.buffer_length +
sizeof(TW_Ioctl_Buf_Apache) - 1))
+ if (copy_from_user(tw_ioctl, argp, sizeof(TW_Ioctl_Buf_Apache) +
driver_command.buffer_length))
goto out3;
/* See which ioctl we are doing */
@@ -867,11 +869,13 @@ static long twa_chrdev_ioctl(struct file *file, unsigned
int cmd, unsigned long
}
/* Now copy the entire response to userspace */
- if (copy_to_user(argp, tw_ioctl, sizeof(TW_Ioctl_Buf_Apache) +
driver_command.buffer_length - 1) == 0)
+ if (copy_to_user(argp, tw_ioctl, sizeof(TW_Ioctl_Buf_Apache) +
driver_command.buffer_length) == 0)
retval = 0;
out3:
/* Now free ioctl buf memory */
- dma_free_coherent(&tw_dev->tw_pci_dev->dev,
data_buffer_length_adjusted+sizeof(TW_Ioctl_Buf_Apache) - 1, cpu_addr,
dma_handle);
+ dma_free_coherent(&tw_dev->tw_pci_dev->dev,
+ sizeof(TW_Ioctl_Buf_Apache) +
data_buffer_length_adjusted,
+ cpu_addr, dma_handle);
out2:
mutex_unlock(&tw_dev->ioctl_lock);
out:
@@ -1392,7 +1396,7 @@ static void twa_load_sgl(TW_Device_Extension *tw_dev,
TW_Command_Full *full_comm
newcommand->request_id__lunl =
cpu_to_le16(TW_REQ_LUN_IN(TW_LUN_OUT(newcommand->request_id__lunl),
request_id));
if (length) {
- newcommand->sg_list[0].address =
TW_CPU_TO_SGL(dma_handle + sizeof(TW_Ioctl_Buf_Apache) - 1);
+ newcommand->sg_list[0].address =
TW_CPU_TO_SGL(dma_handle + sizeof(TW_Ioctl_Buf_Apache));
newcommand->sg_list[0].length = cpu_to_le32(length);
}
newcommand->sgl_entries__lunh =
@@ -1407,7 +1411,7 @@ static void twa_load_sgl(TW_Device_Extension *tw_dev,
TW_Command_Full *full_comm
sgl = (TW_SG_Entry *)((u32
*)oldcommand+oldcommand->size - (sizeof(TW_SG_Entry)/4) + pae);
else
sgl = (TW_SG_Entry *)((u32
*)oldcommand+TW_SGL_OUT(oldcommand->opcode__sgloffset));
- sgl->address = TW_CPU_TO_SGL(dma_handle +
sizeof(TW_Ioctl_Buf_Apache) - 1);
+ sgl->address = TW_CPU_TO_SGL(dma_handle +
sizeof(TW_Ioctl_Buf_Apache));
sgl->length = cpu_to_le32(length);
oldcommand->size += pae;
diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h
index d88cd3499bd5..e65dafda2e3e 100644
--- a/drivers/scsi/3w-9xxx.h
+++ b/drivers/scsi/3w-9xxx.h
@@ -588,7 +588,7 @@ typedef struct TAG_TW_Ioctl_Apache {
TW_Ioctl_Driver_Command driver_command;
char padding[488];
TW_Command_Full firmware_command;
- char data_buffer[1];
+ char data_buffer[];
} TW_Ioctl_Buf_Apache;
/* Lock structure for ioctl get/release lock */
@@ -604,7 +604,7 @@ typedef struct {
unsigned short parameter_id;
unsigned short parameter_size_bytes;
unsigned short actual_parameter_size_bytes;
- unsigned char data[1];
+ unsigned char data[];
} TW_Param_Apache, *PTW_Param_Apache;
/* Response queue */
--
2.26.2
[PATCH] mtd: mtdoops: Don't write panic data twice
If calling mtdoops_write, don't also schedule work to be done later.
Although this appears to not be causing an issue, possibly because the
scheduled work will never get done, it is confusing.
Fixes: 016c1291ce70 ("mtd: mtdoops: do not use mtd->panic_write directly")
Signed-off-by: Mark Tomlinson
---
drivers/mtd/mtdoops.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
index 4ced68be7ed7..774970bfcf85 100644
--- a/drivers/mtd/mtdoops.c
+++ b/drivers/mtd/mtdoops.c
@@ -279,12 +279,13 @@ static void mtdoops_do_dump(struct kmsg_dumper *dumper,
kmsg_dump_get_buffer(dumper, true, cxt->oops_buf + MTDOOPS_HEADER_SIZE,
record_size - MTDOOPS_HEADER_SIZE, NULL);
- /* Panics must be written immediately */
- if (reason != KMSG_DUMP_OOPS)
+ if (reason != KMSG_DUMP_OOPS) {
+ /* Panics must be written immediately */
mtdoops_write(cxt, 1);
-
- /* For other cases, schedule work to write it "nicely" */
- schedule_work(&cxt->work_write);
+ } else {
+ /* For other cases, schedule work to write it "nicely" */
+ schedule_work(&cxt->work_write);
+ }
}
static void mtdoops_notify_add(struct mtd_info *mtd)
--
2.28.0
Re: [PATCH] ASoC: fsl_sai: Set SAI Channel Mode to Output Mode
On Thu, Sep 03, 2020 at 11:09:15AM +0800, Shengjiu Wang wrote: > Transmit data pins will output zero when slots are masked or channels > are disabled. In CHMOD TDM mode, transmit data pins are tri-stated when > slots are masked or channels are disabled. When data pins are tri-stated, > there is noise on some channels when FS clock value is high and data is > read while fsclk is transitioning from high to low. > > Signed-off-by: Cosmin-Gabriel Samoila > Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Though one nit inline: > --- > sound/soc/fsl/fsl_sai.c | 12 ++-- > sound/soc/fsl/fsl_sai.h | 2 ++ > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c > index 62c5fdb678fc..33b194a5c1dc 100644 > --- a/sound/soc/fsl/fsl_sai.c > +++ b/sound/soc/fsl/fsl_sai.c > @@ -486,6 +486,12 @@ static int fsl_sai_hw_params(struct snd_pcm_substream > *substream, > > val_cr4 |= FSL_SAI_CR4_FRSZ(slots); > > + /* Output Mode - data pins transmit 0 when slots are masked > + * or channels are disabled > + */ Coding style for multi-line comments. Yet, probably can simplify? /* Set to output mode to avoid tri-stated data pins */
[RFC PATCH 3/4] usb: xhci-mtk: add support runtime pm
From: CK Hu
add support runtime pm feature
Signed-off-by: Zhanyong Wang
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 446 +++-
drivers/usb/host/xhci-mtk.h | 14 ++
2 files changed, 455 insertions(+), 5 deletions(-)
mode change 100644 => 100755 drivers/usb/host/xhci-mtk.h
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index d95221f..ec1adb4 100755
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,228 @@ enum ssusb_uwk_vers {
SSUSB_UWK_V3,
};
+int xhci_mtk_runtime_ready;
+
+#if IS_ENABLED(CONFIG_PM)
+static int xhci_mtk_runtime_suspend(struct device *dev);
+static int xhci_mtk_runtime_resume(struct device *dev);
+static int xhci_mtk_runtime_idle(struct device *dev);
+static ssize_t xhci_mtk_runtime_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ int i;
+ int ret = 0;
+ int num_ports;
+ struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd;
+ struct xhci_hcd *xhci;
+ struct xhci_hub *usb2_rhub;
+ struct xhci_hub *usb3_rhub;
+ struct xhci_bus_state *bus_state;
+ struct xhci_port *port;
+ u32 usb2_suspended_ports = -1;
+ u32 usb3_suspended_ports = -1;
+ u16 status;
+
+ if (!mtk->hcd)
+ return -ESHUTDOWN;
+
+ if (!xhci_mtk_runtime_ready)
+ return sprintf(buf,
+ "xhci_mtk_runtime_ready is not ready yet!\n");
+
+ if (!mtk->hcd)
+ return -ESHUTDOWN;
+
+ hcd = mtk->hcd;
+ xhci = hcd_to_xhci(hcd);
+ if ((xhci->xhc_state & XHCI_STATE_REMOVING) ||
+ (xhci->xhc_state & XHCI_STATE_HALTED)) {
+ return -ESHUTDOWN;
+ }
+
+ usb2_rhub = &xhci->usb2_rhub;
+ if (usb2_rhub) {
+ bus_state = &usb2_rhub->bus_state;
+ num_ports = usb2_rhub->num_ports;
+ usb2_suspended_ports = bus_state->suspended_ports;
+ usb2_suspended_ports ^= (BIT(num_ports) - 1);
+ usb2_suspended_ports &= (BIT(num_ports) - 1);
+ for (i = 0; i < num_ports; i++) {
+ if (usb2_suspended_ports & BIT(i)) {
+ port = usb2_rhub->ports[i];
+ status = readl(port->addr);
+
+ xhci_info(xhci, "USB2: portsc[%i]: 0x%04X\n",
+ i, status);
+
+ if (!(status & PORT_CONNECT))
+ usb2_suspended_ports &= ~BIT(i);
+ }
+ }
+ }
+
+ usb3_rhub = &xhci->usb3_rhub;
+ if (usb3_rhub) {
+ bus_state = &usb3_rhub->bus_state;
+ num_ports = usb3_rhub->num_ports;
+ usb3_suspended_ports = bus_state->suspended_ports;
+ usb3_suspended_ports ^= (BIT(num_ports) - 1);
+ usb3_suspended_ports &= (BIT(num_ports) - 1);
+ for (i = 0; i < num_ports; i++) {
+ if (usb3_suspended_ports & BIT(i)) {
+ port = usb3_rhub->ports[i];
+ status = readl(port->addr);
+
+ xhci_info(xhci, "USB3: portsc[%i]: 0x%04X\n",
+ i, status);
+
+ if (!(status & PORT_CONNECT))
+ usb3_suspended_ports &= ~BIT(i);
+ }
+ }
+ }
+
+ return sprintf(buf, "USB20: 0x%08X, USB30: 0x%08X ret: %i\n",
+ usb2_suspended_ports, usb3_suspended_ports, ret);
+}
+
+static ssize_t xhci_mtk_runtime_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int len = count;
+ char *cp;
+ int rc = count;
+ static const char suspend_string[] = "suspend";
+ static const char resume_string[] = "resume";
+ static const char idle_string[]= "idle";
+
+ cp = memchr(buf, '\n', count);
+ if (cp)
+ len = cp - buf;
+
+ if (!xhci_mtk_runtime_ready) {
+ rc = -EAGAIN;
+ dev_info(dev,
+ "xhci_mtk_runtime_ready is not ready yet!\n");
+ goto exit;
+ }
+
+ if (len == sizeof(suspend_string) - 1 &&
+ strncmp(buf, suspend_string, len) == 0)
+ xhci_mtk_runtime_suspend(dev);
+ else if (len == sizeof(resume_string) - 1 &&
+ strncmp(buf, resume_string, len) == 0)
+ xhci_
[RFC PATCH 1/4] usb: xhci-mtk: improve bandwidth scheduling with multi-TT
From: Zhanyong Wang
After inserted the usb type-c 3.5mm dongle with headset, dmesg showed:
usb 1-1.1: new full-speed USB device number 5 using xhci-mtk
usb 1-1.1: New USB device found, idVendor=05ac, idProduct=110a, bcdDevice=26.11
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: USB-C to 3.5mm Headphone Jack Adapter
usb 1-1.1: Manufacturer: Apple, Inc.
usb 1-1.1: SerialNumber: DWH915501TFJKLTAM
xhci-mtk 1120.xhci: Not enough bandwidth!
usb 1-1.1: can't set config #2, error -28
improve low-speed/full-speed INT/ISOC bandwidth scheduling with USB
muli-TT.
Signed-off-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 91 ++---
drivers/usb/host/xhci-mtk.h | 8 +++-
2 files changed, 84 insertions(+), 15 deletions(-)
mode change 100644 => 100755 drivers/usb/host/xhci-mtk-sch.c
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
old mode 100644
new mode 100755
index 45c54d56..94292b9
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -383,7 +383,9 @@ static int check_sch_tt(struct usb_device *udev,
u32 fs_budget_start;
u32 start_ss, last_ss;
u32 start_cs, last_cs;
- int i;
+ u32 num_esit, base;
+ int i, j;
+ u32 tmp;
start_ss = offset % 8;
fs_budget_start = (start_ss + 1) % 8;
@@ -398,10 +400,13 @@ static int check_sch_tt(struct usb_device *udev,
if (!(start_ss == 7 || last_ss < 6))
return -ERANGE;
- for (i = 0; i < sch_ep->cs_count; i++)
- if (test_bit(offset + i, tt->split_bit_map))
+ for (i = 0; i < sch_ep->cs_count; i++) {
+ if (test_bit(offset + i, tt->ss_bit_map))
return -ERANGE;
+ if (test_bit(offset + i, tt->cs_bit_map))
+ return -ERANGE;
+ }
} else {
u32 cs_count = DIV_ROUND_UP(sch_ep->maxpkt, FS_PAYLOAD_MAX);
@@ -428,8 +433,10 @@ static int check_sch_tt(struct usb_device *udev,
if (cs_count > 7)
cs_count = 7; /* HW limit */
- for (i = 0; i < cs_count + 2; i++) {
- if (test_bit(offset + i, tt->split_bit_map))
+ if (test_bit(offset, tt->ss_bit_map))
+ return -ERANGE;
+ for (i = 0; i < cs_count; i++) {
+ if (test_bit(offset + 2 + i, tt->cs_bit_map))
return -ERANGE;
}
@@ -445,11 +452,22 @@ static int check_sch_tt(struct usb_device *udev,
sch_ep->num_budget_microframes = sch_ep->esit;
}
+ num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
+ for (i = 0; i < num_esit; i++) {
+ base = sch_ep->offset + i * sch_ep->esit;
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ tmp = tt->fs_bus_bw[base + j]
+ + sch_ep->bw_cost_per_microframe;
+ if (tmp > FS_PAYLOAD_MAX)
+ return -ERANGE;
+ }
+ }
+
return 0;
}
static void update_sch_tt(struct usb_device *udev,
- struct mu3h_sch_ep_info *sch_ep)
+ struct mu3h_sch_ep_info *sch_ep, bool used)
{
struct mu3h_sch_tt *tt = sch_ep->sch_tt;
u32 base, num_esit;
@@ -458,11 +476,52 @@ static void update_sch_tt(struct usb_device *udev,
num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
for (i = 0; i < num_esit; i++) {
base = sch_ep->offset + i * sch_ep->esit;
- for (j = 0; j < sch_ep->num_budget_microframes; j++)
- set_bit(base + j, tt->split_bit_map);
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ if (used)
+ set_bit(base + j, tt->split_bit_map);
+ else
+ clear_bit(base + j, tt->split_bit_map);
+ }
+
+ if (sch_ep->ep_type == ISOC_OUT_EP) {
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ if (used) {
+ set_bit(base + j, tt->ss_bit_map);
+ set_bit(base + j, tt->cs_bit_map);
+ tt->fs_bus_bw[base + j] +=
+ sch_ep->bw_cost_per_microframe;
+ } else {
+ clear_bit(base + j, tt->ss_bit_map);
+ clear_bit(base + j, tt->cs_bit_map);
+ tt->fs_bus_bw[base + j] -=
+ sch_ep->
[RFC PATCH 4/4] arm64: dts: mt8192: add SSUSB related nodes
From: Zhanyong Wang
Add SSUSB related nodes for mt8192
Signed-off-by: Zhanyong Wang
Signed-off-by: Chunfeng Yun
---
Depends on:
https://patchwork.kernel.org/patch/11713559/
[v4,1/3] arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and
Makefile
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 48
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 8871c2f..755f152 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -434,6 +434,54 @@
status = "disabled";
};
+ xhci: xhci@1120 {
+ compatible = "mediatek,mt8192-xhci",
+"mediatek,mtk-xhci";
+ reg = <0 0x1120 0 0x1000>,
+ <0 0x11203e00 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts-extended = <&gic GIC_SPI 97
IRQ_TYPE_LEVEL_HIGH 0>,
+ <&pio 211 IRQ_TYPE_LEVEL_LOW>;
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u3port0 PHY_TYPE_USB3>;
+ assigned-clocks = <&topckgen CLK_TOP_USB_TOP_SEL>,
+ <&topckgen CLK_TOP_SSUSB_XHCI_SEL>;
+ assigned-clock-parents = <&topckgen
CLK_TOP_UNIVPLL_D5_D4>,
+<&topckgen
CLK_TOP_UNIVPLL_D5_D4>;
+ clocks = <&infracfg CLK_INFRA_SSUSB>,
+<&infracfg CLK_INFRA_SSUSB_XHCI>,
+<&apmixedsys CLK_APMIXED_USBPLL>;
+ clock-names = "sys_ck", "xhci_ck", "ref_ck";
+ mediatek,syscon-wakeup = <&pericfg 0x420 3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ };
+
+ u3phy0: usb-phy@11e4 {
+ compatible = "mediatek,mt8192-tphy",
+"mediatek,generic-tphy-v2";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ u2port0: usb-phy@11e4 {
+ reg = <0 0x11e4 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u3port0: usb-phy@11e40700 {
+ reg = <0 0x11e40700 0 0x900>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
audsys: syscon@1121 {
compatible = "mediatek,mt8192-audsys", "syscon";
reg = <0 0x1121 0 0x1000>;
--
1.9.1
[RFC PATCH 2/4] usb: xhci-mtk: add mt8192 wakeup
From: Zhanyong Wang
need to add wakeup solution as V3
since not support presently.
Signed-off-by: Zhanyong Wang
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 9 +
1 file changed, 9 insertions(+)
mode change 100644 => 100755 drivers/usb/host/xhci-mtk.c
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
old mode 100644
new mode 100755
index 4311d4c..d95221f
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -68,9 +68,13 @@
#define SSC_IP_SLEEP_ENBIT(4)
#define SSC_SPM_INT_EN BIT(1)
+/* mt8192 etc */
+#define SSC_IP_SLEEP_EN_V3 BIT(6)
+
enum ssusb_uwk_vers {
SSUSB_UWK_V1 = 1,
SSUSB_UWK_V2,
+ SSUSB_UWK_V3,
};
static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
@@ -305,6 +309,11 @@ static void usb_wakeup_ip_sleep_set(struct xhci_hcd_mtk
*mtk, bool enable)
msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
val = enable ? msk : 0;
break;
+ case SSUSB_UWK_V3:
+ reg = mtk->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
+ msk = SSC_IP_SLEEP_EN_V3 | SSC_SPM_INT_EN;
+ val = enable ? msk : 0;
+ break;
default:
return;
}
--
1.9.1
[RFC PATCH 4/4] arm64: dts: mt8192: add SSUSB related nodes
From: Zhanyong Wang
Add SSUSB related nodes for mt8192
Signed-off-by: Zhanyong Wang
Signed-off-by: Chunfeng Yun
---
Depends on:
https://patchwork.kernel.org/patch/11713559/
[v4,1/3] arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and
Makefile
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 48
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 8871c2f..755f152 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -434,6 +434,54 @@
status = "disabled";
};
+ xhci: xhci@1120 {
+ compatible = "mediatek,mt8192-xhci",
+"mediatek,mtk-xhci";
+ reg = <0 0x1120 0 0x1000>,
+ <0 0x11203e00 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts-extended = <&gic GIC_SPI 97
IRQ_TYPE_LEVEL_HIGH 0>,
+ <&pio 211 IRQ_TYPE_LEVEL_LOW>;
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u3port0 PHY_TYPE_USB3>;
+ assigned-clocks = <&topckgen CLK_TOP_USB_TOP_SEL>,
+ <&topckgen CLK_TOP_SSUSB_XHCI_SEL>;
+ assigned-clock-parents = <&topckgen
CLK_TOP_UNIVPLL_D5_D4>,
+<&topckgen
CLK_TOP_UNIVPLL_D5_D4>;
+ clocks = <&infracfg CLK_INFRA_SSUSB>,
+<&infracfg CLK_INFRA_SSUSB_XHCI>,
+<&apmixedsys CLK_APMIXED_USBPLL>;
+ clock-names = "sys_ck", "xhci_ck", "ref_ck";
+ mediatek,syscon-wakeup = <&pericfg 0x420 3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ };
+
+ u3phy0: usb-phy@11e4 {
+ compatible = "mediatek,mt8192-tphy",
+"mediatek,generic-tphy-v2";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ u2port0: usb-phy@11e4 {
+ reg = <0 0x11e4 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u3port0: usb-phy@11e40700 {
+ reg = <0 0x11e40700 0 0x900>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
audsys: syscon@1121 {
compatible = "mediatek,mt8192-audsys", "syscon";
reg = <0 0x1121 0 0x1000>;
--
1.9.1
Re: [PATCH] ASoC: fsl_sai: Support multiple data channel enable bits
On Tue, Sep 01, 2020 at 07:01:08PM +0800, Shengjiu Wang wrote: > One data channel is one data line. From imx7ulp, the SAI IP is > enhanced to support multiple data channels. > > If there is only two channels input and slots is 2, then enable one > data channel is enough for data transfer. So enable the TCE/RCE and > transmit/receive mask register according to the input channels and > slots configuration. > > Move the data channel enablement from startup() to hw_params(). > > Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen
[RFC PATCH 3/4] usb: xhci-mtk: add support runtime pm
From: CK Hu
add support runtime pm feature
Signed-off-by: Zhanyong Wang
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 446 +++-
drivers/usb/host/xhci-mtk.h | 14 ++
2 files changed, 455 insertions(+), 5 deletions(-)
mode change 100644 => 100755 drivers/usb/host/xhci-mtk.h
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index d95221f..ec1adb4 100755
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,228 @@ enum ssusb_uwk_vers {
SSUSB_UWK_V3,
};
+int xhci_mtk_runtime_ready;
+
+#if IS_ENABLED(CONFIG_PM)
+static int xhci_mtk_runtime_suspend(struct device *dev);
+static int xhci_mtk_runtime_resume(struct device *dev);
+static int xhci_mtk_runtime_idle(struct device *dev);
+static ssize_t xhci_mtk_runtime_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ int i;
+ int ret = 0;
+ int num_ports;
+ struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd;
+ struct xhci_hcd *xhci;
+ struct xhci_hub *usb2_rhub;
+ struct xhci_hub *usb3_rhub;
+ struct xhci_bus_state *bus_state;
+ struct xhci_port *port;
+ u32 usb2_suspended_ports = -1;
+ u32 usb3_suspended_ports = -1;
+ u16 status;
+
+ if (!mtk->hcd)
+ return -ESHUTDOWN;
+
+ if (!xhci_mtk_runtime_ready)
+ return sprintf(buf,
+ "xhci_mtk_runtime_ready is not ready yet!\n");
+
+ if (!mtk->hcd)
+ return -ESHUTDOWN;
+
+ hcd = mtk->hcd;
+ xhci = hcd_to_xhci(hcd);
+ if ((xhci->xhc_state & XHCI_STATE_REMOVING) ||
+ (xhci->xhc_state & XHCI_STATE_HALTED)) {
+ return -ESHUTDOWN;
+ }
+
+ usb2_rhub = &xhci->usb2_rhub;
+ if (usb2_rhub) {
+ bus_state = &usb2_rhub->bus_state;
+ num_ports = usb2_rhub->num_ports;
+ usb2_suspended_ports = bus_state->suspended_ports;
+ usb2_suspended_ports ^= (BIT(num_ports) - 1);
+ usb2_suspended_ports &= (BIT(num_ports) - 1);
+ for (i = 0; i < num_ports; i++) {
+ if (usb2_suspended_ports & BIT(i)) {
+ port = usb2_rhub->ports[i];
+ status = readl(port->addr);
+
+ xhci_info(xhci, "USB2: portsc[%i]: 0x%04X\n",
+ i, status);
+
+ if (!(status & PORT_CONNECT))
+ usb2_suspended_ports &= ~BIT(i);
+ }
+ }
+ }
+
+ usb3_rhub = &xhci->usb3_rhub;
+ if (usb3_rhub) {
+ bus_state = &usb3_rhub->bus_state;
+ num_ports = usb3_rhub->num_ports;
+ usb3_suspended_ports = bus_state->suspended_ports;
+ usb3_suspended_ports ^= (BIT(num_ports) - 1);
+ usb3_suspended_ports &= (BIT(num_ports) - 1);
+ for (i = 0; i < num_ports; i++) {
+ if (usb3_suspended_ports & BIT(i)) {
+ port = usb3_rhub->ports[i];
+ status = readl(port->addr);
+
+ xhci_info(xhci, "USB3: portsc[%i]: 0x%04X\n",
+ i, status);
+
+ if (!(status & PORT_CONNECT))
+ usb3_suspended_ports &= ~BIT(i);
+ }
+ }
+ }
+
+ return sprintf(buf, "USB20: 0x%08X, USB30: 0x%08X ret: %i\n",
+ usb2_suspended_ports, usb3_suspended_ports, ret);
+}
+
+static ssize_t xhci_mtk_runtime_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int len = count;
+ char *cp;
+ int rc = count;
+ static const char suspend_string[] = "suspend";
+ static const char resume_string[] = "resume";
+ static const char idle_string[]= "idle";
+
+ cp = memchr(buf, '\n', count);
+ if (cp)
+ len = cp - buf;
+
+ if (!xhci_mtk_runtime_ready) {
+ rc = -EAGAIN;
+ dev_info(dev,
+ "xhci_mtk_runtime_ready is not ready yet!\n");
+ goto exit;
+ }
+
+ if (len == sizeof(suspend_string) - 1 &&
+ strncmp(buf, suspend_string, len) == 0)
+ xhci_mtk_runtime_suspend(dev);
+ else if (len == sizeof(resume_string) - 1 &&
+ strncmp(buf, resume_string, len) == 0)
+ xhci_
[RFC PATCH 1/4] usb: xhci-mtk: improve bandwidth scheduling with multi-TT
From: Zhanyong Wang
After inserted the usb type-c 3.5mm dongle with headset, dmesg showed:
usb 1-1.1: new full-speed USB device number 5 using xhci-mtk
usb 1-1.1: New USB device found, idVendor=05ac, idProduct=110a, bcdDevice=26.11
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: USB-C to 3.5mm Headphone Jack Adapter
usb 1-1.1: Manufacturer: Apple, Inc.
usb 1-1.1: SerialNumber: DWH915501TFJKLTAM
xhci-mtk 1120.xhci: Not enough bandwidth!
usb 1-1.1: can't set config #2, error -28
improve low-speed/full-speed INT/ISOC bandwidth scheduling with USB
muli-TT.
Signed-off-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 91 ++---
drivers/usb/host/xhci-mtk.h | 8 +++-
2 files changed, 84 insertions(+), 15 deletions(-)
mode change 100644 => 100755 drivers/usb/host/xhci-mtk-sch.c
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
old mode 100644
new mode 100755
index 45c54d56..94292b9
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -383,7 +383,9 @@ static int check_sch_tt(struct usb_device *udev,
u32 fs_budget_start;
u32 start_ss, last_ss;
u32 start_cs, last_cs;
- int i;
+ u32 num_esit, base;
+ int i, j;
+ u32 tmp;
start_ss = offset % 8;
fs_budget_start = (start_ss + 1) % 8;
@@ -398,10 +400,13 @@ static int check_sch_tt(struct usb_device *udev,
if (!(start_ss == 7 || last_ss < 6))
return -ERANGE;
- for (i = 0; i < sch_ep->cs_count; i++)
- if (test_bit(offset + i, tt->split_bit_map))
+ for (i = 0; i < sch_ep->cs_count; i++) {
+ if (test_bit(offset + i, tt->ss_bit_map))
return -ERANGE;
+ if (test_bit(offset + i, tt->cs_bit_map))
+ return -ERANGE;
+ }
} else {
u32 cs_count = DIV_ROUND_UP(sch_ep->maxpkt, FS_PAYLOAD_MAX);
@@ -428,8 +433,10 @@ static int check_sch_tt(struct usb_device *udev,
if (cs_count > 7)
cs_count = 7; /* HW limit */
- for (i = 0; i < cs_count + 2; i++) {
- if (test_bit(offset + i, tt->split_bit_map))
+ if (test_bit(offset, tt->ss_bit_map))
+ return -ERANGE;
+ for (i = 0; i < cs_count; i++) {
+ if (test_bit(offset + 2 + i, tt->cs_bit_map))
return -ERANGE;
}
@@ -445,11 +452,22 @@ static int check_sch_tt(struct usb_device *udev,
sch_ep->num_budget_microframes = sch_ep->esit;
}
+ num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
+ for (i = 0; i < num_esit; i++) {
+ base = sch_ep->offset + i * sch_ep->esit;
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ tmp = tt->fs_bus_bw[base + j]
+ + sch_ep->bw_cost_per_microframe;
+ if (tmp > FS_PAYLOAD_MAX)
+ return -ERANGE;
+ }
+ }
+
return 0;
}
static void update_sch_tt(struct usb_device *udev,
- struct mu3h_sch_ep_info *sch_ep)
+ struct mu3h_sch_ep_info *sch_ep, bool used)
{
struct mu3h_sch_tt *tt = sch_ep->sch_tt;
u32 base, num_esit;
@@ -458,11 +476,52 @@ static void update_sch_tt(struct usb_device *udev,
num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
for (i = 0; i < num_esit; i++) {
base = sch_ep->offset + i * sch_ep->esit;
- for (j = 0; j < sch_ep->num_budget_microframes; j++)
- set_bit(base + j, tt->split_bit_map);
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ if (used)
+ set_bit(base + j, tt->split_bit_map);
+ else
+ clear_bit(base + j, tt->split_bit_map);
+ }
+
+ if (sch_ep->ep_type == ISOC_OUT_EP) {
+ for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+ if (used) {
+ set_bit(base + j, tt->ss_bit_map);
+ set_bit(base + j, tt->cs_bit_map);
+ tt->fs_bus_bw[base + j] +=
+ sch_ep->bw_cost_per_microframe;
+ } else {
+ clear_bit(base + j, tt->ss_bit_map);
+ clear_bit(base + j, tt->cs_bit_map);
+ tt->fs_bus_bw[base + j] -=
+ sch_ep->
[RFC PATCH 2/4] usb: xhci-mtk: add mt8192 wakeup
From: Zhanyong Wang
need to add wakeup solution as V3
since not support presently.
Signed-off-by: Zhanyong Wang
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 9 +
1 file changed, 9 insertions(+)
mode change 100644 => 100755 drivers/usb/host/xhci-mtk.c
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
old mode 100644
new mode 100755
index 4311d4c..d95221f
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -68,9 +68,13 @@
#define SSC_IP_SLEEP_ENBIT(4)
#define SSC_SPM_INT_EN BIT(1)
+/* mt8192 etc */
+#define SSC_IP_SLEEP_EN_V3 BIT(6)
+
enum ssusb_uwk_vers {
SSUSB_UWK_V1 = 1,
SSUSB_UWK_V2,
+ SSUSB_UWK_V3,
};
static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
@@ -305,6 +309,11 @@ static void usb_wakeup_ip_sleep_set(struct xhci_hcd_mtk
*mtk, bool enable)
msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
val = enable ? msk : 0;
break;
+ case SSUSB_UWK_V3:
+ reg = mtk->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
+ msk = SSC_IP_SLEEP_EN_V3 | SSC_SPM_INT_EN;
+ val = enable ? msk : 0;
+ break;
default:
return;
}
--
1.9.1
Re: [PATCH 0/2] dma-mapping: update default segment_boundary_mask
On Wed, Sep 02, 2020 at 10:13:12AM +0200, Niklas Schnelle wrote: > On 9/2/20 12:16 AM, Nicolin Chen wrote: > > These two patches are to update default segment_boundary_mask. > > > > PATCH-1 fixes overflow issues in callers of dma_get_seg_boundary. > > Previous version was a series: https://lkml.org/lkml/2020/8/31/1026 > > > > Then PATCH-2 sets default segment_boundary_mask to ULONG_MAX. > > > > Nicolin Chen (2): > > dma-mapping: introduce dma_get_seg_boundary_nr_pages() > > dma-mapping: set default segment_boundary_mask to ULONG_MAX > > I gave both of your patches a quick test ride on a couple of dev mainframes, > both NVMe, ConnectX and virtio-pci devices all seems to work fine. > I already commented on Christoph's mail that I like the helper approach, > so as for s390 you can add my > > Acked-by: Niklas Schnelle Thanks for testing and the ack!
[PATCH v3 4/9] dt-bindings: ARM: Mediatek: Document bindings for MT8192 Camera
This patch adds the binding documentation of camsys-raw,
camsys and imgsys for Mediatek MT8192.
Signed-off-by: Weiyi Lu
---
.../bindings/arm/mediatek/mediatek,camsys-raw.yaml | 54 ++
.../bindings/arm/mediatek/mediatek,camsys.txt | 1 +
.../bindings/arm/mediatek/mediatek,imgsys.txt | 2 +
3 files changed, 57 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml
new file mode 100644
index 000..eb395ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,camsys-raw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek CAMSYS RAW Controller
+
+maintainers:
+ - Weiyi Lu
+
+description:
+ The Mediatek camsys raw controller provides functional configurations and
clocks to the system.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - mediatek,mt8192-camsys_rawa
+ - mediatek,mt8192-camsys_rawb
+ - mediatek,mt8192-camsys_rawc
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ '#clock-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+camsys_rawa: syscon@1a04f000 {
+compatible = "mediatek,mt8192-camsys_rawa", "syscon";
+reg = <0 0x1a04f000 0 0x1000>;
+#clock-cells = <1>;
+};
+
+ - |
+camsys_rawb: syscon@1a06f000 {
+compatible = "mediatek,mt8192-camsys_rawb", "syscon";
+reg = <0 0x1a06f000 0 0x1000>;
+#clock-cells = <1>;
+};
+
+ - |
+camsys_rawc: syscon@1a08f000 {
+compatible = "mediatek,mt8192-camsys_rawc", "syscon";
+reg = <0 0x1a08f000 0 0x1000>;
+#clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
index a0ce820..0082f21 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
@@ -9,6 +9,7 @@ Required Properties:
- "mediatek,mt6765-camsys", "syscon"
- "mediatek,mt6779-camsys", "syscon"
- "mediatek,mt8183-camsys", "syscon"
+ - "mediatek,mt8192-camsys", "syscon"
- #clock-cells: Must be 1
The camsys controller uses the common clk binding from
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index 1e1f007..b4312d1 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -14,6 +14,8 @@ Required Properties:
- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
- "mediatek,mt8183-imgsys", "syscon"
+ - "mediatek,mt8192-imgsys", "syscon"
+ - "mediatek,mt8192-imgsys2", "syscon"
- #clock-cells: Must be 1
The imgsys controller uses the common clk binding from
--
1.8.1.1.dirty
[PATCH v3 8/9] clk: mediatek: Add configurable enable control to mtk_pll_data
In all MediaTek PLL design, bit0 of CON0 register is always
the enable bit.
However, there's a special case of usbpll on MT8192.
The enable bit of usbpll is moved to bit2 of other register.
Add configurable en_reg and pll_en_bit for enable control or
default 0 where pll data are static variables.
Hence, CON0_BASE_EN could also be removed.
And there might have another special case on other chips,
the enable bit is still on CON0 register but not at bit0.
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-mtk.h | 2 ++
drivers/clk/mediatek/clk-pll.c | 16 ++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index c3d6756..c580663 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -233,6 +233,8 @@ struct mtk_pll_data {
uint32_t pcw_chg_reg;
const struct mtk_pll_div_table *div_table;
const char *parent_name;
+ uint32_t en_reg;
+ uint8_t pll_en_bit; /* Assume 0, indicates BIT(0) by default */
};
void mtk_clk_register_plls(struct device_node *node,
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index e0b00bc..bd91113 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -16,7 +16,6 @@
#define REG_CON0 0
#define REG_CON1 4
-#define CON0_BASE_EN BIT(0)
#define CON0_PWR_ONBIT(0)
#define CON0_ISO_ENBIT(1)
#define PCW_CHG_MASK BIT(31)
@@ -44,6 +43,7 @@ struct mtk_clk_pll {
void __iomem*tuner_en_addr;
void __iomem*pcw_addr;
void __iomem*pcw_chg_addr;
+ void __iomem*en_addr;
const struct mtk_pll_data *data;
};
@@ -56,7 +56,7 @@ static int mtk_pll_is_prepared(struct clk_hw *hw)
{
struct mtk_clk_pll *pll = to_mtk_clk_pll(hw);
- return (readl(pll->base_addr + REG_CON0) & CON0_BASE_EN) != 0;
+ return (readl(pll->en_addr) & BIT(pll->data->pll_en_bit)) != 0;
}
static unsigned long __mtk_pll_recalc_rate(struct mtk_clk_pll *pll, u32 fin,
@@ -247,8 +247,8 @@ static int mtk_pll_prepare(struct clk_hw *hw)
writel(r, pll->pwr_addr);
udelay(1);
- r = readl(pll->base_addr + REG_CON0) | CON0_BASE_EN;
- writel(r, pll->base_addr + REG_CON0);
+ r = readl(pll->en_addr) | BIT(pll->data->pll_en_bit);
+ writel(r, pll->en_addr);
if (pll->data->en_mask) {
r = readl(pll->base_addr + REG_CON0) | pll->data->en_mask;
@@ -286,8 +286,8 @@ static void mtk_pll_unprepare(struct clk_hw *hw)
writel(r, pll->base_addr + REG_CON0);
}
- r = readl(pll->base_addr + REG_CON0) & ~CON0_BASE_EN;
- writel(r, pll->base_addr + REG_CON0);
+ r = readl(pll->en_addr) & ~BIT(pll->data->pll_en_bit);
+ writel(r, pll->en_addr);
r = readl(pll->pwr_addr) | CON0_ISO_EN;
writel(r, pll->pwr_addr);
@@ -329,6 +329,10 @@ static struct clk *mtk_clk_register_pll(const struct
mtk_pll_data *data,
pll->tuner_addr = base + data->tuner_reg;
if (data->tuner_en_reg)
pll->tuner_en_addr = base + data->tuner_en_reg;
+ if (data->en_reg)
+ pll->en_addr = base + data->en_reg;
+ else
+ pll->en_addr = pll->base_addr + REG_CON0;
pll->hw.init = &init;
pll->data = data;
--
1.8.1.1.dirty
[PATCH v3 6/9] clk: mediatek: Add dt-bindings for MT8192 clocks
Add MT8192 clock dt-bindings, include topckgen, apmixedsys, infracfg, pericfg and subsystem clocks. Signed-off-by: Weiyi Lu --- include/dt-bindings/clock/mt8192-clk.h | 592 + 1 file changed, 592 insertions(+) create mode 100644 include/dt-bindings/clock/mt8192-clk.h diff --git a/include/dt-bindings/clock/mt8192-clk.h b/include/dt-bindings/clock/mt8192-clk.h new file mode 100644 index 000..50b1ba2 --- /dev/null +++ b/include/dt-bindings/clock/mt8192-clk.h @@ -0,0 +1,592 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 MediaTek Inc. + * Author: Weiyi Lu + */ + +#ifndef _DT_BINDINGS_CLK_MT8192_H +#define _DT_BINDINGS_CLK_MT8192_H + +/* TOPCKGEN */ + +#define CLK_TOP_AXI_SEL0 +#define CLK_TOP_SPM_SEL1 +#define CLK_TOP_SCP_SEL2 +#define CLK_TOP_BUS_AXIMEM_SEL 3 +#define CLK_TOP_DISP_SEL 4 +#define CLK_TOP_MDP_SEL5 +#define CLK_TOP_IMG1_SEL 6 +#define CLK_TOP_IMG2_SEL 7 +#define CLK_TOP_IPE_SEL8 +#define CLK_TOP_DPE_SEL9 +#define CLK_TOP_CAM_SEL10 +#define CLK_TOP_CCU_SEL11 +#define CLK_TOP_DSP7_SEL 12 +#define CLK_TOP_MFG_REF_SEL13 +#define CLK_TOP_MFG_PLL_SEL14 +#define CLK_TOP_CAMTG_SEL 15 +#define CLK_TOP_CAMTG2_SEL 16 +#define CLK_TOP_CAMTG3_SEL 17 +#define CLK_TOP_CAMTG4_SEL 18 +#define CLK_TOP_CAMTG5_SEL 19 +#define CLK_TOP_CAMTG6_SEL 20 +#define CLK_TOP_UART_SEL 21 +#define CLK_TOP_SPI_SEL22 +#define CLK_TOP_MSDC50_0_H_SEL 23 +#define CLK_TOP_MSDC50_0_SEL 24 +#define CLK_TOP_MSDC30_1_SEL 25 +#define CLK_TOP_MSDC30_2_SEL 26 +#define CLK_TOP_AUDIO_SEL 27 +#define CLK_TOP_AUD_INTBUS_SEL 28 +#define CLK_TOP_PWRAP_ULPOSC_SEL 29 +#define CLK_TOP_ATB_SEL30 +#define CLK_TOP_SSPM_SEL 31 +#define CLK_TOP_DPI_SEL32 +#define CLK_TOP_SCAM_SEL 33 +#define CLK_TOP_DISP_PWM_SEL 34 +#define CLK_TOP_USB_TOP_SEL35 +#define CLK_TOP_SSUSB_XHCI_SEL 36 +#define CLK_TOP_I2C_SEL37 +#define CLK_TOP_SENINF_SEL 38 +#define CLK_TOP_SENINF1_SEL39 +#define CLK_TOP_SENINF2_SEL40 +#define CLK_TOP_SENINF3_SEL41 +#define CLK_TOP_TL_SEL 42 +#define CLK_TOP_DXCC_SEL 43 +#define CLK_TOP_AUD_ENGEN1_SEL 44 +#define CLK_TOP_AUD_ENGEN2_SEL 45 +#define CLK_TOP_AES_UFSFDE_SEL 46 +#define CLK_TOP_UFS_SEL47 +#define CLK_TOP_AUD_1_SEL 48 +#define CLK_TOP_AUD_2_SEL 49 +#define CLK_TOP_ADSP_SEL 50 +#define CLK_TOP_DPMAIF_MAIN_SEL51 +#define CLK_TOP_VENC_SEL 52 +#define CLK_TOP_VDEC_SEL 53 +#define CLK_TOP_CAMTM_SEL 54 +#define CLK_TOP_PWM_SEL55 +#define CLK_TOP_AUDIO_H_SEL56 +#define CLK_TOP_SPMI_MST_SEL 57 +#define CLK_TOP_AES_MSDCFDE_SEL58 +#define CLK_TOP_MCUPM_SEL 59 +#define CLK_TOP_SFLASH_SEL 60 +#define CLK_TOP_APLL_I2S0_M_SEL61 +#define CLK_TOP_APLL_I2S1_M_SEL62 +#define CLK_TOP_APLL_I2S2_M_SEL63 +#define CLK_TOP_APLL_I2S3_M_SEL64 +#define CLK_TOP_APLL_I2S4_M_SEL65 +#define CLK_TOP_APLL_I2S5_M_SEL66 +#define CLK_TOP_APLL_I2S6_M_SEL67 +#define CLK_TOP_APLL_I2S7_M_SEL68 +#define CLK_TOP_APLL_I2S8_M_SEL69 +#define CLK_TOP_APLL_I2S9_M_SEL70 +#define CLK_TOP_MAINPLL_D3 71 +#define CLK_TOP_MAINPLL_D4 72 +#define CLK_TOP_MAINPLL_D4_D2 73 +#define CLK_TOP_MAINPLL_D4_D4 74 +#define CLK_TOP_MAINPLL_D4_D8 75 +#define CLK_TOP_MAINPLL_D4_D16 76 +#define CLK_TOP_MAINPLL_D5 77 +#define CLK_TOP_MAINPLL_D5_D2 78 +#define CLK_TOP_MAINPLL_D5_D4 79 +#define CLK_TOP_MAINPLL_D5_D8 80 +#define CLK_TOP_MAINPLL_D6 81 +#define CLK_TOP_MAINPLL_D6_D2 82 +#define CLK_TOP_MAINPLL_D6_D4 83 +#define CLK_TOP_MAINPLL_D7 84 +#define CLK_TOP_MAINPLL_D7_D2 85 +#define CLK_TOP_MAINPLL_D7_D4 86 +#define CLK_TOP_MAINPLL_D7_D8 87 +#define CLK_TOP_UNIVPLL_D3 88 +#define CLK_TOP_UNIVPLL_D4 89 +#define CLK_TOP_UNIVPLL_D4_D2 90 +#define CLK_TOP_UNIVPLL_D4_D4 91 +#define CLK_TOP_UNIVPLL_D4_D8 92 +#define CLK_TOP_UNIVPLL_D5 93 +#define CLK_TOP_UNIVPLL_D5_D2
[PATCH v3 7/9] clk: mediatek: Fix asymmetrical PLL enable and disable control
The en_mask actually is a combination of divider enable mask
and pll enable bit(bit0).
Before this patch, we enabled both divider mask and bit0 in prepare(),
but only cleared the bit0 in unprepare().
Now, setting the enable register(CON0) in 2 steps: first divider mask,
then bit0 during prepare(), vice versa.
Hence, en_mask will only be used as divider enable mask.
Meanwhile, all the SoC PLL data are updated.
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-mt2701.c | 26 +-
drivers/clk/mediatek/clk-mt2712.c | 30 +++---
drivers/clk/mediatek/clk-mt6765.c | 20 ++--
drivers/clk/mediatek/clk-mt6779.c | 24
drivers/clk/mediatek/clk-mt6797.c | 20 ++--
drivers/clk/mediatek/clk-mt7622.c | 18 +-
drivers/clk/mediatek/clk-mt7629.c | 12 ++--
drivers/clk/mediatek/clk-mt8173.c | 28 ++--
drivers/clk/mediatek/clk-mt8183.c | 22 +++---
drivers/clk/mediatek/clk-pll.c| 16
10 files changed, 112 insertions(+), 104 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt2701.c
b/drivers/clk/mediatek/clk-mt2701.c
index 695be0f..462a998 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -934,31 +934,31 @@ static int mtk_pericfg_init(struct platform_device *pdev)
}
static const struct mtk_pll_data apmixed_plls[] = {
- PLL(CLK_APMIXED_ARMPLL, "armpll", 0x200, 0x20c, 0x8001,
+ PLL(CLK_APMIXED_ARMPLL, "armpll", 0x200, 0x20c, 0x8000,
PLL_AO, 21, 0x204, 24, 0x0, 0x204, 0),
- PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x210, 0x21c, 0xf001,
+ PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x210, 0x21c, 0xf000,
HAVE_RST_BAR, 21, 0x210, 4, 0x0, 0x214, 0),
- PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x220, 0x22c, 0xf301,
+ PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x220, 0x22c, 0xf300,
HAVE_RST_BAR, 7, 0x220, 4, 0x0, 0x224, 14),
- PLL(CLK_APMIXED_MMPLL, "mmpll", 0x230, 0x23c, 0x0001, 0,
+ PLL(CLK_APMIXED_MMPLL, "mmpll", 0x230, 0x23c, 0, 0,
21, 0x230, 4, 0x0, 0x234, 0),
- PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x240, 0x24c, 0x0001, 0,
+ PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x240, 0x24c, 0, 0,
21, 0x240, 4, 0x0, 0x244, 0),
- PLL(CLK_APMIXED_TVDPLL, "tvdpll", 0x250, 0x25c, 0x0001, 0,
+ PLL(CLK_APMIXED_TVDPLL, "tvdpll", 0x250, 0x25c, 0, 0,
21, 0x250, 4, 0x0, 0x254, 0),
- PLL(CLK_APMIXED_AUD1PLL, "aud1pll", 0x270, 0x27c, 0x0001, 0,
+ PLL(CLK_APMIXED_AUD1PLL, "aud1pll", 0x270, 0x27c, 0, 0,
31, 0x270, 4, 0x0, 0x274, 0),
- PLL(CLK_APMIXED_TRGPLL, "trgpll", 0x280, 0x28c, 0x0001, 0,
+ PLL(CLK_APMIXED_TRGPLL, "trgpll", 0x280, 0x28c, 0, 0,
31, 0x280, 4, 0x0, 0x284, 0),
- PLL(CLK_APMIXED_ETHPLL, "ethpll", 0x290, 0x29c, 0x0001, 0,
+ PLL(CLK_APMIXED_ETHPLL, "ethpll", 0x290, 0x29c, 0, 0,
31, 0x290, 4, 0x0, 0x294, 0),
- PLL(CLK_APMIXED_VDECPLL, "vdecpll", 0x2a0, 0x2ac, 0x0001, 0,
+ PLL(CLK_APMIXED_VDECPLL, "vdecpll", 0x2a0, 0x2ac, 0, 0,
31, 0x2a0, 4, 0x0, 0x2a4, 0),
- PLL(CLK_APMIXED_HADDS2PLL, "hadds2pll", 0x2b0, 0x2bc, 0x0001, 0,
+ PLL(CLK_APMIXED_HADDS2PLL, "hadds2pll", 0x2b0, 0x2bc, 0, 0,
31, 0x2b0, 4, 0x0, 0x2b4, 0),
- PLL(CLK_APMIXED_AUD2PLL, "aud2pll", 0x2c0, 0x2cc, 0x0001, 0,
+ PLL(CLK_APMIXED_AUD2PLL, "aud2pll", 0x2c0, 0x2cc, 0, 0,
31, 0x2c0, 4, 0x0, 0x2c4, 0),
- PLL(CLK_APMIXED_TVD2PLL, "tvd2pll", 0x2d0, 0x2dc, 0x0001, 0,
+ PLL(CLK_APMIXED_TVD2PLL, "tvd2pll", 0x2d0, 0x2dc, 0, 0,
21, 0x2d0, 4, 0x0, 0x2d4, 0),
};
diff --git a/drivers/clk/mediatek/clk-mt2712.c
b/drivers/clk/mediatek/clk-mt2712.c
index a3bd9a1..fd81162 100644
--- a/drivers/clk/mediatek/clk-mt2712.c
+++ b/drivers/clk/mediatek/clk-mt2712.c
@@ -1222,38 +1222,38 @@
};
static const struct mtk_pll_data plls[] = {
- PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x0230, 0x023C, 0xf101,
+ PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x0230, 0x023C, 0xf100,
HAVE_RST_BAR, 31, 0x0230, 4, 0, 0, 0, 0x0234, 0),
- PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x0240, 0x024C, 0xfe000101,
+ PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x0240, 0x024C, 0xfe000100,
HAVE_RST_BAR, 31, 0x0240, 4, 0, 0, 0, 0x0244, 0),
- PLL(CLK_APMIXED_VCODECPLL, "vcodecpll", 0x0320, 0x032C, 0xc101,
+ PLL(CLK_APMIXED_VCODECPLL, "vcodecpll", 0x0320, 0x032C, 0xc100,
0, 31, 0x0320, 4, 0, 0, 0, 0x0324, 0),
- PLL(CLK_APMIXED_VENCPLL, "vencpll", 0x0280,
