Re: [PATCH 02/10] fpga: fpga-mgr: altera-ps-spi: Simplify registration
On 10/3/20 10:14 PM, Moritz Fischer wrote: > Simplify registration by using new devm_fpga_mgr_register() API. > > Signed-off-by: Moritz Fischer > --- > drivers/fpga/altera-ps-spi.c | 14 +- > 1 file changed, 1 insertion(+), 13 deletions(-) Looks fine Reviewed-by: Tom Rix
Re: [PATCH 01/10] fpga: fpga-mgr: Add devm_fpga_mgr_register() API
On 10/3/20 10:14 PM, Moritz Fischer wrote:
> Add a devm_fpga_mgr_register() API that can be used to register a FPGA
> Manager that was created using devm_fpga_mgr_create().
>
> Introduce a struct fpga_mgr_devres that makes the devres
> allocation a little bit more readable and gets reused for
> devm_fpga_mgr_create() devm_fpga_mgr_register().
>
> Signed-off-by: Moritz Fischer
> ---
> drivers/fpga/fpga-mgr.c | 76 ++-
> include/linux/fpga/fpga-mgr.h | 2 +
> 2 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index f38bab01432e..774ac98fb69c 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -21,6 +21,10 @@
> static DEFINE_IDA(fpga_mgr_ida);
> static struct class *fpga_mgr_class;
>
> +struct fpga_mgr_devres {
> + struct fpga_manager *mgr;
> +};
> +
> /**
> * fpga_image_info_alloc - Allocate a FPGA image info struct
> * @dev: owning device
> @@ -651,21 +655,21 @@ struct fpga_manager *devm_fpga_mgr_create(struct device
> *dev, const char *name,
> const struct fpga_manager_ops *mops,
> void *priv)
> {
> - struct fpga_manager **ptr, *mgr;
> + struct fpga_mgr_devres *dr;
>
> - ptr = devres_alloc(devm_fpga_mgr_release, sizeof(*ptr), GFP_KERNEL);
> - if (!ptr)
> + dr = devres_alloc(devm_fpga_mgr_release, sizeof(*dr), GFP_KERNEL);
> + if (!dr)
> return NULL;
>
> - mgr = fpga_mgr_create(dev, name, mops, priv);
> - if (!mgr) {
> - devres_free(ptr);
> - } else {
> - *ptr = mgr;
> - devres_add(dev, ptr);
> + dr->mgr = fpga_mgr_create(dev, name, mops, priv);
> + if (!dr->mgr) {
> + devres_free(dr);
> + return NULL;
> }
>
> - return mgr;
> + devres_add(dev, dr);
> +
> + return dr->mgr;
> }
> EXPORT_SYMBOL_GPL(devm_fpga_mgr_create);
>
> @@ -722,6 +726,58 @@ void fpga_mgr_unregister(struct fpga_manager *mgr)
> }
> EXPORT_SYMBOL_GPL(fpga_mgr_unregister);
>
> +static int fpga_mgr_devres_match(struct device *dev, void *priv,
> + void *match_data)
> +{
> + struct fpga_mgr_devres *dr = priv;
> +
> + return match_data == dr->mgr;
> +}
> +
> +static void devm_fpga_mgr_unregister(struct device *dev, void *priv)
> +{
> + struct fpga_mgr_devres *dr = priv;
> +
> + fpga_mgr_unregister(dr->mgr);
> +}
> +
> +/**
> + * devm_fpga_mgr_register - resource managed variant of fpga_mgr_register()
> + * @dev: managing device for this FPGA manager
> + * @mgr: fpga manager struct
> + *
> + * This is the devres variant of fpga_mgr_register() for which the unregister
> + * function will be called automatically when the managing device is
> detached.
> + */
> +int devm_fpga_mgr_register(struct device *dev, struct fpga_manager *mgr)
> +{
> + struct fpga_mgr_devres *dr;
> + int err;
nit
int ret;
Fine if it isn't changed.
Reviewed-by: Tom Rix
> +
> + /* Make sure that the struct fpga_manager * that is passed in is
> + * managed itself.
> + */
> + if (WARN_ON(!devres_find(dev, devm_fpga_mgr_release,
> + fpga_mgr_devres_match, mgr)))
> + return -EINVAL;
> +
> + dr = devres_alloc(devm_fpga_mgr_unregister, sizeof(*dr), GFP_KERNEL);
> + if (!dr)
> + return -ENOMEM;
> +
> + err = fpga_mgr_register(mgr);
> + if (err) {
> + devres_free(dr);
> + return err;
> + }
> +
> + dr->mgr = mgr;
> + devres_add(dev, dr);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(devm_fpga_mgr_register);
> +
> static void fpga_mgr_dev_release(struct device *dev)
> {
> }
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index e8ca62b2cb5b..2bc3030a69e5 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -198,6 +198,8 @@ void fpga_mgr_free(struct fpga_manager *mgr);
> int fpga_mgr_register(struct fpga_manager *mgr);
> void fpga_mgr_unregister(struct fpga_manager *mgr);
>
> +int devm_fpga_mgr_register(struct device *dev, struct fpga_manager *mgr);
> +
> struct fpga_manager *devm_fpga_mgr_create(struct device *dev, const char
> *name,
> const struct fpga_manager_ops *mops,
> void *priv);
Re: [RFC][PATCHSET] epoll cleanups
On Sat, Oct 3, 2020 at 7:36 PM Al Viro wrote: > > Locking and especially control flow in fs/eventpoll.c is > overcomplicated. As the result, the code has been hard to follow > and easy to fuck up while modifying. Scanning through the patches they all look superficially ok to me, but I'm wondering how much test coverage you have (because I'm wondering how much test coverage we have in general for epoll). But I'm certainly not in the least against trying to make the epoll code more straightforward and understandable. Linus
Re: [PATCH v2 2/6] fpga: m10bmc-sec: create max10 bmc security engine
On 10/4/20 11:01 AM, Russ Weight wrote: > > > On 10/2/20 8:15 PM, Randy Dunlap wrote: >> On 10/2/20 6:24 PM, Russ Weight wrote: >>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig >>> index c534cc80f398..2380d36b08c7 100644 >>> --- a/drivers/fpga/Kconfig >>> +++ b/drivers/fpga/Kconfig >>> @@ -235,4 +235,15 @@ config IFPGA_SEC_MGR >>> region and for the BMC. Select this option to enable >>> updates for secure FPGA devices. >>> >>> +config IFPGA_M10_BMC_SECURE >>> +tristate "Intel MAX10 BMC security engine" >>> + depends on MFD_INTEL_M10_BMC && IFPGA_SEC_MGR >>> +help >>> + Secure update support for the Intel MAX10 board management >>> + controller. >>> + >>> + This is a subdriver of the Intel MAX10 board management controller >>> + (BMC) and provides support for secure updates for the BMC image, >>> + the FPGA image, the Root Entry Hashes, etc. >>> + >>> endif # FPGA >> Dagnabit, I need a bot to do this. >> >> Clean up the indentation in the Kconfig file. >> >> From Documentation/process/coding-style.rst, section 10: >> >> Lines under a ``config`` definition >> are indented with one tab, while help text is indented an additional two >> spaces. >> >> checkpatch should have found that issue. Did it not? > Sorry - I thought I had addressed the indentation errors after the first > submission. > I'll fix it. > > I am running checkpatch.pl --strict, and I did not see a warning/error for > this. OK, I looked at checkpatch.pl and I don't see any checks for that. I'll just work on a pseudo-bot then. thanks. -- ~Randy
[PATCH 2/7] buffer: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 5417169026c3 ("[FS] Implement block_page_mkwrite.")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 50bbc99e3d96..66f4765e60ee 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2515,7 +2515,7 @@ int block_page_mkwrite(struct vm_area_struct *vma, struct
vm_fault *vmf,
}
/* page is wholly or partially inside EOF */
- if (((page->index + 1) << PAGE_SHIFT) > size)
+ if (((page->index + 1ULL) << PAGE_SHIFT) > size)
end = size & ~PAGE_MASK;
else
end = PAGE_SIZE;
--
2.28.0
[PATCH 3/7] ceph: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 61f68816211e ("ceph: check caps in filemap_fault and page_mkwrite")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/ceph/addr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 6ea761c84494..970e5a094035 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -1522,7 +1522,7 @@ static vm_fault_t ceph_filemap_fault(struct vm_fault *vmf)
struct ceph_inode_info *ci = ceph_inode(inode);
struct ceph_file_info *fi = vma->vm_file->private_data;
struct page *pinned_page = NULL;
- loff_t off = vmf->pgoff << PAGE_SHIFT;
+ loff_t off = (loff_t)vmf->pgoff << PAGE_SHIFT;
int want, got, err;
sigset_t oldset;
vm_fault_t ret = VM_FAULT_SIGBUS;
--
2.28.0
[PATCH 1/7] 9P: Cast to loff_t before multiplying
On 32-bit systems, this multiplication will overflow for files larger
than 4GB.
Cc: sta...@vger.kernel.org
Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/9p/vfs_file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index 3576123d8299..6d97b6b4d34b 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -612,9 +612,9 @@ static void v9fs_mmap_vm_close(struct vm_area_struct *vma)
struct writeback_control wbc = {
.nr_to_write = LONG_MAX,
.sync_mode = WB_SYNC_ALL,
- .range_start = vma->vm_pgoff * PAGE_SIZE,
+ .range_start = (loff_t)vma->vm_pgoff * PAGE_SIZE,
/* absolute end, byte at end included */
- .range_end = vma->vm_pgoff * PAGE_SIZE +
+ .range_end = (loff_t)vma->vm_pgoff * PAGE_SIZE +
(vma->vm_end - vma->vm_start - 1),
};
--
2.28.0
[PATCH 0/7] Fix a pile of 4GB file problems on 32-bit
I caught a bug in my own code where I forgot to cast to loff_t before shifting. So I thought I'd grep around and see if I could find any other occurrences. I found a few that were clearly bugs, and they're fixed below. There are other places where we don't cast, and I think they're OK. For example, some places we have a 'nr_pages' being shifted by PAGE_SHIFT, and that's probably OK because it's probably a single I/O. Also, I didn't touch AFFS or ROMFS or some other filesystems which probably have never seen a 4GB file in their lives. Might be worth fixing to be sure nobody copies bad code from them, but not worth cc'ing stable for. I didn't look for SECTOR_SHIFT or SECTOR_SIZE (or bare 9/512), just PAGE_SIZE and PAGE_SHIFT. I can't find a GCC warning to enable for this pattern, so I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97287 Matthew Wilcox (Oracle) (7): 9P: Cast to loff_t before multiplying buffer: Promote to unsigned long long before shifting ceph: Promote to unsigned long long before shifting ocfs2: Promote to unsigned long long before shifting btrfs: Promote to unsigned long long before shifting btrfs: Promote to unsigned long long before shifting btrfs: Promote to unsigned long long before multiplying fs/9p/vfs_file.c | 4 ++-- fs/btrfs/ioctl.c | 6 +++--- fs/btrfs/raid56.c | 2 +- fs/btrfs/scrub.c | 25 - fs/buffer.c | 2 +- fs/ceph/addr.c| 2 +- fs/ocfs2/alloc.c | 2 +- 7 files changed, 25 insertions(+), 18 deletions(-) -- 2.28.0
[PATCH 6/7] btrfs: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 53b381b3abeb ("Btrfs: RAID5 and RAID6")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/btrfs/raid56.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 255490f42b5d..5ee0a53301bd 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1089,7 +1089,7 @@ static int rbio_add_io_page(struct btrfs_raid_bio *rbio,
u64 disk_start;
stripe = >bbio->stripes[stripe_nr];
- disk_start = stripe->physical + (page_index << PAGE_SHIFT);
+ disk_start = stripe->physical + ((loff_t)page_index << PAGE_SHIFT);
/* if the device is missing, just fail this stripe */
if (!stripe->dev->bdev)
--
2.28.0
[PATCH 4/7] ocfs2: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: 35edec1d52c0 ("ocfs2: update truncate handling of partial clusters")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/ocfs2/alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 4c1b90442d6f..26eff79ecb50 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -6867,7 +6867,7 @@ static void ocfs2_zero_cluster_pages(struct inode *inode,
loff_t start,
ocfs2_map_and_dirty_page(inode, handle, from, to, page, 1,
);
- start = (page->index + 1) << PAGE_SHIFT;
+ start = (page->index + 1ULL) << PAGE_SHIFT;
}
out:
if (pages)
--
2.28.0
[PATCH 5/7] btrfs: Promote to unsigned long long before shifting
On 32-bit systems, this shift will overflow for files larger than 4GB.
Cc: sta...@vger.kernel.org
Fixes: df480633b891 ("btrfs: extent-tree: Switch to new delalloc space reserve
and release")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/btrfs/ioctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ac45f022b495..4d3b7e4ae53a 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1277,7 +1277,7 @@ static int cluster_pages_for_defrag(struct inode *inode,
page_cnt = min_t(u64, (u64)num_pages, (u64)file_end - start_index + 1);
ret = btrfs_delalloc_reserve_space(BTRFS_I(inode), _reserved,
- start_index << PAGE_SHIFT,
+ (loff_t)start_index << PAGE_SHIFT,
page_cnt << PAGE_SHIFT);
if (ret)
return ret;
@@ -1367,7 +1367,7 @@ static int cluster_pages_for_defrag(struct inode *inode,
btrfs_mod_outstanding_extents(BTRFS_I(inode), 1);
spin_unlock(_I(inode)->lock);
btrfs_delalloc_release_space(BTRFS_I(inode), data_reserved,
- start_index << PAGE_SHIFT,
+ (loff_t)start_index << PAGE_SHIFT,
(page_cnt - i_done) << PAGE_SHIFT, true);
}
@@ -1395,7 +1395,7 @@ static int cluster_pages_for_defrag(struct inode *inode,
put_page(pages[i]);
}
btrfs_delalloc_release_space(BTRFS_I(inode), data_reserved,
- start_index << PAGE_SHIFT,
+ (loff_t)start_index << PAGE_SHIFT,
page_cnt << PAGE_SHIFT, true);
btrfs_delalloc_release_extents(BTRFS_I(inode), page_cnt << PAGE_SHIFT);
extent_changeset_free(data_reserved);
--
2.28.0
[PATCH 7/7] btrfs: Promote to unsigned long long before multiplying
On 32-bit systems, these shifts will overflow for files larger than 4GB.
Add helper functions to avoid this problem coming back.
Cc: sta...@vger.kernel.org
Fixes: 73ff61dbe5ed ("Btrfs: fix device replace of a missing RAID 5/6 device")
Fixes: be50a8ddaae1 ("Btrfs: Simplify scrub_setup_recheck_block()'s argument")
Fixes: ff023aac3119 ("Btrfs: add code to scrub to copy read data to another
disk")
Fixes: b5d67f64f9bc ("Btrfs: change scrub to support big blocks")
Fixes: a2de733c78fa ("btrfs: scrub")
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/btrfs/scrub.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 354ab9985a34..ccbaf9c6e87a 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1262,12 +1262,17 @@ static inline void scrub_stripe_index_and_offset(u64
logical, u64 map_type,
}
}
+static u64 sblock_length(struct scrub_block *sblock)
+{
+ return (u64)sblock->page_count * PAGE_SIZE;
+}
+
static int scrub_setup_recheck_block(struct scrub_block *original_sblock,
struct scrub_block *sblocks_for_recheck)
{
struct scrub_ctx *sctx = original_sblock->sctx;
struct btrfs_fs_info *fs_info = sctx->fs_info;
- u64 length = original_sblock->page_count * PAGE_SIZE;
+ u64 length = sblock_length(original_sblock);
u64 logical = original_sblock->pagev[0]->logical;
u64 generation = original_sblock->pagev[0]->generation;
u64 flags = original_sblock->pagev[0]->flags;
@@ -1610,6 +1615,11 @@ static void scrub_write_block_to_dev_replace(struct
scrub_block *sblock)
}
}
+static u64 sbio_length(struct scrub_bio *sbio)
+{
+ return (u64)sbio->page_count * PAGE_SIZE;
+}
+
static int scrub_write_page_to_dev_replace(struct scrub_block *sblock,
int page_num)
{
@@ -1659,10 +1669,9 @@ static int scrub_add_page_to_wr_bio(struct scrub_ctx
*sctx,
bio->bi_iter.bi_sector = sbio->physical >> 9;
bio->bi_opf = REQ_OP_WRITE;
sbio->status = 0;
- } else if (sbio->physical + sbio->page_count * PAGE_SIZE !=
+ } else if (sbio->physical + sbio_length(sbio) !=
spage->physical_for_dev_replace ||
- sbio->logical + sbio->page_count * PAGE_SIZE !=
- spage->logical) {
+ sbio->logical + sbio_length(sbio) != spage->logical) {
scrub_wr_submit(sctx);
goto again;
}
@@ -2005,10 +2014,8 @@ static int scrub_add_page_to_rd_bio(struct scrub_ctx
*sctx,
bio->bi_iter.bi_sector = sbio->physical >> 9;
bio->bi_opf = REQ_OP_READ;
sbio->status = 0;
- } else if (sbio->physical + sbio->page_count * PAGE_SIZE !=
- spage->physical ||
- sbio->logical + sbio->page_count * PAGE_SIZE !=
- spage->logical ||
+ } else if (sbio->physical + sbio_length(sbio) != spage->physical ||
+ sbio->logical + sbio_length(sbio) != spage->logical ||
sbio->dev != spage->dev) {
scrub_submit(sctx);
goto again;
@@ -2094,7 +2101,7 @@ static void scrub_missing_raid56_pages(struct scrub_block
*sblock)
{
struct scrub_ctx *sctx = sblock->sctx;
struct btrfs_fs_info *fs_info = sctx->fs_info;
- u64 length = sblock->page_count * PAGE_SIZE;
+ u64 length = sblock_length(sblock);
u64 logical = sblock->pagev[0]->logical;
struct btrfs_bio *bbio = NULL;
struct bio *bio;
--
2.28.0
Re: [PATCH v2 2/6] fpga: m10bmc-sec: create max10 bmc security engine
On 10/2/20 8:15 PM, Randy Dunlap wrote: > On 10/2/20 6:24 PM, Russ Weight wrote: >> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig >> index c534cc80f398..2380d36b08c7 100644 >> --- a/drivers/fpga/Kconfig >> +++ b/drivers/fpga/Kconfig >> @@ -235,4 +235,15 @@ config IFPGA_SEC_MGR >>region and for the BMC. Select this option to enable >>updates for secure FPGA devices. >> >> +config IFPGA_M10_BMC_SECURE >> +tristate "Intel MAX10 BMC security engine" >> +depends on MFD_INTEL_M10_BMC && IFPGA_SEC_MGR >> +help >> + Secure update support for the Intel MAX10 board management >> + controller. >> + >> + This is a subdriver of the Intel MAX10 board management controller >> + (BMC) and provides support for secure updates for the BMC image, >> + the FPGA image, the Root Entry Hashes, etc. >> + >> endif # FPGA > Dagnabit, I need a bot to do this. > > Clean up the indentation in the Kconfig file. > > From Documentation/process/coding-style.rst, section 10: > > Lines under a ``config`` definition > are indented with one tab, while help text is indented an additional two > spaces. > > checkpatch should have found that issue. Did it not? Sorry - I thought I had addressed the indentation errors after the first submission. I'll fix it. I am running checkpatch.pl --strict, and I did not see a warning/error for this. > > > thanks.
[RFC PATCH 2/3] dt-bindings: gpio: Add binding documentation for Etron EJ168/EJ188/EJ198
Etron EJ168/EJ188/EJ198 are USB xHCI host controllers which embed a GPIO
controller.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/gpio/etron,ej1x8.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
diff --git a/Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
b/Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
new file mode 100644
index ..fa554045bdb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/etron,ej1x8.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO controller embedded into the EJ168/EJ188/EJ198 xHCI controllers
+
+maintainers:
+ - Martin Blumenstingl
+
+properties:
+ compatible:
+enum:
+ - pci1b6f,7023
+ - pci1b6f,7052
+
+ reg:
+maxItems: 1
+
+ "#gpio-cells":
+const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie {
+#address-cells = <3>;
+#size-cells = <2>;
+
+gpio@0,0,0 {
+ compatible = "pci1b6f,7023";
+ reg = <0x0 0x0 0x0 0x0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+};
+ };
+
+...
--
2.28.0
[RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
EJ168/EJ188/EJ198 are USB xHCI controllers. They also contain four GPIO
lines which are used on some systems to toggle an LED based on whether a
USB device is connected.
There is no public datasheet available for this hardware. All
information in this driver is taken from the
"F9K1115v2.03.97-GPL-10.2.85-20140313" GPL code dump of the Belkin
F9K1115v2. This board comes with an EJ168 USB xHCI controller and the
USB 3.0 LED is connected to one of the GPIOs. Inside the GPL source
archive the related code can be found in:
linux/kernels/mips-linux-2.6.31/drivers/usb/host/etxhci-pci.c
Signed-off-by: Martin Blumenstingl
---
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ej1x8.c | 311 ++
3 files changed, 321 insertions(+)
create mode 100644 drivers/gpio/gpio-ej1x8.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8030fd91a3cc..88820b04ffa5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -215,6 +215,15 @@ config GPIO_EIC_SPRD
help
Say yes here to support Spreadtrum EIC device.
+config GPIO_EJ1X8
+ tristate "Etron Tech Inc. EJ168/EJ188/EJ198 GPIO driver"
+ depends on OF_GPIO && PCI
+ help
+ Selecting this option will enable the GPIO pins present on
+ the Etron Tech Inc. EJ168/EJ188/EJ198 USB xHCI controllers.
+
+ If unsure, say N.
+
config GPIO_EM
tristate "Emma Mobile GPIO"
depends on (ARCH_EMEV2 || COMPILE_TEST) && OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4f9abff4f2dc..6d5e345b1f2d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_GPIO_DAVINCI)+= gpio-davinci.o
obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EIC_SPRD)+= gpio-eic-sprd.o
+obj-$(CONFIG_GPIO_EJ1X8) += gpio-ej1x8.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_EXAR)+= gpio-exar.o
diff --git a/drivers/gpio/gpio-ej1x8.c b/drivers/gpio/gpio-ej1x8.c
new file mode 100644
index ..c673e62c34f8
--- /dev/null
+++ b/drivers/gpio/gpio-ej1x8.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (C) 2020 Martin Blumenstingl
*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EJ1X8_GPIO_INIT0x44
+#define EJ1X8_GPIO_WRITE 0x68
+#define EJ1X8_GPIO_READ0x6c
+
+#define EJ1X8_GPIO_CTRL0x18005020
+#define EJ1X8_GPIO_CTRL_READ_ALL_MASK GENMASK(7, 0)
+#define EJ1X8_GPIO_CTRL_WRITE_ALL_MASK GENMASK(23, 16)
+#define EJ1X8_GPIO_CTRL_OUT_LOW0x0
+#define EJ1X8_GPIO_CTRL_OUT_HIGH 0x1
+#define EJ1X8_GPIO_CTRL_IN 0x2
+#define EJ1X8_GPIO_CTRL_MASK 0x3
+
+#define EJ1X8_GPIO_MODE0x18005022
+#define EJ1X8_GPIO_MODE_READ_WRITE_ALL_MASKGENMASK(23, 16)
+#define EJ1X8_GPIO_MODE_DISABLE0x0
+#define EJ1X8_GPIO_MODE_ENABLE 0x1
+#define EJ1X8_GPIO_MODE_MASK 0x3
+
+static LIST_HEAD(ej1x8_gpios);
+
+struct ej1x8_gpio {
+ spinlock_t lock;
+ struct pci_dev *pci_dev;
+ struct gpio_chipchip;
+ struct list_headlist_head;
+};
+
+static u8 ej1x8_gpio_shift(unsigned int gpio, u8 mask)
+{
+ return (gpio * fls(mask));
+}
+
+static u8 ej1x8_gpio_mask(unsigned int gpio, u8 mask)
+{
+ return mask << ej1x8_gpio_shift(gpio, mask);
+}
+
+static int ej1x8_gpio_read(struct gpio_chip *gc, u32 reg, u32 *value)
+{
+ struct ej1x8_gpio *ej1x8 = gpiochip_get_data(gc);
+ int err;
+
+ err = pci_write_config_dword(ej1x8->pci_dev, EJ1X8_GPIO_WRITE, reg);
+ if (err) {
+ dev_err(gc->parent, "Failed to select 0x%08x register\n", reg);
+ return err;
+ }
+
+ usleep_range(1000, 1);
+
+ err = pci_read_config_dword(ej1x8->pci_dev, EJ1X8_GPIO_READ, value);
+ if (err) {
+ dev_err(gc->parent, "Failed to read 0x%08x register\n", reg);
+ return err;
+ }
+
+ return 0;
+}
+
+static int ej1x8_gpio_write(struct gpio_chip *gc, u32 reg, u32 value)
+{
+ struct ej1x8_gpio *ej1x8 = gpiochip_get_data(gc);
+ int err;
+
+ err = pci_write_config_dword(ej1x8->pci_dev, EJ1X8_GPIO_WRITE,
+reg | value | BIT(24));
+
[RFC PATCH 0/3] GPIO support on the Etron EJ168/EJ188/EJ198 xHCI controllers
Hello,
I have a "Belkin F9K115v2" (wifi router) [0]. It comes with an Etron
EJ168 xHCI controllers soldered to the board. One of the LEDs on this
device is connected to one of the four GPIO lines provided by the
Etron xHCI controller.
The goal of this series to add support for the GPIO controller on the
Etron EJ168/EJ188/EJ198 controllers.
Unfortunately there's no (public) datasheet available. I have Cc'ed
Etron and I'm hoping that they can either provide a datasheet or at
least some code-review feedback.
Instead I used the GPL tarball [0] for this device. Inside this
tarball the relevant "reference" code is in:
linux/kernels/mips-linux-2.6.31/drivers/usb/host/etxhci-pci.c
Unfortunately it uses magic numbers for the registers instead of
human-readable names. The register names are what I came up with.
For reference, I have tested this on a patched OpenWrt build with the
following .dts changes (I am showing these here so it will be easier
to review the whole series):
{
status = "okay";
xhci: usb-controller@0,0,0 {
compatible = "pci1b6f,7023";
reg = <0x0 0x0 0x0 0x0 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
gpio-controller;
#gpio-cells = <2>;
xhci_port0: port@1 {
reg = <1>;
#trigger-source-cells = <0>;
};
};
};
leds {
compatible = "gpio-leds";
usb3 {
label = "green:usb3";
gpios = < 2 GPIO_ACTIVE_LOW>;
trigger-sources = <_port0>;
linux,default-trigger = "usbport";
};
};
In general I followed [2] because it says:
PCI drivers should have a really good reason for not using the
pci_register_driver() [...] The main reason [...] is because one
PCI device implements several different HW services.
My understanding that my driver fits into this category.
I am sending this as RFC because this is my first self-written GPIO
driver as well as my first PCI device driver. Any feedback is welcome!
Best regards,
Martin
[0] https://openwrt.org/toh/belkin/f9k1115v2
[1] https://www.belkin.com/support/dl/F9K1115v2.03.97-GPL-10.2.85.tar.gz
[2]
https://www.kernel.org/doc/html/latest/PCI/pci.html#how-to-find-pci-devices-manually
Martin Blumenstingl (3):
PCI: Add the IDs for Etron EJ168 and EJ188
dt-bindings: gpio: Add binding documentation for Etron
EJ168/EJ188/EJ198
gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
.../devicetree/bindings/gpio/etron,ej1x8.yaml | 48 +++
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ej1x8.c | 311 ++
include/linux/pci_ids.h | 4 +
5 files changed, 373 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml
create mode 100644 drivers/gpio/gpio-ej1x8.c
--
2.28.0
[RFC PATCH 1/3] PCI: Add the IDs for Etron EJ168 and EJ188
Add the vendor ID for Etron Technology, Inc. as well as the device IDs for the two USB xHCI controllers EJ168 and EJ188. Signed-off-by: Martin Blumenstingl --- include/linux/pci_ids.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 1ab1e24bcbce..1c8370aa4b95 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2587,6 +2587,10 @@ #define PCI_VENDOR_ID_REDHAT 0x1b36 +#define PCI_VENDOR_ID_ETRON0x1b6f +#define PCI_DEVICE_ID_ETRON_EJ168 0x7023 +#define PCI_DEVICE_ID_ETRON_EJ188 0x7052 + #define PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS0x1c36 #define PCI_VENDOR_ID_CIRCUITCO0x1cc8 -- 2.28.0
Re: [PATCH] media: zoran.rst: place it at the right place this time
On Sun, Oct 04, 2020 at 06:00:30PM +0200, Mauro Carvalho Chehab wrote:
> I was too quick moving zoran.rst... it ends that the original
> patch didn't do the right thing and forgot to update the files
> that references it.
>
> Fix it.
>
> Fixes: 6b90346919d4 ("media: zoran: move documentation file to the right
> place")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../driver-api/media/drivers/{v4l-drivers => }/zoran.rst| 0
> MAINTAINERS | 2 +-
> drivers/staging/media/zoran/Kconfig | 2 +-
> 3 files changed, 2 insertions(+), 2 deletions(-)
> rename Documentation/driver-api/media/drivers/{v4l-drivers => }/zoran.rst
> (100%)
>
> diff --git a/Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> b/Documentation/driver-api/media/drivers/zoran.rst
> similarity index 100%
> rename from Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> rename to Documentation/driver-api/media/drivers/zoran.rst
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba5eb1dff9c2..7a12633747c8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19247,7 +19247,7 @@ L:linux-me...@vger.kernel.org
> S: Maintained
> W: http://mjpeg.sourceforge.net/driver-zoran/
> Q: https://patchwork.linuxtv.org/project/linux-media/list/
> -F: Documentation/media/v4l-drivers/zoran.rst
> +F: Documentation/driver-api/media/drivers/zoran.rst
> F: drivers/staging/media/zoran/
>
> ZPOOL COMPRESSED PAGE STORAGE API
> diff --git a/drivers/staging/media/zoran/Kconfig
> b/drivers/staging/media/zoran/Kconfig
> index 492507030276..7874842033ca 100644
> --- a/drivers/staging/media/zoran/Kconfig
> +++ b/drivers/staging/media/zoran/Kconfig
> @@ -8,7 +8,7 @@ config VIDEO_ZORAN
> 36057/36067 PCI controller chipset. This includes the Iomega
> Buz, Pinnacle DC10+ and the Linux Media Labs LML33. There is
> a driver homepage at
Re: [PATCH 1/4] media: zoran: move documentation file to the right place
On Sat, Oct 03, 2020 at 10:41:54AM +0200, Mauro Carvalho Chehab wrote:
> The zoran revert patch misplaced the Zoran doc file. Move it to
> the right place.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/driver-api/media/drivers/index.rst | 1 +
> .../{media => driver-api/media/drivers}/v4l-drivers/zoran.rst| 0
> 2 files changed, 1 insertion(+)
> rename Documentation/{media =>
> driver-api/media/drivers}/v4l-drivers/zoran.rst (100%)
>
> diff --git a/Documentation/driver-api/media/drivers/index.rst
> b/Documentation/driver-api/media/drivers/index.rst
> index 5f340cfdb4cc..eb7011782863 100644
> --- a/Documentation/driver-api/media/drivers/index.rst
> +++ b/Documentation/driver-api/media/drivers/index.rst
> @@ -25,6 +25,7 @@ Video4Linux (V4L) drivers
> sh_mobile_ceu_camera
> tuners
> vimc-devel
> + zoran
>
>
> Digital TV drivers
> diff --git a/Documentation/media/v4l-drivers/zoran.rst
> b/Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> similarity index 100%
> rename from Documentation/media/v4l-drivers/zoran.rst
> rename to Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
> --
> 2.26.2
>
Hello
Acked-by: Corentin Labbe
Thanks
Re: remove set_fs for riscv v2
On Sat, 26 Sep 2020 12:13:41 PDT (-0700), Arnd Bergmann wrote: On Sat, Sep 26, 2020 at 7:50 PM Palmer Dabbelt wrote: I'm OK taking it, but there's a few things I'd like to sort out. IIRC I put it on a temporary branch over here https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/log/?h=riscv-remove_set_fs under the assumption it might get lost otherwise, but let me know if that's not what you were looking for. Arnd: Are you OK with the asm-generic stuff? I couldn't find anything in my mail history, so sorry if I just missed it. For some reason I had missed that __copy_from_user() change earlier, but I had a closer look now and this is all very good, feel free to add an Acked-by: Arnd Bergmann Thanks. These (along with the rest of Christoph's patch set, and a merge from base.set_fs) are on my for-next.
Re: [EXT] Re: [PATCH v4 11/13] task_isolation: net: don't flush backlog on CPUs running isolated tasks
On Thu, 2020-10-01 at 16:47 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:58:24PM +, Alex Belits wrote:
> > From: Yuri Norov
> >
> > If CPU runs isolated task, there's no any backlog on it, and
> > so we don't need to flush it.
>
> What guarantees that we have no backlog on it?
I believe, the logic was that it is not supposed to have backlog
because it could not be produced while the CPU was in userspace,
because one has to enter kernel to receive (by interrupt) or send (by
syscall) anything.
Now, looking at this patch. I don't think, it can be guaranteed that
there was no backlog before it entered userspace. Then backlog
processing will be delayed until exit from isolation. It won't be
queued, and flush_work() will not wait when no worker is assigned, so
there won't be a deadlock, however this delay may not be such a great
idea.
So it may be better to flush backlog before entering isolation, and in
flush_all_backlogs() instead of skipping all CPUs in isolated mode,
check if their per-CPU softnet_data->input_pkt_queue and softnet_data-
>process_queue are empty, and if they are not, call backlog anyway.
Then, if for whatever reason backlog will appear after flushing (we
can't guarantee that nothing preempted us then), it will cause one
isolation breaking event, and if nothing will be queued before re-
entering isolation, there will be no backlog until exiting isolation.
>
> > Currently flush_all_backlogs()
> > enqueues corresponding work on all CPUs including ones that run
> > isolated tasks. It leads to breaking task isolation for nothing.
> >
> > In this patch, backlog flushing is enqueued only on non-isolated
> > CPUs.
> >
> > Signed-off-by: Yuri Norov
> > [abel...@marvell.com: use safe task_isolation_on_cpu()
> > implementation]
> > Signed-off-by: Alex Belits
> > ---
> > net/core/dev.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 90b59fc50dc9..83a282f7453d 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -74,6 +74,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -5624,9 +5625,13 @@ static void flush_all_backlogs(void)
> >
> > get_online_cpus();
> >
> > - for_each_online_cpu(cpu)
> > + smp_rmb();
>
> What is it ordering?
Same as with other calls to task_isolation_on_cpu(cpu), it orders
access to ll_isol_flags.
> > + for_each_online_cpu(cpu) {
> > + if (task_isolation_on_cpu(cpu))
> > + continue;
> > queue_work_on(cpu, system_highpri_wq,
> > per_cpu_ptr(_works, cpu));
> > + }
> >
> > for_each_online_cpu(cpu)
> > flush_work(per_cpu_ptr(_works, cpu));
>
> Thanks.
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
Hi Greg,
> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> breaks all bluetooth connections on my machine.
>
> Cc: Marcel Holtmann
> Cc: Sathish Narsimman
> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating
> whitelist")
> Signed-off-by: Greg Kroah-Hartman
> ---
> net/bluetooth/hci_request.c | 41 ++---
> 1 file changed, 2 insertions(+), 39 deletions(-)
>
> This has been bugging me for since 5.9-rc1, when all bluetooth devices
> stopped working on my desktop system. I finally got the time to do
> bisection today, and it came down to this patch. Reverting it on top of
> 5.9-rc7 restored bluetooth devices and now my input devices properly
> work.
>
> As it's almost 5.9-final, any chance this can be merged now to fix the
> issue?
can you be specific what breaks since our guys and I also think the
ChromeOS guys have been testing these series of patches heavily.
>>>
>>> My bluetooth trackball does not connect at all. With this reverted, it
>>> all "just works".
>>>
>>> Same I think for a Bluetooth headset, can check that again if you really
>>> need me to, but the trackball is reliable here.
>>>
When you run btmon does it indicate any errors?
>>>
>>> How do I run it and where are the errors displayed?
>>
>> you can do btmon -w trace.log and just let it run like tcdpump.
>
> Ok, attached.
>
> The device is not connecting, and then I open the gnome bluetooth dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
>
> Any ideas?
the trace file is from -rc7 or from -rc7 with this patch reverted?
I asked, because I see no hint that anything goes wrong. However I have a
suspicion if you bisected it to this patch.
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index e0269192f2e5..94c0daa9f28d 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -732,7 +732,7 @@ static int add_to_white_list(struct hci_request *req,
return -1;
/* White list can not be used with RPAs */
- if (!allow_rpa && !use_ll_privacy(hdev) &&
+ if (!allow_rpa &&
hci_find_irk_by_addr(hdev, >addr, params->addr_type)) {
return -1;
}
@@ -812,7 +812,7 @@ static u8 update_white_list(struct hci_request *req)
}
/* White list can not be used with RPAs */
- if (!allow_rpa && !use_ll_privacy(hdev) &&
+ if (!allow_rpa &&
hci_find_irk_by_addr(hdev, >bdaddr, b->bdaddr_type)) {
return 0x00;
}
If you just do the above, does thing work for you again?
My suspicion is that the use_ll_privacy check is the wrong one here. It only
checks if hardware feature is available, not if it is also enabled.
Regards
Marcel
Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource
On Mon, Oct 05, 2020 at 12:21:12AM +0800, pierre kuo wrote: > hi Greg: > > Please resend, I can't take patches off of a random web site. > > Now lore.kernel.org I could take them from :) > > Please refer to the attachments and links on lore.kernel.org. > > https://lore.kernel.org/lkml/20200920113808.3-1-vichy@gmail.com > https://lore.kernel.org/lkml/20200920113808.3-2-vichy@gmail.com Why are you adding new functions but not actually calling them anywhere? We don't like adding infrastructure that no one uses, that's just wasteful. Please redo the series and include some conversions as well, so that we can see if these new functions are even needed or not. thanks, greg k-h
Re: [PATCH 2/2] driver core: platform: provide devm_platform_iounremap_resource
hi Greg:
> Please resend, I can't take patches off of a random web site.
> Now lore.kernel.org I could take them from :)
Please refer to the attachments and links on lore.kernel.org.
https://lore.kernel.org/lkml/20200920113808.3-1-vichy@gmail.com
https://lore.kernel.org/lkml/20200920113808.3-2-vichy@gmail.com
Appreciate your help,
From b141d537904b71b802770d9c0fc3787b98c5cf71 Mon Sep 17 00:00:00 2001
From: pierre Kuo
Date: Tue, 18 Aug 2020 23:05:00 +0800
Subject: [PATCH 1/2] lib: devres: provide devm_iounremap_resource()
Driver doesn't have a single helper function to release memroy
allocated by devm_ioremap_resource(). That mean it needs respectively
to call devm_release_mem_region() and devm_iounmap() for memory release.
This patch creates a helper, devm_iounremap_resource(), to combine above
operations.
Signed-off-by: pierre Kuo
---
include/linux/device.h | 2 ++
lib/devres.c | 25 +
2 files changed, 27 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 9e6ea8931a52..33ec7e54c1a9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -240,6 +240,8 @@ void devm_free_pages(struct device *dev, unsigned long addr);
void __iomem *devm_ioremap_resource(struct device *dev,
const struct resource *res);
+void devm_iounremap_resource(struct device *dev,
+ const struct resource *res, void __iomem *addr);
void __iomem *devm_ioremap_resource_wc(struct device *dev,
const struct resource *res);
diff --git a/lib/devres.c b/lib/devres.c
index ebb1573d9ae3..cdda0cd0a263 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -113,6 +113,31 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
}
EXPORT_SYMBOL(devm_iounmap);
+/**
+ * devm_iounremap_resource() - release mem region, and unremap address
+ * @dev: generic device to handle the resource for
+ * @res: resource of mem region to be release
+ * @addr: address to unmap
+ *
+ * Release memory region and unmap address.
+ */
+void devm_iounremap_resource(struct device *dev,
+ const struct resource *res, void __iomem *addr)
+{
+ resource_size_t size;
+
+ BUG_ON(!dev);
+ if (!res || resource_type(res) != IORESOURCE_MEM) {
+ dev_err(dev, "invalid resource\n");
+ return;
+ }
+
+ size = resource_size(res);
+ devm_release_mem_region(dev, res->start, size);
+ devm_iounmap(dev, addr);
+}
+EXPORT_SYMBOL(devm_iounremap_resource);
+
static void __iomem *
__devm_ioremap_resource(struct device *dev, const struct resource *res,
enum devm_ioremap_type type)
--
2.17.1
From 33afa315c3c941b303e9b3152552010ad266ebbf Mon Sep 17 00:00:00 2001
From: pierre Kuo
Date: Wed, 19 Aug 2020 15:57:05 +0800
Subject: [PATCH 2/2] driver core: platform: provide
devm_platform_iounremap_resource
Combine platform_get_resource() and devm_iounremap_resource() to release
the iomem allocated by devm_platform_get_and_ioremap_resource().
Signed-off-by: pierre Kuo
---
drivers/base/platform.c | 24
include/linux/platform_device.h | 4
2 files changed, 28 insertions(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e5d8a0503b4f..e2655c00873f 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -84,6 +84,30 @@ devm_platform_get_and_ioremap_resource(struct platform_device *pdev,
}
EXPORT_SYMBOL_GPL(devm_platform_get_and_ioremap_resource);
+/**
+ * devm_platform_iounremap_resource - call devm_iounremap_resource() for a
+ * platform device with memory that addr points to.
+ *
+ * @pdev: platform device to use both for memory resource lookup as well as
+ *resource management
+ * @index: resource index
+ * @addr: address to be unmap.
+ */
+void
+devm_platform_iounremap_resource(struct platform_device *pdev,
+ unsigned int index, void __iomem *addr)
+{
+ struct resource *r;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, index);
+ if (!r)
+ dev_err(>dev,
+ "MEM resource index %d not found\n", index);
+ else
+ devm_iounremap_resource(>dev, r, addr);
+}
+EXPORT_SYMBOL_GPL(devm_platform_iounremap_resource);
+
/**
* devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
*device
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 77a2aada106d..75da15937679 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -67,6 +67,10 @@ devm_platform_ioremap_resource_wc(struct platform_device *pdev,
extern void __iomem *
devm_platform_ioremap_resource_byname(struct platform_device *pdev,
const char *name);
+extern void
+devm_platform_iounremap_resource(struct platform_device *pdev,
+ unsigned int index,
+ void __iomem *addr);
extern int platform_get_irq(struct platform_device *, unsigned int);
extern int platform_get_irq_optional(struct platform_device *, unsigned int);
extern int platform_irq_count(struct platform_device *);
--
2.17.1
Re: [sched/fair] fcf0553db6: netperf.Throughput_Mbps -30.8% regression
On Sun, Oct 04, 2020 at 09:27:16PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -30.8% regression of netperf.Throughput_Mbps due to commit:
>
>
> commit: fcf0553db6f4c79387864f6e4ab4a891601f395e ("sched/fair: Remove
> meaningless imbalance calculation")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
This commit was the start of a series that made large changes to load
balancing. The series was not bisect-safe and has since been reconciled
with the NUMA balancing. Any workload with a potential load balancing
problem has to be checked against the latest kernel to see if the problem
persists there. If it does, then tip/sched/core should be checked or
5.10-rc1 when it comes out as tip has a few more LB changes pending.
--
Mel Gorman
SUSE Labs
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On 02-10-20, 18:41, Rob Herring wrote: > .../phy/amlogic,meson-g12a-usb2-phy.yaml | 2 ++ > .../bindings/phy/qcom,ipq806x-usb-phy-hs.yaml | 2 ++ > .../bindings/phy/qcom,ipq806x-usb-phy-ss.yaml | 2 ++ > .../bindings/phy/qcom,qusb2-phy.yaml | 1 + > .../bindings/phy/qcom-usb-ipq4019-phy.yaml| 2 ++ For phy changes: Acked-By: Vinod Koul -- ~Vinod
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote: > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > > > That leaves the only interesting places as vb2_dc_get_userptr() and > > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > > REQUIRED behavior in the function's comment about checking PTEs. It > > > just DMA maps them. Badly broken. > > > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > > > Yeah, see also the follow_pfn trickery in > > videobuf_dma_contig_user_get(), I think this is fully intentional and > > userspace abi we can't break :-/ > > We don't need to break uABI, it just needs to work properly in the > kernel: > > vma = find_vma_intersection() > dma_buf = dma_buf_get_from_vma(vma) > sg = dma_buf_p2p_dma_map(dma_buf) > [.. do dma ..] > dma_buf_unmap(sg) > dma_buf_put(dma_buf) > > It is as we discussed before, dma buf needs to be discoverable from a > VMA, at least for users doing this kind of stuff. I'm not a big fan of magic behaviour like this, there's more to dma-buf buffer sharing than just "how do I get at the backing storage". Thus far we've done everything rather explicitly. Plus with exynos and habanalabs converted there's only v4l left over, and that has a proper dma-buf import path already. > > Yup this should be done with dma_buf instead, and v4l has that. But > > old uapi and all that. This is why I said we might need a new > > VM_DYNAMIC_PFNMAP or so, to make follow_pfn not resolve this in the > > case where the driver manages the underlying iomem range (or whatever > > it is) dynamically and moves buffer objects around, like drm drivers > > do. But I looked, and we've run out of vma->vm_flags :-( > > A VM flag doesn't help - we need to introduce some kind of lifetime, > and that has to be derived from the VMA. It needs data not just a flag I don't want to make it work, I just want to make it fail. Rough idea I have in mind is to add a follow_pfn_longterm, for all callers which aren't either synchronized through mmap_sem or an mmu_notifier. If this really breaks anyone's use-case we can add a tainting kernel option which re-enables this (we've done something similar for phys_addr_t based buffer sharing in fbdev, entirely unfixable since the other driver has to just blindly trust that what userspace passes around is legit). This here isn't unfixable, but if v4l people want to keep it without a big "security hole here" sticker, they should do the work, not me :-) > > The other problem is that I also have no real working clue about all > > the VM_* flags and what they all mean, and whether drm drivers set the > > right ones in all cases (they probably don't, but oh well). > > Documentation for this stuff in headers is a bit thin at times. > > Yah, I don't really know either :\ > > The comment above vm_normal_page() is a bit helpful. Don't know what > VM_IO/VM_PFNMAP mean in their 3 combinations > > There are very few places that set VM_PFNMAP without VM_IO.. Best I could find is: - mk68 seems to outright reject pagefaults on VM_IO vma - some places set VM_IO together with VM_MIXEDMAP instead of VM_PFNMAP. There's some comments that this makes cow possible, but I guess that's for the old pfn remap vma (remap_file_pages, which is removed now). But really no clue. VM_IO | VM_MIXEDMAP kinda makes me wonder whether follow_pfn gets the page refcounting all right or horribly wrong in some cases ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
Lars, Thank you for your review! The changes which you have suggested also made ModemManager to recognize the device (which it didn't do before). Please check out the v2. Cheers, Leonid. ___ On 10/4/20 5:32 PM, Lars Melin wrote: On 10/4/2020 21:16, Lars Melin wrote: On 10/4/2020 20:29, Leonid Bloch wrote: On 10/4/20 1:58 PM, Lars Melin wrote: On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. Please see below. Thanks, Leonid. ``` Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1054 bcdDevice 4.14 iManufacturer 1 Telit Wireless Solutions iProduct 2 FT980-KS iSerial 3 cb42f61 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x013d bNumInterfaces 8 bConfigurationValue 1 iConfiguration 4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 239 Miscellaneous Device bFunctionSubClass 4 bFunctionProtocol 1 iFunction 7 RNDIS Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 4 bInterfaceProtocol 1 iInterface 5 RNDIS Communications Control ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 04 24 02 00 ** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 RNDIS Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5
[PATCH] media: zoran.rst: place it at the right place this time
I was too quick moving zoran.rst... it ends that the original
patch didn't do the right thing and forgot to update the files
that references it.
Fix it.
Fixes: 6b90346919d4 ("media: zoran: move documentation file to the right place")
Signed-off-by: Mauro Carvalho Chehab
---
.../driver-api/media/drivers/{v4l-drivers => }/zoran.rst| 0
MAINTAINERS | 2 +-
drivers/staging/media/zoran/Kconfig | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename Documentation/driver-api/media/drivers/{v4l-drivers => }/zoran.rst
(100%)
diff --git a/Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
b/Documentation/driver-api/media/drivers/zoran.rst
similarity index 100%
rename from Documentation/driver-api/media/drivers/v4l-drivers/zoran.rst
rename to Documentation/driver-api/media/drivers/zoran.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index ba5eb1dff9c2..7a12633747c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19247,7 +19247,7 @@ L: linux-me...@vger.kernel.org
S: Maintained
W: http://mjpeg.sourceforge.net/driver-zoran/
Q: https://patchwork.linuxtv.org/project/linux-media/list/
-F: Documentation/media/v4l-drivers/zoran.rst
+F: Documentation/driver-api/media/drivers/zoran.rst
F: drivers/staging/media/zoran/
ZPOOL COMPRESSED PAGE STORAGE API
diff --git a/drivers/staging/media/zoran/Kconfig
b/drivers/staging/media/zoran/Kconfig
index 492507030276..7874842033ca 100644
--- a/drivers/staging/media/zoran/Kconfig
+++ b/drivers/staging/media/zoran/Kconfig
@@ -8,7 +8,7 @@ config VIDEO_ZORAN
36057/36067 PCI controller chipset. This includes the Iomega
Buz, Pinnacle DC10+ and the Linux Media Labs LML33. There is
a driver homepage at
[PATCH v2] USB: serial: option: Add Telit FT980-KS composition
This commit adds the following Telit FT980-KS composition:
0x1054: rndis, diag, adb, nmea, modem, modem, aux
AT commands can be sent to /dev/ttyUSB2.
Signed-off-by: Leonid Bloch
---
The full composition is not tested, and it is the default one according
to Telit support. What is tested, is that this commit makes
/dev/ttyUSB{0..4} appear upon connecting the FT980-KS, and allows
sending AT commands to /dev/ttyUSB2.
Changes since v1:
* Interface #3 (ADB) is blacklisted.
* NCTRL flag is set to the diag interface.
These changes (relative to v1) also allow ModemManager to recognize the
device.
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 0c6f160a214a..fe76710167f8 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1186,6 +1186,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = NCTRL(2) | RSVD(3) },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1053, 0xff),/*
Telit FN980 (ECM) */
.driver_info = NCTRL(0) | RSVD(1) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1054, 0xff),/*
Telit FT980-KS */
+ .driver_info = NCTRL(2) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910),
.driver_info = NCTRL(0) | RSVD(1) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
--
2.28.0
Re: [PATCH v4] hwmon (pmbus/max20730): add device monitoring via debugfs
On Tue, Sep 22, 2020 at 07:15:38PM +, Ugur Usug wrote:
> Add debugfs interface support for accessing device specific registers
> (MFR_VOUT_MIN,
> MFR_DEVSET1 and MFR_DEVSET2) and others including OPERATION, ON_OFF_CONFIG,
> SMB_ALERT_MASK, VOUT_MODE, VOUT_COMMAND and VOUT_MAX.
>
> This patch changes following items in max20730_debugfs_read():
> - the EINVAL returns to "Invalid" or "Not supported"
> - strcpy() and strnlen() calls to strlcpy() calls
> - VOUT_MODE, VOUT_COMMAND and VOUT_MAX raw outputs to unit volts
> - terminating '\0' characters to the simple_read_from_buffer() return
>
> Signed-off-by: Ugur Usug
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/pmbus/max20730.c | 363
> -
> 1 file changed, 362 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
> index a151a2b..3175c9b 100644
> --- a/drivers/hwmon/pmbus/max20730.c
> +++ b/drivers/hwmon/pmbus/max20730.c
> @@ -8,6 +8,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -26,16 +27,367 @@ enum chips {
> max20743
> };
>
> +enum {
> + MAX20730_DEBUGFS_VOUT_MIN = 0,
> + MAX20730_DEBUGFS_FREQUENCY,
> + MAX20730_DEBUGFS_PG_DELAY,
> + MAX20730_DEBUGFS_INTERNAL_GAIN,
> + MAX20730_DEBUGFS_BOOT_VOLTAGE,
> + MAX20730_DEBUGFS_OUT_V_RAMP_RATE,
> + MAX20730_DEBUGFS_OC_PROTECT_MODE,
> + MAX20730_DEBUGFS_SS_TIMING,
> + MAX20730_DEBUGFS_IMAX,
> + MAX20730_DEBUGFS_OPERATION,
> + MAX20730_DEBUGFS_ON_OFF_CONFIG,
> + MAX20730_DEBUGFS_SMBALERT_MASK,
> + MAX20730_DEBUGFS_VOUT_MODE,
> + MAX20730_DEBUGFS_VOUT_COMMAND,
> + MAX20730_DEBUGFS_VOUT_MAX,
> + MAX20730_DEBUGFS_NUM_ENTRIES
> +};
> +
> struct max20730_data {
> enum chips id;
> struct pmbus_driver_info info;
> struct mutex lock; /* Used to protect against parallel writes */
> u16 mfr_devset1;
> + u16 mfr_devset2;
> + u16 mfr_voutmin;
> };
>
> #define to_max20730_data(x) container_of(x, struct max20730_data, info)
>
> +#define VOLT_FROM_REG(val) DIV_ROUND_CLOSEST((val), 1 << 9)
> +
> +#define PMBUS_SMB_ALERT_MASK 0x1B
> +
> +#define MAX20730_MFR_VOUT_MIN0xd1
> #define MAX20730_MFR_DEVSET1 0xd2
> +#define MAX20730_MFR_DEVSET2 0xd3
> +
> +#define MAX20730_MFR_VOUT_MIN_MASK GENMASK(9, 0)
> +#define MAX20730_MFR_VOUT_MIN_BIT_POS0
> +
> +#define MAX20730_MFR_DEVSET1_RGAIN_MASK (BIT(13) | BIT(14))
> +#define MAX20730_MFR_DEVSET1_OTP_MASK(BIT(11) | BIT(12))
> +#define MAX20730_MFR_DEVSET1_VBOOT_MASK (BIT(8) | BIT(9))
> +#define MAX20730_MFR_DEVSET1_OCP_MASK(BIT(5) | BIT(6))
> +#define MAX20730_MFR_DEVSET1_FSW_MASKGENMASK(4, 2)
> +#define MAX20730_MFR_DEVSET1_TSTAT_MASK (BIT(0) | BIT(1))
> +
> +#define MAX20730_MFR_DEVSET1_RGAIN_BIT_POS 13
> +#define MAX20730_MFR_DEVSET1_OTP_BIT_POS 11
> +#define MAX20730_MFR_DEVSET1_VBOOT_BIT_POS 8
> +#define MAX20730_MFR_DEVSET1_OCP_BIT_POS 5
> +#define MAX20730_MFR_DEVSET1_FSW_BIT_POS 2
> +#define MAX20730_MFR_DEVSET1_TSTAT_BIT_POS 0
> +
> +#define MAX20730_MFR_DEVSET2_IMAX_MASK GENMASK(10, 8)
> +#define MAX20730_MFR_DEVSET2_VRATE (BIT(6) | BIT(7))
> +#define MAX20730_MFR_DEVSET2_OCPM_MASK BIT(5)
> +#define MAX20730_MFR_DEVSET2_SS_MASK (BIT(0) | BIT(1))
> +
> +#define MAX20730_MFR_DEVSET2_IMAX_BIT_POS8
> +#define MAX20730_MFR_DEVSET2_VRATE_BIT_POS 6
> +#define MAX20730_MFR_DEVSET2_OCPM_BIT_POS5
> +#define MAX20730_MFR_DEVSET2_SS_BIT_POS 0
> +
> +#define DEBUG_FS_DATA_MAX16
> +
> +struct max20730_debugfs_data {
> + struct i2c_client *client;
> + int debugfs_entries[MAX20730_DEBUGFS_NUM_ENTRIES];
> +};
> +
> +#define to_psu(x, y) container_of((x), \
> + struct max20730_debugfs_data, debugfs_entries[(y)])
> +
> +#ifdef CONFIG_DEBUG_FS
> +static ssize_t max20730_debugfs_read(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + int ret, len;
> + int *idxp = file->private_data;
> + int idx = *idxp;
> + struct max20730_debugfs_data *psu = to_psu(idxp, idx);
> + const struct pmbus_driver_info *info;
> + const struct max20730_data *data;
> + char tbuf[DEBUG_FS_DATA_MAX] = { 0 };
> + u16 val;
> +
> + info = pmbus_get_driver_info(psu->client);
> + data = to_max20730_data(info);
> +
> + switch (idx) {
> + case MAX20730_DEBUGFS_VOUT_MIN:
> + ret = VOLT_FROM_REG(data->mfr_voutmin * 1);
> + len = snprintf(tbuf, DEBUG_FS_DATA_MAX, "%d.%d\n",
> +ret / 1, ret % 1);
> + break;
> + case MAX20730_DEBUGFS_FREQUENCY:
> + val = (data->mfr_devset1 & MAX20730_MFR_DEVSET1_FSW_MASK)
> +
Re: [PATCH 3/4] rcu/tree: Make struct kernel_param_ops definitions const
On Sat, Oct 03, 2020 at 05:18:08PM -0700, Joe Perches wrote:
> These should be const, so make it so.
>
> Signed-off-by: Joe Perches
Queued for testing and review, thank you!
Thanx, Paul
> ---
> kernel/rcu/tree.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index f78ee759af9c..c4732bb80818 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -552,12 +552,12 @@ static int param_set_next_fqs_jiffies(const char *val,
> const struct kernel_param
> return ret;
> }
>
> -static struct kernel_param_ops first_fqs_jiffies_ops = {
> +static const struct kernel_param_ops first_fqs_jiffies_ops = {
> .set = param_set_first_fqs_jiffies,
> .get = param_get_ulong,
> };
>
> -static struct kernel_param_ops next_fqs_jiffies_ops = {
> +static const struct kernel_param_ops next_fqs_jiffies_ops = {
> .set = param_set_next_fqs_jiffies,
> .get = param_get_ulong,
> };
> --
> 2.26.0
>
Re: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training
On 10/2/20 4:03 PM, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link is off (-5)
>
> The panel was hooked up to a logic analyzer and it was found that, as
> part of link training, the bridge chip was writing a 0x1 to DPCD
> address 00600h and the panel responded NACK. As can be seen in header
> files, the write of 0x1 to DPCD address 0x600h means we were trying to
> write the value DP_SET_POWER_D0 to the register DP_SET_POWER. The
> panel vendor says that a NACK in this case is not unexpected and means
> "not ready, try again".
>
> In testing, we found that this panel would respond with a NACK in
> about 1/25 times. Adding the retry logic worked fine and the most
> number of tries needed was 3. Just to be safe, we'll add 10 tries
> here and we'll add a little blurb to the logs if we ever need more
> than 5.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++
> 1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ecdf9b01340f..6e12cda69b54 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -106,6 +106,8 @@
> #define SN_NUM_GPIOS 4
> #define SN_GPIO_PHYSICAL_OFFSET 1
>
> +#define SN_LINK_TRAINING_TRIES 10
> +
> /**
> * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
> * @dev: Pointer to our device.
> @@ -673,6 +675,7 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> {
> unsigned int val;
> int ret;
> + int i;
>
> /* set dp clk frequency value */
> regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> @@ -689,19 +692,34 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> goto exit;
> }
>
> - /* Semi auto link training mode */
> - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> -val == ML_TX_MAIN_LINK_OFF ||
> -val == ML_TX_NORMAL_MODE, 1000,
> -500 * 1000);
> - if (ret) {
> - *last_err_str = "Training complete polling failed";
> - } else if (val == ML_TX_MAIN_LINK_OFF) {
> - *last_err_str = "Link training failed, link is off";
> - ret = -EIO;
> + /*
> + * We'll try to link train several times. As part of link training
> + * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If
> + * the panel isn't ready quite it might respond NAK here which means
> + * we need to try again.
> + */
> + for (i = 0; i < SN_LINK_TRAINING_TRIES; i++) {
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + ret = regmap_read_poll_timeout(pdata->regmap,
> SN_ML_TX_MODE_REG, val,
> + val == ML_TX_MAIN_LINK_OFF ||
> + val == ML_TX_NORMAL_MODE, 1000,
> + 500 * 1000);
> + if (ret) {
> + *last_err_str = "Training complete polling failed";
> + } else if (val == ML_TX_MAIN_LINK_OFF) {
> + *last_err_str = "Link training failed, link is off";
> + ret = -EIO;
> + continue;
> + }
> +
> + break;
> }
>
> + /* If we saw quite a few retries, add a note about it */
> + if (!ret && i > SN_LINK_TRAINING_TRIES / 2)
> + DRM_DEV_INFO(pdata->dev, "Link training needed %d retries\n",
> i);
> +
> exit:
> /* Disable the PLL if we failed */
> if (ret)
Apologies for the previous HTML email, I was trying a new mail client
and... will not be switching to it.
Anyway.. again, this time in text..
Tested on the Lenovo C630, and haven’t seen the message, although I
hadn’t seen the described issue before either.
Tested-By: Steev Klimaszewski
[PATCH rdma-next v5 4/4] RDMA/umem: Move to allocate SG table from pages
From: Maor Gottlieb
Remove the implementation of ib_umem_add_sg_table and instead
call to __sg_alloc_table_from_pages which already has the logic to
merge contiguous pages.
Besides that it removes duplicated functionality, it reduces the
memory consumption of the SG table significantly. Prior to this
patch, the SG table was allocated in advance regardless consideration
of contiguous pages.
In huge pages system of 2MB page size, without this change, the SG table
would contain x512 SG entries.
E.g. for 100GB memory registration:
Number of entries Size
Before26214400 600.0MB
After512001.2MB
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/umem.c | 94 +-
1 file changed, 12 insertions(+), 82 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index c1ab6a4f2bc3..e9fecbdf391b 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -61,73 +61,6 @@ static void __ib_umem_release(struct ib_device *dev, struct
ib_umem *umem, int d
sg_free_table(>sg_head);
}
-/* ib_umem_add_sg_table - Add N contiguous pages to scatter table
- *
- * sg: current scatterlist entry
- * page_list: array of npage struct page pointers
- * npages: number of pages in page_list
- * max_seg_sz: maximum segment size in bytes
- * nents: [out] number of entries in the scatterlist
- *
- * Return new end of scatterlist
- */
-static struct scatterlist *ib_umem_add_sg_table(struct scatterlist *sg,
- struct page **page_list,
- unsigned long npages,
- unsigned int max_seg_sz,
- int *nents)
-{
- unsigned long first_pfn;
- unsigned long i = 0;
- bool update_cur_sg = false;
- bool first = !sg_page(sg);
-
- /* Check if new page_list is contiguous with end of previous page_list.
-* sg->length here is a multiple of PAGE_SIZE and sg->offset is 0.
-*/
- if (!first && (page_to_pfn(sg_page(sg)) + (sg->length >> PAGE_SHIFT) ==
- page_to_pfn(page_list[0])))
- update_cur_sg = true;
-
- while (i != npages) {
- unsigned long len;
- struct page *first_page = page_list[i];
-
- first_pfn = page_to_pfn(first_page);
-
- /* Compute the number of contiguous pages we have starting
-* at i
-*/
- for (len = 0; i != npages &&
- first_pfn + len == page_to_pfn(page_list[i]) &&
- len < (max_seg_sz >> PAGE_SHIFT);
-len++)
- i++;
-
- /* Squash N contiguous pages from page_list into current sge */
- if (update_cur_sg) {
- if ((max_seg_sz - sg->length) >= (len << PAGE_SHIFT)) {
- sg_set_page(sg, sg_page(sg),
- sg->length + (len << PAGE_SHIFT),
- 0);
- update_cur_sg = false;
- continue;
- }
- update_cur_sg = false;
- }
-
- /* Squash N contiguous pages into next sge or first sge */
- if (!first)
- sg = sg_next(sg);
-
- (*nents)++;
- sg_set_page(sg, first_page, len << PAGE_SHIFT, 0);
- first = false;
- }
-
- return sg;
-}
-
/**
* ib_umem_find_best_pgsz - Find best HW page size to use for this MR
*
@@ -217,7 +150,7 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
struct mm_struct *mm;
unsigned long npages;
int ret;
- struct scatterlist *sg;
+ struct scatterlist *sg = NULL;
unsigned int gup_flags = FOLL_WRITE;
/*
@@ -272,15 +205,9 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
cur_base = addr & PAGE_MASK;
- ret = sg_alloc_table(>sg_head, npages, GFP_KERNEL);
- if (ret)
- goto vma;
-
if (!umem->writable)
gup_flags |= FOLL_FORCE;
- sg = umem->sg_head.sgl;
-
while (npages) {
cond_resched();
ret = pin_user_pages_fast(cur_base,
@@ -292,15 +219,19 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
goto umem_release;
cur_base += ret * PAGE_SIZE;
- npages -= ret;
-
- sg = ib_umem_add_sg_table(sg, page_list, ret,
- dma_get_max_seg_size(device->dma_device),
- >sg_nents);
+
[PATCH rdma-next v5 1/4] lib/scatterlist: Add support in dynamic allocation of SG table from pages
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers that can't supply
all the pages at one time.
This function returns the last populated SGE in the table. Users should
pass it as an argument to the function from the second call and forward.
As before, nents will be equal to the number of populated SGEs (chunks).
With this new extension, drivers can benefit the optimization of merging
contiguous pages without a need to allocate all pages in advance and
hold them in a large buffer.
E.g. with the Infiniband driver that allocates a single page for hold the
pages. For 1TB memory registration, the temporary buffer would consume only
4KB, instead of 2GB.
Signed-off-by: Maor Gottlieb
Reviewed-by: Christoph Hellwig
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 ++-
include/linux/scatterlist.h | 38 +++---
lib/scatterlist.c | 125
tools/testing/scatterlist/main.c| 9 +-
5 files changed, 142 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 12b30075134a..f2eaed6aca3d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -403,6 +403,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
unsigned int max_segment = i915_sg_segment_size();
struct sg_table *st;
unsigned int sg_page_sizes;
+ struct scatterlist *sg;
int ret;
st = kmalloc(sizeof(*st), GFP_KERNEL);
@@ -410,13 +411,12 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
return ERR_PTR(-ENOMEM);
alloc_table:
- ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
- 0, num_pages << PAGE_SHIFT,
- max_segment,
- GFP_KERNEL);
- if (ret) {
+ sg = __sg_alloc_table_from_pages(st, pvec, num_pages, 0,
+num_pages << PAGE_SHIFT, max_segment,
+NULL, 0, GFP_KERNEL);
+ if (IS_ERR(sg)) {
kfree(st);
- return ERR_PTR(ret);
+ return ERR_CAST(sg);
}
ret = i915_gem_gtt_prepare_pages(obj, st);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index ab524ab3b0b4..f22acd398b1f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -419,6 +419,7 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
int ret = 0;
static size_t sgl_size;
static size_t sgt_size;
+ struct scatterlist *sg;
if (vmw_tt->mapped)
return 0;
@@ -441,13 +442,15 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
if (unlikely(ret != 0))
return ret;
- ret = __sg_alloc_table_from_pages
- (_tt->sgt, vsgt->pages, vsgt->num_pages, 0,
-(unsigned long) vsgt->num_pages << PAGE_SHIFT,
-dma_get_max_seg_size(dev_priv->dev->dev),
-GFP_KERNEL);
- if (unlikely(ret != 0))
+ sg = __sg_alloc_table_from_pages(_tt->sgt, vsgt->pages,
+ vsgt->num_pages, 0,
+ (unsigned long) vsgt->num_pages << PAGE_SHIFT,
+ dma_get_max_seg_size(dev_priv->dev->dev),
+ NULL, 0, GFP_KERNEL);
+ if (IS_ERR(sg)) {
+ ret = PTR_ERR(sg);
goto out_sg_alloc_fail;
+ }
if (vsgt->num_pages > vmw_tt->sgt.nents) {
uint64_t over_alloc =
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 45cf7b69d852..36c47e7e66a2 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -165,6 +165,22 @@ static inline void sg_set_buf(struct scatterlist *sg,
const void *buf,
#define for_each_sgtable_dma_sg(sgt, sg, i)\
for_each_sg((sgt)->sgl, sg, (sgt)->nents, i)
+static inline void __sg_chain(struct scatterlist *chain_sg,
+ struct scatterlist *sgl)
+{
+ /*
+* offset and length are unused for chain entry. Clear them.
+*/
+ chain_sg->offset = 0;
+ chain_sg->length = 0;
+
+ /*
+* Set lowest bit to indicate a link pointer, and make sure to clear
+* the termination bit if it happens to be set.
+*/
+ chain_sg->page_link = ((unsigned long) sgl | SG_CHAIN) & ~SG_END;
+}
+
/**
*
[PATCH rdma-next v5 2/4] tools/testing/scatterlist: Rejuvenate bit-rotten test
From: Tvrtko Ursulin
A couple small tweaks are needed to make the test build and run
on current kernels.
Signed-off-by: Tvrtko Ursulin
Cc: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
tools/testing/scatterlist/Makefile | 3 ++-
tools/testing/scatterlist/linux/mm.h | 35
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/tools/testing/scatterlist/Makefile
b/tools/testing/scatterlist/Makefile
index cbb003d9305e..c65233876622 100644
--- a/tools/testing/scatterlist/Makefile
+++ b/tools/testing/scatterlist/Makefile
@@ -14,7 +14,7 @@ targets: include $(TARGETS)
main: $(OFILES)
clean:
- $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h
linux/highmem.h linux/kmemleak.h asm/io.h
+ $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h
linux/highmem.h linux/kmemleak.h linux/slab.h asm/io.h
@rmdir asm
scatterlist.c: ../../../lib/scatterlist.c
@@ -28,4 +28,5 @@ include: ../../../include/linux/scatterlist.h
@touch asm/io.h
@touch linux/highmem.h
@touch linux/kmemleak.h
+ @touch linux/slab.h
@cp $< linux/scatterlist.h
diff --git a/tools/testing/scatterlist/linux/mm.h
b/tools/testing/scatterlist/linux/mm.h
index 6f9ac14aa800..6ae907f375d2 100644
--- a/tools/testing/scatterlist/linux/mm.h
+++ b/tools/testing/scatterlist/linux/mm.h
@@ -114,6 +114,12 @@ static inline void *kmalloc(unsigned int size, unsigned
int flags)
return malloc(size);
}
+static inline void *
+kmalloc_array(unsigned int n, unsigned int size, unsigned int flags)
+{
+ return malloc(n * size);
+}
+
#define kfree(x) free(x)
#define kmemleak_alloc(a, b, c, d)
@@ -122,4 +128,33 @@ static inline void *kmalloc(unsigned int size, unsigned
int flags)
#define PageSlab(p) (0)
#define flush_kernel_dcache_page(p)
+#define MAX_ERRNO 4095
+
+#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned
long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error)
+{
+ return (void *) error;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+ return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr)
+{
+ if (IS_ERR(ptr))
+ return PTR_ERR(ptr);
+ else
+ return 0;
+}
+
+#define IS_ENABLED(x) (0)
+
#endif
--
2.26.2
[PATCH rdma-next v5 0/4] Dynamicaly allocate SG table from the pages
From: Leon Romanovsky Changelog: v5: * Use sg_init_table to allocate table and avoid changes is __sg_alloc_table * Fix offset issue v4: https://lore.kernel.org/lkml/20200927064647.3106737-1-l...@kernel.org * Fixed formatting in first patch. * Added fix (clear tmp_netnts) in first patch to fix i915 failure. * Added test patches v3: https://lore.kernel.org/linux-rdma/20200922083958.2150803-1-l...@kernel.org/ * Squashed Christopher's suggestion to avoid introduced new API, but extend existing one. v2: https://lore.kernel.org/linux-rdma/20200916140726.839377-1-l...@kernel.org * Fixed indentations and comments * Deleted sg_alloc_next() * Squashed lib/scatterlist patches into one v1: https://lore.kernel.org/lkml/20200910134259.1304543-1-l...@kernel.org * Changed _sg_chain to be __sg_chain * Added dependency on ARCH_NO_SG_CHAIN * Removed struct sg_append v0: * https://lore.kernel.org/lkml/20200903121853.1145976-1-l...@kernel.org -- >From Maor: This series extends __sg_alloc_table_from_pages to allow chaining of new pages to already initialized SG table. This allows for the drivers to utilize the optimization of merging contiguous pages without a need to pre allocate all the pages and hold them in a very large temporary buffer prior to the call to SG table initialization. The second patch changes the Infiniband driver to use the new API. It removes duplicate functionality from the code and benefits the optimization of allocating dynamic SG table from pages. In huge pages system of 2MB page size, without this change, the SG table would contain x512 SG entries. E.g. for 100GB memory registration: Number of entries Size Before26214400 600.0MB After512001.2MB Thanks Maor Gottlieb (2): lib/scatterlist: Add support in dynamic allocation of SG table from pages RDMA/umem: Move to allocate SG table from pages Tvrtko Ursulin (2): tools/testing/scatterlist: Rejuvenate bit-rotten test tools/testing/scatterlist: Show errors in human readable form drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 ++- drivers/infiniband/core/umem.c | 94 ++- include/linux/scatterlist.h | 38 +++--- lib/scatterlist.c | 125 tools/testing/scatterlist/Makefile | 3 +- tools/testing/scatterlist/linux/mm.h| 35 ++ tools/testing/scatterlist/main.c| 53 ++--- 8 files changed, 225 insertions(+), 150 deletions(-) -- 2.26.2
[PATCH rdma-next v5 3/4] tools/testing/scatterlist: Show errors in human readable form
From: Tvrtko Ursulin
Instead of just asserting dump some more useful info about what the test
saw versus what it expected to see.
Signed-off-by: Tvrtko Ursulin
Cc: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
tools/testing/scatterlist/main.c | 44
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 4899359a31ac..b2c7e9f7b8d3 100644
--- a/tools/testing/scatterlist/main.c
+++ b/tools/testing/scatterlist/main.c
@@ -5,6 +5,15 @@
#define MAX_PAGES (64)
+struct test {
+ int alloc_ret;
+ unsigned num_pages;
+ unsigned *pfn;
+ unsigned size;
+ unsigned int max_seg;
+ unsigned int expected_segments;
+};
+
static void set_pages(struct page **pages, const unsigned *array, unsigned num)
{
unsigned int i;
@@ -17,17 +26,32 @@ static void set_pages(struct page **pages, const unsigned
*array, unsigned num)
#define pfn(...) (unsigned []){ __VA_ARGS__ }
+static void fail(struct test *test, struct sg_table *st, const char *cond)
+{
+ unsigned int i;
+
+ fprintf(stderr, "Failed on '%s'!\n\n", cond);
+
+ printf("size = %u, max segment = %u, expected nents = %u\nst->nents =
%u, st->orig_nents= %u\n",
+ test->size, test->max_seg, test->expected_segments, st->nents,
+ st->orig_nents);
+
+ printf("%u input PFNs:", test->num_pages);
+ for (i = 0; i < test->num_pages; i++)
+ printf(" %x", test->pfn[i]);
+ printf("\n");
+
+ exit(1);
+}
+
+#define VALIDATE(cond, st, test) \
+ if (!(cond)) \
+ fail((test), (st), #cond);
+
int main(void)
{
const unsigned int sgmax = SCATTERLIST_MAX_SEGMENT;
- struct test {
- int alloc_ret;
- unsigned num_pages;
- unsigned *pfn;
- unsigned size;
- unsigned int max_seg;
- unsigned int expected_segments;
- } *test, tests[] = {
+ struct test *test, tests[] = {
{ -EINVAL, 1, pfn(0), PAGE_SIZE, PAGE_SIZE + 1, 1 },
{ -EINVAL, 1, pfn(0), PAGE_SIZE, 0, 1 },
{ -EINVAL, 1, pfn(0), PAGE_SIZE, sgmax + 1, 1 },
@@ -66,8 +90,8 @@ int main(void)
if (test->alloc_ret)
continue;
- assert(st.nents == test->expected_segments);
- assert(st.orig_nents == test->expected_segments);
+ VALIDATE(st.nents == test->expected_segments, , test);
+ VALIDATE(st.orig_nents == test->expected_segments, , test);
sg_free_table();
}
--
2.26.2
Re: [PATCH v4 2/2] hwmon: pmbus: max20730: adjust the vout reading given voltage divider
On Sun, Oct 04, 2020 at 03:14:45AM +, Chu Lin wrote:
> Problem:
> We use voltage dividers so that the voltage presented at the voltage
> sense pins is confusing. We might need to convert these readings to more
> meaningful readings given the voltage divider.
>
> Solution:
> Read the voltage divider resistance from dts and convert the voltage
> reading to a more meaningful reading.
>
> Testing:
> max20730 with voltage divider
>
> Signed-off-by: Chu Lin
> ---
> ChangeLog v1 -> v2
> hwmon: pmbus: max20730:
> - Don't do anything to the ret if an error is returned from pmbus_read_word
> - avoid overflow when doing multiplication
>
> ChangeLog v2 -> v3
> dt-bindings: hwmon: max20730:
> - Provide the binding documentation in yaml format
> hwmon: pmbus: max20730:
> - No change
>
> ChangeLog v3 -> v4
> dt-bindings: hwmon: max20730:
> - Fix highefficiency to high efficiency in description
> - Fix presents to present in vout-voltage-divider
> - Add additionalProperties: false
> hwmon: pmbus: max20730:
> - No change
You claim that there have been no changes since v2 of this patch,
yet you dropped my Reviewed-by: tag. Any reason ?
Guenter
>
> drivers/hwmon/pmbus/max20730.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
> index a151a2b588a5..fbf2f1e6c969 100644
> --- a/drivers/hwmon/pmbus/max20730.c
> +++ b/drivers/hwmon/pmbus/max20730.c
> @@ -31,6 +31,7 @@ struct max20730_data {
> struct pmbus_driver_info info;
> struct mutex lock; /* Used to protect against parallel writes */
> u16 mfr_devset1;
> + u32 vout_voltage_divider[2];
> };
>
> #define to_max20730_data(x) container_of(x, struct max20730_data, info)
> @@ -114,6 +115,14 @@ static int max20730_read_word_data(struct i2c_client
> *client, int page,
> max_c = max_current[data->id][(data->mfr_devset1 >> 5) & 0x3];
> ret = val_to_direct(max_c, PSC_CURRENT_OUT, info);
> break;
> + case PMBUS_READ_VOUT:
> + ret = pmbus_read_word_data(client, page, phase, reg);
> + if (ret > 0 && data->vout_voltage_divider[0] &&
> data->vout_voltage_divider[1]) {
> + u64 temp = DIV_ROUND_CLOSEST_ULL((u64)ret *
> data->vout_voltage_divider[1],
> +
> data->vout_voltage_divider[0]);
> + ret = clamp_val(temp, 0, 0x);
> + }
> + break;
> default:
> ret = -ENODATA;
> break;
> @@ -364,6 +373,15 @@ static int max20730_probe(struct i2c_client *client,
> data->id = chip_id;
> mutex_init(>lock);
> memcpy(>info, _info[chip_id], sizeof(data->info));
> + if (of_property_read_u32_array(client->dev.of_node,
> "vout-voltage-divider",
> +data->vout_voltage_divider,
> +ARRAY_SIZE(data->vout_voltage_divider))
> != 0)
> + memset(data->vout_voltage_divider, 0,
> sizeof(data->vout_voltage_divider));
> + if (data->vout_voltage_divider[1] < data->vout_voltage_divider[0]) {
> + dev_err(dev,
> + "The total resistance of voltage divider is less than
> output resistance\n");
> + return -ENODEV;
> + }
>
> ret = i2c_smbus_read_word_data(client, MAX20730_MFR_DEVSET1);
> if (ret < 0)
> --
> 2.28.0.806.g8561365e88-goog
>
[PATCH v6] ipvs: adjust the debug info in function set_tcp_state
Outputting client,virtual,dst addresses info when tcp state changes,
which makes the connection debug more clear
---
v5,v6: fix indentation and add changelogs
v3,v4: fix checkpatch
v2: IP_VS_DBG_BUF outputs src,virtual,dst of ip_vs_conn
v1: fix the inverse of src and dst address
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_proto_tcp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c
b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index dc2e7da2742a..7da51390cea6 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -539,8 +539,8 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct
ip_vs_conn *cp,
if (new_state != cp->state) {
struct ip_vs_dest *dest = cp->dest;
- IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] %s:%d->"
- "%s:%d state: %s->%s conn->refcnt:%d\n",
+ IP_VS_DBG_BUF(8, "%s %s [%c%c%c%c] c:%s:%d v:%s:%d "
+ "d:%s:%d state: %s->%s conn->refcnt:%d\n",
pd->pp->name,
((state_off == TCP_DIR_OUTPUT) ?
"output " : "input "),
@@ -548,10 +548,12 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct
ip_vs_conn *cp,
th->fin ? 'F' : '.',
th->ack ? 'A' : '.',
th->rst ? 'R' : '.',
- IP_VS_DBG_ADDR(cp->daf, >daddr),
- ntohs(cp->dport),
IP_VS_DBG_ADDR(cp->af, >caddr),
ntohs(cp->cport),
+ IP_VS_DBG_ADDR(cp->af, >vaddr),
+ ntohs(cp->vport),
+ IP_VS_DBG_ADDR(cp->daf, >daddr),
+ ntohs(cp->dport),
tcp_state_name(cp->state),
tcp_state_name(new_state),
refcount_read(>refcnt));
--
2.20.1 (Apple Git-117)
Re: [PATCH 1/2] usb: serial: qmi_wwan: add Cellient MPL200 card
Wilken Gottwalt writes:
> Add usb ids of the Cellient MPL200 card.
>
> Signed-off-by: Wilken Gottwalt
> ---
> drivers/net/usb/qmi_wwan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 07c42c0719f5..0bf2b19d5d54 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
This is not a 'usb: serial' driver. Please resend with a less confusing
subject prefix.
> @@ -1432,6 +1432,7 @@ static const struct usb_device_id products[] = {
> {QMI_GOBI_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */
> {QMI_GOBI_DEVICE(0x12d1, 0x14f1)}, /* Sony Gobi 3000 Composite */
> {QMI_GOBI_DEVICE(0x1410, 0xa021)}, /* Foxconn Gobi 3000 Modem
> device (Novatel E396) */
> + {QMI_FIXED_INTF(0x2692, 0x9025, 4)},/* Cellient MPL200 (rebranded
> Qualcomm 0x05c6) */
>
> { } /* END */
> };
This table is supposed to be organized by device type. The last section
is for Gobi2k and Gobi3k devices. Please try to put new devices into
the correct section.
Thanks
Bjørn
[PATCH v6] ipvs: inspect reply packets from DR/TUN real servers
Just like for MASQ, inspect the reply packets coming from DR/TUN
real servers and alter the connection's state and timeout
according to the protocol.
It's ipvs's duty to do traffic statistic if packets get hit,
no matter what mode it is.
---
Changes in v1: support DR/TUN mode statistic
Changes in v2: ip_vs_conn_out_get handles DR/TUN mode's conn
Changes in v3: fix checkpatch
Changes in v4, v5: restructure and optimise this feature
Changes in v6: rewrite subject and patch description
Signed-off-by: longguang.yue
---
net/netfilter/ipvs/ip_vs_conn.c | 18 +++---
net/netfilter/ipvs/ip_vs_core.c | 17 ++---
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index a90b8eac16ac..af08ca2d9174 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -401,6 +401,8 @@ struct ip_vs_conn *ip_vs_ct_in_get(const struct
ip_vs_conn_param *p)
struct ip_vs_conn *ip_vs_conn_out_get(const struct ip_vs_conn_param *p)
{
unsigned int hash;
+ __be16 sport;
+ const union nf_inet_addr *saddr;
struct ip_vs_conn *cp, *ret=NULL;
/*
@@ -411,10 +413,20 @@ struct ip_vs_conn *ip_vs_conn_out_get(const struct
ip_vs_conn_param *p)
rcu_read_lock();
hlist_for_each_entry_rcu(cp, _vs_conn_tab[hash], c_list) {
- if (p->vport == cp->cport && p->cport == cp->dport &&
- cp->af == p->af &&
+ if (p->vport != cp->cport)
+ continue;
+
+ if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ) {
+ sport = cp->vport;
+ saddr = >vaddr;
+ } else {
+ sport = cp->dport;
+ saddr = >daddr;
+ }
+
+ if (p->cport == sport && cp->af == p->af &&
ip_vs_addr_equal(p->af, p->vaddr, >caddr) &&
- ip_vs_addr_equal(p->af, p->caddr, >daddr) &&
+ ip_vs_addr_equal(p->af, p->caddr, saddr) &&
p->protocol == cp->protocol &&
cp->ipvs == p->ipvs) {
if (!__ip_vs_conn_get(cp))
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index e3668a6e54e4..494ea1fcf4d8 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -875,7 +875,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
unsigned int verdict = NF_DROP;
if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
- goto ignore_cp;
+ goto after_nat;
/* Ensure the checksum is correct */
if (!skb_csum_unnecessary(skb) && ip_vs_checksum_complete(skb, ihl)) {
@@ -900,7 +900,7 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
if (ip_vs_route_me_harder(cp->ipvs, af, skb, hooknum))
goto out;
-
+after_nat:
/* do the statistics and put it back */
ip_vs_out_stats(cp, skb);
@@ -909,8 +909,6 @@ static int handle_response_icmp(int af, struct sk_buff *skb,
ip_vs_notrack(skb);
else
ip_vs_update_conntrack(skb, cp, 0);
-
-ignore_cp:
verdict = NF_ACCEPT;
out:
@@ -1276,6 +1274,9 @@ handle_response(int af, struct sk_buff *skb, struct
ip_vs_proto_data *pd,
{
struct ip_vs_protocol *pp = pd->pp;
+ if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
+ goto after_nat;
+
IP_VS_DBG_PKT(11, af, pp, skb, iph->off, "Outgoing packet");
if (skb_ensure_writable(skb, iph->len))
@@ -1316,6 +1317,7 @@ handle_response(int af, struct sk_buff *skb, struct
ip_vs_proto_data *pd,
IP_VS_DBG_PKT(10, af, pp, skb, iph->off, "After SNAT");
+after_nat:
ip_vs_out_stats(cp, skb);
ip_vs_set_state(cp, IP_VS_DIR_OUTPUT, skb, pd);
skb->ipvs_property = 1;
@@ -1413,8 +1415,6 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum,
struct sk_buff *skb, in
ipvs, af, skb, );
if (likely(cp)) {
- if (IP_VS_FWD_METHOD(cp) != IP_VS_CONN_F_MASQ)
- goto ignore_cp;
return handle_response(af, skb, pd, cp, , hooknum);
}
@@ -1475,14 +1475,9 @@ ip_vs_out(struct netns_ipvs *ipvs, unsigned int hooknum,
struct sk_buff *skb, in
}
}
-out:
IP_VS_DBG_PKT(12, af, pp, skb, iph.off,
"ip_vs_out: packet continues traversal as normal");
return NF_ACCEPT;
-
-ignore_cp:
- __ip_vs_conn_put(cp);
- goto out;
}
/*
--
2.20.1 (Apple Git-117)
Re: [Linux-kernel-mentees] [PATCH] fs: fix KMSAN uninit-value bug by initializing nd in do_file_open_root
On 20-09-2020 01:47, Anant Thazhemadam wrote: > On 19-09-2020 17:03, Anant Thazhemadam wrote: >> On 19-09-2020 22:25, Al Viro wrote: >>> On Sat, Sep 19, 2020 at 05:17:27PM +0100, Al Viro wrote: >>> Lovely... That would get an empty path and non-directory for a starting point, but it should end up with LAST_ROOT in nd->last_type. Which should not be able to reach the readers of those fields... Which kernel had that been on? >>> Yecchhh... I see what's going on; I suspect that this ought to be enough. >>> Folks, could somebody test it on the original reproducer setup? >> Sure. I can do that. > Looks like this patch actually fixes this bug. > I made syzbot test the patch, and no issues were triggered! > > Note: syzbot tested the patch with the KMSAN kernel, which > was recently rebased on v5.9-rc4. > > Thanks, > Anant Ping. Has the patch that was tested been applied to any tree yet? If yes, could someone please let me know the commit details, so we can close the issue? (Unfortunately, I was unable to find it. :( ) Thanks, Anant
Re: [EXT] Re: [PATCH v4 10/13] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu()
On Thu, 2020-10-01 at 16:44 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:57:33PM +, Alex Belits wrote:
> > From: Yuri Norov
> >
> > For nohz_full CPUs the desirable behavior is to receive interrupts
> > generated by tick_nohz_full_kick_cpu(). But for hard isolation it's
> > obviously not desirable because it breaks isolation.
> >
> > This patch adds check for it.
> >
> > Signed-off-by: Yuri Norov
> > [abel...@marvell.com: updated, only exclude CPUs running isolated
> > tasks]
> > Signed-off-by: Alex Belits
> > ---
> > kernel/time/tick-sched.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 6e4cd8459f05..2f82a6daf8fc 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -268,7 +269,8 @@ static void tick_nohz_full_kick(void)
> > */
> > void tick_nohz_full_kick_cpu(int cpu)
> > {
> > - if (!tick_nohz_full_cpu(cpu))
> > + smp_rmb();
>
> What is it ordering?
ll_isol_flags will be read in task_isolation_on_cpu(), that accrss
should be ordered against writing in
task_isolation_kernel_enter(), fast_task_isolation_cpu_cleanup()
and task_isolation_start().
Since task_isolation_on_cpu() is often called for multiple CPUs in a
sequence, it would be wasteful to include a barrier inside it.
> > + if (!tick_nohz_full_cpu(cpu) || task_isolation_on_cpu(cpu))
> > return;
>
> You can't simply ignore an IPI. There is always a reason for a
> nohz_full CPU
> to be kicked. Something triggered a tick dependency. It can be posix
> cpu timers
> for example, or anything.
I realize that this is unusual, however the idea is that while the task
is running in isolated mode in userspace, we assume that from this CPUs
point of view whatever is happening in kernel, can wait until CPU is
back in kernel, and when it first enters kernel from this mode, it
should "catch up" with everything that happened in its absence.
task_isolation_kernel_enter() is supposed to do that, so by the time
anything should be done involving the rest of the kernel, CPU is back
to normal.
It is application's responsibility to avoid triggering things that
break its isolation, so the application assumes that everything that
involves entering kernel will not be available while it is isolated. If
isolation will be broken, or application will request return from
isolation, everything will go back to normal environment with all
functionality available.
> >
> > irq_work_queue_on(_cpu(nohz_full_kick_work, cpu), cpu);
> > --
> > 2.26.2
> >
Re: [PATCH v4] staging: qlge: fix build breakage with dumping enabled
On Sat, Oct 03, 2020 at 02:53:48PM +0900, Benjamin Poirier wrote:
On 2020-10-03 07:59 +0800, Coiby Xu wrote:
This fixes commit 0107635e15ac
("staging: qlge: replace pr_err with netdev_err") which introduced an
build breakage of missing `struct ql_adapter *qdev` for some functions
and a warning of type mismatch with dumping enabled, i.e.,
$ make CFLAGS_MODULE="-DQL_ALL_DUMP -DQL_OB_DUMP -DQL_CB_DUMP \
-DQL_IB_DUMP -DQL_REG_DUMP -DQL_DEV_DUMP" M=drivers/staging/qlge
qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’:
qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this function); did
you mean ‘cdev’?
2051 | netdev_err(qdev->ndev, "%s\n", __func__);
| ^~~~
qlge_dbg.c: In function ‘ql_dump_routing_entries’:
qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 3 has type ‘int’ [-Wformat=]
1435 |"%s: Routing Mask %d = 0x%.08x\n",
| ~^
| |
| char *
| %d
1436 |i, value);
|~
||
|int
qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned int’
argument [-Wformat=]
1435 |"%s: Routing Mask %d = 0x%.08x\n",
| ^
| |
| unsigned int
Note that now ql_dump_rx_ring/ql_dump_tx_ring won't check if the passed
parameter is a null pointer.
Fixes: 0107635e15ac ("staging: qlge: replace pr_err with netdev_err")
Reported-by: Benjamin Poirier
Suggested-by: Benjamin Poirier
Signed-off-by: Coiby Xu
---
Reviewed-by: Benjamin Poirier
Thank you! Btw, I guess when this patch is picked, the "Reviewed-by" tag
will also be included. So I needn't to send another patch, am I right?
--
Best regards,
Coiby
Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel
On Thu, 2020-10-01 at 16:40 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:49:49PM +, Alex Belits wrote:
> > +/**
> > + * task_isolation_kernel_enter() - clear low-level task isolation
> > flag
> > + *
> > + * This should be called immediately after entering kernel.
> > + */
> > +static inline void task_isolation_kernel_enter(void)
> > +{
> > + unsigned long flags;
> > +
> > + /*
> > +* This function runs on a CPU that ran isolated task.
> > +*
> > +* We don't want this CPU running code from the rest of kernel
> > +* until other CPUs know that it is no longer isolated.
> > +* When CPU is running isolated task until this point anything
> > +* that causes an interrupt on this CPU must end up calling
> > this
> > +* before touching the rest of kernel. That is, this function
> > or
> > +* fast_task_isolation_cpu_cleanup() or stop_isolation()
> > calling
> > +* it. If any interrupt, including scheduling timer, arrives,
> > it
> > +* will still end up here early after entering kernel.
> > +* From this point interrupts are disabled until all CPUs will
> > see
> > +* that this CPU is no longer running isolated task.
> > +*
> > +* See also fast_task_isolation_cpu_cleanup().
> > +*/
> > + smp_rmb();
>
> I'm a bit confused what this read memory barrier is ordering. Also
> against
> what it pairs.
My bad, I have kept it after there were left no write accesses from
other CPUs.
>
> > + if((this_cpu_read(ll_isol_flags) & FLAG_LL_TASK_ISOLATION) ==
> > 0)
> > + return;
> > +
> > + local_irq_save(flags);
> > +
> > + /* Clear low-level flags */
> > + this_cpu_write(ll_isol_flags, 0);
> > +
> > + /*
> > +* If something happened that requires a barrier that would
> > +* otherwise be called from remote CPUs by CPU kick procedure,
> > +* this barrier runs instead of it. After this barrier, CPU
> > +* kick procedure would see the updated ll_isol_flags, so it
> > +* will run its own IPI to trigger a barrier.
> > +*/
> > + smp_mb();
> > + /*
> > +* Synchronize instructions -- this CPU was not kicked while
> > +* in isolated mode, so it might require synchronization.
> > +* There might be an IPI if kick procedure happened and
> > +* ll_isol_flags was already updated while it assembled a CPU
> > +* mask. However if this did not happen, synchronize everything
> > +* here.
> > +*/
> > + instr_sync();
>
> It's the first time I meet an instruction barrier. I should get
> information
> about that but what is it ordering here?
Against barriers in instruction cache flushing (flush_icache_range()
and such).
> > + local_irq_restore(flags);
> > +}
>
> Thanks.
Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver
On Sun, Oct 04, 2020 at 05:32:57PM +0300, Jarkko Sakkinen wrote: > On Sat, Oct 03, 2020 at 04:39:25PM +0200, Greg KH wrote: > > You use gpl-only header files in this file, so how in the world can it > > be bsd-3 licensed? > > > > Please get your legal department to agree with this, after you explain > > to them how you are mixing gpl2-only code in with this file. > > I'll do what I already stated that I will do. Should I do something > more? And forward this message to the aformentioned entity. /Jarkko
Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel
On Thu, 2020-10-01 at 15:56 +0200, Frederic Weisbecker wrote:
> External Email
>
> ---
> ---
> On Wed, Jul 22, 2020 at 02:49:49PM +, Alex Belits wrote:
> > +/*
> > + * Description of the last two tasks that ran isolated on a given
> > CPU.
> > + * This is intended only for messages about isolation breaking. We
> > + * don't want any references to actual task while accessing this
> > from
> > + * CPU that caused isolation breaking -- we know nothing about
> > timing
> > + * and don't want to use locking or RCU.
> > + */
> > +struct isol_task_desc {
> > + atomic_t curr_index;
> > + atomic_t curr_index_wr;
> > + boolwarned[2];
> > + pid_t pid[2];
> > + pid_t tgid[2];
> > + charcomm[2][TASK_COMM_LEN];
> > +};
> > +static DEFINE_PER_CPU(struct isol_task_desc, isol_task_descs);
>
> So that's quite a huge patch that would have needed to be split up.
> Especially this tracing engine.
>
> Speaking of which, I agree with Thomas that it's unnecessary. It's
> too much
> code and complexity. We can use the existing trace events and perform
> the
> analysis from userspace to find the source of the disturbance.
The idea behind this is that isolation breaking events are supposed to
be known to the applications while applications run normally, and they
should not require any analysis or human intervention to be handled.
A process may exit isolation because some leftover delayed work, for
example, a timer or a workqueue, is still present on a CPU, or because
a page fault or some other exception, normally handled silently, is
caused by the task. It is also possible to direct an interrupt to a CPU
that is running an isolated task -- currently it's perfectly valid to
set interrupt smp affinity to a CPU running isolated task, and then
interrupt will cause breaking isolation. While it's probably not the
best way of handling interrupts, I would rather not prohibit this
explicitly.
There is also a matter of avoiding race conditions on entering
isolation. Once CPU entered isolation, other CPUs should avoid
disturbing it when they know that CPU is running a task in isolated
mode. However for a short time after entering isolation other CPUs may
be unaware of this, and will still send IPIs to it. Preventing this
scenario completely would be very costly in terms of what other CPUs
will have to do before notifying others, so similar to how EINTR works,
we can simply specify that this is allowed, and task is supposed to re-
enter isolation after this. It's still a bad idea to specify that
isolation breaking can continue happening while application is running
in isolated mode, however allowing some "grace period" after entering
is acceptable as long as application is aware of this happening.
In libtmc I have moved this handling of isolation breaking into a
separate thread, intended to become a separate daemon if necessary. In
part it was done because initial implementation of isolation made it
very difficult to avoid repeating delayed work on isolated CPUs, so
something had to watch for it from non-isolated CPU. It's possible that
now, when delayed work does not appear on isolated CPUs out of nowhere,
the need in isolation manager thread will disappear, and task itself
will be able to handle all isolation breaking, like original
implementation by Chris was supposed to.
However in either case it's still useful for the task, or isolation
manager, to get a description of the isolation-breaking event. This is
what those things are intended for. Now they only produce log messages
because this is where initially all description of isolation-breaking
events went, however I would prefer to make logging optional but always
let applications read those events descriptions, regardless of any
tracing mechanism being used. I was more focused on making the
reporting mechanism properly detect the cause of isolation breaking
because that functionality was not quite working in earlier work by
Chris and Yuri, so I have kept logging as the only output, but made it
suitable for producing events that applications will be able to
receive. Application, or isolation manager, will receive clear and
unambiguous reporting, so there will be no need for any additional
analysis or guesswork.
After adding a proper "low-level" isolation flags, I got the idea that
we might have a better yet reporting mechanism. Early isolation
breaking detection on kernel entry may set a flag that says that
isolation breaking happened, however its cause is unknown. Or, more
likely, only some general information about isolation breaking is
available, like a type of exception. Then, once a known isolation-
breaking reporting mechanism is called from interrupt, syscall, IPI or
exception processing, the flag is cleared, and reporting is supposed to
be done. However if then kernel returns to userspace on isolated task
but isolation breaking is not reported yet, an isolation breaking
reporting
Re: [PATCH 1/1] efi/libstub/x86: simplify efi_is_native()
On Sun, Oct 04, 2020 at 04:14:11PM +0200, Ard Biesheuvel wrote:
> On Sat, 3 Oct 2020 at 21:44, Arvind Sankar wrote:
> >
> > On Sat, Oct 03, 2020 at 01:28:18PM -0400, Brian Gerst wrote:
> > > On Sat, Oct 3, 2020 at 2:05 AM Heinrich Schuchardt
> > > wrote:
> > > >
> > > > CONFIG_EFI_MIXED depends on CONFIG_X86_64=y.
> > > > There is no need to check CONFIG_X86_64 again.
> > > >
> > > > Signed-off-by: Heinrich Schuchardt
> > > > ---
> > > > arch/x86/include/asm/efi.h | 2 --
> > > > 1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> > > > index b9c2667ac46c..ab28bf1c74cf 100644
> > > > --- a/arch/x86/include/asm/efi.h
> > > > +++ b/arch/x86/include/asm/efi.h
> > > > @@ -223,8 +223,6 @@ static inline bool efi_is_64bit(void)
> > > >
> > > > static inline bool efi_is_native(void)
> > > > {
> > > > - if (!IS_ENABLED(CONFIG_X86_64))
> > > > - return true;
> > > > return efi_is_64bit();
> > > > }
> > >
> > > This would then return false for native 32-bit.
> > >
> > > --
> > > Brian Gerst
> >
> > 32-bit doesn't use this implementation: it's #define'd to true in
> > drivers/firmware/efi/libstub/efistub.h.
> >
>
> Yes, and the reason this [now redundant] test exists is because this
> did not use to be the case before
>
> de8c55208c386 efi/libstub: Fix mixed mode boot issue after macro refactor
Heh, my fault for not cleaning it up then :)
>
> So for this patch
>
> Acked-by: Ard Biesheuvel
>
> I'll queue this up
Re: [PATCH v39 11/24] x86/sgx: Add SGX enclave driver
On Sat, Oct 03, 2020 at 04:39:25PM +0200, Greg KH wrote:
> On Sat, Oct 03, 2020 at 07:50:46AM +0300, Jarkko Sakkinen wrote:
> > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that can
> > be used by applications to set aside private regions of code and data. The
> > code outside the SGX hosted software entity is prevented from accessing the
> > memory inside the enclave by the CPU. We call these entities enclaves.
> >
> > Add a driver that provides an ioctl API to construct and run enclaves.
> > Enclaves are constructed from pages residing in reserved physical memory
> > areas. The contents of these pages can only be accessed when they are
> > mapped as part of an enclave, by a hardware thread running inside the
> > enclave.
> >
> > The starting state of an enclave consists of a fixed measured set of
> > pages that are copied to the EPC during the construction process by
> > using the opcode ENCLS leaf functions and Software Enclave Control
> > Structure (SECS) that defines the enclave properties.
> >
> > Enclaves are constructed by using ENCLS leaf functions ECREATE, EADD and
> > EINIT. ECREATE initializes SECS, EADD copies pages from system memory to
> > the EPC and EINIT checks a given signed measurement and moves the enclave
> > into a state ready for execution.
> >
> > An initialized enclave can only be accessed through special Thread Control
> > Structure (TCS) pages by using ENCLU (ring-3 only) leaf EENTER. This leaf
> > function converts a thread into enclave mode and continues the execution in
> > the offset defined by the TCS provided to EENTER. An enclave is exited
> > through syscall, exception, interrupts or by explicitly calling another
> > ENCLU leaf EEXIT.
> >
> > The mmap() permissions are capped by the contained enclave page
> > permissions. The mapped areas must also be populated, i.e. each page
> > address must contain a page. This logic is implemented in
> > sgx_encl_may_map().
> >
> > Cc: linux-security-mod...@vger.kernel.org
> > Cc: linux...@kvack.org
> > Cc: Andrew Morton
> > Cc: Matthew Wilcox
> > Acked-by: Jethro Beekman
> > Tested-by: Jethro Beekman
> > Tested-by: Haitao Huang
> > Tested-by: Chunyang Hui
> > Tested-by: Jordan Hand
> > Tested-by: Nathaniel McCallum
> > Tested-by: Seth Moore
> > Tested-by: Darren Kenny
> > Reviewed-by: Darren Kenny
> > Co-developed-by: Sean Christopherson
> > Signed-off-by: Sean Christopherson
> > Co-developed-by: Suresh Siddha
> > Signed-off-by: Suresh Siddha
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > arch/x86/kernel/cpu/sgx/Makefile | 2 +
> > arch/x86/kernel/cpu/sgx/driver.c | 173
> > arch/x86/kernel/cpu/sgx/driver.h | 29 +++
> > arch/x86/kernel/cpu/sgx/encl.c | 331 +++
> > arch/x86/kernel/cpu/sgx/encl.h | 85
> > arch/x86/kernel/cpu/sgx/main.c | 11 +
> > 6 files changed, 631 insertions(+)
> > create mode 100644 arch/x86/kernel/cpu/sgx/driver.c
> > create mode 100644 arch/x86/kernel/cpu/sgx/driver.h
> > create mode 100644 arch/x86/kernel/cpu/sgx/encl.c
> > create mode 100644 arch/x86/kernel/cpu/sgx/encl.h
> >
> > diff --git a/arch/x86/kernel/cpu/sgx/Makefile
> > b/arch/x86/kernel/cpu/sgx/Makefile
> > index 79510ce01b3b..3fc451120735 100644
> > --- a/arch/x86/kernel/cpu/sgx/Makefile
> > +++ b/arch/x86/kernel/cpu/sgx/Makefile
> > @@ -1,2 +1,4 @@
> > obj-y += \
> > + driver.o \
> > + encl.o \
> > main.o
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> > b/arch/x86/kernel/cpu/sgx/driver.c
> > new file mode 100644
> > index ..f54da5f19c2b
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
>
> You use gpl-only header files in this file, so how in the world can it
> be bsd-3 licensed?
>
> Please get your legal department to agree with this, after you explain
> to them how you are mixing gpl2-only code in with this file.
I'll do what I already stated that I will do. Should I do something
more?
> > +// Copyright(c) 2016-18 Intel Corporation.
>
> Dates are hard to get right :(
Will fix.
>
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "driver.h"
> > +#include "encl.h"
> > +
> > +u64 sgx_encl_size_max_32;
> > +u64 sgx_encl_size_max_64;
> > +u32 sgx_misc_reserved_mask;
> > +u64 sgx_attributes_reserved_mask;
> > +u64 sgx_xfrm_reserved_mask = ~0x3;
> > +u32 sgx_xsave_size_tbl[64];
> > +
> > +static int sgx_open(struct inode *inode, struct file *file)
> > +{
> > + struct sgx_encl *encl;
> > + int ret;
> > +
> > + encl = kzalloc(sizeof(*encl), GFP_KERNEL);
> > + if (!encl)
> > + return -ENOMEM;
> > +
> > + atomic_set(>flags, 0);
> > + kref_init(>refcount);
> > + xa_init(>page_array);
> > + mutex_init(>lock);
> > + INIT_LIST_HEAD(>mm_list);
> > + spin_lock_init(>mm_lock);
> > +
> > + ret = init_srcu_struct(>srcu);
> > + if
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
On 10/4/2020 21:16, Lars Melin wrote: On 10/4/2020 20:29, Leonid Bloch wrote: On 10/4/20 1:58 PM, Lars Melin wrote: On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. Please see below. Thanks, Leonid. ``` Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1054 bcdDevice 4.14 iManufacturer 1 Telit Wireless Solutions iProduct 2 FT980-KS iSerial 3 cb42f61 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x013d bNumInterfaces 8 bConfigurationValue 1 iConfiguration 4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 239 Miscellaneous Device bFunctionSubClass 4 bFunctionProtocol 1 iFunction 7 RNDIS Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 4 bInterfaceProtocol 1 iInterface 5 RNDIS Communications Control ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 04 24 02 00 ** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 RNDIS Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9
Re: virtiofs: WARN_ON(out_sgs + in_sgs != total_sgs)
On Fri, Oct 02, 2020 at 10:44:37PM -0400, Qian Cai wrote: > On Fri, 2020-10-02 at 12:28 -0400, Qian Cai wrote: > > Running some fuzzing on virtiofs from a non-privileged user could trigger a > > warning in virtio_fs_enqueue_req(): > > > > WARN_ON(out_sgs + in_sgs != total_sgs); > > Okay, I can reproduce this after running for a few hours: > > out_sgs = 3, in_sgs = 2, total_sgs = 6 Thanks. I can also reproduce it simply by calling. ioctl(fd, 0x5a004000, buf); I think following WARN_ON() is not correct. WARN_ON(out_sgs + in_sgs != total_sgs) toal_sgs should actually be max sgs. It looks at ap->num_pages and counts one sg for each page. And it assumes that same number of pages will be used both for input and output. But there are no such guarantees. With above ioctl() call, I noticed we are using 2 pages for input (out_sgs) and one page for output (in_sgs). So out_sgs=4, in_sgs=3 and total_sgs=8 and warning triggers. I think total sgs is actually max number of sgs and warning should probably be. WARN_ON(out_sgs + in_sgs > total_sgs) Stefan, WDYT? I will send a patch for this. Thanks Vivek > > and this time from flush_bg_queue() instead of fuse_simple_request(). > > From the log, the last piece of code is: > > ftruncate(fd=186, length=4) > > which is a test file on virtiofs: > > [main] testfile fd:186 filename:trinity-testfile3 flags:2 fopened:1 > fcntl_flags:2000 global:1 > [main] start: 0x7f47c1199000 size:4KB name: trinity-testfile3 global:1 > > > [ 9863.468502] WARNING: CPU: 16 PID: 286083 at fs/fuse/virtio_fs.c:1152 > virtio_fs_enqueue_req+0xd36/0xde0 [virtiofs] > [ 9863.474442] Modules linked in: dlci 8021q garp mrp bridge stp llc > ieee802154_socket ieee802154 vsock_loopback vmw_vsock_virtio_transport_common > vmw_vsock_vmci_transport vsock mpls_router vmw_vmci ip_tunnel as > [ 9863.474555] ata_piix fuse serio_raw libata e1000 sunrpc dm_mirror > dm_region_hash dm_log dm_mod > [ 9863.535805] CPU: 16 PID: 286083 Comm: trinity-c5 Kdump: loaded Not tainted > 5.9.0-rc7-next-20201002+ #2 > [ 9863.544368] Hardware name: Red Hat KVM, BIOS > 1.14.0-1.module+el8.3.0+7638+07cf13d2 04/01/2014 > [ 9863.550129] RIP: 0010:virtio_fs_enqueue_req+0xd36/0xde0 [virtiofs] > [ 9863.552998] Code: 60 09 23 d9 e9 44 fa ff ff e8 56 09 23 d9 e9 70 fa ff ff > 48 89 cf 48 89 4c 24 08 e8 44 09 23 d9 48 8b 4c 24 08 e9 7c fa ff ff <0f> 0b > 48 c7 c7 c0 85 60 c0 44 89 e1 44 89 fa 44 89 ee e8 e3 b7 > [ 9863.561720] RSP: 0018:888a696ef6f8 EFLAGS: 00010202 > [ 9863.565420] RAX: RBX: 88892e030008 RCX: > > [ 9863.568735] RDX: 0005 RSI: RDI: > 888a696ef8ac > [ 9863.572037] RBP: 888a49d03d30 R08: ed114d2ddf18 R09: > 888a696ef8a0 > [ 9863.575383] R10: 888a696ef8bf R11: ed114d2ddf17 R12: > 0006 > [ 9863.578668] R13: 0003 R14: 0002 R15: > 0002 > [ 9863.581971] FS: 7f47c12f5740() GS:888a7f80() > knlGS: > [ 9863.585752] CS: 0010 DS: ES: CR0: 80050033 > [ 9863.590232] CR2: CR3: 000a63570005 CR4: > 00770ee0 > [ 9863.594698] DR0: 7f6642e43000 DR1: DR2: > > [ 9863.598521] DR3: DR6: 0ff0 DR7: > 0600 > [ 9863.601861] PKRU: 5540 > [ 9863.603173] Call Trace: > [ 9863.604382] ? virtio_fs_probe+0x13e0/0x13e0 [virtiofs] > [ 9863.606838] ? is_bpf_text_address+0x21/0x30 > [ 9863.608869] ? kernel_text_address+0x125/0x140 > [ 9863.610962] ? __kernel_text_address+0xe/0x30 > [ 9863.613117] ? unwind_get_return_address+0x5f/0xa0 > [ 9863.615427] ? create_prof_cpu_mask+0x20/0x20 > [ 9863.617435] ? _raw_write_lock_irqsave+0xe0/0xe0 > [ 9863.619627] virtio_fs_wake_pending_and_unlock+0x1ea/0x610 [virtiofs] > [ 9863.622638] ? queue_request_and_unlock+0x115/0x280 [fuse] > [ 9863.625224] flush_bg_queue+0x24c/0x3e0 [fuse] > [ 9863.627325] fuse_simple_background+0x3d7/0x6c0 [fuse] > [ 9863.629735] fuse_send_writepage+0x173/0x420 [fuse] > [ 9863.632031] fuse_flush_writepages+0x1fe/0x330 [fuse] > [ 9863.634463] ? make_kgid+0x13/0x20 > [ 9863.636064] ? fuse_change_attributes_common+0x2de/0x940 [fuse] > [ 9863.638850] fuse_do_setattr+0xe84/0x13c0 [fuse] > [ 9863.641024] ? migrate_swap_stop+0x8d1/0x920 > [ 9863.643041] ? fuse_flush_times+0x390/0x390 [fuse] > [ 9863.645347] ? avc_has_perm_noaudit+0x390/0x390 > [ 9863.647465] fuse_setattr+0x197/0x400 [fuse] > [ 9863.649466] notify_change+0x744/0xda0 > [ 9863.651247] ? __down_timeout+0x2a0/0x2a0 > [ 9863.653125] ? do_truncate+0xe2/0x180 > [ 9863.654854] do_truncate+0xe2/0x180 > [ 9863.656509] ? __x64_sys_openat2+0x1c0/0x1c0 > [ 9863.658512] ? alarm_setitimer+0xa0/0x110 > [ 9863.660418] do_sys_ftruncate+0x1ee/0x2c0 > [ 9863.662311] do_syscall_64+0x33/0x40 > [ 9863.663980] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 9863.666384] RIP:
[RFC PATCH v4 3/4] objtool: correct rebuilding of reloc sections
From: Martin Schwidefsky
Currently relocations generated in elf_rebuild_rel_reloc_section/
elf_rebuild_rela_reloc_section functions are broken if the objtool is
built and run on big endian system. E.g. the following errors pop up
during x86 cross compilation:
x86_64-9.1.0-ld: fs/efivarfs/inode.o: bad reloc symbol index (0x200 >=
0x22) for offset 0 in section `.orc_unwind_ip'
x86_64-9.1.0-ld: final link failed: bad value
To address that convert those functions to do things similar to
elf_write_reloc(), reuse gelf_update_rel/gelf_update_rela libelf library
functions.
Signed-off-by: Martin Schwidefsky
Co-developed-by: Vasily Gorbik
Signed-off-by: Vasily Gorbik
---
tools/objtool/elf.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 4e1d7460574b..5c0341b0cde3 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -829,25 +829,27 @@ static int elf_rebuild_rel_reloc_section(struct section
*sec, int nr)
{
struct reloc *reloc;
int idx = 0, size;
- GElf_Rel *relocs;
+ void *buf;
/* Allocate a buffer for relocations */
- size = nr * sizeof(*relocs);
- relocs = malloc(size);
- if (!relocs) {
+ size = nr * sizeof(GElf_Rel);
+ buf = malloc(size);
+ if (!buf) {
perror("malloc");
return -1;
}
- sec->data->d_buf = relocs;
+ sec->data->d_buf = buf;
sec->data->d_size = size;
+ sec->data->d_type = ELF_T_REL;
sec->sh.sh_size = size;
idx = 0;
list_for_each_entry(reloc, >reloc_list, list) {
- relocs[idx].r_offset = reloc->offset;
- relocs[idx].r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ reloc->rel.r_offset = reloc->offset;
+ reloc->rel.r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ gelf_update_rel(sec->data, idx, >rel);
idx++;
}
@@ -858,26 +860,28 @@ static int elf_rebuild_rela_reloc_section(struct section
*sec, int nr)
{
struct reloc *reloc;
int idx = 0, size;
- GElf_Rela *relocs;
+ void *buf;
/* Allocate a buffer for relocations with addends */
- size = nr * sizeof(*relocs);
- relocs = malloc(size);
- if (!relocs) {
+ size = nr * sizeof(GElf_Rela);
+ buf = malloc(size);
+ if (!buf) {
perror("malloc");
return -1;
}
- sec->data->d_buf = relocs;
+ sec->data->d_buf = buf;
sec->data->d_size = size;
+ sec->data->d_type = ELF_T_RELA;
sec->sh.sh_size = size;
idx = 0;
list_for_each_entry(reloc, >reloc_list, list) {
- relocs[idx].r_offset = reloc->offset;
- relocs[idx].r_addend = reloc->addend;
- relocs[idx].r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ reloc->rela.r_offset = reloc->offset;
+ reloc->rela.r_addend = reloc->addend;
+ reloc->rela.r_info = GELF_R_INFO(reloc->sym->idx, reloc->type);
+ gelf_update_rela(sec->data, idx, >rela);
idx++;
}
--
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
[RFC PATCH v4 4/4] objtool: fix x86 orc generation on big endian cross compiles
Correct objtool orc generation endianness problems to enable fully
functional x86 cross compiles on big endian hardware.
Introduces bswap_if_needed macro which does a byte swap if target
endianness doesn't match the host, i.e. cross compilation for little
endian on big endian and vice versa. To be used for multi-byte values
conversion, which are read from / about to be written to a target native
endianness ELF file.
Signed-off-by: Vasily Gorbik
diff --git a/arch/x86/include/asm/orc_types.h b/arch/x86/include/asm/orc_types.h
index fdbffec4cfde..5a2baf28a1dc 100644
--- a/arch/x86/include/asm/orc_types.h
+++ b/arch/x86/include/asm/orc_types.h
@@ -40,6 +40,8 @@
#define ORC_REG_MAX15
#ifndef __ASSEMBLY__
+#include
+
/*
* This struct is more or less a vastly simplified version of the DWARF Call
* Frame Information standard. It contains only the necessary parts of DWARF
@@ -51,10 +53,18 @@
struct orc_entry {
s16 sp_offset;
s16 bp_offset;
+#if defined(__LITTLE_ENDIAN_BITFIELD)
unsignedsp_reg:4;
unsignedbp_reg:4;
unsignedtype:2;
unsignedend:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ unsignedbp_reg:4;
+ unsignedsp_reg:4;
+ unsignedunused:5;
+ unsignedend:1;
+ unsignedtype:2;
+#endif
} __packed;
#endif /* __ASSEMBLY__ */
diff --git a/tools/arch/x86/include/asm/orc_types.h
b/tools/arch/x86/include/asm/orc_types.h
index fdbffec4cfde..5a2baf28a1dc 100644
--- a/tools/arch/x86/include/asm/orc_types.h
+++ b/tools/arch/x86/include/asm/orc_types.h
@@ -40,6 +40,8 @@
#define ORC_REG_MAX15
#ifndef __ASSEMBLY__
+#include
+
/*
* This struct is more or less a vastly simplified version of the DWARF Call
* Frame Information standard. It contains only the necessary parts of DWARF
@@ -51,10 +53,18 @@
struct orc_entry {
s16 sp_offset;
s16 bp_offset;
+#if defined(__LITTLE_ENDIAN_BITFIELD)
unsignedsp_reg:4;
unsignedbp_reg:4;
unsignedtype:2;
unsignedend:1;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ unsignedbp_reg:4;
+ unsignedsp_reg:4;
+ unsignedunused:5;
+ unsignedend:1;
+ unsignedtype:2;
+#endif
} __packed;
#endif /* __ASSEMBLY__ */
diff --git a/tools/objtool/arch/x86/include/arch_endianness.h
b/tools/objtool/arch/x86/include/arch_endianness.h
new file mode 100644
index ..7c362527da20
--- /dev/null
+++ b/tools/objtool/arch/x86/include/arch_endianness.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _ARCH_ENDIANNESS_H
+#define _ARCH_ENDIANNESS_H
+
+#include
+
+#define __TARGET_BYTE_ORDER __LITTLE_ENDIAN
+
+#endif /* _ARCH_ENDIANNESS_H */
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 2df9f769412e..fd892b77e98f 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -13,6 +13,7 @@
#include "special.h"
#include "warn.h"
#include "arch_elf.h"
+#include "endianness.h"
#include
#include
@@ -1370,7 +1371,7 @@ static int read_unwind_hints(struct objtool_file *file)
cfa = >cfi.cfa;
if (hint->type == UNWIND_HINT_TYPE_RET_OFFSET) {
- insn->ret_offset = hint->sp_offset;
+ insn->ret_offset = bswap_if_needed(hint->sp_offset);
continue;
}
@@ -1382,7 +1383,7 @@ static int read_unwind_hints(struct objtool_file *file)
return -1;
}
- cfa->offset = hint->sp_offset;
+ cfa->offset = bswap_if_needed(hint->sp_offset);
insn->cfi.type = hint->type;
insn->cfi.end = hint->end;
}
diff --git a/tools/objtool/endianness.h b/tools/objtool/endianness.h
new file mode 100644
index ..ebece3191b58
--- /dev/null
+++ b/tools/objtool/endianness.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _OBJTOOL_ENDIANNESS_H
+#define _OBJTOOL_ENDIANNESS_H
+
+#include
+#include
+#include "arch_endianness.h"
+
+#ifndef __TARGET_BYTE_ORDER
+#error undefined arch __TARGET_BYTE_ORDER
+#endif
+
+#if __BYTE_ORDER != __TARGET_BYTE_ORDER
+#define __NEED_BSWAP 1
+#else
+#define __NEED_BSWAP 0
+#endif
+
+/*
+ * Does a byte swap if target endianness doesn't match the host, i.e. cross
+ * compilation for little endian on big endian and vice versa.
+ * To be used for multi-byte values conversion, which are read from / about
+ * to be written to a target native endianness ELF file.
+ */
+#define bswap_if_needed(val) \
+({ \
+ __typeof__(val) __ret; \
+ switch (sizeof(val)) {
[RFC PATCH v4 2/4] x86/insn: instruction decoder and big endian cross compiles
From: Martin Schwidefsky
x86 instruction decoder code is shared across the kernel source and the
tools. Currently objtool seems to be the only tool from build tools needed
which breaks x86 cross compilation on big endian systems. Make the x86
instruction decoder build host endianness agnostic to support x86 cross
compilation and enable objtool to implement endianness awareness for
big endian architectures support.
Signed-off-by: Martin Schwidefsky
Co-developed-by: Vasily Gorbik
Signed-off-by: Vasily Gorbik
---
arch/x86/include/asm/insn.h | 33 ++
arch/x86/lib/insn.c | 101 ++
tools/arch/x86/include/asm/insn.h | 33 ++
tools/arch/x86/lib/insn.c | 101 ++
4 files changed, 160 insertions(+), 108 deletions(-)
diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 5c1ae3eff9d4..004e27bdf121 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -7,9 +7,12 @@
* Copyright (C) IBM Corporation, 2009
*/
+#include
/* insn_attr_t is defined in inat.h */
#include
+#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN :
defined(__LITTLE_ENDIAN)
+
struct insn_field {
union {
insn_value_t value;
@@ -20,6 +23,36 @@ struct insn_field {
unsigned char nbytes;
};
+static inline void insn_field_set(struct insn_field *p, insn_value_t v,
+ unsigned char n)
+{
+ p->value = v;
+ p->nbytes = n;
+}
+
+#else
+
+struct insn_field {
+ insn_value_t value;
+ union {
+ insn_value_t little;
+ insn_byte_t bytes[4];
+ };
+ /* !0 if we've run insn_get_xxx() for this field */
+ unsigned char got;
+ unsigned char nbytes;
+};
+
+static inline void insn_field_set(struct insn_field *p, insn_value_t v,
+ unsigned char n)
+{
+ p->value = v;
+ p->little = __cpu_to_le32(v);
+ p->nbytes = n;
+}
+
+#endif
+
struct insn {
struct insn_field prefixes; /*
* Prefixes
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 404279563891..520b31fc1f1a 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -5,6 +5,7 @@
* Copyright (C) IBM Corporation, 2002, 2004, 2009
*/
+#include
#ifdef __KERNEL__
#include
#else
@@ -15,15 +16,28 @@
#include
+#define leXX_to_cpu(t, r) \
+({ \
+ __typeof__(t) v;\
+ switch (sizeof(t)) {\
+ case 4: v = le32_to_cpu(r); break; \
+ case 2: v = le16_to_cpu(r); break; \
+ case 1: v = r; break; \
+ default:\
+ BUILD_BUG(); break; \
+ } \
+ v; \
+})
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
#define __get_next(t, insn)\
- ({ t r = *(t*)insn->next_byte; insn->next_byte += sizeof(t); r; })
+ ({ t r = *(t*)insn->next_byte; insn->next_byte += sizeof(t);
leXX_to_cpu(t, r); })
#define __peek_nbyte_next(t, insn, n) \
- ({ t r = *(t*)((insn)->next_byte + n); r; })
+ ({ t r = *(t*)((insn)->next_byte + n); leXX_to_cpu(t, r); })
#define get_next(t, insn) \
({ if (unlikely(!validate_next(t, insn, 0))) goto err_out;
__get_next(t, insn); })
@@ -157,8 +171,7 @@ void insn_get_prefixes(struct insn *insn)
b = peek_next(insn_byte_t, insn);
attr = inat_get_opcode_attribute(b);
if (inat_is_rex_prefix(attr)) {
- insn->rex_prefix.value = b;
- insn->rex_prefix.nbytes = 1;
+ insn_field_set(>rex_prefix, b, 1);
insn->next_byte++;
if (X86_REX_W(b))
/* REX.W overrides opnd_size */
@@ -295,8 +308,7 @@ void insn_get_modrm(struct insn *insn)
if (inat_has_modrm(insn->attr)) {
mod = get_next(insn_byte_t, insn);
- modrm->value = mod;
- modrm->nbytes = 1;
+ insn_field_set(modrm, mod, 1);
if (inat_is_group(insn->attr)) {
pfx_id = insn_last_prefix_id(insn);
insn->attr = inat_get_group_attribute(mod, pfx_id,
@@ -334,7 +346,7 @@ int insn_rip_relative(struct insn
[RFC PATCH v4 1/4] objtool: allow nested externs to enable BUILD_BUG()
Currently BUILD_BUG() macro is expanded to smth like the following:
do {
extern void __compiletime_assert_0(void)
__attribute__((error("BUILD_BUG failed")));
if (!(!(1)))
__compiletime_assert_0();
} while (0);
If used in a function body this obviously would produce build errors
with -Wnested-externs and -Werror.
Build objtool with -Wno-nested-externs to enable BUILD_BUG() usage.
Signed-off-by: Vasily Gorbik
---
tools/objtool/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 33d1e3ca8efd..4ea9a833dde7 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -37,7 +37,7 @@ INCLUDES := -I$(srctree)/tools/include \
-I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-I$(srctree)/tools/arch/$(SRCARCH)/include \
-I$(srctree)/tools/objtool/arch/$(SRCARCH)/include
-WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
+WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
-Wno-nested-externs
CFLAGS := -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES)
$(LIBELF_FLAGS)
LDFLAGS += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
--
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
[RFC PATCH v4 0/4] objtool and cross compilation
rfc v1 - rfc v2: - rebased onto tip/objtool/core - reformatted couple of lines rfc v2 - rfc v3: - reused __*_ENDIAN_BITFIELD and dropped unneeded byteswap if __KERNEL__ is defined following David's suggestions, - re-splitted changes and made x86 instruction decoder a separate patch, - extra patch to add -Wno-nested-externs build flag to enable BUILD_BUG() usage, - added a safer and more readable leXX_to_cpu macro in x86 instruction decoder, - simplified includes. Switched to using leXX_to_cpu/cpu_to_leXX in the objtool and x86 instruction decoder since is included in the objtool already. rfc v3 - rfc v4: - patch 4: objtool: fix x86 orc generation on big endian cross compiles - introduced "bswap_if_needed()" macro for multi-byte values conversion, which are read from / about to be written to a target native endianness ELF file. - patch 2: x86/insn: instruction decoder and big endian cross compiles - changed subject prefix from objtool to x86/insn - reformated leXX_to_cpu macro make it easier to read Currently objtool seems to be the only tool from all the build tools needed for x86 build which breaks x86 cross compilation on big endian systems. But besides x86 cross compilation, endianness awareness is also needed for big endian architectures objtool support in general. We have working prototype of objtool support and orc unwinder for s390 made originally by Martin Schwidefsky. I'm trying to bring it in shape again and refactor to share more code with "generic" part. But first things first. This patch series points to endianness problems which should be addressed. Recent "other architectures support" patches currently moved only some problematic parts into x86 arch specific folder. Besides that even though big endian stuff is only needed for the objtool arch/x86/lib/insn.c and arch/x86/include/asm/insn.h are shared across the kernel source and the tools, so changes are applied to both. Any suggestions how to make patches more acceptable are welcome. Martin Schwidefsky (2): x86/insn: instruction decoder and big endian cross compiles objtool: correct rebuilding of reloc sections Vasily Gorbik (2): objtool: allow nested externs to enable BUILD_BUG() objtool: fix x86 orc generation on big endian cross compiles arch/x86/include/asm/insn.h | 33 ++ arch/x86/include/asm/orc_types.h | 10 ++ arch/x86/lib/insn.c | 101 -- tools/arch/x86/include/asm/insn.h | 33 ++ tools/arch/x86/include/asm/orc_types.h| 10 ++ tools/arch/x86/lib/insn.c | 101 -- tools/objtool/Makefile| 2 +- .../arch/x86/include/arch_endianness.h| 9 ++ tools/objtool/check.c | 5 +- tools/objtool/elf.c | 34 +++--- tools/objtool/endianness.h| 38 +++ tools/objtool/orc_dump.c | 5 +- tools/objtool/orc_gen.c | 3 + tools/objtool/special.c | 6 +- 14 files changed, 260 insertions(+), 130 deletions(-) create mode 100644 tools/objtool/arch/x86/include/arch_endianness.h create mode 100644 tools/objtool/endianness.h -- ⢋⡀⣀⠹ ⠠⣶⡦⠀ ⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿ ⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿ ⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿ ⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
Re: [ep_insert()] 9ee1cc5666: WARNING:possible_recursive_locking_detected
On Sun, Oct 04, 2020 at 03:17:45PM +0100, Al Viro wrote:
> On Sun, Oct 04, 2020 at 08:56:19PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 9ee1cc56661640a2ace2f7d0b52dec56b3573c53 ("[RFC PATCH 20/27]
> > ep_insert(): we only need tep->mtx around the insertion itself")
> > url:
> > https://github.com/0day-ci/linux/commits/Al-Viro/epoll-switch-epitem-pwqlist-to-single-linked-list/20201004-113938
> > base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> > 22fbc037cd32e4e6771d2271b565806cfb8c134c
>
> False positive, actually - that should've been mutex_lock_nested()
> with 1 for depth; will update.
Folded and pushed; the incremental is
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index d3fdabf6fd34..aa8b8490cc96 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1455,7 +1455,7 @@ static int ep_insert(struct eventpoll *ep, const struct
epoll_event *event,
epi->next = EP_UNACTIVE_PTR;
if (tep)
- mutex_lock(>mtx);
+ mutex_lock_nested(>mtx, 1);
/* Add the current item to the list of active epoll hook for this file
*/
if (unlikely(attach_epitem(tfile, epi) < 0)) {
kmem_cache_free(epi_cache, epi);
[PATCH] apparmor: fix error check
From: Tom Rix
clang static analysis reports this representative problem:
label.c:1463:16: warning: Assigned value is garbage or undefined
label->hname = name;
^
In aa_update_label_name(), this the problem block of code
if (aa_label_acntsxprint(, ...) == -1)
return res;
On failure, aa_label_acntsxprint() has a more complicated return
that just -1. So check for a negative return.
It was also noted that the aa_label_acntsxprint() main comment refers
to a nonexistent parameter, so clean up the comment.
Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels")
Signed-off-by: Tom Rix
---
security/apparmor/label.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/apparmor/label.c b/security/apparmor/label.c
index e68bcedca976..6222fdfebe4e 100644
--- a/security/apparmor/label.c
+++ b/security/apparmor/label.c
@@ -1454,7 +1454,7 @@ bool aa_update_label_name(struct aa_ns *ns, struct
aa_label *label, gfp_t gfp)
if (label->hname || labels_ns(label) != ns)
return res;
- if (aa_label_acntsxprint(, ns, label, FLAGS_NONE, gfp) == -1)
+ if (aa_label_acntsxprint(, ns, label, FLAGS_NONE, gfp) < 0)
return res;
ls = labels_set(label);
@@ -1704,7 +1704,7 @@ int aa_label_asxprint(char **strp, struct aa_ns *ns,
struct aa_label *label,
/**
* aa_label_acntsxprint - allocate a __counted string buffer and print label
- * @strp: buffer to write to. (MAY BE NULL if @size == 0)
+ * @strp: buffer to write to.
* @ns: namespace profile is being viewed from
* @label: label to view (NOT NULL)
* @flags: flags controlling what label info is printed
--
2.18.1
RE: [PATCH 1/2] scsi: ufs: Add DeepSleep feature
Please ignore - I was confused with pre-fetch. Sorry, Avri > -Original Message- > From: Avri Altman > Sent: Sunday, October 4, 2020 10:21 AM > To: 'Adrian Hunter' ; Martin K . Petersen > ; James E . J . Bottomley > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; Alim Akhtar > > Subject: RE: [PATCH 1/2] scsi: ufs: Add DeepSleep feature > > > + /* > > +* DeepSleep requires the Immediate flag. DeepSleep state is > > actually > > +* entered when the link state goes to Hibern8. > > +*/ > > + if (pwr_mode == UFS_DEEPSLEEP_PWR_MODE) > > + cmd[1] = 1; > Shouldn't it be bit1, i.e. cmd[1] = 2 ? > > > cmd[4] = pwr_mode << 4; > >
[PATCH] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
This reverts commit 37054fc81443cc6a8c3a38395f384412b8373d82.
At the very moment this commit was created, the DMA API it relied on was
modified in the DMA tree, which caused the driver to break in
linux-next.
Revert it for now, and it will be resubmitted later to work with the new
DMA API.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 114 +-
drivers/gpu/drm/ingenic/ingenic-drm.h | 4 -
drivers/gpu/drm/ingenic/ingenic-ipu.c | 12 +--
3 files changed, 4 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 0225dc1f5eb8..7d8b0ad52979 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -9,8 +9,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -24,7 +22,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -100,11 +97,6 @@ struct ingenic_drm {
struct notifier_block clock_nb;
};
-static bool ingenic_drm_cached_gem_buf;
-module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool, 0400);
-MODULE_PARM_DESC(cached_gem_buffers,
-"Enable fully cached GEM buffers [default=false]");
-
static bool ingenic_drm_writeable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -402,8 +394,6 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
plane->state->fb->format->format != state->fb->format->format))
crtc_state->mode_changed = true;
- drm_atomic_helper_check_plane_damage(state->state, state);
-
return 0;
}
@@ -521,38 +511,6 @@ void ingenic_drm_plane_config(struct device *dev,
}
}
-void ingenic_drm_sync_data(struct device *dev,
- struct drm_plane_state *old_state,
- struct drm_plane_state *state)
-{
- const struct drm_format_info *finfo = state->fb->format;
- struct ingenic_drm *priv = dev_get_drvdata(dev);
- struct drm_atomic_helper_damage_iter iter;
- unsigned int offset, i;
- struct drm_rect clip;
- dma_addr_t paddr;
- void *addr;
-
- if (!ingenic_drm_cached_gem_buf)
- return;
-
- drm_atomic_helper_damage_iter_init(, old_state, state);
-
- drm_atomic_for_each_plane_damage(, ) {
- for (i = 0; i < finfo->num_planes; i++) {
- paddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
- addr = phys_to_virt(paddr);
-
- /* Ignore x1/x2 values, invalidate complete lines */
- offset = clip.y1 * state->fb->pitches[i];
-
- dma_cache_sync(priv->dev, addr + offset,
- (clip.y2 - clip.y1) *
state->fb->pitches[i],
- DMA_TO_DEVICE);
- }
- }
-}
-
static void ingenic_drm_update_palette(struct ingenic_drm *priv,
const struct drm_color_lut *lut)
{
@@ -581,8 +539,6 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
if (state && state->fb) {
crtc_state = state->crtc->state;
- ingenic_drm_sync_data(priv->dev, oldstate, state);
-
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
@@ -752,69 +708,7 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
*crtc)
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
}
-static struct drm_framebuffer *
-ingenic_drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- if (ingenic_drm_cached_gem_buf)
- return drm_gem_fb_create_with_dirty(dev, file, mode_cmd);
-
- return drm_gem_fb_create(dev, file, mode_cmd);
-}
-
-static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
- struct device *dev = cma_obj->base.dev->dev;
- unsigned long attrs;
- int ret;
-
- if (ingenic_drm_cached_gem_buf)
- attrs = DMA_ATTR_NON_CONSISTENT;
- else
- attrs = DMA_ATTR_WRITE_COMBINE;
-
- /*
-* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
-* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
-* the whole buffer.
-*/
- vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_pgoff = 0;
- vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
-
- ret = dma_mmap_attrs(dev, vma, cma_obj->vaddr, cma_obj->paddr,
-vma->vm_end - vma->vm_start,
Re: [ep_insert()] 9ee1cc5666: WARNING:possible_recursive_locking_detected
On Sun, Oct 04, 2020 at 08:56:19PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 9ee1cc56661640a2ace2f7d0b52dec56b3573c53 ("[RFC PATCH 20/27]
> ep_insert(): we only need tep->mtx around the insertion itself")
> url:
> https://github.com/0day-ci/linux/commits/Al-Viro/epoll-switch-epitem-pwqlist-to-single-linked-list/20201004-113938
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> 22fbc037cd32e4e6771d2271b565806cfb8c134c
False positive, actually - that should've been mutex_lock_nested()
with 1 for depth; will update.
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
On 10/4/2020 20:29, Leonid Bloch wrote: On 10/4/20 1:58 PM, Lars Melin wrote: On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. Please see below. Thanks, Leonid. ``` Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1054 bcdDevice 4.14 iManufacturer 1 Telit Wireless Solutions iProduct 2 FT980-KS iSerial 3 cb42f61 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x013d bNumInterfaces 8 bConfigurationValue 1 iConfiguration 4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 239 Miscellaneous Device bFunctionSubClass 4 bFunctionProtocol 1 iFunction 7 RNDIS Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 4 bInterfaceProtocol 1 iInterface 5 RNDIS Communications Control ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 04 24 02 00 ** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 RNDIS Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4
Re: [RFC][PATCHSET] epoll cleanups
On Sun, Oct 04, 2020 at 01:13:29PM +0100, Matthew Wilcox wrote: > Have you considered just storing a pointer to each struct file in an > epoll set in an XArray? Linked lists suck for modern CPUs, and there'd > be no need to store any additional data in each struct file. Using > xa_alloc() to store the pointer and throw away the index the pointer > got stored at would leave you with something approximating a singly > linked list, except it's an array. Which does zero memory allocations > for a single entry and will then allocate a single node for your first > 64 entries. Won't work - those struct file can get freed while we are collecting the set/allocating epitem/calling ->poll()/etc.
Re: [PATCH 1/1] efi/libstub/x86: simplify efi_is_native()
On Sat, 3 Oct 2020 at 21:44, Arvind Sankar wrote:
>
> On Sat, Oct 03, 2020 at 01:28:18PM -0400, Brian Gerst wrote:
> > On Sat, Oct 3, 2020 at 2:05 AM Heinrich Schuchardt
> > wrote:
> > >
> > > CONFIG_EFI_MIXED depends on CONFIG_X86_64=y.
> > > There is no need to check CONFIG_X86_64 again.
> > >
> > > Signed-off-by: Heinrich Schuchardt
> > > ---
> > > arch/x86/include/asm/efi.h | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> > > index b9c2667ac46c..ab28bf1c74cf 100644
> > > --- a/arch/x86/include/asm/efi.h
> > > +++ b/arch/x86/include/asm/efi.h
> > > @@ -223,8 +223,6 @@ static inline bool efi_is_64bit(void)
> > >
> > > static inline bool efi_is_native(void)
> > > {
> > > - if (!IS_ENABLED(CONFIG_X86_64))
> > > - return true;
> > > return efi_is_64bit();
> > > }
> >
> > This would then return false for native 32-bit.
> >
> > --
> > Brian Gerst
>
> 32-bit doesn't use this implementation: it's #define'd to true in
> drivers/firmware/efi/libstub/efistub.h.
>
Yes, and the reason this [now redundant] test exists is because this
did not use to be the case before
de8c55208c386 efi/libstub: Fix mixed mode boot issue after macro refactor
So for this patch
Acked-by: Ard Biesheuvel
I'll queue this up
Re: [PATCH] mtd: spi-nor: Prefer asynchronous probe
Hi, Am 2020-10-03 19:00, schrieb Doug Anderson: On Sat, Oct 3, 2020 at 9:54 AM Michael Walle wrote: While debugging another issue I also noticed that sometimes my /dev/mtdN devices were reordered. Note that I have two SPI flashes. Might this also be connected to the async probe? It's likely. My guess is that you shouldn't really be depending on the numbering. If you need to depend on the numbering, there should be something that guarantees it like a device tree alias. We have struggled with similar things on MMC for years and I guess Ulf finally decided that we weren't going to get a better solution than the device tree aliases. But this has to be supported by spi-nor first, right? So that would also be something which has to be added before we can make the probe async. And as far as I know there is no such mechanism like /dev/disk/by-X for /dev/mtdN. -michael
[PATCH] dma: dma-jz4780: Fix race in jz4780_dma_tx_status
The jz4780_dma_tx_status() function would check if a channel's cookie
state was set to 'completed', and if not, it would enter the critical
section. However, in that time frame, the jz4780_dma_chan_irq() function
was able to set the cookie to 'completed', and clear the jzchan->vchan
pointer, which was deferenced in the critical section of the first
function.
Fix this race by checking the channel's cookie state after entering the
critical function and not before.
Fixes: d894fc6046fe ("dmaengine: jz4780: add driver for the Ingenic JZ4780 DMA
controller")
Cc: sta...@vger.kernel.org # v4.0
Signed-off-by: Paul Cercueil
Reported-by: Artur Rojek
Tested-by: Artur Rojek
---
drivers/dma/dma-jz4780.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c
index 8beed91428bd..a608efaa435f 100644
--- a/drivers/dma/dma-jz4780.c
+++ b/drivers/dma/dma-jz4780.c
@@ -639,11 +639,11 @@ static enum dma_status jz4780_dma_tx_status(struct
dma_chan *chan,
unsigned long flags;
unsigned long residue = 0;
+ spin_lock_irqsave(>vchan.lock, flags);
+
status = dma_cookie_status(chan, cookie, txstate);
if ((status == DMA_COMPLETE) || (txstate == NULL))
- return status;
-
- spin_lock_irqsave(>vchan.lock, flags);
+ goto out_unlock_irqrestore;
vdesc = vchan_find_desc(>vchan, cookie);
if (vdesc) {
@@ -660,6 +660,7 @@ static enum dma_status jz4780_dma_tx_status(struct dma_chan
*chan,
&& jzchan->desc->status & (JZ_DMA_DCS_AR | JZ_DMA_DCS_HLT))
status = DMA_ERROR;
+out_unlock_irqrestore:
spin_unlock_irqrestore(>vchan.lock, flags);
return status;
}
--
2.28.0
[PATCH v3 2/3] dt-bindings: Add vendor prefix for Ouya Inc.
Ouya is a defunct company from 2012 to 2015. They produced a single device, the Ouya game console. In 2015 they were purchased by Razer Inc. and the Ouya was discontinued. All Ouya services were shuttered in 2019. Signed-off-by: Peter Geis Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9a5ab7b94789..367dd79c95f6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -786,6 +786,8 @@ patternProperties: description: Ortus Technology Co., Ltd. "^osddisplays,.*": description: OSD Displays + "^ouya,.*": +description: Ouya Inc. "^overkiz,.*": description: Overkiz SAS "^ovti,.*": -- 2.25.1
[PATCH v3 3/3] dt-bindings: ARM: tegra: Add Ouya game console
Add a binding for the Tegra30-based Ouya game console. Signed-off-by: Peter Geis Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/tegra.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index e0b3debaee9e..a8bafe68315f 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -69,6 +69,9 @@ properties: - const: asus,tilapia - const: asus,grouper - const: nvidia,tegra30 + - items: + - const: ouya,ouya + - const: nvidia,tegra30 - items: - enum: - nvidia,dalmore -- 2.25.1
[PATCH v3 0/3] Support NVIDIA Tegra-based Ouya game console
Good Day, This series introduces upstream kernel support for the Ouya game console device. Please review and apply. Thank you in advance. Changelog: v3: - Reorder aliases per Dmitry Osipenko's review. - Add sdio clocks per Dmitry Osipenko's review. - Add missing ti sleep bits per Dmitry Osipenko's review. - Enable lp1 sleep mode. - Fix bluetooth comment and add missing power supplies. v2: - Update pmic and clock handles per Rob Herring's review. - Add acks from Rob Herring to patch 2 and 3. Peter Geis (3): ARM: tegra: Add device-tree for Ouya dt-bindings: Add vendor prefix for Ouya Inc. dt-bindings: ARM: tegra: Add Ouya game console .../devicetree/bindings/arm/tegra.yaml|3 + .../devicetree/bindings/vendor-prefixes.yaml |2 + arch/arm/boot/dts/Makefile|3 +- arch/arm/boot/dts/tegra30-ouya.dts| 4511 + 4 files changed, 4518 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/tegra30-ouya.dts -- 2.25.1
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
On 10/4/20 1:58 PM, Lars Melin wrote: On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. Please see below. Thanks, Leonid. ``` Bus 001 Device 005: ID 1bc7:1054 Telit Wireless Solutions Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1054 bcdDevice4.14 iManufacturer 1 Telit Wireless Solutions iProduct2 FT980-KS iSerial 3 cb42f61 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x013d bNumInterfaces 8 bConfigurationValue 1 iConfiguration 4 RNDIS_DIAG_ADB_NMEA_DUN_DUN_SER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass239 Miscellaneous Device bFunctionSubClass 4 bFunctionProtocol 1 iFunction 7 RNDIS Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 4 bInterfaceProtocol 1 iInterface 5 RNDIS Communications Control ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 04 24 02 00 ** UNRECOGNIZED: 05 24 06 00 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 RNDIS Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sun, 2020-10-04 at 15:18 +0200, Greg Kroah-Hartman wrote:
> On Sun, Oct 04, 2020 at 02:17:06PM +0200, Bastien Nocera wrote:
> > On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> > > > Hi Greg,
> > > >
> > > > > > > This reverts commit
> > > > > > > 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2
> > > > > > > as it
> > > > > > > breaks all bluetooth connections on my machine.
> > > > > > >
> > > > > > > Cc: Marcel Holtmann
> > > > > > > Cc: Sathish Narsimman
> > > > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list
> > > > > > > when
> > > > > > > updating whitelist")
> > > > > > > Signed-off-by: Greg Kroah-Hartman
> > > > > > >
> > > > > > > ---
> > > > > > > net/bluetooth/hci_request.c | 41 ++--
> > > > > > >
> > > > > > > -
> > > > > > > 1 file changed, 2 insertions(+), 39 deletions(-)
> > > > > > >
> > > > > > > This has been bugging me for since 5.9-rc1, when all
> > > > > > > bluetooth devices
> > > > > > > stopped working on my desktop system. I finally got the
> > > > > > > time
> > > > > > > to do
> > > > > > > bisection today, and it came down to this patch.
> > > > > > > Reverting
> > > > > > > it on top of
> > > > > > > 5.9-rc7 restored bluetooth devices and now my input
> > > > > > > devices
> > > > > > > properly
> > > > > > > work.
> > > > > > >
> > > > > > > As it's almost 5.9-final, any chance this can be merged
> > > > > > > now
> > > > > > > to fix the
> > > > > > > issue?
> > > > > >
> > > > > > can you be specific what breaks since our guys and I also
> > > > > > think
> > > > > > the
> > > > > > ChromeOS guys have been testing these series of patches
> > > > > > heavily.
> > > > >
> > > > > My bluetooth trackball does not connect at all. With this
> > > > > reverted, it
> > > > > all "just works".
> > > > >
> > > > > Same I think for a Bluetooth headset, can check that again if
> > > > > you
> > > > > really
> > > > > need me to, but the trackball is reliable here.
> > > > >
> > > > > > When you run btmon does it indicate any errors?
> > > > >
> > > > > How do I run it and where are the errors displayed?
> > > >
> > > > you can do btmon -w trace.log and just let it run like tcdpump.
> > >
> > > Ok, attached.
> > >
> > > The device is not connecting, and then I open the gnome bluetooth
> > > dialog
> > > and it scans for devices in the area, but does not connect to my
> > > existing devices at all.
> > >
> > > Any ideas?
> >
> > Use bluetoothctl instead, the Bluetooth Settings from GNOME also
> > run a
> > discovery the whole time the panel is opened, and this breaks a
> > fair
> > number of poor quality adapters. This is worked-around in the most
> > recent version, but using bluetoothctl is a better debugging option
> > in
> > all cases.
>
> Ok, but how do I use that tool? How do I shut down the gnome
> bluetooth
> stuff?
You close the settings window...
> I need newbie steps here please for what to run and what to show you.
bluetoothctl connect "bluetooth address"
eg.
bluetoothctl connect "12:34:56:78:90"
[PATCH] wireless: mwifiex: fix double free
From: Tom Rix
clang static analysis reports this problem:
sdio.c:2403:3: warning: Attempt to free released memory
kfree(card->mpa_rx.buf);
^~~
When mwifiex_init_sdio() fails in its first call to
mwifiex_alloc_sdio_mpa_buffer, it falls back to calling it
again. If the second alloc of mpa_tx.buf fails, the error
handler will try to free the old, previously freed mpa_rx.buf.
Reviewing the code, it looks like a second double free would
happen with mwifiex_cleanup_sdio().
So set both pointers to NULL when they are freed.
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex
driver")
Signed-off-by: Tom Rix
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 69911c728eb1..bde9e4bbfffe 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2403,6 +2403,8 @@ static int mwifiex_alloc_sdio_mpa_buffers(struct
mwifiex_adapter *adapter,
kfree(card->mpa_rx.buf);
card->mpa_tx.buf_size = 0;
card->mpa_rx.buf_size = 0;
+ card->mpa_tx.buf = NULL;
+ card->mpa_rx.buf = NULL;
}
return ret;
--
2.18.1
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sun, Oct 04, 2020 at 02:17:06PM +0200, Bastien Nocera wrote:
> On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote:
> > On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> > > Hi Greg,
> > >
> > > > > > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2
> > > > > > as it
> > > > > > breaks all bluetooth connections on my machine.
> > > > > >
> > > > > > Cc: Marcel Holtmann
> > > > > > Cc: Sathish Narsimman
> > > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when
> > > > > > updating whitelist")
> > > > > > Signed-off-by: Greg Kroah-Hartman
> > > > > >
> > > > > > ---
> > > > > > net/bluetooth/hci_request.c | 41 ++--
> > > > > > -
> > > > > > 1 file changed, 2 insertions(+), 39 deletions(-)
> > > > > >
> > > > > > This has been bugging me for since 5.9-rc1, when all
> > > > > > bluetooth devices
> > > > > > stopped working on my desktop system. I finally got the time
> > > > > > to do
> > > > > > bisection today, and it came down to this patch. Reverting
> > > > > > it on top of
> > > > > > 5.9-rc7 restored bluetooth devices and now my input devices
> > > > > > properly
> > > > > > work.
> > > > > >
> > > > > > As it's almost 5.9-final, any chance this can be merged now
> > > > > > to fix the
> > > > > > issue?
> > > > >
> > > > > can you be specific what breaks since our guys and I also think
> > > > > the
> > > > > ChromeOS guys have been testing these series of patches
> > > > > heavily.
> > > >
> > > > My bluetooth trackball does not connect at all. With this
> > > > reverted, it
> > > > all "just works".
> > > >
> > > > Same I think for a Bluetooth headset, can check that again if you
> > > > really
> > > > need me to, but the trackball is reliable here.
> > > >
> > > > > When you run btmon does it indicate any errors?
> > > >
> > > > How do I run it and where are the errors displayed?
> > >
> > > you can do btmon -w trace.log and just let it run like tcdpump.
> >
> > Ok, attached.
> >
> > The device is not connecting, and then I open the gnome bluetooth
> > dialog
> > and it scans for devices in the area, but does not connect to my
> > existing devices at all.
> >
> > Any ideas?
>
> Use bluetoothctl instead, the Bluetooth Settings from GNOME also run a
> discovery the whole time the panel is opened, and this breaks a fair
> number of poor quality adapters. This is worked-around in the most
> recent version, but using bluetoothctl is a better debugging option in
> all cases.
Ok, but how do I use that tool? How do I shut down the gnome bluetooth
stuff?
I need newbie steps here please for what to run and what to show you.
thanks,
greg k-h
[PATCH] objtool: avoid ../ headers includes and name clashes
Currently objtool headers are being included either by their base name
or included via ../ from a parent directory. In case of a base name usage:
#include "warn.h"
#include "arch_elf.h"
it does not make it apparent from which directory the file comes from.
To make it slightly better, and actually to avoid name clashes some arch
specific files have "arch_" suffix. And files from an arch folder have
to revert to including via ../ e.g:
#include "../../elf.h"
With additional architectures support and the code base growth there is
a need for clearer headers naming scheme for multiple reasons:
1. to make it instantly obvious where these files come from (objtool
itself / objtool arch|generic folders / some other external files),
2. to avoid name clashes of objtool arch specific headers, potential
obtool arch generic headers and the system header files (there is
/usr/include/elf.h already),
3. to avoid ../ includes and improve code readability.
4. to give a warm fuzzy feeling to developers who are mostly kernel
developers and are accustomed to linux kernel headers arranging
scheme.
Doesn't this make it instantly obvious where are these files come from?
#include
#include
And doesn't it look nicer to avoid ugly ../ includes? Which also
guarantees this is elf.h from the objtool and not /usr/include/elf.h.
#include
This patch defines and implements new objtool headers arranging
scheme. Which is:
- all generic headers go to include/objtool (similar to include/linux)
- all arch headers go to arch/$(SRCARCH)/include/arch (to get arch
prefix). This is similar to linux arch specific "asm/*" headers but we
are not abusing "asm" name and calling it what it is. This also helps
to prevent name clashes (arch is not used in system headers or kernel
exports).
To bring objtool to this state the following things are done:
1. current top level tools/objtool/ headers are moved into
include/objtool/ subdirectory,
2. arch specific headers, currently only arch/x86/include/ are moved into
arch/x86/include/arch/ and were stripped of "arch_" suffix,
3. new -I$(srctree)/tools/objtool/include include path to make
includes like possible,
4. rewriting file includes,
5. make git not to ignore include/objtool/ subdirectory.
Signed-off-by: Vasily Gorbik
---
tools/objtool/.gitignore | 2 +-
tools/objtool/Makefile | 1 +
tools/objtool/arch/x86/decode.c| 8
.../objtool/arch/x86/include/{ => arch}/cfi_regs.h | 0
.../arch/x86/include/{arch_elf.h => arch/elf.h}| 0
.../x86/include/{arch_special.h => arch/special.h} | 0
tools/objtool/arch/x86/special.c | 4 ++--
tools/objtool/builtin-check.c | 4 ++--
tools/objtool/builtin-orc.c| 4 ++--
tools/objtool/check.c | 14 +++---
tools/objtool/elf.c| 6 +++---
tools/objtool/{ => include/objtool}/arch.h | 4 ++--
tools/objtool/{ => include/objtool}/builtin.h | 0
tools/objtool/{ => include/objtool}/cfi.h | 2 +-
tools/objtool/{ => include/objtool}/check.h| 4 ++--
tools/objtool/{ => include/objtool}/elf.h | 0
tools/objtool/{ => include/objtool}/objtool.h | 2 +-
tools/objtool/{ => include/objtool}/special.h | 4 ++--
tools/objtool/{ => include/objtool}/warn.h | 2 +-
tools/objtool/objtool.c| 6 +++---
tools/objtool/orc_dump.c | 4 ++--
tools/objtool/orc_gen.c| 4 ++--
tools/objtool/special.c| 8
tools/objtool/weak.c | 2 +-
24 files changed, 43 insertions(+), 42 deletions(-)
rename tools/objtool/arch/x86/include/{ => arch}/cfi_regs.h (100%)
rename tools/objtool/arch/x86/include/{arch_elf.h => arch/elf.h} (100%)
rename tools/objtool/arch/x86/include/{arch_special.h => arch/special.h} (100%)
rename tools/objtool/{ => include/objtool}/arch.h (96%)
rename tools/objtool/{ => include/objtool}/builtin.h (100%)
rename tools/objtool/{ => include/objtool}/cfi.h (96%)
rename tools/objtool/{ => include/objtool}/check.h (96%)
rename tools/objtool/{ => include/objtool}/elf.h (100%)
rename tools/objtool/{ => include/objtool}/objtool.h (96%)
rename tools/objtool/{ => include/objtool}/special.h (94%)
rename tools/objtool/{ => include/objtool}/warn.h (98%)
diff --git a/tools/objtool/.gitignore b/tools/objtool/.gitignore
index 45cefda24c7b..14236db3677f 100644
--- a/tools/objtool/.gitignore
+++ b/tools/objtool/.gitignore
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
arch/x86/lib/inat-tables.c
-objtool
+/objtool
fixdep
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 33d1e3ca8efd..0d944a29a357 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -36,6 +36,7 @@ all: $(OBJTOOL)
Re: [PATCH] [PATCH] of_reserved_mem: Increase the number of reserved regions
Hi, Phil: Phil Chang 於 2020年10月4日 週日 下午1:51寫道： > > Certain SoCs need to support large amount of reserved memory > regions, especially to follow the GKI rules from Google. > In MTK new SoC requires more than 68 regions of reserved memory > for each IP's usage, such as load firmware to specific sapce, space > so that need to reserve more regisions regions. I guess this requirement is from Mediatek SoC, but I find below device tree and just find one reserved memory region, arch/arm64/boot/dts/mediatek/mt7622.dtsi arch/arm64/boot/dts/mediatek/mt8173.dtsi arch/arm64/boot/dts/mediatek/mt8516.dtsi Could you show me the 68 regions? Regards, Chun-Kuang. > > Signed-off-by: Joe Liu > Signed-off-by: YJ Chiang > Signed-off-by: Alix Wu > Signed-off-by: Phil Chang > --- > drivers/of/of_reserved_mem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > index 46b9371c8a33..595f0741dcef 100644 > --- a/drivers/of/of_reserved_mem.c > +++ b/drivers/of/of_reserved_mem.c > @@ -22,7 +22,7 @@ > #include > #include > > -#define MAX_RESERVED_REGIONS 64 > +#define MAX_RESERVED_REGIONS 128 > static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS]; > static int reserved_mem_count; > > -- > 2.18.0 > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
[PATCH] mm/vmscan: drop unneeded assignment in kswapd()
The refactoring to kswapd() in commit e716f2eb24de ("mm, vmscan: prevent
kswapd sleeping prematurely due to mismatched classzone_idx") turned an
assignment to reclaim_order into a dead store, as in all further paths,
reclaim_order will be assigned again before it is used.
make clang-analyzer on x86_64 tinyconfig caught my attention with:
mm/vmscan.c: warning: Although the value stored to 'reclaim_order' is
used in the enclosing expression, the value is never actually read from
'reclaim_order' [clang-analyzer-deadcode.DeadStores]
Compilers will detect this unneeded assignment and optimize this anyway.
So, the resulting binary is identical before and after this change.
Simplify the code and remove unneeded assignment to make clang-analyzer
happy.
No functional change. No change in binary code.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201002
Mel, please ack.
Andrew, please pick this minor non-urgent clean-up patch.
I quickly confirmed that the binary did not change with this change to the
source code; The hash of mm/vmscan.o remained the same before and after
the change.
So, in my setup:
md5sum mm/vmscan.o
7da4675477f186263e36b726cc2b859d mm/vmscan.o
linux-safety, please verify and validate this change.
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 466fc3144fff..130ee40c1255 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3896,7 +3896,7 @@ static int kswapd(void *p)
highest_zoneidx);
/* Read the new order and highest_zoneidx */
- alloc_order = reclaim_order = READ_ONCE(pgdat->kswapd_order);
+ alloc_order = READ_ONCE(pgdat->kswapd_order);
highest_zoneidx = kswapd_highest_zoneidx(pgdat,
highest_zoneidx);
WRITE_ONCE(pgdat->kswapd_order, 0);
--
2.17.1
Re: [PATCH AUTOSEL 5.8 28/29] spi: fsl-dspi: fix use-after-free in remove path
On Tue, Sep 29, 2020 at 08:22:16AM +0200, Sascha Hauer wrote: Hi Sasha, On Mon, Sep 28, 2020 at 09:30:25PM -0400, Sasha Levin wrote: From: Sascha Hauer [ Upstream commit 530b5affc675ade5db4a03f04ed7cd66806c8a1a ] spi_unregister_controller() not only unregisters the controller, but also frees the controller. This will free the driver data with it, so we must not access it later dspi_remove(). Solve this by allocating the driver data separately from the SPI controller. Signed-off-by: Sascha Hauer Link: https://lore.kernel.org/r/20200923131026.20707-1-s.ha...@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- drivers/spi/spi-fsl-dspi.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) This patch causes a regression and shouldn't be applied without the fix in https://lkml.org/lkml/2020/9/28/300. Looks like the fix didn't make it yet, so I'll drop the patch. -- Thanks, Sasha
Re: [PATCH AUTOSEL 5.8 14/29] regmap: debugfs: Fix handling of name string for debugfs init delays
On Tue, Sep 29, 2020 at 08:33:34AM +, Charles Keepax wrote: On Mon, Sep 28, 2020 at 09:30:11PM -0400, Sasha Levin wrote: From: Charles Keepax [ Upstream commit 94cc89eb8fa5039fcb6e3e3d50f929ddcccee095 ] In regmap_debugfs_init the initialisation of the debugfs is delayed if the root node isn't ready yet. Most callers of regmap_debugfs_init pass the name from the regmap_config, which is considered temporary ie. may be unallocated after the regmap_init call returns. This leads to a potential use after free, where config->name has been freed by the time it is used in regmap_debugfs_initcall. Afraid this patch had some issues if you are back porting it you definitely need to take these two patches as well: commit 1d512ee861b80da63cbc501b973c53131aa22f29 regmap: debugfs: Fix more error path regressions Looks like 1d512ee861b is queued for the merge window even though it's a bugfix for this release? I'm going to drop this patch. -- Thanks, Sasha
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > That leaves the only interesting places as vb2_dc_get_userptr() and > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > REQUIRED behavior in the function's comment about checking PTEs. It > > just DMA maps them. Badly broken. > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > Yeah, see also the follow_pfn trickery in > videobuf_dma_contig_user_get(), I think this is fully intentional and > userspace abi we can't break :-/ We don't need to break uABI, it just needs to work properly in the kernel: vma = find_vma_intersection() dma_buf = dma_buf_get_from_vma(vma) sg = dma_buf_p2p_dma_map(dma_buf) [.. do dma ..] dma_buf_unmap(sg) dma_buf_put(dma_buf) It is as we discussed before, dma buf needs to be discoverable from a VMA, at least for users doing this kind of stuff. > Yup this should be done with dma_buf instead, and v4l has that. But > old uapi and all that. This is why I said we might need a new > VM_DYNAMIC_PFNMAP or so, to make follow_pfn not resolve this in the > case where the driver manages the underlying iomem range (or whatever > it is) dynamically and moves buffer objects around, like drm drivers > do. But I looked, and we've run out of vma->vm_flags :-( A VM flag doesn't help - we need to introduce some kind of lifetime, and that has to be derived from the VMA. It needs data not just a flag > The other problem is that I also have no real working clue about all > the VM_* flags and what they all mean, and whether drm drivers set the > right ones in all cases (they probably don't, but oh well). > Documentation for this stuff in headers is a bit thin at times. Yah, I don't really know either :\ The comment above vm_normal_page() is a bit helpful. Don't know what VM_IO/VM_PFNMAP mean in their 3 combinations There are very few places that set VM_PFNMAP without VM_IO.. Jason
Re: [PATCH AUTOSEL 5.8 08/29] net: dsa: microchip: look for phy-mode in port nodes
On Tue, Sep 29, 2020 at 07:56:30AM +0200, Helmut Grohne wrote: Hi Sascha, On Tue, Sep 29, 2020 at 03:30:05AM +0200, Sasha Levin wrote: From: Helmut Grohne [ Upstream commit edecfa98f602a597666e3c5cab2677ada38d93c5 ] Documentation/devicetree/bindings/net/dsa/dsa.txt says that the phy-mode property should be specified on port nodes. However, the microchip drivers read it from the switch node. Let the driver use the per-port property and fall back to the old location with a warning. Fix in-tree users. I don't think this patch is useful for stable users. It corrects a device tree layout issue. Any existing users of the functionality will have an odd, but working device tree and that will continue working (with a warning) after applying this patch. It just has a property on the "wrong" node. I don't think I'd like to update my device tree in a stable update. I've dropped it, thanks! -- Thanks, Sasha
[PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled
The addition of MT8183 support added a dependency on the SCP remoteproc
module. However the initial patch used the "select" Kconfig directive,
which may result in the SCP module to not be compiled if remoteproc was
disabled. In such a case, mtk-vcodec would try to link against
non-existent SCP symbols. "select" was clearly misused here as explained
in kconfig-language.txt.
Replace this by a "depends" directive on at least one of the VPU and
SCP modules, to allow the driver to be compiled as long as one of these
is enabled, and adapt the code to support this new scenario.
Also adapt the Kconfig text to explain the extra requirements for MT8173
and MT8183.
Reported-by: Sakari Ailus
Signed-off-by: Alexandre Courbot
Acked-by: Randy Dunlap # build-tested
---
drivers/media/platform/Kconfig| 10 +--
.../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 72 ---
2 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index a3cb104956d5..98eb62e49ec2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -253,14 +253,16 @@ config VIDEO_MEDIATEK_VCODEC
depends on MTK_IOMMU || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on VIDEO_MEDIATEK_VPU || MTK_SCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
- select VIDEO_MEDIATEK_VPU
- select MTK_SCP
help
Mediatek video codec driver provides HW capability to
- encode and decode in a range of video formats
- This driver rely on VPU driver to communicate with VPU.
+ encode and decode in a range of video formats on MT8173
+ and MT8183.
+
+ Note that support for MT8173 requires VIDEO_MEDIATEK_VPU to
+ also be selected. Support for MT8183 depends on MTK_SCP.
To compile this driver as modules, choose M here: the
modules will be called mtk-vcodec-dec and mtk-vcodec-enc.
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
index 6c2a2568d844..23a80027a8fb 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
@@ -13,6 +13,7 @@ struct mtk_vcodec_fw_ops {
mtk_vcodec_ipi_handler handler, const char *name,
void *priv);
int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
unsigned int len, unsigned int wait);
+ void (*release)(struct mtk_vcodec_fw *fw);
};
struct mtk_vcodec_fw {
@@ -22,6 +23,8 @@ struct mtk_vcodec_fw {
struct mtk_scp *scp;
};
+#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VPU)
+
static int mtk_vcodec_vpu_load_firmware(struct mtk_vcodec_fw *fw)
{
return vpu_load_firmware(fw->pdev);
@@ -64,6 +67,27 @@ static int mtk_vcodec_vpu_ipi_send(struct mtk_vcodec_fw *fw,
int id, void *buf,
return vpu_ipi_send(fw->pdev, id, buf, len);
}
+static void mtk_vcodec_vpu_release(struct mtk_vcodec_fw *fw)
+{
+ put_device(>pdev->dev);
+}
+
+static void mtk_vcodec_vpu_reset_handler(void *priv)
+{
+ struct mtk_vcodec_dev *dev = priv;
+ struct mtk_vcodec_ctx *ctx;
+
+ mtk_v4l2_err("Watchdog timeout!!");
+
+ mutex_lock(>dev_mutex);
+ list_for_each_entry(ctx, >ctx_list, list) {
+ ctx->state = MTK_STATE_ABORT;
+ mtk_v4l2_debug(0, "[%d] Change to state MTK_STATE_ABORT",
+ ctx->id);
+ }
+ mutex_unlock(>dev_mutex);
+}
+
static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = {
.load_firmware = mtk_vcodec_vpu_load_firmware,
.get_vdec_capa = mtk_vcodec_vpu_get_vdec_capa,
@@ -71,8 +95,13 @@ static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = {
.map_dm_addr = mtk_vcodec_vpu_map_dm_addr,
.ipi_register = mtk_vcodec_vpu_set_ipi_register,
.ipi_send = mtk_vcodec_vpu_ipi_send,
+ .release = mtk_vcodec_vpu_release,
};
+#endif /* IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VPU) */
+
+#if IS_ENABLED(CONFIG_MTK_SCP)
+
static int mtk_vcodec_scp_load_firmware(struct mtk_vcodec_fw *fw)
{
return rproc_boot(scp_get_rproc(fw->scp));
@@ -107,6 +136,11 @@ static int mtk_vcodec_scp_ipi_send(struct mtk_vcodec_fw
*fw, int id, void *buf,
return scp_ipi_send(fw->scp, id, buf, len, wait);
}
+static void mtk_vcodec_scp_release(struct mtk_vcodec_fw *fw)
+{
+ scp_put(fw->scp);
+}
+
static const struct mtk_vcodec_fw_ops mtk_vcodec_rproc_msg = {
.load_firmware = mtk_vcodec_scp_load_firmware,
.get_vdec_capa = mtk_vcodec_scp_get_vdec_capa,
@@ -114,23 +148,10 @@ static const struct mtk_vcodec_fw_ops
mtk_vcodec_rproc_msg = {
.map_dm_addr = mtk_vcodec_vpu_scp_dm_addr,
.ipi_register = mtk_vcodec_scp_set_ipi_register,
.ipi_send =
Re: [PATCH] media: mtk-vcodec: fix builds when remoteproc is disabled
On Sun, Oct 4, 2020 at 1:50 AM Randy Dunlap wrote: > > On 10/3/20 6:09 AM, Alexandre Courbot wrote: > > The addition of MT8183 support added a dependency on the SCP remoteproc > > module. However the initial patch used the "select" Kconfig directive, > > which may result in the SCP module to not be compiled if remoteproc was > > disabled. In such a case, mtk-vcodec would try to link against > > non-existent SCP symbols. "select" was clearly misused here as explained > > in kconfig-language.txt. > > > > Replace this by a "depends" directive on at least one of the VPU and > > SCP modules, to allow the driver to be compiled as long as one of these > > is enabled, and adapt the code to support this new scenario. > > > > Also adapt the Kconfig text to explain the extra requirements for MT8173 > > and MT8183. > > > > Reported-by: Sakari Ailus > > Signed-off-by: Alexandre Courbot > > I was seeing this also, so I checked this patch. WFM. > > Acked-by: Randy Dunlap # build-tested Thanks for checking! I will send a v2 with your Acked-by and fix. > > See below. > > > --- > > drivers/media/platform/Kconfig| 11 +-- > > .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 72 --- > > 2 files changed, 55 insertions(+), 28 deletions(-) > > > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > > index a3cb104956d5..e559d9c529b6 100644 > > --- a/drivers/media/platform/Kconfig > > +++ b/drivers/media/platform/Kconfig > > @@ -253,14 +253,17 @@ config VIDEO_MEDIATEK_VCODEC > > depends on MTK_IOMMU || COMPILE_TEST > > depends on VIDEO_DEV && VIDEO_V4L2 > > depends on ARCH_MEDIATEK || COMPILE_TEST > > + depends on VIDEO_MEDIATEK_VPU || MTK_SCP > > select VIDEOBUF2_DMA_CONTIG > > select V4L2_MEM2MEM_DEV > > - select VIDEO_MEDIATEK_VPU > > - select MTK_SCP > > help > > Mediatek video codec driver provides HW capability to > > - encode and decode in a range of video formats > > - This driver rely on VPU driver to communicate with VPU. > > + encode and decode in a range of video formats on MT8173 > > + and MT8183. > > + > > + Note that support for support for MT8173 requires > > Drop one of "support for" above. (or "for support" ;) > > > + VIDEO_MEDIATEK_VPU to also be selected. Support for > > + MT8183 depends on MTK_SCP. > > > > To compile this driver as modules, choose M here: the > > modules will be called mtk-vcodec-dec and mtk-vcodec-enc. > > > thanks. > -- > ~Randy
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> > Hi Greg,
> >
> > > > > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2
> > > > > as it
> > > > > breaks all bluetooth connections on my machine.
> > > > >
> > > > > Cc: Marcel Holtmann
> > > > > Cc: Sathish Narsimman
> > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when
> > > > > updating whitelist")
> > > > > Signed-off-by: Greg Kroah-Hartman
> > > > >
> > > > > ---
> > > > > net/bluetooth/hci_request.c | 41 ++--
> > > > > -
> > > > > 1 file changed, 2 insertions(+), 39 deletions(-)
> > > > >
> > > > > This has been bugging me for since 5.9-rc1, when all
> > > > > bluetooth devices
> > > > > stopped working on my desktop system. I finally got the time
> > > > > to do
> > > > > bisection today, and it came down to this patch. Reverting
> > > > > it on top of
> > > > > 5.9-rc7 restored bluetooth devices and now my input devices
> > > > > properly
> > > > > work.
> > > > >
> > > > > As it's almost 5.9-final, any chance this can be merged now
> > > > > to fix the
> > > > > issue?
> > > >
> > > > can you be specific what breaks since our guys and I also think
> > > > the
> > > > ChromeOS guys have been testing these series of patches
> > > > heavily.
> > >
> > > My bluetooth trackball does not connect at all. With this
> > > reverted, it
> > > all "just works".
> > >
> > > Same I think for a Bluetooth headset, can check that again if you
> > > really
> > > need me to, but the trackball is reliable here.
> > >
> > > > When you run btmon does it indicate any errors?
> > >
> > > How do I run it and where are the errors displayed?
> >
> > you can do btmon -w trace.log and just let it run like tcdpump.
>
> Ok, attached.
>
> The device is not connecting, and then I open the gnome bluetooth
> dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
>
> Any ideas?
Use bluetoothctl instead, the Bluetooth Settings from GNOME also run a
discovery the whole time the panel is opened, and this breaks a fair
number of poor quality adapters. This is worked-around in the most
recent version, but using bluetoothctl is a better debugging option in
all cases.
Cheers
Re: [RFC][PATCHSET] epoll cleanups
On Sun, Oct 04, 2020 at 03:36:08AM +0100, Al Viro wrote: > Finally, there's the mess with reverse path check. When we insert > a new file into a epoll, we need to check that there won't be excessively long > (or excessively many) wakeup chains. If the target is not an epoll, we need > to check that for the target alone, but if it's another epoll we need the same > check done to everything reachable from that epoll. The way it's currently > done is Not Nice(tm): we collect the set of files to check and, once we have > verified the absence of loops, created a new epitem and inserted it into > the epoll data structures, we run reverse_path_check_proc() for every file > in the set. The set is maintained as a (global) cyclic list threaded through > some struct file. Everything is serialized on epmutex, so the list can be > global. Unfortunately, each struct file ends up with list_head embedded into > it, all for the sake of operation that is rare *and* involves a small fraction > of all struct file instances on the system. > Worse, files can end up disappearing while we are collecting the set; > explicit EPOLL_CTL_DEL does not grab epmutex, and final fput() won't touch > epmutex if all epitem refering to that file have already been removed. This > had been worked around this cycle (by grabbing temporary references to struct > file added to the set), but that's not a good solution. > What we need is to separate the head of epitem list (->f_ep_links) > from struct file; all we need in struct file is a reference to that head. > We could thread the list representing the set of files through those objects > (getting rid of 3 pointers in each struct file) and have epitem removal > free those objects if there's no epitems left *and* they are not included > into the set. Reference from struct file would be cleared as soon as there's > no epitems left. Dissolving the set would free those that have no epitems > left and thus would've been freed by ep_remove() if they hadn't been in the > set. > With some massage it can be done; we end up with > * 3 pointers gone from each struct file > * one pointer added to struct eventpoll > * two-pointer object kept for each non-epoll file that is currently watched by > some epoll. Have you considered just storing a pointer to each struct file in an epoll set in an XArray? Linked lists suck for modern CPUs, and there'd be no need to store any additional data in each struct file. Using xa_alloc() to store the pointer and throw away the index the pointer got stored at would leave you with something approximating a singly linked list, except it's an array. Which does zero memory allocations for a single entry and will then allocate a single node for your first 64 entries.
[RFC v5 1/1] selftests/cpuidle: Add support for cpuidle latency measurement
Measure cpuidle latencies on wakeup to determine and compare with the
advertsied wakeup latencies for each idle state.
Cpuidle wakeup latencies are determined for IPIs and can help
determine any deviations from what is advertsied by the hardware.
A baseline measurement for each case of IPIs is taken at 100 percent
CPU usage to quantify for the kernel-userpsace overhead
during execution.
Signed-off-by: Pratik Rajesh Sampat
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/cpuidle/Makefile | 7 +
tools/testing/selftests/cpuidle/cpuidle.c | 479 ++
tools/testing/selftests/cpuidle/settings | 1 +
4 files changed, 488 insertions(+)
create mode 100644 tools/testing/selftests/cpuidle/Makefile
create mode 100644 tools/testing/selftests/cpuidle/cpuidle.c
create mode 100644 tools/testing/selftests/cpuidle/settings
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 9018f45d631d..2bb0e87f76fd 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -8,6 +8,7 @@ TARGETS += cgroup
TARGETS += clone3
TARGETS += core
TARGETS += cpufreq
+TARGETS += cpuidle
TARGETS += cpu-hotplug
TARGETS += drivers/dma-buf
TARGETS += efivarfs
diff --git a/tools/testing/selftests/cpuidle/Makefile
b/tools/testing/selftests/cpuidle/Makefile
new file mode 100644
index ..d332485e1bc5
--- /dev/null
+++ b/tools/testing/selftests/cpuidle/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+TEST_GEN_PROGS := cpuidle
+
+CFLAGS += -O2
+LDLIBS += -lpthread
+
+include ../lib.mk
diff --git a/tools/testing/selftests/cpuidle/cpuidle.c
b/tools/testing/selftests/cpuidle/cpuidle.c
new file mode 100644
index ..b2f6a0e655b8
--- /dev/null
+++ b/tools/testing/selftests/cpuidle/cpuidle.c
@@ -0,0 +1,479 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Cpuidle latency measurement microbenchmark
+ *
+ * A mechanism to measure wakeup latency for IPI based interrupts. Results of
+ * this microbenchmark can be used to check and validate against the
+ * advertised latencies for each cpuidle state
+ *
+ * IPIs (using pipes) are used to wake the CPU up and measure the
+ * time difference
+ *
+ * Baseline measurements on 100 busy load are used to account for the
+ * kernel-userspace overhead
+ *
+ * Usage:
+ * ./cpuidle --mode --output
+ *
+ * Copyright (C) 2020 Pratik Rajesh Sampat , IBM
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define READ 0
+#define WRITE 1
+
+static int pipe_fd[2];
+static int *cpu_list;
+static int cpus;
+static int idle_states;
+static uint64_t *latency_list;
+
+static char *log_file = "cpuidle.log";
+
+static int get_online_cpus(int *online_cpu_list, int total_cpus)
+{
+ char filename[80];
+ int i, index = 0;
+ FILE *fptr;
+
+ for (i = 0; i < total_cpus; i++) {
+ char status;
+
+ sprintf(filename, "/sys/devices/system/cpu/cpu");
+ sprintf(filename + strlen(filename), "%d%s", i, "/online");
+ fptr = fopen(filename, "r");
+ if (!fptr)
+ continue;
+ assert(fscanf(fptr, "%c", ) != EOF);
+ if (status == '1')
+ online_cpu_list[index++] = i;
+ fclose(fptr);
+ }
+ return index;
+}
+
+static uint64_t us_to_ns(uint64_t val)
+{
+ return val * 1000;
+}
+
+static void get_latency(int cpu)
+{
+ char filename[80];
+ uint64_t latency;
+ FILE *fptr;
+ int state;
+
+ for (state = 0; state < idle_states; state++) {
+ sprintf(filename, "%s%d%s%d%s", "/sys/devices/system/cpu/cpu",
+ cpu, "/cpuidle/state",
+ state, "/latency");
+ fptr = fopen(filename, "r");
+ assert(fptr);
+
+ assert(fscanf(fptr, "%ld", ) != EOF);
+ latency_list[state] = latency;
+ fclose(fptr);
+ }
+}
+
+static int get_idle_state_count(int cpu)
+{
+ struct dirent *entry;
+ int dir_count = 0;
+ char filename[80];
+ DIR *dirp;
+
+ sprintf(filename, "%s%d%s", "/sys/devices/system/cpu/cpu",
+ cpu, "/cpuidle");
+
+ dirp = opendir(filename);
+ if (!dirp)
+ return -1;
+ while (entry = readdir(dirp)) {
+ if (entry->d_type == DT_DIR) {
+ if (strcmp(entry->d_name, ".") == 0 ||
+ strcmp(entry->d_name, "..") == 0)
+ continue;
+ dir_count++;
+ }
+ }
+ closedir(dirp);
+ return dir_count;
+}
+
+/* Enable or disable all idle states */
+static int state_all_idle(char *disable)
+{
+ char
[RFC v5 0/1] Selftest for cpuidle latency measurement
v4: https://lkml.org/lkml/2020/9/2/356 v4-->v5 Based on comments from Artem Bityutskiy, evaluation of timer based wakeup latencies may not be a fruitful measurement especially on the x86 platform which has the capability to pre-arm a CPU when a timer is set. Hence, including only the IPI based tests for latency measurement to acheive expected behaviour across platforms. kernel module + bash selftest approach which presents lower deviations and higher accuracy: https://lkml.org/lkml/2020/7/21/567 --- The patch series introduces a mechanism to measure wakeup latency for IPI based interrupts. The motivation behind this series is to find significant deviations behind advertised latency values To achieve this in the userspace, IPI latencies are calculated by sending information through pipes and inducing a wakeup. To account for delays from kernel-userspace interactions baseline observations are taken on a 100% busy CPU and subsequent obervations must be considered relative to that. One downside of the userspace approach in contrast to the kernel implementation is that the run to run variance can turn out to be high in the order of ms; which is the scope of the experiments at times. Another downside of the userspace approach is that it takes much longer to run and hence a command-line option quick and full are added to make sure quick 1 CPU tests can be carried out when needed and otherwise it can carry out a full system comprehensive test. Usage --- ./cpuidle --mode --output full: runs on all CPUS quick: run on a random CPU num_cpus: Limit the number of CPUS to run on Sample output snippet - --IPI Latency Test--- SRC_CPU DEST_CPU IPI_Latency(ns) ... 0 5 256178 0 6 478161 0 7 285445 0 8 273553 Expected IPI latency(ns): 10 Observed Average IPI latency(ns): 248334 Pratik Rajesh Sampat (1): selftests/cpuidle: Add support for cpuidle latency measurement tools/testing/selftests/Makefile | 1 + tools/testing/selftests/cpuidle/Makefile | 7 + tools/testing/selftests/cpuidle/cpuidle.c | 479 ++ tools/testing/selftests/cpuidle/settings | 1 + 4 files changed, 488 insertions(+) create mode 100644 tools/testing/selftests/cpuidle/Makefile create mode 100644 tools/testing/selftests/cpuidle/cpuidle.c create mode 100644 tools/testing/selftests/cpuidle/settings -- 2.26.2
Re: [BUG] slab: double free detected in cache 'kmalloc-128', objp daff5780
On Tue, Sep 15, 2020 at 1:00 PM Randy Dunlap wrote: > > On 9/15/20 4:41 AM, Peter Geis wrote: > > [33633.566567] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > Hi Peter, > > In the future, could you prevent long lines from being line-wrapped? > E.g., the 2 lines above should all be on one line. > It is much harder to read as it was posted. Apologies, I'll be sure to use an external client for bug reports from now on. > > thanks. > -- > ~Randy > This issue appears to have been resolved by: 678ff6a7afcc mm: slab: fix potential double free in ___cache_free Thank you.
Re: [PATCH v3 6/7] can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces
On 10/2/20 5:41 PM, Vincent Mailhol wrote:
> This driver supports the ES581.4, ES582.1 and ES584.1 interfaces from
> ETAS GmbH (https://www.etas.com/en/products/es58x.php).
>
> Co-developed-by: Arunachalam Santhanam
> Signed-off-by: Arunachalam Santhanam
> Signed-off-by: Vincent Mailhol
> ---
>
> Changes in v3:
> - Remove all the calls to likely() and unlikely().
>
> Changes in v2:
> - Fixed -W1 warnings (v1 was tested with GCC -WExtra but not with -W1).
> ---
> drivers/net/can/usb/Kconfig |9 +
> drivers/net/can/usb/Makefile|1 +
> drivers/net/can/usb/etas_es58x/Makefile |3 +
> drivers/net/can/usb/etas_es58x/es581_4.c| 559
> drivers/net/can/usb/etas_es58x/es581_4.h| 237 ++
> drivers/net/can/usb/etas_es58x/es58x_core.c | 2725 +++
> drivers/net/can/usb/etas_es58x/es58x_core.h | 700 +
> drivers/net/can/usb/etas_es58x/es58x_fd.c | 648 +
> drivers/net/can/usb/etas_es58x/es58x_fd.h | 243 ++
> 9 files changed, 5125 insertions(+)
> create mode 100644 drivers/net/can/usb/etas_es58x/Makefile
> create mode 100644 drivers/net/can/usb/etas_es58x/es581_4.c
> create mode 100644 drivers/net/can/usb/etas_es58x/es581_4.h
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_core.c
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_core.h
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_fd.c
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_fd.h
[...]
Just one header file for now :)
> diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.h
> b/drivers/net/can/usb/etas_es58x/es58x_core.h
> new file mode 100644
> index ..359ddc44a3ad
> --- /dev/null
> +++ b/drivers/net/can/usb/etas_es58x/es58x_core.h
> @@ -0,0 +1,700 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/* Driver for ETAS GmbH ES58X USB CAN(-FD) Bus Interfaces.
> + *
> + * File es58x_core.h: All common definitions and declarations.
> + *
> + * Copyright (C) 2019 Robert Bosch Engineering and Business
> + * Solutions. All rights reserved.
> + * Copyright (C) 2020 ETAS K.K.. All rights reserved.
> + */
> +
> +#ifndef __ES58X_COMMON_H__
> +#define __ES58X_COMMON_H__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "es581_4.h"
> +#include "es58x_fd.h"
> +
> +/* Size of a CAN Standard Frame (rounded up and ignoring bitsuffing). */
> +#define ES58X_SFF_BYTES(data_len) (round_up(47, 8) / 8 + (data_len))
DIV_ROUNDUP
> +/* Size of a CAN Extended Frame (rounded up and ignoring bitsuffing). */
> +#define ES58X_EFF_BYTES(data_len) (round_up(67, 8) / 8 + (data_len))
dame here
> +/* Maximum size of a CAN frame (rounded up and ignoring bitsuffing). */
> +#define ES58X_CAN_FRAME_BYTES_MAX ES58X_EFF_BYTES(CAN_MAX_DLEN)
please add a new file between the define and the doc of the next one
> +/* Maximum size of a CAN-FD frame (rough estimation because
> + * ES58X_SFF_BYTES() and ES58X_EFF_BYTES() macros are using the
> + * constant values for CAN not CAN-FD).
> + */
> +#define ES58X_CANFD_FRAME_BYTES_MAX ES58X_EFF_BYTES(CANFD_MAX_DLEN)
> +
> +/* Driver constants */
> +#define ES58X_RX_URBS_MAX 5 // Empirical value
> +#define ES58X_TX_URBS_MAX 8 // Empirical value
please use one space only
> +
> +#define ES58X_MAX(param) \
> + (ES581_4_##param > ES58X_FD_##param ? \
> + ES581_4_##param : ES58X_FD_##param)
> +#define ES58X_TX_BULK_MAX ES58X_MAX(TX_BULK_MAX)
> +#define ES58X_RX_BULK_MAX ES58X_MAX(RX_BULK_MAX)
> +#define ES58X_RX_LOOPBACK_BULK_MAX ES58X_MAX(RX_LOOPBACK_BULK_MAX)
> +#define ES58X_NUM_CAN_CH_MAX ES58X_MAX(NUM_CAN_CH)
> +
> +/* Use this when channel index is irrelevant (e.g. device
> + * timestamp).
> + */
> +#define ES58X_CHANNEL_IDX_NA 0xFF
> +#define ES58X_EMPTY_MSG NULL
> +
> +/* Threshold on consecutive CAN_STATE_ERROR_PASSIVE. If we receive
> + * ES58X_CONSECUTIVE_ERR_PASSIVE_MAX times the event
> + * ES58X_ERR_CRTL_PASSIVE in a row without any successful Rx or Tx,
> + * we force the device to switch to CAN_STATE_BUS_OFF state.
> + */
> +#define ES58X_CONSECUTIVE_ERR_PASSIVE_MAX 254
Does the device recover from bus off automatically or why is this needed?
> +
> +enum es58x_self_reception_mode {
> + ES58X_SELF_RECEPTION_OFF = 0,
> + ES58X_SELF_RECEPTION_ON = 1
> +};
nitpick: can you name all enums (here and below) according to the type?
e.g. ES58x_SELF_RECEPTION_MODE_OFF
> +
> +enum es58x_physical_media {
> + ES58X_MEDIA_HIGH_SPEED = 1,
> + ES58X_MEDIA_FAULT_TOLERANT = 2
You mean with FAULT_TOLERANT you mean ISO 11898-3? According to [1] they should
be named low speed.
[1]
https://can-cia.org/news/press-releases/view/harmonized-transceiver-naming/2020/7/16/
> +};
> +
> +enum es58x_samples_per_bit {
> + ES58X_ONE_SAMPLE_PER_BIT = 1,
> +
> + /* Some CAN controllers do not support three samples per
> + * bit. In this case the default value of one sample per
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sun, Oct 4, 2020 at 1:24 AM Jason Gunthorpe wrote:
> On Sat, Oct 03, 2020 at 03:52:32PM -0700, John Hubbard wrote:
> > On 10/3/20 2:45 AM, Daniel Vetter wrote:
> > > On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
> > > >
> > > > On 10/2/20 10:53 AM, Daniel Vetter wrote:
> > > > > For $reasons I've stumbled over this code and I'm not sure the change
> > > > > to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> > > > > convert get_user_pages() --> pin_user_pages()") was entirely correct.
> > > > >
> > > > > This here is used for long term buffers (not just quick I/O) like
> > > > > RDMA, and John notes this in his patch. But I thought the rule for
> > > > > these is that they need to add FOLL_LONGTERM, which John's patch
> > > > > didn't do.
> > > >
> > > > Yep. The earlier gup --> pup conversion patches were intended to not
> > > > have any noticeable behavior changes, and FOLL_LONGTERM, with it's
> > > > special cases and such, added some risk that I wasn't ready to take
> > > > on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
> > > > up. So there was some doubt at least in my mind, about which sites
> > > > should have it.
> > > >
> > > > But now that we're here, I think it's really good that you've brought
> > > > this up. It's definitely time to add FOLL_LONGTERM wherever it's
> > > > missing.
> > >
> > > So should I keep this patch, or will it collide with a series you're
> > > working on?
> >
> > It doesn't collide with anything on my end yet, because I've been slow to
> > pick up on the need for changing callsites to add FOLL_LONGTERM. :)
> >
> > And it looks like that's actually a problem, because:
> >
> > >
> > > Also with the firmed up rules, correct that I can also drop the
> > > vma_is_fsdax check when the FOLL_LONGTERM flag is set?
> >
> > That's the right direction to go *in general*, but I see that the
> > pin_user_pages code is still a bit stuck in the past. And this patch
> > won't actually work, with or without that vma_is_fsdax() check.
> > Because:
> >
> > get_vaddr_frames(FOLL_LONGTERM)
> >pin_user_pages_locked()
> > if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM))
> > return -EINVAL;
>
> There is no particular reason this code needs to have the mm sem at
> that point.
>
> It should call pin_user_pages_fast() and only if that fails get the mmap
> lock and extract the VMA to do broken hackery.
Yeah I think that works. I tried understanding gup.c code a bit more,
and it looks like FOLL_LONGTERM only works for the pup_fast variant
right now? All others seem to have this comment that it's somehow
incompatible with FAULT_FLAG_ALLOW_RETRY and daxfs. But grepping
around for that didn't show up anything, at least not nearby dax code.
For my understanding of all this, what's the hiccup there?
For plans, I only started this for a bit of my own learning, but I
think I'll respin with the following changes:
- convert exynos and habanalabs to pin_user_pages_fast directly,
instead of going through this frame-vector detour
- move the locking and convert get_vaddr_frames to pup_fast as Jason suggested
- hack up some truly gross rfc to plug the follow_pfn hole
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v3 5/7] can: dev: add a helper function to calculate the duration of one bit
On 10/4/20 1:06 PM, Marc Kleine-Budde wrote:
> On 10/2/20 5:41 PM, Vincent Mailhol wrote:
>> Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
>> through include/linux/can/dev.h
>>
>> Add an helper function can_bit_time() which returns the duration (in
>> time quanta) of one CAN bit.
>>
>> Rationale for this patch: the sync segment and the bit time are two
>> concepts which are defined in the CAN ISO standard. Device drivers for
>> CAN might need those.
>>
>> Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
>> additional information.
>>
>> Signed-off-by: Vincent Mailhol
[...]
>> index 791c452d98e1..77c3ea49b8fb 100644
>> --- a/include/linux/can/dev.h
>> +++ b/include/linux/can/dev.h
>> @@ -82,6 +82,21 @@ struct can_priv {
>> #endif
>> };
>>
>> +#define CAN_SYNC_SEG 1
>> +
>> +/*
>> + * can_bit_time() - Duration of one bit
>> + *
>> + * Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
>> + * additional information.
>> + *
>> + * Return: the number of time quanta in one bit.
>> + */
>> +static inline int can_bit_time(struct can_bittiming *bt)
>
> make it return an unsigned int
> make the bt pointer const
I'll change this while applying the patch.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 5/7] can: dev: add a helper function to calculate the duration of one bit
On 10/2/20 5:41 PM, Vincent Mailhol wrote:
> Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
> through include/linux/can/dev.h
>
> Add an helper function can_bit_time() which returns the duration (in
> time quanta) of one CAN bit.
>
> Rationale for this patch: the sync segment and the bit time are two
> concepts which are defined in the CAN ISO standard. Device drivers for
> CAN might need those.
>
> Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
> additional information.
>
> Signed-off-by: Vincent Mailhol
> ---
>
> Changes in v3: None
>
> Changes in v2: None
> ---
> drivers/net/can/dev.c | 13 ++---
> include/linux/can/dev.h | 15 +++
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> index 8c3e11820e03..6070b4ab3bd8 100644
> --- a/drivers/net/can/dev.c
> +++ b/drivers/net/can/dev.c
> @@ -60,7 +60,6 @@ EXPORT_SYMBOL_GPL(can_len2dlc);
>
> #ifdef CONFIG_CAN_CALC_BITTIMING
> #define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */
> -#define CAN_CALC_SYNC_SEG 1
>
> /* Bit-timing calculation derived from:
> *
> @@ -86,8 +85,8 @@ can_update_sample_point(const struct can_bittiming_const
> *btc,
> int i;
>
> for (i = 0; i <= 1; i++) {
> - tseg2 = tseg + CAN_CALC_SYNC_SEG -
> - (sample_point_nominal * (tseg + CAN_CALC_SYNC_SEG)) /
> + tseg2 = tseg + CAN_SYNC_SEG -
> + (sample_point_nominal * (tseg + CAN_SYNC_SEG)) /
> 1000 - i;
> tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max);
> tseg1 = tseg - tseg2;
> @@ -96,8 +95,8 @@ can_update_sample_point(const struct can_bittiming_const
> *btc,
> tseg2 = tseg - tseg1;
> }
>
> - sample_point = 1000 * (tseg + CAN_CALC_SYNC_SEG - tseg2) /
> - (tseg + CAN_CALC_SYNC_SEG);
> + sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) /
> + (tseg + CAN_SYNC_SEG);
> sample_point_error = abs(sample_point_nominal - sample_point);
>
> if (sample_point <= sample_point_nominal &&
> @@ -145,7 +144,7 @@ static int can_calc_bittiming(struct net_device *dev,
> struct can_bittiming *bt,
> /* tseg even = round down, odd = round up */
> for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1;
>tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) {
> - tsegall = CAN_CALC_SYNC_SEG + tseg / 2;
> + tsegall = CAN_SYNC_SEG + tseg / 2;
>
> /* Compute all possible tseg choices (tseg=tseg1+tseg2) */
> brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2;
> @@ -223,7 +222,7 @@ static int can_calc_bittiming(struct net_device *dev,
> struct can_bittiming *bt,
>
> /* real bitrate */
> bt->bitrate = priv->clock.freq /
> - (bt->brp * (CAN_CALC_SYNC_SEG + tseg1 + tseg2));
> + (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2));
>
> return 0;
> }
> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
> index 791c452d98e1..77c3ea49b8fb 100644
> --- a/include/linux/can/dev.h
> +++ b/include/linux/can/dev.h
> @@ -82,6 +82,21 @@ struct can_priv {
> #endif
> };
>
> +#define CAN_SYNC_SEG 1
> +
> +/*
> + * can_bit_time() - Duration of one bit
> + *
> + * Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
> + * additional information.
> + *
> + * Return: the number of time quanta in one bit.
> + */
> +static inline int can_bit_time(struct can_bittiming *bt)
make it return an unsigned int
make the bt pointer const
> +{
> + return CAN_SYNC_SEG + bt->prop_seg + bt->phase_seg1 + bt->phase_seg2;
> +}
> +
> /*
> * get_can_dlc(value) - helper macro to cast a given data length code (dlc)
> * to u8 and ensure the dlc value to be max. 8 bytes.
>
tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] USB: serial: option: Add Telit FT980-KS composition
On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. thanks Lars
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sun, Oct 04, 2020 at 12:51:24PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> > Hi Greg,
> >
> > >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> > >>> breaks all bluetooth connections on my machine.
> > >>>
> > >>> Cc: Marcel Holtmann
> > >>> Cc: Sathish Narsimman
> > >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating
> > >>> whitelist")
> > >>> Signed-off-by: Greg Kroah-Hartman
> > >>> ---
> > >>> net/bluetooth/hci_request.c | 41 ++---
> > >>> 1 file changed, 2 insertions(+), 39 deletions(-)
> > >>>
> > >>> This has been bugging me for since 5.9-rc1, when all bluetooth devices
> > >>> stopped working on my desktop system. I finally got the time to do
> > >>> bisection today, and it came down to this patch. Reverting it on top of
> > >>> 5.9-rc7 restored bluetooth devices and now my input devices properly
> > >>> work.
> > >>>
> > >>> As it's almost 5.9-final, any chance this can be merged now to fix the
> > >>> issue?
> > >>
> > >> can you be specific what breaks since our guys and I also think the
> > >> ChromeOS guys have been testing these series of patches heavily.
> > >
> > > My bluetooth trackball does not connect at all. With this reverted, it
> > > all "just works".
> > >
> > > Same I think for a Bluetooth headset, can check that again if you really
> > > need me to, but the trackball is reliable here.
> > >
> > >> When you run btmon does it indicate any errors?
> > >
> > > How do I run it and where are the errors displayed?
> >
> > you can do btmon -w trace.log and just let it run like tcdpump.
>
> Ok, attached.
>
> The device is not connecting, and then I open the gnome bluetooth dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
>
And any hints on how to read this file? 'btsnoop' has no man page, and
the --help options are pretty sparse :(
thanks,
greg k-h
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> >>> breaks all bluetooth connections on my machine.
> >>>
> >>> Cc: Marcel Holtmann
> >>> Cc: Sathish Narsimman
> >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating
> >>> whitelist")
> >>> Signed-off-by: Greg Kroah-Hartman
> >>> ---
> >>> net/bluetooth/hci_request.c | 41 ++---
> >>> 1 file changed, 2 insertions(+), 39 deletions(-)
> >>>
> >>> This has been bugging me for since 5.9-rc1, when all bluetooth devices
> >>> stopped working on my desktop system. I finally got the time to do
> >>> bisection today, and it came down to this patch. Reverting it on top of
> >>> 5.9-rc7 restored bluetooth devices and now my input devices properly
> >>> work.
> >>>
> >>> As it's almost 5.9-final, any chance this can be merged now to fix the
> >>> issue?
> >>
> >> can you be specific what breaks since our guys and I also think the
> >> ChromeOS guys have been testing these series of patches heavily.
> >
> > My bluetooth trackball does not connect at all. With this reverted, it
> > all "just works".
> >
> > Same I think for a Bluetooth headset, can check that again if you really
> > need me to, but the trackball is reliable here.
> >
> >> When you run btmon does it indicate any errors?
> >
> > How do I run it and where are the errors displayed?
>
> you can do btmon -w trace.log and just let it run like tcdpump.
Ok, attached.
The device is not connecting, and then I open the gnome bluetooth dialog
and it scans for devices in the area, but does not connect to my
existing devices at all.
Any ideas?
thanks,
greg k-h
btsnoop � 5 5�� ⎉,~�Linux version
5.9.0-rc7-4-g0216685bdd99 (x86_64)! !�� ⎉,~�Bluetooth subsystem
version
2.22 ⎉,~� pe��Phci0 ⎉,~�
⎉,~�pe��P �� ⎉,~� bluetoothd ⎉-:�L
⎉-:�Y �
⎉-:�p ⎉-:�q
⎉-:�� : ⎉-:��B
⎉-<�_B ⎉-<�n
���.& ⎉-<� ⎉-<�$A
$ ⎉-<��A ⎉-<��B
⎉-<�lB
⎉-<�t3�� ⎉-<�'
⎉-<�T : ⎉-<�^ ⎉-<Ŗ �4�_� � 3 � � ⎉-<ŻR
� thread
k F7
3 ⎉-<��R
⎉-<�
⎉-<�0 �4�_� � 2 � � ⎉-<�9
��!5% �� o�o��wk�;QF*t����4� 3 3 ⎉-D�= ��!5%� o�o��wk�;QF*t����4�
⎉-E=pB ⎉-EH�B
⎉-EH�B ⎉-ET�B : : ⎉-H�Y>8
*�!�o� �� �L t'�ڶDE � r��5 IP� 4 4 ⎉-H�!>2
*�!�o� �� "
S19743271de39a3d6C J J ⎉-H�@ *�!�o��6 �L t'�ڶDE �
r��5 IP�" S19743271de39a3d6C 5 5 ⎉-I�>3
��!lT �� & MyRun 18004074 # # ⎉-I
�>!
��!lT �� &4 4 ⎉-I
� ��!lT� & MyRun 18004074&
⎉-L �B ⎉-L�B ⎉-L�B
⎉-L&�B ⎉-L�/�6 �ZV( <�[�
KD-43XD8305
=d� d
B B ⎉-L�' 6 �ZV( �.
KD-43XD8305
=d� d
< 5 5 ⎉-M8%>3
��!lT �� & MyRun 18004074 # # ⎉-M?�>!
��!lT �� &4 4 ⎉-M@ ��!lT�
&MyRun 18004074& ⎉-O�SB
⎉-O��B ⎉-O��B
⎉-O�VB 5 5 ⎉-P�>3
��!lT �� & MyRun 18004074 # # ⎉-P
�>!
��!lT �� &4 4 ⎉-P
� ��!lT� & MyRun 18004074&
⎉-S$]B ⎉-S38B ⎉-S3]B
⎉-S@�B
[PATCH] ASoC: omap-mcbsp: Fix use of uninitialised pointer
Commit 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP
and Sidetone function split"), in rearranging various files, also replaced
calls to platform_get_resource_by_name() + devm_ioremap_resource() with a
single call to devm_platform_ioremap_resource_byname(). However, the
struct resource is needed as we access its members so at present a null
pointer is dereferenced. Fix by doing things the old way.
Addresses-Coverity-ID: 1497530 ("Memory - illegal accesses")
Fixes: 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP and
Sidetone function split")
Signed-off-by: Alex Dewar
---
sound/soc/ti/omap-mcbsp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c
index 186cea91076f..6025b30bbe77 100644
--- a/sound/soc/ti/omap-mcbsp.c
+++ b/sound/soc/ti/omap-mcbsp.c
@@ -620,7 +620,11 @@ static int omap_mcbsp_init(struct platform_device *pdev)
spin_lock_init(>lock);
mcbsp->free = true;
- mcbsp->io_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpu");
+ if (!res)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ mcbsp->io_base = devm_ioremap_resource(>dev, res);
if (IS_ERR(mcbsp->io_base))
return PTR_ERR(mcbsp->io_base);
--
2.28.0
[PATCH v3] i2c: pxa: move to generic GPIO recovery
Starting with
commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
GPIO bus recovery is supported by the I2C core, so we can remove the
driver implementation and use that one instead.
Signed-off-by: Codrin Ciubotariu
---
patch not tested.
Changes in v3:
- fix compile errors from unprepare_recovery callback
Changes in v2:
- readded the pinctrl state change to default from the
unprepare_recovery callback;
drivers/i2c/busses/i2c-pxa.c | 76
1 file changed, 8 insertions(+), 68 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 35ca2c02c9b9..a636ea0eb50a 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -264,9 +264,6 @@ struct pxa_i2c {
u32 hs_mask;
struct i2c_bus_recovery_info recovery;
- struct pinctrl *pinctrl;
- struct pinctrl_state*pinctrl_default;
- struct pinctrl_state*pinctrl_recovery;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -1305,13 +1302,12 @@ static void i2c_pxa_prepare_recovery(struct i2c_adapter
*adap)
*/
gpiod_set_value(i2c->recovery.scl_gpiod, ibmr & IBMR_SCLS);
gpiod_set_value(i2c->recovery.sda_gpiod, ibmr & IBMR_SDAS);
-
- WARN_ON(pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_recovery));
}
static void i2c_pxa_unprepare_recovery(struct i2c_adapter *adap)
{
struct pxa_i2c *i2c = adap->algo_data;
+ struct i2c_bus_recovery_info *bri = adap->bus_recovery_info;
u32 isr;
/*
@@ -1325,7 +1321,7 @@ static void i2c_pxa_unprepare_recovery(struct i2c_adapter
*adap)
i2c_pxa_do_reset(i2c);
}
- WARN_ON(pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_default));
+ WARN_ON(pinctrl_select_state(bri->pinctrl, bri->pins_default));
dev_dbg(>adap.dev, "recovery: IBMR 0x%08x ISR 0x%08x\n",
readl(_IBMR(i2c)), readl(_ISR(i2c)));
@@ -1347,76 +1343,20 @@ static int i2c_pxa_init_recovery(struct pxa_i2c *i2c)
if (IS_ENABLED(CONFIG_I2C_PXA_SLAVE))
return 0;
- i2c->pinctrl = devm_pinctrl_get(dev);
- if (PTR_ERR(i2c->pinctrl) == -ENODEV)
- i2c->pinctrl = NULL;
- if (IS_ERR(i2c->pinctrl))
- return PTR_ERR(i2c->pinctrl);
-
- if (!i2c->pinctrl)
- return 0;
-
- i2c->pinctrl_default = pinctrl_lookup_state(i2c->pinctrl,
- PINCTRL_STATE_DEFAULT);
- i2c->pinctrl_recovery = pinctrl_lookup_state(i2c->pinctrl, "recovery");
-
- if (IS_ERR(i2c->pinctrl_default) || IS_ERR(i2c->pinctrl_recovery)) {
- dev_info(dev, "missing pinmux recovery information: %ld %ld\n",
-PTR_ERR(i2c->pinctrl_default),
-PTR_ERR(i2c->pinctrl_recovery));
- return 0;
- }
-
- /*
-* Claiming GPIOs can influence the pinmux state, and may glitch the
-* I2C bus. Do this carefully.
-*/
- bri->scl_gpiod = devm_gpiod_get(dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
- if (bri->scl_gpiod == ERR_PTR(-EPROBE_DEFER))
- return -EPROBE_DEFER;
- if (IS_ERR(bri->scl_gpiod)) {
- dev_info(dev, "missing scl gpio recovery information: %pe\n",
-bri->scl_gpiod);
- return 0;
- }
-
- /*
-* We have SCL. Pull SCL low and wait a bit so that SDA glitches
-* have no effect.
-*/
- gpiod_direction_output(bri->scl_gpiod, 0);
- udelay(10);
- bri->sda_gpiod = devm_gpiod_get(dev, "sda", GPIOD_OUT_HIGH_OPEN_DRAIN);
-
- /* Wait a bit in case of a SDA glitch, and then release SCL. */
- udelay(10);
- gpiod_direction_output(bri->scl_gpiod, 1);
-
- if (bri->sda_gpiod == ERR_PTR(-EPROBE_DEFER))
- return -EPROBE_DEFER;
-
- if (IS_ERR(bri->sda_gpiod)) {
- dev_info(dev, "missing sda gpio recovery information: %pe\n",
-bri->sda_gpiod);
+ bri->pinctrl = devm_pinctrl_get(dev);
+ if (PTR_ERR(bri->pinctrl) == -ENODEV) {
+ bri->pinctrl = NULL;
return 0;
}
+ if (IS_ERR(bri->pinctrl))
+ return PTR_ERR(bri->pinctrl);
bri->prepare_recovery = i2c_pxa_prepare_recovery;
bri->unprepare_recovery = i2c_pxa_unprepare_recovery;
- bri->recover_bus = i2c_generic_scl_recovery;
i2c->adap.bus_recovery_info = bri;
- /*
-* Claiming GPIOs can change the pinmux state, which confuses the
-* pinctrl since pinctrl's idea of the current setting is unaffected
-* by the pinmux change caused by claiming the GPIO. Work around that
-* by switching pinctrl to the GPIO state here. We do it this way to
-* avoid glitching the I2C bus.
-*/
-
[PATCH 2/2] ath11k: Handle errors if peer creation fails
ath11k_peer_create() is called without its return value being checked,
meaning errors will be unhandled. Add missing check and, as the mutex is
unconditionally unlocked on leaving this function, simplify the exit
path.
Addresses-Coverity-ID: 1497531 ("Code maintainability issues")
Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
Signed-off-by: Alex Dewar
---
drivers/net/wireless/ath/ath11k/mac.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c
b/drivers/net/wireless/ath/ath11k/mac.c
index 7f8dd47d2333..58db1b57b941 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -5211,7 +5211,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
struct ath11k *ar = hw->priv;
struct ath11k_base *ab = ar->ab;
struct ath11k_vif *arvif = (void *)vif->drv_priv;
- int ret;
+ int ret = 0;
struct peer_create_params param;
mutex_lock(>conf_mutex);
@@ -5225,13 +5225,12 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw
*hw,
arvif->vdev_type != WMI_VDEV_TYPE_AP &&
arvif->vdev_type != WMI_VDEV_TYPE_MONITOR) {
memcpy(>chanctx, ctx, sizeof(*ctx));
- mutex_unlock(>conf_mutex);
- return 0;
+ goto unlock;
}
if (WARN_ON(arvif->is_started)) {
- mutex_unlock(>conf_mutex);
- return -EBUSY;
+ ret = -EBUSY;
+ goto unlock;
}
if (ab->hw_params.vdev_start_delay) {
@@ -5239,6 +5238,8 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
param.peer_type = WMI_PEER_TYPE_DEFAULT;
param.peer_addr = ar->mac_addr;
ret = ath11k_peer_create(ar, arvif, NULL, );
+ if (ret)
+ goto unlock;
}
ret = ath11k_mac_vdev_start(arvif, >def);
@@ -5246,23 +5247,19 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw
*hw,
ath11k_warn(ab, "failed to start vdev %i addr %pM on freq %d:
%d\n",
arvif->vdev_id, vif->addr,
ctx->def.chan->center_freq, ret);
- goto err;
+ goto unlock;
}
if (arvif->vdev_type == WMI_VDEV_TYPE_MONITOR) {
ret = ath11k_monitor_vdev_up(ar, arvif->vdev_id);
if (ret)
- goto err;
+ goto unlock;
}
arvif->is_started = true;
/* TODO: Setup ps and cts/rts protection */
- mutex_unlock(>conf_mutex);
-
- return 0;
-
-err:
+unlock:
mutex_unlock(>conf_mutex);
return ret;
--
2.28.0
[PATCH 1/2] ath11k: Fix memory leak on error path
In ath11k_mac_setup_iface_combinations(), if memory cannot be assigned
for the variable limits, then the memory assigned to combinations will
be leaked. Fix this.
Addresses-Coverity-ID: 1497534 ("Resource leaks")
Fixes: 2626c269702e ("ath11k: add interface_modes to hw_params")
Signed-off-by: Alex Dewar
---
drivers/net/wireless/ath/ath11k/mac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c
b/drivers/net/wireless/ath/ath11k/mac.c
index 3f63a7bd6b59..7f8dd47d2333 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -6041,8 +6041,10 @@ static int ath11k_mac_setup_iface_combinations(struct
ath11k *ar)
n_limits = 2;
limits = kcalloc(n_limits, sizeof(*limits), GFP_KERNEL);
- if (!limits)
+ if (!limits) {
+ kfree(combinations);
return -ENOMEM;
+ }
limits[0].max = 1;
limits[0].types |= BIT(NL80211_IFTYPE_STATION);
--
2.28.0
RE: [PATCH 1/8] staging: rtl8723bs: replace RND4 with round_up()
From: Ross Schmidt > Sent: 04 October 2020 02:18 > > Use round_up instead of define RND4. RND4 was also particularly horrid! ... > diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c > b/drivers/staging/rtl8723bs/core/rtw_security.c > index 7f74e1d05b3a..159d32ace2bc 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_security.c > +++ b/drivers/staging/rtl8723bs/core/rtw_security.c > @@ -260,7 +260,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 > *pxmitframe) > arcfour_encrypt(, payload+length, > crc, 4); > > pframe += pxmitpriv->frag_len; > - pframe = (u8 *)RND4((SIZE_PTR)(pframe)); > + pframe = (u8 *)round_up((SIZE_PTR)(pframe), 4); I also suspect this is equivalent to: pframe == round_up(pxmitpriv->frag_len, 4); Does make one wonder whether the skipped bytes need to be zeroed though. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
