RE: [PATCH v1 3/3] scsi: ufs: Make UPIU trace easier differentiate among CDB, OSF, and TM
>
>
> From: Bean Huo
>
> Transaction Specific Fields (TSF) in the UPIU package could be CDB
> (SCSI/UFS Command Descriptor Block), OSF (Opcode Specific Field), and
> TM I/O parameter (Task Management Input/Output Parameter). But,
> currently,
> we take all of these as CDB in the UPIU trace. Thus makes user confuse
> among CDB, OSF, and TM message. So fix it with this patch.
>
> Signed-off-by: Bean Huo
> ---
> drivers/scsi/ufs/ufshcd.c | 9 +
> include/trace/events/ufs.h | 10 +++---
> 2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 29d7240a61bf..5b2219e44743 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -315,7 +315,8 @@ static void ufshcd_add_cmd_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
> {
> struct utp_upiu_req *rq = hba->lrb[tag].ucd_req_ptr;
>
> - trace_ufshcd_upiu(dev_name(hba->dev), str, >header,
> >sc.cdb);
> + trace_ufshcd_upiu(dev_name(hba->dev), str, >header,
> >sc.cdb,
> + "CDB");
> }
>
> static void ufshcd_add_query_upiu_trace(struct ufs_hba *hba, unsigned int
> tag,
> @@ -329,7 +330,7 @@ static void ufshcd_add_query_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
> rq_rsp = (struct utp_upiu_req *)hba->lrb[tag].ucd_rsp_ptr;
>
> trace_ufshcd_upiu(dev_name(hba->dev), str, _rsp->header,
> - _rsp->qr);
> + _rsp->qr, "OSF");
> }
>
> static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, unsigned int
> tag,
> @@ -340,10 +341,10 @@ static void ufshcd_add_tm_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
>
> if (!strcmp("tm_send", str))
> trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
> - >input_param1);
> + >input_param1, "TM_INPUT");
> else
> trace_ufshcd_upiu(dev_name(hba->dev), str, >rsp_header,
> - >output_param1);
> + >output_param1, "TM_OUTPUT");
> }
>
> static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
> diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
> index 0bd54a184391..68e8e97a9b47 100644
> --- a/include/trace/events/ufs.h
> +++ b/include/trace/events/ufs.h
> @@ -295,15 +295,17 @@ TRACE_EVENT(ufshcd_uic_command,
> );
>
> TRACE_EVENT(ufshcd_upiu,
> - TP_PROTO(const char *dev_name, const char *str, void *hdr, void *tsf),
> + TP_PROTO(const char *dev_name, const char *str, void *hdr, void *tsf,
> +const char *tsf_type),
>
> - TP_ARGS(dev_name, str, hdr, tsf),
> + TP_ARGS(dev_name, str, hdr, tsf, tsf_type),
>
> TP_STRUCT__entry(
> __string(dev_name, dev_name)
> __string(str, str)
> __array(unsigned char, hdr, 12)
> __array(unsigned char, tsf, 16)
> + __string(tsf_type, tsf_type)
> ),
>
> TP_fast_assign(
> @@ -311,12 +313,14 @@ TRACE_EVENT(ufshcd_upiu,
> __assign_str(str, str);
> memcpy(__entry->hdr, hdr, sizeof(__entry->hdr));
> memcpy(__entry->tsf, tsf, sizeof(__entry->tsf));
> + __assign_str(tsf_type, tsf_type);
> ),
>
> TP_printk(
> - "%s: %s: HDR:%s, CDB:%s",
> + "%s: %s: HDR:%s, %s:%s",
> __get_str(str), __get_str(dev_name),
> __print_hex(__entry->hdr, sizeof(__entry->hdr)),
> + __get_str(tsf_type),
This breaks what current parsers expects.
Why str is not enough to distinguish between the command?
Thanks,
Avri
> __print_hex(__entry->tsf, sizeof(__entry->tsf))
> )
> );
> --
> 2.17.1
Re: [PATCH v2] phram: Allow the user to set the erase page size.
Hi Guohua, Guohua Zhong wrote on Mon, 7 Dec 2020 15:07:15 +0800: > On Mon, Dec 7, 2020 at 14:56 AM Guohua Zhong wrote: > > > >> Permit the user to specify the erase page size as a parameter. > >> This solves two problems: > > > >> - phram can access images made by mkfs.jffs2. mkfs.jffs2 won't > >> create images with erase sizes less than 8KiB; many architectures > >> define PAGE_SIZE as 4KiB. > > > >> - Allows more effective use of small capacity devices. JFFS2 > >> needs somewhere between 2 and 5 empty pages for garbage collection; > >> and for an NVRAM part with only 32KiB of space, a smaller erase page > >> allows much better utilization in applications where garbage collection > >> is important. > > > >> Signed-off-by: Patrick O'Grady > >> Reviewed-by: Joern Engel > >> Link: > >> https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/ > >> [Guohua Zhong: fix token array index out of bounds and update patch for > >> kernel master branch] > >> Signed-off-by: Guohua Zhong > >> Reported-by: kernel test robot > > > > Looks good to me, except the authorship. > > If I understand correctly, you took this old patch and resend it. > > Please make sure that the "From:"-Line contains the original author. > > You can fix this up using git commit --amend --author=. > > The git format-patch will create a correct patch. > > Sorry, I am not clear this rule before. But I found the same issue > independently. It looks good > after changging the erase size for phram driver. Then when I try to send the > patch, I found that > Patrick O'Grady has already send a patch which has not been merged as the > link below > https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/ > > So I resend a patch with some change and fix for mainline kernel with the old > patch link of Patrick O'Grady. > > If I need to change the authorship, I will resend this patch for V3 with > authorship of Patrick O'Grady. Yes please. Also please drop the reference to kernel test robot as you are not fixing an issue in the kernel that the robot reported (perhaps you had a warning from the robot about the patch itself, this is called a review and we usually don't get credited for that, at least not with a misleading reported-by tag). Thanks, Miquèl
Re: [f2fs-dev] [PATCH 2/2] f2fs: introduce max_io_bytes, a sysfs entry, to limit bio size
On 2020/12/4 4:55, Jaegeuk Kim wrote: This patch adds max_io_bytes to limit bio size when f2fs tries to merge consecutive IOs. This can give a testing point to split out bios and check end_io handles those bios correctly. This is used to capture a recent bug on the decompression and fsverity flow. Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
Re: [f2fs-dev] [PATCH 1/2] f2fs: don't allow any writes on readonly mount
On 2020/12/4 4:55, Jaegeuk Kim wrote: generic_make_request: Trying to write to read-only block-device dm-5 (partno 0) WARNING: CPU: 7 PID: 546 at block/blk-core.c:2190 generic_make_request_checks+0x664/0x690 pc : generic_make_request_checks+0x664/0x690 lr : generic_make_request_checks+0x664/0x690 Call trace: generic_make_request_checks+0x664/0x690 generic_make_request+0xf0/0x3a4 submit_bio+0x80/0x250 __submit_merged_bio+0x368/0x4e0 __submit_merged_write_cond.llvm.12294350193007536502+0xe0/0x3e8 f2fs_wait_on_page_writeback+0x84/0x128 f2fs_convert_inline_page+0x35c/0x6f8 f2fs_convert_inline_inode+0xe0/0x2e0 f2fs_file_mmap+0x48/0x9c mmap_region+0x41c/0x74c do_mmap+0x40c/0x4fc vm_mmap_pgoff+0xb8/0x114 vm_mmap+0x34/0x48 elf_map+0x68/0x108 load_elf_binary+0x538/0xb70 search_binary_handler+0xac/0x1dc exec_binprm+0x50/0x15c __do_execve_file+0x620/0x740 __arm64_sys_execve+0x54/0x68 el0_svc_common+0x9c/0x168 el0_svc_handler+0x60/0x6c el0_svc+0x8/0xc Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
linux-next: build warning after merge of the jc_docs tree
Hi all,
After merging the jc_docs tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/nios2/index.rst:7: WARNING: toctree contains reference to
nonexisting document 'nios2/features'
Introduced by commit
ed13a92d0fde ("docs: archis: add a per-architecture features list")
--
Cheers,
Stephen Rothwell
pgpM3JUPIkozk.pgp
Description: OpenPGP digital signature
Re: [PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons
On Friday, 27 November 2020 19:54:30 CET ron minnich wrote: > Thanks, Sven, for your patience, I will indeed try to test this next week. Any test results? Kind regards, Sven signature.asc Description: This is a digitally signed message part.
linux-next: build warning after merge of the hwmon-staging tree
Hi all,
After merging the hwmon-staging tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/hwmon/q54sj108a2.rst:4: WARNING: Title underline too short.
Kernel driver q54sj108a2
=
Introduced by commit
b722d7b9e4da ("hwmon: (pmbus) Driver for Delta power supplies Q54SJ108A2")
--
Cheers,
Stephen Rothwell
pgpxgq_PQN5Lr.pgp
Description: OpenPGP digital signature
RE: [PATCH v1 2/3] scsi: ufs: Distinguish between TM request UPIU and response UPIU in TM UPIU trace
>
>
> From: Bean Huo
>
> Distinguish between TM request UPIU and response UPIU in TM UPIU trace,
> for the TM response, let TM UPIU trace print its TM response UPIU.
>
> Signed-off-by: Bean Huo
Acked-by: Avri Altman
Again - same comment:
But you need to change the complete string so not to break the current parsers.
I would also pass to the struct utp_upiu_header *,
so no comparison is needed.
Thanks,
Avri
> ---
> drivers/scsi/ufs/ufshcd.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index e10de94adb3f..29d7240a61bf 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -338,8 +338,12 @@ static void ufshcd_add_tm_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
> int off = (int)tag - hba->nutrs;
> struct utp_task_req_desc *descp = >utmrdl_base_addr[off];
>
> - trace_ufshcd_upiu(dev_name(hba->dev), str, >req_header,
> - >input_param1);
> + if (!strcmp("tm_send", str))
> + trace_ufshcd_upiu(dev_name(hba->dev), str,
> >req_header,
> + >input_param1);
> + else
> + trace_ufshcd_upiu(dev_name(hba->dev), str,
> >rsp_header,
> + >output_param1);
> }
>
> static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
> --
> 2.17.1
Re: [PATCH net] net: hns3: remove a misused pragma packed
From: Huazhong Tan
Date: Mon, 7 Dec 2020 15:20:25 +0800
> hclge_dbg_reg_info[] is defined as an array of packed structure
> accidentally. However, this array contains pointers, which are
> no longer aligned naturally, and cannot be relocated on PPC64.
> Hence, when compile-testing this driver on PPC64 with
> CONFIG_RELOCATABLE=y (e.g. PowerPC allyesconfig), there will be
> some warnings.
>
> Since each field in structure hclge_qos_pri_map_cmd and
> hclge_dbg_bitmap_cmd is type u8, the pragma packed is unnecessary
> for these two structures as well, so remove the pragma packed in
> hclge_debugfs.h to fix this issue, and this increases
> hclge_dbg_reg_info[] by 4 bytes per entry.
>
> Fixes: a582b78dfc33 ("net: hns3: code optimization for debugfs related to
> "dump reg"")
> Reported-by: Stephen Rothwell
> Signed-off-by: Huazhong Tan
Applied, thank you.
linux-next: build warning after merge of the block tree
Hi all,
After merging the block tree, today's linux-next build (htmldocs)
produced this warning:
kernel/trace/blktrace.c:1039: warning: Excess function parameter 'q'
description in 'blk_add_trace_rq_remap'
Introduced by commit
a54895fa057c ("block: remove the request_queue to argument request based
tracepoints")
--
Cheers,
Stephen Rothwell
pgpFQ9Tornr6B.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/5] crypto: hisilicon/sec - add new type of sqe for Kunpeng930
On Mon, Dec 07, 2020 at 03:46:28PM +0800, liulongfang wrote: > > I need to use "__packed __aligned(n)" to make sure the structure length is > normal. > Is it possible to use "__packed __aligned(n)" in the kernel? I don't see why not. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
RE: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
> -Original Message- > From: Anshuman Khandual [mailto:anshuman.khand...@arm.com] > Sent: Monday, December 7, 2020 8:31 PM > To: Song Bao Hua (Barry Song) ; Mike Rapoport > ; Will Deacon > Cc: steve.cap...@arm.com; catalin.mari...@arm.com; > linux-kernel@vger.kernel.org; nsaenzjulie...@suse.de; liwei (CM) > ; butao ; > linux-arm-ker...@lists.infradead.org; fengbaopeng > > Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the memory > reserved for the page map > > > > On 12/7/20 7:10 AM, Song Bao Hua (Barry Song) wrote: > > > > > >> -Original Message- > >> From: Mike Rapoport [mailto:r...@linux.ibm.com] > >> Sent: Saturday, December 5, 2020 12:44 AM > >> To: Will Deacon > >> Cc: liwei (CM) ; catalin.mari...@arm.com; fengbaopeng > >> ; nsaenzjulie...@suse.de; > steve.cap...@arm.com; > >> Song Bao Hua (Barry Song) ; > >> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; butao > >> > >> Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the > >> memory > >> reserved for the page map > >> > >> On Fri, Dec 04, 2020 at 11:13:47AM +, Will Deacon wrote: > >>> On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > do not free the reserved memory for the page map, decrease the section > size can reduce the waste of reserved memory. > > Signed-off-by: Wei Li > Signed-off-by: Baopeng Feng > Signed-off-by: Xia Qing > --- > arch/arm64/include/asm/sparsemem.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/sparsemem.h > >> b/arch/arm64/include/asm/sparsemem.h > index 1f43fcc79738..8963bd3def28 100644 > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,7 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITSCONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS 30 > +#define SECTION_SIZE_BITS 27 > >>> > >>> We chose '30' to avoid running out of bits in the page flags. What > >>> changed? > >> > >> I think that for 64-bit there are still plenty of free bits. I didn't > >> check now, but when I played with SPARSEMEM on m68k there were 8 bits > >> for section out of 32. > >> > >>> With this patch, I can trigger: > >>> > >>> ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds > >> SECTION_SIZE > >>> #error Allocator MAX_ORDER exceeds SECTION_SIZE > >>> > >>> if I bump up NR_CPUS and NODES_SHIFT. > >> > >> I don't think it's related to NR_CPUS and NODES_SHIFT. > >> This seems rather 64K pages that cause this. > >> > >> Not that is shouldn't be addressed. > > > > Right now, only 4K PAGES will define ARM64_SWAPPER_USES_SECTION_MAPS. > > Other cases will use vmemmap_populate_basepages(). > > The original patch should be only addressing the issue in 4K pages: > > https://lore.kernel.org/lkml/20200812010655.96339-1-liwei...@huawei.com/ > > > > would we do something like the below? > > #ifdef CONFIG_ARM64_4K_PAGE > > #define SECTION_SIZE_BITS 27 > > #else > > #define SECTION_SIZE_BITS 30 > > #endif > > This is bit arbitrary. Probably 27 can be further reduced for 4K page size. > Instead, we should make SECTION_SIZE_BITS explicitly depend upon MAX_ORDER. > IOW section size should be the same as the highest order page in the buddy. > CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64. A quick test shows > SECTION_SIZE_BITS would be 22 on 4K pages and 29 for 64K pages. As a fall > back SECTION_SIZE_BITS can still be 30 in case CONFIG_FORCE_MAX_ZONEORDER > is not defined. This will break the pmd mapping for vmemmap. As for each 128M(2^27), we can have 2MB pmd mapping. > > --- a/arch/arm64/include/asm/sparsemem.h > +++ b/arch/arm64/include/asm/sparsemem.h > @@ -7,7 +7,7 @@ > > #ifdef CONFIG_SPARSEMEM > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > -#define SECTION_SIZE_BITS 30 > +#define SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) > #endif > > #endif > > A similar approach exists on ia64 platform as well. Thanks Barry
Re: [PATCH 2/5] crypto: hisilicon/sec - add new type of sqe for Kunpeng930
On 2020/12/7 11:45, Herbert Xu Wrote: > On Mon, Dec 07, 2020 at 11:43:38AM +0800, liulongfang wrote: >> >> Can I use __attribute__((aligned(n))) instead of #pragma pack(n)? > > We normally just use __aligned(n) in the kernel. > > Cheers, > I need to use "__packed __aligned(n)" to make sure the structure length is normal. Is it possible to use "__packed __aligned(n)" in the kernel? Thanks. Longfang.
Re: [RFC PATCH v2 0/2] add simple copy support
On 04.12.2020 23:40, Keith Busch wrote:
On Fri, Dec 04, 2020 at 11:25:12AM +, Damien Le Moal wrote:
On 2020/12/04 20:02, SelvaKumar S wrote:
> This patchset tries to add support for TP4065a ("Simple Copy Command"),
> v2020.05.04 ("Ratified")
>
> The Specification can be found in following link.
> https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
>
> This is an RFC. Looking forward for any feedbacks or other alternate
> designs for plumbing simple copy to IO stack.
>
> Simple copy command is a copy offloading operation and is used to copy
> multiple contiguous ranges (source_ranges) of LBA's to a single destination
> LBA within the device reducing traffic between host and device.
>
> This implementation accepts destination, no of sources and arrays of
> source ranges from application and attach it as payload to the bio and
> submits to the device.
>
> Following limits are added to queue limits and are exposed in sysfs
> to userspace
>- *max_copy_sectors* limits the sum of all source_range length
>- *max_copy_nr_ranges* limits the number of source ranges
>- *max_copy_range_sectors* limit the maximum number of sectors
>that can constitute a single source range.
Same comment as before. I think this is a good start, but for this to be really
useful to users and kernel components alike, this really needs copy emulation
for drives that do not have a native copy feature, similarly to what write zeros
handling for instance: if the drive does not have a copy command (simple copy
for NVMe or XCOPY for scsi), then the block layer should issue read/write
commands to seamlessly execute the copy. Otherwise, this will only serve a small
niche for users and will not be optimal for FS and DM drivers that could be
simplified with a generic block layer copy functionality.
This is my 10 cents though, others may differ about this.
Yes, I agree that copy emulation support should be included with the
hardware enabled solution.
Keith, Damien,
Can we do the block layer emulation with this patchset and then work in
follow-up patchses on (i) the FS interface with F2FS as a first user and
(ii) other HW accelerations such as XCOPY?
For XCOPY, I believe we need to have a separate discussion as much works
is already done that we should align to.
Re: [RFC][PATCH 1/2] cpufreq: Add special-purpose fast-switching callback for drivers
On 30-11-20, 19:37, Rafael J. Wysocki wrote:
> Index: linux-pm/include/linux/cpufreq.h
> ===
> --- linux-pm.orig/include/linux/cpufreq.h
> +++ linux-pm/include/linux/cpufreq.h
> @@ -320,6 +320,15 @@ struct cpufreq_driver {
> unsigned int index);
> unsigned int(*fast_switch)(struct cpufreq_policy *policy,
> unsigned int target_freq);
> + /*
> + * ->fast_switch() replacement for drivers that use an internal
> + * representation of performance levels and can pass hints other than
> + * the target performance level to the hardware.
> + */
> + void(*adjust_perf)(unsigned int cpu, bool busy,
Maybe this should still take policy as an argument (like other calls)
instead of CPU, even if it is going to be used for single-cpu per
policy case for now.
> +unsigned long min_perf,
> +unsigned long target_perf,
> +unsigned long capacity);
--
viresh
RE: [PATCH v1 1/3] scsi: ufs: Distinguish between query REQ and query RSP in query trace
>
> From: Bean Huo
>
> Currently, in the query completion trace print, since we use
> hba->lrb[tag].ucd_req_ptr and didn't differentiate UPIU between
> request and response, thus header and transaction-specific field
> in UPIU printed by query trace are identical. This is not very
> practical. As below:
>
> query_send: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00
> 00 00 00 00 00 00 00 00 00
> query_complete: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00
> 00 00 00 00 00 00 00 00 00 00 00
>
> For the failure analysis, we want to understand the real response
> reported by the UFS device, however, the current query trace tells
> us nothing. After this patch, the query trace on the query_send, and
> the above a pair of query_send and query_complete will be:
>
> query_send: HDR:16 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00
> 00 00 00 00 00 00 00 00 00
> ufshcd_upiu: HDR:36 00 00 0e 00 81 00 00 00 00 00 00, CDB:06 0e 03 00 00 00 00
> 00 00 00 00 01 00 00 00 00
>
> Signed-off-by: Bean Huo
Acked-by: Avri Altman
But you need to change the complete string so not to break the current parsers.
I would also pass to ufshcd_add_query_upiu_trace the struct utp_upiu_req *,
so no comparison is needed.
Thanks,
Avri
> ---
> drivers/scsi/ufs/ufshcd.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index ceb562accc39..e10de94adb3f 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -321,9 +321,15 @@ static void ufshcd_add_cmd_upiu_trace(struct
> ufs_hba *hba, unsigned int tag,
> static void ufshcd_add_query_upiu_trace(struct ufs_hba *hba, unsigned int
> tag,
> const char *str)
> {
> - struct utp_upiu_req *rq = hba->lrb[tag].ucd_req_ptr;
> + struct utp_upiu_req *rq_rsp;
> +
> + if (!strcmp("query_send", str))
> + rq_rsp = hba->lrb[tag].ucd_req_ptr;
> + else
> + rq_rsp = (struct utp_upiu_req *)hba->lrb[tag].ucd_rsp_ptr;
>
> - trace_ufshcd_upiu(dev_name(hba->dev), str, >header, >qr);
> + trace_ufshcd_upiu(dev_name(hba->dev), str, _rsp->header,
> + _rsp->qr);
> }
>
> static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, unsigned int
> tag,
> --
> 2.17.1
Re: [f2fs-dev] [PATCH v3] f2fs: fix race of pending_pages in decompression
On 2020/12/7 15:28, Daeho Jeong wrote:
It looks like it will be better to move this into merge condition?
if (bio && (!page_is_mergeable(sbi, bio,
*last_block_in_bio, blkaddr) ||
!f2fs_crypt_mergeable_bio(bio, inode, page->index, NULL) ||
f2fs_verify_mergeable_bio())) {
I tried this for the first time, but it requires unnecessary checks
within the compression cluster.
We only need to check f2fs_verify_mergeable_bio for i == 0 case? something like:
static bool f2fs_verify_mergeable_bio(struct bio *bio, bool verify, bool
first_page)
{
if (!first_page)
return false;
if (!verify)
return false;
ctx = bio->bi_private;
if (!(ctx->enabled_steps & (1 << STEP_VERITY)))
return true;
}
Thoughts?
I wanted to just check one time in the beginning of the cluster.
What do you think?
It's trivial, but I'm think about the readability... at least, one line comment
is needed to describe why we submit previous bio. :)
Thanks,
.
Re: BUG: Invalid wait context with KMEMLEAK and KASAN enabled
Boqun,
- Ursprüngliche Mail -
>> Does this ring a bell?
>>
>> [2.298447] =
>> [2.298971] [ BUG: Invalid wait context ]
>> [2.298971] 5.10.0-rc6+ #388 Not tainted
>> [2.298971] -
>> [2.298971] ksoftirqd/1/15 is trying to lock:
>> [2.298971] 888100b94598 (>list_lock){}-{3:3}, at:
>> free_debug_processing+0x3d/0x210
>
> I guest you also had CONFIG_PROVE_RAW_LOCK_NESTING=y, right?
Yes, this is the case!
Thanks,
//richard
Re: [PATCH v5 02/19] dt-bindings: usb: Convert generic USB properties to DT schemas
On Sat, 2020-12-05 at 18:24 +0300, Serge Semin wrote:
> The generic USB properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert its content into the generic USB, USB HCD and USB DRD DT
> schemas. So the Generic USB schema will be applicable to all USB
> controllers, USB HCD - for the generic USB Host controllers and the USB
> DRD - for the USB Dual-role controllers.
>
> Note the USB DRD schema is supposed to work in conjunction with
> the USB peripheral/gadget and USB host controllers DT schemas.
>
> Signed-off-by: Serge Semin
> Reviewed-by: Rob Herring
>
> ---
>
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
> the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
> the multi-lined version of the list.
> - Drop quotes from around the string constants.
>
> Changelog v4:
> - Redistribute the properties between generic ones, USB HCD-specific and
> USB DRD-specific.
> - Discard the Rob'es Reviewed-by tag. Please review the patch one more time.
> ---
> .../devicetree/bindings/usb/generic.txt | 57 --
> .../devicetree/bindings/usb/usb-drd.yaml | 77 +++
> .../devicetree/bindings/usb/usb-hcd.yaml | 5 ++
> .../devicetree/bindings/usb/usb.yaml | 22 ++
> 4 files changed, 104 insertions(+), 57 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> create mode 100644 Documentation/devicetree/bindings/usb/usb-drd.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> b/Documentation/devicetree/bindings/usb/generic.txt
> deleted file mode 100644
> index ba472e7aefc9..
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ /dev/null
> @@ -1,57 +0,0 @@
> -Generic USB Properties
> -
> -Optional properties:
> - - maximum-speed: tells USB controllers we want to work up to a certain
> - speed. Valid arguments are "super-speed-plus",
> - "super-speed", "high-speed", "full-speed" and
> - "low-speed". In case this isn't passed via DT, USB
> - controllers should default to their maximum HW
> - capability.
> - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> - particular mode. Valid arguments are "host",
> - "peripheral" and "otg". In case this attribute isn't
> - passed via DT, USB DRD controllers should default to
> - OTG.
> - - phy_type: tells USB controllers that we want to configure the core to
> support
> - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> - selected. Valid arguments are "utmi" and "utmi_wide".
> - In case this isn't passed via DT, USB controllers should
> - default to HW capability.
> - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> - with which the device and its descriptors are compliant,
> - in binary-coded decimal (i.e. 2.0 is 0200H). This
> - property is used if any real OTG features(HNP/SRP/ADP)
> - is enabled, if ADP is required, otg-rev should be
> - 0x0200 or above.
> - - companion: phandle of a companion
> - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally
> HNP
> - is the basic function of real OTG except you want it
> - to be a srp-capable only B device.
> - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> - optional for OTG device.
> - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> - optional for OTG device.
> - - usb-role-switch: boolean, indicates that the device is capable of
> assigning
> - the USB data role (USB host or USB device) for a given
> - USB connector, such as Type-C, Type-B(micro).
> - see connector/usb-connector.yaml.
> - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> - device default operation mode of controller while usb
> - role is USB_ROLE_NONE. Valid arguments are "host" and
> - "peripheral". Defaults to "peripheral" if not
> - specified.
> -
> -
> -This is an attribute to a USB controller such as:
> -
> -dwc3@4a03 {
> - compatible = "synopsys,dwc3";
> - reg = <0x4a03 0xcfff>;
> - interrupts = <0 92 4>
> - usb-phy = <_phy>, <,phy>;
> - maximum-speed = "super-speed";
> - dr_mode = "otg";
> - phy_type = "utmi_wide";
> - otg-rev = <0x0200>;
> - adp-disable;
> -};
> diff --git
Re: [PATCH] MAINTAINERS: Update 68k Mac entry
Hi Finn,
On Sat, Dec 5, 2020 at 4:49 AM Finn Thain wrote:
> Two files under drivers/macintosh are actually m68k-only. I think that
> patches for these files should be reviewed in the appropriate forum and
> merged via the appropriate tree, rather than falling to the powerpc
> maintainers to deal with. Update the "M68K ON APPLE MACINTOSH" section
> accordingly.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Joshua Thompson
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-m...@lists.linux-m68k.org
> Signed-off-by: Finn Thain
Reviewed-by: Geert Uytterhoeven
i.e. will queue in the m68k for-v5.11 branch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [v2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase
Hi: Thank you very much for your patience review. There are two main purposes of this patch: 1.i2c_mark_adapter_suspended_mark_adapter_resumed Avoid accessing the adapter while it is suspended by marking it suspended during suspend. This allows the I2C core to catch this, and print a warning. https://patchwork.kernel.org/project/linux-arm-kernel/patch/20181219164827.20985-2-wsa+rene...@sang-engineering.com/ 2. IRQF_NO_SUSPEND. Having interrupts disabled means not only that an interrupt will not occur at an awkward time, but also that using any functionality that requires interrupts will not work. So if the driver uses an I2C bus or similar to tell the device to turn off, and if the I2C bus uses interrupts to indicate completion (which is normal), then either the device must be powered-off in suspend_late, so the I2C interrupt must be marked IRQF_NO_SUSPEND. https://patchwork.kernel.org/project/linux-acpi/patch/20180923135812.29574-8-hdego...@redhat.com/ On Thu, 2020-12-03 at 10:01 +0200, Grygorii Strashko wrote: > > On 03/12/2020 03:25, Qii Wang wrote: > > On Wed, 2020-12-02 at 16:35 +0100, Wolfram Sang wrote: > >> Hi, > >> > >>> Some i2c device driver indirectly uses I2C driver when it is now > >>> being suspended. The i2c devices driver is suspended during the > >>> NOIRQ phase and this cannot be changed due to other dependencies. > >>> Therefore, we also need to move the suspend handling for the I2C > >>> controller driver to the NOIRQ phase as well. > >>> > >>> Signed-off-by: Qii Wang > >> > >> Is this a bugfix and should go into 5.10? Or can it wait for 5.11? > >> > > > > Yes, Can you help to apply it into 5.10? Thanks > > To be honest if you still do have any i2c device which accessing i2c buss > after _noirq > stage and your driver does not implement .master_xfer_atomic() - you > definitely have a bigger problem. > So adding IRQF_NO_SUSPEND sound like a hack and probably works just by luck. > At present, it is only a problem caused by missing interrupts, and .master_xfer_atomic() just a implement in polling mode. Why not set the interrupt to a state that can always be triggered?
[PATCH] ALSA: hda/realtek - Add support for Memeza EDL03 headset mic
The Memeza laptop EDL03 with codec ALC256 can't detect the headset
microphone. The headphone jack sensing works after we add a pin
definition for it by ALC256_FIXUP_ASUS_MIC_NO_PRESENCE.
Signed-off-by: Chris Chiu
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d5e4d0ba1008..8b9b94cfc67e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7871,6 +7871,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7",
ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904",
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board",
ALC700_FIXUP_INTEL_REFERENCE),
+ SND_PCI_QUIRK(0x10ec, 0x115a, "Memeza EDL03",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x10ec, 0x1230, "Intel Reference board",
ALC295_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6",
ALC269_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)",
ALC269_FIXUP_INV_DMIC),
--
2.20.1
Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map
On 12/7/20 7:10 AM, Song Bao Hua (Barry Song) wrote: > > >> -Original Message- >> From: Mike Rapoport [mailto:r...@linux.ibm.com] >> Sent: Saturday, December 5, 2020 12:44 AM >> To: Will Deacon >> Cc: liwei (CM) ; catalin.mari...@arm.com; fengbaopeng >> ; nsaenzjulie...@suse.de; steve.cap...@arm.com; >> Song Bao Hua (Barry Song) ; >> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; butao >> >> Subject: Re: [PATCH] arm64: mm: decrease the section size to reduce the >> memory >> reserved for the page map >> >> On Fri, Dec 04, 2020 at 11:13:47AM +, Will Deacon wrote: >>> On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP do not free the reserved memory for the page map, decrease the section size can reduce the waste of reserved memory. Signed-off-by: Wei Li Signed-off-by: Baopeng Feng Signed-off-by: Xia Qing --- arch/arm64/include/asm/sparsemem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/sparsemem.h >> b/arch/arm64/include/asm/sparsemem.h index 1f43fcc79738..8963bd3def28 100644 --- a/arch/arm64/include/asm/sparsemem.h +++ b/arch/arm64/include/asm/sparsemem.h @@ -7,7 +7,7 @@ #ifdef CONFIG_SPARSEMEM #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS -#define SECTION_SIZE_BITS 30 +#define SECTION_SIZE_BITS 27 >>> >>> We chose '30' to avoid running out of bits in the page flags. What changed? >> >> I think that for 64-bit there are still plenty of free bits. I didn't >> check now, but when I played with SPARSEMEM on m68k there were 8 bits >> for section out of 32. >> >>> With this patch, I can trigger: >>> >>> ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds >> SECTION_SIZE >>> #error Allocator MAX_ORDER exceeds SECTION_SIZE >>> >>> if I bump up NR_CPUS and NODES_SHIFT. >> >> I don't think it's related to NR_CPUS and NODES_SHIFT. >> This seems rather 64K pages that cause this. >> >> Not that is shouldn't be addressed. > > Right now, only 4K PAGES will define ARM64_SWAPPER_USES_SECTION_MAPS. > Other cases will use vmemmap_populate_basepages(). > The original patch should be only addressing the issue in 4K pages: > https://lore.kernel.org/lkml/20200812010655.96339-1-liwei...@huawei.com/ > > would we do something like the below? > #ifdef CONFIG_ARM64_4K_PAGE > #define SECTION_SIZE_BITS 27 > #else > #define SECTION_SIZE_BITS 30 > #endif This is bit arbitrary. Probably 27 can be further reduced for 4K page size. Instead, we should make SECTION_SIZE_BITS explicitly depend upon MAX_ORDER. IOW section size should be the same as the highest order page in the buddy. CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64. A quick test shows SECTION_SIZE_BITS would be 22 on 4K pages and 29 for 64K pages. As a fall back SECTION_SIZE_BITS can still be 30 in case CONFIG_FORCE_MAX_ZONEORDER is not defined. --- a/arch/arm64/include/asm/sparsemem.h +++ b/arch/arm64/include/asm/sparsemem.h @@ -7,7 +7,7 @@ #ifdef CONFIG_SPARSEMEM #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS -#define SECTION_SIZE_BITS 30 +#define SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT) #endif #endif A similar approach exists on ia64 platform as well.
[PATCH] ALSA: hda/realtek - Enable headset mic of ASUS X430UN with ALC256
The ASUS laptop X430UN with ALC256 can't detect the headset microphone
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.
Signed-off-by: Chris Chiu
Signed-off-by: Jian-Hong Pan
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f2398721ac1e..d5e4d0ba1008 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7827,6 +7827,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x10d0, "ASUS X540LA/X540LJ",
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x115d, "Asus 1015E",
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
SND_PCI_QUIRK(0x1043, 0x11c0, "ASUS X556UR",
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1043, 0x1271, "ASUS X430UN",
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1290, "ASUS X441SA",
ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x12a0, "ASUS X441UV",
ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC),
--
2.20.1
Re: [PATCH v2 00/19] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA
Hi Santosh, On 24/11/2020 19.08, Vinod Koul wrote: > On 17-11-20, 12:56, Peter Ujfalusi wrote: >> Hi, >> >> The series have build dependency on ti_sci/soc series (v2): >> https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/ >> >> Santosh kindly created immutable branch holdinf the series: >> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git >> for_5.11/drivers-soc > > Santosh, Can I have a signed tag for this please? Can you please provide a tag for Vinod? I'm ready to send v3 with few small fixes and waiting for Rob to get to the binding documents before I do. Thanks, - Péter >> >> The unmapped event handling in INTA is already mainline. >> >> Changes since v1: >> - Both DT binding document has been updated to address all comments and >> suggestions from Rob, all checks are passing on them >> - included new patch to fix the normal channel start offset when ultra-high >> capacity channels are available for the UDMA and updated the BCDMA/PKTDMA >> patches along the same line >> - Re-arranged the patches for Vinod so that the preparational patches and >> fixes >> can be picked up separately (they still have dependency on Santosh's >> branch): >> >> patch 1-5: Fixes and new features for existing devices using UDMA, but the >> the BCDMA/PKTDMA support is building on top of these. >> Build dependency on Santosh's branch >> patch 6: Optional second stage router configuration callback support in >> core >> patch 7-9: Per channel coherency support in core and use it in dmatest. >> patch 10-: Initial AM64 BCDMA and PKTDMA support >> >> The DMSS introduced within AM64 as a simplified Data movement engine is built >> on similar grounds as the K3 NAVSS and UDMAP, but with significant >> architectural >> changes. >> >> - Rings are built into the DMAs >> The DMAs no longer use the general purpose ringacc, all rings has been moved >> inside of the DMAs. The new rings within the DMAs are simplified to be dual >> directional compared to the uni-directional rings in ringacc. >> There is no more of a concept of generic purpose rings, all rings are >> assigned >> to specific channels or flows. >> >> - Per channel coherency support >> The DMAs use the 'ASEL' bits to select data and configuration fetch path. The >> ASEL bits are placed at the unused parts of any address field used by the >> DMAs (pointers to descriptors, addresses in descriptors, ring base >> addresses). >> The ASEL is not part of the address (the DMAs can address 48bits). >> Individual channels can be configured to be coherent (via ACP port) or non >> coherent individually by configuring the ASEL to appropriate value. >> >> - Two different DMAs (well, three actually) >> PKTDMA >> Similar to UDMAP channels configured in packet mode. >> The flow configuration of the channels has changed significantly in a way >> that >> each channel have at least one flow assigned at design time and each flow is >> directly mapped to corresponding ring. >> When multiple flows are set, the channel can only use the flows within it's >> assigned range. >> PKTDMA also introduced multiple tflows which did not existed in UDMAP. >> >> BCDMA >> It has two types of channels: >> - split channels (tchan/rchan): Similar to UDMAP channels configured in TR >> mode. >> - Block copy channels (bchan): Similar to EDMA or traditional DMA channels, >> they >> can be used for mem2mem type of transfers or to service peripherals not >> accessible via PSI-L by using external triggers for the TR. >> BCDMA channels do not have support for multiple flows >> >> With the introduction of the new DMAs (especially the BCDMA) we also need to >> update the resource manager code to support the second range from sysfw for >> UDMA channels. >> >> The two outstanding change in the series in my view is >> the handling of the DMAs sideband signal of ASEL to select path to provide >> coherency or non coherency. >> >> The smaller one is the device_router_config callback to allow the >> configuration >> of the triggers when BCDMA is servicing a triggering peripheral to solve a >> chicken-egg situation: >> The router needs to know the event number to send which in turn depends on >> the >> channel we got for servicing the peripheral. >> >> Regards, >> Peter >> --- >> Grygorii Strashko (1): >> soc: ti: k3-ringacc: add AM64 DMA rings support. >> >> Peter Ujfalusi (17): >> dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt >> is not 0 >> dmaengine: ti: k3-udma: Wait for peer teardown completion if supported >> dmaengine: ti: k3-udma: Add support for second resource range from >> sysfw >> dmaengine: ti: k3-udma-glue: Add function to get device pointer for >> DMA API >> dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings >> dmaengine: of-dma: Add support for optional router configuration >> callback >> dmaengine: Add support for per channel coherency handling
Re: [f2fs-dev] [PATCH v3] f2fs: fix race of pending_pages in decompression
> It looks like it will be better to move this into merge condition?
>
> if (bio && (!page_is_mergeable(sbi, bio,
> *last_block_in_bio, blkaddr) ||
> !f2fs_crypt_mergeable_bio(bio, inode, page->index, NULL)
> ||
> f2fs_verify_mergeable_bio())) {
>
I tried this for the first time, but it requires unnecessary checks
within the compression cluster.
I wanted to just check one time in the beginning of the cluster.
What do you think?
Re: [PATCH 3/7] mm,madvise: call soft_offline_page() without MF_COUNT_INCREASED
On 2020-12-07 03:34, HORIGUCHI NAOYA wrote: diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 869ece2a1de2..ba861169c9ae 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1269,6 +1269,12 @@ static int memory_failure_dev_pagemap(unsigned long pfn, int flags, if (!cookie) goto out; + if (flags & MF_COUNT_INCREASED) + /* +* Drop the extra refcount in case we come from madvise(). +*/ + put_page(page); + Should this if-block come before dax_lock_page() block? Yeah, it should go first thing since as you noticed we kept the refcount if we fail. Saturday brain... I will fix it. Thanks Naoya -- Oscar Salvador SUSE L3
Re: [PATCH 1/3] iio: dummy: convert all simple allocation devm_ variants
On Sat, Dec 5, 2020 at 8:46 PM Jonathan Cameron wrote:
>
> On Thu, 3 Dec 2020 11:50:03 +0200
> Alexandru Ardelean wrote:
>
> > Since a main requirement for an IIO device is to have a parent device
> > object, it makes sense to attach more of the IIO device's objects to the
> > lifetime of the parent object, to clean up the code.
> > The idea is to also provide a base example that is more up-to-date with
> > what's going on lately with most IIO drivers.
>
> To some degree maybe, it's also very very handy for testing odd corner
> cases with. I'd definitely not recommend it as a reference driver
> because it inherently has some odd corners because we need to
> fake various things that don't exist without hardware.
It's funny because during GSoC it seemed like some people would try to
use this as a starting point, then shift to another working ADC/DAC
example.
I was also thinking about maybe extending this a bit further, to have
it a bit more dynamic at load time [being able to load fake IIO
drivers, load fake data to be read via fake IIO device].
No idea when this will be ready, but it's on my long todo-list.
>
> >
> > This change tackles the simple allocations, to convert them to
> > device-managed calls, and tie them to the parent device.
>
> I'm confused or maybe I missrecall how this works.
>
> IIRC there isn't a parent device...
>
> Maybe we could create one via a bit of smoke and magic.
Yep, there isn't one.
I'll add one through some smoke, magic, some OF and maybe some fake
i2c/spi device IDs.
>
>
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/iio/dummy/iio_simple_dummy.c | 29
> > 1 file changed, 8 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/iio/dummy/iio_simple_dummy.c
> > b/drivers/iio/dummy/iio_simple_dummy.c
> > index c0b7ef900735..2a2e62f780a1 100644
> > --- a/drivers/iio/dummy/iio_simple_dummy.c
> > +++ b/drivers/iio/dummy/iio_simple_dummy.c
> > @@ -574,11 +574,9 @@ static struct iio_sw_device *iio_dummy_probe(const
> > char *name)
> >* parent = >dev;
> >*/
> >
> > - swd = kzalloc(sizeof(*swd), GFP_KERNEL);
> > - if (!swd) {
> > - ret = -ENOMEM;
> > - goto error_kzalloc;
> > - }
> > + swd = devm_kzalloc(parent, sizeof(*swd), GFP_KERNEL);
> > + if (!swd)
> > + return ERR_PTR(-ENOMEM);
> > /*
> >* Allocate an IIO device.
> >*
> > @@ -587,11 +585,9 @@ static struct iio_sw_device *iio_dummy_probe(const
> > char *name)
> >* It also has a region (accessed by iio_priv()
> >* for chip specific state information.
> >*/
> > - indio_dev = iio_device_alloc(parent, sizeof(*st));
> > - if (!indio_dev) {
> > - ret = -ENOMEM;
> > - goto error_ret;
> > - }
> > + indio_dev = devm_iio_device_alloc(parent, sizeof(*st));
> > + if (!indio_dev)
> > + return ERR_PTR(-ENOMEM);
> >
> > st = iio_priv(indio_dev);
> > mutex_init(>lock);
> > @@ -615,7 +611,7 @@ static struct iio_sw_device *iio_dummy_probe(const char
> > *name)
> >*indio_dev->name = id->name;
> >*indio_dev->name = spi_get_device_id(spi)->name;
> >*/
> > - indio_dev->name = kstrdup(name, GFP_KERNEL);
> > + indio_dev->name = devm_kstrdup(parent, name, GFP_KERNEL);
> >
> > /* Provide description of available channels */
> > indio_dev->channels = iio_dummy_channels;
> > @@ -632,7 +628,7 @@ static struct iio_sw_device *iio_dummy_probe(const char
> > *name)
> >
> > ret = iio_simple_dummy_events_register(indio_dev);
> > if (ret < 0)
> > - goto error_free_device;
> > + return ERR_PTR(ret);
> >
> > ret = iio_simple_dummy_configure_buffer(indio_dev);
> > if (ret < 0)
> > @@ -649,11 +645,6 @@ static struct iio_sw_device *iio_dummy_probe(const
> > char *name)
> > iio_simple_dummy_unconfigure_buffer(indio_dev);
> > error_unregister_events:
> > iio_simple_dummy_events_unregister(indio_dev);
> > -error_free_device:
> > - iio_device_free(indio_dev);
> > -error_ret:
> > - kfree(swd);
> > -error_kzalloc:
> > return ERR_PTR(ret);
> > }
> >
> > @@ -683,10 +674,6 @@ static int iio_dummy_remove(struct iio_sw_device *swd)
> >
> > iio_simple_dummy_events_unregister(indio_dev);
> >
> > - /* Free all structures */
> > - kfree(indio_dev->name);
> > - iio_device_free(indio_dev);
> > -
> > return 0;
> > }
> >
>
[PATCH net] net: hns3: remove a misused pragma packed
hclge_dbg_reg_info[] is defined as an array of packed structure
accidentally. However, this array contains pointers, which are
no longer aligned naturally, and cannot be relocated on PPC64.
Hence, when compile-testing this driver on PPC64 with
CONFIG_RELOCATABLE=y (e.g. PowerPC allyesconfig), there will be
some warnings.
Since each field in structure hclge_qos_pri_map_cmd and
hclge_dbg_bitmap_cmd is type u8, the pragma packed is unnecessary
for these two structures as well, so remove the pragma packed in
hclge_debugfs.h to fix this issue, and this increases
hclge_dbg_reg_info[] by 4 bytes per entry.
Fixes: a582b78dfc33 ("net: hns3: code optimization for debugfs related to "dump
reg"")
Reported-by: Stephen Rothwell
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h
index a9066e6..ca2ab6c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h
@@ -35,8 +35,6 @@
#define HCLGE_DBG_DFX_SSU_2_OFFSET 12
-#pragma pack(1)
-
struct hclge_qos_pri_map_cmd {
u8 pri0_tc : 4,
pri1_tc : 4;
@@ -85,8 +83,6 @@ struct hclge_dbg_reg_type_info {
struct hclge_dbg_reg_common_msg reg_msg;
};
-#pragma pack()
-
static const struct hclge_dbg_dfx_message hclge_dbg_bios_common_reg[] = {
{false, "Reserved"},
{true, "BP_CPU_STATE"},
--
2.7.4
Re: [PATCH 2/3] thermal: mediatek: Add LVTS drivers for SoC theraml zones
>
> Add a LVTS (Low voltage thermal sensor) driver to report junction
> temperatures in Mediatek SoC and register the maximum temperature
> of sensors and each sensor as a thermal zone.
>
> Signed-off-by: Yu-Chia Chang
> Signed-off-by: Michael Kao
> ---
> drivers/thermal/mediatek/Kconfig | 10 +
> drivers/thermal/mediatek/Makefile|1 +
> drivers/thermal/mediatek/soc_temp_lvts.c | 1293 ++
> drivers/thermal/mediatek/soc_temp_lvts.h | 312 ++
> 4 files changed, 1616 insertions(+)
> create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.c
> create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.h
>
> diff --git a/drivers/thermal/mediatek/Kconfig
> b/drivers/thermal/mediatek/Kconfig
> index 0351e73170b7..d716d0372e1e 100644
> --- a/drivers/thermal/mediatek/Kconfig
> +++ b/drivers/thermal/mediatek/Kconfig
> @@ -20,4 +20,14 @@ config MTK_SOC_THERMAL
> configures thermal controllers to collect temperature
> via AUXADC interface.
>
> +config MTK_SOC_THERMAL_LVTS
> +tristate "LVTS (Low voltage thermal sensor) driver for Mediatek SoCs"
> +depends on HAS_IOMEM
> +depends on NVMEM
> +depends on RESET_TI_SYSCON
> +help
> + Enable this option if you want to get SoC temperature
> + information for Mediatek platforms. This driver
> + configures LVTS thermal controllers to collect temperatures
> + via Analog Serial Interface(ASIF).
> endif
> diff --git a/drivers/thermal/mediatek/Makefile
> b/drivers/thermal/mediatek/Makefile
> index f75313ddce5e..16ce166e5916 100644
> --- a/drivers/thermal/mediatek/Makefile
> +++ b/drivers/thermal/mediatek/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_MTK_SOC_THERMAL) += soc_temp.o
> +obj-$(CONFIG_MTK_SOC_THERMAL_LVTS) += soc_temp_lvts.o
> diff --git a/drivers/thermal/mediatek/soc_temp_lvts.c
> b/drivers/thermal/mediatek/soc_temp_lvts.c
> new file mode 100644
> index ..1a608870c151
> --- /dev/null
> +++ b/drivers/thermal/mediatek/soc_temp_lvts.c
> @@ -0,0 +1,1293 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "soc_temp_lvts.h"
sort headers
> +
> +/*==
> + * Definition or macro function
> + *==
> + */
> +#define STOP_COUNTING_V4 (DEVICE_WRITE | RG_TSFM_CTRL_0 << 8 | 0x00)
> +#define SET_RG_TSFM_LPDLY_V4 (DEVICE_WRITE | RG_TSFM_CTRL_4 << 8 | 0xA6)
> +#define SET_COUNTING_WINDOW_20US1_V4 (DEVICE_WRITE | RG_TSFM_CTRL_2 << 8 |
> 0x00)
> +#define SET_COUNTING_WINDOW_20US2_V4 (DEVICE_WRITE | RG_TSFM_CTRL_1 << 8 |
> 0x20)
> +#define TSV2F_CHOP_CKSEL_AND_TSV2F_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_2 <<
> 8 | 0x84)
> +#define TSBG_DEM_CKSEL_X_TSBG_CHOP_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_4 <<
> 8 | 0x7C)
> +#define SET_TS_RSV_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_1 << 8 | 0x8D)
> +#define SET_TS_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 | 0xF4)
> +#define TOGGLE_RG_TSV2F_VCO_RST1_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 |
> 0xFC)
> +#define TOGGLE_RG_TSV2F_VCO_RST2_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 |
> 0xF4)
> +
> +#define SET_LVTS_AUTO_RCK_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_6 << 8 | 0x01)
> +#define SELECT_SENSOR_RCK_V4(id) (DEVICE_WRITE | RG_TSV2F_CTRL_5 << 8 | (id))
> +#define SET_DEVICE_SINGLE_MODE_V4 (DEVICE_WRITE | RG_TSFM_CTRL_3 << 8 | 0x78)
> +#define KICK_OFF_RCK_COUNTING_V4 (DEVICE_WRITE | RG_TSFM_CTRL_0 << 8 | 0x02)
> +#define SET_SENSOR_NO_RCK_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_5 << 8 | 0x10)
> +#define SET_DEVICE_LOW_POWER_SINGLE_MODE_V4 (DEVICE_WRITE | RG_TSFM_CTRL_3
> << 8| 0xB8)
> +
> +#define ENABLE_FEATURE(feature)(lvts_data->feature_bitmap |=
> (feature))
> +#define DISABLE_FEATURE(feature) (lvts_data->feature_bitmap &=
> (~(feature)))
> +#define IS_ENABLE(feature) (lvts_data->feature_bitmap &
> (feature))
> +
> +#define DISABLE_THERMAL_HW_REBOOT (-274000)
> +
> +#define CLOCK_26MHZ_CYCLE_NS (38)
> +#define BUS_ACCESS_US (2)
> +
> +#define FEATURE_DEVICE_AUTO_RCK(BIT(0))
> +#define FEATURE_CK26M_ACTIVE (BIT(1))
> +#define CK26M_ACTIVE (((lvts_data->feature_bitmap & FEATURE_CK26M_ACTIVE)
> \
> + ? 1 : 0) << 30)
> +#define GET_BASE_ADDR(tc_id) \
> + (lvts_data->domain[lvts_data->tc[tc_id].domain_index].base \
> + + lvts_data->tc[tc_id].addr_offset)
> +
> +#define SET_TC_SPEED_IN_US(pu, gd, fd, sd) \
> + { \
> + .period_unit = (((pu) * 1000) / (256 *
> CLOCK_26MHZ_CYCLE_NS)), \
> + .group_interval_delay = ((gd) / (pu)), \
> + .filter_interval_delay = ((fd) /
Re: [PATCH v2 0/5] Some cleanups and improvements for blk-iocost
Hi Jens, Hi, This patch set did some cleanups and improvements for blk-iocost, and no big functional changes. Please help to review. Thanks. Changes from v1: - Add acked-by tag from Tejun. - Drop 2 unnecessary patches. - Move the related variable declarations inside the block together with the code in patch 3. - Move the commit_weights() into ioc_check_iocgs(). - Move more related logics of adjusting base vrate into the ioc_adjust_base_vrate(). - Rename the new functions. Could you take this patch set if no objection from your side? Thanks. Baolin Wang (5): blk-iocost: Fix some typos in comments blk-iocost: Remove unnecessary advance declaration blk-iocost: Move the usage ratio calculation to the correct place blk-iocost: Factor out the active iocgs' state check into a separate function blk-iocost: Factor out the base vrate change into a separate function block/blk-iocost.c | 251 + 1 file changed, 137 insertions(+), 114 deletions(-)
Re: [PATCH 5.9 00/46] 5.9.13-rc1 review
On Sun, 6 Dec 2020 at 17:14, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.9.13 release. > There are 46 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 Tue, 08 Dec 2020 11:15:42 +. > 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/v5.x/stable-review/patch-5.9.13-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.9.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 NOTE: Following two warnings noticed. WARNING: bad unlock balance detected! - mkfs.ext4/426 is trying to release lock (rcu_read_lock) https://lore.kernel.org/stable/CA+G9fYs=nR-d0n8kV4=OWD+v=gr2ufoewu9s4og1_fzrxhg...@mail.gmail.com/ sched: core.c:7270 Illegal context switch in RCU-bh read-side critical section! __alloc_pages_nodemask https://lore.kernel.org/stable/ca+g9fyvhjtwqkgyh7hqzssdbht7pm5zia9vtkrhe_bdsqp3...@mail.gmail.com/ Summary kernel: 5.9.13-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.9.y git commit: 1372e1af58d410676db7917cc3484ca22d471623 git describe: v5.9.12-47-g1372e1af58d4 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.12-47-g1372e1af58d4 No regressions (compared to build v5.9.12) No fixes (compared to build v5.9.12) Ran 53360 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-i386-clang - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * v4l2-compliance * kvm-unit-tests * ltp-commands-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-math-tests * network-basic-tests * kselftest * ltp-controllers-tests * ltp-open-posix-tests * kunit * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] watchdog: qcom: Avoid context switch in restart handler
On 12/6/20 10:00 PM, Manivannan Sadhasivam wrote:
> The use of msleep() in the restart handler will cause scheduler to
> induce a context switch which is not desirable. This generates below
> warning on SDX55 when WDT is the only available restart source:
>
> [ 39.800188] reboot: Restarting system
> [ 39.804115] [ cut here ]
> [ 39.807855] WARNING: CPU: 0 PID: 678 at kernel/rcu/tree_plugin.h:297
> rcu_note_context_switch+0x190/0x764
> [ 39.812538] Modules linked in:
> [ 39.821954] CPU: 0 PID: 678 Comm: reboot Not tainted
> 5.10.0-rc1-00063-g33a9990d1d66-dirty #47
> [ 39.824854] Hardware name: Generic DT based system
> [ 39.833470] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 39.838154] [] (show_stack) from []
> (dump_stack+0x8c/0xa0)
> [ 39.846049] [] (dump_stack) from [] (__warn+0xd8/0xf0)
> [ 39.853058] [] (__warn) from []
> (warn_slowpath_fmt+0x64/0xc8)
> [ 39.859925] [] (warn_slowpath_fmt) from []
> (rcu_note_context_switch+0x190/0x764)
> [ 39.867503] [] (rcu_note_context_switch) from []
> (__schedule+0x84/0x640)
> [ 39.876685] [] (__schedule) from []
> (schedule+0x58/0x10c)
> [ 39.885095] [] (schedule) from []
> (schedule_timeout+0x1e8/0x3d4)
> [ 39.892135] [] (schedule_timeout) from []
> (msleep+0x2c/0x38)
> [ 39.899947] [] (msleep) from []
> (qcom_wdt_restart+0xc4/0xcc)
> [ 39.907319] [] (qcom_wdt_restart) from []
> (watchdog_restart_notifier+0x18/0x28)
> [ 39.914715] [] (watchdog_restart_notifier) from []
> (atomic_notifier_call_chain+0x60/0x84)
> [ 39.923487] [] (atomic_notifier_call_chain) from []
> (machine_restart+0x78/0x7c)
> [ 39.933551] [] (machine_restart) from []
> (__do_sys_reboot+0xdc/0x1e0)
> [ 39.942397] [] (__do_sys_reboot) from []
> (ret_fast_syscall+0x0/0x54)
> [ 39.950721] Exception stack(0xc3e0bfa8 to 0xc3e0bff0)
> [ 39.958855] bfa0: 0001221c bed2fe24 fee1dead 28121969
> 01234567
> [ 39.963832] bfc0: 0001221c bed2fe24 0003 0058 000225e0
>
> [ 39.971985] bfe0: b6e62560 bed2fc84 00010fd8 b6e62580
> [ 39.980124] ---[ end trace 3f578288bad866e4 ]---
>
> Hence, replace msleep() with mdelay() to fix this issue.
>
> Fixes: 05e487d905ab ("watchdog: qcom: register a restart notifier")
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Guenter Roeck
> ---
> drivers/watchdog/qcom-wdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> index ab7465d186fd..cdf754233e53 100644
> --- a/drivers/watchdog/qcom-wdt.c
> +++ b/drivers/watchdog/qcom-wdt.c
> @@ -148,7 +148,7 @@ static int qcom_wdt_restart(struct watchdog_device *wdd,
> unsigned long action,
>*/
> wmb();
>
> - msleep(150);
> + mdelay(150);
> return 0;
> }
>
>
[PATCH] Input: i8042 - add Acer laptops to the i8042 reset list
The touchpad operates in Basic Mode by default in the Acer BIOS
setup, but some Aspire/TravelMate models require the i8042 to be
reset in order to be correctly detected.
Signed-off-by: Chris Chiu
---
drivers/input/serio/i8042-x86ia64io.h | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index a4c9b9652560..f5ce656dc73f 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -607,6 +607,48 @@ static const struct dmi_system_id __initconst
i8042_dmi_reset_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA150"),
},
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-332"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-132"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-432"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A315-31"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A314-31"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A114-31"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate Spin B118-RN"),
+ },
+ },
{
/* Advent 4211 */
.matches = {
--
2.20.1
Re: [PATCH 6/6] mm/gup: migrate pinned pages out of movable zone
On Fri, Dec 04, 2020 at 12:43:29PM -0500, Pavel Tatashin wrote:
> On Thu, Dec 3, 2020 at 11:14 PM Joonsoo Kim wrote:
> >
> > On Wed, Dec 02, 2020 at 12:23:30AM -0500, Pavel Tatashin wrote:
> > > We do not allocate pin pages in ZONE_MOVABLE, but if pages were already
> > > allocated before pinning they need to migrated to a different zone.
> > > Currently, we migrate movable CMA pages only. Generalize the function
> > > that migrates CMA pages to migrate all movable pages.
> > >
> > > Signed-off-by: Pavel Tatashin
> > > ---
> > > include/linux/migrate.h| 1 +
> > > include/trace/events/migrate.h | 3 +-
> > > mm/gup.c | 56 +-
> > > 3 files changed, 24 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> > > index 0f8d1583fa8e..00bab23d1ee5 100644
> > > --- a/include/linux/migrate.h
> > > +++ b/include/linux/migrate.h
> > > @@ -27,6 +27,7 @@ enum migrate_reason {
> > > MR_MEMPOLICY_MBIND,
> > > MR_NUMA_MISPLACED,
> > > MR_CONTIG_RANGE,
> > > + MR_LONGTERM_PIN,
> > > MR_TYPES
> > > };
> > >
> > > diff --git a/include/trace/events/migrate.h
> > > b/include/trace/events/migrate.h
> > > index 4d434398d64d..363b54ce104c 100644
> > > --- a/include/trace/events/migrate.h
> > > +++ b/include/trace/events/migrate.h
> > > @@ -20,7 +20,8 @@
> > > EM( MR_SYSCALL, "syscall_or_cpuset")\
> > > EM( MR_MEMPOLICY_MBIND, "mempolicy_mbind") \
> > > EM( MR_NUMA_MISPLACED, "numa_misplaced") \
> > > - EMe(MR_CONTIG_RANGE,"contig_range")
> > > + EM( MR_CONTIG_RANGE,"contig_range") \
> > > + EMe(MR_LONGTERM_PIN,"longterm_pin")
> > >
> > > /*
> > > * First define the enums in the above macros to be exported to userspace
> > > diff --git a/mm/gup.c b/mm/gup.c
> > > index 724d8a65e1df..1d511f65f8a7 100644
> > > --- a/mm/gup.c
> > > +++ b/mm/gup.c
> > > @@ -1593,19 +1593,18 @@ static bool check_dax_vmas(struct vm_area_struct
> > > **vmas, long nr_pages)
> > > }
> > > #endif
> > >
> > > -#ifdef CONFIG_CMA
> > > -static long check_and_migrate_cma_pages(struct mm_struct *mm,
> > > - unsigned long start,
> > > - unsigned long nr_pages,
> > > - struct page **pages,
> > > - struct vm_area_struct **vmas,
> > > - unsigned int gup_flags)
> > > +static long check_and_migrate_movable_pages(struct mm_struct *mm,
> > > + unsigned long start,
> > > + unsigned long nr_pages,
> > > + struct page **pages,
> > > + struct vm_area_struct **vmas,
> > > + unsigned int gup_flags)
> > > {
> > > unsigned long i;
> > > unsigned long step;
> > > bool drain_allow = true;
> > > bool migrate_allow = true;
> > > - LIST_HEAD(cma_page_list);
> > > + LIST_HEAD(page_list);
> > > long ret = nr_pages;
> > > struct migration_target_control mtc = {
> > > .nid = NUMA_NO_NODE,
> > > @@ -1623,13 +1622,12 @@ static long check_and_migrate_cma_pages(struct
> > > mm_struct *mm,
> > >*/
> > > step = compound_nr(head) - (pages[i] - head);
> > > /*
> > > - * If we get a page from the CMA zone, since we are going to
> > > - * be pinning these entries, we might as well move them out
> > > - * of the CMA zone if possible.
> > > + * If we get a movable page, since we are going to be
> > > pinning
> > > + * these entries, try to move them out if possible.
> > >*/
> > > - if (is_migrate_cma_page(head)) {
> > > + if (is_migrate_movable(get_pageblock_migratetype(head))) {
> >
> > is_migrate_movable() isn't a check for the ZONE. It's a check for the
> > MIGRATE_TYPE. MIGRATE_TYPE doesn't require hard guarantee for
> > migration, and, most of memory, including ZONE_NORMAL, is
> > MIGRATE_MOVABLE. With this code, long term gup would always fails due
> > to not enough memory. I think that correct change would be
> > "is_migrate_cma_page(hear) && zone == ZONE_MOVABLE".
>
> Good point. The above should be OR not AND.
>
> zone_idx(page_zone(head)) == ZONE_MOVABLE || is_migrate_cma_page(hear)
Yep!
Thanks.
Re: [PATCH 0/2] SCMI performance protocol power scale interface
On 24-11-20, 10:43, Lukasz Luba wrote: > Hi all, > > The Energy Model (EM) supports power values expressed in an abstract scale > via new API. The SCMI performance protocol provides the information about > power scale. This patch set implements the needed interface and updates > cpufreq driver to set the right scale in the EM. > > It is based on top of patch series adding milli-Watts flag in EM [1] > (next-20201124 was used as a base). > > Regards, > Lukasz > > [1] > https://lore.kernel.org/linux-pm/20201103090600.29053-1-lukasz.l...@arm.com/ > > Lukasz Luba (2): > firmware: arm_scmi: Add power_scale_mw_get() interface > cpufreq: arm_scmi: Discover the power scale in performance protocol > > drivers/cpufreq/scmi-cpufreq.c | 4 +++- > drivers/firmware/arm_scmi/perf.c | 8 > include/linux/scmi_protocol.h| 1 + > 3 files changed, 12 insertions(+), 1 deletion(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 0/6] prohibit pinning pages in ZONE_MOVABLE
On Fri, Dec 04, 2020 at 12:50:56PM -0500, Pavel Tatashin wrote: > > > Yes, this indeed could be a problem for some configurations. I will > > > add your comment to the commit log of one of the patches. > > > > It sounds like there is some inherent tension here, breaking THP's > > when doing pin_user_pages() is a really nasty thing to do. DMA > > benefits greatly from THP. > > > > I know nothing about ZONE_MOVABLE, is this auto-setup or an admin > > option? If the result of this patch is standard systems can no longer > > pin > 80% of their memory I have some regression concerns.. > > ZONE_MOVABLE can be configured via kernel parameter, or when memory > nodes are onlined after hot-add; so this is something that admins > configure. ZONE_MOVABLE is designed to gurantee memory hot-plug Just note, the origin of ZONE_MOVABLE is to provide availability of huge page, especially, hugetlb page. AFAIK, not guarantee memory hot-plug. See following commit that introduces the ZONE_MOVABLE. 2a1e274 Create the ZONE_MOVABLE zone > functionality, and not availability of THP, however, I did not know > about the use case where some admins might configure ZONE_MOVABLE to The usecase is lightly mentioned in previous discussion. http://lkml.kernel.org/r/alpine.deb.2.23.453.2011221300100.2830...@chino.kir.corp.google.com Anyway, I agree with your other arguments and this patchset. Thanks.
Re: Re: [PATCH v2] phram: Allow the user to set the erase page size.
On Mon, Dec 7, 2020 at 14:56 AM Guohua Zhong wrote: > >> Permit the user to specify the erase page size as a parameter. >> This solves two problems: > >> - phram can access images made by mkfs.jffs2. mkfs.jffs2 won't >> create images with erase sizes less than 8KiB; many architectures >> define PAGE_SIZE as 4KiB. > >> - Allows more effective use of small capacity devices. JFFS2 >> needs somewhere between 2 and 5 empty pages for garbage collection; >> and for an NVRAM part with only 32KiB of space, a smaller erase page >> allows much better utilization in applications where garbage collection >> is important. > >> Signed-off-by: Patrick O'Grady >> Reviewed-by: Joern Engel >> Link: >> https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/ >> [Guohua Zhong: fix token array index out of bounds and update patch for >> kernel master branch] >> Signed-off-by: Guohua Zhong >> Reported-by: kernel test robot > > Looks good to me, except the authorship. > If I understand correctly, you took this old patch and resend it. > Please make sure that the "From:"-Line contains the original author. > You can fix this up using git commit --amend --author=. > The git format-patch will create a correct patch. Sorry, I am not clear this rule before. But I found the same issue independently. It looks good after changging the erase size for phram driver. Then when I try to send the patch, I found that Patrick O'Grady has already send a patch which has not been merged as the link below https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/ So I resend a patch with some change and fix for mainline kernel with the old patch link of Patrick O'Grady. If I need to change the authorship, I will resend this patch for V3 with authorship of Patrick O'Grady. -- Thanks, //guohua
Re: [f2fs-dev] [PATCH v3] f2fs: fix race of pending_pages in decompression
On 2020/12/5 12:26, Daeho Jeong wrote: From: Daeho Jeong I found out f2fs_free_dic() is invoked in a wrong timing, but f2fs_verify_bio() still needed the dic info and it triggered the below kernel panic. It has been caused by the race condition of pending_pages value between decompression and verity logic, when the same compression cluster had been split in different bios. By split bios, f2fs_verify_bio() ended up with decreasing pending_pages value before it is reset to nr_cpages by f2fs_decompress_pages() and caused the kernel panic. [ 4416.564763] Unable to handle kernel NULL pointer dereference at virtual address ... [ 4416.896016] Workqueue: fsverity_read_queue f2fs_verity_work [ 4416.908515] pc : fsverity_verify_page+0x20/0x78 [ 4416.913721] lr : f2fs_verify_bio+0x11c/0x29c [ 4416.913722] sp : ffc019533cd0 [ 4416.913723] x29: ffc019533cd0 x28: 0402 [ 4416.913724] x27: 0001 x26: 0100 [ 4416.913726] x25: 0001 x24: 0004 [ 4416.913727] x23: 1000 x22: [ 4416.913728] x21: x20: 2076f9c0 [ 4416.913729] x19: 2076f9c0 x18: ff8a32380c30 [ 4416.913731] x17: ffc01f966d97 x16: 0298 [ 4416.913732] x15: x14: [ 4416.913733] x13: f074faec89ff x12: [ 4416.913734] x11: 1000 x10: 1000 [ 4416.929176] x9 : 20d1f5c7 x8 : [ 4416.929178] x7 : 626d7464ff286b6b x6 : ffc019533ade [ 4416.929179] x5 : 8049000e x4 : 2793e9e0 [ 4416.929180] x3 : 8049000e x2 : ff89ecfa74d0 [ 4416.929181] x1 : 0c40 x0 : 2076f9c0 [ 4416.929184] Call trace: [ 4416.929187] fsverity_verify_page+0x20/0x78 [ 4416.929189] f2fs_verify_bio+0x11c/0x29c [ 4416.929192] f2fs_verity_work+0x58/0x84 [ 4417.050667] process_one_work+0x270/0x47c [ 4417.055354] worker_thread+0x27c/0x4d8 [ 4417.059784] kthread+0x13c/0x320 [ 4417.063693] ret_from_fork+0x10/0x18 Is race condition as below? Thread Af2fs_post_read_wq fsverity_wq - f2fs_read_multi_pages() - f2fs_alloc_dic - dic->pending_pages = 2 - submit_bio() - submit_bio() - f2fs_post_read_work() handle first bio - f2fs_decompress_work() - __read_end_io() - f2fs_decompress_pages() - dic->pending_pages-- - enqueue f2fs_verity_work() - f2fs_verity_work() handle first bio - f2fs_verify_bio() - dic->pending_pages-- - f2fs_post_read_work() handle second bio - f2fs_decompress_work() - enqueue f2fs_verity_work() - f2fs_verify_pages() - f2fs_free_dic() - f2fs_verity_work() handle second bio - f2fs_verfy_bio() - use-after-free on dic If this is correct, could you please add this into commit message? Signed-off-by: Daeho Jeong Signed-off-by: Jaegeuk Kim --- v3: back to v1 and enabled verity in a unit of cluster v2: merged verity_pages with pending_pages, and increased the pending_pages count only if STEP_VERITY is set on bio --- fs/f2fs/compress.c | 2 -- fs/f2fs/data.c | 51 -- fs/f2fs/f2fs.h | 1 + 3 files changed, 41 insertions(+), 13 deletions(-) diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c index 87090da8693d..832b19986caf 100644 --- a/fs/f2fs/compress.c +++ b/fs/f2fs/compress.c @@ -803,8 +803,6 @@ void f2fs_decompress_pages(struct bio *bio, struct page *page, bool verity) if (cops->destroy_decompress_ctx) cops->destroy_decompress_ctx(dic); out_free_dic: - if (verity) - atomic_set(>pending_pages, dic->nr_cpages); if (!verity) f2fs_decompress_end_io(dic->rpages, dic->cluster_size, ret, false); diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 42254d3859c7..861e5783a5fc 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -202,7 +202,7 @@ static void f2fs_verify_bio(struct bio *bio) dic = (struct decompress_io_ctx *)page_private(page);
[PATCH] arm64: dts: imx8mn: Fix duplicate node name
Error log:
sysfs: cannot create duplicate filename '/bus/platform/devices/3000.bus'
The spba bus name is duplicate with aips bus name.
Refine spba bus name to fix this issue.
Fixes: 970406eaef3a ("arm64: dts: imx8mn: Enable Asynchronous Sample Rate
Converter")
Signed-off-by: Shengjiu Wang
---
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index fd669c0f3fe5..30762eb4f0a7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -246,7 +246,7 @@ aips1: bus@3000 {
#size-cells = <1>;
ranges;
- spba: bus@3000 {
+ spba: spba-bus@3000 {
compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.27.0
Re: [PATCH] staging:hantro: Fixed "replace comma with semicolon" Warning:
Hi Travis, On Fri, 2020-12-04 at 17:51 -0600, Travis Carter wrote: > Corrected the following Warning: > drivers/staging/media/hantro/hantro_v4l2.c:319: WARNING: Possible comma where > semicolon could be used > > Signed-off-by: Travis Carter > --- > drivers/staging/media/hantro/hantro_v4l2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/hantro/hantro_v4l2.c > b/drivers/staging/media/hantro/hantro_v4l2.c > index b668a82d40ad..e1081c16f56a 100644 > --- a/drivers/staging/media/hantro/hantro_v4l2.c > +++ b/drivers/staging/media/hantro/hantro_v4l2.c > @@ -316,7 +316,7 @@ hantro_reset_fmt(struct v4l2_pix_format_mplane *fmt, > > fmt->pixelformat = vpu_fmt->fourcc; > fmt->field = V4L2_FIELD_NONE; > - fmt->colorspace = V4L2_COLORSPACE_JPEG, > + fmt->colorspace = V4L2_COLORSPACE_JPEG; > fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; > fmt->quantization = V4L2_QUANTIZATION_DEFAULT; > fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT; Thank you, Reviewed-by: Philipp Zabel regards Philipp
Re: [PATCH] kasan: fix slab double free when cpu-hotplug
On Mon, 2020-12-07 at 10:06 +0800, Kuan-Ying Lee wrote:
> On Sat, 2020-12-05 at 17:09 -0800, Andrew Morton wrote:
> > On Sun, 6 Dec 2020 00:17:15 +0800 Kuan-Ying Lee
> > wrote:
> >
> > > On Fri, 2020-12-04 at 17:25 -0800, Andrew Morton wrote:
> > > > On Fri, 4 Dec 2020 20:01:35 +0800 Kuan-Ying Lee
> > > > wrote:
> > > >
> > > > > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > > > > > index d98b516f372f..55783125a767 100644
> > > > > > --- a/mm/kasan/quarantine.c
> > > > > > +++ b/mm/kasan/quarantine.c
> > > > > > @@ -194,7 +194,6 @@ bool quarantine_put(struct kmem_cache *cache,
> > > > > > void *object)
> > > > > >
> > > > > > q = this_cpu_ptr(_quarantine);
> > > > > > if (q->offline) {
> > > > > > - qlink_free(>quarantine_link, cache);
> > > > > > local_irq_restore(flags);
> > > > > > return false;
> > >
> > > Hi Andrew,
> > >
> > > Return false will cause slab allocator to free the object.
> > > Thus, we do not need to qlink_free here to free object twice.
> > >
> > > The return value is introduced from Andrey's patch.
> > > "kasan: sanitize objects when metadata doesn't fit"
> > >
> > >
> > > > > > }
> > > > >
> > > > > Hi Qiang,
> > > > >
> > > > > Thanks for fixing this.
> > > > > Due to that issue, my commit has been removed by Stephen from
> > > > > linux-next.
> > > > >
> > > > >
> > > > > Hi Stephen, Andrew,
> > > > >
> > > > > Should I directly upload the v4 or Stephen can pick the commit which
> > > > > has been removed back to the linux-next.
> > > >
> > > > I took care of it. Restored the original patch and added this one as a
> > > > -fix.
> > >
> > > Thanks for taking care of it.
> > >
> > > I think there are some problem in the patch you just restored.
> > > I saw the restored patch is not based on Andrey's patch and Stephen's
> > > fix conflict patch.
> > >
> > > But the issue Qiang fixed need to be based on the Andrey's patch and
> > > Stephen's fix conflict patch.
> > > "kasan: sanitize objects when metadata doesn't fit"
> > > "kasan-rename-get_alloc-free_info-fix"
> > >
> > > If the restored patch is not based on that, it may cause some problems
> > > and conflicts.
> > >
> > > I think I can prepare a patch v4 based on Andrey's patch, fix the
> > > conflict and include the Qiang's modification.
> >
> > I'm not sure what you mean here. When appying this fix, yes, I had to
> > replace "meta" with "info", of course.
> >
> > So the combined patch, which I'd like to send to Linus next week is as
> > below. Is there something wrong with it?
> >
>
> Is this combined patch based on Andrey's patch?
>
> If yes, Andrey's patch not only change the "info" to "meta" but also
> introduce the return value.
> I think we need to add return value or it will build error.
>
Hi Andrew,
Sorry to bother.
Thanks for fixing my patch.
But it still has some problem.
I know you are busy. I can fix that by myself.
I will upload the patch v4 to fix the conflicts and build errors and
include the Qiang's patch.
Thanks.
Kuan-Ying
> >
> > From: Kuan-Ying Lee
> > Subject: kasan: fix object remaining in offline per-cpu quarantine
> >
> > We hit this issue in our internal test. When enabling generic kasan, a
> > kfree()'d object is put into per-cpu quarantine first. If the cpu goes
> > offline, object still remains in the per-cpu quarantine. If we call
> > kmem_cache_destroy() now, slub will report "Objects remaining" error.
> >
> > [ 74.982625]
> > =
> > [ 74.983380] BUG test_module_slab (Not tainted): Objects remaining in
> > test_module_slab on __kmem_cache_shutdown()
> > [ 74.984145]
> > -
> > [ 74.984145]
> > [ 74.984883] Disabling lock debugging due to kernel taint
> > [ 74.985561] INFO: Slab 0x(ptrval) objects=34 used=1
> > fp=0x(ptrval) flags=0x20010200
> > [ 74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB
> > 5.10.0-rc1-7-g4525c8781ec0-dirty #10
> > [ 74.987262] Hardware name: linux,dummy-virt (DT)
> > [ 74.987606] Call trace:
> > [ 74.987924] dump_backtrace+0x0/0x2b0
> > [ 74.988296] show_stack+0x18/0x68
> > [ 74.988698] dump_stack+0xfc/0x168
> > [ 74.989030] slab_err+0xac/0xd4
> > [ 74.989346] __kmem_cache_shutdown+0x1e4/0x3c8
> > [ 74.989779] kmem_cache_destroy+0x68/0x130
> > [ 74.990176] test_version_show+0x84/0xf0
> > [ 74.990679] module_attr_show+0x40/0x60
> > [ 74.991218] sysfs_kf_seq_show+0x128/0x1c0
> > [ 74.991656] kernfs_seq_show+0xa0/0xb8
> > [ 74.992059] seq_read+0x1f0/0x7e8
> > [ 74.992415] kernfs_fop_read+0x70/0x338
> > [ 74.993051] vfs_read+0xe4/0x250
> > [ 74.993498] ksys_read+0xc8/0x180
> > [ 74.993825] __arm64_sys_read+0x44/0x58
> > [ 74.994203] el0_svc_common.constprop.0+0xac/0x228
> > [ 74.994708]
Re: [PATCH v2 1/3] scsi: ufs: Add "wb_on" sysfs node to control WB on/off
On Sun, 2020-12-06 at 11:13 +0100, Bean Huo wrote:
> From: Bean Huo
>
> Currently UFS WriteBooster driver uses clock scaling up/down to set
> WB on/off, for the platform which doesn't support UFSHCD_CAP_CLK_SCALING,
> WB will be always on. Provide a sysfs attribute to enable/disable WB
> during runtime. Write 1/0 to "wb_on" sysfs node to enable/disable UFS WB.
>
> Signed-off-by: Bean Huo
> ---
> drivers/scsi/ufs/ufs-sysfs.c | 40
> drivers/scsi/ufs/ufshcd.c| 3 +--
> drivers/scsi/ufs/ufshcd.h| 2 ++
> 3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
> index 08e72b7eef6a..b3bf7fca00e5 100644
> --- a/drivers/scsi/ufs/ufs-sysfs.c
> +++ b/drivers/scsi/ufs/ufs-sysfs.c
> @@ -189,6 +189,44 @@ static ssize_t auto_hibern8_store(struct device *dev,
> return count;
> }
>
> +static ssize_t wb_on_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> + return scnprintf(buf, PAGE_SIZE, "%d\n", hba->wb_enabled);
> +}
> +
> +static ssize_t wb_on_store(struct device *dev, struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + struct ufs_hba *hba = dev_get_drvdata(dev);
> + unsigned int wb_enable;
> + ssize_t res;
> +
> + if (ufshcd_is_clkscaling_supported(hba)) {
> + /* If the platform supports UFSHCD_CAP_AUTO_BKOPS_SUSPEND, turn
> + * WB on/off will be done while clock scaling up/down.
> + */
> + dev_warn(dev, "To control WB through wb_on is not allowed!\n");
> + return -EOPNOTSUPP;
> + }
Perhaps wb_on shall override clkscaling control. But this could be
future work.
Reviewed-by: Stanley Chu
> + if (!ufshcd_is_wb_allowed(hba))
> + return -EOPNOTSUPP;
> +
> + if (kstrtouint(buf, 0, _enable))
> + return -EINVAL;
> +
> + if (wb_enable != 0 && wb_enable != 1)
> + return -EINVAL;
> +
> + pm_runtime_get_sync(hba->dev);
> + res = ufshcd_wb_ctrl(hba, wb_enable);
> + pm_runtime_put_sync(hba->dev);
> +
> + return res < 0 ? res : count;
> +}
> +
> static DEVICE_ATTR_RW(rpm_lvl);
> static DEVICE_ATTR_RO(rpm_target_dev_state);
> static DEVICE_ATTR_RO(rpm_target_link_state);
> @@ -196,6 +234,7 @@ static DEVICE_ATTR_RW(spm_lvl);
> static DEVICE_ATTR_RO(spm_target_dev_state);
> static DEVICE_ATTR_RO(spm_target_link_state);
> static DEVICE_ATTR_RW(auto_hibern8);
> +static DEVICE_ATTR_RW(wb_on);
>
> static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
> _attr_rpm_lvl.attr,
> @@ -205,6 +244,7 @@ static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
> _attr_spm_target_dev_state.attr,
> _attr_spm_target_link_state.attr,
> _attr_auto_hibern8.attr,
> + _attr_wb_on.attr,
> NULL
> };
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 92d433d5f3ca..30332592e624 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -247,7 +247,6 @@ static inline int ufshcd_config_vreg_hpm(struct ufs_hba
> *hba,
> static int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag);
> static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
> static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
> -static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
> static int ufshcd_wb_toggle_flush_during_h8(struct ufs_hba *hba, bool set);
> static inline void ufshcd_wb_toggle_flush(struct ufs_hba *hba, bool enable);
> static void ufshcd_hba_vreg_set_lpm(struct ufs_hba *hba);
> @@ -5307,7 +5306,7 @@ static void ufshcd_bkops_exception_event_handler(struct
> ufs_hba *hba)
> __func__, err);
> }
>
> -static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
> +int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
> {
> int ret;
> u8 index;
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 61344c49c2cc..c61584dff74a 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -1068,6 +1068,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
>u8 *desc_buff, int *buff_len,
>enum query_opcode desc_op);
>
> +int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
> +
> /* Wrapper functions for safely calling variant operations */
> static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
> {
RE: [PATCH v2 1/3] scsi: ufs: Add "wb_on" sysfs node to control WB on/off
> > From: Bean Huo > > Currently UFS WriteBooster driver uses clock scaling up/down to set > WB on/off, for the platform which doesn't support > UFSHCD_CAP_CLK_SCALING, > WB will be always on. Provide a sysfs attribute to enable/disable WB > during runtime. Write 1/0 to "wb_on" sysfs node to enable/disable UFS WB. > > Signed-off-by: Bean Huo Reviewed-by: Avri Altman
Re: [PATCH 03/17] drivers/gpu: Convert to mem*_page()
On Fri, Dec 04, 2020 at 11:33:08PM +0100, Thomas Gleixner wrote: > On Fri, Dec 04 2020 at 08:05, Ira Weiny wrote: > > So I think I'm going to submit the base patch to Andrew today (with some > > cleanups per the comments in this thread). > > Could you please base that on tip core/mm where the kmap_local() muck is > and use kmap_local() right away? Sure. Would that mean it should go through you and not Andrew? Ira > > Thanks, > > tglx
[PATCH v2 2/3] f2fs-tools:sload.f2fs compression support
From: Robin Hsu
Add F2FS compression support for sload
* Support file extension filter, either default-accept or default-deny
policy
* Support choice of compression algorithm, LZO (version 2) or LZ4
(default)
* Support custom log of cluster size
* Support minimum number of compressed blocks per cluster (default 1).
A cluster will not be compressed if the number can not be met.
* suuport -r (read-only) option
Bug: 161486536
Test: Tested on Android & Ubuntu PC
Signed-off-by: Robin Hsu
Change-Id: I67f1a40df92a31b7c3d4383c49839359cc534b56
---
fsck/compress_wrapper.c | 102
fsck/compress_wrapper.h | 22 +
fsck/fsck.h | 15 +++
fsck/main.c | 141 +++-
fsck/segment.c | 202 +---
fsck/sload.c| 67 +
include/f2fs_fs.h | 76 ++-
lib/libf2fs_io.c| 33 +++
8 files changed, 644 insertions(+), 14 deletions(-)
create mode 100644 fsck/compress_wrapper.c
create mode 100644 fsck/compress_wrapper.h
diff --git a/fsck/compress_wrapper.c b/fsck/compress_wrapper.c
new file mode 100644
index 000..2cdc4fd
--- /dev/null
+++ b/fsck/compress_wrapper.c
@@ -0,0 +1,102 @@
+/**
+ * compress_wrapper.c
+ *
+ * Copyright (c) 2020 Google Inc.
+ * Robin Hsu
+ * : initial created, for sload compression support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include "f2fs.h" /* for config.h for general environment (non-Android) */
+
+#include "compress_wrapper.h"
+#ifdef HAVE_LIBLZO2
+#include /* for lzo1x_1_15_compress() */
+#endif
+#ifdef HAVE_LIBLZ4
+#include /* for LZ4_compress_fast_extState() */
+#endif
+
+/*
+ * macro/constants borrowed from kernel header (GPL-2.0):
+ * include/linux/lzo.h, and include/linux/lz4.h
+ */
+#ifdef HAVE_LIBLZO2
+#define lzo1x_worst_compress(x)((x) + (x) / 16 + 64 + 3 + 2)
+#define LZO_WORK_SIZE ALIGN_UP(LZO1X_1_15_MEM_COMPRESS, 8)
+#endif
+#ifdef HAVE_LIBLZ4
+#define LZ4_MEMORY_USAGE 14
+#define LZ4_MAX_INPUT_SIZE 0x7E00 /* 2 113 929 216 bytes */
+#define LZ4_STREAMSIZE (LZ4_STREAMSIZE_U64 * sizeof(long long))
+#define LZ4_MEM_COMPRESS LZ4_STREAMSIZE
+#define LZ4_ACCELERATION_DEFAULT 1
+#define LZ4_WORK_SIZE ALIGN_UP(LZ4_MEM_COMPRESS, 8)
+#endif
+
+#ifdef HAVE_LIBLZO2
+static void lzo_compress_init(struct compress_ctx *cc)
+{
+ size_t size = cc->cluster_size * F2FS_BLKSIZE;
+ size_t alloc = size + lzo1x_worst_compress(size)
+ + COMPRESS_HEADER_SIZE + LZO_WORK_SIZE;
+ ASSERT((cc->private = qbuf_alloc(alloc)) != NULL);
+ cc->rbuf = (char *) cc->private + LZO_WORK_SIZE;
+ cc->cbuf = (struct compress_data *)((char *) cc->rbuf + size);
+}
+
+static int lzo_compress(struct compress_ctx *cc)
+{
+ int ret = lzo1x_1_15_compress(cc->rbuf, cc->rlen, cc->cbuf->cdata,
+ (lzo_uintp)(>clen), cc->private);
+ cc->cbuf->clen = cpu_to_le32(cc->clen);
+ return ret;
+}
+#endif
+
+#ifdef HAVE_LIBLZ4
+static void lz4_compress_init(struct compress_ctx *cc)
+{
+ size_t size = cc->cluster_size * F2FS_BLKSIZE;
+ size_t alloc = size + LZ4_COMPRESSBOUND(size)
+ + COMPRESS_HEADER_SIZE + LZ4_WORK_SIZE;
+ ASSERT((cc->private = qbuf_alloc(alloc)) != NULL);
+ cc->rbuf = (char *) cc->private + LZ4_WORK_SIZE;
+ cc->cbuf = (struct compress_data *)((char *) cc->rbuf + size);
+}
+
+static int lz4_compress(struct compress_ctx *cc)
+{
+ cc->clen = LZ4_compress_fast_extState(cc->private, cc->rbuf,
+ (char *)cc->cbuf->cdata, cc->rlen,
+ cc->rlen - F2FS_BLKSIZE * c.sldc_min_cbpc,
+ LZ4_ACCELERATION_DEFAULT);
+
+ if (!cc->clen)
+ return 1;
+
+ cc->cbuf->clen = cpu_to_le32(cc->clen);
+ return 0;
+}
+#endif
+
+const char *ca_names[] = {
+ "LZO",
+ "LZ4",
+ "", /* end of the name list */
+};
+
+compress_ops compr_ops[] = {
+#ifdef HAVE_LIBLZO2
+ {lzo_compress_init, lzo_compress},
+#else
+ {NULL, NULL},
+#endif
+#ifdef HAVE_LIBLZ4
+ {lz4_compress_init, lz4_compress},
+#else
+ {NULL, NULL},
+#endif
+};
diff --git a/fsck/compress_wrapper.h b/fsck/compress_wrapper.h
new file mode 100644
index 000..ec33d43
--- /dev/null
+++ b/fsck/compress_wrapper.h
@@ -0,0 +1,22 @@
+/**
+ * compress_wrapper.h
+ *
+ * Copyright (c) 2020 Google Inc.
+ * Robin Hsu
+ * : initial created, for sload compression support
+ * Copyright (c) 2020 Google Inc.
+ * Robin Hsu
+ * : add sload compression support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General
[PATCH] acer-wireless: send an EV_SYN/SYN_REPORT between state changes
From: Daniel Drake
Sending the switch state change twice within the same frame is invalid
evdev protocol and only works if the client handles keys immediately as
well. Processing events immediately is incorrect, it forces a fake
order of events that does not exist on the device.
Recent versions of libinput changed to only process the device state and
SYN_REPORT time, so now the key event is lost.
Same fix as 'commit ("platform/x86: asus-wireless: send
an EV_SYN/SYN_REPORT between state changes")'
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
drivers/platform/x86/acer-wireless.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/acer-wireless.c
b/drivers/platform/x86/acer-wireless.c
index e0976180532a..1b5d935d085a 100644
--- a/drivers/platform/x86/acer-wireless.c
+++ b/drivers/platform/x86/acer-wireless.c
@@ -28,6 +28,7 @@ static void acer_wireless_notify(struct acpi_device *adev,
u32 event)
return;
}
input_report_key(idev, KEY_RFKILL, 1);
+ input_sync(idev);
input_report_key(idev, KEY_RFKILL, 0);
input_sync(idev);
}
--
2.20.1
[PATCH v2 3/3] f2fs-tools:sload.f2fs compress: Fixed automake
From: Robin Hsu
Fixed automake for sload.f2fs compression support
./configure now will by default depends on liblzo2 and liblz4.
To compile without liblzo2 (and thus not support liblzo2 compression),
run ./configure with '--without-lzo2' option.
To compile without liblz4 (and thus not support liblz4 compression),
run ./configure with '--without-lz4' option.
Test: Build with automake OK on glinux
Bug: 170918502
Signed-off-by: Robin Hsu
Change-Id: I25d339e4cab4ca196781da89fc3df3e13f869234
---
configure.ac | 32
fsck/Makefile.am | 9 ++---
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1e5619d..3a357b2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,6 +44,14 @@ AC_ARG_WITH([blkid],
AS_HELP_STRING([--without-blkid],
[Ignore presence of libblkid and disable blkid support]))
+AC_ARG_WITH([lzo2],
+ AS_HELP_STRING([--without-lzo2],
+ [Ignore liblzo ver.2 for sload (not supporting lzo compression)]))
+
+AC_ARG_WITH([lz4],
+ AS_HELP_STRING([--without-lz4],
+ [Ignore liblz4 for sload (not supporting lz4 compression)]))
+
# Checks for programs.
AC_PROG_CC
AC_PROG_LIBTOOL
@@ -52,6 +60,30 @@ AC_PATH_PROG([LDCONFIG], [ldconfig],
[$PATH:/sbin])
# Checks for libraries.
+AS_IF([test "x$with_lzo2" != xno],
+[AC_CHECK_LIB([lzo2], [main],
+ [AC_SUBST([liblzo2_LIBS], ["-llzo2"])
+ AC_DEFINE([HAVE_LIBLZO2], [1],
+ [Define if you have liblzo2])
+ ],
+ [if test "x$with_lzo2" != xcheck; then
+ AC_MSG_FAILURE(
+ [--with-lzo2 was given (or by default), but test for
liblzo2 failed])
+ fi
+ ], [])])
+
+AS_IF([test "x$with_lz4" != xno],
+[AC_CHECK_LIB([lz4], [main],
+ [AC_SUBST([liblz4_LIBS], ["-llz4"])
+ AC_DEFINE([HAVE_LIBLZ4], [1],
+ [Define if you have liblz4])
+ ],
+ [if test "x$with_lz4" != xcheck; then
+ AC_MSG_FAILURE(
+ [--with-lz4 was given (or by default), but test for liblz4
failed])
+ fi
+ ], [])])
+
PKG_CHECK_MODULES([libuuid], [uuid])
AS_IF([test "x$with_selinux" != "xno"],
diff --git a/fsck/Makefile.am b/fsck/Makefile.am
index 1fc7310..74bc4b8 100644
--- a/fsck/Makefile.am
+++ b/fsck/Makefile.am
@@ -3,12 +3,15 @@
AM_CPPFLAGS = ${libuuid_CFLAGS} -I$(top_srcdir)/include
AM_CFLAGS = -Wall
sbin_PROGRAMS = fsck.f2fs
-noinst_HEADERS = common.h dict.h dqblk_v2.h f2fs.h fsck.h node.h quotaio.h
quotaio_tree.h quotaio_v2.h xattr.h
+noinst_HEADERS = common.h dict.h dqblk_v2.h f2fs.h fsck.h node.h quotaio.h \
+ quotaio_tree.h quotaio_v2.h xattr.h compress_wrapper.h
include_HEADERS = $(top_srcdir)/include/quota.h
fsck_f2fs_SOURCES = main.c fsck.c dump.c mount.c defrag.c resize.c \
- node.c segment.c dir.c sload.c xattr.c \
+ node.c segment.c dir.c sload.c xattr.c compress_wrapper.c \
dict.c mkquota.c quotaio.c quotaio_tree.c quotaio_v2.c
-fsck_f2fs_LDADD = ${libselinux_LIBS} ${libuuid_LIBS}
$(top_builddir)/lib/libf2fs.la
+fsck_f2fs_LDADD = ${libselinux_LIBS} ${libuuid_LIBS} \
+ ${liblzo2_LIBS} ${liblz4_LIBS} \
+ $(top_builddir)/lib/libf2fs.la
install-data-hook:
ln -sf fsck.f2fs $(DESTDIR)/$(sbindir)/dump.f2fs
--
2.29.2.576.ga3fc446d84-goog
[PATCH v2 1/3] f2fs-tools: Added #ifdef WITH_func
From: Robin Hsu
Add proprocessor defines (options) 'WITH_func',
where func = DUMP, DEFRAG, RESIZE, or SLOAD
Bug: 161486536
Test: n/a (trivial)
Signed-off-by: Robin Hsu
Change-Id: I813755548cc71dd8b026abd06893ed0fcf1d8b26
---
fsck/main.c | 16
1 file changed, 16 insertions(+)
diff --git a/fsck/main.c b/fsck/main.c
index e70048b..b20498f 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -345,6 +345,7 @@ void f2fs_parse_options(int argc, char *argv[])
break;
}
} else if (!strcmp("dump.f2fs", prog)) {
+#ifdef WITH_DUMP
const char *option_string = "d:i:n:s:Sa:b:V";
static struct dump_option dump_opt = {
.nid = 0, /* default root ino */
@@ -426,7 +427,9 @@ void f2fs_parse_options(int argc, char *argv[])
}
c.private = _opt;
+#endif
} else if (!strcmp("defrag.f2fs", prog)) {
+#ifdef WITH_DEFRAG
const char *option_string = "d:s:Sl:t:iV";
c.func = DEFRAG;
@@ -484,7 +487,9 @@ void f2fs_parse_options(int argc, char *argv[])
if (err != NOERROR)
break;
}
+#endif
} else if (!strcmp("resize.f2fs", prog)) {
+#ifdef WITH_RESIZE
const char *option_string = "d:st:iV";
c.func = RESIZE;
@@ -526,7 +531,9 @@ void f2fs_parse_options(int argc, char *argv[])
if (err != NOERROR)
break;
}
+#endif
} else if (!strcmp("sload.f2fs", prog)) {
+#ifdef WITH_SLOAD
const char *option_string = "C:d:f:p:s:St:T:V";
#ifdef HAVE_LIBSELINUX
int max_nr_opt = (int)sizeof(c.seopt_file) /
@@ -595,6 +602,7 @@ void f2fs_parse_options(int argc, char *argv[])
if (err != NOERROR)
break;
}
+#endif /* WITH_SLOAD */
}
if (err == NOERROR) {
@@ -707,6 +715,7 @@ static int do_fsck(struct f2fs_sb_info *sbi)
return FSCK_ERRORS_LEFT_UNCORRECTED;
}
+#ifdef WITH_DUMP
static void do_dump(struct f2fs_sb_info *sbi)
{
struct dump_option *opt = (struct dump_option *)c.private;
@@ -733,7 +742,9 @@ static void do_dump(struct f2fs_sb_info *sbi)
print_cp_state(flag);
}
+#endif
+#ifdef WITH_DEFRAG
static int do_defrag(struct f2fs_sb_info *sbi)
{
struct f2fs_super_block *sb = F2FS_RAW_SUPER(sbi);
@@ -782,7 +793,9 @@ out_range:
c.defrag_target);
return -1;
}
+#endif
+#ifdef WITH_RESIZE
static int do_resize(struct f2fs_sb_info *sbi)
{
if (!c.target_sectors)
@@ -796,7 +809,9 @@ static int do_resize(struct f2fs_sb_info *sbi)
return f2fs_resize(sbi);
}
+#endif
+#ifdef WITH_SLOAD
static int do_sload(struct f2fs_sb_info *sbi)
{
if (!c.from_dir) {
@@ -808,6 +823,7 @@ static int do_sload(struct f2fs_sb_info *sbi)
return f2fs_sload(sbi);
}
+#endif
#if defined(__APPLE__)
static u64 get_boottime_ns()
--
2.29.2.576.ga3fc446d84-goog
[PATCH v2 0/3] f2fs-tools: sload compression support
From: Robin Hsu * 3 patch set: #1: added some #ifdef for easier support #2: main code change #3: automake changes v2 fix (from v1): fixed a bug and a more elegant error handling flow. Robin Hsu (3): f2fs-tools: Added #ifdef WITH_func f2fs-tools:sload.f2fs compression support f2fs-tools:sload.f2fs compress: Fixed automake configure.ac| 32 +++ fsck/Makefile.am| 9 +- fsck/compress_wrapper.c | 102 fsck/compress_wrapper.h | 22 + fsck/fsck.h | 15 +++ fsck/main.c | 157 ++- fsck/segment.c | 202 +--- fsck/sload.c| 67 + include/f2fs_fs.h | 76 ++- lib/libf2fs_io.c| 33 +++ 10 files changed, 698 insertions(+), 17 deletions(-) create mode 100644 fsck/compress_wrapper.c create mode 100644 fsck/compress_wrapper.h -- 2.29.2.576.ga3fc446d84-goog
Re: [PATCH v9 2/3] Input: Add Novatek NT36xxx touchscreen driver
Hi AngeloGioacchino,
On Wed, Oct 28, 2020 at 11:13:01PM +0100, khol...@gmail.com wrote:
> +/**
> + * nt36xxx_set_page - Set page number for read/write
> + * @ts: Main driver structure
> + *
> + * Return: Always zero for success, negative number for error
> + */
> +static int nt36xxx_set_page(struct nt36xxx_i2c *ts, u32 pageaddr)
> +{
> + u32 data = cpu_to_be32(pageaddr) >> 8;
> + int ret;
> +
> + ret = regmap_noinc_write(ts->fw_regmap, NT36XXX_CMD_SET_PAGE,
> + , sizeof(data));
> + if (ret)
> + return ret;
> +
> + usleep_range(100, 200);
> + return ret;
> +}
Regmap is supposed to handle paged access for you as long as you set it
up for paged access. Why do you need custom page handling here?
Thanks.
--
Dmitry
Re: [PATCH v2 1/2] Input: i8042 - Prevent intermixing i8042 commands
Hi Raul,
On Thu, Aug 27, 2020 at 02:41:53PM -0600, Raul E Rangel wrote:
> The i8042_mutex must be held by writers of the AUX and KBD ports, as
> well as users of i8042_command. There were a lot of users of
> i8042_command that were not calling i8042_lock_chip/i8042_unlock_chip.
> This resulted in i8042_commands being issues in between PS/2
> transactions.
>
> This change moves the mutex lock into i8042_command and removes the
> burden of locking the mutex from the callers.
I think there is a benefit for allowing users issue a sequence of
commands to i8042 without interruptions, so I would prefer keeping
i8042_[un]lock_chip() in place.
Given that the issue you were observing was caused by i8042_port_close()
interfering with probing, maybe we could do something like this:
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index abae23af0791..aff871001eda 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -344,6 +344,8 @@ int i8042_command(unsigned char *param, int command)
unsigned long flags;
int retval;
+ lockdep_assert_held(_mutex);
+
if (!i8042_present)
return -1;
@@ -364,6 +366,8 @@ static int i8042_kbd_write(struct serio *port, unsigned
char c)
unsigned long flags;
int retval = 0;
+ lockdep_assert_held(_mutex);
+
spin_lock_irqsave(_lock, flags);
if (!(retval = i8042_wait_write())) {
@@ -411,6 +415,8 @@ static void i8042_port_close(struct serio *serio)
port_name = "KBD";
}
+ i8042_lock_chip();
+
i8042_ctr &= ~irq_bit;
if (i8042_command(_ctr, I8042_CMD_CTL_WCTR))
pr_warn("Can't write CTR while closing %s port\n", port_name);
@@ -422,6 +428,8 @@ static void i8042_port_close(struct serio *serio)
if (i8042_command(_ctr, I8042_CMD_CTL_WCTR))
pr_err("Can't reactivate %s port\n", port_name);
+ i8042_unlock_chip();
+
/*
* See if there is any data appeared while we were messing with
* port state.
Thanks.
--
Dmitry
[PATCH] dmaengine: bam_dma: fix return of bam_dma_irq()
While performing suspend/resume, we were getting below kernel crash.
[ 54.541672] [FTS][Info]gesture suspend...
[ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed!
[ 54.605256]
[ 58.345850] irq event 10: bogus return value fff3
..
[ 58.345966] [] el1_irq+0xb0/0x124
[ 58.345971] [] arch_cpu_idle+0x10/0x18
[ 58.345975] [] do_idle+0x1ac/0x1e0
[ 58.345979] [] cpu_startup_entry+0x20/0x28
[ 58.345983] [] rest_init+0xd0/0xdc
[ 58.345988] [] start_kernel+0x390/0x3a4
[ 58.345990] handlers:
[ 58.345994] [] bam_dma_irq
The reason for the crash we found is, bam_dma_irq() was returning
negative value when the device resumes in some conditions.
In addition, the irq handler should have one of the below return values.
IRQ_NONEinterrupt was not from this device or was not handled
IRQ_HANDLED interrupt was handled by this device
IRQ_WAKE_THREAD handler requests to wake the handler thread
Therefore, to resolve this crash, we have changed the return value to
IRQ_NONE.
Signed-off-by: Parth Y Shah
---
drivers/dma/qcom/bam_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 4eeb8bb..d5773d4 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -875,7 +875,7 @@ static irqreturn_t bam_dma_irq(int irq, void *data)
ret = bam_pm_runtime_get_sync(bdev->dev);
if (ret < 0)
- return ret;
+ return IRQ_NONE;
if (srcs & BAM_IRQ) {
clr_mask = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_STTS));
--
2.7.4
[PATCH v2 2/2] pinctrl: qcom: Add SM8350 pinctrl driver
From: Raghavendra Rao Ananta
This adds pincontrol driver for tlmm block found in SM8350 SoC
Signed-off-by: Raghavendra Rao Ananta
Signed-off-by: Jeevan Shriram
[vkoul: rebase and tidy up for upstream]
Signed-off-by: Vinod Koul
---
drivers/pinctrl/qcom/Kconfig |8 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-sm8350.c | 1650 +
3 files changed, 1659 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8350.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 5fe7b8aaf69d..fd681eaf8601 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -236,4 +236,12 @@ config PINCTRL_SM8250
Qualcomm Technologies Inc TLMM block found on the Qualcomm
Technologies Inc SM8250 platform.
+config PINCTRL_SM8350
+ tristate "Qualcomm Technologies Inc SM8350 pin controller driver"
+ depends on GPIOLIB && OF && PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc TLMM block found on the Qualcomm
+ Technologies Inc SM8350 platform.
+
endif
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 9e3d9c91a444..fb71be6796ed 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
obj-$(CONFIG_PINCTRL_SM8150) += pinctrl-sm8150.o
obj-$(CONFIG_PINCTRL_SM8250) += pinctrl-sm8250.o
+obj-$(CONFIG_PINCTRL_SM8350) += pinctrl-sm8350.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sm8350.c
b/drivers/pinctrl/qcom/pinctrl-sm8350.c
new file mode 100644
index ..9485ec24ad10
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sm8350.c
@@ -0,0 +1,1650 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define REG_SIZE 0x1000
+
+#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = REG_SIZE * id, \
+ .io_reg = REG_SIZE * id + 0x4, \
+ .intr_cfg_reg = REG_SIZE * id + 0x8,\
+ .intr_status_reg = REG_SIZE * id + 0xc, \
+ .intr_target_reg = REG_SIZE * id + 0x8, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 3, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1, \
+ .intr_detection_bit = 2,\
+ .intr_detection_width = 2, \
+ }
+
+#define SDC_PINGROUP(pg_name, ctl, pull, drv) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins = (unsigned int)ARRAY_SIZE(pg_name##_pins), \
+ .ctl_reg = ctl, \
+ .io_reg = 0,\
+ .intr_cfg_reg = 0, \
+
[PATCH v2 1/2] dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
Add device tree binding Documentation details for Qualcomm SM8350
pinctrl driver.
Signed-off-by: Vinod Koul
---
.../bindings/pinctrl/qcom,sm8350-pinctrl.yaml | 151 ++
1 file changed, 151 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
new file mode 100644
index ..8ddb347c43da
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8350 TLMM block
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ SM8350 platform.
+
+properties:
+ compatible:
+const: qcom,sm8350-pinctrl
+
+ reg:
+description: Specifies the base address and size of the TLMM register space
+maxItems: 1
+
+ interrupts:
+description: Specifies the TLMM summary IRQ
+maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+description: Specifies the PIN numbers and Flags, as defined in
+ include/dt-bindings/interrupt-controller/irq.h
+const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+const: 2
+
+ gpio-ranges:
+maxItems: 1
+
+ gpio-reserved-ranges:
+maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+type: object
+description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+$ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+properties:
+ pins:
+description:
+ List of gpio pins affected by the properties specified in this
subnode.
+items:
+ oneOf:
+- pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-3])$"
+- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
sdc2_data ]
+minItems: 1
+maxItems: 36
+
+ function:
+description:
+ Specify the alternative function to be configured for the specified
+ pins. Functions are only valid for gpio pins.
+enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async,
+cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng,
+cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
+gpio, ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync,
mdp_vsync0,
+mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1,
+mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck,
+mi2s1_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws,
+mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12,
+mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6,
+mss_grfc7, mss_grfc8, mss_grfc9, nav_gpio, pa_indicator,
+pcie0_clkreqn, pcie1_clkreqn, phase_flag, pll_bist, pll_clk,
+pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable,
+qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
+qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss, qspi0,
+qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10,
+qup11, qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19,
+qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5,
+qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
+sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2,
+tgu_ch3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data,
+uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_present,
+uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ]
+
+
+ drive-strength:
+enum: [2, 4, 6, 8, 10, 12, 14, 16]
+default: 2
+description:
+ Selects the drive strength for the specified pins, in mA.
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+required:
+ - pins
+ - function
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+tlmm: pinctrl@f00 {
+
Re: [PATCH] cpufreq: scmi: add COMMON_CLK dependency
On 03-12-20, 23:55, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Wtihout CONFIG_COMMON_CLK, the scmi driver fails to link:
>
> arm-linux-gnueabi-ld: drivers/cpufreq/scmi-cpufreq.o: in function
> `scmi_cpufreq_probe':
> scmi-cpufreq.c:(.text+0x20c): undefined reference to
> `devm_of_clk_add_hw_provider'
> arm-linux-gnueabi-ld: scmi-cpufreq.c:(.text+0x22c): undefined reference to
> `of_clk_hw_simple_get'
>
> Add a Kconfig dependency for it.
>
> Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy
> clock provider")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/cpufreq/Kconfig.arm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 1f73fa75b1a0..434ef03d2762 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -264,6 +264,7 @@ config ARM_SA1110_CPUFREQ
> config ARM_SCMI_CPUFREQ
> tristate "SCMI based CPUfreq driver"
> depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
> + depends on COMMON_CLK
> select PM_OPP
> help
> This adds the CPUfreq driver support for ARM platforms using SCMI
This is already fixed by:
commit f943849f7206 ("cpufreq: scmi: Fix build for !CONFIG_COMMON_CLK")
--
viresh
Re: [PATCH] cpufreq: imx: fix NVMEM_IMX_OCOTP dependency
On 03-12-20, 23:53, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> A driver should not 'select' drivers from another subsystem.
> If NVMEM is disabled, this one results in a warning:
>
> WARNING: unmet direct dependencies detected for NVMEM_IMX_OCOTP
> Depends on [n]: NVMEM [=n] && (ARCH_MXC [=y] || COMPILE_TEST [=y]) &&
> HAS_IOMEM [=y]
> Selected by [y]:
> - ARM_IMX6Q_CPUFREQ [=y] && CPU_FREQ [=y] && (ARM || ARM64 [=y]) &&
> ARCH_MXC [=y] && REGULATOR_ANATOP [=y]
>
> Change the 'select' to 'depends on' to prevent it from going wrong,
> and allow compile-testing without that driver, since it is only
> a runtime dependency.
>
> Fixes: 2782ef34ed23 ("cpufreq: imx: Select NVMEM_IMX_OCOTP")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/cpufreq/Kconfig.arm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 0732854d94ec..434ef03d2762 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -94,7 +94,7 @@ config ARM_IMX6Q_CPUFREQ
> tristate "Freescale i.MX6 cpufreq support"
> depends on ARCH_MXC
> depends on REGULATOR_ANATOP
> - select NVMEM_IMX_OCOTP
> + depends on NVMEM_IMX_OCOTP || COMPILE_TEST
> select PM_OPP
> help
> This adds cpufreq driver support for Freescale i.MX6 series SoCs.
Applied. Thanks.
--
viresh
[PATCH 1/3] thermal: mediatek: Relocate driver to mediatek folder
Add Mediatek proprietary folder to upstream more thermal zone and cooler
drivers. Relocate the original thermal controller driver to it and rename
as soc_temp.c to show its purpose more clearly.
Signed-off-by: Michael Kao
---
drivers/thermal/Kconfig | 14 ---
drivers/thermal/Makefile | 2 +-
drivers/thermal/mediatek/Kconfig | 23 +++
drivers/thermal/mediatek/Makefile | 1 +
.../{mtk_thermal.c => mediatek/soc_temp.c}| 0
5 files changed, 29 insertions(+), 11 deletions(-)
create mode 100644 drivers/thermal/mediatek/Kconfig
create mode 100644 drivers/thermal/mediatek/Makefile
rename drivers/thermal/{mtk_thermal.c => mediatek/soc_temp.c} (100%)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 7edc8dc6bbab..b2da0a1bda34 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -401,16 +401,10 @@ config DA9062_THERMAL
zone.
Compatible with the DA9062 and DA9061 PMICs.
-config MTK_THERMAL
- tristate "Temperature sensor driver for mediatek SoCs"
- depends on ARCH_MEDIATEK || COMPILE_TEST
- depends on HAS_IOMEM
- depends on NVMEM || NVMEM=n
- depends on RESET_CONTROLLER
- default y
- help
- Enable this option if you want to have support for thermal management
- controller present in Mediatek SoCs
+menu "Mediatek thermal drivers"
+depends on ARCH_MEDIATEK || COMPILE_TEST
+source "drivers/thermal/mediatek/Kconfig"
+endmenu
config AMLOGIC_THERMAL
tristate "Amlogic Thermal Support"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index b64dd50a6629..f9e07c3f529e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -55,7 +55,7 @@ obj-y += st/
obj-$(CONFIG_QCOM_TSENS) += qcom/
obj-y += tegra/
obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
-obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
+obj-$(CONFIG_MTK_THERMAL) += mediatek/
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
diff --git a/drivers/thermal/mediatek/Kconfig b/drivers/thermal/mediatek/Kconfig
new file mode 100644
index ..0351e73170b7
--- /dev/null
+++ b/drivers/thermal/mediatek/Kconfig
@@ -0,0 +1,23 @@
+config MTK_THERMAL
+ tristate "Mediatek thermal drivers"
+ depends on THERMAL_OF
+ help
+ This is the option for Mediatek thermal software
+ solutions. Please enable corresponding options to
+ get temperature information from thermal sensors or
+ turn on throttle mechaisms for thermal mitigation.
+
+if MTK_THERMAL
+
+config MTK_SOC_THERMAL
+ tristate "Temperature sensor driver for mediatek SoCs"
+ depends on HAS_IOMEM
+ depends on NVMEM
+ depends on RESET_CONTROLLER
+ help
+ Enable this option if you want to get SoC temperature
+ information for Mediatek platforms. This driver
+ configures thermal controllers to collect temperature
+ via AUXADC interface.
+
+endif
diff --git a/drivers/thermal/mediatek/Makefile
b/drivers/thermal/mediatek/Makefile
new file mode 100644
index ..f75313ddce5e
--- /dev/null
+++ b/drivers/thermal/mediatek/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MTK_SOC_THERMAL) += soc_temp.o
diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mediatek/soc_temp.c
similarity index 100%
rename from drivers/thermal/mtk_thermal.c
rename to drivers/thermal/mediatek/soc_temp.c
--
2.18.0
[PATCH 3/3] dt-bindings: thermal: Add binding document for mt6873 thermal controller
This patch adds binding document for mt6873 thermal controller.
Signed-off-by: Michael Kao
---
.../thermal/mediatek-thermal-lvts.yaml| 80 +++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/mediatek-thermal-lvts.yaml
diff --git
a/Documentation/devicetree/bindings/thermal/mediatek-thermal-lvts.yaml
b/Documentation/devicetree/bindings/thermal/mediatek-thermal-lvts.yaml
new file mode 100644
index ..745611718c0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal-lvts.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/mediatek-thermal-lvts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek SoC LVTS thermal controller (DTS) binding
+
+maintainers:
+ - Yu-Chia Chang , Michael Kao
+
+properties:
+ compatible:
+const: mediatek,mt6873-lvts
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: lvts_clk
+
+ "#thermal-sensor-cells":
+const: 0
+
+required:
+ - "#thermal-sensor-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+dts: lvts@1100b000 {
+compatible = "mediatek,mt6873-lvts";
+reg = <0x1100b000 0x1000>;
+clocks = < CLK_INFRA_THERM>;
+clock-names = "lvts_clk";
+#thermal-sensor-cells = <0>;
+interrupts = ;
+};
+
+thermal-zones {
+cpu_thermal: cpu-thermal {
+polling-delay-passive = <0>;
+polling-delay = <0>;
+
+thermal-sensors = <>;
+trips {
+cpu_alert1: cpu-alert1 {
+temperature = <85000>;
+hysteresis = <0>;
+type = "passive";
+};
+
+cpu_crit: cpu-crit {
+temperature = <12>;
+hysteresis = <0>;
+type = "critical";
+};
+};
+
+cooling-maps {
+};
+};
+};
+...
--
2.18.0
[PATCH 2/3] thermal: mediatek: Add LVTS drivers for SoC theraml zones
Add a LVTS (Low voltage thermal sensor) driver to report junction
temperatures in Mediatek SoC and register the maximum temperature
of sensors and each sensor as a thermal zone.
Signed-off-by: Yu-Chia Chang
Signed-off-by: Michael Kao
---
drivers/thermal/mediatek/Kconfig | 10 +
drivers/thermal/mediatek/Makefile|1 +
drivers/thermal/mediatek/soc_temp_lvts.c | 1293 ++
drivers/thermal/mediatek/soc_temp_lvts.h | 312 ++
4 files changed, 1616 insertions(+)
create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.c
create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.h
diff --git a/drivers/thermal/mediatek/Kconfig b/drivers/thermal/mediatek/Kconfig
index 0351e73170b7..d716d0372e1e 100644
--- a/drivers/thermal/mediatek/Kconfig
+++ b/drivers/thermal/mediatek/Kconfig
@@ -20,4 +20,14 @@ config MTK_SOC_THERMAL
configures thermal controllers to collect temperature
via AUXADC interface.
+config MTK_SOC_THERMAL_LVTS
+tristate "LVTS (Low voltage thermal sensor) driver for Mediatek SoCs"
+depends on HAS_IOMEM
+depends on NVMEM
+depends on RESET_TI_SYSCON
+help
+ Enable this option if you want to get SoC temperature
+ information for Mediatek platforms. This driver
+ configures LVTS thermal controllers to collect temperatures
+ via Analog Serial Interface(ASIF).
endif
diff --git a/drivers/thermal/mediatek/Makefile
b/drivers/thermal/mediatek/Makefile
index f75313ddce5e..16ce166e5916 100644
--- a/drivers/thermal/mediatek/Makefile
+++ b/drivers/thermal/mediatek/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MTK_SOC_THERMAL) += soc_temp.o
+obj-$(CONFIG_MTK_SOC_THERMAL_LVTS) += soc_temp_lvts.o
diff --git a/drivers/thermal/mediatek/soc_temp_lvts.c
b/drivers/thermal/mediatek/soc_temp_lvts.c
new file mode 100644
index ..1a608870c151
--- /dev/null
+++ b/drivers/thermal/mediatek/soc_temp_lvts.c
@@ -0,0 +1,1293 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "soc_temp_lvts.h"
+
+/*==
+ * Definition or macro function
+ *==
+ */
+#define STOP_COUNTING_V4 (DEVICE_WRITE | RG_TSFM_CTRL_0 << 8 | 0x00)
+#define SET_RG_TSFM_LPDLY_V4 (DEVICE_WRITE | RG_TSFM_CTRL_4 << 8 | 0xA6)
+#define SET_COUNTING_WINDOW_20US1_V4 (DEVICE_WRITE | RG_TSFM_CTRL_2 << 8 |
0x00)
+#define SET_COUNTING_WINDOW_20US2_V4 (DEVICE_WRITE | RG_TSFM_CTRL_1 << 8 |
0x20)
+#define TSV2F_CHOP_CKSEL_AND_TSV2F_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_2 << 8
| 0x84)
+#define TSBG_DEM_CKSEL_X_TSBG_CHOP_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_4 << 8
| 0x7C)
+#define SET_TS_RSV_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_1 << 8 | 0x8D)
+#define SET_TS_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 | 0xF4)
+#define TOGGLE_RG_TSV2F_VCO_RST1_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 |
0xFC)
+#define TOGGLE_RG_TSV2F_VCO_RST2_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 |
0xF4)
+
+#define SET_LVTS_AUTO_RCK_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_6 << 8 | 0x01)
+#define SELECT_SENSOR_RCK_V4(id) (DEVICE_WRITE | RG_TSV2F_CTRL_5 << 8 | (id))
+#define SET_DEVICE_SINGLE_MODE_V4 (DEVICE_WRITE | RG_TSFM_CTRL_3 << 8 | 0x78)
+#define KICK_OFF_RCK_COUNTING_V4 (DEVICE_WRITE | RG_TSFM_CTRL_0 << 8 | 0x02)
+#define SET_SENSOR_NO_RCK_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_5 << 8 | 0x10)
+#define SET_DEVICE_LOW_POWER_SINGLE_MODE_V4 (DEVICE_WRITE | RG_TSFM_CTRL_3 <<
8| 0xB8)
+
+#define ENABLE_FEATURE(feature)(lvts_data->feature_bitmap |=
(feature))
+#define DISABLE_FEATURE(feature) (lvts_data->feature_bitmap &=
(~(feature)))
+#define IS_ENABLE(feature) (lvts_data->feature_bitmap & (feature))
+
+#define DISABLE_THERMAL_HW_REBOOT (-274000)
+
+#define CLOCK_26MHZ_CYCLE_NS (38)
+#define BUS_ACCESS_US (2)
+
+#define FEATURE_DEVICE_AUTO_RCK(BIT(0))
+#define FEATURE_CK26M_ACTIVE (BIT(1))
+#define CK26M_ACTIVE (((lvts_data->feature_bitmap & FEATURE_CK26M_ACTIVE)
\
+ ? 1 : 0) << 30)
+#define GET_BASE_ADDR(tc_id) \
+ (lvts_data->domain[lvts_data->tc[tc_id].domain_index].base \
+ + lvts_data->tc[tc_id].addr_offset)
+
+#define SET_TC_SPEED_IN_US(pu, gd, fd, sd) \
+ { \
+ .period_unit = (((pu) * 1000) / (256 * CLOCK_26MHZ_CYCLE_NS)),
\
+ .group_interval_delay = ((gd) / (pu)), \
+ .filter_interval_delay = ((fd) / (pu)), \
+ .sensor_interval_delay = ((sd) / (pu)), \
+ }
+
+#define GET_CAL_DATA_BITMASK(index, h, l) \
+ (((index) < lvts_data->num_efuse_addr) \
+ ? ((lvts_data->efuse[(index)] & GENMASK(h, l)) >> l)\
+ : 0)
+
+#define
[PATCH 0/3] Add LVTS architecture thermal controller
This patch move thermal files related to Mediatek to the mediatek folder.
And introduce the new architecture LVTS (low pressure thermal sensor) driver to
report
the highest temperature in the SoC and record the highest temperature sensor,
each sensor as a hot zone.
The LVTS body is divided into two parts, the LVTS controller and the LVTS
device.
The LVTS controller can connect up to 4 LVTS devices, and each LVTS device
can connect up to 7 TSMCUs.
The architecture will be the first to be used on mt6873 and mt8192.
Michael Kao (3):
thermal: mediatek: Relocate driver to mediatek folder
thermal: mediatek: Add LVTS drivers for SoC theraml zones
dt-bindings: thermal: Add binding document for mt6873 thermal
controller
.../thermal/mediatek-thermal-lvts.yaml| 80 +
drivers/thermal/Kconfig | 14 +-
drivers/thermal/Makefile |2 +-
drivers/thermal/mediatek/Kconfig | 33 +
drivers/thermal/mediatek/Makefile |2 +
.../{mtk_thermal.c => mediatek/soc_temp.c}|0
drivers/thermal/mediatek/soc_temp_lvts.c | 1293 +
drivers/thermal/mediatek/soc_temp_lvts.h | 312
8 files changed, 1725 insertions(+), 11 deletions(-)
create mode 100644
Documentation/devicetree/bindings/thermal/mediatek-thermal-lvts.yaml
create mode 100644 drivers/thermal/mediatek/Kconfig
create mode 100644 drivers/thermal/mediatek/Makefile
rename drivers/thermal/{mtk_thermal.c => mediatek/soc_temp.c} (100%)
create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.c
create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.h
--
2.18.0
RE: [RFC] fpga: dfl: a prototype uio driver
> Subject: Re: [RFC] fpga: dfl: a prototype uio driver
>
> On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > >From [PATCH 0/2] UIO support for dfl devices
> > https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-
> yilun...@intel.com/
> >
> > Here is an idea to have uio support with no driver override.
> >
> > This makes UIO the primary driver interface because every feature
> > will have one and makes the existing platform driver interface
> > secondary. There will be a new burden for locking write access when
> > they compete.
> >
> > Example shows finding the fpga's temperture.
>
> Hi Tom:
>
> Thanks for the idea and detailed illustrate with the patch. I see it
> abandons the driver_override and expose all the DFL devices to userspace
> by UIO. I'd like to see if we could get some more comments on it.
This allows concurrent access from both userspace and kernel space driver
to the same feature device? conflicts?
Hao
>
> Thanks,
> Yilun
>
> >
> > Signed-off-by: Tom Rix
> > ---
> > drivers/fpga/dfl-fme-main.c | 9 +++-
> > drivers/fpga/dfl-uio.c | 96 +
> > drivers/fpga/dfl.c | 44 -
> > drivers/fpga/dfl.h | 9
> > uio.c | 56 ++
> > 5 files changed, 212 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/fpga/dfl-uio.c
> > create mode 100644 uio.c
> >
> > diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> > index 037dc4f946f0..3323e90a18c4 100644
> > --- a/drivers/fpga/dfl-fme-main.c
> > +++ b/drivers/fpga/dfl-fme-main.c
> > @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device
> *pdev)
> > if (ret)
> > goto dev_destroy;
> >
> > - ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> > + ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
> > if (ret)
> > goto feature_uinit;
> >
> > + ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> > + if (ret)
> > + goto feature_uinit_uio;
> > +
> > return 0;
> >
> > +feature_uinit_uio:
> > + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> > feature_uinit:
> > dfl_fpga_dev_feature_uinit(pdev);
> > dev_destroy:
> > @@ -726,6 +732,7 @@ exit:
> > static int fme_remove(struct platform_device *pdev)
> > {
> > dfl_fpga_dev_ops_unregister(pdev);
> > + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> > dfl_fpga_dev_feature_uinit(pdev);
> > fme_dev_destroy(pdev);
> >
> > diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
> > new file mode 100644
> > index ..7610ee0b19dc
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio.c
> > @@ -0,0 +1,96 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * prototype dfl uio driver
> > + *
> > + * Copyright Tom Rix 2020
> > + */
> > +#include
> > +#include "dfl.h"
> > +
> > +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
> > +{
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
> > +{
> > + int ret = -ENODEV;
> > + return ret;
> > +}
> > +
> > +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
> > +{
> > + int ret = -ENODEV;
> > + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> > + if (feature->dev)
> > + mutex_lock(>lock);
> > +
> > + ret = 0;
> > + return ret;
> > +}
> > +
> > +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
> > +{
> > + int ret = -ENODEV;
> > + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> > + if (feature->dev)
> > + mutex_unlock(>lock);
> > +
> > + ret = 0;
> > + return ret;
> > +}
> > +
> > +static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
> > +{
> > + int ret = -ENODEV;
> > + return ret;
> > +}
> > +
> > +int dfl_uio_add(struct dfl_feature *feature)
> > +{
> > + struct uio_info *uio = >uio;
> > + struct resource *res =
> > + >dev->resource[feature->resource_index];
> > + int ret = 0;
> > +
> > + uio->name = kasprintf(GFP_KERNEL, "dfl-uio-%llx", feature->id);
> > + if (!uio->name) {
> > + ret = -ENOMEM;
> > + goto exit;
> > + }
> > +
> > + uio->version = "0.1";
> > + uio->mem[0].memtype = UIO_MEM_PHYS;
> > + uio->mem[0].addr = res->start & PAGE_MASK;
> > + uio->mem[0].offs = res->start & ~PAGE_MASK;
> > + uio->mem[0].size = (uio->mem[0].offs + resource_size(res)
> > + + PAGE_SIZE - 1) & PAGE_MASK;
> > + /* How are nr_irqs > 1 handled ??? */
> > + if (feature->nr_irqs == 1)
> > + uio->irq = feature->irq_ctx[0].irq;
> > + uio->handler = dfl_uio_handler;
> > + //uio->mmap = dfl_uio_mmap;
> > + uio->open = dfl_uio_open;
> > + uio->release = dfl_uio_release;
> > + uio->irqcontrol = dfl_uio_irqcontrol;
RE: [PATCH] exfat: Avoid allocating upcase table using kcalloc()
> > I have not yet received a report of the same issue. > > But I agree that this problem is likely to occur even if it is low > > probability. > > Perhaps I should clarify my setup a little bit more. > The issue can be reliably reproduced on my laptop. It has 8 GBs of RAM > (pretty common amount nowadays) and runs an unmodified Fedora 32 kernel. > Also, I use zswap, which seems to be contributing to fragmentation as well. > > > I think it would be more appropriate to use kvcalloc and kvfree instead. > > I do not think this is really needed. > Upcase table allocation is relatively large (32 pages of 4KB size) and > happens only once, when the drive is being mounted. Also, exfat driver > does not rely on the fact that the table is physically contiguous. > That said, vmalloc/vfree seems to be the best option, according to > kernel's "Memory Allocation Guide". The address range available for vmalloc() allocations is limited on 32-bit systems. If all kernel codes that need non-contiguous memory of the size order 1 or larger try to allocate it by only vmalloc(), the address range for vmalloc() could be insufficient. So, I think it would be better to give kmalloc() "one" chance. I know that kvmalloc() only tries kmalloc() once (noretry, nowarn) and if it fails, it immediately falls back to vmalloc(). Therefore, I think kvmalloc() and kvfree() are the best solution for solving the problem you are facing and the problem I mentioned above. Could you send me patch v3 that uses kvcalloc() and kvfree()? > > -- > Artem
Re: [PATCH v2] input: raydium_ts_i2c: Do not split tx transactions
On Fri, Dec 04, 2020 at 04:59:41PM -0800, Furquan Shaikh wrote: > Raydium device does not like splitting of tx transactions into > multiple messages - one for the register address and one for the > actual data. This results in incorrect behavior on the device side. > > This change updates raydium_i2c_read and raydium_i2c_write to create > i2c_msg arrays separately and passes those arrays into > raydium_i2c_xfer which decides based on the address whether the bank > switch command should be sent. The bank switch header is still added > by raydium_i2c_read and raydium_i2c_write to ensure that all these > operations are performed as part of a single I2C transfer. It > guarantees that no other transactions are initiated to any other > device on the same bus after the bank switch command is sent. > > Signed-off-by: Furquan Shaikh Applied, thank you. -- Dmitry
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 19-11-20, 11:35, Viresh Kumar wrote:
> On 18-11-20, 08:53, Rob Clark wrote:
> > On Tue, Nov 17, 2020 at 9:28 PM Viresh Kumar
> > wrote:
> > >
> > > On 17-11-20, 09:02, Rob Clark wrote:
> > > > With that on top of the previous patch,
> > >
> > > Don't you still have this ? Which fixed the lockdep in the remove path.
> > >
> > > https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
> > >
> > > To make it clear you need these patches to fix the OPP stuff:
> > >
> > > //From 5.10-rc3 (the one from the above link).
> > > commit e0df59de670b ("opp: Reduce the size of critical section in
> > > _opp_table_kref_release()")
>
> This fixes debugfs stuff while the OPP table is removed.
>
> > > //Below two from linux-next
> > > commit ef43f01ac069 ("opp: Always add entries in dev_list with
> > > opp_table->lock held")
> > > commit 27c09484dd3d ("opp: Allocate the OPP table outside of
> > > opp_table_lock")
>
> This fixes debugfs stuff while the OPP table is added.
>
> > > This matches the diff I gave you earlier.
> > >
> >
> > no, I did not have all three, only "opp: Allocate the OPP table
> > outside of opp_table_lock" plus the fixup. But with all three:
>
> And looking at the lockdep you gave now, it looks like we have a
> problem with OPP table's internal lock (opp_table->lock) as well apart
> from the global opp_table_lock.
>
> I wish there was a way for me to reproduce the lockdep :(
>
> I know this is exhausting for both of us and I really want to be over
> with it as soon as possible, this really should be the last patch
> here, please try this along with other two. This fixes the debugfs
> thing while the OPPs in the OPP table are removed (they are already
> added without a lock around debugfs stuff).
>
> AFAIU, there is no further debugfs stuff that happens from within the
> locks and so this really should be the last patch unless I missed
> something.
Rob, were you able to test this patch ?
--
viresh
[PATCH] media: usb: dvd-usb: fix uninit-value bug in dibusb_read_eeprom_byte()
In dibusb_read_eeprom_byte(), if dibusb_i2c_msg() fails, val gets assigned an value that's not properly initialized. Using kzalloc() in place of kmalloc() for the buffer fixes this issue, as the val can now be set to 0 in the event dibusb_i2c_msg() fails. Reported-by: syzbot+e27b4fd589762b0b9...@syzkaller.appspotmail.com Tested-by: syzbot+e27b4fd589762b0b9...@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam --- drivers/media/usb/dvb-usb/dibusb-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb/dibusb-common.c b/drivers/media/usb/dvb-usb/dibusb-common.c index 02b51d1a1b67..aff60c10cb0b 100644 --- a/drivers/media/usb/dvb-usb/dibusb-common.c +++ b/drivers/media/usb/dvb-usb/dibusb-common.c @@ -223,7 +223,7 @@ int dibusb_read_eeprom_byte(struct dvb_usb_device *d, u8 offs, u8 *val) u8 *buf; int rc; - buf = kmalloc(2, GFP_KERNEL); + buf = kzalloc(2, GFP_KERNEL); if (!buf) return -ENOMEM; -- 2.25.1
Re: [PATCH v2 0/9] Add support for Microsoft Surface System Aggregator Module
On Sun, Dec 06, 2020 at 04:58:52PM +0100, Maximilian Luz wrote:
> On 12/6/20 8:07 AM, Leon Romanovsky wrote:
> > On Thu, Dec 03, 2020 at 10:26:31PM +0100, Maximilian Luz wrote:
> > > Hello,
> > >
> > > Here is version two of the Surface System Aggregator Module (SAM/SSAM)
> > > driver series, adding initial support for the embedded controller on 5th
> > > and later generation Microsoft Surface devices. Initial support includes
> > > the ACPI interface to the controller, via which battery and thermal
> > > information is provided on some of these devices.
> > >
> > > The previous version and cover letter detailing what this series is
> > > about can be found at
> > >
> > >
> > > https://lore.kernel.org/platform-driver-x86/20201115192143.21571-1-luzmaximil...@gmail.com/
> > >
> > > This patch-set can also be found at the following repository and
> > > reference, if you prefer to look at a kernel tree instead of these
> > > emails:
> > >
> > >https://github.com/linux-surface/kernel tags/s/surface-aggregator/v2
> > >
> > > Thank you all for the feedback to v1, I hope I have addressed all
> > > comments.
> >
> >
> > I think that it is too far fetched to attempt and expose UAPI headers
> > for some obscure char device that we are all know won't be around in
> > a couple of years from now due to the nature of how this embedded world
> > works.
> >
> > More on that, the whole purpose of proposed interface is to debug and
> > not intended to be used by any user space code.
>
> I believe this has already been extensively discussed. I want to focus
> more on the part below in this response:
>
> > Also the idea that you are creating new bus just for this device doesn't
> > really sound right. I recommend you to take a look on auxiliary bus and
> > use it or come with very strong justifications why it is not fit yet.
>
> I tend to agree that this is a valid concern to bring up, and adding a
> new bus is not something that should be done lightly.
>
> Let's ignore that this has been merged into -next after I've submitted
> this (and that I only recently became aware of this) for the time being.
> If I would see a clear benefit, I would not hesitate to switch the
> driver and subsystem over to this.
>
> What does concern me most, is the device/driver matching by string.
> Right now, this subsystem matches those via a device UID. This UID is
> directly tied to the EC functionality provided by the device. A bit of
> background to this:
>
> Requests sent to the EC contain an address, so to say. This consists of
>
> - Target category (TC): Broad group of functionality, e.g. battery/AC,
>thermal, HID input, ..., i.e. a subsystem of sorts.
>
> - Target ID (TID): Some major device, e.g. the dual batteries on the
>Surface Book 3 are addressed by target ID 1 and 2, some functionality
>is only available at 2 and some only at 1. May be related to physical
>parts of/locations on the device.
>
> - Instance ID (IID): A device instance, e.g. for thermal sensors each
>sensor is at TC=0x03 (thermal) and has a different instance ID.
>
> Those can be used to pretty much uniquely identify a sub-device on the
> EC.
>
> Note the "pretty much". To truly make them unique we can add a function
> ID (FN). With that, we can for example match for TC=0x03, TID=*, IID=*,
> FN=0x00 to load a driver against all thermal sensors. And this is
> basically the device UID that the subsystem uses for matching (modulo
> domain for virtual devices, i.e. device hubs). Sure, we can use some
> string, but that then leads to having to come up with creative names
> once we need some driver specific data, e.g. in the battery driver [1]:
>
> const struct auxiliary_device_id my_auxiliary_id_table[] = {
> { .name = "surface_aggregator_registry.battery", .driver_data = x },
> { .name = "surface_aggregator_registry.battery_sb3", .driver_data = y
> },
> { },
> }
>
> Arguably, not _that_ big of a deal.
>
> What worries me more is that this will block any path of auto-detecting
> devices on a more general/global level. Right now, we hard-code devices
> because we haven't found any way to detect them via some EC query yet
> [2] (FYI the node groups contain all devices that will eventually be
> added to the bus, which are already 11 devices on the Surface Book 3
> without taking missing thermal sensors into account; also they are
> spread across a bunch of subsystems, so not just platform). That's of
> course not an ideal solution and one that I hope we can eventually fix.
> If we can auto-detect devices, it's very likely that we know or can
> easily get to the device UID. A meaningful string is somewhat more
> difficult.
>
> This registry, which is loaded against a platform device that, from what
> we can tell differentiates the models for some driver bindings by
> Windows (that's speculation), is also the reason why we don't register
> client devices directly under the main module, so instead of a nice
>
[PATCH] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup.
In mtrr_type_lookup, if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, write-back attribute
is returned. These condition checks are for ensuring the input memory
address region is mapped to the physical memory actually.
However, if the end address is just aligned with the top of memory,
the condition check treats the address is over the top of memory, and
write-back attribute is not returned.
There is a real case of NVDIMM. The nd_pmem module tries to map
NVDIMMs as cacheable memories when NVDIMMs are connected. If a NVDIMM
is the last of the DIMMs, the performance of this NVDIMM becomes very
low since it aligned with the top of memory and its memory type is
uncached-minus.
To check the top of memory should use "<=" instead of "<" since both the
input end address and the value of top of memory are actually the start
of next region.
Fixes: b73522e0c1be ("x86/mm/mtrr: Enhance MTRR checks in kernel mapping
helpers")
Signed-off-by: Ying-Tsun Huang
---
arch/x86/kernel/cpu/mtrr/generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index 23ad8e953dfb..b13e87dba27d 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -303,7 +303,7 @@ u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
goto out;
}
- if (mtrr_tom2 && (start >= (1ULL<<32)) && (end < mtrr_tom2))
+ if (mtrr_tom2 && (start >= (1ULL<<32)) && (end <= mtrr_tom2))
type = MTRR_TYPE_WRBACK;
out:
--
2.25.1
[PATCH v3] venus: core: add support to dump FW region
From: Dikshita Agarwal
Add support to dump video FW region during FW crash
using devcoredump helpers.
Signed-off-by: Dikshita Agarwal
---
drivers/media/platform/qcom/venus/core.c | 31
drivers/media/platform/qcom/venus/core.h | 2 ++
drivers/media/platform/qcom/venus/firmware.c | 3 +++
3 files changed, 36 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 5102403..f23923d 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -7,8 +7,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +24,33 @@
#include "firmware.h"
#include "pm_helpers.h"
+static void venus_coredump(struct venus_core *core)
+{
+ struct device *dev;
+ phys_addr_t mem_phys;
+ size_t mem_size;
+ void *mem_va;
+ void *data;
+
+ dev = core->dev;
+ mem_phys = core->fw.mem_phys;
+ mem_size = core->fw.mem_size;
+
+ mem_va = memremap(mem_phys, mem_size, MEMREMAP_WC);
+ if (!mem_va)
+ return;
+
+ data = vmalloc(mem_size);
+ if (!data) {
+ memunmap(mem_va);
+ return;
+ }
+
+ memcpy(data, mem_va, mem_size);
+ dev_coredumpv(dev, data, mem_size, GFP_KERNEL);
+ memunmap(mem_va);
+}
+
static void venus_event_notify(struct venus_core *core, u32 event)
{
struct venus_inst *inst;
@@ -67,6 +96,8 @@ static void venus_sys_error_handler(struct work_struct *work)
venus_shutdown(core);
+ venus_coredump(core);
+
pm_runtime_put_sync(core->dev);
while (core->pmdomains[0] && pm_runtime_active(core->pmdomains[0]))
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 842a294..8122f23 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -171,6 +171,8 @@ struct venus_core {
struct device *dev;
struct iommu_domain *iommu_domain;
size_t mapped_mem_size;
+ phys_addr_t mem_phys;
+ size_t mem_size;
} fw;
struct mutex lock;
struct list_head instances;
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 9a9c097..f3d91d23 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -201,6 +201,9 @@ int venus_boot(struct venus_core *core)
return -EINVAL;
}
+ core->fw.mem_size = mem_size;
+ core->fw.mem_phys = mem_phys;
+
if (core->use_tz)
ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
else
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities
On 20-12-03 23:41:16, Dan Williams wrote: > On Tue, Nov 10, 2020 at 9:44 PM Ben Widawsky wrote: > > > > CXL devices contain an array of capabilities that describe the > > interactions software can interact with the device, or firmware running > > on the device. A CXL compliant device must implement the device status > > and the mailbox capability. A CXL compliant memory device must implement > > the memory device capability. > > > > Each of the capabilities can [will] provide an offset within the MMIO > > region for interacting with the CXL device. > > > > Signed-off-by: Ben Widawsky > > --- > > drivers/cxl/cxl.h | 89 +++ > > drivers/cxl/mem.c | 58 +++--- > > 2 files changed, 143 insertions(+), 4 deletions(-) > > create mode 100644 drivers/cxl/cxl.h > > > > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h > > new file mode 100644 > > index ..02858ae63d6d > > --- /dev/null > > +++ b/drivers/cxl/cxl.h > [..] > > +static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg) > > Going through my reworks and the "raw" jumped out at me. My typical > interpretation of "raw" in respect to register access macros is the > difference between readl() and __raw_readl() which means "don't do > bus endian swizzling, and don't do a memory clobber barrier". Any > heartburn to drop the "raw"? > > ...is it only me that reacts that way? I will drop "raw". Especially given that I intend to reuse the word in v2 for something entirely different, it makes sense. My idea of "raw" was that it's just unfettered access to the device's MMIO space. No offsets, no checks. I'm not sure of a better adjective to describe that, but if you have any in mind, I'd like to add it.
Re: WARNING: bad unlock balance detected! - mkfs.ext4/426 is trying to release lock (rcu_read_lock)
On Mon, Dec 07, 2020 at 11:17:29AM +0530, Naresh Kamboju wrote: > While running "mkfs -t ext4" on arm64 juno-r2 device connected with SSD drive > the following kernel warning reported on stable rc 5.9.13-rc1 kernel. > > Steps to reproduce: > -- > # boot arm64 Juno-r2 device with stable-rc 5.9.13-rc1. > # Connect SSD drive > # Format the file system ext4 type > mkfs -t ext4 > # you will notice this warning Does it happen easily? Can you bisect? > Crash log: > -- > Writing superblocks and filesystem accounting information: 0/895 > [ 86.131095] > [ 86.132592] = > [ 86.137300] WARNING: bad unlock balance detected! > [ 86.142012] 5.9.13-rc1 #1 Not tainted > [ 86.145675] - > [ 86.150384] mkfs.ext4/426 is trying to release lock (rcu_read_lock) at: > [ 86.157020] [] blk_queue_exit+0xcc/0x1b0 > [ 86.162511] but there are no more locks to release! This really doesn't make much sense. blk_queue_exit() in 5.9.12 does: percpu_ref_put(>q_usage_counter); (literally, that's the entire function) percpu_ref_put() does: rcu_read_lock(); if (__ref_is_percpu(ref, _count)) this_cpu_sub(*percpu_count, nr); else if (unlikely(atomic_long_sub_and_test(nr, >count))) ref->release(ref); rcu_read_unlock(); Unless ->release() has an unbalanced rcu_read_unlock(), there definitely is a lock to release! Some archaeology says that ->release is blk_queue_usage_counter_release(), which calls wake_up_all(>mq_freeze_wq); which doesn't appear to use RCU at all. So this trace makes no sense, and all I can do is ask you to bisect it.
[PATCH 1/1] ice: fix array overflow on receiving too many fragments for a packet
From: Zhang Xiaohui
If the hardware receives an oversized packet with too many rx fragments,
skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
This becomes especially visible if it corrupts the freelist pointer of
a slab page.
Signed-off-by: Zhang Xiaohui
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c
b/drivers/net/ethernet/intel/ice/ice_txrx.c
index eae75260f..f0f034fa5 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -823,8 +823,12 @@ ice_add_rx_frag(struct ice_ring *rx_ring, struct
ice_rx_buf *rx_buf,
if (!size)
return;
- skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, rx_buf->page,
+ struct skb_shared_info *shinfo = skb_shinfo(skb);
+
+ if (shinfo->nr_frags < ARRAY_SIZE(shinfo->frags)) {
+ skb_add_rx_frag(skb, shinfo, rx_buf->page,
rx_buf->page_offset, size, truesize);
+ }
/* page is being used so we must update the page offset */
ice_rx_buf_adjust_pg_offset(rx_buf, truesize);
--
2.17.1
Re: [V9fs-developer] [RFC PATCH] 9p: create writeback fid on shared mmap
在 星期一, 2020-12-07 04:53:18 Dominique Martinet 撰写
> Dominique Martinet wrote on Sun, Dec 06, 2020:
> > Chengguang Xu wrote on Sat, Dec 05, 2020:
> > > If vma is shared and the file was opened for writing,
> > > we should also create writeback fid because vma may be
> > > mprotected writable even if now readonly.
> >
> > Hm, I guess it makes sense.
>
> I had a second look, and generic_file_readonly_mmap uses vma's
> `vma->vm_flags & VM_MAYWRITE` instead (together with VM_SHARED),
> while mapping_writably_mapped ultimately basically only seems to
> validate that the mapping is shared from a look at mapping_map_writable
> callers? It's not very clear to me.
>
> , VM_MAYWRITE is set anytime we have a shared map where file has
> been opened read-write, which seems to be what you want with regards to
> protecting from mprotect calls.
>
> How about simply changing check from WRITE to MAYWRITE?
It would be fine and based on the code in do_mmap(), it seems we even don't
need extra check here. The condition (vma->vm_flags & VM_SHARED) will be
enough.
Am I missing something?
Thanks,
Chengguang
>
> v9inode = V9FS_I(inode);
> mutex_lock(>v_mutex);
> if (!v9inode->writeback_fid &&
> (vma->vm_flags & VM_SHARED) &&
> -(vma->vm_flags & VM_WRITE)) {
> +(vma->vm_flags & VM_MAYWRITE)) {
> /*
> * clone a fid and add it to writeback_fid
> * we do it during mmap instead of
[PATCH] watchdog: qcom: Avoid context switch in restart handler
The use of msleep() in the restart handler will cause scheduler to
induce a context switch which is not desirable. This generates below
warning on SDX55 when WDT is the only available restart source:
[ 39.800188] reboot: Restarting system
[ 39.804115] [ cut here ]
[ 39.807855] WARNING: CPU: 0 PID: 678 at kernel/rcu/tree_plugin.h:297
rcu_note_context_switch+0x190/0x764
[ 39.812538] Modules linked in:
[ 39.821954] CPU: 0 PID: 678 Comm: reboot Not tainted
5.10.0-rc1-00063-g33a9990d1d66-dirty #47
[ 39.824854] Hardware name: Generic DT based system
[ 39.833470] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 39.838154] [] (show_stack) from []
(dump_stack+0x8c/0xa0)
[ 39.846049] [] (dump_stack) from [] (__warn+0xd8/0xf0)
[ 39.853058] [] (__warn) from []
(warn_slowpath_fmt+0x64/0xc8)
[ 39.859925] [] (warn_slowpath_fmt) from []
(rcu_note_context_switch+0x190/0x764)
[ 39.867503] [] (rcu_note_context_switch) from []
(__schedule+0x84/0x640)
[ 39.876685] [] (__schedule) from [] (schedule+0x58/0x10c)
[ 39.885095] [] (schedule) from []
(schedule_timeout+0x1e8/0x3d4)
[ 39.892135] [] (schedule_timeout) from []
(msleep+0x2c/0x38)
[ 39.899947] [] (msleep) from []
(qcom_wdt_restart+0xc4/0xcc)
[ 39.907319] [] (qcom_wdt_restart) from []
(watchdog_restart_notifier+0x18/0x28)
[ 39.914715] [] (watchdog_restart_notifier) from []
(atomic_notifier_call_chain+0x60/0x84)
[ 39.923487] [] (atomic_notifier_call_chain) from []
(machine_restart+0x78/0x7c)
[ 39.933551] [] (machine_restart) from []
(__do_sys_reboot+0xdc/0x1e0)
[ 39.942397] [] (__do_sys_reboot) from []
(ret_fast_syscall+0x0/0x54)
[ 39.950721] Exception stack(0xc3e0bfa8 to 0xc3e0bff0)
[ 39.958855] bfa0: 0001221c bed2fe24 fee1dead 28121969
01234567
[ 39.963832] bfc0: 0001221c bed2fe24 0003 0058 000225e0
[ 39.971985] bfe0: b6e62560 bed2fc84 00010fd8 b6e62580
[ 39.980124] ---[ end trace 3f578288bad866e4 ]---
Hence, replace msleep() with mdelay() to fix this issue.
Fixes: 05e487d905ab ("watchdog: qcom: register a restart notifier")
Signed-off-by: Manivannan Sadhasivam
---
drivers/watchdog/qcom-wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
index ab7465d186fd..cdf754233e53 100644
--- a/drivers/watchdog/qcom-wdt.c
+++ b/drivers/watchdog/qcom-wdt.c
@@ -148,7 +148,7 @@ static int qcom_wdt_restart(struct watchdog_device *wdd,
unsigned long action,
*/
wmb();
- msleep(150);
+ mdelay(150);
return 0;
}
--
2.25.1
Re: sched: core.c:7270 Illegal context switch in RCU-bh read-side critical section! __alloc_pages_nodemask
On Mon, Dec 07, 2020 at 11:06:10AM +0530, Naresh Kamboju wrote:
> While booting arm64 hikey board with stable-rc 5.9.13-rc1 the following
> warning
> noticed. This is hard to reproduce.
Ugh. You've got two warnings interleaved here. This is impossible
to read. Do you have any examples where only one of them happens?
> Step to reproduce:
>
> # Boot arm64 hikey device with stable-rc 5.9.13-rc1
> # Since it is hard to reproduce you may notice this warning
>
> Crash log :
> --
> [ 10.763081] [drm] Initialized kirin 1.0.0 20150718 for f410.ade
> on minor 1
> [ 10.764088] Bluetooth: hci0: change remote baud rate command in firmware
> [[0;32m OK [0m] Started TEE Supplicant.
> [ 10.791741] mmc_host mmc2: Bus speed (slot 0) = 2480Hz (slot
> req 40Hz, actual 40HZ div = 31)
> E/TC:0 tee_entry_std:545 Bad arg address 0x6b681000
> [[0;32m OK [0m] Started Periodic Command Scheduler.
> [ 10.846417] mmc_host mmc2: Bus speed (slot 0) = 2480Hz (slot
> req 2500Hz, actual 2480HZ div = 0)
> [ 10.887083]
> [ 10.887087]
> [ 10.887095] =
> [ 10.887098] =
> [ 10.887101] WARNING: bad unlock balance detected!
> [ 10.887107] WARNING: suspicious RCU usage
> [ 10.887112] 5.9.13-rc1 #1 Not tainted
> [ 10.887120] 5.9.13-rc1 #1 Not tainted
> [ 10.887122] -
> [ 10.887129] systemd-udevd/306 is trying to release lock (
> [ 10.887133] -
> [ 10.887135] fs_reclaim) at:
> [ 10.887144] /usr/src/kernel/kernel/sched/core.c:7270 Illegal
> context switch in RCU-bh read-side critical section!
> [ 10.887163] [] __alloc_pages_nodemask+0x250/0x4c0
> [ 10.887166]
> [ 10.887166] other info that might help us debug this:
> [ 10.887166]
> [ 10.887170] but there are no more locks to release!
> [ 10.887175]
> [ 10.887175] other info that might help us debug this:
> [ 10.887179]
> [ 10.887179] rcu_scheduler_active = 2, debug_locks = 0
> [ 10.887182] 1 lock held by systemd-udevd/306:
> [ 10.887189] 1 lock held by systemd-sysctl/342:
> [ 10.887192] #0: 7474e518
> [ 10.887199] #0:
> [ 10.887202] (
> [ 10.887209] 70c54708
> [ 10.887212] >mmap_lock){}-{3:3}
> [ 10.887219] (
> [ 10.887228] , at: do_page_fault+0x168/0x420
> [ 10.887230] >i_mutex_dir_key
> [ 10.887235]
> [ 10.887235] stack backtrace:
> [ 10.887237] #3){}-{3:3}
> [ 10.887246] CPU: 1 PID: 306 Comm: systemd-udevd Not tainted 5.9.13-rc1 #1
> [ 10.887255] , at: iterate_dir+0x54/0x1d0
> [ 10.887258] Hardware name: HiKey Development Board (DT)
> [ 10.887264]
> [ 10.887264] stack backtrace:
> [ 10.887266] Call trace:
> [ 10.887276] dump_backtrace+0x0/0x1f8
> [ 10.887283] show_stack+0x2c/0x38
> [ 10.887292] dump_stack+0xec/0x158
> [ 10.887303] print_unlock_imbalance_bug+0xec/0xf0
> [ 10.887311] lock_release+0x300/0x388
> [ 10.887320] __alloc_pages_nodemask+0x268/0x4c0
> [ 10.887329] alloc_pages_vma+0x90/0x240
> [ 10.887338] handle_mm_fault+0x8d4/0x12f0
> [ 10.887346] do_page_fault+0x1c4/0x420
> [ 10.887353] do_translation_fault+0xb0/0xcc
> [ 10.887363] do_mem_abort+0x50/0xb0
> [ 10.887372] el1_abort+0x28/0x30
> [ 10.887379] el1_sync_handler+0xc0/0xf0
> [ 10.887386] el1_sync+0x7c/0x100
> [ 10.887397] __arch_copy_to_user+0x1d8/0x310
> [ 10.887407] copy_page_to_iter+0x110/0x3e8
> [ 10.887416] generic_file_buffered_read+0x4b8/0xaa8
> [ 10.887423] generic_file_read_iter+0xd4/0x168
> [ 10.887432] blkdev_read_iter+0x50/0x78
> [ 10.887442] new_sync_read+0x100/0x1a0
> [ 10.887449] vfs_read+0x1b4/0x1d8
> [ 10.887457] ksys_read+0x74/0xf8
> [ 10.887465] __arm64_sys_read+0x24/0x30
> [ 10.887472] el0_svc_common.constprop.3+0x7c/0x198
> [ 10.887478] do_el0_svc+0x34/0xa0
> [ 10.887486] el0_sync_handler+0x16c/0x210
> [ 10.887492] el0_sync+0x140/0x180
> [ 10.887504] CPU: 6 PID: 342 Comm: systemd-sysctl Not tainted 5.9.13-rc1 #1
> [ 10.887510] Hardware name: HiKey Development Board (DT)
> [ 10.887515] Call trace:
> [ 10.887524] dump_backtrace+0x0/0x1f8
> [ 10.887531] show_stack+0x2c/0x38
> [ 10.887542] dump_stack+0xec/0x158
> [ 10.887552] lockdep_rcu_suspicious+0xd4/0xf8
> [ 10.887561] ___might_sleep+0x1e4/0x208
> [ 10.887569] __might_sleep+0x54/0x90
> [ 10.887577] __might_fault+0x58/0xa8
> [ 10.887584] filldir64+0x1f0/0x488
> [ 10.887593] call_filldir+0xb0/0x140
> [ 10.887600] ext4_readdir+0x700/0x900
> [ 10.887607] iterate_dir+0x88/0x1d0
> [ 10.887615] __arm64_sys_getdents64+0x70/0x1a0
> [ 10.887622] el0_svc_common.constprop.3+0x7c/0x198
> [ 10.887629] do_el0_svc+0x34/0xa0
> [ 10.887637] el0_sync_handler+0x16c/0x210
> [ 10.887644] el0_sync+0x140/0x180
> [ 10.912334] Console: switching to colour frame buffer device 256x72
>
> Reported-by: Naresh Kamboju
>
> Full boot log
[PATCH v1 2/2] scsi: ufs-mediatek: Keep VCC always-on for specific devices
For some devices which needs extra delay after VCC power down,
VCC shall be kept always-on in some MediaTek UFS platforms to
ensure the stability of such devices because the extra delay may
not be enough in those platforms.
Reviewed-by: Andy Teng
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 21 +
drivers/scsi/ufs/ufs-mediatek.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 3522458db3bb..80618af7c872 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -70,6 +70,13 @@ static bool ufs_mtk_is_va09_supported(struct ufs_hba *hba)
return !!(host->caps & UFS_MTK_CAP_VA09_PWR_CTRL);
}
+static bool ufs_mtk_is_broken_vcc(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ return !!(host->caps & UFS_MTK_CAP_BROKEN_VCC);
+}
+
static void ufs_mtk_cfg_unipro_cg(struct ufs_hba *hba, bool enable)
{
u32 tmp;
@@ -514,6 +521,9 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
if (of_property_read_bool(np, "mediatek,ufs-disable-ah8"))
host->caps |= UFS_MTK_CAP_DISABLE_AH8;
+ if (of_property_read_bool(np, "mediatek,ufs-broken-vcc"))
+ host->caps |= UFS_MTK_CAP_BROKEN_VCC;
+
dev_info(hba->dev, "caps: 0x%x", host->caps);
}
@@ -1003,6 +1013,17 @@ static int ufs_mtk_apply_dev_quirks(struct ufs_hba *hba)
static void ufs_mtk_fixup_dev_quirks(struct ufs_hba *hba)
{
ufshcd_fixup_dev_quirks(hba, ufs_mtk_dev_fixups);
+
+ if (ufs_mtk_is_broken_vcc(hba) && hba->vreg_info.vcc &&
+ (hba->dev_quirks & UFS_DEVICE_QUIRK_DELAY_AFTER_LPM)) {
+ hba->vreg_info.vcc->always_on = true;
+ /*
+* VCC will be kept always-on thus we don't
+* need any delay during regulator operations
+*/
+ hba->dev_quirks &= ~(UFS_DEVICE_QUIRK_DELAY_BEFORE_LPM |
+ UFS_DEVICE_QUIRK_DELAY_AFTER_LPM);
+ }
}
static void ufs_mtk_event_notify(struct ufs_hba *hba,
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 93d35097dfb0..3f0d3bb769e8 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -81,6 +81,7 @@ enum ufs_mtk_host_caps {
UFS_MTK_CAP_BOOST_CRYPT_ENGINE = 1 << 0,
UFS_MTK_CAP_VA09_PWR_CTRL = 1 << 1,
UFS_MTK_CAP_DISABLE_AH8= 1 << 2,
+ UFS_MTK_CAP_BROKEN_VCC = 1 << 3,
};
struct ufs_mtk_crypt_cfg {
--
2.18.0
[PATCH] scsi: ufs: Enable WB flush during suspend only if WB is enabled
WriteBootser flush during suspend is not necessary to be enabled if WriteBooster feature is disabled. Simply adding a check to prevent unexpected power drain. Signed-off-by: Stanley Chu --- drivers/scsi/ufs/ufshcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 4879e87577e1..89fa8b9ac11d 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -5458,7 +5458,7 @@ static bool ufshcd_wb_need_flush(struct ufs_hba *hba) u32 avail_buf; u8 index; - if (!ufshcd_is_wb_allowed(hba)) + if (!ufshcd_is_wb_allowed(hba) || !hba->wb_enabled) return false; /* * The ufs device needs the vcc to be ON to flush. -- 2.18.0
[PATCH v1 0/2] scsi: ufs: Allow regulators being always on
Hi, This series allow vendors to keep the regulator always-on, and provide an implementation on MediaTek UFS platforms. Stanley Chu (2): scsi: ufs: Allow regulators being always-on scsi: ufs-mediatek: Keep VCC always-on for specific devices drivers/scsi/ufs/ufs-mediatek.c | 21 + drivers/scsi/ufs/ufs-mediatek.h | 1 + drivers/scsi/ufs/ufs.h | 1 + drivers/scsi/ufs/ufshcd.c | 2 +- 4 files changed, 24 insertions(+), 1 deletion(-) -- 2.18.0
[PATCH v1 1/2] scsi: ufs: Allow regulators being always-on
Introduce a flag "always_on" in struct ufs_vreg to allow vendors
to keep the regulator always-on.
Reviewed-by: Andy Teng
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs.h| 1 +
drivers/scsi/ufs/ufshcd.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index d593edb48767..26f929afbcef 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -513,6 +513,7 @@ struct ufs_query_res {
struct ufs_vreg {
struct regulator *reg;
const char *name;
+ bool always_on;
bool enabled;
int min_uV;
int max_uV;
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6e72c0543c7b..4879e87577e1 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7973,7 +7973,7 @@ static int ufshcd_disable_vreg(struct device *dev, struct
ufs_vreg *vreg)
{
int ret = 0;
- if (!vreg || !vreg->enabled)
+ if (!vreg || !vreg->enabled || vreg->always_on)
goto out;
ret = regulator_disable(vreg->reg);
--
2.18.0
WARNING: bad unlock balance detected! - mkfs.ext4/426 is trying to release lock (rcu_read_lock)
While running "mkfs -t ext4" on arm64 juno-r2 device connected with SSD drive the following kernel warning reported on stable rc 5.9.13-rc1 kernel. Steps to reproduce: -- # boot arm64 Juno-r2 device with stable-rc 5.9.13-rc1. # Connect SSD drive # Format the file system ext4 type mkfs -t ext4 # you will notice this warning Crash log: -- Writing superblocks and filesystem accounting information: 0/895 [ 86.131095] [ 86.132592] = [ 86.137300] WARNING: bad unlock balance detected! [ 86.142012] 5.9.13-rc1 #1 Not tainted [ 86.145675] - [ 86.150384] mkfs.ext4/426 is trying to release lock (rcu_read_lock) at: [ 86.157020] [] blk_queue_exit+0xcc/0x1b0 [ 86.162511] but there are no more locks to release! [ 86.167392] [ 86.167392] other info that might help us debug this: [ 86.173929] no locks held by mkfs.ext4/426. [ 86.178114] [ 86.178114] stack backtrace: [ 86.182478] CPU: 1 PID: 426 Comm: mkfs.ext4 Not tainted 5.9.13-rc1 #1 [ 86.188926] Hardware name: ARM Juno development board (r2) (DT) [ 86.194853] Call trace: [ 86.197302] dump_backtrace+0x0/0x1f8 [ 86.200967] show_stack+0x2c/0x38 [ 86.204287] dump_stack+0xec/0x158 [ 86.207694] print_unlock_imbalance_bug+0xec/0xf0 [ 86.212404] lock_release+0x300/0x388 [ 86.216070] blk_queue_exit+0xe0/0x1b0 [ 86.219822] blk_mq_submit_bio+0x250/0xa08 [ 86.223922] submit_bio_noacct+0x468/0x518 [ 86.228022] submit_bio+0x4c/0x230 [ 86.231429] submit_bh_wbc+0x17c/0x218 [ 86.235182] __block_write_full_page+0x210/0x648 [ 86.239805] block_write_full_page+0x8c/0x150 [ 86.244167] blkdev_writepage+0x30/0x40 [ 86.248008] __writepage+0x38/0xd8 [ 86.251412] write_cache_pages+0x1fc/0x590 [ 86.255513] generic_writepages+0x64/0xa0 [ 86.259526] blkdev_writepages+0x28/0x38 [ 86.263452] do_writepages+0x6c/0x138 [ 86.267118] __filemap_fdatawrite_range+0x10c/0x148 [ 86.272001] file_write_and_wait_range+0x6c/0xd0 [ 86.276623] blkdev_fsync+0x3c/0x68 [ 86.280113] vfs_fsync_range+0x4c/0x90 [ 86.283864] do_fsync+0x48/0x78 [ 86.287007] __arm64_sys_fsync+0x24/0x38 [ 86.290933] el0_svc_common.constprop.3+0x7c/0x198 [ 86.295729] do_el0_svc+0x34/0xa0 [ 86.299047] el0_sync_handler+0x16c/0x210 [ 86.303060] el0_sync+0x140/0x180 Reported-by: Naresh Kamboju Full test log link, https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.12-47-g1372e1af58d4/testrun/3538037/suite/linux-log-parser/test/check-kernel-exception-2012808/log metadata: git branch: linux-5.9.y git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git commit: 1372e1af58d410676db7917cc3484ca22d471623 git describe: v5.9.12-47-g1372e1af58d4 make_kernelversion: 5.9.13-rc1 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/juno/lkft/linux-stable-rc-5.9/47/config -- Linaro LKFT https://lkft.linaro.org
linux-next: build failure after merge of the staging tree
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/iio/trigger/iio-trig-sysfs.c: In function 'iio_sysfs_trigger_probe':
drivers/iio/trigger/iio-trig-sysfs.c:164:21: error: 'struct irq_work' has no
member named 'flags'
164 | atomic_set(>work.flags, IRQ_WORK_HARD_IRQ);
| ^
Caused by commit
0449fc4eead7 ("iio: sysfs-trigger: Mark irq_work to expire in hardirq
context")
interacting with commit
7a9f50a05843 ("irq_work: Cleanup")
from the tip tree.
I applied the following merge fix patch:
From: Stephen Rothwell
Date: Mon, 7 Dec 2020 16:42:18 +1100
Subject: [PATCH] fixup for "irq_work: Cleanup"
Signed-off-by: Stephen Rothwell
---
drivers/iio/trigger/iio-trig-sysfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c
b/drivers/iio/trigger/iio-trig-sysfs.c
index 10a3fd29362b..0f6b512a5c37 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id)
t->trig->dev.parent = _sysfs_trig_dev;
iio_trigger_set_drvdata(t->trig, t);
- init_irq_work(>work, iio_sysfs_trigger_work);
- atomic_set(>work.flags, IRQ_WORK_HARD_IRQ);
+ t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work);
ret = iio_trigger_register(t->trig);
if (ret)
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpzmi42TNT1w.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/3] thermal: core: Add indication for userspace usage
> On Dec 1, 2020, at 02:39, Srinivas Pandruvada
> wrote:
>
> On Tue, 2020-12-01 at 02:22 +0800, Kai-Heng Feng wrote:
>>> On Dec 1, 2020, at 02:13, Srinivas Pandruvada <
>>> srinivas.pandruv...@linux.intel.com> wrote:
>>
>> [snipped]
>>
> What about creating an new callback
>
> enum thermal_trip_status {
> THERMAL_TRIP_DISABLED = 0,
> THERMAL_TRIP_ENABLED,
> };
>
> int get_trip_status(struct thermal_zone_device *, int trip,
> enum
> thermal_trip_status *state);
>
> Then in
> static void handle_thermal_trip(struct thermal_zone_device *tz,
> int
> trip)
> {
>
> /* before tz->ops->get_trip_temp(tz, trip, _temp); */
> if (tz->ops->get_trip_status) {
> enum thermal_trip_status *status;
>
> if (!tz->ops->get_trip_status(tz, trip, )) {
> if (status == THERMAL_TRIP_DISABLED)
> return;
> }
> }
> ...
> ...
>
> }
>
>
> This callback will help the cases:
> - Allows drivers to selectively disable certain trips during
> init
> state
> or system resume where there can be spikes or always. int340x
> drivers
> can disable always.
This sounds really great. This is indeed can happen on system
resume,
before userspace process thaw.
> - Still give options for drivers to handle critical trip even
> if
> they
> are bound to user space governors. User space process may be
> dead,
> so
> still allow kernel to process graceful shutdown
To make the scenario happen, do we need a new sysfs to let
usespace
enable it with THERMAL_TRIP_ENABLED?
>>> This should be drivers call not user space.
>>
>> Understood. So after thermal_zone_device_register(), the driver can
>> decide to what to return on get_trip_temp().
> get_trip_status()
>
>> Let me work on a new patch if there's no other concern.
> Better to wait for confirmation from Daniel and others.
Daniel,
Do you like Srinivas' proposed solution?
I hope we can find a solution in upstream kernel soon.
Kai-Heng
>
> Thanks,
> Srinivas
>
>>
>> Kai-Heng
>>
>>> Thanks,
>>> Srinivas
sched: core.c:7270 Illegal context switch in RCU-bh read-side critical section! __alloc_pages_nodemask
While booting arm64 hikey board with stable-rc 5.9.13-rc1 the following warning
noticed. This is hard to reproduce.
Step to reproduce:
# Boot arm64 hikey device with stable-rc 5.9.13-rc1
# Since it is hard to reproduce you may notice this warning
Crash log :
--
[ 10.763081] [drm] Initialized kirin 1.0.0 20150718 for f410.ade
on minor 1
[ 10.764088] Bluetooth: hci0: change remote baud rate command in firmware
[[0;32m OK [0m] Started TEE Supplicant.
[ 10.791741] mmc_host mmc2: Bus speed (slot 0) = 2480Hz (slot
req 40Hz, actual 40HZ div = 31)
E/TC:0 tee_entry_std:545 Bad arg address 0x6b681000
[[0;32m OK [0m] Started Periodic Command Scheduler.
[ 10.846417] mmc_host mmc2: Bus speed (slot 0) = 2480Hz (slot
req 2500Hz, actual 2480HZ div = 0)
[ 10.887083]
[ 10.887087]
[ 10.887095] =
[ 10.887098] =
[ 10.887101] WARNING: bad unlock balance detected!
[ 10.887107] WARNING: suspicious RCU usage
[ 10.887112] 5.9.13-rc1 #1 Not tainted
[ 10.887120] 5.9.13-rc1 #1 Not tainted
[ 10.887122] -
[ 10.887129] systemd-udevd/306 is trying to release lock (
[ 10.887133] -
[ 10.887135] fs_reclaim) at:
[ 10.887144] /usr/src/kernel/kernel/sched/core.c:7270 Illegal
context switch in RCU-bh read-side critical section!
[ 10.887163] [] __alloc_pages_nodemask+0x250/0x4c0
[ 10.887166]
[ 10.887166] other info that might help us debug this:
[ 10.887166]
[ 10.887170] but there are no more locks to release!
[ 10.887175]
[ 10.887175] other info that might help us debug this:
[ 10.887179]
[ 10.887179] rcu_scheduler_active = 2, debug_locks = 0
[ 10.887182] 1 lock held by systemd-udevd/306:
[ 10.887189] 1 lock held by systemd-sysctl/342:
[ 10.887192] #0: 7474e518
[ 10.887199] #0:
[ 10.887202] (
[ 10.887209] 70c54708
[ 10.887212] >mmap_lock){}-{3:3}
[ 10.887219] (
[ 10.887228] , at: do_page_fault+0x168/0x420
[ 10.887230] >i_mutex_dir_key
[ 10.887235]
[ 10.887235] stack backtrace:
[ 10.887237] #3){}-{3:3}
[ 10.887246] CPU: 1 PID: 306 Comm: systemd-udevd Not tainted 5.9.13-rc1 #1
[ 10.887255] , at: iterate_dir+0x54/0x1d0
[ 10.887258] Hardware name: HiKey Development Board (DT)
[ 10.887264]
[ 10.887264] stack backtrace:
[ 10.887266] Call trace:
[ 10.887276] dump_backtrace+0x0/0x1f8
[ 10.887283] show_stack+0x2c/0x38
[ 10.887292] dump_stack+0xec/0x158
[ 10.887303] print_unlock_imbalance_bug+0xec/0xf0
[ 10.887311] lock_release+0x300/0x388
[ 10.887320] __alloc_pages_nodemask+0x268/0x4c0
[ 10.887329] alloc_pages_vma+0x90/0x240
[ 10.887338] handle_mm_fault+0x8d4/0x12f0
[ 10.887346] do_page_fault+0x1c4/0x420
[ 10.887353] do_translation_fault+0xb0/0xcc
[ 10.887363] do_mem_abort+0x50/0xb0
[ 10.887372] el1_abort+0x28/0x30
[ 10.887379] el1_sync_handler+0xc0/0xf0
[ 10.887386] el1_sync+0x7c/0x100
[ 10.887397] __arch_copy_to_user+0x1d8/0x310
[ 10.887407] copy_page_to_iter+0x110/0x3e8
[ 10.887416] generic_file_buffered_read+0x4b8/0xaa8
[ 10.887423] generic_file_read_iter+0xd4/0x168
[ 10.887432] blkdev_read_iter+0x50/0x78
[ 10.887442] new_sync_read+0x100/0x1a0
[ 10.887449] vfs_read+0x1b4/0x1d8
[ 10.887457] ksys_read+0x74/0xf8
[ 10.887465] __arm64_sys_read+0x24/0x30
[ 10.887472] el0_svc_common.constprop.3+0x7c/0x198
[ 10.887478] do_el0_svc+0x34/0xa0
[ 10.887486] el0_sync_handler+0x16c/0x210
[ 10.887492] el0_sync+0x140/0x180
[ 10.887504] CPU: 6 PID: 342 Comm: systemd-sysctl Not tainted 5.9.13-rc1 #1
[ 10.887510] Hardware name: HiKey Development Board (DT)
[ 10.887515] Call trace:
[ 10.887524] dump_backtrace+0x0/0x1f8
[ 10.887531] show_stack+0x2c/0x38
[ 10.887542] dump_stack+0xec/0x158
[ 10.887552] lockdep_rcu_suspicious+0xd4/0xf8
[ 10.887561] ___might_sleep+0x1e4/0x208
[ 10.887569] __might_sleep+0x54/0x90
[ 10.887577] __might_fault+0x58/0xa8
[ 10.887584] filldir64+0x1f0/0x488
[ 10.887593] call_filldir+0xb0/0x140
[ 10.887600] ext4_readdir+0x700/0x900
[ 10.887607] iterate_dir+0x88/0x1d0
[ 10.887615] __arm64_sys_getdents64+0x70/0x1a0
[ 10.887622] el0_svc_common.constprop.3+0x7c/0x198
[ 10.887629] do_el0_svc+0x34/0xa0
[ 10.887637] el0_sync_handler+0x16c/0x210
[ 10.887644] el0_sync+0x140/0x180
[ 10.912334] Console: switching to colour frame buffer device 256x72
Reported-by: Naresh Kamboju
Full boot log link,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.12-47-g1372e1af58d4/testrun/3538040/suite/linux-log-parser/test/check-kernel-warning-2012813/log
metadata:
git branch: linux-5.9.y
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit: 1372e1af58d410676db7917cc3484ca22d471623
git describe: v5.9.12-47-g1372e1af58d4
make_kernelversion: 5.9.13-rc1
Re: [PATCH v2 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1
On Sun, 2020-12-06 at 11:13 +0100, Bean Huo wrote:
> From: Bean Huo
>
> According to the JEDEC UFS 3.1 Spec, If
> fWriteBoosterBufferFlushDuringHibernate
> is set to one, the device flushes the WriteBooster Buffer data automatically
> whenever the link enters the hibernate (HIBERN8) state. While the flushing
> operation is in progress, the device should be kept in Active power mode.
> Currently, we set this flag during the UFSHCD probe stage, but we didn't deal
> with its programming failure. Even this failure is less likely to occur, but
> still it is possible.
> This patch is to add checkup of fWriteBoosterBufferFlushDuringHibernate
> setting,
> keep the device as "active power mode" only when this flag be successfully set
> to 1.
>
> Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime
> suspend")
> Signed-off-by: Bean Huo
> ---
> drivers/scsi/ufs/ufs.h| 2 ++
> drivers/scsi/ufs/ufshcd.c | 20 +++-
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> index d593edb48767..311d5f7a024d 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -530,6 +530,8 @@ struct ufs_dev_info {
> bool f_power_on_wp_en;
> /* Keeps information if any of the LU is power on write protected */
> bool is_lu_power_on_wp;
> + /* Indicates if flush WB buffer during hibern8 successfully enabled */
> + bool is_hibern8_wb_flush;
Perhaps a more comprehensive name?
For example, wb_flush_during_hibern8?
> /* Maximum number of general LU supported by the UFS device */
> u8 max_lu_supported;
> u8 wb_dedicated_lu;
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 30332592e624..da38d760944b 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -285,10 +285,16 @@ static inline void ufshcd_wb_config(struct ufs_hba *hba)
> dev_err(hba->dev, "%s: Enable WB failed: %d\n", __func__, ret);
> else
> dev_info(hba->dev, "%s: Write Booster Configured\n", __func__);
> +
> ret = ufshcd_wb_toggle_flush_during_h8(hba, true);
> - if (ret)
> + if (ret) {
> dev_err(hba->dev, "%s: En WB flush during H8: failed: %d\n",
> __func__, ret);
> + hba->dev_info.is_hibern8_wb_flush = false;
Perhaps this statement could be dummy because
hba->dev_info.is_hibern8_wb_flush is zero-initialized and
ufshcd_wb_config() is invoked only once during ufs initialization.
Thanks,
Stanley Chu
> + } else {
> + hba->dev_info.is_hibern8_wb_flush = true;
> + }
> +
> ufshcd_wb_toggle_flush(hba, true);
> }
>
> @@ -5448,6 +5454,7 @@ static bool ufshcd_wb_need_flush(struct ufs_hba *hba)
>
> if (!ufshcd_is_wb_allowed(hba))
> return false;
> +
> /*
>* The ufs device needs the vcc to be ON to flush.
>* With user-space reduction enabled, it's enough to enable flush
> @@ -8540,6 +8547,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum
> ufs_pm_op pm_op)
> enum ufs_pm_level pm_lvl;
> enum ufs_dev_pwr_mode req_dev_pwr_mode;
> enum uic_link_state req_link_state;
> + bool hibern8;
>
> hba->pm_op_in_progress = 1;
> if (!ufshcd_is_shutdown_pm(pm_op)) {
> @@ -8599,11 +8607,13 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum
> ufs_pm_op pm_op)
>* Hibern8, keep device power mode as "active power mode"
>* and VCC supply.
>*/
> + hibern8 = req_link_state == UIC_LINK_HIBERN8_STATE ||
> + (req_link_state == UIC_LINK_ACTIVE_STATE &&
> + ufshcd_is_auto_hibern8_enabled(hba));
> +
> hba->dev_info.b_rpm_dev_flush_capable =
> - hba->auto_bkops_enabled ||
> - (((req_link_state == UIC_LINK_HIBERN8_STATE) ||
> - ((req_link_state == UIC_LINK_ACTIVE_STATE) &&
> - ufshcd_is_auto_hibern8_enabled(hba))) &&
> + hba->auto_bkops_enabled || (hibern8 &&
> + hba->dev_info.is_hibern8_wb_flush &&
> ufshcd_wb_need_flush(hba));
> }
>
Re: [PATCH] Revert "xen: add helpers to allocate unpopulated memory"
On 06.12.20 18:22, Marek Marczykowski-Górecki wrote: This reverts commit 9e2369c06c8a181478039258a4598c1ddd2cadfa. On a Xen PV dom0, with NVME disk, this makes the dom0 crash when starting a domain. This looks like some bad interaction between xen-blkback and xen-scsiback has the same use pattern. NVME driver, both using ZONE_DEVICE. Since the author is on leave now, revert the change until proper solution is developed. The specific crash message is: general protection fault, probably for non-canonical address 0xdead0100: [#1] SMP NOPTI CPU: 1 PID: 134 Comm: kworker/u12:2 Not tainted 5.9.9-1.qubes.x86_64 #1 Hardware name: LENOVO 20M9CTO1WW/20M9CTO1WW, BIOS N2CET50W (1.33 ) 01/15/2020 Workqueue: dm-thin do_worker [dm_thin_pool] RIP: e030:nvme_map_data+0x300/0x3a0 [nvme] Code: b8 fe ff ff e9 a8 fe ff ff 4c 8b 56 68 8b 5e 70 8b 76 74 49 8b 02 48 c1 e8 33 83 e0 07 83 f8 04 0f 85 f2 fe ff ff 49 8b 42 08 <83> b8 d0 00 00 00 04 0f 85 e1 fe ff ff e9 38 fd ff ff 8b 55 70 be RSP: e02b:c900010e7ad8 EFLAGS: 00010246 RAX: dead0100 RBX: 1000 RCX: 8881a58f5000 RDX: 1000 RSI: RDI: 8881a679e000 RBP: 8881a5ef4c80 R08: 8881a5ef4c80 R09: 0002 R10: ea0003dfff40 R11: 0008 R12: 8881a679e000 R13: c900010e7b20 R14: 8881a70b5980 R15: 8881a679e000 FS: () GS:8881b544() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 01d64408 CR3: 0001aa2c CR4: 00050660 Call Trace: nvme_queue_rq+0xa7/0x1a0 [nvme] __blk_mq_try_issue_directly+0x11d/0x1e0 ? add_wait_queue_exclusive+0x70/0x70 blk_mq_try_issue_directly+0x35/0xc0l[ blk_mq_submit_bio+0x58f/0x660 __submit_bio_noacct+0x300/0x330 process_shared_bio+0x126/0x1b0 [dm_thin_pool] process_cell+0x226/0x280 [dm_thin_pool] process_thin_deferred_cells+0x185/0x320 [dm_thin_pool] process_deferred_bios+0xa4/0x2a0 [dm_thin_pool]UX do_worker+0xcc/0x130 [dm_thin_pool] process_one_work+0x1b4/0x370 worker_thread+0x4c/0x310 ? process_one_work+0x370/0x370 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60< ret_from_fork+0x22/0x30 Modules linked in: loop snd_seq_dummy snd_hrtimer nf_tables nfnetlink vfat fat snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_soc_skl snd_soc_sst_ ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine elan_i2c snd_hda_codec_hdmi mei_hdcp iTCO_wdt intel_powerclamp intel_pmc_bxt ee1004 intel_rapl_msr iTCO_vendor _support joydev pcspkr intel_wmi_thunderbolt wmi_bmof thunderbolt ucsi_acpi idma64 typec_ucsi snd_hda_codec_realtek typec snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec thinkpad_acpi snd_hda_core ledtrig_audio int3403_ thermal snd_hwdep snd_seq snd_seq_device snd_pcm iwlwifi snd_timer processor_thermal_device mei_me cfg80211 intel_rapl_common snd e1000e mei int3400_thermal int340x_thermal_zone i2c_i801 acpi_thermal_rel soundcore intel_soc_dts_iosf i2c_s mbus rfkill intel_pch_thermal xenfs ip_tables dm_thin_pool dm_persistent_data dm_bio_prison dm_crypt nouveau rtsx_pci_sdmmc mmc_core mxm_wmi crct10dif_pclmul ttm crc32_pclmul crc32c_intel i915 ghash_clmulni_intel i2c_algo_bit serio_raw nvme drm_kms_helper cec xhci_pci nvme _core rtsx_pci xhci_pci_renesas drm xhci_hcd wmi video pinctrl_cannonlake pinctrl_intel xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn uinput ---[ end trace f8d47e4aa6724df4 ]--- RIP: e030:nvme_map_data+0x300/0x3a0 [nvme] Code: b8 fe ff ff e9 a8 fe ff ff 4c 8b 56 68 8b 5e 70 8b 76 74 49 8b 02 48 c1 e8 33 83 e0 07 83 f8 04 0f 85 f2 fe ff ff 49 8b 42 08 <83> b8 d0 00 00 00 04 0f 85 e1 fe ff ff e9 38 fd ff ff 8b 55 70 be RSP: e02b:c900010e7ad8 EFLAGS: 00010246 RAX: dead0100 RBX: 1000 RCX: 8881a58f5000 RDX: 1000 RSI: RDI: 8881a679e000 RBP: 8881a5ef4c80 R08: 8881a5ef4c80 R09: 0002 R10: ea0003dfff40 R11: 0008 R12: 8881a679e000 R13: c900010e7b20 R14: 8881a70b5980 R15: 8881a679e000 FS: () GS:8881b544() knlGS: CS: e030 DS: ES: CR0: 80050033 CR2: 01d64408 CR3: 0001aa2c CR4: 00050660 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Discussion at https://lore.kernel.org/xen-devel/20201205082839.ts3ju6yta46cgwjn@Air-de-Roger/T Cc: sta...@vger.kernel.org #v5.9+ (for 5.9 it's easier to revert the original commit directly)
Re: [PATCH v3 19/19] vdpa: split vdpasim to core and net modules
On 2020/12/4 上午1:05, Stefano Garzarella wrote: From: Max Gurtovoy Introduce new vdpa_sim_net and vdpa_sim (core) drivers. This is a preparation for adding a vdpa simulator module for block devices. Signed-off-by: Max Gurtovoy [sgarzare: various cleanups/fixes] Signed-off-by: Stefano Garzarella --- v2: - Fixed "warning: variable 'dev' is used uninitialized" reported by 'kernel test robot' and Dan Carpenter - rebased on top of other changes (dev_attr, get_config(), notify(), etc.) - left batch_mapping module parameter in the core [Jason] v1: - Removed unused headers - Removed empty module_init() module_exit() - Moved vdpasim_is_little_endian() in vdpa_sim.h - Moved vdpasim16_to_cpu/cpu_to_vdpasim16() in vdpa_sim.h - Added vdpasim*_to_cpu/cpu_to_vdpasim*() also for 32 and 64 - Replaced 'select VDPA_SIM' with 'depends on VDPA_SIM' since selected option can not depend on other [Jason] --- drivers/vdpa/vdpa_sim/vdpa_sim.h | 105 + drivers/vdpa/vdpa_sim/vdpa_sim.c | 224 +-- drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 171 drivers/vdpa/Kconfig | 13 +- drivers/vdpa/vdpa_sim/Makefile | 1 + 5 files changed, 292 insertions(+), 222 deletions(-) create mode 100644 drivers/vdpa/vdpa_sim/vdpa_sim.h create mode 100644 drivers/vdpa/vdpa_sim/vdpa_sim_net.c Acked-by: Jason Wang
Re: [PATCH v3 15/19] vdpa_sim: set vringh notify callback
On 2020/12/4 上午1:05, Stefano Garzarella wrote:
Instead of calling the vq callback directly, we can leverage the
vringh_notify() function, adding vdpasim_vq_notify() and setting it
in the vringh notify callback.
Suggested-by: Jason Wang
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
v3:
- cleared notify during reset [Jason]
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 03a8717f80ea..1243b02488f7 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -123,6 +123,17 @@ static struct vdpasim *dev_to_sim(struct device *dev)
return vdpa_to_sim(vdpa);
}
+static void vdpasim_vq_notify(struct vringh *vring)
+{
+ struct vdpasim_virtqueue *vq =
+ container_of(vring, struct vdpasim_virtqueue, vring);
+
+ if (!vq->cb)
+ return;
+
+ vq->cb(vq->private);
+}
+
static void vdpasim_queue_ready(struct vdpasim *vdpasim, unsigned int idx)
{
struct vdpasim_virtqueue *vq = >vqs[idx];
@@ -134,6 +145,8 @@ static void vdpasim_queue_ready(struct vdpasim *vdpasim,
unsigned int idx)
(uintptr_t)vq->driver_addr,
(struct vring_used *)
(uintptr_t)vq->device_addr);
+
+ vq->vring.notify = vdpasim_vq_notify;
}
static void vdpasim_vq_reset(struct vdpasim *vdpasim,
@@ -147,6 +160,8 @@ static void vdpasim_vq_reset(struct vdpasim *vdpasim,
vq->private = NULL;
vringh_init_iotlb(>vring, vdpasim->dev_attr.supported_features,
VDPASIM_QUEUE_MAX, false, NULL, NULL, NULL);
+
+ vq->vring.notify = NULL;
}
static void vdpasim_reset(struct vdpasim *vdpasim)
@@ -223,10 +238,10 @@ static void vdpasim_net_work(struct work_struct *work)
smp_wmb();
local_bh_disable();
- if (txq->cb)
- txq->cb(txq->private);
- if (rxq->cb)
- rxq->cb(rxq->private);
+ if (vringh_need_notify_iotlb(>vring) > 0)
+ vringh_notify(>vring);
+ if (vringh_need_notify_iotlb(>vring) > 0)
+ vringh_notify(>vring);
local_bh_enable();
if (++pkts > 4) {
Re: [PATCH v3 14/19] vdpa_sim: add set_config callback in vdpasim_dev_attr
On 2020/12/4 上午1:05, Stefano Garzarella wrote:
The set_config callback can be used by the device to parse the
config structure modified by the driver.
The callback will be invoked, if set, in vdpasim_set_config() after
copying bytes from caller buffer into vdpasim->config buffer.
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index f935ade0806b..03a8717f80ea 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -70,6 +70,7 @@ struct vdpasim_dev_attr {
work_func_t work_fn;
void (*get_config)(struct vdpasim *vdpasim, void *config);
+ void (*set_config)(struct vdpasim *vdpasim, const void *config);
};
/* State of each vdpasim device */
@@ -598,7 +599,15 @@ static void vdpasim_get_config(struct vdpa_device *vdpa,
unsigned int offset,
static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,
const void *buf, unsigned int len)
{
- /* No writable config supportted by vdpasim */
+ struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+
+ if (offset + len > vdpasim->dev_attr.config_size)
+ return;
+
+ memcpy(vdpasim->config + offset, buf, len);
+
+ if (vdpasim->dev_attr.set_config)
+ vdpasim->dev_attr.set_config(vdpasim, vdpasim->config);
}
static u32 vdpasim_get_generation(struct vdpa_device *vdpa)
Re: [PATCH v3 13/19] vdpa_sim: add get_config callback in vdpasim_dev_attr
On 2020/12/4 上午1:05, Stefano Garzarella wrote:
The get_config callback can be used by the device to fill the
config structure.
The callback will be invoked in vdpasim_get_config() before copying
bytes into caller buffer.
Move vDPA-net config updates from vdpasim_set_features() in the
new vdpasim_net_get_config() callback.
Signed-off-by: Stefano Garzarella
---
v3:
- checked if get_config callback is set before call it
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 35 +++-
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index fe71ed7890e1..f935ade0806b 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -60,6 +60,8 @@ struct vdpasim_virtqueue {
#define VDPASIM_NET_FEATURES (VDPASIM_FEATURES | \
(1ULL << VIRTIO_NET_F_MAC))
+struct vdpasim;
+
struct vdpasim_dev_attr {
u64 supported_features;
size_t config_size;
@@ -67,6 +69,7 @@ struct vdpasim_dev_attr {
u32 id;
work_func_t work_fn;
+ void (*get_config)(struct vdpasim *vdpasim, void *config);
};
/* State of each vdpasim device */
@@ -522,8 +525,6 @@ static u64 vdpasim_get_features(struct vdpa_device *vdpa)
static int vdpasim_set_features(struct vdpa_device *vdpa, u64 features)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
- struct virtio_net_config *config =
- (struct virtio_net_config *)vdpasim->config;
/* DMA mapping must be done by driver */
if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
@@ -531,16 +532,6 @@ static int vdpasim_set_features(struct vdpa_device *vdpa,
u64 features)
vdpasim->features = features & vdpasim->dev_attr.supported_features;
- /* We generally only know whether guest is using the legacy interface
-* here, so generally that's the earliest we can set config fields.
-* Note: We actually require VIRTIO_F_ACCESS_PLATFORM above which
-* implies VIRTIO_F_VERSION_1, but let's not try to be clever here.
-*/
-
- config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
- config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
- memcpy(config->mac, macaddr_buf, ETH_ALEN);
Patch looks good to me.
But we need Michael to confirm whether doing moving like this is safe. I
guess what has been done were trying to make sure get_config() fail
before set_features(), but it's not clear to me whether it's useful.
Thanks
-
return 0;
}
@@ -595,8 +586,13 @@ static void vdpasim_get_config(struct vdpa_device *vdpa, unsigned int offset,
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
- if (offset + len < vdpasim->dev_attr.config_size)
- memcpy(buf, vdpasim->config + offset, len);
+ if (offset + len > vdpasim->dev_attr.config_size)
+ return;
+
+ if (vdpasim->dev_attr.get_config)
+ vdpasim->dev_attr.get_config(vdpasim, vdpasim->config);
+
+ memcpy(buf, vdpasim->config + offset, len);
}
static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,
@@ -739,6 +735,16 @@ static const struct vdpa_config_ops
vdpasim_batch_config_ops = {
.free = vdpasim_free,
};
+static void vdpasim_net_get_config(struct vdpasim *vdpasim, void *config)
+{
+ struct virtio_net_config *net_config =
+ (struct virtio_net_config *)config;
+
+ net_config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
+ net_config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
+ memcpy(net_config->mac, macaddr_buf, ETH_ALEN);
+}
+
static int __init vdpasim_dev_init(void)
{
struct vdpasim_dev_attr dev_attr = {};
@@ -747,6 +753,7 @@ static int __init vdpasim_dev_init(void)
dev_attr.supported_features = VDPASIM_NET_FEATURES;
dev_attr.nvqs = VDPASIM_VQ_NUM;
dev_attr.config_size = sizeof(struct virtio_net_config);
+ dev_attr.get_config = vdpasim_net_get_config;
dev_attr.work_fn = vdpasim_net_work;
vdpasim_dev = vdpasim_create(_attr);
Re: [PATCH] clk: imx: Fix reparenting of UARTs not associated with sdout
Hi Adam,
On Fri, Dec 04, 2020 at 12:31:54PM -0600, Adam Ford wrote:
> The default clock source on i.MX8M Mini and Nano boards use a 24MHz clock,
> but users who need to re-parent the clock source run into issues because
> all the UART clocks are enabled whether or not they're needed by sdout.
>
> Any attempt to change the parent results in an busy error because the
> clocks have been enabled already.
>
> clk: failed to reparent uart1 to sys_pll1_80m: -16
>
> Instead of pre-initializing all UARTS, scan the device tree to see if UART
> clock is used as stdout before initializing it. Only enable the UART clock
> if it's needed in order to delay the clock initialization until after the
> re-parenting of the clocks.
>
> Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
> Suggested-by: Aisheng Dong
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
> index 47882c51cb85..6dcc5fbd8f3f 100644
> --- a/drivers/clk/imx/clk.c
> +++ b/drivers/clk/imx/clk.c
> @@ -163,12 +163,18 @@ __setup_param("earlyprintk", imx_keep_uart_earlyprintk,
>
> void imx_register_uart_clocks(struct clk ** const clks[])
> {
> + struct clk *uart_clk;
> if (imx_keep_uart_clocks) {
> int i;
>
> imx_uart_clocks = clks;
> - for (i = 0; imx_uart_clocks[i]; i++)
> - clk_prepare_enable(*imx_uart_clocks[i]);
> + for (i = 0; imx_uart_clocks[i]; i++) {
> + uart_clk = of_clk_get(of_stdout, i);
This looks wrong. imx_uart_clocks is an array containing all clocks that
could possibly be used for an UART. With of_clk_get(of_stdout, i) you
get the nth clock for one specific UART.
What you have to do here is: For each of imx_uart_clocks[] you have to
iterate over all clocks of the of_stdout node.
Sascha
> + if (IS_ERR(uart_clk))
> + continue;
> + clk_prepare_enable(uart_clk);
> + clk_put(uart_clk);
> + }
> }
> }
>
> --
> 2.25.1
>
>
--
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: [PATCH v3 12/19] vdpa_sim: make 'config' generic and usable for any device type
On 2020/12/4 上午1:05, Stefano Garzarella wrote:
Add new 'config_size' attribute in 'vdpasim_dev_attr' and allocates
'config' dynamically to support any device types.
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 949f4231d08a..fe71ed7890e1 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -62,6 +62,7 @@ struct vdpasim_virtqueue {
struct vdpasim_dev_attr {
u64 supported_features;
+ size_t config_size;
int nvqs;
u32 id;
@@ -76,7 +77,8 @@ struct vdpasim {
struct vdpasim_dev_attr dev_attr;
/* spinlock to synchronize virtqueue state */
spinlock_t lock;
- struct virtio_net_config config;
+ /* virtio config according to device type */
+ void *config;
struct vhost_iotlb *iommu;
void *buffer;
u32 status;
@@ -376,6 +378,10 @@ static struct vdpasim *vdpasim_create(struct
vdpasim_dev_attr *dev_attr)
goto err_iommu;
set_dma_ops(dev, _dma_ops);
+ vdpasim->config = kzalloc(dev_attr->config_size, GFP_KERNEL);
+ if (!vdpasim->config)
+ goto err_iommu;
+
vdpasim->vqs = kcalloc(dev_attr->nvqs, sizeof(struct vdpasim_virtqueue),
GFP_KERNEL);
if (!vdpasim->vqs)
@@ -516,7 +522,8 @@ static u64 vdpasim_get_features(struct vdpa_device *vdpa)
static int vdpasim_set_features(struct vdpa_device *vdpa, u64 features)
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
- struct virtio_net_config *config = >config;
+ struct virtio_net_config *config =
+ (struct virtio_net_config *)vdpasim->config;
/* DMA mapping must be done by driver */
if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
@@ -588,8 +595,8 @@ static void vdpasim_get_config(struct vdpa_device *vdpa,
unsigned int offset,
{
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
- if (offset + len < sizeof(struct virtio_net_config))
- memcpy(buf, (u8 *)>config + offset, len);
+ if (offset + len < vdpasim->dev_attr.config_size)
+ memcpy(buf, vdpasim->config + offset, len);
}
static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,
@@ -676,6 +683,7 @@ static void vdpasim_free(struct vdpa_device *vdpa)
if (vdpasim->iommu)
vhost_iotlb_free(vdpasim->iommu);
kfree(vdpasim->vqs);
+ kfree(vdpasim->config);
}
static const struct vdpa_config_ops vdpasim_config_ops = {
@@ -738,6 +746,7 @@ static int __init vdpasim_dev_init(void)
dev_attr.id = VIRTIO_ID_NET;
dev_attr.supported_features = VDPASIM_NET_FEATURES;
dev_attr.nvqs = VDPASIM_VQ_NUM;
+ dev_attr.config_size = sizeof(struct virtio_net_config);
dev_attr.work_fn = vdpasim_net_work;
vdpasim_dev = vdpasim_create(_attr);
Re: [PATCH] Fixes kernel crash generating from bam_dma_irq()
Hi Parth,
On 06-12-20, 15:51, Parth Y Shah wrote:
> While performing suspend/resume, we were getting below kernel crash.
>
> [ 54.541672] [FTS][Info]gesture suspend...
> [ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed!
> [ 54.605256]
> [ 58.345850] irq event 10: bogus return value fff3
> ..
>
> [ 58.345966] [] el1_irq+0xb0/0x124
> [ 58.345971] [] arch_cpu_idle+0x10/0x18
> [ 58.345975] [] do_idle+0x1ac/0x1e0
> [ 58.345979] [] cpu_startup_entry+0x20/0x28
> [ 58.345983] [] rest_init+0xd0/0xdc
> [ 58.345988] [] start_kernel+0x390/0x3a4
> [ 58.345990] handlers:
> [ 58.345994] [] bam_dma_irq
>
> The reason for the crash we found is, bam_dma_irq() was returning
> negative value when the device resumes in some conditions.
>
> In addition, the irq handler should have one of the below return values.
>
> IRQ_NONEinterrupt was not from this device or was not handled
> IRQ_HANDLED interrupt was handled by this device
> IRQ_WAKE_THREAD handler requests to wake the handler thread
>
> Therefore, to resolve this crash, we have changed the return value to
> IRQ_NONE.
The change and explanation look good to me, unfortunately the patch
title is incorrect. It describes the fix it does and not the change in
this patch. Also do add subsystem and driver tags to the patch! git log
would tell you this information
Consider: "dmaengine: bam_dma: fix return of bam_dma_irq()" as a
suggestion.
>
> Signed-off-by: Parth Y Shah
> ---
> drivers/dma/qcom/bam_dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 4eeb8bb..d5773d4 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -875,7 +875,7 @@ static irqreturn_t bam_dma_irq(int irq, void *data)
>
> ret = bam_pm_runtime_get_sync(bdev->dev);
Also this looks wrong to me. get_sync() can sleep and we cant invoke
that in an irq. Srini have you seen this issue
> if (ret < 0)
> - return ret;
> + return IRQ_NONE;
>
> if (srcs & BAM_IRQ) {
> clr_mask = readl_relaxed(bam_addr(bdev, 0, BAM_IRQ_STTS));
> --
> 2.7.4
--
~Vinod
Re: [PATCH v2 3/3] scsi: ufs: Changes comment in the function ufshcd_wb_probe()
On Sun, 2020-12-06 at 11:13 +0100, Bean Huo wrote: > From: Bean Huo > > USFHCD supports WriteBooster "LU dedicated buffer” mode and > “shared buffer” mode both, so changes the comment in the > function ufshcd_wb_probe(). > > Signed-off-by: Bean Huo > Reviewed-by: Can Guo Reviewed-by: Stanley Chu
Re: [PATCH] vhost scsi: fix error return code in vhost_scsi_set_endpoint()
On 2020/12/4 下午4:43, Zhang Changzhong wrote:
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session")
Reported-by: Hulk Robot
Signed-off-by: Zhang Changzhong
---
drivers/vhost/scsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 6ff8a5096..4ce9f00 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1643,7 +1643,8 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs,
if (!vhost_vq_is_setup(vq))
continue;
- if (vhost_scsi_setup_vq_cmds(vq, vq->num))
+ ret = vhost_scsi_setup_vq_cmds(vq, vq->num);
+ if (ret)
goto destroy_vq_cmds;
}
Acked-by: Jason Wang
[GIT PULL]: soundwire updates for v5.11-rc1
Hello Greg, Please pull to receive updates for v5.11 as detailed below: The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git tags/soundwire-5.11-rc1 for you to fetch changes up to 17e0da0b8979a53977f684813f5c9db817d170e2: soundwire: intel: fix another unused-function warning (2020-12-05 13:11:54 +0530) soundwire updates for 5.11-rc1 Updates for last PR for this year contain: - Improvements from Intel for port interrupt handling - SDCA cascade interrupt support - runtime pm for master device Arnd Bergmann (1): soundwire: intel: fix another unused-function warning Pierre-Louis Bossart (7): soundwire: SDCA: detect sdca_cascade interrupt soundwire: bus: add comments to explain interrupt loop filter soundwire: bus: reset slave_notify status at each loop soundwire: registers: add definitions for clearable interrupt fields soundwire: bus: only clear valid DP0 interrupts soundwire: bus: only clear valid DPN interrupts soundwire: master: use pm_runtime_set_active() on add Srinivas Kandagatla (1): soundwire: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute Vinod Koul (1): soundwire: qcom: Fix build failure when slimbus is module drivers/soundwire/bus.c | 55 +++-- drivers/soundwire/intel.c | 8 ++--- drivers/soundwire/master.c | 14 + drivers/soundwire/qcom.c| 2 +- drivers/soundwire/sysfs_slave_dpn.c | 1 + include/linux/soundwire/sdw.h | 4 +++ include/linux/soundwire/sdw_registers.h | 11 +++ 7 files changed, 79 insertions(+), 16 deletions(-) Thanks -- ~Vinod signature.asc Description: PGP signature
[PATCH 0/1] dt-bindings: clock: imx8qxp-lpcg: eliminate yamllint warnings
This patch is based on the latest linux-next code. Zhen Lei (1): dt-bindings: clock: imx8qxp-lpcg: eliminate yamllint warnings .../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) -- 1.8.3
[PATCH 1/1] dt-bindings: clock: imx8qxp-lpcg: eliminate yamllint warnings
Eliminate the following yamllint warnings: ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml :32:13:[warning] wrong indentation: expected 14 but found 12 (indentation) :35:9: [warning] wrong indentation: expected 10 but found 8 (indentation) Signed-off-by: Zhen Lei --- .../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index e709e530e17a27a..940486ef1051d10 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -29,18 +29,18 @@ properties: - const: fsl,imx8qxp-lpcg - items: - enum: -- fsl,imx8qm-lpcg + - fsl,imx8qm-lpcg - const: fsl,imx8qxp-lpcg - enum: -- fsl,imx8qxp-lpcg-adma -- fsl,imx8qxp-lpcg-conn -- fsl,imx8qxp-lpcg-dc -- fsl,imx8qxp-lpcg-dsp -- fsl,imx8qxp-lpcg-gpu -- fsl,imx8qxp-lpcg-hsio -- fsl,imx8qxp-lpcg-img -- fsl,imx8qxp-lpcg-lsio -- fsl,imx8qxp-lpcg-vpu + - fsl,imx8qxp-lpcg-adma + - fsl,imx8qxp-lpcg-conn + - fsl,imx8qxp-lpcg-dc + - fsl,imx8qxp-lpcg-dsp + - fsl,imx8qxp-lpcg-gpu + - fsl,imx8qxp-lpcg-hsio + - fsl,imx8qxp-lpcg-img + - fsl,imx8qxp-lpcg-lsio + - fsl,imx8qxp-lpcg-vpu deprecated: true reg: maxItems: 1 -- 1.8.3
Re: [PATCH v6 0/6] Tegra210 audio graph card
Hi Mark, This series adds audio graph based sound card support for Tegra210 platforms like Jetson-TX1 an Jetson-Nano. The following preparatory audio graph enhancement series is already merged. * https://patchwork.kernel.org/project/alsa-devel/list/?series=375629=* Following are the summary of changes: * Add graph/audio-graph based schemas or schema updates for Tegra210 component and machine drivers. * Add Tegra audio graph machine driver. * Add required DT support for Jetson-TX1/Nano. [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: dt-bindings: tegra: Add graph bindings (no commit info) [2/3] ASoC: dt-bindings: tegra: Add json-schema for Tegra audio graph card (no commit info) [3/3] ASoC: tegra: Add audio graph based card driver (no commit info) I don't see above patches in linux-next yet. Should I wait some more time for this to appear? Thanks, Sameer.
[PATCH v2 1/1] dt-bindings: display: eliminate yamllint warnings
Eliminate the following yamllint warnings: ./Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml :52:9: [warning] wrong indentation: expected 6 but found 8 (indentation) ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml :42:8: [warning] wrong indentation: expected 8 but found 7 (indentation) :45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml :21:6: [warning] wrong indentation: expected 6 but found 5 (indentation) ./Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml :25:10: [warning] wrong indentation: expected 10 but found 9 (indentation) Signed-off-by: Zhen Lei Acked-by: Sam Ravnborg --- .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 ++-- .../devicetree/bindings/display/bridge/intel,keembay-dsi.yaml | 4 ++-- Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml | 4 ++-- Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 60585a4fc22bc9f..9392b5502a3293c 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -49,8 +49,8 @@ properties: Video port for panel or connector. required: -- port@0 -- port@1 + - port@0 + - port@1 required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml index ab5be26252240ea..35c9dfd866501a0 100644 --- a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml @@ -39,10 +39,10 @@ properties: properties: '#address-cells': - const: 1 +const: 1 '#size-cells': - const: 0 +const: 0 port@0: type: object diff --git a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml index 40caa61188098c2..a222b52d8b8ff6b 100644 --- a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml +++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml @@ -18,8 +18,8 @@ description: | properties: compatible: items: - - const: intel,keembay-msscam - - const: syscon + - const: intel,keembay-msscam + - const: syscon reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index d2170de6b72302f..2f5df1d235aea8a 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -22,7 +22,7 @@ properties: compatible: items: - enum: - - tianma,fhd-video + - tianma,fhd-video - const: novatek,nt36672a description: This indicates the panel manufacturer of the panel that is in turn using the NT36672A panel driver. This compatible string -- 1.8.3
[PATCH v2 0/1] dt-bindings: display: eliminate yamllint warnings
This patch is based on the latest linux-next code. v1 --> v2: Extract the modification of the Documentation/devicetree/bindings/display/ parts and send the patch separately. https://www.spinics.net/lists/arm-kernel/msg860713.html v1: There're too many people, I just send to the maintainer, reviewer, supporter. Eliminate below warnings: ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml:32:13: [warning] wrong indentation: expected 14 but found 12 (indentation) ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml:35:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml:21:6: [warning] wrong indentation: expected 6 but found 5 (indentation) ./Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml:52:9: [warning] wrong indentation: expected 6 but found 8 (indentation) ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml:42:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml:45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) ./Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml:25:10: [warning] wrong indentation: expected 10 but found 9 (indentation) ./Documentation/devicetree/bindings/media/i2c/adv7604.yaml:24:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: [error] missing document start "---" (document-start) ./Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:29:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:32:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml:79:17: [warning] wrong indentation: expected 14 but found 16 (indentation) ./Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml:88:17: [warning] wrong indentation: expected 14 but found 16 (indentation) ./Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml:72:17: [warning] wrong indentation: expected 18 but found 16 (indentation) ./Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml:75:17: [warning] wrong indentation: expected 18 but found 16 (indentation) ./Documentation/devicetree/bindings/mmc/mtk-sd.yaml:20:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/mmc/mtk-sd.yaml:30:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/mmc/mtk-sd.yaml:33:9: [warning] wrong indentation: expected 10 but found 8 (indentation) ./Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml:10:4: [warning] wrong indentation: expected 2 but found 3 (indentation) Zhen Lei (1): dt-bindings: display: eliminate yamllint warnings .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 ++-- .../devicetree/bindings/display/bridge/intel,keembay-dsi.yaml | 4 ++-- Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml | 4 ++-- Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) -- 1.8.3
