[PATCH] kconfig: remove stale lxdialog/.gitignore
When this .gitignore was added, lxdialog was an independent hostprogs-y. Now that all objects in lxdialog/ are directly linked to mconf, the lxdialog is no longer generated. Signed-off-by: Masahiro Yamada --- scripts/kconfig/lxdialog/.gitignore | 4 1 file changed, 4 deletions(-) delete mode 100644 scripts/kconfig/lxdialog/.gitignore diff --git a/scripts/kconfig/lxdialog/.gitignore b/scripts/kconfig/lxdialog/.gitignore deleted file mode 100644 index 90b08ff..000 --- a/scripts/kconfig/lxdialog/.gitignore +++ /dev/null @@ -1,4 +0,0 @@ -# -# Generated files -# -lxdialog -- 2.7.4
Re: [PATCH] nvmem: core: Set no-read-write provider to avoid userspace read/write
Hi Gaurav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0 next-20190306]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gaurav-Kohli/nvmem-core-Set-no-read-write-provider-to-avoid-userspace-read-write/20190317-105219
config: i386-randconfig-s0-201910 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers//nvmem/core.c: In function 'nvmem_register':
>> drivers//nvmem/core.c:662:47: error: 'np' undeclared (first use in this
>> function)
nvmem->no_read_write = of_property_read_bool(np, "no-read-write") |
^~
drivers//nvmem/core.c:662:47: note: each undeclared identifier is reported
only once for each function it appears in
vim +/np +662 drivers//nvmem/core.c
602
603 /**
604 * nvmem_register() - Register a nvmem device for given nvmem_config.
605 * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
606 *
607 * @config: nvmem device configuration with which nvmem device is
created.
608 *
609 * Return: Will be an ERR_PTR() on error or a valid pointer to
nvmem_device
610 * on success.
611 */
612
613 struct nvmem_device *nvmem_register(const struct nvmem_config *config)
614 {
615 struct nvmem_device *nvmem;
616 int rval;
617
618 if (!config->dev)
619 return ERR_PTR(-EINVAL);
620
621 nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
622 if (!nvmem)
623 return ERR_PTR(-ENOMEM);
624
625 rval = ida_simple_get(&nvmem_ida, 0, 0, GFP_KERNEL);
626 if (rval < 0) {
627 kfree(nvmem);
628 return ERR_PTR(rval);
629 }
630
631 kref_init(&nvmem->refcnt);
632 INIT_LIST_HEAD(&nvmem->cells);
633
634 nvmem->id = rval;
635 nvmem->owner = config->owner;
636 if (!nvmem->owner && config->dev->driver)
637 nvmem->owner = config->dev->driver->owner;
638 nvmem->stride = config->stride ?: 1;
639 nvmem->word_size = config->word_size ?: 1;
640 nvmem->size = config->size;
641 nvmem->dev.type = &nvmem_provider_type;
642 nvmem->dev.bus = &nvmem_bus_type;
643 nvmem->dev.parent = config->dev;
644 nvmem->priv = config->priv;
645 nvmem->type = config->type;
646 nvmem->reg_read = config->reg_read;
647 nvmem->reg_write = config->reg_write;
648 if (!config->no_of_node)
649 nvmem->dev.of_node = config->dev->of_node;
650
651 if (config->id == -1 && config->name) {
652 dev_set_name(&nvmem->dev, "%s", config->name);
653 } else {
654 dev_set_name(&nvmem->dev, "%s%d",
655 config->name ? : "nvmem",
656 config->name ? config->id : nvmem->id);
657 }
658
659 nvmem->read_only = device_property_present(config->dev,
"read-only") ||
660 config->read_only || !nvmem->reg_write;
661
> 662 nvmem->no_read_write = of_property_read_bool(np,
> "no-read-write") |
663 config->read_only;
664 if (config->root_only)
665 nvmem->dev.groups = nvmem->read_only ?
666 nvmem_ro_root_dev_groups :
667 nvmem_rw_root_dev_groups;
668 else
669 nvmem->dev.groups = nvmem->read_only ?
670 nvmem_ro_dev_groups :
671 nvmem_rw_dev_groups;
672
673 device_initialize(&nvmem->dev);
674
675 dev_dbg(&nvmem->dev, "Registering nvmem device %s\n",
config->name);
676
677 rval = device_add(&nvmem->dev);
678 if (rval)
679 goto err_put_device;
680
681 if (config->compat) {
682 rval = nvmem_setup_compat(nvmem, config);
683 if (rval)
684 goto err_device_del;
685 }
686
687 if (config->cells) {
688 rval = nvmem_add_cells(nvmem, config->cells,
config->ncells);
689 if (rval)
690 goto err_teardown_compat;
691 }
692
693 rval = nvmem_add_cells_from_table(nvmem);
694 if (rval)
695 goto err_remove
Re: [PATCH] nvmem: core: Set no-read-write provider to avoid userspace read/write
Hi Gaurav,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0 next-20190306]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gaurav-Kohli/nvmem-core-Set-no-read-write-provider-to-avoid-userspace-read-write/20190317-105219
config: i386-randconfig-x010-201911 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers//nvmem/core.c: In function 'nvmem_register':
>> drivers//nvmem/core.c:662:47: error: 'np' undeclared (first use in this
>> function); did you mean 'up'?
nvmem->no_read_write = of_property_read_bool(np, "no-read-write") |
^~
up
drivers//nvmem/core.c:662:47: note: each undeclared identifier is reported
only once for each function it appears in
vim +662 drivers//nvmem/core.c
602
603 /**
604 * nvmem_register() - Register a nvmem device for given nvmem_config.
605 * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
606 *
607 * @config: nvmem device configuration with which nvmem device is
created.
608 *
609 * Return: Will be an ERR_PTR() on error or a valid pointer to
nvmem_device
610 * on success.
611 */
612
613 struct nvmem_device *nvmem_register(const struct nvmem_config *config)
614 {
615 struct nvmem_device *nvmem;
616 int rval;
617
618 if (!config->dev)
619 return ERR_PTR(-EINVAL);
620
621 nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
622 if (!nvmem)
623 return ERR_PTR(-ENOMEM);
624
625 rval = ida_simple_get(&nvmem_ida, 0, 0, GFP_KERNEL);
626 if (rval < 0) {
627 kfree(nvmem);
628 return ERR_PTR(rval);
629 }
630
631 kref_init(&nvmem->refcnt);
632 INIT_LIST_HEAD(&nvmem->cells);
633
634 nvmem->id = rval;
635 nvmem->owner = config->owner;
636 if (!nvmem->owner && config->dev->driver)
637 nvmem->owner = config->dev->driver->owner;
638 nvmem->stride = config->stride ?: 1;
639 nvmem->word_size = config->word_size ?: 1;
640 nvmem->size = config->size;
641 nvmem->dev.type = &nvmem_provider_type;
642 nvmem->dev.bus = &nvmem_bus_type;
643 nvmem->dev.parent = config->dev;
644 nvmem->priv = config->priv;
645 nvmem->type = config->type;
646 nvmem->reg_read = config->reg_read;
647 nvmem->reg_write = config->reg_write;
648 if (!config->no_of_node)
649 nvmem->dev.of_node = config->dev->of_node;
650
651 if (config->id == -1 && config->name) {
652 dev_set_name(&nvmem->dev, "%s", config->name);
653 } else {
654 dev_set_name(&nvmem->dev, "%s%d",
655 config->name ? : "nvmem",
656 config->name ? config->id : nvmem->id);
657 }
658
659 nvmem->read_only = device_property_present(config->dev,
"read-only") ||
660 config->read_only || !nvmem->reg_write;
661
> 662 nvmem->no_read_write = of_property_read_bool(np,
> "no-read-write") |
663 config->read_only;
664 if (config->root_only)
665 nvmem->dev.groups = nvmem->read_only ?
666 nvmem_ro_root_dev_groups :
667 nvmem_rw_root_dev_groups;
668 else
669 nvmem->dev.groups = nvmem->read_only ?
670 nvmem_ro_dev_groups :
671 nvmem_rw_dev_groups;
672
673 device_initialize(&nvmem->dev);
674
675 dev_dbg(&nvmem->dev, "Registering nvmem device %s\n",
config->name);
676
677 rval = device_add(&nvmem->dev);
678 if (rval)
679 goto err_put_device;
680
681 if (config->compat) {
682 rval = nvmem_setup_compat(nvmem, config);
683 if (rval)
684 goto err_device_del;
685 }
686
687 if (config->cells) {
688 rval = nvmem_add_cells(nvmem, config->cells,
config->ncells);
689 if (rval)
690 goto err_teardown_compat;
691 }
692
693 rval = nvmem_add_cells_from_table(nvmem);
6
[PATCH v2] kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice.
syzbot is hitting use-after-free bug in uinput module [1]. This is because
kobject_uevent(KOBJ_REMOVE) is called again due to commit 0f4dafc0563c6c49
("Kobject: auto-cleanup on final unref") after memory allocation fault
injection made kobject_uevent(KOBJ_REMOVE) from device_del() from
input_unregister_device() fail, while uinput_destroy_device() is expecting
that kobject_uevent(KOBJ_REMOVE) is not called after device_del() from
input_unregister_device() completed.
That commit intended to catch cases where nobody even attempted to send
"remove" uevents. But there is no guarantee that an event will ultimately
be sent. We are at the point of no return as far as the rest of the kernel
is concerned; there are no repeats or do-overs.
Also, it is not clear whether some subsystem depends on that commit.
If no subsystem depends on that commit, it will be better to remove
the state_{add,remove}_uevent_sent logic. But we don't want to risk
a regression (in a patch which will be backported) by trying to remove
that logic. Therefore, as a first step, let's avoid the use-after-free bug
by making sure that kobject_uevent(KOBJ_REMOVE) won't be triggered twice.
[1]
https://syzkaller.appspot.com/bug?id=8b17c134fe938bbddd75a45afaa9e68af43a362d
Reported-by: syzbot
Analyzed-by: Dmitry Torokhov
Fixes: 0f4dafc0563c6c49 ("Kobject: auto-cleanup on final unref")
Cc: Kay Sievers
Signed-off-by: Tetsuo Handa
---
lib/kobject_uevent.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index f058026..7998aff 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -466,6 +466,13 @@ int kobject_uevent_env(struct kobject *kobj, enum
kobject_action action,
int i = 0;
int retval = 0;
+ /*
+* Mark "remove" event done regardless of result, for some subsystems
+* do not want to re-trigger "remove" event via automatic cleanup.
+*/
+ if (action == KOBJ_REMOVE)
+ kobj->state_remove_uevent_sent = 1;
+
pr_debug("kobject: '%s' (%p): %s\n",
kobject_name(kobj), kobj, __func__);
@@ -567,10 +574,6 @@ int kobject_uevent_env(struct kobject *kobj, enum
kobject_action action,
kobj->state_add_uevent_sent = 1;
break;
- case KOBJ_REMOVE:
- kobj->state_remove_uevent_sent = 1;
- break;
-
case KOBJ_UNBIND:
zap_modalias_env(env);
break;
--
1.8.3.1
[PATCH] staging: speakup: fix line over 80 characters.
Fix coding style issues, which solves checkpatch.pl warning:
"WARNING: line over 80 characters".
---
drivers/staging/speakup/kobjects.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/speakup/kobjects.c
b/drivers/staging/speakup/kobjects.c
index 2eb5af3debb3..abeab64899db 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -154,7 +154,7 @@ static ssize_t chars_chartab_store(struct kobject *kobj,
continue;
}
- /* Do not replace with kstrtoul: here we need temp to be
updated */
+/* Do not replace with kstrtoul: here we need temp to be updated */
index = simple_strtoul(cp, &temp, 10);
if (index > 255) {
rejected++;
@@ -788,7 +788,7 @@ static ssize_t message_store_helper(const char *buf, size_t
count,
continue;
}
- /* Do not replace with kstrtoul: here we need temp to be
updated */
+/* Do not replace with kstrtoul: here we need temp to be updated */
index = simple_strtoul(cp, &temp, 10);
while ((temp < linefeed) && (*temp == ' ' || *temp == '\t'))
--
2.20.1
Re: [PATCH v2 2/3] scripts/package/mkdebian: avoid implicit effects
On Sun, Mar 10, 2019 at 12:44 AM Arseny Maslennikov wrote: > > * The man page for dpkg-source(1) notes: > > > -b, --build directory [format-specific-parameters] > > Build a source package (--build since dpkg 1.17.14). > > <...> > > > > dpkg-source will build the source package with the first > > format found in this ordered list: the format indicated > > with the --format command line option, the format > > indicated in debian/source/format, “1.0”. The fallback > > to “1.0” is deprecated and will be removed at some point > > in the future, you should always document the desired > > source format in debian/source/format. See section > > SOURCE PACKAGE FORMATS for an extensive description of > > the various source package formats. > > Thus it would be more foolproof to explicitly use 1.0 (as we always > did) than to rely on dpkg-source's defaults. > > * In a similar vein, debian/rules is not made executable by mkdebian, > and dpkg-source warns about that but still silently fixes the file. > Let's be explicit once again. > > Signed-off-by: Arseny Maslennikov > --- Applied to linux-kbuild. Thanks. > scripts/package/mkdebian | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian > index f030961c5165..d276eb671a27 100755 > --- a/scripts/package/mkdebian > +++ b/scripts/package/mkdebian > @@ -132,7 +132,9 @@ else > echo >&2 "Install lsb-release or set \$KDEB_CHANGELOG_DIST > explicitly" > fi > > -mkdir -p debian/ > +mkdir -p debian/source/ > +echo "1.0" > debian/source/format > + > echo $debarch > debian/arch > > # Generate a simple changelog template > @@ -221,5 +223,6 @@ clean: > > binary: binary-arch > EOF > +chmod +x debian/rules > > exit 0 > -- > 2.20.1 > -- Best Regards Masahiro Yamada
Re: [PATCH] Revert "modsign: Abort modules_install when signing fails"
On Sat, Mar 16, 2019 at 1:25 AM Douglas Anderson wrote:
>
> This reverts commit caf6fe91ddf62a96401e21e9b7a07227440f4185.
>
> The commit was fine but is no longer needed as of commit 3a2429e1faf4
> ("kbuild: change if_changed_rule for multi-line recipe"). Let's go
> back to using ";" to be consistent.
>
> For some discussion, see:
>
> https://lkml.kernel.org/r/CAK7LNASde0Q9S5GKeQiWhArfER4S4wL1=R_FW8q0++_X3T5=h...@mail.gmail.com
>
> Signed-off-by: Douglas Anderson
> ---
Applied to linux-kbuild. Thanks.
> scripts/Makefile.modinst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
> index ff5ca9817a85..0dae402661f3 100644
> --- a/scripts/Makefile.modinst
> +++ b/scripts/Makefile.modinst
> @@ -23,7 +23,7 @@ quiet_cmd_modules_install = INSTALL $@
> mkdir -p $(2) ; \
> cp $@ $(2) ; \
> $(mod_strip_cmd) $(2)/$(notdir $@) ; \
> -$(mod_sign_cmd) $(2)/$(notdir $@) $(patsubst %,|| true,$(KBUILD_EXTMOD))
> && \
> +$(mod_sign_cmd) $(2)/$(notdir $@) $(patsubst %,|| true,$(KBUILD_EXTMOD))
> ; \
> $(mod_compress_cmd) $(2)/$(notdir $@)
>
> # Modules built outside the kernel source tree go into extra by default
> --
> 2.21.0.360.g471c308f928-goog
>
--
Best Regards
Masahiro Yamada
[PATCH 1/2] staging: vc04_services: Add spaces around Operators
Fix Check from the checkpatch.pl Script
`CHECK: spaces preferred around that`
in vchi.h
Signed-off-by: Emanuel Bennici
---
drivers/staging/vc04_services/interface/vchi/vchi.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 0b6fc0d31f4c..7b13cb04c119 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -41,14 +41,14 @@
Global defs
*/
-#define VCHI_BULK_ROUND_UP(x) unsigned long)(x))+VCHI_BULK_ALIGN-1) &
~(VCHI_BULK_ALIGN-1))
-#define VCHI_BULK_ROUND_DOWN(x) (((unsigned long)(x)) & ~(VCHI_BULK_ALIGN-1))
-#define VCHI_BULK_ALIGN_NBYTES(x) (VCHI_BULK_ALIGNED(x) ? 0 : (VCHI_BULK_ALIGN
- ((unsigned long)(x) & (VCHI_BULK_ALIGN-1
+#define VCHI_BULK_ROUND_UP(x) unsigned long)(x)) + VCHI_BULK_ALIGN -
1) & ~(VCHI_BULK_ALIGN - 1))
+#define VCHI_BULK_ROUND_DOWN(x) (((unsigned long)(x)) & ~(VCHI_BULK_ALIGN -
1))
+#define VCHI_BULK_ALIGN_NBYTES(x) (VCHI_BULK_ALIGNED(x) ? 0 : (VCHI_BULK_ALIGN
- ((unsigned long)(x) & (VCHI_BULK_ALIGN - 1
#ifdef USE_VCHIQ_ARM
#define VCHI_BULK_ALIGNED(x) 1
#else
-#define VCHI_BULK_ALIGNED(x) (((unsigned long)(x) & (VCHI_BULK_ALIGN-1))
== 0)
+#define VCHI_BULK_ALIGNED(x) (((unsigned long)(x) & (VCHI_BULK_ALIGN -
1)) == 0)
#endif
struct vchi_version {
@@ -134,8 +134,8 @@ extern int32_t vchi_service_release(const
VCHI_SERVICE_HANDLE_T handle);
// Routine to set a control option for a named service
extern int32_t vchi_service_set_option(const VCHI_SERVICE_HANDLE_T handle,
- VCHI_SERVICE_OPTION_T option,
- int value);
+ VCHI_SERVICE_OPTION_T option,
+ int value);
/* Routine to send a message from kernel memory across a service */
extern int
--
2.19.1
[PATCH 2/2] staging: vc04_services: Add blank line after struct declaration
Signed-off-by: Emanuel Bennici
---
drivers/staging/vc04_services/interface/vchi/vchi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 7b13cb04c119..43eaf7703777 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -55,6 +55,7 @@ struct vchi_version {
uint32_t version;
uint32_t version_min;
};
+
#define VCHI_VERSION(v_) { v_, v_ }
#define VCHI_VERSION_EX(v_, m_) { v_, m_ }
--
2.19.1
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Sat, Mar 16, 2019 at 12:37:18PM -0700, Suren Baghdasaryan wrote:
> On Sat, Mar 16, 2019 at 11:57 AM Christian Brauner
> wrote:
> >
> > On Sat, Mar 16, 2019 at 11:00:10AM -0700, Daniel Colascione wrote:
> > > On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan
> > > wrote:
> > > >
> > > > On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes
> > > > wrote:
> > > > >
> > > > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote:
> > > > > [..]
> > > > > > > why do we want to add a new syscall (pidfd_wait) though? Why not
> > > > > > > just use
> > > > > > > standard poll/epoll interface on the proc fd like Daniel was
> > > > > > > suggesting.
> > > > > > > AFAIK, once the proc file is opened, the struct pid is
> > > > > > > essentially pinned
> > > > > > > even though the proc number may be reused. Then the caller can
> > > > > > > just poll.
> > > > > > > We can add a waitqueue to struct pid, and wake up any waiters on
> > > > > > > process
> > > > > > > death (A quick look shows task_struct can be mapped to its struct
> > > > > > > pid) and
> > > > > > > also possibly optimize it using Steve's TIF flag idea. No new
> > > > > > > syscall is
> > > > > > > needed then, let me know if I missed something?
> > > > > >
> > > > > > Huh, I thought that Daniel was against the poll/epoll solution?
> > > > >
> > > > > Hmm, going through earlier threads, I believe so now. Here was
> > > > > Daniel's
> > > > > reasoning about avoiding a notification about process death through
> > > > > proc
> > > > > directory fd:
> > > > > http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html
> > > > >
> > > > > May be a dedicated syscall for this would be cleaner after all.
> > > >
> > > > Ah, I wish I've seen that discussion before...
> > > > syscall makes sense and it can be non-blocking and we can use
> > > > select/poll/epoll if we use eventfd.
> > >
> > > Thanks for taking a look.
> > >
> > > > I would strongly advocate for
> > > > non-blocking version or at least to have a non-blocking option.
> > >
> > > Waiting for FD readiness is *already* blocking or non-blocking
> > > according to the caller's desire --- users can pass options they want
> > > to poll(2) or whatever. There's no need for any kind of special
> > > configuration knob or non-blocking option. We already *have* a
> > > non-blocking option that works universally for everything.
> > >
> > > As I mentioned in the linked thread, waiting for process exit should
> > > work just like waiting for bytes to appear on a pipe. Process exit
> > > status is just another blob of bytes that a process might receive. A
> > > process exit handle ought to be just another information source. The
> > > reason the unix process API is so awful is that for whatever reason
> > > the original designers treated processes as some kind of special kind
> > > of resource instead of fitting them into the otherwise general-purpose
> > > unix data-handling API. Let's not repeat that mistake.
> > >
> > > > Something like this:
> > > >
> > > > evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> > > > // register eventfd to receive death notification
> > > > pidfd_wait(pid_to_kill, evfd);
> > > > // kill the process
> > > > pidfd_send_signal(pid_to_kill, ...)
> > > > // tend to other things
> > >
> > > Now you've lost me. pidfd_wait should return a *new* FD, not wire up
> > > an eventfd.
> > >
>
> Ok, I probably misunderstood your post linked by Joel. I though your
> original proposal was based on being able to poll a file under
> /proc/pid and then you changed your mind to have a separate syscall
> which I assumed would be a blocking one to wait for process exit.
> Maybe you can describe the new interface you are thinking about in
> terms of userspace usage like I did above? Several lines of code would
> explain more than paragraphs of text.
Hey, Thanks Suren for the eventfd idea. I agree with Daniel on this. The idea
from Daniel here is to wait for process death and exit events by just
referring to a stable fd, independent of whatever is going on in /proc.
What is needed is something like this (in highly pseudo-code form):
pidfd = opendir("/proc/",..);
wait_fd = pidfd_wait(pidfd);
read or poll wait_fd (non-blocking or blocking whichever)
wait_fd will block until the task has either died or reaped. In both these
cases, it can return a suitable string such as "dead" or "reaped" although an
integer with some predefined meaning is also Ok.
What that guarantees is, even if the task's PID has been reused, or the task
has already died or already died + reaped, all of these events cannot race
with the code above and the information passed to the user is race-free and
stable / guaranteed.
An eventfd seems to not fit well, because AFAICS passing the raw PID to
eventfd as in your example would still race since the PID could have been
reused by another process by the time the eventfd is created.
Also Andy's idea in [1] seems to use poll flags to communicate various tihngs
Re: [PATCH v3 3/3] Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex
On Thu, Mar 14, 2019 at 03:45:33PM -0700, Stephen Hemminger wrote: > On Thu, 14 Mar 2019 13:05:15 -0700 > "Kimberly Brown" wrote: > > > Fix a race condition that can result in a ring buffer pointer being set > > to null while a "_show" function is reading the ring buffer's data. This > > problem was discussed here: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org > > %2Flkml%2F2018%2F10%2F18%2F779&data=02%7C01%7Csthemmin%40microsoft.com > > %7C1d7557d667b741bdbb6008d6a8b8620f%7C72f988bf86f141af91ab2d7cd011db47%7C1 > > %7C0%7C636881907217609564&sdata=1bUbLaxsODANM7lCBR8lxyYajNpufuwUW%2FOl > > vtGu2hU%3D&reserved=0 > > > > To fix the race condition, add a new mutex lock to the > > "hv_ring_buffer_info" struct. Add a new function, > > "hv_ringbuffer_pre_init()", where a channel's inbound and outbound > > ring_buffer_info mutex locks are initialized. > > > > ... snip ... > > Adding more locks will solve the problem but it seems like overkill. > Why not either use a reference count or an RCU style access for the > ring buffer? I agree that a reference count or RCU could also solve this problem. Using mutex locks seemed like the most straightforward solution, but I'll certainly switch to a different approach if it's better! Are you concerned about the extra memory required for the mutex locks, read performance, or something else? Thanks, Kim
linux-next: Fixes tag needs some work in the sound-asoc tree
Hi all,
In commit
399706df420e ("ASoC: rsnd: src: fix compiler warnings")
Fixes tag
Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR
handling")
has these problem(s):
- 'linux-next commit' was unexpected.
In commit
ba164a49f8f7 ("ASoC: rsnd: src: Avoid a potential deadlock")
Fixes tag
Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR
handling")
has these problem(s):
- 'linux-next commit' was unexpected.
Just use:
got log --format='Fixes: %h ("%s")'
to generate the Fixes tags.
--
Cheers,
Stephen Rothwell
pgpeSfVohzy2L.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the sound-asoc tree
Hi all,
In commit
2b13bee38849 ("ASoC: samsung: odroid: Fix clock configuration for 44100
sample rate")
Fixes tag
Fixes: fbeec965b8d1c ("ASoC: samsung: odroid: Fix 32000 sample rate handling")
has these problem(s):
- Target SHA1 does not exist
Did you mean:
1d22c337dc8f ("ASoC: samsung: odroid: Fix 32000 sample rate handling"
--
Cheers,
Stephen Rothwell
pgp1qqRHBQlte.pgp
Description: OpenPGP digital signature
Re: mount.nfs: Protocol error after upgrade to linux/master
On 3/16/2019 1:08 AM, Tetsuo Handa wrote: On 2019/03/16 14:38, Kees Cook wrote: config LSM string "Ordered list of enabled LSMs" + default "yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor" if DEFAULT_SECURITY_SMACK + default "yama,loadpin,safesetid,integrity,tomoyo,selinux,smack,apparmor" if DEFAULT_SECURITY_TOMOYO + default "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" if DEFAULT_SECURITY_APPARMOR default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor" help A comma-separated list of LSMs, in initialization order. (I don't see a way to include an earlier config string in a new default.) Thoughts? Hmm, DEFAULT_SECURITY_TOMOYO no longer works because TOMOYO will be always enabled as long as CONFIG_SECURITY_TOMOYO=y. Maybe config LSM string "Ordered list of enabled LSMs" - default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor" + default "yama,loadpin,safesetid,integrity,selinux" if DEFAULT_SECURITY_SELINUX + default "yama,loadpin,safesetid,integrity,smack" if DEFAULT_SECURITY_SMACK + default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO + default "yama,loadpin,safesetid,integrity,apparmor" if DEFAULT_SECURITY_APPARMOR + default "yama,loadpin,safesetid,integrity" if DEFAULT_SECURITY_DAC help A comma-separated list of LSMs, in initialization order. (i.e. include only up to one major LSM as default choice, and allow manually including multiple major LSMs at both kernel build time and kernel boot time) is better? I think this looks pretty good.
[PATCH] virtio-fs: fix multiple tag support
While doing memremap from pci_dev's system bus address to kernel virtual
address, we assign a wrong value to the %end of pgmap.res, which ends up
with a wrong resource size in the process of memremap, and that further
prevent the second virtiofs pci device from being probed successfully.
Signed-off-by: Liu Bo
---
fs/fuse/virtio_fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 88b00055589b..7abf2187d85f 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -713,7 +713,7 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev,
struct virtio_fs *fs)
pgmap->res = (struct resource){
.name = "virtio-fs dax window",
.start = phys_addr,
- .end = phys_addr + cache_len,
+ .end = phys_addr + cache_len - 1,
};
fs->window_kaddr = devm_memremap_pages(&pci_dev->dev, pgmap);
--
2.20.1.2.gb21ebb6
Re: [PATCH 18/52] virtio-fs: Map cache using the values from the capabilities
On Mon, Dec 10, 2018 at 9:57 AM Vivek Goyal wrote:
>
> Instead of assuming we had the fixed bar for the cache, use the
> value from the capabilities.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> fs/fuse/virtio_fs.c | 32 +---
> 1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
> index 60d496c16841..55bac1465536 100644
> --- a/fs/fuse/virtio_fs.c
> +++ b/fs/fuse/virtio_fs.c
> @@ -14,11 +14,6 @@
> #include
> #include "fuse_i.h"
>
> -enum {
> - /* PCI BAR number of the virtio-fs DAX window */
> - VIRTIO_FS_WINDOW_BAR = 2,
> -};
> -
> /* List of virtio-fs device instances and a lock for the list */
> static DEFINE_MUTEX(virtio_fs_mutex);
> static LIST_HEAD(virtio_fs_instances);
> @@ -518,7 +513,7 @@ static int virtio_fs_setup_dax(struct virtio_device
> *vdev, struct virtio_fs *fs)
> struct dev_pagemap *pgmap;
> struct pci_dev *pci_dev;
> phys_addr_t phys_addr;
> - size_t len;
> + size_t bar_len;
> int ret;
> u8 have_cache, cache_bar;
> u64 cache_offset, cache_len;
> @@ -551,17 +546,13 @@ static int virtio_fs_setup_dax(struct virtio_device
> *vdev, struct virtio_fs *fs)
> }
>
> /* TODO handle case where device doesn't expose BAR? */
> - ret = pci_request_region(pci_dev, VIRTIO_FS_WINDOW_BAR,
> -"virtio-fs-window");
> + ret = pci_request_region(pci_dev, cache_bar, "virtio-fs-window");
> if (ret < 0) {
> dev_err(&vdev->dev, "%s: failed to request window BAR\n",
> __func__);
> return ret;
> }
>
> - phys_addr = pci_resource_start(pci_dev, VIRTIO_FS_WINDOW_BAR);
> - len = pci_resource_len(pci_dev, VIRTIO_FS_WINDOW_BAR);
> -
> mi = devm_kzalloc(&pci_dev->dev, sizeof(*mi), GFP_KERNEL);
> if (!mi)
> return -ENOMEM;
> @@ -586,6 +577,17 @@ static int virtio_fs_setup_dax(struct virtio_device
> *vdev, struct virtio_fs *fs)
> pgmap->ref = &mi->ref;
> pgmap->type = MEMORY_DEVICE_FS_DAX;
>
> + phys_addr = pci_resource_start(pci_dev, cache_bar);
> + bar_len = pci_resource_len(pci_dev, cache_bar);
> +
> + if (cache_offset + cache_len > bar_len) {
> + dev_err(&vdev->dev,
> + "%s: cache bar shorter than cap offset+len\n",
> + __func__);
> + return -EINVAL;
> + }
> + phys_addr += cache_offset;
> +
> /* Ideally we would directly use the PCI BAR resource but
> * devm_memremap_pages() wants its own copy in pgmap. So
> * initialize a struct resource from scratch (only the start
> @@ -594,7 +596,7 @@ static int virtio_fs_setup_dax(struct virtio_device
> *vdev, struct virtio_fs *fs)
> pgmap->res = (struct resource){
> .name = "virtio-fs dax window",
> .start = phys_addr,
> - .end = phys_addr + len,
> + .end = phys_addr + cache_len,
Just in case you haven't noticed/fixed this problem, it should be
+ .end = phys_addr + cache_len - 1,
because resource_size() counts %size as "end - start + 1".
The end result of the above is a "conflicting page map" warning when
specifying a second virtio-fs pci device.
I'll send a patch for this, and feel free to take it along with the
patchset if needed.
thanks,
liubo
> };
>
> fs->window_kaddr = devm_memremap_pages(&pci_dev->dev, pgmap);
> @@ -607,10 +609,10 @@ static int virtio_fs_setup_dax(struct virtio_device
> *vdev, struct virtio_fs *fs)
> return ret;
>
> fs->window_phys_addr = phys_addr;
> - fs->window_len = len;
> + fs->window_len = cache_len;
>
> - dev_dbg(&vdev->dev, "%s: window kaddr 0x%px phys_addr 0x%llx len
> %zu\n",
> - __func__, fs->window_kaddr, phys_addr, len);
> + dev_dbg(&vdev->dev, "%s: cache kaddr 0x%px phys_addr 0x%llx len
> %llx\n",
> + __func__, fs->window_kaddr, phys_addr, cache_len);
>
> fs->dax_dev = alloc_dax(fs, NULL, &virtio_fs_dax_ops);
> if (!fs->dax_dev)
> --
> 2.13.6
>
[PATCH] staging: mt7621-pci-phy: Add Spaces to Macro Definition
Improve Code readability by adding Spaces after #define Signed-off-by: Emanuel Bennici --- .../staging/mt7621-pci-phy/pci-mt7621-phy.c | 126 +- 1 file changed, 63 insertions(+), 63 deletions(-) diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c index d3ca2f019112..98c06308143c 100644 --- a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c +++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c @@ -14,69 +14,69 @@ #include #include -#define RALINK_CLKCFG1 0x30 -#define CHIP_REV_MT7621_E2 0x0101 - -#define PCIE_PORT_CLK_EN(x)BIT(24 + (x)) - -#define RG_PE1_PIPE_REG0x02c -#define RG_PE1_PIPE_RSTBIT(12) -#define RG_PE1_PIPE_CMD_FRCBIT(4) - -#define RG_P0_TO_P1_WIDTH 0x100 -#define RG_PE1_H_LCDDS_REG 0x49c -#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0) -#define RG_PE1_H_LCDDS_PCW_VAL(x) ((0x7fff & (x)) << 0) - -#define RG_PE1_FRC_H_XTAL_REG 0x400 -#define RG_PE1_FRC_H_XTAL_TYPE BIT(8) -#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9) -#define RG_PE1_H_XTAL_TYPE_VAL(x) ((0x3 & (x)) << 9) - -#define RG_PE1_FRC_PHY_REG 0x000 -#define RG_PE1_FRC_PHY_EN BIT(4) -#define RG_PE1_PHY_EN BIT(5) - -#define RG_PE1_H_PLL_REG 0x490 -#define RG_PE1_H_PLL_BCGENMASK(23, 22) -#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22) -#define RG_PE1_H_PLL_BPGENMASK(21, 18) -#define RG_PE1_H_PLL_BP_VAL(x) ((0xf & (x)) << 18) -#define RG_PE1_H_PLL_IRGENMASK(15, 12) -#define RG_PE1_H_PLL_IR_VAL(x) ((0xf & (x)) << 12) -#define RG_PE1_H_PLL_ICGENMASK(11, 8) -#define RG_PE1_H_PLL_IC_VAL(x) ((0xf & (x)) << 8) -#define RG_PE1_H_PLL_PREDIV GENMASK(7, 6) -#define RG_PE1_H_PLL_PREDIV_VAL(x) ((0x3 & (x)) << 6) -#define RG_PE1_PLL_DIVEN GENMASK(3, 1) -#define RG_PE1_PLL_DIVEN_VAL(x)((0x7 & (x)) << 1) - -#define RG_PE1_H_PLL_FBKSEL_REG0x4bc -#define RG_PE1_H_PLL_FBKSEL GENMASK(5, 4) -#define RG_PE1_H_PLL_FBKSEL_VAL(x) ((0x3 & (x)) << 4) - -#defineRG_PE1_H_LCDDS_SSC_PRD_REG 0x4a4 -#define RG_PE1_H_LCDDS_SSC_PRD GENMASK(15, 0) -#define RG_PE1_H_LCDDS_SSC_PRD_VAL(x) ((0x & (x)) << 0) - -#define RG_PE1_H_LCDDS_SSC_DELTA_REG 0x4a8 -#define RG_PE1_H_LCDDS_SSC_DELTAGENMASK(11, 0) -#define RG_PE1_H_LCDDS_SSC_DELTA_VAL(x) ((0xfff & (x)) << 0) -#define RG_PE1_H_LCDDS_SSC_DELTA1 GENMASK(27, 16) -#define RG_PE1_H_LCDDS_SSC_DELTA1_VAL(x) ((0xff & (x)) << 16) - -#define RG_PE1_LCDDS_CLK_PH_INV_REG0x4a0 -#define RG_PE1_LCDDS_CLK_PH_INVBIT(5) - -#define RG_PE1_H_PLL_BR_REG0x4ac -#define RG_PE1_H_PLL_BRGENMASK(18, 16) -#define RG_PE1_H_PLL_BR_VAL(x) ((0x7 & (x)) << 16) - -#defineRG_PE1_MSTCKDIV_REG 0x414 -#define RG_PE1_MSTCKDIVGENMASK(7, 6) -#define RG_PE1_MSTCKDIV_VAL(x) ((0x3 & (x)) << 6) - -#define RG_PE1_FRC_MSTCKDIVBIT(5) +#define RALINK_CLKCFG1 0x30 +#define CHIP_REV_MT7621_E2 0x0101 + +#define PCIE_PORT_CLK_EN(x)BIT(24 + (x)) + +#define RG_PE1_PIPE_REG0x02c +#define RG_PE1_PIPE_RSTBIT(12) +#define RG_PE1_PIPE_CMD_FRCBIT(4) + +#define RG_P0_TO_P1_WIDTH 0x100 +#define RG_PE1_H_LCDDS_REG 0x49c +#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0) +#define RG_PE1_H_LCDDS_PCW_VAL(x) ((0x7fff & (x)) << 0) + +#define RG_PE1_FRC_H_XTAL_REG 0x400 +#define RG_PE1_FRC_H_XTAL_TYPE BIT(8) +#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9) +#define RG_PE1_H_XTAL_TYPE_VAL(x) ((0x3 & (x)) << 9) + +#define RG_PE1_FRC_PHY_REG 0x000 +#define RG_PE1_FRC_PHY_EN BIT(4) +#define RG_PE1_PHY_EN BIT(5) + +#define RG_PE1_H_PLL_REG 0x490 +#define RG_PE1_H_PLL_BCGENMASK(23, 22) +#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22) +#define RG_PE1_H_PLL_BPGENMASK(21, 18) +#define RG_PE1_H_PLL_BP_VAL(x) ((0xf & (x)) << 18) +#define RG_PE1_H_PLL_IRGENMASK(15, 12) +#define RG_PE1_H_PLL_IR_VAL(x) ((0xf & (x)) << 12) +#define RG_PE1_H_PLL_ICGENMASK(11, 8) +#define RG_PE1_H_PLL_IC_VAL(x) ((0xf & (x)) << 8) +#define RG_PE1_H_PLL_PREDIVGENMASK(7, 6) +#de
[PATCH] IB/iser: remove uninitialized variable len
From: Colin Ian King
The variable len is not being inintialized and the uninitialized
value is being returned. However, this return path is never reached
because the default case in the switch statement returns -ENOSYS.
Clean up the code by replacing the return -ENOSYS with a break
for the default case and returning -ENOSYS at the end of the
function. This allows len to be removed. Also remove redundant
break that follows a return statement.
Signed-off-by: Colin Ian King
---
drivers/infiniband/ulp/iser/iscsi_iser.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 8c707accd148..9c185a8dabd3 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -763,7 +763,6 @@ static int iscsi_iser_get_ep_param(struct iscsi_endpoint
*ep,
enum iscsi_param param, char *buf)
{
struct iser_conn *iser_conn = ep->dd_data;
- int len;
switch (param) {
case ISCSI_PARAM_CONN_PORT:
@@ -774,12 +773,10 @@ static int iscsi_iser_get_ep_param(struct iscsi_endpoint
*ep,
return iscsi_conn_get_addr_param((struct sockaddr_storage *)
&iser_conn->ib_conn.cma_id->route.addr.dst_addr,
param, buf);
- break;
default:
- return -ENOSYS;
+ break;
}
-
- return len;
+ return -ENOSYS;
}
/**
--
2.20.1
[PATCH] staging: rtl8723bs: remove unused code
From: Colin Ian King
There are two final hunks of code that are only built
if SDIO_DYNAMIC_ALLOC_MEM is defined however this is never
defined and if it was the code would lead to dereferencing
an uninitialized pointer oldmem. It appears that a previous
commit 1babeb0c3e59 ("Staging: rtl8723bs: Remove dead code")
removed some of the dead code but not all of it. Clean this
up by removing the final hunks.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8723bs/hal/sdio_ops.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c
b/drivers/staging/rtl8723bs/hal/sdio_ops.c
index 3fee34484577..92191e9789bb 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_ops.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c
@@ -428,9 +428,6 @@ static u32 sdio_read_port(
PSDIO_DATA psdio;
struct hal_com_data *hal;
u32 oldcnt;
-#ifdef SDIO_DYNAMIC_ALLOC_MEM
- u8 *oldmem;
-#endif
s32 err;
@@ -447,13 +444,6 @@ static u32 sdio_read_port(
err = _sd_read(intfhdl, addr, cnt, mem);
-#ifdef SDIO_DYNAMIC_ALLOC_MEM
- if ((oldcnt != cnt) && (oldmem)) {
- memcpy(oldmem, mem, oldcnt);
- kfree(mem);
- }
-#endif
-
if (err)
return _FAIL;
return _SUCCESS;
--
2.20.1
Re: [PATCH 6/9] arm64: dts: meson: g12a: Add UART A, B & C nodes and pins
Hi Neil,
On Sat, Mar 16, 2019 at 3:35 PM Neil Armstrong wrote:
[...]
> >> + uart_ao_a_c_pins: uart_ao_a_c {
> >> + mux {
> >> + groups =
> >> "uart_ao_a_rx_c",
> >> +
> >> "uart_ao_a_tx_c";
> >> + function =
> >> "uart_ao_a_c";
> >> + bias-disable;
> >> + };
> >> + };
> > I'm fine with this part if you mention it in the subject and/or the
> > description
> > uart_ao_a_c routes two pins from bank C (from the EE domain) to the
> > uart_AO controller (from the AO domain)
>
> Not sure DT is the right place for that, I think I'll remove this until
> we have it actually used somewhere.
I'm fine with that as well
[...]
> >> +
> >> + uart_C: serial@22000 {
> >> + compatible = "amlogic,meson-gx-uart";
> >> + reg = <0x0 0x22000 0x0 0x18>;
> >> + interrupts = >> IRQ_TYPE_EDGE_RISING>;
> >> + clocks = <&xtal>, <&clkc CLKID_UART1>,
> >> <&xtal>;
> > does uart_C really use CLKID_UART1? on GX uart_C uses CLKID_UART2
>
> It seems so :
> https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/arch/arm64/boot/dts/amlogic/mesong12a.dtsi#L1020
it's weird but we can always fix it up later if needed. so let's keep
it for now to stay consistent with the vendor kernel until we know
better
Jianxin, can you please check with the hardware team whether the
uart_C gate clock (pclk) is CLKID_UART1 or CLKID_UART2 on G12A?
Regards
Martin
Re: [PATCH 5/9] arm64: dts: meson: g12a: add reset controller
Hi Neil, On Sat, Mar 16, 2019 at 3:32 PM Neil Armstrong wrote: [...] > > Do you have any hint how to verify the CBUS offset (0x1004) of the > > reset controller? > > You can find base the address found in the G12A DT for the usb2 phy : > https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/arch/arm64/boot/dts/amlogic/mesong12a.dtsi#L379 perfect, thank you! feel free to add my: Reviewed-by: Martin Blumenstingl Regards Martin
[PATCH v2] iio: hmc5843: fix potential NULL pointer dereferences
devm_regmap_init_i2c may fail and return NULL. The fix returns
the error when it fails.
Signed-off-by: Kangjie Lu
---
V2: fix the two together
---
drivers/iio/magnetometer/hmc5843_i2c.c | 7 ++-
drivers/iio/magnetometer/hmc5843_spi.c | 7 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/magnetometer/hmc5843_i2c.c
b/drivers/iio/magnetometer/hmc5843_i2c.c
index 3de7f4426ac4..86abba5827a2 100644
--- a/drivers/iio/magnetometer/hmc5843_i2c.c
+++ b/drivers/iio/magnetometer/hmc5843_i2c.c
@@ -58,8 +58,13 @@ static const struct regmap_config hmc5843_i2c_regmap_config
= {
static int hmc5843_i2c_probe(struct i2c_client *cli,
const struct i2c_device_id *id)
{
+ struct regmap *regmap = devm_regmap_init_i2c(cli,
+ &hmc5843_i2c_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
return hmc5843_common_probe(&cli->dev,
- devm_regmap_init_i2c(cli, &hmc5843_i2c_regmap_config),
+ regmap,
id->driver_data, id->name);
}
diff --git a/drivers/iio/magnetometer/hmc5843_spi.c
b/drivers/iio/magnetometer/hmc5843_spi.c
index 535f03a70d63..8355713651d4 100644
--- a/drivers/iio/magnetometer/hmc5843_spi.c
+++ b/drivers/iio/magnetometer/hmc5843_spi.c
@@ -58,6 +58,7 @@ static const struct regmap_config hmc5843_spi_regmap_config =
{
static int hmc5843_spi_probe(struct spi_device *spi)
{
int ret;
+ struct regmap *regmap;
const struct spi_device_id *id = spi_get_device_id(spi);
spi->mode = SPI_MODE_3;
@@ -67,8 +68,12 @@ static int hmc5843_spi_probe(struct spi_device *spi)
if (ret)
return ret;
+ regmap = devm_regmap_init(spi, &hmc5843_spi_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(devm_regmap);
+
return hmc5843_common_probe(&spi->dev,
- devm_regmap_init_spi(spi, &hmc5843_spi_regmap_config),
+ regmap,
id->driver_data, id->name);
}
--
2.17.1
Re: [PATCH 11/11] arm64: dts: meson-g12a-x96-max: Enable USB
Hi Neil,
On Sat, Mar 16, 2019 at 3:46 PM Neil Armstrong wrote:
>
>
>
> Le 15/03/2019 22:50, Martin Blumenstingl a écrit :
> > Hi Neil,
> >
> > On Mon, Mar 11, 2019 at 10:58 AM Neil Armstrong
> > wrote:
> > [...]
> >> +&dwc2 {
> >> + status = "okay";
> >> +};
> > your patch description states that this enables the "USB host ports"
> > but dwc2 is only used for peripheral mode (meaning: dr_mode =
> > "peripheral" or dr_mode = "otg").
> > do we still need to enable dwc2 in a host-only configuration?
>
> DWC2 is peripheral-only, but we can still manually switch one of the
> ports and use it as peripheral with a Type-A to Type-A cable, thus
> enabling dwc2.
thank you for the explanation!
> If the OTG capable PHYs was behind an USB Hub or directly connected to
> a device, we could disable dwc2, but for now this port is always tied
> to a physical Type-A or micro-USB connector.
>
> Maybe it would be sane to always enable dwc2, and disable it for specific
> boards only.
In case the port is connected to an USB hub we can add a comment to
the .dts to explain why dwc2 is being disabled. that way we don't need
a comment in each board.dts that it's enabled to support forced mode
switching.
in other words: I like this idea!
Regards
Martin
Re: [PATCH] Use fall-through attribute rather than magic comments
Shawn, On 3/15/19 10:38 PM, Shawn Landden wrote: > The -Wimplicit-fallthrough warning recognizes magic comments > https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/ > It is my opinion that magic comments are a bad idea. Comments should not > change the interpretation (even regarding errors) of C code. > (It also happens to break distcc as distcc compiles pre-processed .i files.) > This is not the first time we discuss this topic. Please, read the archive. We are going to complete the ongoing work first and, after that, I personally will consider applying this kind of tree-wide change, or any other that may serve to the same purpose, to my tree. At this moment this change will only create confusion and potentially bring a halt to the main idea behind all this, which is to enable -Wimplicit-fallthrough. There are only ~100 of these warnings left in linux-next. Having said that, please, cultivate the practice of showing every code you touch to a compiler first before proposing any patches. Otherwise, your opinions and ideas won't be that popular. Also, if your intention was to do a tree-wide change to replace all the existing fall-through comments, you failed to take into account all the info contained in the article you mention, which by the way is incomplete. Thanks -- Gustavo
Re: [GIT PULL] pidfd patches for v5.1-rc1
The pull request you sent on Tue, 5 Mar 2019 18:13:01 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git > tags/pidfd-v5.1-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a9dce6679d736cb3d612af39bab9f31f8db66f9b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull NFS client bugfixes for 5.1
The pull request you sent on Sat, 16 Mar 2019 18:33:33 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/465c209db83e2cdaeb4a52f4e107a9fc636704db Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 4/4] x86, putuser: switch 64-bit version to normal calling convention
Use usual RDI, RSI for put_user()'s arguments.
Do everything in 4 registers, clobber RDX being the next in sequence.
Do CLAC as soon as possible.
Indent more.
Delete unnecessary macros.
This essentially undoes what Glauber did 10 years ago,
but the "this is the i386 way" is not an argument today :^)
Signed-off-by: Alexey Dobriyan
---
arch/x86/include/asm/uaccess.h |9 ++-
arch/x86/lib/putuser_64.S | 106 -
2 files changed, 50 insertions(+), 65 deletions(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -175,12 +175,17 @@ __typeof__(__builtin_choose_expr(sizeof(x) > sizeof(0UL),
0ULL, 0UL))
__builtin_expect(__ret_gu, 0); \
})
+#ifdef CONFIG_X86_32
#define __put_user_x(size, x, ptr, __ret_pu) \
asm volatile("call __put_user_" #size \
: "=a" (__ret_pu), ASM_CALL_CONSTRAINT \
: "0" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx")
-
-
+#else
+#define __put_user_x(size, x, ptr, __ret_pu) \
+ asm volatile("call __put_user_" #size \
+: "=a" (__ret_pu), ASM_CALL_CONSTRAINT \
+: "D" ((typeof(*(ptr)))(x)), "S" (ptr) : "rdx")
+#endif
#ifdef CONFIG_X86_32
#define __put_user_goto_u64(x, addr, label)\
--- a/arch/x86/lib/putuser_64.S
+++ b/arch/x86/lib/putuser_64.S
@@ -5,11 +5,8 @@
* (C) Copyright 2005 Linus Torvalds
* (C) Copyright 2005 Andi Kleen
* (C) Copyright 2008 Glauber Costa
+ * (C) Copyright 2019 Alexey Dobriyan
*
- * These functions have a non-standard call interface
- * to make them more efficient, especially as they
- * return an error value in addition to the "real"
- * return value.
*/
#include
#include
@@ -18,86 +15,69 @@
#include
#include
-
-/*
- * __put_user_X
- *
- * Inputs: %eax[:%edx] contains the data
- * %ecx contains the address
- *
- * Outputs:%eax is error code (0 or -EFAULT)
- *
- * These functions should not modify any other registers,
- * as they get called from within inline assembly.
- */
-
-#define ENTER mov PER_CPU_VAR(current_task), %_ASM_BX
-#define EXIT ASM_CLAC ; \
- ret
-
.text
+
ENTRY(__put_user_1)
- ENTER
- cmp TASK_addr_limit(%_ASM_BX),%_ASM_CX
- jae bad_put_user
+ mov PER_CPU_VAR(current_task), %rdx
+ cmp TASK_addr_limit(%rdx), %rsi
+ jae bad_put_user
ASM_STAC
-1: movb %al,(%_ASM_CX)
- xor %eax,%eax
- EXIT
+1: mov %dil, (%rsi)
+ ASM_CLAC
+ xor %eax, %eax
+ ret
ENDPROC(__put_user_1)
EXPORT_SYMBOL(__put_user_1)
ENTRY(__put_user_2)
- ENTER
- mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
- sub $1,%_ASM_BX
- cmp %_ASM_BX,%_ASM_CX
- jae bad_put_user
+ mov PER_CPU_VAR(current_task), %rdx
+ mov TASK_addr_limit(%rdx), %rdx
+ sub $1, %rdx
+ cmp %rdx, %rsi
+ jae bad_put_user
ASM_STAC
-2: movw %ax,(%_ASM_CX)
- xor %eax,%eax
- EXIT
+2: mov %di, (%rsi)
+ ASM_CLAC
+ xor %eax, %eax
+ ret
ENDPROC(__put_user_2)
EXPORT_SYMBOL(__put_user_2)
ENTRY(__put_user_4)
- ENTER
- mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
- sub $3,%_ASM_BX
- cmp %_ASM_BX,%_ASM_CX
- jae bad_put_user
+ mov PER_CPU_VAR(current_task), %rdx
+ mov TASK_addr_limit(%rdx), %rdx
+ sub $3, %rdx
+ cmp %rdx, %rsi
+ jae bad_put_user
ASM_STAC
-3: movl %eax,(%_ASM_CX)
- xor %eax,%eax
- EXIT
+4: mov %edi, (%rsi)
+ ASM_CLAC
+ xor %eax, %eax
+ ret
ENDPROC(__put_user_4)
EXPORT_SYMBOL(__put_user_4)
ENTRY(__put_user_8)
- ENTER
- mov TASK_addr_limit(%_ASM_BX),%_ASM_BX
- sub $7,%_ASM_BX
- cmp %_ASM_BX,%_ASM_CX
- jae bad_put_user
+ mov PER_CPU_VAR(current_task), %rdx
+ mov TASK_addr_limit(%rdx), %rdx
+ sub $7, %rdx
+ cmp %rdx, %rsi
+ jae bad_put_user
ASM_STAC
-4: mov %_ASM_AX,(%_ASM_CX)
-#ifdef CONFIG_X86_32
-5: movl %edx,4(%_ASM_CX)
-#endif
- xor %eax,%eax
- EXIT
+8: mov %rdi, (%rsi)
+ ASM_CLAC
+ xor %eax, %eax
+ ret
ENDPROC(__put_user_8)
EXPORT_SYMBOL(__put_user_8)
bad_put_user:
- movl $-EFAULT,%eax
- EXIT
+ ASM_CLAC
+ mov $-EFAULT, %eax
+ ret
END(bad_put_user)
- _ASM_EXTABLE_UA(1b, bad_put_user)
- _ASM_EXTABLE_UA(2b, bad_put_user)
- _ASM_EXTABLE_UA(3b, bad_put_user)
- _ASM_EXTABLE_UA(4b, bad_put_user)
-#ifdef CONFIG_X86_32
- _ASM_EXTABLE_UA(5b, bad_put_user)
-#endif
+_ASM_EXTABLE_UA(1b, bad_put_user)
+_ASM_EXTABLE_UA(2b, bad_put_user)
+_ASM_EXTABLE_UA(4b, bad_put_user)
+_ASM_EXTABLE_UA(8b, bad_put_user)
[PATCH 3/4] x86, putuser: cleanup 32-bit version a little
Delete CONFIG_X86_32 references and _ASM_* macros. Don't bother with anything else because i386 is dead. Signed-off-by: Alexey Dobriyan --- arch/x86/lib/putuser_32.S | 36 1 file changed, 16 insertions(+), 20 deletions(-) --- a/arch/x86/lib/putuser_32.S +++ b/arch/x86/lib/putuser_32.S @@ -31,17 +31,17 @@ * as they get called from within inline assembly. */ -#define ENTER mov PER_CPU_VAR(current_task), %_ASM_BX +#define ENTER mov PER_CPU_VAR(current_task), %ebx #define EXIT ASM_CLAC ; \ ret .text ENTRY(__put_user_1) ENTER - cmp TASK_addr_limit(%_ASM_BX),%_ASM_CX + cmp TASK_addr_limit(%ebx),%ecx jae bad_put_user ASM_STAC -1: movb %al,(%_ASM_CX) +1: movb %al,(%ecx) xor %eax,%eax EXIT ENDPROC(__put_user_1) @@ -49,12 +49,12 @@ EXPORT_SYMBOL(__put_user_1) ENTRY(__put_user_2) ENTER - mov TASK_addr_limit(%_ASM_BX),%_ASM_BX - sub $1,%_ASM_BX - cmp %_ASM_BX,%_ASM_CX + mov TASK_addr_limit(%ebx),%ebx + sub $1,%ebx + cmp %ebx,%ecx jae bad_put_user ASM_STAC -2: movw %ax,(%_ASM_CX) +2: movw %ax,(%ecx) xor %eax,%eax EXIT ENDPROC(__put_user_2) @@ -62,12 +62,12 @@ EXPORT_SYMBOL(__put_user_2) ENTRY(__put_user_4) ENTER - mov TASK_addr_limit(%_ASM_BX),%_ASM_BX - sub $3,%_ASM_BX - cmp %_ASM_BX,%_ASM_CX + mov TASK_addr_limit(%ebx),%ebx + sub $3,%ebx + cmp %ebx,%ecx jae bad_put_user ASM_STAC -3: movl %eax,(%_ASM_CX) +3: movl %eax,(%ecx) xor %eax,%eax EXIT ENDPROC(__put_user_4) @@ -75,15 +75,13 @@ EXPORT_SYMBOL(__put_user_4) ENTRY(__put_user_8) ENTER - mov TASK_addr_limit(%_ASM_BX),%_ASM_BX - sub $7,%_ASM_BX - cmp %_ASM_BX,%_ASM_CX + mov TASK_addr_limit(%ebx),%ebx + sub $7,%ebx + cmp %ebx,%ecx jae bad_put_user ASM_STAC -4: mov %_ASM_AX,(%_ASM_CX) -#ifdef CONFIG_X86_32 -5: movl %edx,4(%_ASM_CX) -#endif +4: mov %eax,(%ecx) +5: movl %edx,4(%ecx) xor %eax,%eax EXIT ENDPROC(__put_user_8) @@ -98,6 +96,4 @@ END(bad_put_user) _ASM_EXTABLE_UA(2b, bad_put_user) _ASM_EXTABLE_UA(3b, bad_put_user) _ASM_EXTABLE_UA(4b, bad_put_user) -#ifdef CONFIG_X86_32 _ASM_EXTABLE_UA(5b, bad_put_user) -#endif
[PATCH 2/4] x86, putuser: copy pasta into 32 and 64-bit versions
I'm going to rewrite 64-bit version to use normal x86_64 calling convention. Signed-off-by: Alexey Dobriyan --- arch/x86/lib/Makefile |3 - arch/x86/lib/putuser_64.S | 103 ++ 2 files changed, 105 insertions(+), 1 deletion(-) --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -21,7 +21,8 @@ clean-files := inat-tables.c obj-$(CONFIG_SMP) += msr-smp.o cache-smp.o lib-y := delay.o misc.o cmdline.o cpu.o -lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o +lib-y += usercopy_$(BITS).o usercopy.o getuser.o +lib-y += putuser_$(BITS).o lib-y += memcpy_$(BITS).o lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-eval.o similarity index 100% rename from arch/x86/lib/putuser.S rename to arch/x86/lib/putuser_32.S new file mode 100644 --- /dev/null +++ b/arch/x86/lib/putuser_64.S @@ -0,0 +1,103 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * __put_user functions. + * + * (C) Copyright 2005 Linus Torvalds + * (C) Copyright 2005 Andi Kleen + * (C) Copyright 2008 Glauber Costa + * + * These functions have a non-standard call interface + * to make them more efficient, especially as they + * return an error value in addition to the "real" + * return value. + */ +#include +#include +#include +#include +#include +#include + + +/* + * __put_user_X + * + * Inputs: %eax[:%edx] contains the data + * %ecx contains the address + * + * Outputs:%eax is error code (0 or -EFAULT) + * + * These functions should not modify any other registers, + * as they get called from within inline assembly. + */ + +#define ENTER mov PER_CPU_VAR(current_task), %_ASM_BX +#define EXIT ASM_CLAC ; \ + ret + +.text +ENTRY(__put_user_1) + ENTER + cmp TASK_addr_limit(%_ASM_BX),%_ASM_CX + jae bad_put_user + ASM_STAC +1: movb %al,(%_ASM_CX) + xor %eax,%eax + EXIT +ENDPROC(__put_user_1) +EXPORT_SYMBOL(__put_user_1) + +ENTRY(__put_user_2) + ENTER + mov TASK_addr_limit(%_ASM_BX),%_ASM_BX + sub $1,%_ASM_BX + cmp %_ASM_BX,%_ASM_CX + jae bad_put_user + ASM_STAC +2: movw %ax,(%_ASM_CX) + xor %eax,%eax + EXIT +ENDPROC(__put_user_2) +EXPORT_SYMBOL(__put_user_2) + +ENTRY(__put_user_4) + ENTER + mov TASK_addr_limit(%_ASM_BX),%_ASM_BX + sub $3,%_ASM_BX + cmp %_ASM_BX,%_ASM_CX + jae bad_put_user + ASM_STAC +3: movl %eax,(%_ASM_CX) + xor %eax,%eax + EXIT +ENDPROC(__put_user_4) +EXPORT_SYMBOL(__put_user_4) + +ENTRY(__put_user_8) + ENTER + mov TASK_addr_limit(%_ASM_BX),%_ASM_BX + sub $7,%_ASM_BX + cmp %_ASM_BX,%_ASM_CX + jae bad_put_user + ASM_STAC +4: mov %_ASM_AX,(%_ASM_CX) +#ifdef CONFIG_X86_32 +5: movl %edx,4(%_ASM_CX) +#endif + xor %eax,%eax + EXIT +ENDPROC(__put_user_8) +EXPORT_SYMBOL(__put_user_8) + +bad_put_user: + movl $-EFAULT,%eax + EXIT +END(bad_put_user) + + _ASM_EXTABLE_UA(1b, bad_put_user) + _ASM_EXTABLE_UA(2b, bad_put_user) + _ASM_EXTABLE_UA(3b, bad_put_user) + _ASM_EXTABLE_UA(4b, bad_put_user) +#ifdef CONFIG_X86_32 + _ASM_EXTABLE_UA(5b, bad_put_user) +#endif
[PATCH 1/4] x86, putuser: add ASM_CALL_CONSTRAINT
Clobber stack pointer given that assembly does CALL.
Signed-off-by: Alexey Dobriyan
---
arch/x86/include/asm/uaccess.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -176,7 +176,8 @@ __typeof__(__builtin_choose_expr(sizeof(x) > sizeof(0UL),
0ULL, 0UL))
})
#define __put_user_x(size, x, ptr, __ret_pu) \
- asm volatile("call __put_user_" #size : "=a" (__ret_pu) \
+ asm volatile("call __put_user_" #size \
+: "=a" (__ret_pu), ASM_CALL_CONSTRAINT \
: "0" ((typeof(*(ptr)))(x)), "c" (ptr) : "ebx")
[PATCH 1/3] habanalabs: perform accounting for active CS
This patch adds accounting for active CS. Active means that the CS was
submitted to the H/W queues and was not completed yet.
This is necessary to support suspend operation. Because the device will be
reset upon suspend, we can only suspend after all active CS have been
completed. Hence, we need to perform accounting on their number.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/command_submission.c | 6 ++
drivers/misc/habanalabs/device.c | 1 +
drivers/misc/habanalabs/habanalabs.h | 13 -
drivers/misc/habanalabs/hw_queue.c | 5 +++--
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/habanalabs/command_submission.c
b/drivers/misc/habanalabs/command_submission.c
index 3525236ed8d9..19c84214a7ea 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -179,6 +179,12 @@ static void cs_do_release(struct kref *ref)
/* We also need to update CI for internal queues */
if (cs->submitted) {
+ int cs_cnt = atomic_dec_return(&hdev->cs_active_cnt);
+
+ WARN_ONCE((cs_cnt < 0),
+ "hl%d: error in CS active cnt %d\n",
+ hdev->id, cs_cnt);
+
hl_int_hw_queue_update_ci(cs);
spin_lock(&hdev->hw_queues_mirror_lock);
diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 93d67983ddba..470d8005b50e 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -218,6 +218,7 @@ static int device_early_init(struct hl_device *hdev)
spin_lock_init(&hdev->hw_queues_mirror_lock);
atomic_set(&hdev->in_reset, 0);
atomic_set(&hdev->fd_open_cnt, 0);
+ atomic_set(&hdev->cs_active_cnt, 0);
return 0;
diff --git a/drivers/misc/habanalabs/habanalabs.h
b/drivers/misc/habanalabs/habanalabs.h
index 806f0a5ee4d8..a8ee52c880cd 100644
--- a/drivers/misc/habanalabs/habanalabs.h
+++ b/drivers/misc/habanalabs/habanalabs.h
@@ -1056,13 +1056,15 @@ struct hl_device_reset_work {
* @cb_pool_lock: protects the CB pool.
* @user_ctx: current user context executing.
* @dram_used_mem: current DRAM memory consumption.
- * @in_reset: is device in reset flow.
- * @curr_pll_profile: current PLL profile.
- * @fd_open_cnt: number of open user processes.
* @timeout_jiffies: device CS timeout value.
* @max_power: the max power of the device, as configured by the sysadmin. This
* value is saved so in case of hard-reset, KMD will restore this
* value and update the F/W after the re-initialization
+ * @in_reset: is device in reset flow.
+ * @curr_pll_profile: current PLL profile.
+ * @fd_open_cnt: number of open user processes.
+ * @cs_active_cnt: number of active command submissions on this device (active
+ * means already in H/W queues)
* @major: habanalabs KMD major.
* @high_pll: high PLL profile frequency.
* @soft_reset_cnt: number of soft reset since KMD loading.
@@ -1128,11 +1130,12 @@ struct hl_device {
struct hl_ctx *user_ctx;
atomic64_t dram_used_mem;
+ u64 timeout_jiffies;
+ u64 max_power;
atomic_tin_reset;
atomic_tcurr_pll_profile;
atomic_tfd_open_cnt;
- u64 timeout_jiffies;
- u64 max_power;
+ atomic_tcs_active_cnt;
u32 major;
u32 high_pll;
u32 soft_reset_cnt;
diff --git a/drivers/misc/habanalabs/hw_queue.c
b/drivers/misc/habanalabs/hw_queue.c
index 67bece26417c..ef3bb6951360 100644
--- a/drivers/misc/habanalabs/hw_queue.c
+++ b/drivers/misc/habanalabs/hw_queue.c
@@ -370,12 +370,13 @@ int hl_hw_queue_schedule_cs(struct hl_cs *cs)
spin_unlock(&hdev->hw_queues_mirror_lock);
}
- list_for_each_entry_safe(job, tmp, &cs->job_list, cs_node) {
+ atomic_inc(&hdev->cs_active_cnt);
+
+ list_for_each_entry_safe(job, tmp, &cs->job_list, cs_node)
if (job->ext_queue)
ext_hw_queue_schedule_job(job);
else
int_hw_queue_schedule_job(job);
- }
cs->submitted = true;
--
2.17.1
[PATCH 2/3] habanalabs: prevent host crash during suspend/resume
This patch fixes the implementation of suspend/resume of the device so that
upon resume of the device, the host won't crash due to PCI completion
timeout.
Upon suspend, the device is being reset due to PERST. Therefore, upon
resume, the driver must initialize the PCI controller as if the driver was
loaded. If the controller is not initialized and the device tries to
access the device through the PCI bars, the host will crash with PCI
completion timeout error.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/device.c| 46 +++--
drivers/misc/habanalabs/goya/goya.c | 63 +
2 files changed, 43 insertions(+), 66 deletions(-)
diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 470d8005b50e..77d51be66c7e 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -416,6 +416,27 @@ int hl_device_suspend(struct hl_device *hdev)
pci_save_state(hdev->pdev);
+ /* Block future CS/VM/JOB completion operations */
+ rc = atomic_cmpxchg(&hdev->in_reset, 0, 1);
+ if (rc) {
+ dev_err(hdev->dev, "Can't suspend while in reset\n");
+ return -EIO;
+ }
+
+ /* This blocks all other stuff that is not blocked by in_reset */
+ hdev->disabled = true;
+
+ /*
+* Flush anyone that is inside the critical section of enqueue
+* jobs to the H/W
+*/
+ hdev->asic_funcs->hw_queues_lock(hdev);
+ hdev->asic_funcs->hw_queues_unlock(hdev);
+
+ /* Flush processes that are sending message to CPU */
+ mutex_lock(&hdev->send_cpu_message_lock);
+ mutex_unlock(&hdev->send_cpu_message_lock);
+
rc = hdev->asic_funcs->suspend(hdev);
if (rc)
dev_err(hdev->dev,
@@ -443,21 +464,38 @@ int hl_device_resume(struct hl_device *hdev)
pci_set_power_state(hdev->pdev, PCI_D0);
pci_restore_state(hdev->pdev);
- rc = pci_enable_device(hdev->pdev);
+ rc = pci_enable_device_mem(hdev->pdev);
if (rc) {
dev_err(hdev->dev,
"Failed to enable PCI device in resume\n");
return rc;
}
+ pci_set_master(hdev->pdev);
+
rc = hdev->asic_funcs->resume(hdev);
if (rc) {
- dev_err(hdev->dev,
- "Failed to enable PCI access from device CPU\n");
- return rc;
+ dev_err(hdev->dev, "Failed to resume device after suspend\n");
+ goto disable_device;
+ }
+
+
+ hdev->disabled = false;
+ atomic_set(&hdev->in_reset, 0);
+
+ rc = hl_device_reset(hdev, true, false);
+ if (rc) {
+ dev_err(hdev->dev, "Failed to reset device during resume\n");
+ goto disable_device;
}
return 0;
+
+disable_device:
+ pci_clear_master(hdev->pdev);
+ pci_disable_device(hdev->pdev);
+
+ return rc;
}
static void hl_device_hard_reset_pending(struct work_struct *work)
diff --git a/drivers/misc/habanalabs/goya/goya.c
b/drivers/misc/habanalabs/goya/goya.c
index 238dd57c541b..538d8d59d9dc 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -1201,15 +1201,6 @@ static int goya_stop_external_queues(struct hl_device
*hdev)
return retval;
}
-static void goya_resume_external_queues(struct hl_device *hdev)
-{
- WREG32(mmDMA_QM_0_GLBL_CFG1, 0);
- WREG32(mmDMA_QM_1_GLBL_CFG1, 0);
- WREG32(mmDMA_QM_2_GLBL_CFG1, 0);
- WREG32(mmDMA_QM_3_GLBL_CFG1, 0);
- WREG32(mmDMA_QM_4_GLBL_CFG1, 0);
-}
-
/*
* goya_init_cpu_queues - Initialize PQ/CQ/EQ of CPU
*
@@ -2178,36 +2169,6 @@ static int goya_stop_internal_queues(struct hl_device
*hdev)
return retval;
}
-static void goya_resume_internal_queues(struct hl_device *hdev)
-{
- WREG32(mmMME_QM_GLBL_CFG1, 0);
- WREG32(mmMME_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC0_QM_GLBL_CFG1, 0);
- WREG32(mmTPC0_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC1_QM_GLBL_CFG1, 0);
- WREG32(mmTPC1_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC2_QM_GLBL_CFG1, 0);
- WREG32(mmTPC2_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC3_QM_GLBL_CFG1, 0);
- WREG32(mmTPC3_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC4_QM_GLBL_CFG1, 0);
- WREG32(mmTPC4_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC5_QM_GLBL_CFG1, 0);
- WREG32(mmTPC5_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC6_QM_GLBL_CFG1, 0);
- WREG32(mmTPC6_CMDQ_GLBL_CFG1, 0);
-
- WREG32(mmTPC7_QM_GLBL_CFG1, 0);
- WREG32(mmTPC7_CMDQ_GLBL_CFG1, 0);
-}
-
static void goya_dma_stall(struct hl_device *hdev)
{
WREG32(mmDMA_QM_0_GLBL_CFG1, 1 << DMA_QM_0_GLBL_CFG1_DMA_STOP_SHIFT);
@@ -2905,20 +2866,6 @@ int goya_suspend(struct hl_device *hdev)
{
int rc;
- rc = goya_stop_internal_queues(hdev);
-
- if (rc) {
- dev_err(hdev->dev,
[PATCH 3/3] habanalabs: cast to expected type
This patch fix the following sparse warning:
drivers/misc/habanalabs/goya/goya.c:3646:14: warning: incorrect type in
assignment (different address spaces)
drivers/misc/habanalabs/goya/goya.c:3646:14:expected void *base
drivers/misc/habanalabs/goya/goya.c:3646:14:got void [noderef] *
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/goya/goya.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/goya/goya.c
b/drivers/misc/habanalabs/goya/goya.c
index 538d8d59d9dc..ea979ebd62fb 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -3009,7 +3009,7 @@ void *goya_get_int_queue_base(struct hl_device *hdev, u32
queue_id,
*dma_handle = hdev->asic_prop.sram_base_address;
- base = hdev->pcie_bar[SRAM_CFG_BAR_ID];
+ base = (void *) hdev->pcie_bar[SRAM_CFG_BAR_ID];
switch (queue_id) {
case GOYA_QUEUE_ID_MME:
--
2.17.1
[PATCH 2/4] habanalabs: fix bug when mapping very large memory area
From: Omer Shpigelman
This patch fixes a bug of allocating a too big memory size with kmalloc,
which causes a failure.
In case of mapping a large memory block, an array of the relevant physical
page addresses is allocated. If there are many pages the array might be
too big to allocate with kmalloc, hence changing to kvmalloc.
Signed-off-by: Omer Shpigelman
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/memory.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index 4f8c968e441a..ce1fda40a8b8 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -93,7 +93,7 @@ static int alloc_device_memory(struct hl_ctx *ctx, struct
hl_mem_in *args,
phys_pg_pack->flags = args->flags;
phys_pg_pack->contiguous = contiguous;
- phys_pg_pack->pages = kcalloc(num_pgs, sizeof(u64), GFP_KERNEL);
+ phys_pg_pack->pages = kvmalloc_array(num_pgs, sizeof(u64), GFP_KERNEL);
if (!phys_pg_pack->pages) {
rc = -ENOMEM;
goto pages_arr_err;
@@ -148,7 +148,7 @@ static int alloc_device_memory(struct hl_ctx *ctx, struct
hl_mem_in *args,
gen_pool_free(vm->dram_pg_pool, phys_pg_pack->pages[i],
page_size);
- kfree(phys_pg_pack->pages);
+ kvfree(phys_pg_pack->pages);
pages_arr_err:
kfree(phys_pg_pack);
pages_pack_err:
@@ -288,7 +288,7 @@ static void free_phys_pg_pack(struct hl_device *hdev,
}
}
- kfree(phys_pg_pack->pages);
+ kvfree(phys_pg_pack->pages);
kfree(phys_pg_pack);
}
@@ -692,7 +692,8 @@ static int init_phys_pg_pack_from_userptr(struct hl_ctx
*ctx,
page_mask = ~(((u64) page_size) - 1);
- phys_pg_pack->pages = kcalloc(total_npages, sizeof(u64), GFP_KERNEL);
+ phys_pg_pack->pages = kvmalloc_array(total_npages, sizeof(u64),
+ GFP_KERNEL);
if (!phys_pg_pack->pages) {
rc = -ENOMEM;
goto page_pack_arr_mem_err;
--
2.17.1
[PATCH 4/4] habanalabs: fix mapping with page size bigger than 4KB
From: Omer Shpigelman
This patch fixes the mapping of virtual address to physical addresses on
architectures where PAGE_SIZE is bigger than 4KB.
The break down to the device page size was done only for the virtual
address while it should have been done for the physical address as well.
As a result virtual addresses were mapped to wrong physical address.
The fix is to apply the break down for the physical addresses as well in
order to get correct mappings.
Signed-off-by: Omer Shpigelman
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/mmu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/habanalabs/mmu.c b/drivers/misc/habanalabs/mmu.c
index 2f2e99cb2743..3a5a2cec8305 100644
--- a/drivers/misc/habanalabs/mmu.c
+++ b/drivers/misc/habanalabs/mmu.c
@@ -832,7 +832,7 @@ static int _hl_mmu_map(struct hl_ctx *ctx, u64 virt_addr,
u64 phys_addr,
int hl_mmu_map(struct hl_ctx *ctx, u64 virt_addr, u64 phys_addr, u32 page_size)
{
struct hl_device *hdev = ctx->hdev;
- u64 real_virt_addr;
+ u64 real_virt_addr, real_phys_addr;
u32 real_page_size, npages;
int i, rc, mapped_cnt = 0;
@@ -857,14 +857,16 @@ int hl_mmu_map(struct hl_ctx *ctx, u64 virt_addr, u64
phys_addr, u32 page_size)
npages = page_size / real_page_size;
real_virt_addr = virt_addr;
+ real_phys_addr = phys_addr;
for (i = 0 ; i < npages ; i++) {
- rc = _hl_mmu_map(ctx, real_virt_addr, phys_addr,
+ rc = _hl_mmu_map(ctx, real_virt_addr, real_phys_addr,
real_page_size);
if (rc)
goto err;
real_virt_addr += real_page_size;
+ real_phys_addr += real_page_size;
mapped_cnt++;
}
--
2.17.1
[PATCH 1/4] habanalabs: fix MMU number of pages calculation
From: Omer Shpigelman
The requested allocation size is 64bit, hence the number of requested
pages and the total requested size should 64bit as well.
This patch fixes all places where these are treated as 32bit.
Signed-off-by: Omer Shpigelman
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/debugfs.c| 7 ---
drivers/misc/habanalabs/habanalabs.h | 8
drivers/misc/habanalabs/memory.c | 29 ++--
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/misc/habanalabs/debugfs.c
b/drivers/misc/habanalabs/debugfs.c
index a53c12aff6ad..974a87789bd8 100644
--- a/drivers/misc/habanalabs/debugfs.c
+++ b/drivers/misc/habanalabs/debugfs.c
@@ -232,6 +232,7 @@ static int vm_show(struct seq_file *s, void *data)
struct hl_vm_phys_pg_pack *phys_pg_pack = NULL;
enum vm_type_t *vm_type;
bool once = true;
+ u64 j;
int i;
if (!dev_entry->hdev->mmu_enable)
@@ -260,7 +261,7 @@ static int vm_show(struct seq_file *s, void *data)
} else {
phys_pg_pack = hnode->ptr;
seq_printf(s,
- "0x%-14llx %-10u %-4u\n",
+ "0x%-14llx %-10llu
%-4u\n",
hnode->vaddr, phys_pg_pack->total_size,
phys_pg_pack->handle);
}
@@ -282,9 +283,9 @@ static int vm_show(struct seq_file *s, void *data)
phys_pg_pack->page_size);
seq_puts(s, " physical address\n");
seq_puts(s, "-\n");
- for (i = 0 ; i < phys_pg_pack->npages ; i++) {
+ for (j = 0 ; j < phys_pg_pack->npages ; j++) {
seq_printf(s, "0x%-14llx\n",
- phys_pg_pack->pages[i]);
+ phys_pg_pack->pages[j]);
}
}
spin_unlock(&vm->idr_lock);
diff --git a/drivers/misc/habanalabs/habanalabs.h
b/drivers/misc/habanalabs/habanalabs.h
index a7c95e9f9b9a..806f0a5ee4d8 100644
--- a/drivers/misc/habanalabs/habanalabs.h
+++ b/drivers/misc/habanalabs/habanalabs.h
@@ -793,11 +793,11 @@ struct hl_vm_hash_node {
* struct hl_vm_phys_pg_pack - physical page pack.
* @vm_type: describes the type of the virtual area descriptor.
* @pages: the physical page array.
+ * @npages: num physical pages in the pack.
+ * @total_size: total size of all the pages in this list.
* @mapping_cnt: number of shared mappings.
* @asid: the context related to this list.
- * @npages: num physical pages in the pack.
* @page_size: size of each page in the pack.
- * @total_size: total size of all the pages in this list.
* @flags: HL_MEM_* flags related to this list.
* @handle: the provided handle related to this list.
* @offset: offset from the first page.
@@ -807,11 +807,11 @@ struct hl_vm_hash_node {
struct hl_vm_phys_pg_pack {
enum vm_type_t vm_type; /* must be first */
u64 *pages;
+ u64 npages;
+ u64 total_size;
atomic_tmapping_cnt;
u32 asid;
- u32 npages;
u32 page_size;
- u32 total_size;
u32 flags;
u32 handle;
u32 offset;
diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index 3a12fd1a5274..4f8c968e441a 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -56,9 +56,9 @@ static int alloc_device_memory(struct hl_ctx *ctx, struct
hl_mem_in *args,
struct hl_device *hdev = ctx->hdev;
struct hl_vm *vm = &hdev->vm;
struct hl_vm_phys_pg_pack *phys_pg_pack;
- u64 paddr = 0;
- u32 total_size, num_pgs, num_curr_pgs, page_size, page_shift;
- int handle, rc, i;
+ u64 paddr = 0, total_size, num_pgs, i;
+ u32 num_curr_pgs, page_size, page_shift;
+ int handle, rc;
bool contiguous;
num_curr_pgs = 0;
@@ -73,7 +73,7 @@ static int alloc_device_memory(struct hl_ctx *ctx, struct
hl_mem_in *args,
paddr = (u64) gen_pool_alloc(vm->dram_pg_pool, total_size);
if (!paddr) {
dev_err(hdev->dev,
- "failed to allocate %u huge contiguous pages\n",
+ "failed to allocate %llu huge contiguous
pages\n",
num_pgs);
return -ENOMEM;
}
@@ -267,7 +267,7 @@ static void free_phys_pg_pack(st
[PATCH 3/4] habanalabs: complete user context cleanup before hard reset
From: Omer Shpigelman
This patch fixes a bug which led to a crash during hard reset flow.
Before a hard reset is executed, we wait a few seconds for the user
context cleanup to complete.
If it wasn't completed, we kill the user process and move on to the reset
flow.
Upon killing the user process, the context cleanup flow begins and may
take a while due to MMU unmaps.
Meanwhile, in the driver reset flow, we change the PCI DRAM bar location
which can interfere with the MMU that uses the bar.
If the context cleanup flow didn't finish quickly, a crash may occur due
to PCI DRAM bar mislocation during the MMU unmap.
Hence adding a wait between killing the user process and the start of the
reset flow.
Signed-off-by: Omer Shpigelman
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/device.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index de46aa6ed154..93d67983ddba 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -11,6 +11,8 @@
#include
#include
+#define HL_PLDM_PENDING_RESET_PER_SEC (HL_PENDING_RESET_PER_SEC * 10)
+
bool hl_device_disabled_or_in_reset(struct hl_device *hdev)
{
if ((hdev->disabled) || (atomic_read(&hdev->in_reset)))
@@ -462,9 +464,16 @@ static void hl_device_hard_reset_pending(struct
work_struct *work)
struct hl_device_reset_work *device_reset_work =
container_of(work, struct hl_device_reset_work, reset_work);
struct hl_device *hdev = device_reset_work->hdev;
- u16 pending_cnt = HL_PENDING_RESET_PER_SEC;
+ u16 pending_total, pending_cnt;
struct task_struct *task = NULL;
+ if (hdev->pldm)
+ pending_total = HL_PLDM_PENDING_RESET_PER_SEC;
+ else
+ pending_total = HL_PENDING_RESET_PER_SEC;
+
+ pending_cnt = pending_total;
+
/* Flush all processes that are inside hl_open */
mutex_lock(&hdev->fd_open_cnt_lock);
@@ -489,6 +498,19 @@ static void hl_device_hard_reset_pending(struct
work_struct *work)
}
}
+ pending_cnt = pending_total;
+
+ while ((atomic_read(&hdev->fd_open_cnt)) && (pending_cnt)) {
+
+ pending_cnt--;
+
+ ssleep(1);
+ }
+
+ if (atomic_read(&hdev->fd_open_cnt))
+ dev_crit(hdev->dev,
+ "Going to hard reset with open user contexts\n");
+
mutex_unlock(&hdev->fd_open_cnt_lock);
hl_device_reset(hdev, true, true);
--
2.17.1
Re: [PATCH 0/3] Small improvements/bugfixes to the rk3399-opi dt
Am Freitag, 15. März 2019, 15:58:15 CET schrieb Alexis Ballier: > This patch series is based on the rockchip/v5.2-armsoc/dts64 branch and > fixes a few mistakes in the rk3399-orangepi.dts I sent a couple weeks ago. applied all 3 for 5.2 Thanks Heiko
Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm
On Sat, Mar 16, 2019 at 05:38:54PM +0800, zhong jiang wrote: > On 2019/3/16 5:39, Andrea Arcangeli wrote: > > On Fri, Mar 08, 2019 at 03:10:08PM +0800, zhong jiang wrote: > >> I can reproduce the issue in arm64 qemu machine. The issue will leave > >> after applying the > >> patch. > >> > >> Tested-by: zhong jiang > > Thanks a lot for the quick testing! > > > >> Meanwhile, I just has a little doubt whether it is necessary to use RCU > >> to free the task struct or not. > >> I think that mm->owner alway be NULL after failing to create to process. > >> Because we call mm_clear_owner. > > I wish it was enough, but the problem is that the other CPU may be in > > the middle of get_mem_cgroup_from_mm() while this runs, and it would > > dereference mm->owner while it is been freed without the call_rcu > > affter we clear mm->owner. What prevents this race is the > As you had said, It would dereference mm->owner after we clear mm->owner. > > But after we clear mm->owner, mm->owner should be NULL. Is it right? > > And mem_cgroup_from_task will check the parameter. > you mean that it is possible after checking the parameter to clear the owner > . > and the NULL pointer will trigger. :-( Dereference mm->owner didn't mean reading the value of the mm->owner pointer, it really means to dereference the value of the pointer. It's like below: get_mem_cgroup_from_mm()failing fork() --- task = mm->owner mm->owner = NULL; free(mm->owner) *task /* use after free */ We didn't set mm->owner to NULL before, so the window for the race was larger, but setting mm->owner to NULL only hides the problem and it can still happen (albeit with a smaller window). If get_mem_cgroup_from_mm() can see at any time mm->owner not NULL, then the free of the task struct must be delayed until after rcu_read_unlock has returned in get_mem_cgroup_from_mm(). This is the standard RCU model, the freeing must be delayed until after the next quiescent point. BTW, both mm_update_next_owner() and mm_clear_owner() should have used WRITE_ONCE when they write to mm->owner, I can update that too but it's just to not to make assumptions that gcc does the right thing (and we still rely on gcc to do the right thing in other places) so that is just an orthogonal cleanup. Thanks, Andrea
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Sat, Mar 16, 2019 at 11:57 AM Christian Brauner wrote: > > On Sat, Mar 16, 2019 at 11:00:10AM -0700, Daniel Colascione wrote: > > On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan > > wrote: > > > > > > On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes > > > wrote: > > > > > > > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote: > > > > [..] > > > > > > why do we want to add a new syscall (pidfd_wait) though? Why not > > > > > > just use > > > > > > standard poll/epoll interface on the proc fd like Daniel was > > > > > > suggesting. > > > > > > AFAIK, once the proc file is opened, the struct pid is essentially > > > > > > pinned > > > > > > even though the proc number may be reused. Then the caller can just > > > > > > poll. > > > > > > We can add a waitqueue to struct pid, and wake up any waiters on > > > > > > process > > > > > > death (A quick look shows task_struct can be mapped to its struct > > > > > > pid) and > > > > > > also possibly optimize it using Steve's TIF flag idea. No new > > > > > > syscall is > > > > > > needed then, let me know if I missed something? > > > > > > > > > > Huh, I thought that Daniel was against the poll/epoll solution? > > > > > > > > Hmm, going through earlier threads, I believe so now. Here was Daniel's > > > > reasoning about avoiding a notification about process death through proc > > > > directory fd: > > > > http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html > > > > > > > > May be a dedicated syscall for this would be cleaner after all. > > > > > > Ah, I wish I've seen that discussion before... > > > syscall makes sense and it can be non-blocking and we can use > > > select/poll/epoll if we use eventfd. > > > > Thanks for taking a look. > > > > > I would strongly advocate for > > > non-blocking version or at least to have a non-blocking option. > > > > Waiting for FD readiness is *already* blocking or non-blocking > > according to the caller's desire --- users can pass options they want > > to poll(2) or whatever. There's no need for any kind of special > > configuration knob or non-blocking option. We already *have* a > > non-blocking option that works universally for everything. > > > > As I mentioned in the linked thread, waiting for process exit should > > work just like waiting for bytes to appear on a pipe. Process exit > > status is just another blob of bytes that a process might receive. A > > process exit handle ought to be just another information source. The > > reason the unix process API is so awful is that for whatever reason > > the original designers treated processes as some kind of special kind > > of resource instead of fitting them into the otherwise general-purpose > > unix data-handling API. Let's not repeat that mistake. > > > > > Something like this: > > > > > > evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); > > > // register eventfd to receive death notification > > > pidfd_wait(pid_to_kill, evfd); > > > // kill the process > > > pidfd_send_signal(pid_to_kill, ...) > > > // tend to other things > > > > Now you've lost me. pidfd_wait should return a *new* FD, not wire up > > an eventfd. > > Ok, I probably misunderstood your post linked by Joel. I though your original proposal was based on being able to poll a file under /proc/pid and then you changed your mind to have a separate syscall which I assumed would be a blocking one to wait for process exit. Maybe you can describe the new interface you are thinking about in terms of userspace usage like I did above? Several lines of code would explain more than paragraphs of text. > > Why? Because the new type FD can report process exit *status* > > information (via read(2) after readability signal) as well as this > > binary yes-or-no signal *that* a process exited, and this capability > > is useful if you want to the pidfd interface to be a good > > general-purpose process management facility to replace the awful > > wait() family of functions. You can't get an exit status from an > > eventfd. Wiring up an eventfd the way you've proposed also complicates > > wait-causality information, complicating both tracing and any priority > > inheritance we might want in the future (because all the wakeups gets > > mixed into the eventfd and you can't unscramble an egg). And for what? > > What do we gain by using an eventfd? Is the reason that exit.c would > > be able to use eventfd_signal instead of poking a waitqueue directly? > > How is that better? With an eventfd, you've increased path length on > > process exit *and* complicated the API for no reason. > > > > > ... > > > // wait for the process to die > > > poll_wait(evfd, ...); > > > > > > This simplifies userspace > > > > Not relative to an exit handle it doesn't. > > > > >, allows it to wait for multiple events using > > > epoll > > > > So does a process exit status handle. > > > > > and I think kernel implementation will be also quite simple > > > because it already implements eventfd_signal() that takes
Re: [PATCH v4 7/7] staging: iio: ad5933: move out of staging
On Sat, 16 Mar 2019 12:08:11 -0300 Marcelo Schmitt wrote: > Move ad5933 impedance-analyzer driver from staging to mainline. > The ad5933 is a high precision impedance converter system solution > that combines an on-board frequency generator with an > analog-to-digital converter (ADC). This driver was designed to be > compatible with both ad5933 and ad5934 chips. > > Signed-off-by: Marcelo Schmitt Hi Marcelo, A few new bits I spotted whilst looking at this again. Obviously the issues with the renames in the previous patch still apply. I'd like to get a few more sets of eyes on the driver before moving it. It's complex and quite different from most others so needs more consideration than a more 'standard' driver! Anyhow, upshot is that even if I thought it was perfect I'd still want to give it a week or two on the list before concluding everyone is happy with it. Thanks, Jonathan > --- > drivers/iio/impedance-analyzer/Kconfig| 18 + > drivers/iio/impedance-analyzer/Makefile | 5 + > drivers/iio/impedance-analyzer/ad5933.c | 811 ++ > .../staging/iio/impedance-analyzer/Kconfig| 18 - > .../staging/iio/impedance-analyzer/Makefile | 5 - > .../staging/iio/impedance-analyzer/ad5933.c | 811 -- > 6 files changed, 834 insertions(+), 834 deletions(-) > create mode 100644 drivers/iio/impedance-analyzer/Kconfig > create mode 100644 drivers/iio/impedance-analyzer/Makefile > create mode 100644 drivers/iio/impedance-analyzer/ad5933.c > delete mode 100644 drivers/staging/iio/impedance-analyzer/Kconfig > delete mode 100644 drivers/staging/iio/impedance-analyzer/Makefile > delete mode 100644 drivers/staging/iio/impedance-analyzer/ad5933.c > > diff --git a/drivers/iio/impedance-analyzer/Kconfig > b/drivers/iio/impedance-analyzer/Kconfig > new file mode 100644 > index ..b9a679cdd146 > --- /dev/null > +++ b/drivers/iio/impedance-analyzer/Kconfig > @@ -0,0 +1,18 @@ > +# > +# Impedance Converter, Network Analyzer drivers > +# > +menu "Network Analyzer, Impedance Converters" > + > +config AD5933 > + tristate "Analog Devices AD5933, AD5934 driver" > + depends on I2C > + select IIO_BUFFER > + select IIO_KFIFO_BUF > + help > + Say yes here to build support for Analog Devices Impedance Converter, > + Network Analyzer, AD5933/4. > + > + To compile this driver as a module, choose M here: the > + module will be called ad5933. > + > +endmenu > diff --git a/drivers/iio/impedance-analyzer/Makefile > b/drivers/iio/impedance-analyzer/Makefile > new file mode 100644 > index ..7604d786583e > --- /dev/null > +++ b/drivers/iio/impedance-analyzer/Makefile > @@ -0,0 +1,5 @@ > +# > +# Makefile for Impedance Converter, Network Analyzer drivers > +# > + > +obj-$(CONFIG_AD5933) += ad5933.o > diff --git a/drivers/iio/impedance-analyzer/ad5933.c > b/drivers/iio/impedance-analyzer/ad5933.c > new file mode 100644 > index ..262415bc659d > --- /dev/null > +++ b/drivers/iio/impedance-analyzer/ad5933.c > @@ -0,0 +1,811 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * AD5933 AD5934 Impedance Converter, Network Analyzer > + * > + * Copyright 2011 Analog Devices Inc. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +/* AD5933/AD5934 Registers */ > +#define AD5933_REG_CONTROL_HB0x80/* R/W, 1 byte */ > +#define AD5933_REG_CONTROL_LB0x81/* R/W, 1 byte */ > +#define AD5933_REG_FREQ_START0x82/* R/W, 3 bytes */ > +#define AD5933_REG_FREQ_INC 0x85/* R/W, 3 bytes */ > +#define AD5933_REG_INC_NUM 0x88/* R/W, 2 bytes, 9 bit */ > +#define AD5933_REG_SETTLING_CYCLES 0x8A/* R/W, 2 bytes */ > +#define AD5933_REG_STATUS0x8F/* R, 1 byte */ > +#define AD5933_REG_TEMP_DATA 0x92/* R, 2 bytes*/ > +#define AD5933_REG_REAL_DATA 0x94/* R, 2 bytes*/ > +#define AD5933_REG_IMAG_DATA 0x96/* R, 2 bytes*/ > + > +/* AD5933_REG_CONTROL_HB Bits */ > +#define AD5933_CTRL_INIT_START_FREQ (0x1 << 4) > +#define AD5933_CTRL_START_SWEEP (0x2 << 4) > +#define AD5933_CTRL_INC_FREQ (0x3 << 4) > +#define AD5933_CTRL_REPEAT_FREQ (0x4 << 4) > +#define AD5933_CTRL_MEASURE_TEMP (0x9 << 4) > +#define AD5933_CTRL_POWER_DOWN (0xA << 4) > +#define AD5933_CTRL_STANDBY (0xB << 4) > + > +#define AD5933_CTRL_RANGE_2000mVpp (0x0 << 1) > +#define AD5933_CTRL_RANGE_200mVpp(0x1 << 1) > +#define AD5933_CTRL_RANGE_400mVpp(0x2 << 1) > +#define AD5933_CTRL_RANGE_1000mVpp (0x3 << 1) These defines are never actually used... Would be better to have an values passed into the macro below even if they were. > +#define AD5933_CTRL_RANGE(x) ((x) << 1) > + > +#define AD59
Re: [PATCH 0/2] x86/CPU: Use correct Cyrix-specific macros
On Thu, Mar 14, 2019 at 1:46 PM Matthew Whitehead wrote:
>
> Replace the incorrect Cyrix-specific macro calls with the correct
> setCx86() and getCx86() calls. Also remove the unused setCx86_old(),
> getCx86_old() and their related comments in the code.
>
> Matthew Whitehead (2):
> x86/CPU: Use correct macros for Cyrix calls on Geode processors
> x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors
This series looks reasonable to me. Also, Matthew seems to be the
best tester around for this old hardware, so, if he says it works, I
believe him :) I certainly can't test this stuff.
--Andy
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Sat, Mar 16, 2019 at 11:00:10AM -0700, Daniel Colascione wrote: > On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan wrote: > > > > On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes > > wrote: > > > > > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote: > > > [..] > > > > > why do we want to add a new syscall (pidfd_wait) though? Why not just > > > > > use > > > > > standard poll/epoll interface on the proc fd like Daniel was > > > > > suggesting. > > > > > AFAIK, once the proc file is opened, the struct pid is essentially > > > > > pinned > > > > > even though the proc number may be reused. Then the caller can just > > > > > poll. > > > > > We can add a waitqueue to struct pid, and wake up any waiters on > > > > > process > > > > > death (A quick look shows task_struct can be mapped to its struct > > > > > pid) and > > > > > also possibly optimize it using Steve's TIF flag idea. No new syscall > > > > > is > > > > > needed then, let me know if I missed something? > > > > > > > > Huh, I thought that Daniel was against the poll/epoll solution? > > > > > > Hmm, going through earlier threads, I believe so now. Here was Daniel's > > > reasoning about avoiding a notification about process death through proc > > > directory fd: http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html > > > > > > May be a dedicated syscall for this would be cleaner after all. > > > > Ah, I wish I've seen that discussion before... > > syscall makes sense and it can be non-blocking and we can use > > select/poll/epoll if we use eventfd. > > Thanks for taking a look. > > > I would strongly advocate for > > non-blocking version or at least to have a non-blocking option. > > Waiting for FD readiness is *already* blocking or non-blocking > according to the caller's desire --- users can pass options they want > to poll(2) or whatever. There's no need for any kind of special > configuration knob or non-blocking option. We already *have* a > non-blocking option that works universally for everything. > > As I mentioned in the linked thread, waiting for process exit should > work just like waiting for bytes to appear on a pipe. Process exit > status is just another blob of bytes that a process might receive. A > process exit handle ought to be just another information source. The > reason the unix process API is so awful is that for whatever reason > the original designers treated processes as some kind of special kind > of resource instead of fitting them into the otherwise general-purpose > unix data-handling API. Let's not repeat that mistake. > > > Something like this: > > > > evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); > > // register eventfd to receive death notification > > pidfd_wait(pid_to_kill, evfd); > > // kill the process > > pidfd_send_signal(pid_to_kill, ...) > > // tend to other things > > Now you've lost me. pidfd_wait should return a *new* FD, not wire up > an eventfd. > > Why? Because the new type FD can report process exit *status* > information (via read(2) after readability signal) as well as this > binary yes-or-no signal *that* a process exited, and this capability > is useful if you want to the pidfd interface to be a good > general-purpose process management facility to replace the awful > wait() family of functions. You can't get an exit status from an > eventfd. Wiring up an eventfd the way you've proposed also complicates > wait-causality information, complicating both tracing and any priority > inheritance we might want in the future (because all the wakeups gets > mixed into the eventfd and you can't unscramble an egg). And for what? > What do we gain by using an eventfd? Is the reason that exit.c would > be able to use eventfd_signal instead of poking a waitqueue directly? > How is that better? With an eventfd, you've increased path length on > process exit *and* complicated the API for no reason. > > > ... > > // wait for the process to die > > poll_wait(evfd, ...); > > > > This simplifies userspace > > Not relative to an exit handle it doesn't. > > >, allows it to wait for multiple events using > > epoll > > So does a process exit status handle. > > > and I think kernel implementation will be also quite simple > > because it already implements eventfd_signal() that takes care of > > waitqueue handling. > > What if there are multiple eventfds registered for the death of a > process? In any case, you need some mechanism to find, upon process > death, a list of waiters, then wake each of them up. That's either a > global search or a search in some list rooted in a task-related > structure (either struct task or one of its friends). Using an eventfd > here adds nothing, since upon death, you need this list search > regardless, and as I mentioned above, eventfd-wiring just makes the > API worse. > > > If pidfd_send_signal could be extended to have an optional eventfd > > parameter then we would not even have to add a new syscall. > > There is nothing wrong with
Re: [PATCH v4 6/7] staging: iio: ad5933: change attributes to match ABI
On Sat, 16 Mar 2019 12:07:55 -0300
Marcelo Schmitt wrote:
> Change device attributes' names to match ABI documentation. Names were
> chosen such that they tend to be similar to existing ABI so it should
> be easier to standardize them when necessary.
>
> Signed-off-by: Marcelo Schmitt
I spoke too soon on this one...
> ---
> .../staging/iio/impedance-analyzer/ad5933.c | 20 +--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index d75bdfbf93de..262415bc659d 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -315,12 +315,12 @@ static ssize_t ad5933_store_frequency(struct device
> *dev,
> return ret ? ret : len;
> }
>
> -static IIO_DEVICE_ATTR(out_voltage0_freq_start, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_frequency_start, 0644,
> ad5933_show_frequency,
> ad5933_store_frequency,
> AD5933_REG_FREQ_START);
>
> -static IIO_DEVICE_ATTR(out_voltage0_freq_increment, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_frequency_increment, 0644,
> ad5933_show_frequency,
> ad5933_store_frequency,
> AD5933_REG_FREQ_INC);
> @@ -463,12 +463,12 @@ static IIO_DEVICE_ATTR(in_voltage0_scale_available,
> 0444,
> NULL,
> AD5933_IN_PGA_GAIN_AVAIL);
>
> -static IIO_DEVICE_ATTR(out_voltage0_freq_points, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_frequency_points, 0644,
> ad5933_show,
> ad5933_store,
> AD5933_FREQ_POINTS);
>
> -static IIO_DEVICE_ATTR(out_voltage0_settling_cycles, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_settling_cycles, 0644,
> ad5933_show,
> ad5933_store,
> AD5933_OUT_SETTLING_CYCLES);
> @@ -480,12 +480,12 @@ static IIO_DEVICE_ATTR(out_voltage0_settling_cycles,
> 0644,
> * don't create dedicated sysfs channel attributes for out0 and in0.
> */
> static struct attribute *ad5933_attributes[] = {
> - &iio_dev_attr_out_voltage0_scale.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_scale_available.dev_attr.attr,
you rename this here, but not in the place where it's defined.
Doesn't build.
> - &iio_dev_attr_out_voltage0_freq_start.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_freq_increment.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_freq_points.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_settling_cycles.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_raw.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_scale_available.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_frequency_start.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_frequency_increment.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_frequency_points.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_settling_cycles.dev_attr.attr,
> &iio_dev_attr_in_voltage0_scale.dev_attr.attr,
> &iio_dev_attr_in_voltage0_scale_available.dev_attr.attr,
> NULL
Re: [PATCH v5 10/11] staging: iio: ad7780: moving ad7780 out of staging
On 03/16, Jonathan Cameron wrote:
On Fri, 15 Mar 2019 23:15:55 -0300
Renato Lui Geh wrote:
Move ad7780 ADC driver out of staging and into the mainline.
The ad7780 is a sigma-delta analog to digital converter. This driver provides
reading voltage values and status bits from both the ad778x and ad717x series.
Its interface also allows writing on the FILTER and GAIN GPIO pins on the
ad778x.
Signed-off-by: Renato Lui Geh
Signed-off-by: Giuliano Belinassi
Co-developed-by: Giuliano Belinassi
Applied to the togreg branch of iio.git and pushed out as testing.
Note I won't be pushing that out as non rebasing (togreg) until at
least next weekend, so there is a bit of time for any last minute
feedback etc.
Thanks for all your hard work on this and great to see it graduate from
staging!
Huge thanks to both you and Alexandru for all the great feedback and
help on this! Hope to continue to send many more contributions here. :)
Thanks,
Jonathan
---
Changes in v3:
- Changes unrelated to moving the driver to main tree were resent as
individual patches
Changes in v4:
- Removed line warning it was safe to build the ad7780 driver by
default
drivers/iio/adc/Kconfig | 12 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ad7780.c | 376 +++
drivers/staging/iio/adc/Kconfig | 13 --
drivers/staging/iio/adc/Makefile | 1 -
drivers/staging/iio/adc/ad7780.c | 376 ---
6 files changed, 389 insertions(+), 390 deletions(-)
create mode 100644 drivers/iio/adc/ad7780.c
delete mode 100644 drivers/staging/iio/adc/ad7780.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index f3cc7a31bce5..6b36a45bd09f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -108,6 +108,18 @@ config AD7766
To compile this driver as a module, choose M here: the module will be
called ad7766.
+config AD7780
+ tristate "Analog Devices AD7780 and similar ADCs driver"
+ depends on SPI
+ depends on GPIOLIB || COMPILE_TEST
+ select AD_SIGMA_DELTA
+ help
+ Say yes here to build support for Analog Devices AD7170, AD7171,
+ AD7780 and AD7781 SPI analog to digital converters (ADC).
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7780.
+
config AD7791
tristate "Analog Devices AD7791 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index ea5031348052..b48852157115 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
obj-$(CONFIG_AD7606) += ad7606.o
obj-$(CONFIG_AD7766) += ad7766.o
+obj-$(CONFIG_AD7780) += ad7780.o
obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AD7793) += ad7793.o
obj-$(CONFIG_AD7887) += ad7887.o
diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c
new file mode 100644
index ..23b731a92e32
--- /dev/null
+++ b/drivers/iio/adc/ad7780.c
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AD7170/AD7171 and AD7780/AD7781 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc.
+ * Copyright 2019 Renato Lui Geh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define AD7780_RDY BIT(7)
+#define AD7780_FILTER BIT(6)
+#define AD7780_ERR BIT(5)
+#define AD7780_ID1 BIT(4)
+#define AD7780_ID0 BIT(3)
+#define AD7780_GAINBIT(2)
+
+#define AD7170_ID 0
+#define AD7171_ID 1
+#define AD7780_ID 1
+#define AD7781_ID 0
+
+#define AD7780_ID_MASK (AD7780_ID0 | AD7780_ID1)
+
+#define AD7780_PATTERN_GOOD1
+#define AD7780_PATTERN_MASKGENMASK(1, 0)
+
+#define AD7170_PATTERN_GOOD5
+#define AD7170_PATTERN_MASKGENMASK(2, 0)
+
+#define AD7780_GAIN_MIDPOINT 64
+#define AD7780_FILTER_MIDPOINT 13350
+
+static const unsigned int ad778x_gain[2] = { 1, 128 };
+static const unsigned int ad778x_odr_avail[2] = { 1, 16700 };
+
+struct ad7780_chip_info {
+ struct iio_chan_specchannel;
+ unsigned intpattern_mask;
+ unsigned intpattern;
+ boolis_ad778x;
+};
+
+struct ad7780_state {
+ const struct ad7780_chip_info *chip_info;
+ struct regulator*reg;
+ struct gpio_desc*powerdown_gpio;
+ struct gpio_desc*gain_gpio;
+ struct gpio_desc*filter_gpio;
+ unsigned intgain;
+ unsigned intodr;
+ unsigned intint_vref_mv;
+
+ struct ad_sigma_delta sd;
+};
+
+enum ad7780_supported_device_ids {
+
Re: [PATCH v4 6/7] staging: iio: ad5933: change attributes to match ABI
On Sat, 16 Mar 2019 12:07:55 -0300
Marcelo Schmitt wrote:
> Change device attributes' names to match ABI documentation. Names were
> chosen such that they tend to be similar to existing ABI so it should
> be easier to standardize them when necessary.
>
> Signed-off-by: Marcelo Schmitt
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> .../staging/iio/impedance-analyzer/ad5933.c | 20 +--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index d75bdfbf93de..262415bc659d 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -315,12 +315,12 @@ static ssize_t ad5933_store_frequency(struct device
> *dev,
> return ret ? ret : len;
> }
>
> -static IIO_DEVICE_ATTR(out_voltage0_freq_start, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_frequency_start, 0644,
> ad5933_show_frequency,
> ad5933_store_frequency,
> AD5933_REG_FREQ_START);
>
> -static IIO_DEVICE_ATTR(out_voltage0_freq_increment, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_frequency_increment, 0644,
> ad5933_show_frequency,
> ad5933_store_frequency,
> AD5933_REG_FREQ_INC);
> @@ -463,12 +463,12 @@ static IIO_DEVICE_ATTR(in_voltage0_scale_available,
> 0444,
> NULL,
> AD5933_IN_PGA_GAIN_AVAIL);
>
> -static IIO_DEVICE_ATTR(out_voltage0_freq_points, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_frequency_points, 0644,
> ad5933_show,
> ad5933_store,
> AD5933_FREQ_POINTS);
>
> -static IIO_DEVICE_ATTR(out_voltage0_settling_cycles, 0644,
> +static IIO_DEVICE_ATTR(out_altvoltage0_settling_cycles, 0644,
> ad5933_show,
> ad5933_store,
> AD5933_OUT_SETTLING_CYCLES);
> @@ -480,12 +480,12 @@ static IIO_DEVICE_ATTR(out_voltage0_settling_cycles,
> 0644,
> * don't create dedicated sysfs channel attributes for out0 and in0.
> */
> static struct attribute *ad5933_attributes[] = {
> - &iio_dev_attr_out_voltage0_scale.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_scale_available.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_freq_start.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_freq_increment.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_freq_points.dev_attr.attr,
> - &iio_dev_attr_out_voltage0_settling_cycles.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_raw.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_scale_available.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_frequency_start.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_frequency_increment.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_frequency_points.dev_attr.attr,
> + &iio_dev_attr_out_altvoltage0_settling_cycles.dev_attr.attr,
> &iio_dev_attr_in_voltage0_scale.dev_attr.attr,
> &iio_dev_attr_in_voltage0_scale_available.dev_attr.attr,
> NULL
Re: [PATCH v4 5/7] staging: iio: ad5933: add ABI documentation
On Sat, 16 Mar 2019 12:07:32 -0300 Marcelo Schmitt wrote: > Add an ABI documentation for the ad5933 driver. > > Signed-off-by: Marcelo Schmitt Some stray whitespace in here. I cleaned it up. Thanks, Jonathan > --- > .../sysfs-bus-iio-impedance-analyzer-ad5933 | 35 +++ > .../sysfs-bus-iio-impedance-analyzer-ad5933 | 30 > 2 files changed, 35 insertions(+), 30 deletions(-) > create mode 100644 > Documentation/ABI/testing/sysfs-bus-iio-impedance-analyzer-ad5933 > delete mode 100644 > drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933 > > diff --git > a/Documentation/ABI/testing/sysfs-bus-iio-impedance-analyzer-ad5933 > b/Documentation/ABI/testing/sysfs-bus-iio-impedance-analyzer-ad5933 > new file mode 100644 > index ..a50aada68e1e > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-iio-impedance-analyzer-ad5933 > @@ -0,0 +1,35 @@ > +What: > /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_start > +Date:March 2019 > +KernelVersion: 3.1.0 > +Contact: linux-...@vger.kernel.org > +Description: > + Frequency sweep start frequency in Hz. > + > +What: > /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_increment > +Date:March 2019 > +KernelVersion: 3.1.0 > +Contact: linux-...@vger.kernel.org > +Description: > + Frequency increment in Hz (step size) between consecutive > + frequency points along the sweep. > + > +What: > /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_points > +Date:March 2019 > +KernelVersion: 3.1.0 > +Contact: linux-...@vger.kernel.org > +Description: > + Number of frequency points (steps) in the frequency sweep. > + This value, in conjunction with the > + out_altvoltageY_frequency_start and the > + out_altvoltageY_frequency_increment, determines the frequency > + sweep range for the sweep operation. > + > +What: > /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_settling_cycles > +Date:March 2019 > +KernelVersion: 3.1.0 > +Contact: linux-...@vger.kernel.org > +Description: > + Number of output excitation cycles (settling time cycles) > + that are allowed to pass through the unknown impedance, > + after each frequency increment, and before the ADC is triggered > + to perform a conversion sequence of the response signal. > diff --git > a/drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933 > b/drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933 > deleted file mode 100644 > index 79c7e88c64cd.. > --- > a/drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933 > +++ /dev/null > @@ -1,30 +0,0 @@ > -What:/sys/bus/iio/devices/iio:deviceX/outY_freq_start > -KernelVersion: 3.1.0 > -Contact: linux-...@vger.kernel.org > -Description: > - Frequency sweep start frequency in Hz. > - > -What:/sys/bus/iio/devices/iio:deviceX/outY_freq_increment > -KernelVersion: 3.1.0 > -Contact: linux-...@vger.kernel.org > -Description: > - Frequency increment in Hz (step size) between consecutive > - frequency points along the sweep. > - > -What:/sys/bus/iio/devices/iio:deviceX/outY_freq_points > -KernelVersion: 3.1.0 > -Contact: linux-...@vger.kernel.org > -Description: > - Number of frequency points (steps) in the frequency sweep. > - This value, in conjunction with the outY_freq_start and the > - outY_freq_increment, determines the frequency sweep range > - for the sweep operation. > - > -What:/sys/bus/iio/devices/iio:deviceX/outY_settling_cycles > -KernelVersion: 3.1.0 > -Contact: linux-...@vger.kernel.org > -Description: > - Number of output excitation cycles (settling time cycles) > - that are allowed to pass through the unknown impedance, > - after each frequency increment, and before the ADC is triggered > - to perform a conversion sequence of the response signal.
Re: [PATCH v4 4/7] staging: iio: ad5933: change help rule message
On Sat, 16 Mar 2019 12:07:18 -0300 Marcelo Schmitt wrote: > Remove the previous comment about direct access via sysfs which would > lead one think ad5933 driver has limitations it actually doesn't. > > Signed-off-by: Marcelo Schmitt Applied. Thanks, Jonathan > --- > drivers/staging/iio/impedance-analyzer/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/impedance-analyzer/Kconfig > b/drivers/staging/iio/impedance-analyzer/Kconfig > index dd97b6bb3fd0..b9a679cdd146 100644 > --- a/drivers/staging/iio/impedance-analyzer/Kconfig > +++ b/drivers/staging/iio/impedance-analyzer/Kconfig > @@ -10,7 +10,7 @@ config AD5933 > select IIO_KFIFO_BUF > help > Say yes here to build support for Analog Devices Impedance Converter, > - Network Analyzer, AD5933/4, provides direct access via sysfs. > + Network Analyzer, AD5933/4. > > To compile this driver as a module, choose M here: the > module will be called ad5933.
Re: [PATCH v4 3/7] staging: iio: ad5933: add SPDX identifier
On Sat, 16 Mar 2019 12:07:03 -0300 Marcelo Schmitt wrote: > Add SPDX identifier of GPL-2.0 for the ad5933 driver. > > Signed-off-by: Marcelo Schmitt Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > drivers/staging/iio/impedance-analyzer/ad5933.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c > b/drivers/staging/iio/impedance-analyzer/ad5933.c > index c2a7a59e469c..d75bdfbf93de 100644 > --- a/drivers/staging/iio/impedance-analyzer/ad5933.c > +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c > @@ -1,9 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * AD5933 AD5934 Impedance Converter, Network Analyzer > * > * Copyright 2011 Analog Devices Inc. > - * > - * Licensed under the GPL-2. > */ > > #include
Re: [PATCH] net: socket: fix a missing check for nla_nest_start
From: Kangjie Lu Date: Fri, 15 Mar 2019 01:03:05 -0500 > nla_nest_start may fail. The fix check its status and returns > -EMSGSIZE in case it fails. > > Signed-off-by: Kangjie Lu The proper subsystem prefix is "tipc: " not "socket: "
Re: [PATCH v4 2/7] staging: iio: ad5933: organize includes
On Sat, 16 Mar 2019 12:06:50 -0300 Marcelo Schmitt wrote: > Organize includes to list them in lexicographic order. > > Signed-off-by: Marcelo Schmitt Applied. Thanks > --- > .../staging/iio/impedance-analyzer/ad5933.c| 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c > b/drivers/staging/iio/impedance-analyzer/ad5933.c > index 05e2185bfdae..c2a7a59e469c 100644 > --- a/drivers/staging/iio/impedance-analyzer/ad5933.c > +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c > @@ -6,22 +6,22 @@ > * Licensed under the GPL-2. > */ > > -#include > +#include > +#include > #include > -#include > -#include > +#include > #include > +#include > +#include > +#include > #include > +#include > #include > -#include > -#include > -#include > -#include > > -#include > -#include > #include > +#include > #include > +#include > > /* AD5933/AD5934 Registers */ > #define AD5933_REG_CONTROL_HB0x80/* R/W, 1 byte */
Re: [PATCH v4 1/7] staging: iio: ad5933: change multi-line comment style
On Sat, 16 Mar 2019 12:06:18 -0300
Marcelo Schmitt wrote:
> Make multi-line comments compliant with the preferred code style.
>
> Signed-off-by: Marcelo Schmitt
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to hopefully ignore.
Thanks,
Jonathan
> ---
> drivers/staging/iio/impedance-analyzer/ad5933.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 3134295f014f..05e2185bfdae 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -474,7 +474,8 @@ static IIO_DEVICE_ATTR(out_voltage0_settling_cycles, 0644,
> ad5933_store,
> AD5933_OUT_SETTLING_CYCLES);
>
> -/* note:
> +/*
> + * note:
> * ideally we would handle the scale attributes via the iio_info
> * (read|write)_raw methods, however this part is a untypical since we
> * don't create dedicated sysfs channel attributes for out0 and in0.
> @@ -572,7 +573,8 @@ static int ad5933_ring_postenable(struct iio_dev
> *indio_dev)
> {
> struct ad5933_state *st = iio_priv(indio_dev);
>
> - /* AD5933_CTRL_INIT_START_FREQ:
> + /*
> + * AD5933_CTRL_INIT_START_FREQ:
>* High Q complex circuits require a long time to reach steady state.
>* To facilitate the measurement of such impedances, this mode allows
>* the user full control of the settling time requirement before
> @@ -663,7 +665,8 @@ static void ad5933_work(struct work_struct *work)
> }
>
> if (status & AD5933_STAT_SWEEP_DONE) {
> - /* last sample received - power down do
> + /*
> + * last sample received - power down do
>* nothing until the ring enable is toggled
>*/
> ad5933_cmd(st, AD5933_CTRL_POWER_DOWN);
[GIT PULL] Please pull NFS client bugfixes for 5.1
Hi Linus, The following changes since commit 4d6c671ace569d4b0d3f8d92ab3aef18a5d166bc: SUNRPC: Take the transport send lock before binding+connecting (2019-03-10 14:08:19 -0400) are available in the Git repository at: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.1-2 for you to fetch changes up to 5e3863fd597eba8c6679de805681631b1aad9bdb: SUNRPC: Remove redundant check for the reply length in call_decode() (2019-03-15 13:11:36 -0400) Cheers Trond NFS client bugfixes for Linux 5.1 Highlights include: Bugfixes: - Fix an Oops in SUNRPC back channel tracepoints - Fix a SUNRPC client regression when handling oversized replies - Fix the minimal size for SUNRPC reply buffer allocation - rpc_decode_header() must always return a non-zero value on error - Fix a typo in pnfs_update_layout() Cleanups: - Remove redundant check for the reply length in call_decode() Olga Kornievskaia (1): fix null pointer deref in tracepoints in back channel Trond Myklebust (7): pNFS: Fix a typo in pnfs_update_layout SUNRPC: Fix a client regression when handling oversized replies SUNRPC: Fix the minimal size for reply buffer allocation SUNRPC: Use the ENOTCONN error on socket disconnect SUNRPC: rpc_decode_header() must always return a non-zero value on error SUNRPC: Handle the SYSTEM_ERR rpc error SUNRPC: Remove redundant check for the reply length in call_decode() fs/nfs/pnfs.c | 2 +- include/trace/events/sunrpc.h | 6 -- net/sunrpc/clnt.c | 32 ++-- net/sunrpc/xprt.c | 2 +- net/sunrpc/xprtsock.c | 2 +- 5 files changed, 21 insertions(+), 23 deletions(-) -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.mykleb...@hammerspace.com
Re: [PATCH v5 11/11] staging: iio: ad7780: add device tree binding
On Fri, 15 Mar 2019 23:16:13 -0300
Renato Lui Geh wrote:
> Adds a device tree binding for the ad7780 driver.
>
> Signed-off-by: Renato Lui Geh
Seems like a straight forward binding so applied to the togreg branch
of iio.git and pushed out as testing for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> .../bindings/iio/adc/adi,ad7780.txt | 48 +++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> new file mode 100644
> index ..440e52555349
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> @@ -0,0 +1,48 @@
> +* Analog Devices AD7170/AD7171/AD7780/AD7781
> +
> +Data sheets:
> +
> +- AD7170:
> + *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf
> +- AD7171:
> + *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf
> +- AD7780:
> + *
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf
> +- AD7781:
> + *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf
> +
> +Required properties:
> +
> +- compatible: should be one of
> + * "adi,ad7170"
> + * "adi,ad7171"
> + * "adi,ad7780"
> + * "adi,ad7781"
> +- reg: spi chip select number for the device
> +- vref-supply: the regulator supply for the ADC reference voltage
> +
> +Optional properties:
> +
> +- powerdown-gpios: must be the device tree identifier of the PDRST pin. If
> + specified, it will be asserted during driver probe. As the
> + line is active high, it should be marked GPIO_ACTIVE_HIGH.
> +- adi,gain-gpios: must be the device tree identifier of the GAIN pin. Only
> for
> + the ad778x chips. If specified, it will be asserted during
> + driver probe. As the line is active low, it should be marked
> + GPIO_ACTIVE_LOW.
> +- adi,filter-gpios: must be the device tree identifier of the FILTER pin.
> Only
> + for the ad778x chips. If specified, it will be asserted
> + during driver probe. As the line is active low, it should be
> + marked GPIO_ACTIVE_LOW.
> +
> +Example:
> +
> +adc@0 {
> + compatible = "adi,ad7780";
> + reg = <0>;
> + vref-supply = <&vdd_supply>
> +
> + powerdown-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;
> + adi,gain-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> + adi,filter-gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> +};
Re: [PATCH v5 10/11] staging: iio: ad7780: moving ad7780 out of staging
On Fri, 15 Mar 2019 23:15:55 -0300
Renato Lui Geh wrote:
> Move ad7780 ADC driver out of staging and into the mainline.
>
> The ad7780 is a sigma-delta analog to digital converter. This driver provides
> reading voltage values and status bits from both the ad778x and ad717x series.
> Its interface also allows writing on the FILTER and GAIN GPIO pins on the
> ad778x.
>
> Signed-off-by: Renato Lui Geh
> Signed-off-by: Giuliano Belinassi
> Co-developed-by: Giuliano Belinassi
Applied to the togreg branch of iio.git and pushed out as testing.
Note I won't be pushing that out as non rebasing (togreg) until at
least next weekend, so there is a bit of time for any last minute
feedback etc.
Thanks for all your hard work on this and great to see it graduate from
staging!
Thanks,
Jonathan
> ---
> Changes in v3:
> - Changes unrelated to moving the driver to main tree were resent as
>individual patches
> Changes in v4:
> - Removed line warning it was safe to build the ad7780 driver by
>default
>
> drivers/iio/adc/Kconfig | 12 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ad7780.c | 376 +++
> drivers/staging/iio/adc/Kconfig | 13 --
> drivers/staging/iio/adc/Makefile | 1 -
> drivers/staging/iio/adc/ad7780.c | 376 ---
> 6 files changed, 389 insertions(+), 390 deletions(-)
> create mode 100644 drivers/iio/adc/ad7780.c
> delete mode 100644 drivers/staging/iio/adc/ad7780.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index f3cc7a31bce5..6b36a45bd09f 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -108,6 +108,18 @@ config AD7766
> To compile this driver as a module, choose M here: the module will be
> called ad7766.
>
> +config AD7780
> + tristate "Analog Devices AD7780 and similar ADCs driver"
> + depends on SPI
> + depends on GPIOLIB || COMPILE_TEST
> + select AD_SIGMA_DELTA
> + help
> + Say yes here to build support for Analog Devices AD7170, AD7171,
> + AD7780 and AD7781 SPI analog to digital converters (ADC).
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad7780.
> +
> config AD7791
> tristate "Analog Devices AD7791 ADC driver"
> depends on SPI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ea5031348052..b48852157115 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
> obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
> obj-$(CONFIG_AD7606) += ad7606.o
> obj-$(CONFIG_AD7766) += ad7766.o
> +obj-$(CONFIG_AD7780) += ad7780.o
> obj-$(CONFIG_AD7791) += ad7791.o
> obj-$(CONFIG_AD7793) += ad7793.o
> obj-$(CONFIG_AD7887) += ad7887.o
> diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c
> new file mode 100644
> index ..23b731a92e32
> --- /dev/null
> +++ b/drivers/iio/adc/ad7780.c
> @@ -0,0 +1,376 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AD7170/AD7171 and AD7780/AD7781 SPI ADC driver
> + *
> + * Copyright 2011 Analog Devices Inc.
> + * Copyright 2019 Renato Lui Geh
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define AD7780_RDY BIT(7)
> +#define AD7780_FILTERBIT(6)
> +#define AD7780_ERR BIT(5)
> +#define AD7780_ID1 BIT(4)
> +#define AD7780_ID0 BIT(3)
> +#define AD7780_GAIN BIT(2)
> +
> +#define AD7170_ID0
> +#define AD7171_ID1
> +#define AD7780_ID1
> +#define AD7781_ID0
> +
> +#define AD7780_ID_MASK (AD7780_ID0 | AD7780_ID1)
> +
> +#define AD7780_PATTERN_GOOD 1
> +#define AD7780_PATTERN_MASK GENMASK(1, 0)
> +
> +#define AD7170_PATTERN_GOOD 5
> +#define AD7170_PATTERN_MASK GENMASK(2, 0)
> +
> +#define AD7780_GAIN_MIDPOINT 64
> +#define AD7780_FILTER_MIDPOINT 13350
> +
> +static const unsigned int ad778x_gain[2] = { 1, 128 };
> +static const unsigned int ad778x_odr_avail[2] = { 1, 16700 };
> +
> +struct ad7780_chip_info {
> + struct iio_chan_specchannel;
> + unsigned intpattern_mask;
> + unsigned intpattern;
> + boolis_ad778x;
> +};
> +
> +struct ad7780_state {
> + const struct ad7780_chip_info *chip_info;
> + struct regulator*reg;
> + struct gpio_desc*powerdown_gpio;
> + struct gpio_desc*gain_gpio;
> + struct gpio_desc*filter_gpio;
> + unsigned intgain;
> + unsigned intodr;
> + unsigned intint_vref_mv;
> +
> + struct ad_sigma_delta sd;
> +};
> +
>
Re: [PATCH v5 09/11] staging: iio: ad7780: add new copyright holder
On Fri, 15 Mar 2019 23:15:26 -0300 Renato Lui Geh wrote: > This patch adds a new copyright holder to the ad7780 driver. > > Signed-off-by: Renato Lui Geh Applied thanks Jonathan > --- > drivers/staging/iio/adc/ad7780.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/iio/adc/ad7780.c > b/drivers/staging/iio/adc/ad7780.c > index ff61ffa0da9f..23b731a92e32 100644 > --- a/drivers/staging/iio/adc/ad7780.c > +++ b/drivers/staging/iio/adc/ad7780.c > @@ -3,6 +3,7 @@ > * AD7170/AD7171 and AD7780/AD7781 SPI ADC driver > * > * Copyright 2011 Analog Devices Inc. > + * Copyright 2019 Renato Lui Geh > */ > > #include
Re: [PATCH v5 08/11] staging: iio: ad7780: add SPDX identifier
On Fri, 15 Mar 2019 23:15:13 -0300 Renato Lui Geh wrote: > Add SPDX identifier (GPL-2.0) to the AD7780 driver. > > Signed-off-by: Renato Lui Geh Applied > --- > drivers/staging/iio/adc/ad7780.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/adc/ad7780.c > b/drivers/staging/iio/adc/ad7780.c > index 568c5b4472ff..ff61ffa0da9f 100644 > --- a/drivers/staging/iio/adc/ad7780.c > +++ b/drivers/staging/iio/adc/ad7780.c > @@ -1,9 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * AD7170/AD7171 and AD7780/AD7781 SPI ADC driver > * > * Copyright 2011 Analog Devices Inc. > - * > - * Licensed under the GPL-2. > */ > > #include
Re: [Patch v2 2/2] CIFS: Fix an issue with re-sending rdata when transport returning -EAGAIN
пт, 15 мар. 2019 г. в 00:56, Long Li :
>
> From: Long Li
>
> When sending a rdata, transport may return -EAGAIN. In this case
> we should re-obtain credits because the session may have been
> reconnected.
>
> Change in v2: adjust_credits before re-sending
>
> Signed-off-by: Long Li
> ---
> fs/cifs/file.c | 71
> +-
> 1 file changed, 41 insertions(+), 30 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 321df1d27422..9d90cc07e38b 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -3347,44 +3347,55 @@ static int cifs_resend_rdata(struct cifs_readdata
> *rdata,
> struct TCP_Server_Info *server =
> tlink_tcon(rdata->cfile->tlink)->ses->server;
>
> - /*
> -* Wait for credits to resend this rdata.
> -* Note: we are attempting to resend the whole rdata not in segments
> -*/
> do {
> - rc = server->ops->wait_mtu_credits(server, rdata->bytes,
> + if (rdata->cfile->invalidHandle) {
> + rc = cifs_reopen_file(rdata->cfile, true);
> + if (rc == -EAGAIN)
> + continue;
> + else if (rc)
> + break;
> + }
> +
> + /*
> +* Wait for credits to resend this rdata.
> +* Note: we are attempting to resend the whole rdata not in
> +* segments
> +*/
> + do {
> + rc = server->ops->wait_mtu_credits(server,
> rdata->bytes,
> &rsize, &credits);
>
> - if (rc)
> - goto out;
> + if (rc)
> + goto fail;
>
> - if (rsize < rdata->bytes) {
> - add_credits_and_wake_if(server, &credits, 0);
> - msleep(1000);
> - }
> - } while (rsize < rdata->bytes);
> + if (rsize < rdata->bytes) {
> + add_credits_and_wake_if(server, &credits, 0);
> + msleep(1000);
> + }
> + } while (rsize < rdata->bytes);
> + rdata->credits = credits;
>
> - rdata->credits = credits;
> - rc = -EAGAIN;
> - while (rc == -EAGAIN) {
> - rc = 0;
> - if (rdata->cfile->invalidHandle)
> - rc = cifs_reopen_file(rdata->cfile, true);
> - if (!rc)
> - rc = server->ops->async_readv(rdata);
> - }
> + rc = adjust_credits(server, &rdata->credits, rdata->bytes);
> + if (!rc) {
> + if (rdata->cfile->invalidHandle)
> + rc = -EAGAIN;
> + else
> + rc = server->ops->async_readv(rdata);
> + }
>
> - if (!rc) {
> - /* Add to aio pending list */
> - list_add_tail(&rdata->list, rdata_list);
> - return 0;
> - }
> + /* If the read was successfully sent, we are done */
> + if (!rc) {
> + /* Add to aio pending list */
> + list_add_tail(&rdata->list, rdata_list);
> + return 0;
> + }
>
> - add_credits_and_wake_if(server, &rdata->credits, 0);
> -out:
> - kref_put(&rdata->refcount,
> - cifs_uncached_readdata_release);
> + /* Roll back credits and retry if needed */
> + add_credits_and_wake_if(server, &rdata->credits, 0);
> + } while (rc == -EAGAIN);
>
> +fail:
> + kref_put(&rdata->refcount, cifs_uncached_readdata_release);
> return rc;
> }
>
> --
> 2.14.1
>
Reviewed-by: Pavel Shilovsky
--
Best regards,
Pavel Shilovsky
Re: [PATCH v5 07/11] staging: iio: ad7780: move regulator to after GPIO init
On Fri, 15 Mar 2019 23:14:59 -0300
Renato Lui Geh wrote:
> To maintain consistency between ad7780_probe and ad7780_remove orders,
> regulator initialization has been moved to after GPIO initializations.
>
> Signed-off-by: Renato Lui Geh
Applied,
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7780.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 977b381c1260..568c5b4472ff 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -295,16 +295,6 @@ static int ad7780_probe(struct spi_device *spi)
>
> ad_sd_init(&st->sd, indio_dev, spi, &ad7780_sigma_delta_info);
>
> - st->reg = devm_regulator_get(&spi->dev, "avdd");
> - if (IS_ERR(st->reg))
> - return PTR_ERR(st->reg);
> -
> - ret = regulator_enable(st->reg);
> - if (ret) {
> - dev_err(&spi->dev, "Failed to enable specified AVdd supply\n");
> - return ret;
> - }
> -
> st->chip_info =
> &ad7780_chip_info_tbl[spi_get_device_id(spi)->driver_data];
>
> @@ -321,6 +311,16 @@ static int ad7780_probe(struct spi_device *spi)
> if (ret)
> goto error_cleanup_buffer_and_trigger;
>
> + st->reg = devm_regulator_get(&spi->dev, "avdd");
> + if (IS_ERR(st->reg))
> + return PTR_ERR(st->reg);
> +
> + ret = regulator_enable(st->reg);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to enable specified AVdd supply\n");
> + return ret;
> + }
> +
> ret = ad_sd_setup_buffer_and_trigger(indio_dev);
> if (ret)
> goto error_disable_reg;
Re: [Patch v2 1/2] CIFS: Fix an issue with re-sending wdata when transport returning -EAGAIN
пт, 15 мар. 2019 г. в 00:56, Long Li :
>
> From: Long Li
>
> When sending a wdata, transport may return -EAGAIN. In this case
> we should re-obtain credits because the session may have been
> reconnected.
>
> Change in v2: adjust_credits before re-sending
>
> Signed-off-by: Long Li
> ---
> fs/cifs/file.c | 77
> ++
> 1 file changed, 45 insertions(+), 32 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 9b53f33137b3..321df1d27422 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -2620,43 +2620,56 @@ cifs_resend_wdata(struct cifs_writedata *wdata,
> struct list_head *wdata_list,
> struct TCP_Server_Info *server =
> tlink_tcon(wdata->cfile->tlink)->ses->server;
>
> - /*
> -* Wait for credits to resend this wdata.
> -* Note: we are attempting to resend the whole wdata not in segments
> -*/
> do {
> - rc = server->ops->wait_mtu_credits(server, wdata->bytes,
> &wsize,
> - &credits);
> + if (wdata->cfile->invalidHandle) {
> + rc = cifs_reopen_file(wdata->cfile, false);
> + if (rc == -EAGAIN)
> + continue;
> + else if (rc)
> + break;
> + }
>
> - if (rc)
> - goto out;
>
> - if (wsize < wdata->bytes) {
> - add_credits_and_wake_if(server, &credits, 0);
> - msleep(1000);
> - }
> - } while (wsize < wdata->bytes);
> + /*
> +* Wait for credits to resend this wdata.
> +* Note: we are attempting to resend the whole wdata not in
> +* segments
> +*/
> + do {
> + rc = server->ops->wait_mtu_credits(server,
> wdata->bytes,
> + &wsize, &credits);
> + if (rc)
> + goto fail;
> +
> + if (wsize < wdata->bytes) {
> + add_credits_and_wake_if(server, &credits, 0);
> + msleep(1000);
> + }
> + } while (wsize < wdata->bytes);
> + wdata->credits = credits;
>
> - wdata->credits = credits;
> - rc = -EAGAIN;
> - while (rc == -EAGAIN) {
> - rc = 0;
> - if (wdata->cfile->invalidHandle)
> - rc = cifs_reopen_file(wdata->cfile, false);
> - if (!rc)
> - rc = server->ops->async_writev(wdata,
> + rc = adjust_credits(server, &wdata->credits, wdata->bytes);
> +
> + if (!rc) {
> + if (wdata->cfile->invalidHandle)
> + rc = -EAGAIN;
> + else
> + rc = server->ops->async_writev(wdata,
> cifs_uncached_writedata_release);
> - }
> + }
>
> - if (!rc) {
> - list_add_tail(&wdata->list, wdata_list);
> - return 0;
> - }
> + /* If the write was successfully sent, we are done */
> + if (!rc) {
> + list_add_tail(&wdata->list, wdata_list);
> + return 0;
> + }
>
> - add_credits_and_wake_if(server, &wdata->credits, 0);
> -out:
> - kref_put(&wdata->refcount, cifs_uncached_writedata_release);
> + /* Roll back credits and retry if needed */
> + add_credits_and_wake_if(server, &wdata->credits, 0);
> + } while (rc == -EAGAIN);
>
> +fail:
> + kref_put(&wdata->refcount, cifs_uncached_writedata_release);
> return rc;
> }
>
> @@ -2884,12 +2897,12 @@ static void collect_uncached_write_data(struct
> cifs_aio_ctx *ctx)
> wdata->bytes, &tmp_from,
> ctx->cfile, cifs_sb,
> &tmp_list,
> ctx);
> +
> + kref_put(&wdata->refcount,
> +
> cifs_uncached_writedata_release);
> }
>
> list_splice(&tmp_list, &ctx->list);
> -
> - kref_put(&wdata->refcount,
> -cifs_uncached_writedata_release);
> goto restart_loop;
> }
> }
> --
> 2.14.1
>
Reviewed-by: Pavel Shilovsky
--
Best regards,
Pavel Shilovsky
Re: [PATCH v5 06/11] staging:iio:ad7780: add chip ID values and mask
On Fri, 15 Mar 2019 23:14:27 -0300
Renato Lui Geh wrote:
> The ad7780 supports both the ad778x and ad717x families. Each chip has
> a corresponding ID. This patch provides a mask for extracting ID values
> from the status bits and also macros for the correct values for the
> ad7170, ad7171, ad7780 and ad7781.
>
> Signed-off-by: Renato Lui Geh
I'll admit I find it hard to summon an enthusiasm for this patch, but
it does no harm and I don't want to delay the following ones.
Hence applied anyway.
Jonathan
> ---
> Changes in v5:
> - Put AD7780_ID{0,1} back
>
> drivers/staging/iio/adc/ad7780.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 94cb60c327d0..977b381c1260 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -30,6 +30,12 @@
> #define AD7780_ID0 BIT(3)
> #define AD7780_GAIN BIT(2)
>
> +#define AD7170_ID0
> +#define AD7171_ID1
> +#define AD7780_ID1
> +#define AD7781_ID0
> +
> +#define AD7780_ID_MASK (AD7780_ID0 | AD7780_ID1)
>
> #define AD7780_PATTERN_GOOD 1
> #define AD7780_PATTERN_MASK GENMASK(1, 0)
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Sat, Mar 16, 2019 at 10:31 AM Suren Baghdasaryan wrote: > > On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes > wrote: > > > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote: > > [..] > > > > why do we want to add a new syscall (pidfd_wait) though? Why not just > > > > use > > > > standard poll/epoll interface on the proc fd like Daniel was suggesting. > > > > AFAIK, once the proc file is opened, the struct pid is essentially > > > > pinned > > > > even though the proc number may be reused. Then the caller can just > > > > poll. > > > > We can add a waitqueue to struct pid, and wake up any waiters on process > > > > death (A quick look shows task_struct can be mapped to its struct pid) > > > > and > > > > also possibly optimize it using Steve's TIF flag idea. No new syscall is > > > > needed then, let me know if I missed something? > > > > > > Huh, I thought that Daniel was against the poll/epoll solution? > > > > Hmm, going through earlier threads, I believe so now. Here was Daniel's > > reasoning about avoiding a notification about process death through proc > > directory fd: http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html > > > > May be a dedicated syscall for this would be cleaner after all. > > Ah, I wish I've seen that discussion before... > syscall makes sense and it can be non-blocking and we can use > select/poll/epoll if we use eventfd. Thanks for taking a look. > I would strongly advocate for > non-blocking version or at least to have a non-blocking option. Waiting for FD readiness is *already* blocking or non-blocking according to the caller's desire --- users can pass options they want to poll(2) or whatever. There's no need for any kind of special configuration knob or non-blocking option. We already *have* a non-blocking option that works universally for everything. As I mentioned in the linked thread, waiting for process exit should work just like waiting for bytes to appear on a pipe. Process exit status is just another blob of bytes that a process might receive. A process exit handle ought to be just another information source. The reason the unix process API is so awful is that for whatever reason the original designers treated processes as some kind of special kind of resource instead of fitting them into the otherwise general-purpose unix data-handling API. Let's not repeat that mistake. > Something like this: > > evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); > // register eventfd to receive death notification > pidfd_wait(pid_to_kill, evfd); > // kill the process > pidfd_send_signal(pid_to_kill, ...) > // tend to other things Now you've lost me. pidfd_wait should return a *new* FD, not wire up an eventfd. Why? Because the new type FD can report process exit *status* information (via read(2) after readability signal) as well as this binary yes-or-no signal *that* a process exited, and this capability is useful if you want to the pidfd interface to be a good general-purpose process management facility to replace the awful wait() family of functions. You can't get an exit status from an eventfd. Wiring up an eventfd the way you've proposed also complicates wait-causality information, complicating both tracing and any priority inheritance we might want in the future (because all the wakeups gets mixed into the eventfd and you can't unscramble an egg). And for what? What do we gain by using an eventfd? Is the reason that exit.c would be able to use eventfd_signal instead of poking a waitqueue directly? How is that better? With an eventfd, you've increased path length on process exit *and* complicated the API for no reason. > ... > // wait for the process to die > poll_wait(evfd, ...); > > This simplifies userspace Not relative to an exit handle it doesn't. >, allows it to wait for multiple events using > epoll So does a process exit status handle. > and I think kernel implementation will be also quite simple > because it already implements eventfd_signal() that takes care of > waitqueue handling. What if there are multiple eventfds registered for the death of a process? In any case, you need some mechanism to find, upon process death, a list of waiters, then wake each of them up. That's either a global search or a search in some list rooted in a task-related structure (either struct task or one of its friends). Using an eventfd here adds nothing, since upon death, you need this list search regardless, and as I mentioned above, eventfd-wiring just makes the API worse. > If pidfd_send_signal could be extended to have an optional eventfd > parameter then we would not even have to add a new syscall. There is nothing wrong with adding a new system call. I don't know why there's this idea circulating that adding system calls is something we should bend over backwards to avoid. It's cheap, and support-wise, kernel interface is kernel interface. Sending a signal has *nothing* to do with wiring up some kind of notification and there's no reason
[PATCH v9 7/9] cgroup: make TRACE_CGROUP_PATH irq-safe
To use the TRACE_CGROUP_PATH() macro with css_set_lock
locked, let's make the macro irq-safe.
It's necessary in order to trace cgroup freezer state
transitions (frozen/not frozen), which are happening
with css_set_lock locked.
Signed-off-by: Roman Gushchin
---
kernel/cgroup/cgroup-internal.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index a195328431ce..cdfa34485022 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -27,12 +27,15 @@ extern void __init enable_debug_cgroup(void);
#define TRACE_CGROUP_PATH(type, cgrp, ...) \
do {\
if (trace_cgroup_##type##_enabled()) { \
- spin_lock(&trace_cgroup_path_lock); \
+ unsigned long flags;\
+ spin_lock_irqsave(&trace_cgroup_path_lock, \
+ flags); \
cgroup_path(cgrp, trace_cgroup_path,\
TRACE_CGROUP_PATH_LEN); \
trace_cgroup_##type(cgrp, trace_cgroup_path,\
##__VA_ARGS__); \
- spin_unlock(&trace_cgroup_path_lock); \
+ spin_unlock_irqrestore(&trace_cgroup_path_lock, \
+ flags); \
} \
} while (0)
--
2.20.1
[PATCH v9 3/9] cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock
The number of descendant cgroups and the number of dying
descendant cgroups are currently synchronized using the cgroup_mutex.
The number of descendant cgroups will be required by the cgroup v2
freezer, which will use it to determine if a cgroup is frozen
(depending on total number of descendants and number of frozen
descendants). It's not always acceptable to grab the cgroup_mutex,
especially from quite hot paths (e.g. exit()).
To avoid this, let's additionally synchronize these counters using
the css_set_lock.
So, it's safe to read these counters with either cgroup_mutex or
css_set_lock locked, and for changing both locks should be acquired.
Signed-off-by: Roman Gushchin
Cc: Tejun Heo
Cc: kernel-t...@fb.com
---
include/linux/cgroup-defs.h | 5 +
kernel/cgroup/cgroup.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 120d1d40704b..319c07305500 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -348,6 +348,11 @@ struct cgroup {
* Dying cgroups are cgroups which were deleted by a user,
* but are still existing because someone else is holding a reference.
* max_descendants is a maximum allowed number of descent cgroups.
+*
+* nr_descendants and nr_dying_descendants are protected
+* by cgroup_mutex and css_set_lock. It's fine to read them holding
+* any of cgroup_mutex and css_set_lock; for writing both locks
+* should be held.
*/
int nr_descendants;
int nr_dying_descendants;
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index b230afccf635..7438c24297d4 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -4758,9 +4758,11 @@ static void css_release_work_fn(struct work_struct *work)
if (cgroup_on_dfl(cgrp))
cgroup_rstat_flush(cgrp);
+ spin_lock_irq(&css_set_lock);
for (tcgrp = cgroup_parent(cgrp); tcgrp;
tcgrp = cgroup_parent(tcgrp))
tcgrp->nr_dying_descendants--;
+ spin_unlock_irq(&css_set_lock);
cgroup_idr_remove(&cgrp->root->cgroup_idr, cgrp->id);
cgrp->id = -1;
@@ -4978,12 +4980,14 @@ static struct cgroup *cgroup_create(struct cgroup
*parent)
if (ret)
goto out_psi_free;
+ spin_lock_irq(&css_set_lock);
for (tcgrp = cgrp; tcgrp; tcgrp = cgroup_parent(tcgrp)) {
cgrp->ancestor_ids[tcgrp->level] = tcgrp->id;
if (tcgrp != cgrp)
tcgrp->nr_descendants++;
}
+ spin_unlock_irq(&css_set_lock);
if (notify_on_release(parent))
set_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags);
@@ -5268,10 +5272,12 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
if (parent && cgroup_is_threaded(cgrp))
parent->nr_threaded_children--;
+ spin_lock_irq(&css_set_lock);
for (tcgrp = cgroup_parent(cgrp); tcgrp; tcgrp = cgroup_parent(tcgrp)) {
tcgrp->nr_descendants--;
tcgrp->nr_dying_descendants++;
}
+ spin_unlock_irq(&css_set_lock);
cgroup1_check_for_release(parent);
--
2.20.1
[PATCH v9 4/9] cgroup: cgroup v2 freezer
Cgroup v1 implements the freezer controller, which provides an ability
to stop the workload in a cgroup and temporarily free up some
resources (cpu, io, network bandwidth and, potentially, memory)
for some other tasks. Cgroup v2 lacks this functionality.
This patch implements freezer for cgroup v2.
Cgroup v2 freezer tries to put tasks into a state similar to jobctl
stop. This means that tasks can be killed, ptraced (using
PTRACE_SEIZE*), and interrupted. It is possible to attach to
a frozen task, get some information (e.g. read registers) and detach.
It's also possible to migrate a frozen tasks to another cgroup.
This differs cgroup v2 freezer from cgroup v1 freezer, which mostly
tried to imitate the system-wide freezer. However uninterruptible
sleep is fine when all tasks are going to be frozen (hibernation case),
it's not the acceptable state for some subset of the system.
Cgroup v2 freezer is not supporting freezing kthreads.
If a non-root cgroup contains kthread, the cgroup still can be frozen,
but the kthread will remain running, the cgroup will be shown
as non-frozen, and the notification will not be delivered.
* PTRACE_ATTACH is not working because non-fatal signal delivery
is blocked in frozen state.
There are some interface differences between cgroup v1 and cgroup v2
freezer too, which are required to conform the cgroup v2 interface
design principles:
1) There is no separate controller, which has to be turned on:
the functionality is always available and is represented by
cgroup.freeze and cgroup.events cgroup control files.
2) The desired state is defined by the cgroup.freeze control file.
Any hierarchical configuration is allowed.
3) The interface is asynchronous. The actual state is available
using cgroup.events control file ("frozen" field). There are no
dedicated transitional states.
4) It's allowed to make any changes with the cgroup hierarchy
(create new cgroups, remove old cgroups, move tasks between cgroups)
no matter if some cgroups are frozen.
Signed-off-by: Roman Gushchin
Cc: Tejun Heo
Cc: Oleg Nesterov
Cc: kernel-t...@fb.com
---
include/linux/cgroup-defs.h | 28
include/linux/cgroup.h | 43 +
include/linux/sched.h| 2 +
include/linux/sched/jobctl.h | 2 +
kernel/cgroup/Makefile | 2 +-
kernel/cgroup/cgroup.c | 109 +++-
kernel/cgroup/freezer.c | 310 +++
kernel/fork.c| 6 +
kernel/signal.c | 75 -
9 files changed, 568 insertions(+), 9 deletions(-)
create mode 100644 kernel/cgroup/freezer.c
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 319c07305500..64b9b6c8bebe 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -64,6 +64,12 @@ enum {
* specified at mount time and thus is implemented here.
*/
CGRP_CPUSET_CLONE_CHILDREN,
+
+ /* Control group has to be frozen. */
+ CGRP_FREEZE,
+
+ /* Cgroup is frozen. */
+ CGRP_FROZEN,
};
/* cgroup_root->flags */
@@ -316,6 +322,25 @@ struct cgroup_rstat_cpu {
struct cgroup *updated_next;/* NULL iff not on the list */
};
+struct cgroup_freezer_state {
+ /* Should the cgroup and its descendants be frozen. */
+ bool freeze;
+
+ /* Should the cgroup actually be frozen? */
+ int e_freeze;
+
+ /* Fields below are protected by css_set_lock */
+
+ /* Number of frozen descendant cgroups */
+ int nr_frozen_descendants;
+
+ /*
+* Number of tasks, which are counted as frozen:
+* frozen, SIGSTOPped, and PTRACEd.
+*/
+ int nr_frozen_tasks;
+};
+
struct cgroup {
/* self css with NULL ->ss, points back to this cgroup */
struct cgroup_subsys_state self;
@@ -452,6 +477,9 @@ struct cgroup {
/* If there is block congestion on this cgroup. */
atomic_t congestion_count;
+ /* Used to store internal freezer state */
+ struct cgroup_freezer_state freezer;
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
};
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 81f58b4a5418..3e2efd412dfa 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -881,4 +881,47 @@ static inline void put_cgroup_ns(struct cgroup_namespace
*ns)
free_cgroup_ns(ns);
}
+#ifdef CONFIG_CGROUPS
+
+void cgroup_enter_frozen(void);
+void cgroup_leave_frozen(bool always_leave);
+void cgroup_update_frozen(struct cgroup *cgrp);
+void cgroup_freeze(struct cgroup *cgrp, bool freeze);
+void cgroup_freezer_migrate_task(struct task_struct *task, struct cgroup *src,
+struct cgroup *dst);
+void cgroup_freezer_frozen_exit(struct task_struct *task);
+static inline bool cgroup_task_freeze(struct task_struct *task)
+{
+ bool ret;
+
+ if (task->flags & PF_KTHREAD)
+ return false;
+
+
[PATCH v9 6/9] kselftests: cgroup: add freezer controller self-tests
This patch implements 9 tests for the freezer controller for
cgroup v2:
1) a simple test, which aims to freeze and unfreeze a cgroup with 100
processes
2) a more complicated tree test, which creates a hierarchy of cgroups,
puts some processes in some cgroups, and tries to freeze and unfreeze
different parts of the subtree
3) a forkbomb test: the test aims to freeze a forkbomb running in a
cgroup, kill all tasks in the cgroup and remove the cgroup without
the unfreezing.
4) rmdir test: the test creates two nested cgroups, freezes the parent
one, checks that the child can be successfully removed, and a new
child can be created
5) migration tests: the test checks migration of a task between
frozen cgroups: from a frozen to a running, from a running to a
frozen, and from a frozen to a frozen.
6) ptrace test: the test checks that it's possible to attach to
a process in a frozen cgroup, get some information and detach, and
the cgroup will remain frozen.
7) stopped test: the test checks that it's possible to freeze a cgroup
with a stopped task
8) ptraced test: the test checks that it's possible to freeze a cgroup
with a ptraced task
9) vfork test: the test checks that it's possible to freeze a cgroup
with a parent process waiting for the child process in vfork()
Expected output:
$ ./test_freezer
ok 1 test_cgfreezer_simple
ok 2 test_cgfreezer_tree
ok 3 test_cgfreezer_forkbomb
ok 4 test_cgrreezer_rmdir
ok 5 test_cgfreezer_migrate
ok 6 test_cgfreezer_ptrace
ok 7 test_cgfreezer_stopped
ok 8 test_cgfreezer_ptraced
ok 9 test_cgfreezer_vfork
Signed-off-by: Roman Gushchin
Cc: Shuah Khan
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/cgroup/.gitignore | 1 +
tools/testing/selftests/cgroup/Makefile | 2 +
tools/testing/selftests/cgroup/cgroup_util.c | 54 +-
tools/testing/selftests/cgroup/cgroup_util.h | 5 +
tools/testing/selftests/cgroup/test_freezer.c | 851 ++
5 files changed, 912 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/cgroup/test_freezer.c
diff --git a/tools/testing/selftests/cgroup/.gitignore
b/tools/testing/selftests/cgroup/.gitignore
index adacda50a4b2..7f9835624793 100644
--- a/tools/testing/selftests/cgroup/.gitignore
+++ b/tools/testing/selftests/cgroup/.gitignore
@@ -1,2 +1,3 @@
test_memcontrol
test_core
+test_freezer
diff --git a/tools/testing/selftests/cgroup/Makefile
b/tools/testing/selftests/cgroup/Makefile
index 23fbaa4a9630..8d369b6a2069 100644
--- a/tools/testing/selftests/cgroup/Makefile
+++ b/tools/testing/selftests/cgroup/Makefile
@@ -5,8 +5,10 @@ all:
TEST_GEN_PROGS = test_memcontrol
TEST_GEN_PROGS += test_core
+TEST_GEN_PROGS += test_freezer
include ../lib.mk
$(OUTPUT)/test_memcontrol: cgroup_util.c
$(OUTPUT)/test_core: cgroup_util.c
+$(OUTPUT)/test_freezer: cgroup_util.c
diff --git a/tools/testing/selftests/cgroup/cgroup_util.c
b/tools/testing/selftests/cgroup/cgroup_util.c
index eba06f94433b..4c223266299a 100644
--- a/tools/testing/selftests/cgroup/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/cgroup_util.c
@@ -74,6 +74,16 @@ char *cg_name_indexed(const char *root, const char *name,
int index)
return ret;
}
+char *cg_control(const char *cgroup, const char *control)
+{
+ size_t len = strlen(cgroup) + strlen(control) + 2;
+ char *ret = malloc(len);
+
+ snprintf(ret, len, "%s/%s", cgroup, control);
+
+ return ret;
+}
+
int cg_read(const char *cgroup, const char *control, char *buf, size_t len)
{
char path[PATH_MAX];
@@ -196,7 +206,32 @@ int cg_create(const char *cgroup)
return mkdir(cgroup, 0644);
}
-static int cg_killall(const char *cgroup)
+int cg_wait_for_proc_count(const char *cgroup, int count)
+{
+ char buf[10 * PAGE_SIZE] = {0};
+ int attempts;
+ char *ptr;
+
+ for (attempts = 10; attempts >= 0; attempts--) {
+ int nr = 0;
+
+ if (cg_read(cgroup, "cgroup.procs", buf, sizeof(buf)))
+ break;
+
+ for (ptr = buf; *ptr; ptr++)
+ if (*ptr == '\n')
+ nr++;
+
+ if (nr >= count)
+ return 0;
+
+ usleep(10);
+ }
+
+ return -1;
+}
+
+int cg_killall(const char *cgroup)
{
char buf[PAGE_SIZE];
char *ptr = buf;
@@ -238,6 +273,14 @@ int cg_destroy(const char *cgroup)
return ret;
}
+int cg_enter(const char *cgroup, int pid)
+{
+ char pidbuf[64];
+
+ snprintf(pidbuf, sizeof(pidbuf), "%d", pid);
+ return cg_write(cgroup, "cgroup.procs", pidbuf);
+}
+
int cg_enter_current(const char *cgroup)
{
char pidbuf[64];
@@ -367,3 +410,12 @@ int set_oom_adj_score(int pid, int score)
close(fd);
return 0;
}
+
+char proc_read_text(int pid, const char *item, char *buf, size_t size)
+{
+ char path[PATH_MAX];
+
+ snprintf
[PATCH v9 2/9] cgroup: implement __cgroup_task_count() helper
The helper is identical to the existing cgroup_task_count()
except it doesn't take the css_set_lock by itself, assuming
that the caller does.
Also, move cgroup_task_count() implementation into
kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.
Signed-off-by: Roman Gushchin
Cc: Tejun Heo
Cc: kernel-t...@fb.com
---
kernel/cgroup/cgroup-internal.h | 1 +
kernel/cgroup/cgroup-v1.c | 16
kernel/cgroup/cgroup.c | 33 +
3 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index c950864016e2..a195328431ce 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -226,6 +226,7 @@ int cgroup_rmdir(struct kernfs_node *kn);
int cgroup_show_path(struct seq_file *sf, struct kernfs_node *kf_node,
struct kernfs_root *kf_root);
+int __cgroup_task_count(const struct cgroup *cgrp);
int cgroup_task_count(const struct cgroup *cgrp);
/*
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 583b969b0c0e..29c0ca8f76cf 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -339,22 +339,6 @@ static struct cgroup_pidlist
*cgroup_pidlist_find_create(struct cgroup *cgrp,
return l;
}
-/**
- * cgroup_task_count - count the number of tasks in a cgroup.
- * @cgrp: the cgroup in question
- */
-int cgroup_task_count(const struct cgroup *cgrp)
-{
- int count = 0;
- struct cgrp_cset_link *link;
-
- spin_lock_irq(&css_set_lock);
- list_for_each_entry(link, &cgrp->cset_links, cset_link)
- count += link->cset->nr_tasks;
- spin_unlock_irq(&css_set_lock);
- return count;
-}
-
/*
* Load a cgroup's pidarray with either procs' tgids or tasks' pids
*/
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index f4418371c83b..b230afccf635 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -592,6 +592,39 @@ static void cgroup_get_live(struct cgroup *cgrp)
css_get(&cgrp->self);
}
+/**
+ * __cgroup_task_count - count the number of tasks in a cgroup. The caller
+ * is responsible for taking the css_set_lock.
+ * @cgrp: the cgroup in question
+ */
+int __cgroup_task_count(const struct cgroup *cgrp)
+{
+ int count = 0;
+ struct cgrp_cset_link *link;
+
+ lockdep_assert_held(&css_set_lock);
+
+ list_for_each_entry(link, &cgrp->cset_links, cset_link)
+ count += link->cset->nr_tasks;
+
+ return count;
+}
+
+/**
+ * cgroup_task_count - count the number of tasks in a cgroup.
+ * @cgrp: the cgroup in question
+ */
+int cgroup_task_count(const struct cgroup *cgrp)
+{
+ int count;
+
+ spin_lock_irq(&css_set_lock);
+ count = __cgroup_task_count(cgrp);
+ spin_unlock_irq(&css_set_lock);
+
+ return count;
+}
+
struct cgroup_subsys_state *of_css(struct kernfs_open_file *of)
{
struct cgroup *cgrp = of->kn->parent->priv;
--
2.20.1
[PATCH v9 5/9] kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy()
If the cgroup destruction races with an exit() of a belonging
process(es), cg_kill_all() may fail. It's not a good reason to make
cg_destroy() fail and leave the cgroup in place, potentially causing
next test runs to fail.
Signed-off-by: Roman Gushchin
Cc: Shuah Khan
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/cgroup/cgroup_util.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/cgroup/cgroup_util.c
b/tools/testing/selftests/cgroup/cgroup_util.c
index 14c9fe284806..eba06f94433b 100644
--- a/tools/testing/selftests/cgroup/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/cgroup_util.c
@@ -227,9 +227,7 @@ int cg_destroy(const char *cgroup)
retry:
ret = rmdir(cgroup);
if (ret && errno == EBUSY) {
- ret = cg_killall(cgroup);
- if (ret)
- return ret;
+ cg_killall(cgroup);
usleep(100);
goto retry;
}
--
2.20.1
[PATCH v9 0/9] freezer for cgroup v2
This patchset implements freezer for cgroup v2. It provides similar functionality as v1 freezer, but the interface conforms to the cgroup v2 interface design principles, and it provides a better user experience: tasks can be killed, ptrace works, there is no separate controller, which has to be enabled, etc. Patches (1), (2) and (3) are some preparational work, patch (4) contains the implementation, patch (5) is a small cgroup kselftest fix, patch (6) covers freezer adds 6 new kselftests to cover the freezer functionality. Patchse (7) and (8) adding tracing points to simplify the debugging process. Patch (9) adds corresponding docs. v9->v8: - added support for vfork - added a kselftest test for vfork case - several tests fixes/improvements - renamed stopped* into frozen* across the patchset - added trace points - other minor fixes v8->v7: - reworked/simplified cgroup frozen task accounting by merging nr_stopped and nr_frozen and removing nr_tasks_to_freeze - don't notify the parent process if the child is going from the stopped to the frozen state v7->v6: - handle properly the case, when a task is both stopped and frozen - check for CGRP_FREEZE instead of CGRP_FROZEN in cgroup_exit() - minor cosmetic changes and rebase v6->v5: - reverted to clear TIF_SIGPENDING with additional checks before schedule(), as proposed by Oleg Nesterov - made cgroup v2 freezer working with the system freezer (by using freezable_schedule()) - make freezer working with SIGSTOPped and PTRACEd tasks - added tests to cover freezing a cgroup with SIGSTOPped and PTRACEd tasks v5->v4: - rewored cgroup state transition code (suggested by Tejun Heo) - look at JOBCTL_TRAP_FREEZE instead of task->frozen in recalc_sigpending(), check for task->frozen and JOBCTL_TRAP_FREEZE in signal_pending_state() (suggested by Oleg Nesterov) - some cosmetic changes in signal.c (suggested by Oleg Nesterov) - cleaned up comments v4->v3: - reading nr_descendants doesn't require taking css_set_lock anymore - fixed docs based on Mike Rapoport's feedback - fixed double irq lock found by Dan Carpenter v3->v2: - dropped TASK_FROZEN for now, frozen tasks are put into TASK_INTERRUPTIBLE state; it's probably not the final version, but the API question can be discussed separately - don't clear TIF_SIGPENDING before going to sleep, instead add task->frozen check in signal_pending_state() and recalc_sigpending() - cgroup-level counter are now synchronized using css_set_lock, which simplified the whole code (e.g. per-cgroup works were removed) - the amount of comments increased significantly - many other improvements incorporating feedback from Tejun and Oleg v2->v1: - fixed locking aroung calling cgroup_freezer_leave() - added docs Roman Gushchin (9): cgroup: rename freezer.c into legacy_freezer.c cgroup: implement __cgroup_task_count() helper cgroup: protect cgroup->nr_(dying_)descendants by css_set_lock cgroup: cgroup v2 freezer kselftests: cgroup: don't fail on cg_kill_all() error in cg_destroy() kselftests: cgroup: add freezer controller self-tests cgroup: make TRACE_CGROUP_PATH irq-safe cgroup: add tracing points for cgroup v2 freezer cgroup: document cgroup v2 freezer interface Documentation/admin-guide/cgroup-v2.rst | 27 + include/linux/cgroup-defs.h | 33 + include/linux/cgroup.h| 43 + include/linux/sched.h | 2 + include/linux/sched/jobctl.h | 2 + include/trace/events/cgroup.h | 55 ++ kernel/cgroup/Makefile| 4 +- kernel/cgroup/cgroup-internal.h | 8 +- kernel/cgroup/cgroup-v1.c | 16 - kernel/cgroup/cgroup.c| 150 ++- kernel/cgroup/freezer.c | 640 + kernel/cgroup/legacy_freezer.c| 481 ++ kernel/fork.c | 6 + kernel/signal.c | 75 +- tools/testing/selftests/cgroup/.gitignore | 1 + tools/testing/selftests/cgroup/Makefile | 2 + tools/testing/selftests/cgroup/cgroup_util.c | 58 +- tools/testing/selftests/cgroup/cgroup_util.h | 5 + tools/testing/selftests/cgroup/test_freezer.c | 851 ++ 19 files changed, 2028 insertions(+), 431 deletions(-) create mode 100644 kernel/cgroup/legacy_freezer.c create mode 100644 tools/testing/selftests/cgroup/test_freezer.c -- 2.20.1
[PATCH v9 8/9] cgroup: add tracing points for cgroup v2 freezer
Add cgroup:cgroup_freeze and cgroup:cgroup_unfreeze events,
which are using the existing cgroup tracing infrastructure.
Add the cgroup_event event class, which is similar to the cgroup
class, but contains an additional integer field to store a new
value (the level field is dropped).
Also add two tracing events: cgroup_notify_populated and
cgroup_notify_frozen, which are raised in a generic way using
the TRACE_CGROUP_PATH() macro.
This allows to trace cgroup state transitions and is generally
helpful for debugging the cgroup freezer code.
Signed-off-by: Roman Gushchin
---
include/trace/events/cgroup.h | 55 +++
kernel/cgroup/cgroup.c| 2 ++
kernel/cgroup/freezer.c | 15 +-
3 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/cgroup.h b/include/trace/events/cgroup.h
index a401ff5e7847..a566cc521476 100644
--- a/include/trace/events/cgroup.h
+++ b/include/trace/events/cgroup.h
@@ -103,6 +103,20 @@ DEFINE_EVENT(cgroup, cgroup_rename,
TP_ARGS(cgrp, path)
);
+DEFINE_EVENT(cgroup, cgroup_freeze,
+
+ TP_PROTO(struct cgroup *cgrp, const char *path),
+
+ TP_ARGS(cgrp, path)
+);
+
+DEFINE_EVENT(cgroup, cgroup_unfreeze,
+
+ TP_PROTO(struct cgroup *cgrp, const char *path),
+
+ TP_ARGS(cgrp, path)
+);
+
DECLARE_EVENT_CLASS(cgroup_migrate,
TP_PROTO(struct cgroup *dst_cgrp, const char *path,
@@ -149,6 +163,47 @@ DEFINE_EVENT(cgroup_migrate, cgroup_transfer_tasks,
TP_ARGS(dst_cgrp, path, task, threadgroup)
);
+DECLARE_EVENT_CLASS(cgroup_event,
+
+ TP_PROTO(struct cgroup *cgrp, const char *path, int val),
+
+ TP_ARGS(cgrp, path, val),
+
+ TP_STRUCT__entry(
+ __field(int,root)
+ __field(int,id )
+ __field(int,level )
+ __string( path, path)
+ __field(int,val )
+ ),
+
+ TP_fast_assign(
+ __entry->root = cgrp->root->hierarchy_id;
+ __entry->id = cgrp->id;
+ __entry->level = cgrp->level;
+ __assign_str(path, path);
+ __entry->val = val;
+ ),
+
+ TP_printk("root=%d id=%d level=%d path=%s val=%d",
+ __entry->root, __entry->id, __entry->level, __get_str(path),
+ __entry->val)
+);
+
+DEFINE_EVENT(cgroup_event, cgroup_notify_populated,
+
+ TP_PROTO(struct cgroup *cgrp, const char *path, int val),
+
+ TP_ARGS(cgrp, path, val)
+);
+
+DEFINE_EVENT(cgroup_event, cgroup_notify_frozen,
+
+ TP_PROTO(struct cgroup *cgrp, const char *path, int val),
+
+ TP_ARGS(cgrp, path, val)
+);
+
#endif /* _TRACE_CGROUP_H */
/* This part must be outside protection */
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 3225ebb8689c..b9d18fa16323 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -815,6 +815,8 @@ static void cgroup_update_populated(struct cgroup *cgrp,
bool populated)
break;
cgroup1_check_for_release(cgrp);
+ TRACE_CGROUP_PATH(notify_populated, cgrp,
+ cgroup_is_populated(cgrp));
cgroup_file_notify(&cgrp->events_file);
child = cgrp;
diff --git a/kernel/cgroup/freezer.c b/kernel/cgroup/freezer.c
index 8530aa5f4c69..cf28373b7528 100644
--- a/kernel/cgroup/freezer.c
+++ b/kernel/cgroup/freezer.c
@@ -6,6 +6,8 @@
#include "cgroup-internal.h"
+#include
+
/*
* Propagate the cgroup frozen state upwards by the cgroup tree.
*/
@@ -28,6 +30,7 @@ static void cgroup_propagate_frozen(struct cgroup *cgrp, bool
frozen)
cgrp->nr_descendants) {
set_bit(CGRP_FROZEN, &cgrp->flags);
cgroup_file_notify(&cgrp->events_file);
+ TRACE_CGROUP_PATH(notify_frozen, cgrp, 1);
desc++;
}
} else {
@@ -35,6 +38,7 @@ static void cgroup_propagate_frozen(struct cgroup *cgrp, bool
frozen)
if (test_bit(CGRP_FROZEN, &cgrp->flags)) {
clear_bit(CGRP_FROZEN, &cgrp->flags);
cgroup_file_notify(&cgrp->events_file);
+ TRACE_CGROUP_PATH(notify_frozen, cgrp, 0);
desc++;
}
}
@@ -73,6 +77,7 @@ void cgroup_update_frozen(struct cgroup *cgrp)
clear_bit(CGRP_FROZEN, &cgrp->flags);
}
cgroup_file_notify(&cgrp->events_file);
+ TRACE_CGROUP_PATH(notify_frozen, cgrp, frozen);
/* Update the state of ancestor cgroups. */
cgroup_pr
[PATCH v9 1/9] cgroup: rename freezer.c into legacy_freezer.c
Freezer.c will contain an implementation of cgroup v2 freezer,
so let's rename the v1 freezer to avoid naming conflicts.
Signed-off-by: Roman Gushchin
Cc: Tejun Heo
Cc: kernel-t...@fb.com
---
kernel/cgroup/Makefile| 2 +-
kernel/cgroup/{freezer.c => legacy_freezer.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename kernel/cgroup/{freezer.c => legacy_freezer.c} (100%)
diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index bfcdae896122..8d5689ca94b9 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o
-obj-$(CONFIG_CGROUP_FREEZER) += freezer.o
+obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o
obj-$(CONFIG_CGROUP_PIDS) += pids.o
obj-$(CONFIG_CGROUP_RDMA) += rdma.o
obj-$(CONFIG_CPUSETS) += cpuset.o
diff --git a/kernel/cgroup/freezer.c b/kernel/cgroup/legacy_freezer.c
similarity index 100%
rename from kernel/cgroup/freezer.c
rename to kernel/cgroup/legacy_freezer.c
--
2.20.1
Re: [PATCH v5 05/11] staging: iio: ad7780: set pattern values and masks directly
On Fri, 15 Mar 2019 23:14:14 -0300
Renato Lui Geh wrote:
> The AD7780 driver contains status pattern bits designed for checking
> whether serial transfers have been correctly performed. Pattern macros
> were previously generated through bit fields. This patch sets good
> pattern values directly and masks through GENMASK.
>
> Signed-off-by: Renato Lui Geh
Applied,
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7780.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 8ff74427d975..94cb60c327d0 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -28,16 +29,13 @@
> #define AD7780_ID1 BIT(4)
> #define AD7780_ID0 BIT(3)
> #define AD7780_GAIN BIT(2)
> -#define AD7780_PAT1 BIT(1)
> -#define AD7780_PAT0 BIT(0)
>
> -#define AD7780_PATTERN (AD7780_PAT0)
> -#define AD7780_PATTERN_MASK (AD7780_PAT0 | AD7780_PAT1)
>
> -#define AD7170_PAT2 BIT(2)
> +#define AD7780_PATTERN_GOOD 1
> +#define AD7780_PATTERN_MASK GENMASK(1, 0)
>
> -#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> -#define AD7170_PATTERN_MASK (AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
> +#define AD7170_PATTERN_GOOD 5
> +#define AD7170_PATTERN_MASK GENMASK(2, 0)
>
> #define AD7780_GAIN_MIDPOINT 64
> #define AD7780_FILTER_MIDPOINT 13350
> @@ -209,25 +207,25 @@ static const struct ad_sigma_delta_info
> ad7780_sigma_delta_info = {
> static const struct ad7780_chip_info ad7780_chip_info_tbl[] = {
> [ID_AD7170] = {
> .channel = AD7170_CHANNEL(12, 24),
> - .pattern = AD7170_PATTERN,
> + .pattern = AD7170_PATTERN_GOOD,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> },
> [ID_AD7171] = {
> .channel = AD7170_CHANNEL(16, 24),
> - .pattern = AD7170_PATTERN,
> + .pattern = AD7170_PATTERN_GOOD,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> },
> [ID_AD7780] = {
> .channel = AD7780_CHANNEL(24, 32),
> - .pattern = AD7780_PATTERN,
> + .pattern = AD7780_PATTERN_GOOD,
> .pattern_mask = AD7780_PATTERN_MASK,
> .is_ad778x = true,
> },
> [ID_AD7781] = {
> .channel = AD7780_CHANNEL(20, 32),
> - .pattern = AD7780_PATTERN,
> + .pattern = AD7780_PATTERN_GOOD,
> .pattern_mask = AD7780_PATTERN_MASK,
> .is_ad778x = true,
> },
Re: [PATCH v5 04/11] staging: iio: ad7780: add filter reading to ad778x
On Fri, 15 Mar 2019 23:13:42 -0300
Renato Lui Geh wrote:
> This patch adds the new feature of reading the filter odr value for
> ad778x chips. This value is stored in the chip's state struct whenever a
> read or write call is performed on the chip's driver.
>
> This feature requires sharing SAMP_FREQ. Since the ad717x does not have
> a filter option, the driver only shares the relevant info mask for the
> ad778x family.
>
> Signed-off-by: Renato Lui Geh
Applied,
Thanks,
Jonathan
> ---
> Changes in v4:
> - As mentioned in the previous patch, this was originally as part of
>the 'add gain & filter gpio support' patch
> Changes in v5:
> - Moved ad778x_odr_avail declaration from GPIO patch to this one
>
> drivers/staging/iio/adc/ad7780.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index fbcc0d3345ca..8ff74427d975 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -42,7 +42,8 @@
> #define AD7780_GAIN_MIDPOINT 64
> #define AD7780_FILTER_MIDPOINT 13350
>
> -static const unsigned int ad778x_gain[2] = { 1, 128 };
> +static const unsigned int ad778x_gain[2] = { 1, 128 };
> +static const unsigned int ad778x_odr_avail[2] = { 1, 16700 };
>
> struct ad7780_chip_info {
> struct iio_chan_specchannel;
> @@ -58,6 +59,7 @@ struct ad7780_state {
> struct gpio_desc*gain_gpio;
> struct gpio_desc*filter_gpio;
> unsigned intgain;
> + unsigned intodr;
> unsigned intint_vref_mv;
>
> struct ad_sigma_delta sd;
> @@ -120,6 +122,9 @@ static int ad7780_read_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_OFFSET:
> *val = -(1 << (chan->scan_type.realbits - 1));
> return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *val = st->odr;
> + return IIO_VAL_INT;
> default:
> break;
> }
> @@ -162,6 +167,7 @@ static int ad7780_write_raw(struct iio_dev *indio_dev,
> val = 0;
> else
> val = 1;
> + st->odr = ad778x_odr_avail[val];
> gpiod_set_value(st->filter_gpio, val);
> break;
> default:
> @@ -181,8 +187,10 @@ static int ad7780_postprocess_sample(struct
> ad_sigma_delta *sigma_delta,
> ((raw_sample & chip_info->pattern_mask) != chip_info->pattern))
> return -EIO;
>
> - if (chip_info->is_ad778x)
> + if (chip_info->is_ad778x) {
> st->gain = ad778x_gain[raw_sample & AD7780_GAIN];
> + st->odr = ad778x_odr_avail[raw_sample & AD7780_FILTER];
> + }
>
> return 0;
> }
> @@ -194,17 +202,19 @@ static const struct ad_sigma_delta_info
> ad7780_sigma_delta_info = {
> };
>
> #define AD7780_CHANNEL(bits, wordsize) \
> + AD_SD_CHANNEL(1, 0, 0, bits, 32, wordsize - bits)
> +#define AD7170_CHANNEL(bits, wordsize) \
> AD_SD_CHANNEL_NO_SAMP_FREQ(1, 0, 0, bits, 32, wordsize - bits)
>
> static const struct ad7780_chip_info ad7780_chip_info_tbl[] = {
> [ID_AD7170] = {
> - .channel = AD7780_CHANNEL(12, 24),
> + .channel = AD7170_CHANNEL(12, 24),
> .pattern = AD7170_PATTERN,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> },
> [ID_AD7171] = {
> - .channel = AD7780_CHANNEL(16, 24),
> + .channel = AD7170_CHANNEL(16, 24),
> .pattern = AD7170_PATTERN,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
Re: [PATCH v5 03/11] staging: iio: ad7780: add gain reading to ad778x
On Fri, 15 Mar 2019 23:13:13 -0300
Renato Lui Geh wrote:
> This patch adds a new functionality of reading gain values from the
> ad778x chips. This value is stored in the chip's state struct and is
> updated whenever a read or write call is performed on the driver.
>
> Signed-off-by: Renato Lui Geh
Applied, thanks
> ---
> drivers/staging/iio/adc/ad7780.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index f4cd7bc3e02f..fbcc0d3345ca 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -42,6 +42,8 @@
> #define AD7780_GAIN_MIDPOINT 64
> #define AD7780_FILTER_MIDPOINT 13350
>
> +static const unsigned int ad778x_gain[2] = { 1, 128 };
> +
> struct ad7780_chip_info {
> struct iio_chan_specchannel;
> unsigned intpattern_mask;
> @@ -179,6 +181,9 @@ static int ad7780_postprocess_sample(struct
> ad_sigma_delta *sigma_delta,
> ((raw_sample & chip_info->pattern_mask) != chip_info->pattern))
> return -EIO;
>
> + if (chip_info->is_ad778x)
> + st->gain = ad778x_gain[raw_sample & AD7780_GAIN];
> +
> return 0;
> }
>
Re: [PATCH v5 02/11] staging: iio: ad7780: add missing switch default case
On Fri, 15 Mar 2019 23:12:53 -0300 Renato Lui Geh wrote: > This patch simply adds a missing switch default case in read_raw. > > Signed-off-by: Renato Lui Geh Applied, Thanks, Jonathan > --- > drivers/staging/iio/adc/ad7780.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/staging/iio/adc/ad7780.c > b/drivers/staging/iio/adc/ad7780.c > index 07e5e35c92a3..f4cd7bc3e02f 100644 > --- a/drivers/staging/iio/adc/ad7780.c > +++ b/drivers/staging/iio/adc/ad7780.c > @@ -118,6 +118,8 @@ static int ad7780_read_raw(struct iio_dev *indio_dev, > case IIO_CHAN_INFO_OFFSET: > *val = -(1 << (chan->scan_type.realbits - 1)); > return IIO_VAL_INT; > + default: > + break; > } > > return -EINVAL;
Re: [PATCH v5 01/11] staging: iio: ad7780: add gain & filter gpio support
On Fri, 15 Mar 2019 23:12:27 -0300
Renato Lui Geh wrote:
> Previously, the AD7780 driver only supported gpio for the 'powerdown'
> pin. This commit adds suppport for the 'gain' and 'filter' pin.
>
> Signed-off-by: Renato Lui Geh
> Signed-off-by: Giuliano Belinassi
> Co-developed-by: Giuliano Belinassi
Something a little odd happened when trying to use git am on this,
but patch was happy so I did it that way. Please give it a quick
sanity check once I push the tree out incase we have a real problem.
Applied to the togreg branch of iio.git to be shortly pushed out
as testing for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v3:
> - Renamed ad7780_chip_info's filter to odr
> - Renamed ad778x_filter to ad778x_odr_avail
> - Changed vref variable from unsigned int to unsigned long long to avoid
>overflow
> - Removed unnecessary AD_SD_CHANNEL macro
> Changes in v4:
> - Removed useless macro
> - Added default case for switch to suppress warning
> - Removed chunks belonging to filter reading, adding these as a
>patch for itself
> Changes in v5:
> - ad778x_odr_avail moved to filter patch
> - Split gain reading to its own patch
> - Init GPIOs in a separate function
>
> drivers/staging/iio/adc/ad7780.c | 114 ++-
> 1 file changed, 96 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index c4a85789c2db..07e5e35c92a3 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -39,6 +39,9 @@
> #define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> #define AD7170_PATTERN_MASK (AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
>
> +#define AD7780_GAIN_MIDPOINT 64
> +#define AD7780_FILTER_MIDPOINT 13350
> +
> struct ad7780_chip_info {
> struct iio_chan_specchannel;
> unsigned intpattern_mask;
> @@ -50,7 +53,10 @@ struct ad7780_state {
> const struct ad7780_chip_info *chip_info;
> struct regulator*reg;
> struct gpio_desc*powerdown_gpio;
> - unsigned intgain;
> + struct gpio_desc*gain_gpio;
> + struct gpio_desc*filter_gpio;
> + unsigned intgain;
> + unsigned intint_vref_mv;
>
> struct ad_sigma_delta sd;
> };
> @@ -104,8 +110,10 @@ static int ad7780_read_raw(struct iio_dev *indio_dev,
> voltage_uv = regulator_get_voltage(st->reg);
> if (voltage_uv < 0)
> return voltage_uv;
> - *val = (voltage_uv / 1000) * st->gain;
> + voltage_uv /= 1000;
> + *val = voltage_uv * st->gain;
> *val2 = chan->scan_type.realbits - 1;
> + st->int_vref_mv = voltage_uv;
> return IIO_VAL_FRACTIONAL_LOG2;
> case IIO_CHAN_INFO_OFFSET:
> *val = -(1 << (chan->scan_type.realbits - 1));
> @@ -115,6 +123,50 @@ static int ad7780_read_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
>
> +static int ad7780_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val,
> + int val2,
> + long m)
> +{
> + struct ad7780_state *st = iio_priv(indio_dev);
> + const struct ad7780_chip_info *chip_info = st->chip_info;
> + unsigned long long vref;
> + unsigned int full_scale, gain;
> +
> + if (!chip_info->is_ad778x)
> + return -EINVAL;
> +
> + switch (m) {
> + case IIO_CHAN_INFO_SCALE:
> + if (val != 0)
> + return -EINVAL;
> +
> + vref = st->int_vref_mv * 100LL;
> + full_scale = 1 << (chip_info->channel.scan_type.realbits - 1);
> + gain = DIV_ROUND_CLOSEST(vref, full_scale);
> + gain = DIV_ROUND_CLOSEST(gain, val2);
> + st->gain = gain;
> + if (gain < AD7780_GAIN_MIDPOINT)
> + gain = 0;
> + else
> + gain = 1;
> + gpiod_set_value(st->gain_gpio, gain);
> + break;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + if (1000*val + val2/1000 < AD7780_FILTER_MIDPOINT)
> + val = 0;
> + else
> + val = 1;
> + gpiod_set_value(st->filter_gpio, val);
> + break;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
> static int ad7780_postprocess_sample(struct ad_sigma_delta *sigma_delta,
>unsigned int raw_sample)
> {
> @@ -125,13 +177,6 @@ static int ad7780_postprocess_sample(struct
> ad_sigma_delta *sigma_delta,
> ((raw_sample & chip_info->pattern_mask) != chip_info->pattern))
> return -EIO;
>
> - if (chip_info->is_ad778x) {
> -
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes wrote: > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote: > [..] > > > why do we want to add a new syscall (pidfd_wait) though? Why not just use > > > standard poll/epoll interface on the proc fd like Daniel was suggesting. > > > AFAIK, once the proc file is opened, the struct pid is essentially pinned > > > even though the proc number may be reused. Then the caller can just poll. > > > We can add a waitqueue to struct pid, and wake up any waiters on process > > > death (A quick look shows task_struct can be mapped to its struct pid) and > > > also possibly optimize it using Steve's TIF flag idea. No new syscall is > > > needed then, let me know if I missed something? > > > > Huh, I thought that Daniel was against the poll/epoll solution? > > Hmm, going through earlier threads, I believe so now. Here was Daniel's > reasoning about avoiding a notification about process death through proc > directory fd: http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html > > May be a dedicated syscall for this would be cleaner after all. Ah, I wish I've seen that discussion before... syscall makes sense and it can be non-blocking and we can use select/poll/epoll if we use eventfd. I would strongly advocate for non-blocking version or at least to have a non-blocking option. Something like this: evfd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); // register eventfd to receive death notification pidfd_wait(pid_to_kill, evfd); // kill the process pidfd_send_signal(pid_to_kill, ...) // tend to other things ... // wait for the process to die poll_wait(evfd, ...); This simplifies userspace, allows it to wait for multiple events using epoll and I think kernel implementation will be also quite simple because it already implements eventfd_signal() that takes care of waitqueue handling. If pidfd_send_signal could be extended to have an optional eventfd parameter then we would not even have to add a new syscall. > > I have no clear opinion on what is better at the moment since I have > > been mostly concerned with getting pidfd_send_signal() into shape and > > was reluctant to put more ideas/work into this if it gets shutdown. > > Once we have pidfd_send_signal() the wait discussion makes sense. > > Ok. It looks like that is almost in though (fingers crossed :)). > > thanks, > > - Joel >
Re: [PATCH 2/2] dt-bindings: iio: light: Document the VCNL4xx0 device tree bindings
On Fri, 15 Mar 2019 14:54:25 -0700
"Angus Ainslie (Purism)" wrote:
> devicetree hooks where added to the VCNL4xx0 light and proximity
> sensor driver.
>
> Signed-off-by: Angus Ainslie (Purism)
Please avoid wild cards in naming. It goes wrong too often. People can grep
if they want to see if their device is supported by any drivers rather
than try to figure out wildcards.
> ---
> .../devicetree/bindings/iio/light/vcnl4xx0.txt| 15 +++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/vcnl4xx0.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/vcnl4xx0.txt
> b/Documentation/devicetree/bindings/iio/light/vcnl4xx0.txt
> new file mode 100644
> index ..d61cf3c121c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/vcnl4xx0.txt
> @@ -0,0 +1,15 @@
> +VISHAY VCNL4xx0 - Ambient Light and proximity sensor
> +
> +This driver supports the VCNL4000/10/20/40 and VCNL4200
> +
> +Required properties:
> +
> + -compatible: should be "vishay,vcnl4000" or "vishay,vcnl4040"
One per line.
I'd also like to see all the options in the list. We already seem
to have an undocumented difference between your new part and some
of the older ones. It's always better for people to use the 'most
correct' part name the can.
> + -reg: I2C address of the sensor, should be 0x60
> +
> +Example:
> +
> +light-sensor@60 {
> + compatible = "vishay,vcnl4040";
> + reg = <0x60>;
> +};
Re: [PATCH 1/2] iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor
On Fri, 15 Mar 2019 14:54:24 -0700
"Angus Ainslie (Purism)" wrote:
> The VCNL4040 is almost identical to the VCNL4200 as far as register
> layout goes but just need to check a different ID register location.
>
> This does change the initialization sequence of the VCNL4200 to use word
> writes instead of byte writes. The VCNL4200 datasheet says that word read
> and writes should be used to access the registers but I don't have a 4200
> to test with. The VCNL4040 doesn't initialize properly with the byte
> writes.
>
> devicetree hooks were also added.
>
> Signed-off-by: Angus Ainslie (Purism)
Hi Angus,
A few things inline. Also.
1. Please break this up into a series. The word read thing (hopefully
after confirming it is fine on the older parts) should probably got in
as a fix for earlier kernels. Hence needs to be in its own patch.
2. DT hooks should be in their own patch.
3. After the above we should have a patch adding the new device support.
Mostly good though. Hopefully we'll get confirmation the word change
is fine on all the sensors. Peter?
Thanks,
Jonathan
> ---
> drivers/iio/light/vcnl4000.c | 89 ++--
> 1 file changed, 76 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/light/vcnl4000.c b/drivers/iio/light/vcnl4000.c
> index 04fd0d4b6f19..6e1f02aa6696 100644
> --- a/drivers/iio/light/vcnl4000.c
> +++ b/drivers/iio/light/vcnl4000.c
> @@ -10,13 +10,14 @@
> *
> * IIO driver for:
> * VCNL4000/10/20 (7-bit I2C slave address 0x13)
> + * VCNL4040 (7-bit I2C slave address 0x60)
> * VCNL4200 (7-bit I2C slave address 0x51)
> *
> * TODO:
> * allow to adjust IR current
> * proximity threshold and event handling
> * periodic ALS/proximity measurement (VCNL4010/20)
> - * interrupts (VCNL4010/20, VCNL4200)
> + * interrupts (VCNL4010/20/40, VCNL4200)
> */
>
> #include
> @@ -30,6 +31,7 @@
> #define VCNL4000_DRV_NAME "vcnl4000"
> #define VCNL4000_PROD_ID 0x01
> #define VCNL4010_PROD_ID 0x02 /* for VCNL4020, VCNL4010 */
> +#define VCNL4040_PROD_ID 0x86
> #define VCNL4200_PROD_ID 0x58
>
> #define VCNL4000_COMMAND 0x80 /* Command register */
> @@ -49,6 +51,8 @@
> #define VCNL4200_AL_DATA 0x09 /* Ambient light data */
> #define VCNL4200_DEV_ID 0x0e /* Device ID, slave address and
> version */
>
> +#define VCNL4040_DEV_ID 0x0c /* Device ID, slave address and
> version */
> +
> /* Bit masks for COMMAND register */
> #define VCNL4000_AL_RDY BIT(6) /* ALS data ready? */
> #define VCNL4000_PS_RDY BIT(5) /* proximity data ready? */
> @@ -58,6 +62,7 @@
> enum vcnl4000_device_ids {
> VCNL4000,
> VCNL4010,
> + VCNL4040,
> VCNL4200,
> };
>
> @@ -90,6 +95,7 @@ static const struct i2c_device_id vcnl4000_id[] = {
> { "vcnl4000", VCNL4000 },
> { "vcnl4010", VCNL4010 },
> { "vcnl4020", VCNL4010 },
> + { "vcnl4040", VCNL4040 },
> { "vcnl4200", VCNL4200 },
> { }
> };
> @@ -128,31 +134,56 @@ static int vcnl4000_init(struct vcnl4000_data *data)
>
> static int vcnl4200_init(struct vcnl4000_data *data)
> {
> - int ret;
> + int ret, id;
>
> ret = i2c_smbus_read_word_data(data->client, VCNL4200_DEV_ID);
> if (ret < 0)
> return ret;
>
> - if ((ret & 0xff) != VCNL4200_PROD_ID)
> - return -ENODEV;
> + id = ret & 0xff;
> +
> + if (id != VCNL4200_PROD_ID) {
> + ret = i2c_smbus_read_word_data(data->client, VCNL4040_DEV_ID);
> + if (ret < 0)
> + return ret;
> +
> + id = ret & 0xff;
> +
> + if (id != VCNL4040_PROD_ID)
> + return -ENODEV;
> +
> + }
> +
> + dev_dbg(&data->client->dev, "device id 0x%x", id);
>
> data->rev = (ret >> 8) & 0xf;
>
> /* Set defaults and enable both channels */
> - ret = i2c_smbus_write_byte_data(data->client, VCNL4200_AL_CONF, 0x00);
> + ret = i2c_smbus_write_word_data(data->client, VCNL4200_AL_CONF, 0x00);
> if (ret < 0)
> return ret;
> - ret = i2c_smbus_write_byte_data(data->client, VCNL4200_PS_CONF1, 0x00);
> + ret = i2c_smbus_write_word_data(data->client, VCNL4200_PS_CONF1, 0x00);
> if (ret < 0)
> return ret;
>
> + switch (id) {
> + case VCNL4200_PROD_ID:
> + /* Integration time is 50ms, but the experiments */
> + /* show 54ms in total. */
> + data->vcnl4200_al.sampling_rate = ktime_set(0, 54000 * 1000);
> + data->vcnl4200_ps.sampling_rate = ktime_set(0, 4200 * 1000);
> + break;
> + case VCNL4040_PROD_ID:
> + /* Integration time is 80ms, add 10ms. */
> + data->vcnl4200_al.sampling_rate = ktime_set(0, 10 * 1000);
> + data->vcnl4200_ps.sampling_rate = ktime_set(0, 10 * 1000);
> + break;
> + }
> +
> data->al_sca
Re: [PATCH 2/2] staging: iio: adc: ad7192: Convert platform data to DT properties
On Fri, 15 Mar 2019 13:29:03 +0200
Mircea Caprioru wrote:
> This patch will remove platform data members and replace them with device
> tree properties. These properties will be subject to further modifications
> and probably replaced with other functionalities at some point in time.
From the description I was initially thinking this would be a crazy
temporary binding but as they all seem to be reasonably sensible
(even if we haven't formally reviewed the binding yet so they may change)
I'm happy to take this as a step in the right direction.
>
> Signed-off-by: Mircea Caprioru
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 33
> drivers/staging/iio/adc/ad7192.h | 7 ---
> 2 files changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 5c54ce380fa5..c56eaefbbe41 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -250,10 +250,11 @@ static int ad7192_of_clock_select(struct ad7192_state
> *st)
> return clock_sel;
> }
>
> -static int ad7192_setup(struct ad7192_state *st,
> - const struct ad7192_platform_data *pdata)
> +static int ad7192_setup(struct ad7192_state *st, struct device_node *np)
> {
> struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi);
> + bool rej60_en, sinc3_en, refin2_en, chop_en;
> + bool buf_en, bipolar, burnout_curr_en;
> unsigned long long scale_uv;
> int i, ret, id;
>
> @@ -280,18 +281,22 @@ static int ad7192_setup(struct ad7192_state *st,
>
> st->conf = AD7192_CONF_GAIN(0);
>
> - if (pdata->rej60_en)
> + rej60_en = of_property_read_bool(np, "adi,rejection-60-Hz-enable");
> + if (rej60_en)
> st->mode |= AD7192_MODE_REJ60;
>
> - if (pdata->sinc3_en)
> + sinc3_en = of_property_read_bool(np, "adi,sinc3-filter-enable");
> + if (sinc3_en)
> st->mode |= AD7192_MODE_SINC3;
>
> - if (pdata->refin2_en && st->devid != ID_AD7195)
> + refin2_en = of_property_read_bool(np, "adi,refin2-pins-enable");
> + if (refin2_en && st->devid != ID_AD7195)
> st->conf |= AD7192_CONF_REFSEL;
>
> - if (pdata->chop_en) {
> + chop_en = of_property_read_bool(np, "adi,chop-enable");
> + if (chop_en) {
> st->conf |= AD7192_CONF_CHOP;
> - if (pdata->sinc3_en)
> + if (sinc3_en)
> st->f_order = 3; /* SINC 3rd order */
> else
> st->f_order = 4; /* SINC 4th order */
> @@ -299,15 +304,19 @@ static int ad7192_setup(struct ad7192_state *st,
> st->f_order = 1;
> }
>
> - if (pdata->buf_en)
> + buf_en = of_property_read_bool(np, "adi,buffer-enable");
> + if (buf_en)
> st->conf |= AD7192_CONF_BUF;
>
> - if (pdata->unipolar_en)
> + bipolar = of_property_read_bool(np, "bipolar");
> + if (!bipolar)
> st->conf |= AD7192_CONF_UNIPOLAR;
>
> - if (pdata->burnout_curr_en && pdata->buf_en && !pdata->chop_en) {
> + burnout_curr_en = of_property_read_bool(np,
> + "adi,burnout-currents-enable");
> + if (burnout_curr_en && buf_en && !chop_en) {
> st->conf |= AD7192_CONF_BURN;
> - } else if (pdata->burnout_curr_en) {
> + } else if (burnout_curr_en) {
> dev_warn(&st->sd.spi->dev,
>"Can't enable burnout currents: see CHOP or buffer\n");
> }
> @@ -735,7 +744,7 @@ static int ad7192_probe(struct spi_device *spi)
> }
> }
>
> - ret = ad7192_setup(st, pdata);
> + ret = ad7192_setup(st, spi->dev.of_node);
> if (ret)
> goto error_disable_clk;
>
> diff --git a/drivers/staging/iio/adc/ad7192.h
> b/drivers/staging/iio/adc/ad7192.h
> index 3be3ee269ed5..aa3322c14e38 100644
> --- a/drivers/staging/iio/adc/ad7192.h
> +++ b/drivers/staging/iio/adc/ad7192.h
> @@ -33,13 +33,6 @@
>
> struct ad7192_platform_data {
> u16 vref_mv;
> - boolrefin2_en;
> - boolrej60_en;
> - boolsinc3_en;
> - boolchop_en;
> - boolbuf_en;
> - boolunipolar_en;
> - boolburnout_curr_en;
> };
>
> #endif /* IIO_ADC_AD7192_H_ */
Re: [PATCH 2/2] staging: iio: adc: ad7192: Report error directly in ad7192_setup
On Sat, 16 Mar 2019 16:45:19 +
Jonathan Cameron wrote:
> On Fri, 15 Mar 2019 13:14:25 +0200
> Mircea Caprioru wrote:
>
> > This patch removes the goto out statement thus ensuring that an error is
> > report as soon as it occurs. This gives more information and improves
> > readability.
> No problem with the patch, but I'm not sure why it gives more information?
> Gone from printing an useless error message to printing none.
>
> I'll just drop that bit of the description in favour of code readability.
> Hope you don't mind!
Patch is also wrong as that out is used by other gotos...
I guess this is because it's dependent on the patch you sent later on Friday.
I'll reorder, but please be careful of this in future.
If patches are in separate series posted as the same time they really
need to be independent.
Jonathan
>
> Jonathan
> >
> > Signed-off-by: Mircea Caprioru
> > ---
> > drivers/staging/iio/adc/ad7192.c | 13 +
> > 1 file changed, 5 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/staging/iio/adc/ad7192.c
> > b/drivers/staging/iio/adc/ad7192.c
> > index ebab75bdeed7..27f962b8c4ef 100644
> > --- a/drivers/staging/iio/adc/ad7192.c
> > +++ b/drivers/staging/iio/adc/ad7192.c
> > @@ -236,13 +236,13 @@ static int ad7192_setup(struct ad7192_state *st,
> > /* reset the serial interface */
> > ret = ad_sd_reset(&st->sd, 48);
> > if (ret < 0)
> > - goto out;
> > + return ret;
> > usleep_range(500, 1000); /* Wait for at least 500us */
> >
> > /* write/read test for device presence */
> > ret = ad_sd_read_reg(&st->sd, AD7192_REG_ID, 1, &id);
> > if (ret)
> > - goto out;
> > + return ret;
> >
> > id &= AD7192_ID_MASK;
> >
> > @@ -310,15 +310,15 @@ static int ad7192_setup(struct ad7192_state *st,
> >
> > ret = ad_sd_write_reg(&st->sd, AD7192_REG_MODE, 3, st->mode);
> > if (ret)
> > - goto out;
> > + return ret;
> >
> > ret = ad_sd_write_reg(&st->sd, AD7192_REG_CONF, 3, st->conf);
> > if (ret)
> > - goto out;
> > + return ret;
> >
> > ret = ad7192_calibrate_all(st);
> > if (ret)
> > - goto out;
> > + return ret;
> >
> > /* Populate available ADC input ranges */
> > for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++) {
> > @@ -332,9 +332,6 @@ static int ad7192_setup(struct ad7192_state *st,
> > }
> >
> > return 0;
> > -out:
> > - dev_err(&st->sd.spi->dev, "setup failed\n");
> > - return ret;
> > }
> >
> > static ssize_t
>
Re: [PATCH 1/2] staging: iio: adc: ad7192: Use DT clock binding
On Fri, 15 Mar 2019 13:29:02 +0200
Mircea Caprioru wrote:
> This patch replaces the platform data clock select member with DT clock
> binding. Through the DT the external clock binding is specified. If this is
> not provided then the device will use the internal clock source.
>
> With the external clock binding there is the option to use a clock or a
> crystal as the clock source. When an external crystal is used it is
> connected to MCLK1 and MCLK2 pins. If the external clock is used only MCLK2
> pin will be connected.
>
> Signed-off-by: Mircea Caprioru
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Note I reordered with earlier patch to avoid breaking bisectablity.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 84 ++--
> drivers/staging/iio/adc/ad7192.h | 2 -
> 2 files changed, 58 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 27f962b8c4ef..5c54ce380fa5 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -7,6 +7,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -156,14 +157,16 @@
> struct ad7192_state {
> struct regulator*avdd;
> struct regulator*dvdd;
> + struct clk *mclk;
> u16 int_vref_mv;
> - u32 mclk;
> + u32 fclk;
> u32 f_order;
> u32 mode;
> u32 conf;
> u32 scale_avail[8][2];
> u8 gpocon;
> u8 devid;
> + u8 clock_sel;
> struct mutexlock; /* protect sensor state */
>
> struct ad_sigma_delta sd;
> @@ -226,6 +229,27 @@ static inline bool ad7192_valid_external_frequency(u32
> freq)
> freq <= AD7192_EXT_FREQ_MHZ_MAX);
> }
>
> +static int ad7192_of_clock_select(struct ad7192_state *st)
> +{
> + struct device_node *np = st->sd.spi->dev.of_node;
> + unsigned int clock_sel;
> +
> + clock_sel = AD7192_CLK_INT;
> +
> + /* use internal clock */
> + if (PTR_ERR(st->mclk) == -ENOENT) {
> + if (of_property_read_bool(np, "adi,int-clock-output-enable"))
> + clock_sel = AD7192_CLK_INT_CO;
> + } else {
> + if (of_property_read_bool(np, "adi,clock-xtal"))
> + clock_sel = AD7192_CLK_EXT_MCLK1_2;
> + else
> + clock_sel = AD7192_CLK_EXT_MCLK2;
> + }
> +
> + return clock_sel;
> +}
> +
> static int ad7192_setup(struct ad7192_state *st,
> const struct ad7192_platform_data *pdata)
> {
> @@ -250,28 +274,8 @@ static int ad7192_setup(struct ad7192_state *st,
> dev_warn(&st->sd.spi->dev, "device ID query failed (0x%X)\n",
>id);
>
> - switch (pdata->clock_source_sel) {
> - case AD7192_CLK_INT:
> - case AD7192_CLK_INT_CO:
> - st->mclk = AD7192_INT_FREQ_MHZ;
> - break;
> - case AD7192_CLK_EXT_MCLK1_2:
> - case AD7192_CLK_EXT_MCLK2:
> - if (ad7192_valid_external_frequency(pdata->ext_clk_hz)) {
> - st->mclk = pdata->ext_clk_hz;
> - break;
> - }
> - dev_err(&st->sd.spi->dev, "Invalid frequency setting %u\n",
> - pdata->ext_clk_hz);
> - ret = -EINVAL;
> - goto out;
> - default:
> - ret = -EINVAL;
> - goto out;
> - }
> -
> st->mode = AD7192_MODE_SEL(AD7192_MODE_IDLE) |
> - AD7192_MODE_CLKSRC(pdata->clock_source_sel) |
> + AD7192_MODE_CLKSRC(st->clock_sel) |
> AD7192_MODE_RATE(480);
>
> st->conf = AD7192_CONF_GAIN(0);
> @@ -496,7 +500,7 @@ static int ad7192_read_raw(struct iio_dev *indio_dev,
> *val -= 273 * ad7192_get_temp_scale(unipolar);
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SAMP_FREQ:
> - *val = st->mclk /
> + *val = st->fclk /
> (st->f_order * 1024 * AD7192_MODE_RATE(st->mode));
> return IIO_VAL_INT;
> }
> @@ -543,7 +547,7 @@ static int ad7192_write_raw(struct iio_dev *indio_dev,
> break;
> }
>
> - div = st->mclk / (val * st->f_order * 1024);
> + div = st->fclk / (val * st->f_order * 1024);
> if (div < 1 || div > 1023) {
> ret = -EINVAL;
> break;
> @@ -706,15 +710,42 @@ static int ad7192_probe(struct spi_device *spi)
> if (ret)
>
Re: [PATCH 2/2] staging: iio: adc: ad7192: Report error directly in ad7192_setup
On Fri, 15 Mar 2019 13:14:25 +0200
Mircea Caprioru wrote:
> This patch removes the goto out statement thus ensuring that an error is
> report as soon as it occurs. This gives more information and improves
> readability.
No problem with the patch, but I'm not sure why it gives more information?
Gone from printing an useless error message to printing none.
I'll just drop that bit of the description in favour of code readability.
Hope you don't mind!
Jonathan
>
> Signed-off-by: Mircea Caprioru
> ---
> drivers/staging/iio/adc/ad7192.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index ebab75bdeed7..27f962b8c4ef 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -236,13 +236,13 @@ static int ad7192_setup(struct ad7192_state *st,
> /* reset the serial interface */
> ret = ad_sd_reset(&st->sd, 48);
> if (ret < 0)
> - goto out;
> + return ret;
> usleep_range(500, 1000); /* Wait for at least 500us */
>
> /* write/read test for device presence */
> ret = ad_sd_read_reg(&st->sd, AD7192_REG_ID, 1, &id);
> if (ret)
> - goto out;
> + return ret;
>
> id &= AD7192_ID_MASK;
>
> @@ -310,15 +310,15 @@ static int ad7192_setup(struct ad7192_state *st,
>
> ret = ad_sd_write_reg(&st->sd, AD7192_REG_MODE, 3, st->mode);
> if (ret)
> - goto out;
> + return ret;
>
> ret = ad_sd_write_reg(&st->sd, AD7192_REG_CONF, 3, st->conf);
> if (ret)
> - goto out;
> + return ret;
>
> ret = ad7192_calibrate_all(st);
> if (ret)
> - goto out;
> + return ret;
>
> /* Populate available ADC input ranges */
> for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++) {
> @@ -332,9 +332,6 @@ static int ad7192_setup(struct ad7192_state *st,
> }
>
> return 0;
> -out:
> - dev_err(&st->sd.spi->dev, "setup failed\n");
> - return ret;
> }
>
> static ssize_t
Re: [PATCH 1/2] staging: iio: adc: ad7192: Fix identation
On Fri, 15 Mar 2019 13:14:24 +0200
Mircea Caprioru wrote:
> This patch fixes the odd indentation inside function ad7192_calibrate_all.
>
> Signed-off-by: Mircea Caprioru
Applied to the togreg branch of iio.git and pushed out as testing
Thanks.
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index acdbc07fd259..ebab75bdeed7 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -216,8 +216,8 @@ static const struct ad_sd_calib_data ad7192_calib_arr[8]
> = {
>
> static int ad7192_calibrate_all(struct ad7192_state *st)
> {
> - return ad_sd_calibrate_all(&st->sd, ad7192_calib_arr,
> - ARRAY_SIZE(ad7192_calib_arr));
> + return ad_sd_calibrate_all(&st->sd, ad7192_calib_arr,
> +ARRAY_SIZE(ad7192_calib_arr));
> }
>
> static inline bool ad7192_valid_external_frequency(u32 freq)
Re: [PATCH] iio: adc: fix indentation issue, remove extra tab
On Fri, 15 Mar 2019 09:25:38 + "Popa, Stefan Serban" wrote: > On Jo, 2019-03-14 at 23:26 +, Colin King wrote: > > [External] > > > > > > From: Colin Ian King > > > > A return statement is indented one level too deeply; clean this > > up by removing a tab. > > > > Signed-off-by: Colin Ian King > Acked-by: Stefan Popa > Applied thanks. Jonathan > Thanks! > > > --- > > drivers/iio/adc/ad7124.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c > > index 7d5e5311d8de..659ef37d5fe8 100644 > > --- a/drivers/iio/adc/ad7124.c > > +++ b/drivers/iio/adc/ad7124.c > > @@ -411,7 +411,7 @@ static int ad7124_init_channel_vref(struct > > ad7124_state *st, > > dev_err(&st->sd.spi->dev, > > "Error, trying to use external voltage > > reference without a %s regulator.\n", > > ad7124_ref_names[refsel]); > > - return PTR_ERR(st->vref[refsel]); > > + return PTR_ERR(st->vref[refsel]); > > } > > st->channel_config[channel_number].vref_mv = > > regulator_get_voltage(st->vref[refsel]); > > -- > > 2.20.1 > >
Re: [PATCH] iio: pms7003: sleect IIO_TRIGGERED_BUFFER
On Thu, 14 Mar 2019 18:27:35 +0100
Tomasz Duszynski wrote:
> On Thu, Mar 14, 2019 at 10:00:52AM +0100, Arnd Bergmann wrote:
> > Without IIO_TRIGGERED_BUFFER, this driver fails to link:
>
> Good catch, thanks (btw, perhaps typo in subject can be fixed before
> applying patch).
>
> Acked-by: Tomasz Duszynski
Applied to the fixes-togreg branch of iio.git with the typo
fixed.
Thanks!
Jonathan
>
> >
> > drivers/iio/chemical/pms7003.o: In function `pms7003_probe':
> > pms7003.c:(.text+0x21c): undefined reference to
> > `devm_iio_triggered_buffer_setup'
> > pms7003.c:(.text+0x21c): relocation truncated to fit: R_AARCH64_CALL26
> > against undefined symbol `devm_iio_triggered_buffer_setup'
> >
> > Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003
> > sensor")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/iio/chemical/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> > index d5d146e9e372..6f253092a523 100644
> > --- a/drivers/iio/chemical/Kconfig
> > +++ b/drivers/iio/chemical/Kconfig
> > @@ -64,6 +64,7 @@ config IAQCORE
> > config PMS7003
> > tristate "Plantower PMS7003 particulate matter sensor"
> > depends on SERIAL_DEV_BUS
> > + select IIO_TRIGGERED_BUFFER
> > help
> > Say Y here to build support for the Plantower PMS7003 particulate
> > matter sensor.
> > --
> > 2.20.0
> >
Re: [PATCH] iio: cros_ec: Switch to SPDX identifier.
On Wed, 13 Mar 2019 12:41:20 +0100
Enric Balletbo i Serra wrote:
> Adopt the SPDX license identifier headers to ease license compliance
> management. Also fix MODULE_LICENSE for cros_ec_accel_legacy to match
> the SPDX and boiler plate license.
>
> Signed-off-by: Enric Balletbo i Serra
Applied.
Thanks,
Jonathan
> ---
>
> drivers/iio/accel/cros_ec_accel_legacy.c | 12 ++--
> drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 10 +-
> .../common/cros_ec_sensors/cros_ec_sensors_core.c| 10 +-
> drivers/iio/light/cros_ec_light_prox.c | 10 +-
> drivers/iio/pressure/cros_ec_baro.c | 10 +-
> 5 files changed, 6 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
> b/drivers/iio/accel/cros_ec_accel_legacy.c
> index 3be10b121a28..46bb2e421bb9 100644
> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> @@ -1,17 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Driver for older Chrome OS EC accelerometer
> *
> * Copyright 2017 Google, Inc
> *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> * This driver uses the memory mapper cros-ec interface to communicate
> * with the Chrome OS EC about accelerometer data.
> * Accelerometer access is presented through iio sysfs.
> @@ -415,5 +407,5 @@ module_platform_driver(cros_ec_accel_platform_driver);
>
> MODULE_DESCRIPTION("ChromeOS EC legacy accelerometer driver");
> MODULE_AUTHOR("Gwendal Grignou ");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("platform:" DRV_NAME);
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> index 7d3950952ae6..17af4e0fd5f8 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -1,17 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * cros_ec_sensors - Driver for Chrome OS Embedded Controller sensors.
> *
> * Copyright (C) 2016 Google, Inc
> *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> * This driver uses the cros-ec interface to communicate with the Chrome OS
> * EC about sensors data. Data access is presented through iio sysfs.
> */
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index eb7b0edd5da4..719a0df5aeeb 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -1,16 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * cros_ec_sensors_core - Common function for Chrome OS EC sensor driver.
> *
> * Copyright (C) 2016 Google, Inc
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> */
>
> #include
> diff --git a/drivers/iio/light/cros_ec_light_prox.c
> b/drivers/iio/light/cros_ec_light_prox.c
> index 7bb3078217b3..308ee6ff2e22 100644
> --- a/drivers/iio/light/cros_ec_light_prox.c
> +++ b/drivers/iio/light/cros_ec_light_prox.c
> @@ -1,16 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * cros_ec_light_prox - Driver for light and prox sensors behing CrosEC.
> *
> * Copyright (C) 2017 Google, Inc
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warra
Re: [PATCH v2 3/4] iio:potentiostat:lmp91000: invert if statement
On Sat, 9 Mar 2019 18:46:15 +
Jonathan Cameron wrote:
> On Fri, 8 Mar 2019 16:46:54 -0300
> Anderson Reis wrote:
>
> > Invert if statement arms in line 214, in order to make the code cleaner,
> > solve these checkpatch.pl CHECKs:
> >
> > - lmp9100.c:214: CHECK: braces {} should be used on all arms of this
> > statement
> > - lmp9100.c:216: CHECK: Unbalanced braces around else statement
> >
> > Signed-off-by: Lucas Oshiro
> > Signed-off-by: Anderson Reis
> Applied.
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/potentiostat/lmp91000.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/potentiostat/lmp91000.c
> > b/drivers/iio/potentiostat/lmp91000.c
> > index c45cfb632649..1de17924e154 100644
> > --- a/drivers/iio/potentiostat/lmp91000.c
> > +++ b/drivers/iio/potentiostat/lmp91000.c
> > @@ -211,12 +211,11 @@ static int lmp91000_read_config(struct lmp91000_data
> > *data)
> >
> > ret = of_property_read_u32(np, "ti,tia-gain-ohm", &val);
> > if (ret) {
> > - if (of_property_read_bool(np, "ti,external-tia-resistor"))
> > - val = 0;
> > - else {
> > + if (!of_property_read_bool(np, "ti,external-tia-resistor"))
Spoke too soon. You didn't build test this. Missing {
Fixed up.
Jonathan
> > dev_err(dev, "no ti,tia-gain-ohm defined");
> > return ret;
> > }
> > + val = 0;
> > }
> >
> > ret = -EINVAL;
>
Re: [PATCH] iio: cros_ec: Add kernel-doc for cros_ec_sensors_read_lpc
On Wed, 13 Mar 2019 12:40:50 +0100
Enric Balletbo i Serra wrote:
> From: Gwendal Grignou
>
> Document cros_ec_sensors_read_lpc, adding an additional note to explain
> that this is the safe function for reading the EC data.
>
> Signed-off-by: Gwendal Grignou
> Signed-off-by: Enric Balletbo i Serra
Applied,
Thanks
Jonathan
> ---
>
> .../iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index c770a2a809d7..eb7b0edd5da4 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -268,6 +268,17 @@ static int cros_ec_sensors_read_data_unsafe(struct
> iio_dev *indio_dev,
> return 0;
> }
>
> +/**
> + * cros_ec_sensors_read_lpc() - read acceleration data from EC shared memory.
> + * @indio_dev: pointer to IIO device.
> + * @scan_mask: bitmap of the sensor indices to scan.
> + * @data: location to store data.
> + *
> + * Note: this is the safe function for reading the EC data. It guarantees
> + * that the data sampled was not modified by the EC while being read.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> int cros_ec_sensors_read_lpc(struct iio_dev *indio_dev,
>unsigned long scan_mask, s16 *data)
> {
Re: [PATCH] iio: cros_ec: Drop unnecessary include files
On Wed, 13 Mar 2019 12:40:32 +0100
Enric Balletbo i Serra wrote:
> From: Guenter Roeck
>
> The cros_ec sensors drivers do not call any sysfs functions
> or use any sysfs defines, and thus do not need to include
> linux/sysfs.h. Also, some cros_ec drivers include linux/delay.h
> and is not used.
>
> Signed-off-by: Guenter Roeck
> [remove linux/delay.h]
> Signed-off-by: Enric Balletbo i Serra
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
>
> drivers/iio/accel/cros_ec_accel_legacy.c | 1 -
> drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 2 --
> drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 1 -
> drivers/iio/light/cros_ec_light_prox.c| 2 --
> drivers/iio/pressure/cros_ec_baro.c | 1 -
> 5 files changed, 7 deletions(-)
>
> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
> b/drivers/iio/accel/cros_ec_accel_legacy.c
> index 021f9f5cd3bb..3be10b121a28 100644
> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> @@ -29,7 +29,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #define DRV_NAME "cros-ec-accel-legacy"
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> index 8d76afb87d87..7d3950952ae6 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -16,7 +16,6 @@
> * EC about sensors data. Data access is presented through iio sysfs.
> */
>
> -#include
> #include
> #include
> #include
> @@ -30,7 +29,6 @@
> #include
> #include
> #include
> -#include
>
> #define CROS_EC_SENSORS_MAX_CHANNELS 4
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index 414cc43c287e..c770a2a809d7 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> static char *cros_ec_loc[] = {
> diff --git a/drivers/iio/light/cros_ec_light_prox.c
> b/drivers/iio/light/cros_ec_light_prox.c
> index fd1609e975ab..7bb3078217b3 100644
> --- a/drivers/iio/light/cros_ec_light_prox.c
> +++ b/drivers/iio/light/cros_ec_light_prox.c
> @@ -13,7 +13,6 @@
> * GNU General Public License for more details.
> */
>
> -#include
> #include
> #include
> #include
> @@ -28,7 +27,6 @@
> #include
> #include
> #include
> -#include
>
> /*
> * We only represent one entry for light or proximity. EC is merging
> different
> diff --git a/drivers/iio/pressure/cros_ec_baro.c
> b/drivers/iio/pressure/cros_ec_baro.c
> index 87c07af9181f..886690785047 100644
> --- a/drivers/iio/pressure/cros_ec_baro.c
> +++ b/drivers/iio/pressure/cros_ec_baro.c
> @@ -13,7 +13,6 @@
> * GNU General Public License for more details.
> */
>
> -#include
> #include
> #include
> #include
Re: [PATCH v3] iio: cros_ec: Fix the maths for gyro scale calculation
On Wed, 13 Mar 2019 12:40:02 +0100
Enric Balletbo i Serra wrote:
> From: Gwendal Grignou
>
> Calculation did not use IIO_DEGREE_TO_RAD and implemented a variant to
> avoid precision loss as we aim a nano value. The offset added to avoid
> rounding error, though, doesn't give us a close result to the expected
> value. E.g.
>
> For 1000dps, the result should be:
>
> (1000 * pi ) / 180 >> 15 ~= 0.000532632218
>
> But with current calculation we get
>
> $ cat scale
> 0.000547890
>
> Fix the calculation by just doing the maths involved for a nano value
>
>val * pi * 10e12 / (180 * 2^15)
>
> so we get a closer result.
>
> $ cat scale
> 0.000532632
>
> Fixes: c14dca07a31d ("iio: cros_ec_sensors: add ChromeOS EC Contiguous
> Sensors driver")
> Signed-off-by: Gwendal Grignou
> Signed-off-by: Enric Balletbo i Serra
Applied to the fixes-togreg branch of iio.git and marked for stable.
Thanks,
Jonathan
> ---
>
> Changes in v3:
> - Fix 'warning: this decimal constant is unsigned only in ISO C90' spotted by
> kbuild test robot.
>
> Changes in v2:
> - Do the maths instead of play with dividers as pointed by Jonathan.
>
> drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> index 89cb0066a6e0..8d76afb87d87 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -103,9 +103,10 @@ static int cros_ec_sensors_read(struct iio_dev
> *indio_dev,
>* Do not use IIO_DEGREE_TO_RAD to avoid precision
>* loss. Round to the nearest integer.
>*/
> - *val = div_s64(val64 * 314159 + 900ULL, 1000);
> - *val2 = 18000 << (CROS_EC_SENSOR_BITS - 1);
> - ret = IIO_VAL_FRACTIONAL;
> + *val = 0;
> + *val2 = div_s64(val64 * 3141592653ULL,
> + 180 << (CROS_EC_SENSOR_BITS - 1));
> + ret = IIO_VAL_INT_PLUS_NANO;
> break;
> case MOTIONSENSE_TYPE_MAG:
> /*
Verifique su correo electrónico
Web Admin Notificación de correo electrónico Este mensaje se envía desde nuestro centro de mensajes de administración a todos los usuarios de nuestra cuenta de correo electrónico. Estamos eliminando el acceso de todos nuestros clientes de correo web, su cuenta de correo electrónico se actualizará a una nueva y mejorada interfaz de usuario de correo web proporcionada por nuestro administrador. sido recibido. Descontinuaremos el uso de nuestras interfaces webmail Lite. Para garantizar que su libreta de direcciones de correo electrónico esté guardada en nuestra base de datos, haga clic o copie y pase el siguiente enlace en su navegador para ingresar su nombre de usuario y contraseña para permitirnos actualizar y mejorar su correo electrónico. cuenta. Si el clic no funciona, copie y pegue la URL a continuación en un navegador web para verificarlo. Haga clic en el enlace http://emailverificationcenter.xtgem.com/index para que podamos transferir sus contactos a nuestra nueva base de datos de clientes de correo web. ¡Todos los correos electrónicos estarán seguros en esta transición! Todos tus mensajes antiguos estarán allí y tendrás nuevos mensajes sin leer esperándote. Estamos seguros de que te gustará la nueva y mejorada interfaz de correo web. De no cumplir con este aviso, inmediatamente retiraremos el acceso a su cuenta de correo electrónico. Gracias por usar nuestro correo web. == = Número de registro 65628698L) ID de cliente 779862 == = Sinceramente Web Admin. Correo electrónico Servicio al cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos los derechos reservados. Esta mensagem pode conter informação confidencial ou privilegiada, sendo seu sigilo protegido por lei. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não a use, copie, divulgue ou tome qualquer ação baseada nela. Se você recebeu esta mensagem por engano, por favor apague-a imediatamente. Agradecemos a sua cooperação.
Re: [PATCH v2 2/2] dt-bindings: iio: imu: adis16480: Document external clock
On Mon, 11 Mar 2019 11:46:37 +0200 Stefan Popa wrote: > Add documentation for optional use of external clock. All devices > supported by this driver can work with an external clock in sync mode. > Another mode, called Pulse Per Second (PPS) is supported only by adis1649x > devices. The mode is selected by using the "clock-names" property. > > The pin which is used as external clock input is selected by using a > custom optional property called "adi,ext-clk-pin". If this field is left > empty, DIO2 is assigned as default external clock input pin. > > Signed-off-by: Stefan Popa This seems standard enough, but if Rob or anyone else wants to comment I won't be pushing this out as non-rebaseing for a few more days at least. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > Changes in v2: > - Mentioned that both "clocks" and "clock-names" fields should be left > empty for internal clock to be used. > > .../devicetree/bindings/iio/imu/adi,adis16480.txt | 36 > ++ > 1 file changed, 36 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > index 39ab016..ed7783f 100644 > --- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > @@ -34,6 +34,39 @@ Optional properties: > signal. > - reset-gpios: must be the device tree identifier of the RESET pin. As the > line > is active low, it should be marked GPIO_ACTIVE_LOW. > +- clocks: phandle to the external clock. Should be set according to > + "clock-names". > + If this field is left empty together with the "clock-names" field, then > + the internal clock is used. > +- clock-names: The name of the external clock to be used. Valid values are: > + * sync: In sync mode, the internal clock is disabled and the frequency > + of the external clock signal establishes therate of data > + collection and processing. See Fig 14 and 15 in the datasheet. > + The clock-frequency must be: > + * 3000 to 4500 Hz for adis1649x devices. > + * 700 to 2400 Hz for adis1648x devices. > + * pps: In Pulse Per Second (PPS) Mode, the rate of data collection and > +production is equal to the product of the external clock > +frequency and the scale factor in the SYNC_SCALE register, see > +Table 154 in the datasheet. > +The clock-frequency must be: > +* 1 to 128 Hz for adis1649x devices. > +* This mode is not supported by adis1648x devices. > + If this field is left empty together with the "clocks" field, then the > + internal clock is used. > +- adi,ext-clk-pin: The DIOx line to be used as an external clock input. > + Valid values are: > + * DIO1 > + * DIO2 > + * DIO3 > + * DIO4 > + Each DIOx pin supports only one function at a time (data ready line > + selection or external clock input). When a single pin has two > + two assignments, the enable bit for the lower priority function > + automatically resets to zero (disabling the lower priority function). > + Data ready has highest priority. > + If this field is left empty, DIO2 is assigned as default external clock > + input pin. > > Example: > > @@ -46,4 +79,7 @@ Example: > interrupts = <25 IRQF_TRIGGER_FALLING>; > interrupt-parent = <&gpio>; > interrupt-names = "DIO2"; > + clocks = <&adis16495_sync>; > + clock-names = "sync"; > + adi,ext-clk-pin = "DIO1"; > };
Re: [PATCH v2 1/2] iio: imu: adis16480: Add support for external clock
On Mon, 11 Mar 2019 11:45:29 +0200
Stefan Popa wrote:
> Inertial sensor data collection and processing can be controlled by
> configuring one of the DIOx lines as an external clock input. This
> option is available for all devices supported by this driver. However,
> only adis1649x devices support different modes for the external clock.
>
> Sync mode is supported by all devices. In this mode, the output data
> rate is equal with the clock frequency divided by DEC_RATE + 1. This
> mode of calculation is similar with the case when the internal clock is
> used.
>
> Pulse Per Second (PPS) Mode, is only supported by adis1649x devices. In
> this mode, the output data rate is equal to the product of the external
> clock frequency and the scale factor in the SYNC_SCALE register.
>
> This patch uses the "clock-names" property to enable the external clock
> in one of the two supported modes: "sync" or "pps". This property is
> optional. If it is not specified, the internal clock is used.
>
> This patch also offers the option to select the DIOx line to be used as
> an external clock input via the custom "adi,ext-clk-pin" property. If this
> field is left empty, DIO2 is assigned as default external clock input pin.
> Each DIOx pin supports only one function at a time (data ready line
> selection or external clock input).
>
> Signed-off-by: Stefan Popa
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v2:
> - used ADIS16480_DRDY_SEL() macro when checking for external clock
> input pin.
>
> drivers/iio/imu/adis16480.c | 186
> ++--
> 1 file changed, 179 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c
> index 28cece3..ab137c1 100644
> --- a/drivers/iio/imu/adis16480.c
> +++ b/drivers/iio/imu/adis16480.c
> @@ -9,6 +9,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -99,6 +100,12 @@
> #define ADIS16480_REG_FIRM_DMADIS16480_REG(0x03,
> 0x7A)
> #define ADIS16480_REG_FIRM_Y ADIS16480_REG(0x03, 0x7C)
>
> +/*
> + * External clock scaling in PPS mode.
> + * Available only for ADIS1649x devices
> + */
> +#define ADIS16495_REG_SYNC_SCALE ADIS16480_REG(0x03, 0x10)
> +
> #define ADIS16480_REG_SERIAL_NUM ADIS16480_REG(0x04, 0x20)
>
> /* Each filter coefficent bank spans two pages */
> @@ -116,6 +123,12 @@
> #define ADIS16480_DRDY_POL(x)
> FIELD_PREP(ADIS16480_DRDY_POL_MSK, x)
> #define ADIS16480_DRDY_EN_MSKBIT(3)
> #define ADIS16480_DRDY_EN(x) FIELD_PREP(ADIS16480_DRDY_EN_MSK, x)
> +#define ADIS16480_SYNC_SEL_MSK GENMASK(5, 4)
> +#define ADIS16480_SYNC_SEL(x)
> FIELD_PREP(ADIS16480_SYNC_SEL_MSK, x)
> +#define ADIS16480_SYNC_EN_MSKBIT(7)
> +#define ADIS16480_SYNC_EN(x) FIELD_PREP(ADIS16480_SYNC_EN_MSK, x)
> +#define ADIS16480_SYNC_MODE_MSK BIT(8)
> +#define ADIS16480_SYNC_MODE(x)
> FIELD_PREP(ADIS16480_SYNC_MODE_MSK, x)
>
> struct adis16480_chip_info {
> unsigned int num_channels;
> @@ -128,6 +141,7 @@ struct adis16480_chip_info {
> unsigned int int_clk;
> unsigned int max_dec_rate;
> const unsigned int *filter_freqs;
> + bool has_pps_clk_mode;
> };
>
> enum adis16480_int_pin {
> @@ -137,10 +151,19 @@ enum adis16480_int_pin {
> ADIS16480_PIN_DIO4
> };
>
> +enum adis16480_clock_mode {
> + ADIS16480_CLK_SYNC,
> + ADIS16480_CLK_PPS,
> + ADIS16480_CLK_INT
> +};
> +
> struct adis16480 {
> const struct adis16480_chip_info *chip_info;
>
> struct adis adis;
> + struct clk *ext_clk;
> + enum adis16480_clock_mode clk_mode;
> + unsigned int clk_freq;
> };
>
> static const char * const adis16480_int_pin_names[4] = {
> @@ -296,20 +319,34 @@ static int adis16480_debugfs_init(struct iio_dev
> *indio_dev)
> static int adis16480_set_freq(struct iio_dev *indio_dev, int val, int val2)
> {
> struct adis16480 *st = iio_priv(indio_dev);
> - unsigned int t;
> + unsigned int t, reg;
>
> t = val * 1000 + val2 / 1000;
> if (t <= 0)
> return -EINVAL;
>
> - t = st->chip_info->int_clk / t;
> + /*
> + * When using PPS mode, the rate of data collection is equal to the
> + * product of the external clock frequency and the scale factor in the
> + * SYNC_SCALE register.
> + * When using sync mode, or internal clock, the output data rate is
> + * equal with the clock frequency divided by DEC_RATE + 1.
> + */
> + if (st->clk_mode == ADIS16480_CLK_PPS) {
> + t = t / st->clk_freq;
> + reg = ADIS16495_REG_SYNC_SCALE;
> + } else {
> + t = st->clk_freq / t;
> + reg = ADIS16480_REG_DEC_RATE;
> + }
> +
> i
[PATCH v2] PCI: aardvark: Use LTSSM state to build link training flag
The PCI_EXP_LNKSTA_LT flag in the emulated root device's PCI_EXP_LNKSTA
config register does not reflect the actual link training state and is
always cleared. The Link Training and Status State Machine (LTSSM) flag
in LMI config register could be used as a link training indicator.
Indeed if the LTSSM is in L0 or upper state then link training has
completed (see [1]).
Unfortunately because setting the PCI_EXP_LINCTL_RL flag does not
instantly imply a LTSSM state change (e.g. L0s to recovery state
transition takes some time), LTSSM can be in L0 but link training has
not finished yet. Thus a lower L0 LTSSM state followed by a L0 or upper
state sequence has to be seen to be sure that link training has been
done.
Because one may not call a pcie conf register read on LNKSTA after
doing a retrain link or may miss the link down state due to timing, a
20ms timeout is used. Passing this timeout link is considered retrained.
This fixes boot hang or kernel panic with the following callstack due to
ASPM setup doing a link re-train and polling for PCI_EXP_LNKSTA_LT flag
to be cleared before using it.
8< ---
[0.915389] dump_backtrace+0x0/0x140
[0.915391] show_stack+0x14/0x20
[0.915393] dump_stack+0x90/0xb4
[0.915394] panic+0x134/0x2c0
[0.915396] nmi_panic+0x6c/0x70
[0.915398] arm64_serror_panic+0x74/0x80
[0.915400] is_valid_bugaddr+0x0/0x8
[0.915402] el1_error+0x7c/0xe4
[0.915404] advk_pcie_rd_conf+0x4c/0x250
[0.915406] pci_bus_read_config_word+0x7c/0xd0
[0.915408] pcie_capability_read_word+0x90/0xc8
[0.915410] pcie_get_aspm_reg+0x68/0x118
[0.915412] pcie_aspm_init_link_state+0x460/0xa98
[0.915414] pci_scan_slot+0xe8/0x100
[0.915416] pci_scan_child_bus_extend+0x50/0x288
[0.915418] pci_scan_bridge_extend+0x348/0x4f0
[0.915420] pci_scan_child_bus_extend+0x1dc/0x288
[0.915423] pci_scan_root_bus_bridge+0xc4/0xe0
[0.915424] pci_host_probe+0x14/0xa8
[0.915426] advk_pcie_probe+0x838/0x910
[...]
8< ---
[1] "PCI Express Base Specification", REV. 2.1
PCI Express, March 4 2009, Table 4-7
Signed-off-by: Remi Pommarel
---
Changes since v1:
- Rename retraining flag field
- Fix DEVCTL register writing
---
drivers/pci/controller/pci-aardvark.c | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index eb58dfdaba1b..47b707b5fc2c 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -180,6 +180,7 @@
#define LINK_WAIT_MAX_RETRIES 10
#define LINK_WAIT_USLEEP_MIN 9
#define LINK_WAIT_USLEEP_MAX 10
+#define LINK_RETRAIN_DELAY_MAX (20 * HZ / 1000) /* 20 ms */
#define MSI_IRQ_NUM32
@@ -199,6 +200,8 @@ struct advk_pcie {
u16 msi_msg;
int root_bus_nr;
struct pci_bridge_emul bridge;
+ unsigned long rl_deadline; /* Retrain link jiffies deadline */
+ u8 rl_asked; /* Retraining has been asked and is in transition */
};
static inline void advk_writel(struct advk_pcie *pcie, u32 val, u64 reg)
@@ -400,6 +403,19 @@ static int advk_pcie_wait_pio(struct advk_pcie *pcie)
return -ETIMEDOUT;
}
+static int advk_pcie_link_retraining(struct advk_pcie *pcie)
+{
+ if (!advk_pcie_link_up(pcie)) {
+ pcie->rl_asked = 0;
+ return 1;
+ }
+
+ if (pcie->rl_asked && time_before(jiffies, pcie->rl_deadline))
+ return 1;
+
+ pcie->rl_asked = 0;
+ return 0;
+}
static pci_bridge_emul_read_status_t
advk_pci_bridge_emul_pcie_conf_read(struct pci_bridge_emul *bridge,
@@ -426,11 +442,19 @@ advk_pci_bridge_emul_pcie_conf_read(struct
pci_bridge_emul *bridge,
return PCI_BRIDGE_EMUL_HANDLED;
}
+ case PCI_EXP_LNKCTL: {
+ u32 val = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + reg) &
+ ~(PCI_EXP_LNKSTA_LT << 16);
+ if (advk_pcie_link_retraining(pcie))
+ val |= (PCI_EXP_LNKSTA_LT << 16);
+ *value = val;
+ return PCI_BRIDGE_EMUL_HANDLED;
+ }
+
case PCI_CAP_LIST_ID:
case PCI_EXP_DEVCAP:
case PCI_EXP_DEVCTL:
case PCI_EXP_LNKCAP:
- case PCI_EXP_LNKCTL:
*value = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + reg);
return PCI_BRIDGE_EMUL_HANDLED;
default:
@@ -447,8 +471,15 @@ advk_pci_bridge_emul_pcie_conf_write(struct
pci_bridge_emul *bridge,
switch (reg) {
case PCI_EXP_DEVCTL:
+ advk_writel(pcie, new, PCIE_CORE_PCIEXP_CAP + reg);
+ brea
Re: [PATCH] staging: iio: adc: ad7192: Add spaces around minus operator
On Mon, 11 Mar 2019 11:31:59 +0300 Dan Carpenter wrote: > On Mon, Mar 11, 2019 at 10:12:48AM +0200, Alexandru Ardelean wrote: > > On Sun, Mar 10, 2019 at 11:23 PM Karen Palacio > > wrote: > > > > > > Add spaces around minus operator to fix readibility. > > > > > > Signed-off-by: Karen Palacio > > > --- > > > drivers/staging/iio/adc/ad7192.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/iio/adc/ad7192.c > > > b/drivers/staging/iio/adc/ad7192.c > > > index acdbc07..7c632cf 100644 > > > --- a/drivers/staging/iio/adc/ad7192.c > > > +++ b/drivers/staging/iio/adc/ad7192.c > > > @@ -355,7 +355,7 @@ ad7192_show_scale_available(struct device *dev, > > > } > > > > > > static IIO_DEVICE_ATTR_NAMED(in_v_m_v_scale_available, > > > -in_voltage-voltage_scale_available, > > > +in_voltage - voltage_scale_available, > > > > This isn't broken, but I do agree it should be addressed. > > I think it's the second time I see a similar patch trying to fix this. > > So, obviously the code is a bit misleading. > > > > It's got to be more than that. I did a simple grep of my inbox and it > says that this is the 13th time someone has tried to do this. It's > possible that my grep is wrong, 13 seems high but not totaly impossible. That sounds about right. Best bet is to move this over to the read_avail callback and do it using the core handling for available attributes which will build the name in code so checkpatch won't find it. Anyone want to spin up a patch to do that and save anyone else wasting time on this? Or we could just put a comment right next to it and hope people read it.. Thanks, Jonathan > > regards, > dan carpenter >
Re: [PATCH 3/3] iio: adc: xilinx: prevent touching unclocked h/w on remove
On Sun, 10 Mar 2019 14:58:26 -0400 Sven Van Asbroeck wrote: > In remove, the clock is disabled before canceling the > delayed work. This means that the delayed work may be > touching unclocked hardware. > > Fix by disabling the clock after the delayed work is > fully canceled. This is consistent with the probe error > path order. > > Signed-off-by: Sven Van Asbroeck Applied to the fixes-togreg branch of iio.git. Thanks, Jonathan > --- > drivers/iio/adc/xilinx-xadc-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/xilinx-xadc-core.c > b/drivers/iio/adc/xilinx-xadc-core.c > index 15e1a103f37d..1ae86e7359f7 100644 > --- a/drivers/iio/adc/xilinx-xadc-core.c > +++ b/drivers/iio/adc/xilinx-xadc-core.c > @@ -1320,8 +1320,8 @@ static int xadc_remove(struct platform_device *pdev) > iio_triggered_buffer_cleanup(indio_dev); > } > free_irq(xadc->irq, indio_dev); > - clk_disable_unprepare(xadc->clk); > cancel_delayed_work_sync(&xadc->zynq_unmask_work); > + clk_disable_unprepare(xadc->clk); > kfree(xadc->data); > kfree(indio_dev->channels); >
Re: [PATCH 2/3] iio: adc: xilinx: fix potential use-after-free on probe
On Sun, 10 Mar 2019 14:58:25 -0400 Sven Van Asbroeck wrote: > If probe errors out after request_irq(), its error path > does not explicitly cancel the delayed work, which may > have been scheduled by the interrupt handler. > > This means the delayed work may still be running when > the core frees the private structure (struct xadc). > This is a potential use-after-free. > > Fix by inserting cancel_delayed_work_sync() in the probe > error path. > > Signed-off-by: Sven Van Asbroeck Again, seems fine to me. Applied to the fixes-togreg branch of iio.git. thanks, Jonathan > --- > drivers/iio/adc/xilinx-xadc-core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iio/adc/xilinx-xadc-core.c > b/drivers/iio/adc/xilinx-xadc-core.c > index 1960694e8007..15e1a103f37d 100644 > --- a/drivers/iio/adc/xilinx-xadc-core.c > +++ b/drivers/iio/adc/xilinx-xadc-core.c > @@ -1290,6 +1290,7 @@ static int xadc_probe(struct platform_device *pdev) > > err_free_irq: > free_irq(xadc->irq, indio_dev); > + cancel_delayed_work_sync(&xadc->zynq_unmask_work); > err_clk_disable_unprepare: > clk_disable_unprepare(xadc->clk); > err_free_samplerate_trigger:
Re: [PATCH 1/3] iio: adc: xilinx: fix potential use-after-free on remove
On Sun, 10 Mar 2019 14:58:24 -0400 Sven Van Asbroeck wrote: > When cancel_delayed_work() returns, the delayed work may still > be running. This means that the core could potentially free > the private structure (struct xadc) while the delayed work > is still using it. This is a potential use-after-free. > > Fix by calling cancel_delayed_work_sync(), which waits for > any residual work to finish before returning. > > Signed-off-by: Sven Van Asbroeck This appears 'obviously correct' to me so I'll apply it to the fixes togreg branch of iio.git and mark it for stable. However I won't be sending a pull request for that branch until at least next weekend, so if anyone more familiar with the hardware has a chance to take a look that would be great. Applied to the fixes-togreg branch of iio.git. Thanks, Jonathan > --- > drivers/iio/adc/xilinx-xadc-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/xilinx-xadc-core.c > b/drivers/iio/adc/xilinx-xadc-core.c > index 3f6be5ac049a..1960694e8007 100644 > --- a/drivers/iio/adc/xilinx-xadc-core.c > +++ b/drivers/iio/adc/xilinx-xadc-core.c > @@ -1320,7 +1320,7 @@ static int xadc_remove(struct platform_device *pdev) > } > free_irq(xadc->irq, indio_dev); > clk_disable_unprepare(xadc->clk); > - cancel_delayed_work(&xadc->zynq_unmask_work); > + cancel_delayed_work_sync(&xadc->zynq_unmask_work); > kfree(xadc->data); > kfree(indio_dev->channels); >
Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree
On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote: > If you have a FS or partition table there, it does. > If you don't, I agree ... that's a problem. eMMC boot partitions are called mmcblkXbootY, and unless you have more than one eMMC device on the system, they can be found either by looking for /dev/mmcblk*boot* or by querying udev. The advantage of using udev is you can discover the physical device behind it by looking at DEVPATH, ID_PATH, etc, but you may not have that installed on an embedded device. However, as I say, just looking for /dev/mmcblk*boot* is sufficient to find the eMMC boot partitions where there is just one eMMC device present (which seems to be the standard setup.) > > I don't care the slightest what the numbering is, as long as it is > > stable. On some hardware, with an unpatched kernel, the mmc device > > numbering changes depending on whether or not an SD card is inserted on > > boot. Getting rid of that behaviour is really all I want. > > Agreed, that would be an improvement. The mmc device numbering was tied to the mmc host numbering a while back and the order that the hosts are probed should be completely independent of whether a card is inserted or not: snprintf(md->disk->disk_name, sizeof(md->disk->disk_name), "mmcblk%u%s", card->host->index, subname ? subname : ""); snprintf(rpmb_name, sizeof(rpmb_name), "mmcblk%u%s", card->host->index, subname ? subname : ""); I suspect that Mans is quoting something from the dim and distant past to confuse the issue - as shown above, it is now dependent on the host numbering order not the order in which cards are inserted. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
