[PATCH] fpga: dfl: use driver core functions, not sysfs ones.
This is a driver, do not call "raw" sysfs functions, instead call driver
core ones. Specifically convert the use of sysfs_create_files() and
sysfs_remove_files() to use device_add_groups() and
device_remove_groups()
Cc: Wu Hao
Cc: Alan Tull
Cc: Moritz Fischer
Cc: linux-f...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/fpga/dfl-afu-main.c | 14 --
drivers/fpga/dfl-fme-main.c | 7 ---
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 02baa6a227c0..68b4d0874b93 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -141,10 +141,11 @@ id_show(struct device *dev, struct device_attribute
*attr, char *buf)
}
static DEVICE_ATTR_RO(id);
-static const struct attribute *port_hdr_attrs[] = {
+static struct attribute *port_hdr_attrs[] = {
_attr_id.attr,
NULL,
};
+ATTRIBUTE_GROUPS(port_hdr);
static int port_hdr_init(struct platform_device *pdev,
struct dfl_feature *feature)
@@ -153,7 +154,7 @@ static int port_hdr_init(struct platform_device *pdev,
port_reset(pdev);
- return sysfs_create_files(>dev.kobj, port_hdr_attrs);
+ return device_add_groups(>dev, port_hdr_groups);
}
static void port_hdr_uinit(struct platform_device *pdev,
@@ -161,7 +162,7 @@ static void port_hdr_uinit(struct platform_device *pdev,
{
dev_dbg(>dev, "PORT HDR UInit.\n");
- sysfs_remove_files(>dev.kobj, port_hdr_attrs);
+ device_remove_groups(>dev, port_hdr_groups);
}
static long
@@ -214,10 +215,11 @@ afu_id_show(struct device *dev, struct device_attribute
*attr, char *buf)
}
static DEVICE_ATTR_RO(afu_id);
-static const struct attribute *port_afu_attrs[] = {
+static struct attribute *port_afu_attrs[] = {
_attr_afu_id.attr,
NULL
};
+ATTRIBUTE_GROUPS(port_afu);
static int port_afu_init(struct platform_device *pdev,
struct dfl_feature *feature)
@@ -234,7 +236,7 @@ static int port_afu_init(struct platform_device *pdev,
if (ret)
return ret;
- return sysfs_create_files(>dev.kobj, port_afu_attrs);
+ return device_add_groups(>dev, port_afu_groups);
}
static void port_afu_uinit(struct platform_device *pdev,
@@ -242,7 +244,7 @@ static void port_afu_uinit(struct platform_device *pdev,
{
dev_dbg(>dev, "PORT AFU UInit.\n");
- sysfs_remove_files(>dev.kobj, port_afu_attrs);
+ device_remove_groups(>dev, port_afu_groups);
}
static const struct dfl_feature_ops port_afu_ops = {
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 086ad2420ade..0be4635583d5 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -72,12 +72,13 @@ static ssize_t bitstream_metadata_show(struct device *dev,
}
static DEVICE_ATTR_RO(bitstream_metadata);
-static const struct attribute *fme_hdr_attrs[] = {
+static struct attribute *fme_hdr_attrs[] = {
_attr_ports_num.attr,
_attr_bitstream_id.attr,
_attr_bitstream_metadata.attr,
NULL,
};
+ATTRIBUTE_GROUPS(fme_hdr);
static int fme_hdr_init(struct platform_device *pdev,
struct dfl_feature *feature)
@@ -89,7 +90,7 @@ static int fme_hdr_init(struct platform_device *pdev,
dev_dbg(>dev, "FME cap %llx.\n",
(unsigned long long)readq(base + FME_HDR_CAP));
- ret = sysfs_create_files(>dev.kobj, fme_hdr_attrs);
+ ret = device_add_groups(>dev, fme_hdr_groups);
if (ret)
return ret;
@@ -100,7 +101,7 @@ static void fme_hdr_uinit(struct platform_device *pdev,
struct dfl_feature *feature)
{
dev_dbg(>dev, "FME HDR UInit.\n");
- sysfs_remove_files(>dev.kobj, fme_hdr_attrs);
+ device_remove_groups(>dev, fme_hdr_groups);
}
static const struct dfl_feature_ops fme_hdr_ops = {
--
2.22.0
Re: [PATCH 2/2] ftrace/selftest: Test if set_event/ftrace_pid exists before writing
On Wed, 3 Jul 2019 22:01:05 -0400
Steven Rostedt wrote:
> On Thu, 4 Jul 2019 10:51:26 +0900
> Masami Hiramatsu wrote:
>
> > > > diff --git a/tools/testing/selftests/ftrace/test.d/functions
> > > > b/tools/testing/selftests/ftrace/test.d/functions
> > > > index 779ec11f61bd..a7b06291e32c 100644
> > > > --- a/tools/testing/selftests/ftrace/test.d/functions
> > > > +++ b/tools/testing/selftests/ftrace/test.d/functions
> > > > @@ -91,8 +91,8 @@ initialize_ftrace() { # Reset ftrace to initial-state
> > > > reset_events_filter
> > > > reset_ftrace_filter
> > > > disable_events
> > > > -echo > set_event_pid # event tracer is always on
> > > > -echo > set_ftrace_pid
> > > > +[ -f set_event_pid ] && echo > set_event_pid # event tracer is
> > > > always on
> > >
> > > I probably should remove that comment, because I believe that was why
> > > it wasn't tested :-/
> >
> > Hmm, OK. I think this comment means "the event tracer is always on if
> > clearing
> > set_event_pid filter". Would this need to be removed?
>
> When this was added in commit 131f840d5b7 ("selftests: ftrace:
> Initialize ftrace before each test"), we had this:
>
> +echo > set_event_pid # event tracer is always on
> +[ -f set_ftrace_filter ] && echo | tee set_ftrace_*
> +[ -f set_graph_function ] && echo | tee set_graph_*
> +[ -f stack_trace_filter ] && echo > stack_trace_filter
> +[ -f kprobe_events ] && echo > kprobe_events
> +[ -f uprobe_events ] && echo > uprobe_events
>
> Where set_event_pid is the only file not tested for existence. I
> figured that comment was the reason for not testing it. If that was the
> case, then adding a test, I would think we should remove the comment.
Ah, I see.
>
> Do you agree?
Yes, I agree with removing it.
Thank you!
>
> -- Steve
>
>
> >
> > Thank you,
> >
> > >
> > > -- Steve
> > >
> > >
> > > > +[ -f set_ftrace_pid ] && echo > set_ftrace_pid
> > > > [ -f set_ftrace_filter ] && echo | tee set_ftrace_*
> > > > [ -f set_graph_function ] && echo | tee set_graph_*
> > > > [ -f stack_trace_filter ] && echo > stack_trace_filter
> > >
> >
> >
>
--
Masami Hiramatsu
Re: [PATCH RFC 0/3] Support CPU hotplug for ARM64
Hi Xiongfeng On 2019/7/4 11:26, Xiongfeng Wang wrote: Hi Justin, On 2019/7/4 11:00, Jia He wrote: Hi Xiongfeng It is a little bit awkful that I am also investigating acpi based cpu hotplug issue silimar with your idea. My question is your purpose to implement the vcpu hotplug in arm64 qemu? Yes, my purpose is to implement the vcpu hotplug in arm64 qemu. So that I can add or remove vcpu without shutting down the Guest OS. Thanks for the infor, I guess you used GED device in qemu ;-)? --- Cheers, Justin (Jia He)
Re: [PATCH] checkpatch: avoid default n
On Wed, 2019-07-03 at 08:37 -0700, Joe Perches wrote: > On Wed, 2019-07-03 at 17:03 +0800, Yingjoe Chen wrote: > > On Wed, 2019-07-03 at 01:42 -0700, Joe Perches wrote: > > > On Wed, 2019-07-03 at 16:30 +0800, Miles Chen wrote: > > > > This change reports a warning when "default n" is used. > > > > > > > > I have seen several "remove default n" patches, so I think > > > > it might be helpful to add this test in checkpatch. > > > > DEFAULT_VALUE_STYLE > > > > tested: > > > > WARNING: 'default n' is the default value, no need to write it > > > > explicitly. > > > > + default n > > > > > > I don't think this is reasonable as there are > > > several uses like: > > > > > > default y > > > default n if > > > > > > For instance: > > > > > > arch/alpha/Kconfig-config ALPHA_WTINT > > > arch/alpha/Kconfig- bool "Use WTINT" if ALPHA_SRM || ALPHA_GENERIC > > > arch/alpha/Kconfig- default y if ALPHA_QEMU > > > arch/alpha/Kconfig: default n if ALPHA_EV5 || ALPHA_EV56 || > > > (ALPHA_EV4 && !ALPHA_LCA) > > > arch/alpha/Kconfig: default n if !ALPHA_SRM && !ALPHA_GENERIC > > > > Hi, > > > > > > I've sent similar patch in 2016, my version won't complain about these. > > > > https://lkml.org/lkml/2016/4/22/580 > > Hi again. > > https://lore.kernel.org/lkml/1461259011.1918.23.ca...@perches.com/ > > I would prefer a generic solution that also handles the > quoted use. > > $ git grep -P 'default\s*\"[ynm]"' -- '*/Kconfig*' > arch/mips/Kconfig: default "y" > arch/mips/Kconfig: default "y" > arch/mips/Kconfig: default "y" > arch/mips/Kconfig: default "y" > arch/mips/cavium-octeon/Kconfig:default "n" > arch/mips/cavium-octeon/Kconfig:default "y" > arch/mips/cavium-octeon/Kconfig:default "y" > arch/mips/cavium-octeon/Kconfig:default "y" > arch/mips/cavium-octeon/Kconfig:default "y" > arch/mips/cavium-octeon/Kconfig:default "y" > arch/mips/cavium-octeon/Kconfig:default "y" > arch/powerpc/Kconfig: default "y" if PPC_POWERNV > arch/powerpc/Kconfig: default "y" if PPC_POWERNV > arch/powerpc/Kconfig: default "n" > drivers/auxdisplay/Kconfig: default "n" > drivers/crypto/Kconfig: default "m" > drivers/rapidio/devices/Kconfig:default "n" > > or maybe 2 separate patches. > > And the "default y" case and probably the > "default \!?EXPERT" is or should be generally > discouraged. Especially for drivers. > > https://lore.kernel.org/lkml/CAHk-=wiz24juvehj5sec0ug1gk2nvb363wo02rrsr1oeht6...@mail.gmail.com/ > > Thanks for your comment, I'll send another patch for these cases: 1. default "[ynm]" 2. default \!?EXPERT 3. default n$
Re: [PATCH v1 OPT1] driver core: Fix use-after-free and double free on glue directory
On Thu, Jul 04, 2019 at 08:57:53AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2019-07-03 at 21:37 +0200, Greg KH wrote: > > Ok, I guess I have to take this patch, as the other one is so bad :) > > > > But, I need a very large comment here saying why we are poking around in > > a kref and why we need to do this, at the expense of anything else. > > > > So can you respin this patch with a comment here to help explain it so > > we have a chance to understand it when we run across this line in 10 > > years? > > Also are we confident that an open dir on the glue dir from userspace > won't keep the kref up ? How do you "open" a directory which raises the kref? thanks, greg k-h
Re: [PATCH v4 OPT2] driver core: Fix use-after-free and double free on glue directory
On Thu, Jul 04, 2019 at 08:57:13AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2019-07-03 at 21:36 +0200, Greg KH wrote: > > > > > -static struct kobject *get_device_parent(struct device *dev, > > > - struct device *parent) > > > +/** > > > + * __get_device_parent() - Get the parent device kobject. > > > + * @dev: Pointer to the device structure. > > > + * @parent: Pointer to the parent device structure. > > > + * @lock: When we live in a glue directory, should we hold the > > > + *gdp_mutex lock when this function returns? If @lock > > > + *is true, this function returns with the gdp_mutex > > > + *holed. Otherwise it will not. > > > > Ugh, if you are trying to get me to hate one version of these patches, > > this is how you do it :) > > > > A function should not "sometimes takes a lock, sometimes does not, > > depending on a parameter passed into it" That way lies madness... > > Yes, I prefer this approach to the fix but I dont like the patch either > for the same reason... > > ... > > > Anyway, this is a mess. > > > > Ugh I hate glue dirs... > > Amen... Well, can we just remove them? Who relies on them anymore? thanks, greg k-h
Re: [PATCH v2 1/2] ASoC: tas5720.c: cleanup variant management
On Wed, 3 Jul 2019, Andrew F. Davis wrote:
On 7/2/19 6:12 AM, Nikolaus Voss wrote:
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 11:35 AM, Nikolaus Voss wrote:
On Mon, 1 Jul 2019, Andrew F. Davis wrote:
On 7/1/19 9:42 AM, Nikolaus Voss wrote:
Replace enum tas572x_type with struct tas5720_variant which aggregates
variant specific stuff and can be directly referenced from an id
table.
Signed-off-by: Nikolaus Voss
---
sound/soc/codecs/tas5720.c | 98
+-
1 file changed, 33 insertions(+), 65 deletions(-)
diff --git a/sound/soc/codecs/tas5720.c b/sound/soc/codecs/tas5720.c
index 37fab8f22800..b2e897f094b4 100644
--- a/sound/soc/codecs/tas5720.c
+++ b/sound/soc/codecs/tas5720.c
@@ -28,9 +28,10 @@
/* Define how often to check (and clear) the fault status register
(in ms) */
#define TAS5720_FAULT_CHECK_INTERVAL 200
-enum tas572x_type {
- TAS5720,
- TAS5722,
+struct tas5720_variant {
+ const int device_id;
+ const struct regmap_config *reg_config;
+ const struct snd_soc_component_driver *comp_drv;
};
static const char * const tas5720_supply_names[] = {
@@ -44,7 +45,7 @@ struct tas5720_data {
struct snd_soc_component *component;
struct regmap *regmap;
struct i2c_client *tas5720_client;
- enum tas572x_type devtype;
+ const struct tas5720_variant *variant;
Why add a new struct? Actually I don't see the need for this patch at
all, the commit message only explains the 'what' not the 'why'. We can
and do already build this info from the tas572x_type.
As the commit message says, the purpose is to aggregate the variant
specifics and make it accessible via one pointer. This is a standard
approach for of/acpi_device_id tables and thus makes the code simpler
and improves readability. This is a maintenance patch to prepare using
the device match API in a proper way.
"make it accessible via one pointer" is again a "what", the "why" is:
"This is a standard approach"
"makes the code simpler and improves readability"
Those are valid reasons and should be what you put in the commit message.
ok
Also below are several functional changes, the cover letter says
this is
not a functional change, yet the driver behaves differently now.
Can you be a little bit more specific? The code should behave exactly as
before.
Sure, for instance the line "unexpected private driver data" is removed,
this can now never happen, that is a functional change. The phrase "no
functional change", should be reserved for only changes to spelling,
formatting, code organizing, etc..
"unexpected private driver data" was unreachable code before, but you're
right, debug output has changed a little, but the functional part is
exactly the same.
Niko
Andrew
struct regulator_bulk_data supplies[TAS5720_NUM_SUPPLIES];
struct delayed_work fault_check_work;
unsigned int last_fault;
@@ -179,17 +180,13 @@ static int tas5720_set_dai_tdm_slot(struct
snd_soc_dai *dai,
goto error_snd_soc_component_update_bits;
/* Configure TDM slot width. This is only applicable to
TAS5722. */
- switch (tas5720->devtype) {
- case TAS5722:
+ if (tas5720->variant->device_id == TAS5722_DEVICE_ID) {
I also don't like this, TAS5722_DEVICE_ID is the expected contents of a
register, you are using it like the enum tas572x_type that you removed.
I'd leave that enum, the device ID register itself is not guaranteed to
be correct or unique, which is why we warn about mismatches below but
then continue to use the user provided device type anyway.
Strange, with me it's the other way round, I don't like the enum. The
mismatch behavior hasn't changed a bit, the same warning is printed. If
the device ID is no longer unique in the future (apparently it is for
now) the driver should explicitly handle this instead of printing a
warning, because warnings should be reserved for an indication of any
kind of misconfiguration and not of expected behavior.
That said the variant struct can of course replace the enum in every
aspect, even for what you describe above. The enum was an ordinal
representation of the user-selected i2c_device_id, the variant struct* is
a pointer representation of the user-selected i2c/of/acpi_device_id. The
only difference is that it directly points to the variant specific parts
of the driver instead of resolving those via multiple switch/case
statements.
The enum identifies the device type, easy as that, if you want to
instead do all the logic switching on some internal ID register value
code then make a patch for just that and explain what is gained. Don't
do that into this one.
I don't do and I don't want to. The struct pointer identifies the device
type the same way as the enum does. I guess we better leave things as they
are. Anyway, thanks for your time and effort.
Nikolaus
Re: [PATCH 4.19 00/72] 4.19.57-stable review
Tested and booted in my x86 system. No regressions.
Re: [PATCH 5.1 00/55] 5.1.16-stable review
Tested and booted on my x86 system. No regressions.
Re: [PATCH 4.14 00/43] 4.14.132-stable review
Booted and tested in my x86 systems. No regressions.
pci memory resources not being assigned to bridge
Hi, I'm in the process of updating our products from a 4.4 based kernel to 5.1 (and probably 5.2 since that release is imminent). On one product which uses a Freescale/NXP P2041 CPU, IDT pcie bridge and Marvell switch chip[1]. Annoyingly the hardware has a reset line that holds the switch chip in reset but the bridge chip has a separate reset line that is not held high by default. So when the system starts up the initial scan sees the bridge and assigns resource to its end points. Later once the switch chip reset is released (either via a gpio-hog or manually) and the bus rescanned the switch devices are detected but the host side of the pci bridge isn't assigned any memory space so pci accesses trigger a master abort which on that SoC leads to a machine check exception. [root@linuxbox ~]# uname -a Linux linuxbox 5.2.0-rc7-at1+ #8 SMP Thu Jul 4 04:26:18 UTC 2019 ppc GNU/Linu[root@linuxbox ~]# lspci -t -+-[2000:00]---00.0-[01-06]00.0-[02-06]--+-02.0-[03]-- | +-03.0-[04]-- | +-04.0-[05]-- | \-05.0-[06]-- \-[:00]- [root@linuxbox ~]# lspci -v -s 2000:01:00 2000:01:00.0 Class 0604: Device 111d:803e (rev 0e) Flags: bus master, fast devsel, latency 0 Bus: primary=01, secondary=02, subordinate=06, sec-latency=0 I/O behind bridge: None Memory behind bridge: None Prefetchable memory behind bridge: None Capabilities: [40] Express Upstream Port, MSI 00 Capabilities: [c0] Power Management version 3 Capabilities: [100] Advanced Error Reporting Capabilities: [200] Virtual Channel Kernel driver in use: pcieport [root@linuxbox ~]# echo 472 >/sys/class/gpio/export [root@linuxbox ~]# echo out >/sys/class/gpio/gpio472/direction [root@linuxbox ~]# echo 0 >/sys/class/gpio/gpio472/value [root@linuxbox ~]# echo 1 >/sys/bus/pci/rescan pci 2000:03:00.0: [11ab:e097] type 00 class 0x058000 pci 2000:03:00.0: reg 0x10: [mem 0xd000-0xd00f 64bit pref] pci 2000:03:00.0: reg 0x18: [mem 0x-0x03ff 64bit] pci 2000:03:00.0: Adding to iommu group 15 pci_bus 2000:03: busn_res: [bus 03] end is updated to 03 pci 2000:04:00.0: [11ab:e097] type 00 class 0x058000 pci 2000:04:00.0: reg 0x10: [mem 0xd000-0xd00f 64bit pref] pci 2000:04:00.0: reg 0x18: [mem 0x-0x03ff 64bit] pci 2000:04:00.0: Adding to iommu group 15 pci_bus 2000:04: busn_res: [bus 04] end is updated to 04 pci 2000:05:00.0: [11ab:e097] type 00 class 0x058000 pci 2000:05:00.0: reg 0x10: [mem 0xd000-0xd00f 64bit pref] pci 2000:05:00.0: reg 0x18: [mem 0x-0x03ff 64bit] pci 2000:05:00.0: Adding to iommu group 15 pci_bus 2000:05: busn_res: [bus 05] end is updated to 05 pci 2000:06:00.0: [11ab:e097] type 00 class 0x058000 pci 2000:06:00.0: reg 0x10: [mem 0xd000-0xd00f 64bit pref] pci 2000:06:00.0: reg 0x18: [mem 0x-0x03ff 64bit] pci 2000:06:00.0: Adding to iommu group 15 pci_bus 2000:06: busn_res: [bus 06] end is updated to 06 pci_bus 2000:02: busn_res: [bus 02-06] end is updated to 06 pci_bus 2000:01: busn_res: [bus 01-06] end is updated to 06 pcieport 2000:00:00.0: BAR 9: no space for [mem size 0x0040 64bit pref] pcieport 2000:00:00.0: BAR 9: failed to assign [mem size 0x0040 64bit pref] pcieport 2000:01:00.0: BAR 8: assigned [mem 0xc4000-0xc4fff] pcieport 2000:01:00.0: BAR 9: assigned [mem 0xc5000-0xc503f 64bit pref] pci 2000:02:02.0: BAR 8: assigned [mem 0xc4000-0xc43ff] pci 2000:02:03.0: BAR 8: assigned [mem 0xc4400-0xc47ff] pci 2000:02:04.0: BAR 8: assigned [mem 0xc4800-0xc4bff] pci 2000:02:05.0: BAR 8: assigned [mem 0xc4c00-0xc4fff] pci 2000:02:02.0: BAR 9: assigned [mem 0xc5000-0xc500f 64bit pref] pci 2000:02:03.0: BAR 9: assigned [mem 0xc5010-0xc501f 64bit pref] pci 2000:02:04.0: BAR 9: assigned [mem 0xc5020-0xc502f 64bit pref] pci 2000:02:05.0: BAR 9: assigned [mem 0xc5030-0xc503f 64bit pref] pci 2000:03:00.0: BAR 2: assigned [mem 0xc4000-0xc43ff 64bit] pci 2000:03:00.0: BAR 0: assigned [mem 0xc5000-0xc500f 64bit pref] pci 2000:02:02.0: PCI bridge to [bus 03] pci 2000:02:02.0: bridge window [mem 0xc4000-0xc43ff] pci 2000:02:02.0: bridge window [mem 0xc5000-0xc500f 64bit pref] pci 2000:04:00.0: BAR 2: assigned [mem 0xc4400-0xc47ff 64bit] pci 2000:04:00.0: BAR 0: assigned [mem 0xc5010-0xc501f 64bit pref] pci 2000:02:03.0: PCI bridge to [bus 04] pci 2000:02:03.0: bridge window [mem 0xc4400-0xc47ff] pci 2000:02:03.0: bridge window [mem 0xc5010-0xc501f 64bit pref] pci 2000:05:00.0: BAR 2: assigned [mem 0xc4800-0xc4bff 64bit] pci 2000:05:00.0: BAR 0: assigned [mem 0xc5020-0xc502f 64bit pref] pci 2000:02:04.0: PCI bridge to [bus 05] pci 2000:02:04.0: bridge window [mem 0xc4800-0xc4bff]
Re: [PATCH v2] gen_compile_command: Add support for separate KBUILD_OUTPUT directory
On Tue, Jun 25, 2019 at 1:31 AM Matthias Kaehlcke wrote: > > gen_compile_command.py currently assumes that the .cmd files and the > source code live in the same directory, which is not the case when > a separate KBUILD_OUTPUT directory is used. > > Add a new option to specify this the kbuild output directory. If the > option is not set the kernel source directory is used. I do not understand this patch. In my understanding, this tool already provides -d, --directory option, which is supposed to point to the kbuild output directory, not a source directory. This works except under tools/. > -entry = process_line(directory, dirpath, > +entry = process_line(source_directory, dirpath, > result.group(1), > result.group(2)) This is wrong. result.group(2) returns the relative path to the output tree instead of the source tree. (or absolute path). [Example of breakage] $ make -j8 O=foo defconfig all $ scripts/gen_compile_commands.py -d . -k foo WARNING: Found 0 entries. Have you compiled the kernel? -- Best Regards Masahiro Yamada
[PATCH] rcuperf: Make rcuperf kernel test more robust for !expedited mode
It is possible that the rcuperf kernel test runs concurrently with init
starting up. During this time, the system is running all grace periods
as expedited. However, rcuperf can also be run for normal GP tests.
Right now, it depends on a holdoff time before starting the test to
ensure grace periods start later. This works fine with the default
holdoff time however it is not robust in situations where init takes
greater than the holdoff time to finish running. Or, as in my case:
I modified the rcuperf test locally to also run a thread that did
preempt disable/enable in a loop. This had the effect of slowing down
init. The end result was that the "batches:" counter in rcuperf was 0
causing a division by 0 error in the results. This counter was 0 because
only expedited GPs seem to happen, not normal ones which led to the
rcu_state.gp_seq counter remaining constant across grace periods which
unexpectedly happen to be expedited. The system was running expedited
RCU all the time because rcu_unexpedited_gp() would not have run yet
from init. In other words, the test would concurrently with init
booting in expedited GP mode.
To fix this properly, let us check if system_state if SYSTEM_RUNNING
is set before starting the test. The system_state approximately aligns
with when rcu_unexpedited_gp() is called and works well in practice.
I also tried late_initcall however it is still too early to be
meaningful for this case.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcuperf.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index 4513807cd4c4..5a879d073c1c 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -375,6 +375,14 @@ rcu_perf_writer(void *arg)
if (holdoff)
schedule_timeout_uninterruptible(holdoff * HZ);
+ /*
+* Wait until rcu_end_inkernel_boot() is called for normal GP tests
+* so that RCU is not always expedited for normal GP tests.
+* The system_state test is approximate, but works well in practice.
+*/
+ while (!gp_exp && system_state != SYSTEM_RUNNING)
+ schedule_timeout_uninterruptible(1);
+
t = ktime_get_mono_fast_ns();
if (atomic_inc_return(_rcu_perf_writer_started) >= nrealwriters) {
t_rcu_perf_writer_started = t;
--
2.22.0.410.gd8fdbe21b5-goog
Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
On 2019/7/3 下午9:08, Tiwei Bie wrote:
On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
On 2019/7/3 下午7:52, Tiwei Bie wrote:
On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
On 2019/7/3 下午5:13, Tiwei Bie wrote:
Details about this can be found here:
https://lwn.net/Articles/750770/
What's new in this version
==
A new VFIO device type is introduced - vfio-vhost. This addressed
some comments from here:https://patchwork.ozlabs.org/cover/984763/
Below is the updated device interface:
Currently, there are two regions of this device: 1) CONFIG_REGION
(VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to setup the
device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX), which
can be used to notify the device.
1. CONFIG_REGION
The region described by CONFIG_REGION is the main control interface.
Messages will be written to or read from this region.
The message type is determined by the `request` field in message
header. The message size is encoded in the message header too.
The message format looks like this:
struct vhost_vfio_op {
__u64 request;
__u32 flags;
/* Flag values: */
#define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need reply */
__u32 size;
union {
__u64 u64;
struct vhost_vring_state state;
struct vhost_vring_addr addr;
} payload;
};
The existing vhost-kernel ioctl cmds are reused as the message
requests in above structure.
Still a comments like V1. What's the advantage of inventing a new protocol?
I'm trying to make it work in VFIO's way..
I believe either of the following should be better:
- using vhost ioctl, we can start from SET_VRING_KICK/SET_VRING_CALL and
extend it with e.g notify region. The advantages is that all exist userspace
program could be reused without modification (or minimal modification). And
vhost API hides lots of details that is not necessary to be understood by
application (e.g in the case of container).
Do you mean reusing vhost's ioctl on VFIO device fd directly,
or introducing another mdev driver (i.e. vhost_mdev instead of
using the existing vfio_mdev) for mdev device?
Can we simply add them into ioctl of mdev_parent_ops?
Right, either way, these ioctls have to be and just need to be
added in the ioctl of the mdev_parent_ops. But another thing we
also need to consider is that which file descriptor the userspace
will do the ioctl() on. So I'm wondering do you mean let the
userspace do the ioctl() on the VFIO device fd of the mdev
device?
Yes. Is there any other way btw?
Thanks
[PATCH] genirq: update irq stats from NMI handlers
The NMI handlers handle_percpu_devid_fasteoi_nmi() and
handle_fasteoi_nmi() added by commit 2dcf1fbcad35 ("genirq: Provide NMI
handlers") do not update the interrupt counts. Due to that the NMI
interrupt count does not show up correctly in /proc/interrupts.
Update the functions to fix this. With this change, we can see stats of
the perf NMI interrupts on arm64.
Fixes: 2dcf1fbcad35 ("genirq: Provide NMI handlers")
Signed-off-by: Shijith Thotton
---
kernel/irq/chip.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 29d6c7d070b4..88d1e054c6ea 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -748,6 +748,8 @@ void handle_fasteoi_nmi(struct irq_desc *desc)
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
+ kstat_incr_irqs_this_cpu(desc);
+
trace_irq_handler_entry(irq, action);
/*
* NMIs cannot be shared, there is only one action.
@@ -962,6 +964,8 @@ void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc)
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
+ __kstat_incr_irqs_this_cpu(desc);
+
trace_irq_handler_entry(irq, action);
res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
trace_irq_handler_exit(irq, action, res);
--
2.17.0
[PATCH v2] gpiolib: Preserve desc->flags when setting state
desc->flags may already have values set by of_gpiochip_add() so make
sure that this isn't undone when setting the initial direction.
Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning")
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- add braces to avoid ambiguious else warning
drivers/gpio/gpiolib.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e013d417a936..5ac57264171b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1392,12 +1392,13 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip,
void *data,
for (i = 0; i < chip->ngpio; i++) {
struct gpio_desc *desc = >descs[i];
- if (chip->get_direction && gpiochip_line_is_valid(chip, i))
- desc->flags = !chip->get_direction(chip, i) ?
- (1 << FLAG_IS_OUT) : 0;
- else
- desc->flags = !chip->direction_input ?
- (1 << FLAG_IS_OUT) : 0;
+ if (chip->get_direction && gpiochip_line_is_valid(chip, i)) {
+ if (!chip->get_direction(chip, i))
+ set_bit(FLAG_IS_OUT, >flags);
+ } else {
+ if (!chip->direction_input)
+ set_bit(FLAG_IS_OUT, >flags);
+ }
}
acpi_gpiochip_add(chip);
--
2.22.0
Re: [PATCH] percpu: Make pcpu_setup_first_chunk() void function
On Wed, Jul 03, 2019 at 04:25:52PM +0800, Kefeng Wang wrote:
> pcpu_setup_first_chunk() will panic or BUG_ON if the are some
> error and doesn't return any error, hence it can be defined to
> return void.
>
> Signed-off-by: Kefeng Wang
> ---
> arch/ia64/mm/contig.c| 5 +
> arch/ia64/mm/discontig.c | 5 +
> include/linux/percpu.h | 2 +-
> mm/percpu.c | 17 ++---
> 4 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/arch/ia64/mm/contig.c b/arch/ia64/mm/contig.c
> index d29fb6b9fa33..db09a693f094 100644
> --- a/arch/ia64/mm/contig.c
> +++ b/arch/ia64/mm/contig.c
> @@ -134,10 +134,7 @@ setup_per_cpu_areas(void)
> ai->atom_size = page_size;
> ai->alloc_size = percpu_page_size;
>
> - rc = pcpu_setup_first_chunk(ai, __per_cpu_start + __per_cpu_offset[0]);
> - if (rc)
> - panic("failed to setup percpu area (err=%d)", rc);
> -
> + pcpu_setup_first_chunk(ai, __per_cpu_start + __per_cpu_offset[0]);
> pcpu_free_alloc_info(ai);
> }
> #else
> diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
> index 05490dd073e6..004dee231874 100644
> --- a/arch/ia64/mm/discontig.c
> +++ b/arch/ia64/mm/discontig.c
> @@ -245,10 +245,7 @@ void __init setup_per_cpu_areas(void)
> gi->cpu_map = _map[unit];
> }
>
> - rc = pcpu_setup_first_chunk(ai, base);
> - if (rc)
> - panic("failed to setup percpu area (err=%d)", rc);
> -
> + pcpu_setup_first_chunk(ai, base);
> pcpu_free_alloc_info(ai);
> }
> #endif
> diff --git a/include/linux/percpu.h b/include/linux/percpu.h
> index 9909dc0e273a..5e76af742c80 100644
> --- a/include/linux/percpu.h
> +++ b/include/linux/percpu.h
> @@ -105,7 +105,7 @@ extern struct pcpu_alloc_info * __init
> pcpu_alloc_alloc_info(int nr_groups,
>int nr_units);
> extern void __init pcpu_free_alloc_info(struct pcpu_alloc_info *ai);
>
> -extern int __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
> +extern void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
>void *base_addr);
>
> #ifdef config_need_per_cpu_embed_first_chunk
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 9821241fdede..ad32c3d11ca7 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2267,12 +2267,9 @@ static void pcpu_dump_alloc_info(const char *lvl,
> * share the same vm, but use offset regions in the area allocation map.
> * the chunk serving the dynamic region is circulated in the chunk slots
> * and available for dynamic allocation like any other chunk.
> - *
> - * returns:
> - * 0 on success, -errno on failure.
> */
> -int __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
> - void *base_addr)
> +void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
> +void *base_addr)
> {
> size_t size_sum = ai->static_size + ai->reserved_size + ai->dyn_size;
> size_t static_size, dyn_size;
> @@ -2457,7 +2454,6 @@ int __init pcpu_setup_first_chunk(const struct
> pcpu_alloc_info *ai,
>
> /* we're done */
> pcpu_base_addr = base_addr;
> - return 0;
> }
>
> #ifdef config_smp
> @@ -2710,7 +2706,7 @@ int __init pcpu_embed_first_chunk(size_t reserved_size,
> size_t dyn_size,
> struct pcpu_alloc_info *ai;
> size_t size_sum, areas_size;
> unsigned long max_distance;
> - int group, i, highest_group, rc;
> + int group, i, highest_group, rc = 0;
>
> ai = pcpu_build_alloc_info(reserved_size, dyn_size, atom_size,
> cpu_distance_fn);
> @@ -2795,7 +2791,7 @@ int __init pcpu_embed_first_chunk(size_t reserved_size,
> size_t dyn_size,
> pfn_down(size_sum), ai->static_size, ai->reserved_size,
> ai->dyn_size, ai->unit_size);
>
> - rc = pcpu_setup_first_chunk(ai, base);
> + pcpu_setup_first_chunk(ai, base);
> goto out_free;
>
> out_free_areas:
> @@ -2920,7 +2916,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size,
> unit_pages, psize_str, ai->static_size,
> ai->reserved_size, ai->dyn_size);
>
> - rc = pcpu_setup_first_chunk(ai, vm.addr);
> + pcpu_setup_first_chunk(ai, vm.addr);
> goto out_free_ar;
>
> enomem:
> @@ -3014,8 +3010,7 @@ void __init setup_per_cpu_areas(void)
> ai->groups[0].nr_units = 1;
> ai->groups[0].cpu_map[0] = 0;
>
> - if (pcpu_setup_first_chunk(ai, fc) < 0)
> - panic("failed to initialize percpu areas.");
> + pcpu_setup_first_chunk(ai, fc);
> pcpu_free_alloc_info(ai);
> }
>
> --
> 2.20.1
>
Hi Kefeng,
This makes sense to me. I've applied this to for-5.4.
Thanks,
Dennis
Re: linux-next: build failure after merge of the rdma tree
在 2019/7/4 12:07, wangxi 写道:
>
>
> 在 2019/7/4 10:04, Jason Gunthorpe 写道:
>> On Thu, Jul 04, 2019 at 12:02:35PM +1000, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Mon, 1 Jul 2019 14:14:31 +1000 Stephen Rothwell
>>> wrote:
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/infiniband/hw/hns/hns_roce_ah.o
see include/linux/module.h for more information
>>> .
>>> .
>>> .
ERROR: "hns_roce_bitmap_cleanup"
[drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined!
>>> .
>>> .
>>> .
ERROR: "hns_roce_ib_destroy_cq"
[drivers/infiniband/hw/hns/hns-roce-hw-v1.ko] undefined!
Presumably caused by commit
e9816ddf2a33 ("RDMA/hns: Cleanup unnecessary exported symbols")
I have used the rdma tree from next-20190628 for today.
>>>
>>> I am still getting these errors/warnings.
>>
>> I have not got a fixing patch from HNS team.
>>
>> At this late date I will revert the problematic HNS patch tomorrow.
>> There is indeed a mistake, I will append a patch as soon as possible.
>
> The patch sent before has a problem caused by the merge of the local code.
> The correct one
> should be as follows :
>
> diff --git a/drivers/infiniband/hw/hns/Makefile
> b/drivers/infiniband/hw/hns/Makefile
> index b956cf4..b06125f 100644
> --- a/drivers/infiniband/hw/hns/Makefile
> +++ b/drivers/infiniband/hw/hns/Makefile
> @@ -9,8 +9,8 @@ hns-roce-objs := hns_roce_main.o hns_roce_cmd.o hns_roce_pd.o
> \
> hns_roce_cq.o hns_roce_alloc.o hns_roce_db.o hns_roce_srq.o
> hns_roce_restrack.o
>
> ifdef CONFIG_INFINIBAND_HNS_HIP06
> -hns-roce-hw-v1-objs := hns_roce_hw_v1.o
> -obj-$(CONFIG_INFINIBAND_HNS) += hns-roce-hw-v1.o $(hns-roce-objs)
> +hns-roce-hw-v1-objs := hns_roce_hw_v1.o $(hns-roce-objs)
> +obj-$(CONFIG_INFINIBAND_HNS) += hns-roce-hw-v1.o
> endif
>
The old patch does have an error and I will append a new patch as soon as
possible.
>> Jason
>> .
>>
Re: linux-next: build failure after merge of the rdma tree
在 2019/7/4 10:04, Jason Gunthorpe 写道:
> On Thu, Jul 04, 2019 at 12:02:35PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 1 Jul 2019 14:14:31 +1000 Stephen Rothwell
>> wrote:
>>>
>>> Hi all,
>>>
>>> After merging the rdma tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> WARNING: modpost: missing MODULE_LICENSE() in
>>> drivers/infiniband/hw/hns/hns_roce_ah.o
>>> see include/linux/module.h for more information
>> .
>> .
>> .
>>> ERROR: "hns_roce_bitmap_cleanup"
>>> [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined!
>> .
>> .
>> .
>>> ERROR: "hns_roce_ib_destroy_cq"
>>> [drivers/infiniband/hw/hns/hns-roce-hw-v1.ko] undefined!
>>>
>>> Presumably caused by commit
>>>
>>> e9816ddf2a33 ("RDMA/hns: Cleanup unnecessary exported symbols")
>>>
>>> I have used the rdma tree from next-20190628 for today.
>>
>> I am still getting these errors/warnings.
>
> I have not got a fixing patch from HNS team.
>
> At this late date I will revert the problematic HNS patch tomorrow.
> There is indeed a mistake, I will append a patch as soon as possible.
The patch sent before has a problem caused by the merge of the local code. The
correct one
should be as follows :
diff --git a/drivers/infiniband/hw/hns/Makefile
b/drivers/infiniband/hw/hns/Makefile
index b956cf4..b06125f 100644
--- a/drivers/infiniband/hw/hns/Makefile
+++ b/drivers/infiniband/hw/hns/Makefile
@@ -9,8 +9,8 @@ hns-roce-objs := hns_roce_main.o hns_roce_cmd.o hns_roce_pd.o \
hns_roce_cq.o hns_roce_alloc.o hns_roce_db.o hns_roce_srq.o
hns_roce_restrack.o
ifdef CONFIG_INFINIBAND_HNS_HIP06
-hns-roce-hw-v1-objs := hns_roce_hw_v1.o
-obj-$(CONFIG_INFINIBAND_HNS) += hns-roce-hw-v1.o $(hns-roce-objs)
+hns-roce-hw-v1-objs := hns_roce_hw_v1.o $(hns-roce-objs)
+obj-$(CONFIG_INFINIBAND_HNS) += hns-roce-hw-v1.o
endif
> Jason
> .
>
Re: [PATCH v2 2/3] vsock/virtio: stop workers during the .remove()
On 2019/6/28 下午8:36, Stefano Garzarella wrote:
Before to call vdev->config->reset(vdev) we need to be sure that
no one is accessing the device, for this reason, we add new variables
in the struct virtio_vsock to stop the workers during the .remove().
This patch also add few comments before vdev->config->reset(vdev)
and vdev->config->del_vqs(vdev).
Suggested-by: Stefan Hajnoczi
Suggested-by: Michael S. Tsirkin
Signed-off-by: Stefano Garzarella
---
net/vmw_vsock/virtio_transport.c | 51 +++-
1 file changed, 50 insertions(+), 1 deletion(-)
This should work. But we may consider to convert the_virtio_vosck to
socket object and use socket refcnt and destructor in the future instead
of inventing something new by ourselves.
Thanks
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 7ad510ec12e0..1b44ec6f3f6c 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -38,6 +38,7 @@ struct virtio_vsock {
* must be accessed with tx_lock held.
*/
struct mutex tx_lock;
+ bool tx_run;
struct work_struct send_pkt_work;
spinlock_t send_pkt_list_lock;
@@ -53,6 +54,7 @@ struct virtio_vsock {
* must be accessed with rx_lock held.
*/
struct mutex rx_lock;
+ bool rx_run;
int rx_buf_nr;
int rx_buf_max_nr;
@@ -60,6 +62,7 @@ struct virtio_vsock {
* vqs[VSOCK_VQ_EVENT] must be accessed with event_lock held.
*/
struct mutex event_lock;
+ bool event_run;
struct virtio_vsock_event event_list[8];
u32 guest_cid;
@@ -94,6 +97,10 @@ static void virtio_transport_loopback_work(struct
work_struct *work)
spin_unlock_bh(>loopback_list_lock);
mutex_lock(>rx_lock);
+
+ if (!vsock->rx_run)
+ goto out;
+
while (!list_empty()) {
struct virtio_vsock_pkt *pkt;
@@ -102,6 +109,7 @@ static void virtio_transport_loopback_work(struct work_struct *work)
virtio_transport_recv_pkt(pkt);
}
+out:
mutex_unlock(>rx_lock);
}
@@ -130,6 +138,9 @@ virtio_transport_send_pkt_work(struct work_struct *work)
mutex_lock(>tx_lock);
+ if (!vsock->tx_run)
+ goto out;
+
vq = vsock->vqs[VSOCK_VQ_TX];
for (;;) {
@@ -188,6 +199,7 @@ virtio_transport_send_pkt_work(struct work_struct *work)
if (added)
virtqueue_kick(vq);
+out:
mutex_unlock(>tx_lock);
if (restart_rx)
@@ -323,6 +335,10 @@ static void virtio_transport_tx_work(struct work_struct
*work)
vq = vsock->vqs[VSOCK_VQ_TX];
mutex_lock(>tx_lock);
+
+ if (!vsock->tx_run)
+ goto out;
+
do {
struct virtio_vsock_pkt *pkt;
unsigned int len;
@@ -333,6 +349,8 @@ static void virtio_transport_tx_work(struct work_struct
*work)
added = true;
}
} while (!virtqueue_enable_cb(vq));
+
+out:
mutex_unlock(>tx_lock);
if (added)
@@ -361,6 +379,9 @@ static void virtio_transport_rx_work(struct work_struct
*work)
mutex_lock(>rx_lock);
+ if (!vsock->rx_run)
+ goto out;
+
do {
virtqueue_disable_cb(vq);
for (;;) {
@@ -470,6 +491,9 @@ static void virtio_transport_event_work(struct work_struct
*work)
mutex_lock(>event_lock);
+ if (!vsock->event_run)
+ goto out;
+
do {
struct virtio_vsock_event *event;
unsigned int len;
@@ -484,7 +508,7 @@ static void virtio_transport_event_work(struct work_struct
*work)
} while (!virtqueue_enable_cb(vq));
virtqueue_kick(vsock->vqs[VSOCK_VQ_EVENT]);
-
+out:
mutex_unlock(>event_lock);
}
@@ -619,12 +643,18 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
INIT_WORK(>send_pkt_work, virtio_transport_send_pkt_work);
INIT_WORK(>loopback_work, virtio_transport_loopback_work);
+ mutex_lock(>tx_lock);
+ vsock->tx_run = true;
+ mutex_unlock(>tx_lock);
+
mutex_lock(>rx_lock);
virtio_vsock_rx_fill(vsock);
+ vsock->rx_run = true;
mutex_unlock(>rx_lock);
mutex_lock(>event_lock);
virtio_vsock_event_fill(vsock);
+ vsock->event_run = true;
mutex_unlock(>event_lock);
vdev->priv = vsock;
@@ -659,6 +689,24 @@ static void virtio_vsock_remove(struct virtio_device *vdev)
/* Reset all connected sockets when the device disappear */
vsock_for_each_connected_socket(virtio_vsock_reset_sock);
+ /* Stop all work handlers to make sure no one is accessing the device,
+* so we can safely call vdev->config->reset().
+*/
+ mutex_lock(>rx_lock);
+ vsock->rx_run = false;
+ mutex_unlock(>rx_lock);
+
+ mutex_lock(>tx_lock);
+ vsock->tx_run = false;
+
Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
On 2019/7/3 下午6:41, Stefano Garzarella wrote:
On Wed, Jul 03, 2019 at 05:53:58PM +0800, Jason Wang wrote:
On 2019/6/28 下午8:36, Stefano Garzarella wrote:
Some callbacks used by the upper layers can run while we are in the
.remove(). A potential use-after-free can happen, because we free
the_virtio_vsock without knowing if the callbacks are over or not.
To solve this issue we move the assignment of the_virtio_vsock at the
end of .probe(), when we finished all the initialization, and at the
beginning of .remove(), before to release resources.
For the same reason, we do the same also for the vdev->priv.
We use RCU to be sure that all callbacks that use the_virtio_vsock
ended before freeing it. This is not required for callbacks that
use vdev->priv, because after the vdev->config->del_vqs() we are sure
that they are ended and will no longer be invoked.
We also take the mutex during the .remove() to avoid that .probe() can
run while we are resetting the device.
Signed-off-by: Stefano Garzarella
---
net/vmw_vsock/virtio_transport.c | 67 +---
1 file changed, 44 insertions(+), 23 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 9c287e3e393c..7ad510ec12e0 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -65,19 +65,22 @@ struct virtio_vsock {
u32 guest_cid;
};
-static struct virtio_vsock *virtio_vsock_get(void)
-{
- return the_virtio_vsock;
-}
-
static u32 virtio_transport_get_local_cid(void)
{
- struct virtio_vsock *vsock = virtio_vsock_get();
+ struct virtio_vsock *vsock;
+ u32 ret;
- if (!vsock)
- return VMADDR_CID_ANY;
+ rcu_read_lock();
+ vsock = rcu_dereference(the_virtio_vsock);
+ if (!vsock) {
+ ret = VMADDR_CID_ANY;
+ goto out_rcu;
+ }
- return vsock->guest_cid;
+ ret = vsock->guest_cid;
+out_rcu:
+ rcu_read_unlock();
+ return ret;
}
static void virtio_transport_loopback_work(struct work_struct *work)
@@ -197,14 +200,18 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
struct virtio_vsock *vsock;
int len = pkt->len;
- vsock = virtio_vsock_get();
+ rcu_read_lock();
+ vsock = rcu_dereference(the_virtio_vsock);
if (!vsock) {
virtio_transport_free_pkt(pkt);
- return -ENODEV;
+ len = -ENODEV;
+ goto out_rcu;
}
- if (le64_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid)
- return virtio_transport_send_pkt_loopback(vsock, pkt);
+ if (le64_to_cpu(pkt->hdr.dst_cid) == vsock->guest_cid) {
+ len = virtio_transport_send_pkt_loopback(vsock, pkt);
+ goto out_rcu;
+ }
if (pkt->reply)
atomic_inc(>queued_replies);
@@ -214,6 +221,9 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
spin_unlock_bh(>send_pkt_list_lock);
queue_work(virtio_vsock_workqueue, >send_pkt_work);
+
+out_rcu:
+ rcu_read_unlock();
return len;
}
@@ -222,12 +232,14 @@ virtio_transport_cancel_pkt(struct vsock_sock *vsk)
{
struct virtio_vsock *vsock;
struct virtio_vsock_pkt *pkt, *n;
- int cnt = 0;
+ int cnt = 0, ret;
LIST_HEAD(freeme);
- vsock = virtio_vsock_get();
+ rcu_read_lock();
+ vsock = rcu_dereference(the_virtio_vsock);
if (!vsock) {
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_rcu;
}
spin_lock_bh(>send_pkt_list_lock);
@@ -255,7 +267,11 @@ virtio_transport_cancel_pkt(struct vsock_sock *vsk)
queue_work(virtio_vsock_workqueue, >rx_work);
}
- return 0;
+ ret = 0;
+
+out_rcu:
+ rcu_read_unlock();
+ return ret;
}
static void virtio_vsock_rx_fill(struct virtio_vsock *vsock)
@@ -590,8 +606,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
vsock->rx_buf_max_nr = 0;
atomic_set(>queued_replies, 0);
- vdev->priv = vsock;
- the_virtio_vsock = vsock;
mutex_init(>tx_lock);
mutex_init(>rx_lock);
mutex_init(>event_lock);
@@ -613,6 +627,9 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
virtio_vsock_event_fill(vsock);
mutex_unlock(>event_lock);
+ vdev->priv = vsock;
+ rcu_assign_pointer(the_virtio_vsock, vsock);
You probably need to use rcu_dereference_protected() to access
the_virtio_vsock in the function in order to survive from sparse.
Ooo, thanks!
Do you mean when we check if the_virtio_vsock is not null at the beginning of
virtio_vsock_probe()?
I mean instead of:
/* Only one virtio-vsock device per guest is supported */
if (the_virtio_vsock) {
ret = -EBUSY;
goto out;
}
you should use:
if
linux-next: manual merge of the device-mapper tree with the jc_docs tree
Hi all,
Today's linux-next merge of the device-mapper tree got a conflict in:
Documentation/device-mapper/snapshot.rst
between commit:
f0ba43774cea ("docs: convert docs to ReST and rename to *.rst")
from the jc_docs tree and commit:
a8a9f1434a86 ("dm snapshot: add optional discard support features")
from the device-mapper tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/device-mapper/snapshot.rst
index 4c53304e72f1,1810833f6dc6..
--- a/Documentation/device-mapper/snapshot.rst
+++ b/Documentation/device-mapper/snapshot.rst
@@@ -31,7 -30,8 +31,8 @@@ original data will be saved in the fills up.
-*) snapshot
+- snapshot
+[<# feature args> []*]
A snapshot of the block device is created. Changed chunks of
sectors will be stored on the . Writes will
pgpyJ8_qMKwyP.pgp
Description: OpenPGP digital signature
[PATCH] tpm: fixes uninitialized allocated banks for IBM vtpm driver
The nr_allocated_banks and allocated banks are initialized as part of
tpm_chip_register. Currently, this is done as part of auto startup
function. However, some drivers, like the ibm vtpm driver, do not run
auto startup during initialization. This results in uninitialized memory
issue and causes a kernel panic during boot.
This patch moves the pcr allocation outside the auto startup function
into tpm_chip_register. This ensures that allocated banks are initialized
in any case.
Fixes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
PCR read")
Signed-off-by: Nayna Jain
---
drivers/char/tpm/tpm-chip.c | 37 +
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm1-cmd.c | 12
drivers/char/tpm/tpm2-cmd.c | 6 +-
4 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 8804c9e916fd..958508bb8379 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -550,6 +550,39 @@ static int tpm_add_hwrng(struct tpm_chip *chip)
return hwrng_register(>hwrng);
}
+/*
+ * tpm_pcr_allocation() - initializes the chip allocated banks for PCRs
+ */
+static int tpm_pcr_allocation(struct tpm_chip *chip)
+{
+ int rc = 0;
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ rc = tpm2_get_pcr_allocation(chip);
+ if (rc)
+ goto out;
+ }
+
+ /* Initialize TPM 1.2 */
+ chip->allocated_banks = kcalloc(1, sizeof(*chip->allocated_banks),
+ GFP_KERNEL);
+ if (!chip->allocated_banks) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ chip->allocated_banks[0].alg_id = TPM_ALG_SHA1;
+ chip->allocated_banks[0].digest_size = hash_digest_size[HASH_ALGO_SHA1];
+ chip->allocated_banks[0].crypto_id = HASH_ALGO_SHA1;
+ chip->nr_allocated_banks = 1;
+
+ return 0;
+out:
+ if (rc < 0)
+ rc = -ENODEV;
+ return rc;
+}
+
/*
* tpm_chip_register() - create a character device for the TPM chip
* @chip: TPM chip to use.
@@ -573,6 +606,10 @@ int tpm_chip_register(struct tpm_chip *chip)
if (rc)
return rc;
+ rc = tpm_pcr_allocation(chip);
+ if (rc)
+ return rc;
+
tpm_sysfs_add_device(chip);
rc = tpm_bios_log_setup(chip);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 2cce072f25b5..eabe6b755fa6 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -454,6 +454,7 @@ int tpm2_unseal_trusted(struct tpm_chip *chip,
ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
u32 *value, const char *desc);
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
int tpm2_auto_startup(struct tpm_chip *chip);
void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 85dcf2654d11..ec5f3693c096 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -696,18 +696,6 @@ int tpm1_auto_startup(struct tpm_chip *chip)
goto out;
}
- chip->allocated_banks = kcalloc(1, sizeof(*chip->allocated_banks),
- GFP_KERNEL);
- if (!chip->allocated_banks) {
- rc = -ENOMEM;
- goto out;
- }
-
- chip->allocated_banks[0].alg_id = TPM_ALG_SHA1;
- chip->allocated_banks[0].digest_size = hash_digest_size[HASH_ALGO_SHA1];
- chip->allocated_banks[0].crypto_id = HASH_ALGO_SHA1;
- chip->nr_allocated_banks = 1;
-
return rc;
out:
if (rc > 0)
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index e74c5b7b64bf..b4384d0e3741 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -841,7 +841,7 @@ struct tpm2_pcr_selection {
u8 pcr_select[3];
} __packed;
-static ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
+ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
{
struct tpm2_pcr_selection pcr_selection;
struct tpm_buf buf;
@@ -1041,10 +1041,6 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
}
- rc = tpm2_get_pcr_allocation(chip);
- if (rc)
- goto out;
-
rc = tpm2_get_cc_attrs_tbl(chip);
out:
--
2.20.1
Re: [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
On Thu, Jul 04, 2019 at 01:33:16AM +, Voon, Weifeng wrote:
> > > @@ -155,22 +171,26 @@ static int stmmac_mdio_read(struct mii_bus *bus,
> > int phyaddr, int phyreg)
> > > struct stmmac_priv *priv = netdev_priv(ndev);
> > > unsigned int mii_address = priv->hw->mii.addr;
> > > unsigned int mii_data = priv->hw->mii.data;
> > > - u32 v;
> > > - int data;
> > > u32 value = MII_BUSY;
> > > + int data = 0;
> > > + u32 v;
> > >
> > > value |= (phyaddr << priv->hw->mii.addr_shift)
> > > & priv->hw->mii.addr_mask;
> > > value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw-
> > >mii.reg_mask;
> > > value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
> > > & priv->hw->mii.clk_csr_mask;
> > > - if (priv->plat->has_gmac4)
> > > + if (priv->plat->has_gmac4) {
> > > value |= MII_GMAC4_READ;
> > > + if (phyreg & MII_ADDR_C45)
> > > + stmmac_mdio_c45_setup(priv, phyreg, , );
> > > + }
> > >
> > > if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v &
> > MII_BUSY),
> > > 100, 1))
> > > return -EBUSY;
> > >
> > > + writel(data, priv->ioaddr + mii_data);
> >
> > That looks odd. Could you explain why it is needed.
> >
> > Thanks
> > Andrew
>
> Hi Andrew,
> This mdio c45 support needed to access DWC xPCS which is a Clause-45
I mean it looks odd doing a write to the data register in the middle
of stmmac_mdio_read().
Andrew
Re: [PATCH RFC 0/3] Support CPU hotplug for ARM64
Hi Justin, On 2019/7/4 11:00, Jia He wrote: > Hi Xiongfeng > > It is a little bit awkful that I am also investigating acpi based cpu > hotplug issue silimar with > > your idea. My question is your purpose to implement the vcpu hotplug in arm64 > qemu? Yes, my purpose is to implement the vcpu hotplug in arm64 qemu. So that I can add or remove vcpu without shutting down the Guest OS. Thanks, Xiongfeng > > Thanks for the ellaboration > > --- > Cheers, > Justin (Jia He) > > On 2019/6/28 19:13, Xiongfeng Wang wrote: >> This patchset mark all the GICC node in MADT as possible CPUs even though it >> is disabled. But only those enabled GICC node are marked as present CPUs. >> So that kernel will initialize some CPU related data structure in advance >> before >> the CPU is actually hot added into the system. This patchset also implement >> 'acpi_(un)map_cpu()' and 'arch_(un)register_cpu()' for ARM64. These >> functions are >> needed to enable CPU hotplug. >> >> To support CPU hotplug, we need to add all the possible GICC node in MADT >> including those CPUs that are not present but may be hot added later. Those >> CPUs are marked as disabled in GICC nodes. >> >> Xiongfeng Wang (3): >> ACPI / scan: evaluate _STA for processors declared via ASL Device >> statement >> arm64: mark all the GICC nodes in MADT as possible cpu >> arm64: Add CPU hotplug support >> >> arch/arm64/kernel/acpi.c | 22 ++ >> arch/arm64/kernel/setup.c | 19 ++- >> arch/arm64/kernel/smp.c | 11 +-- >> drivers/acpi/scan.c | 12 >> 4 files changed, 57 insertions(+), 7 deletions(-) >> > > . >
Re: [PATCH] dax: Fix missed PMD wakeups
On Wed, Jul 03, 2019 at 02:28:41PM -0700, Dan Williams wrote:
> On Wed, Jul 3, 2019 at 12:53 PM Matthew Wilcox wrote:
> > @@ -211,7 +215,8 @@ static void *get_unlocked_entry(struct xa_state *xas)
> > for (;;) {
> > entry = xas_find_conflict(xas);
> > if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) ||
> > - !dax_is_locked(entry))
> > + !dax_is_locked(entry) ||
> > + dax_entry_order(entry) < xas_get_order(xas))
>
> Doesn't this potentially allow a locked entry to be returned for a
> caller that expects all value entries are unlocked?
It only allows locked entries to be returned for callers which pass in
an xas which refers to a PMD entry. This is fine for grab_mapping_entry()
because it checks size_flag & is_pte_entry.
dax_layout_busy_page() only uses 0-order.
__dax_invalidate_entry() only uses 0-order.
dax_writeback_one() needs an extra fix:
/* Did a PMD entry get split? */
if (dax_is_locked(entry))
goto put_unlocked;
dax_insert_pfn_mkwrite() checks for a mismatch of pte vs pmd.
So I think we're good for all current users.
> > +#ifdef CONFIG_XARRAY_MULTI
> > + unsigned int sibs = xas->xa_sibs;
> > +
> > + while (sibs) {
> > + order++;
> > + sibs /= 2;
> > + }
>
> Use ilog2() here?
Thought about it. sibs is never going to be more than 31, so I don't
know that it's worth eliminating 5 add/shift pairs in favour of whatever
the ilog2 instruction is on a given CPU. In practice, on x86, sibs is
going to be either 0 (PTEs) or 7 (PMDs). We could also avoid even having
this function by passing PMD_ORDER or PTE_ORDER into get_unlocked_entry().
It's probably never going to be noticable in this scenario because it's
the very last thing checked before we put ourselves on a waitqueue and
go to sleep.
[PATCH 1/1] tools/dtrace: initial implementation of DTrace
This initial implementation of a tiny subset of DTrace functionality provides the following options: dtrace [-lvV] [-b bufsz] -s script -b set trace buffer size -l list probes (only works with '-s script' for now) -s enable or list probes for the specified BPF program -V report DTrace API version The patch comprises quite a bit of code due to DTrace requiring a few crucial components, even in its most basic form. The code is structured around the command line interface implemented in dtrace.c. It provides option parsing and drives the three modes of operation that are currently implemented: 1. Report DTrace API version information. Report the version information and terminate. 2. List probes in BPF programs. Initialize the list of probes that DTrace recognizes, load BPF programs, parse all BPF ELF section names, resolve them into known probes, and emit the probe names. Then terminate. 3. Load BPF programs and collect tracing data. Initialize the list of probes that DTrace recognizes, load BPF programs and attach them to their corresponding probes, set up perf event output buffers, and start processing tracing data. This implementation makes extensive use of BPF (handled by dt_bpf.c) and the perf event output ring buffer (handled by dt_buffer.c). DTrace-style probe handling (dt_probe.c) offers an interface to probes that hides the implementation details of the individual probe types by provider (dt_fbt.c and dt_syscall.c). Probe lookup by name uses a hashtable implementation (dt_hash.c). The dt_utils.c code populates a list of online CPU ids, so we know what CPUs we can obtain tracing data from. Building the tool is trivial because its only dependency (libbpf) is in the kernel tree under tools/lib/bpf. A simple 'make' in the tools/dtrace directory suffices. The 'dtrace' executable needs to run as root because BPF programs cannot be loaded by non-root users. Signed-off-by: Kris Van Hees Reviewed-by: David Mc Lean Reviewed-by: Eugene Loh --- MAINTAINERS| 6 + tools/dtrace/Makefile | 88 ++ tools/dtrace/bpf_sample.c | 145 tools/dtrace/dt_bpf.c | 188 + tools/dtrace/dt_buffer.c | 331 + tools/dtrace/dt_fbt.c | 201 ++ tools/dtrace/dt_hash.c | 211 +++ tools/dtrace/dt_probe.c| 230 ++ tools/dtrace/dt_syscall.c | 179 tools/dtrace/dt_utils.c| 132 +++ tools/dtrace/dtrace.c | 249 tools/dtrace/dtrace.h | 13 ++ tools/dtrace/dtrace_impl.h | 101 +++ 13 files changed, 2074 insertions(+) create mode 100644 tools/dtrace/Makefile create mode 100644 tools/dtrace/bpf_sample.c create mode 100644 tools/dtrace/dt_bpf.c create mode 100644 tools/dtrace/dt_buffer.c create mode 100644 tools/dtrace/dt_fbt.c create mode 100644 tools/dtrace/dt_hash.c create mode 100644 tools/dtrace/dt_probe.c create mode 100644 tools/dtrace/dt_syscall.c create mode 100644 tools/dtrace/dt_utils.c create mode 100644 tools/dtrace/dtrace.c create mode 100644 tools/dtrace/dtrace.h create mode 100644 tools/dtrace/dtrace_impl.h diff --git a/MAINTAINERS b/MAINTAINERS index 606d1f80bc49..668468834865 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5474,6 +5474,12 @@ W: https://linuxtv.org S: Odd Fixes F: drivers/media/pci/dt3155/ +DTRACE +M: Kris Van Hees +L: dtrace-de...@oss.oracle.com +S: Maintained +F: tools/dtrace/ + DVB_USB_AF9015 MEDIA DRIVER M: Antti Palosaari L: linux-me...@vger.kernel.org diff --git a/tools/dtrace/Makefile b/tools/dtrace/Makefile new file mode 100644 index ..99fd0f9dd1d6 --- /dev/null +++ b/tools/dtrace/Makefile @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# This Makefile is based on samples/bpf. +# +# Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. + +DT_VERSION := 2.0.0 +DT_GIT_VERSION := $(shell git rev-parse HEAD 2>/dev/null || \ + echo Unknown) + +DTRACE_PATH?= $(abspath $(srctree)/$(src)) +TOOLS_PATH := $(DTRACE_PATH)/.. +SAMPLES_PATH := $(DTRACE_PATH)/../../samples + +hostprogs-y:= dtrace + +LIBBPF := $(TOOLS_PATH)/lib/bpf/libbpf.a +OBJS := dt_bpf.o dt_buffer.o dt_utils.o dt_probe.o \ + dt_hash.o \ + dt_fbt.o dt_syscall.o + +dtrace-objs:= $(OBJS) dtrace.o + +always := $(hostprogs-y) +always += bpf_sample.o + +KBUILD_HOSTCFLAGS += -DDT_VERSION=\"$(DT_VERSION)\" +KBUILD_HOSTCFLAGS += -DDT_GIT_VERSION=\"$(DT_GIT_VERSION)\" +KBUILD_HOSTCFLAGS += -I$(srctree)/tools/lib
[PATCH 0/1] tools/dtrace: initial implementation of DTrace
This patch is also available, applied to bpf-next, at the following URL: https://github.com/oracle/dtrace-linux-kernel/tree/dtrace-bpf As suggested in feedback to my earlier patch submissions, this code takes an approach to avoid kernel code changes as much as possible. The current patch does not involve any kernel code changes. Further development of this code will continue with this approach, incrementally adding features to this first minimal implementation. The goal is a fully featured and functional DTrace implementation involving kernel changes only when strictly necessary. The code presented here supports two very basic functions: 1. Listing probes that are used in BPF programs # dtrace -l -s bpf_sample.o ID PROVIDERMODULE FUNCTION NAME 18876fbt vmlinuxksys_write entry 70423syscall vmlinux write entry 2. Loading BPF tracing programs and collecting data that they generate # dtrace -s bpf_sample.o CPU ID 15 70423 0x8c0968bf8ec0 0x01 0x0055e019eb3f60 0x2c 15 18876 0x8c0968bf8ec0 0x01 0x0055e019eb3f60 0x2c ... Only kprobes and syscall tracepoints are supported since this is an initial patch. It does show the use of a generic BPF function to implement the actual probe action, called from two distinct probe types. Follow-up patches will add more probe types, add more tracing features from the D language, add support for D script compilation to BPF, etc. The implementation makes use of libbpf for handling BPF ELF objects, and uses the perf event output ring buffer (supported through BPF) to retrieve the tracing data. The next step in development will be adding support to libbpf for programs using shared functions from a collection of functions included in the BPF ELF object (as suggested by Alexei). The code is structured as follows: tools/dtrace/dtrace.c = command line utility tools/dtrace/dt_bpf.c = interface to libbpf tools/dtrace/dt_buffer.c = perf event output buffer handling tools/dtrace/dt_fbt.c = kprobes probe provider tools/dtrace/dt_syscall.c = syscall tracepoint probe provider tools/dtrace/dt_probe.c= generic probe and probe provider handling code This implements a generic interface to the actual probe providers (dt_fbt and dt_syscall). tools/dtrace/dt_hash.c = general probe hashing implementation tools/dtrace/dt_utils.c= support code (manage list of online CPUs) tools/dtrace/dtrace.h = API header file (used by BPF program source code) tools/dtrace/dtrace_impl.h = implementation header file tools/dtrace/bpf_sample.c = sample BPF program using two probe types I included an entry for the MAINTAINERS file. I offer to actively maintain this code, and to keep advancing its development. Cheers, Kris Van Hees
Re: [PATCH RFC 0/3] Support CPU hotplug for ARM64
Hi Xiongfeng It is a little bit awkful that I am also investigating acpi based cpu hotplug issue silimar with your idea. My question is your purpose to implement the vcpu hotplug in arm64 qemu? Thanks for the ellaboration --- Cheers, Justin (Jia He) On 2019/6/28 19:13, Xiongfeng Wang wrote: This patchset mark all the GICC node in MADT as possible CPUs even though it is disabled. But only those enabled GICC node are marked as present CPUs. So that kernel will initialize some CPU related data structure in advance before the CPU is actually hot added into the system. This patchset also implement 'acpi_(un)map_cpu()' and 'arch_(un)register_cpu()' for ARM64. These functions are needed to enable CPU hotplug. To support CPU hotplug, we need to add all the possible GICC node in MADT including those CPUs that are not present but may be hot added later. Those CPUs are marked as disabled in GICC nodes. Xiongfeng Wang (3): ACPI / scan: evaluate _STA for processors declared via ASL Device statement arm64: mark all the GICC nodes in MADT as possible cpu arm64: Add CPU hotplug support arch/arm64/kernel/acpi.c | 22 ++ arch/arm64/kernel/setup.c | 19 ++- arch/arm64/kernel/smp.c | 11 +-- drivers/acpi/scan.c | 12 4 files changed, 57 insertions(+), 7 deletions(-)
RE: [PATCHv5 02/20] PCI: mobiveil: Format the code without functionality change
Hi Lorenzo, Thanks for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月3日 23:19 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 02/20] PCI: mobiveil: Format the code without > functionality change > > On Fri, Apr 12, 2019 at 08:35:24AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > Just format the code without functionality change. > > > > Signed-off-by: Hou Zhiqiang > > Reviewed-by: Minghuan Lian > > --- > > V5: > > - Retouched the subject. > > > > drivers/pci/controller/pcie-mobiveil.c | 261 > > + > > 1 file changed, 137 insertions(+), 124 deletions(-) > > Ok, dropping this patch means that everything else should be rebased. So > what I am going to do: > > - I will publish a branch (pci/mobiveil) where I added the patches > that are ready to be merged with commit logs rewritten; this patch > is part of it but in the final version it must be split as requested. > - You have to split this patch and the other patches I requested > you to split but do NOT modify the patches with my commit logs > rewritten in pci/mobiveil, it took me time to rewrite them. Yes, will split them and won't modify the commit logs, and thanks a lot for your help! > > If you can manage to rebase patches on pci/mobiveil on top of v5.2-rc1, > send them separately so that I can merge them as a base for the subsequent > patches to be applied. You meant send the patches one by one, which you requested to split, and other patches without any changes can be send together, right? > > If you have any questions please ask, do not post patches if there is > something that is not clear. Yes, I'll, thanks for your guide again! B.R, Zhiqiang > > Lorenzo > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > > b/drivers/pci/controller/pcie-mobiveil.c > > index d55c7e780c6e..b87471f08a40 100644 > > --- a/drivers/pci/controller/pcie-mobiveil.c > > +++ b/drivers/pci/controller/pcie-mobiveil.c > > @@ -31,38 +31,40 @@ > > * translation tables are grouped into windows, each window registers > are > > * grouped into blocks of 4 or 16 registers each > > */ > > -#define PAB_REG_BLOCK_SIZE 16 > > -#define PAB_EXT_REG_BLOCK_SIZE 4 > > +#define PAB_REG_BLOCK_SIZE 16 > > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > -#define PAB_REG_ADDR(offset, win) (offset + (win * > > PAB_REG_BLOCK_SIZE)) -#define PAB_EXT_REG_ADDR(offset, win) (offset > + > > (win * PAB_EXT_REG_BLOCK_SIZE)) > > +#define PAB_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_REG_BLOCK_SIZE)) > > +#define PAB_EXT_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > -#define LTSSM_STATUS 0x0404 > > -#define LTSSM_STATUS_L0_MASK 0x3f > > -#define LTSSM_STATUS_L0 0x2d > > +#define LTSSM_STATUS 0x0404 > > +#define LTSSM_STATUS_L0_MASK 0x3f > > +#define LTSSM_STATUS_L0 0x2d > > > > -#define PAB_CTRL 0x0808 > > -#define AMBA_PIO_ENABLE_SHIFT 0 > > -#define PEX_PIO_ENABLE_SHIFT 1 > > -#define PAGE_SEL_SHIFT13 > > -#define PAGE_SEL_MASK 0x3f > > -#define PAGE_LO_MASK 0x3ff > > -#define PAGE_SEL_OFFSET_SHIFT 10 > > +#define PAB_CTRL 0x0808 > > +#define AMBA_PIO_ENABLE_SHIFT 0 > > +#define PEX_PIO_ENABLE_SHIFT 1 > > +#define PAGE_SEL_SHIFT13 > > +#define PAGE_SEL_MASK 0x3f > > +#define PAGE_LO_MASK 0x3ff > > +#define PAGE_SEL_OFFSET_SHIFT 10 > > > > -#define PAB_AXI_PIO_CTRL 0x0840 > > -#define APIO_EN_MASK 0xf > > +#define PAB_AXI_PIO_CTRL 0x0840 > > +#define APIO_EN_MASK 0xf > > > > -#define PAB_PEX_PIO_CTRL 0x08c0 > > -#define PIO_ENABLE_SHIFT 0 > > +#define PAB_PEX_PIO_CTRL 0x08c0 > > +#define PIO_ENABLE_SHIFT 0 > > > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > > -#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > +#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > #define PAB_INTP_INTX_MASK0x01e0 > > #define PAB_INTP_MSI_MASK 0x8 > > > > -#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > -#define WIN_ENABLE_SHIFT 0 > > -#define WIN_TYPE_SHIFT1 > > +#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > +#define WIN_ENABLE_SHIFT 0 > > +#define WIN_TYPE_SHIFT1 > > > > #define PAB_EXT_AXI_AMAP_SIZE(win) PAB_EXT_REG_ADDR(0xbaf0, > win) > > > > @@ -70,16 +72,16 @@ > > #define
[PATCH] net: ethernet: allwinner: Remove unneeded memset
Remove unneeded memset as alloc_etherdev is using kvzalloc which uses __GFP_ZERO flag Signed-off-by: Hariprasad Kelam --- drivers/net/ethernet/allwinner/sun4i-emac.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c index 9e06dff..6253e5e 100644 --- a/drivers/net/ethernet/allwinner/sun4i-emac.c +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c @@ -818,7 +818,6 @@ static int emac_probe(struct platform_device *pdev) SET_NETDEV_DEV(ndev, >dev); db = netdev_priv(ndev); - memset(db, 0, sizeof(*db)); db->dev = >dev; db->ndev = ndev; -- 2.7.4
linux-next: manual merge of the mlx5-next tree with the rdma tree
Hi all,
Today's linux-next merge of the mlx5-next tree got a conflict in:
drivers/infiniband/hw/mlx5/cq.c
between commit:
e39afe3d6dbd ("RDMA: Convert CQ allocations to be under core responsibility")
from the rdma tree and commit:
38164b771947 ("net/mlx5: mlx5_core_create_cq() enhancements")
from the mlx5-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/hw/mlx5/cq.c
index bfe3efdd77d7,4efbbd2fce0c..
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@@ -891,7 -891,8 +891,8 @@@ int mlx5_ib_create_cq(struct ib_cq *ibc
int entries = attr->cqe;
int vector = attr->comp_vector;
struct mlx5_ib_dev *dev = to_mdev(ibdev);
+ u32 out[MLX5_ST_SZ_DW(create_cq_out)];
- struct mlx5_ib_cq *cq;
+ struct mlx5_ib_cq *cq = to_mcq(ibcq);
int uninitialized_var(index);
int uninitialized_var(inlen);
u32 *cqb = NULL;
pgpKx7MjTZIi0.pgp
Description: OpenPGP digital signature
[PATCH] trace:add "gfp_t" support in synthetic_events
Add "gfp_t" support in synthetic_events, then the "gfp_t" type parameter in some functions can be traced. Signed-off-by: Zhengjun Xing --- kernel/trace/trace_events_hist.c | 4 1 file changed, 4 insertions(+) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index ca6b0dff60c5..0d3ab01b7cb5 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -752,6 +752,8 @@ static int synth_field_size(char *type) size = sizeof(unsigned long); else if (strcmp(type, "pid_t") == 0) size = sizeof(pid_t); + else if (strcmp(type, "gfp_t") == 0) + size = sizeof(gfp_t); else if (synth_field_is_string(type)) size = synth_field_string_size(type); @@ -792,6 +794,8 @@ static const char *synth_field_fmt(char *type) fmt = "%lu"; else if (strcmp(type, "pid_t") == 0) fmt = "%d"; + else if (strcmp(type, "gfp_t") == 0) + fmt = "%u"; else if (synth_field_is_string(type)) fmt = "%s"; -- 2.14.1
[PATCH] ACPI: PM: Make acpi_sleep_state_supported() non-static
With some upcoming patches to save/restore the Hyper-V drivers related
states, a Linux VM running on Hyper-V will be able to hibernate. When
a Linux VM hibernates, unluckily we must disable the memory hot-add/remove
and balloon up/down capabilities in the hv_balloon driver
(drivers/hv/hv_balloon.c), because these can not really work according to
the design of the related back-end driver on the host.
By default, Hyper-V does not enable the virtual ACPI S4 state for a VM;
on recent Hyper-V hosts, the administrator is able to enable the virtual
ACPI S4 state for a VM, so we hope to use the presence of the virtual ACPI
S4 state as a hint for hv_balloon to disable the aforementioned
capabilities. In this way, hibernation will work more reliably, from the
user's perspective.
By marking acpi_sleep_state_supported() non-static, we'll be able to
implement a hv_is_hibernation_supported() API in the always-built-in
module arch/x86/hyperv/hv_init.c, and the API will be called by hv_balloon.
Signed-off-by: Dexuan Cui
---
Previously I posted a version that tries to export the function:
https://lkml.org/lkml/2019/6/14/1077, which may be an overkill.
So I proposed a second patch (which covers this patch and shows how this
patch will be used): https://lkml.org/lkml/2019/6/19/861
I explained the situation in detail here: https://lkml.org/lkml/2019/6/21/63
(a correction: old Hyper-V hosts can support guest hibernation, but some
important functionalities in the host's management tool stack are missing).
There is no further reply in that discussion, so I'm sending this patch to
draw people's attention again. :-)
drivers/acpi/sleep.c| 2 +-
include/acpi/acpi_bus.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 8ff08e531443..d1ff303a857a 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -77,7 +77,7 @@ static int acpi_sleep_prepare(u32 acpi_state)
return 0;
}
-static bool acpi_sleep_state_supported(u8 sleep_state)
+bool acpi_sleep_state_supported(u8 sleep_state)
{
acpi_status status;
u8 type_a, type_b;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 31b6c87d6240..3e6563e1a2c0 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -651,6 +651,12 @@ static inline int acpi_pm_set_bridge_wakeup(struct device
*dev, bool enable)
}
#endif
+#ifdef CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT
+bool acpi_sleep_state_supported(u8 sleep_state);
+#else
+bool acpi_sleep_state_supported(u8 sleep_state) { return false; }
+#endif
+
#ifdef CONFIG_ACPI_SLEEP
u32 acpi_target_system_state(void);
#else
--
2.19.1
RE: [PATCHv5 02/20] PCI: mobiveil: Format the code without functionality change
Hi Lorenzo, Thanks for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月3日 23:10 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 02/20] PCI: mobiveil: Format the code without > functionality change > > On Fri, Apr 12, 2019 at 08:35:24AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > Just format the code without functionality change. > > > > Signed-off-by: Hou Zhiqiang > > Reviewed-by: Minghuan Lian > > --- > > V5: > > - Retouched the subject. > > > > drivers/pci/controller/pcie-mobiveil.c | 261 > > + > > 1 file changed, 137 insertions(+), 124 deletions(-) > > Again, I will drop this patch. You tend to do multiple changes in one single > patch, I understand this patch is just reformatting/renaming variables but at > least I would separate indentation changes from changes where eg you add > local variables. > > At least try to group the changes you are making instead of mixing them all > up. Yes, will spilt it. B.R, Zhiqiang > > Thanks, > Lorenzo > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > > b/drivers/pci/controller/pcie-mobiveil.c > > index d55c7e780c6e..b87471f08a40 100644 > > --- a/drivers/pci/controller/pcie-mobiveil.c > > +++ b/drivers/pci/controller/pcie-mobiveil.c > > @@ -31,38 +31,40 @@ > > * translation tables are grouped into windows, each window registers > are > > * grouped into blocks of 4 or 16 registers each > > */ > > -#define PAB_REG_BLOCK_SIZE 16 > > -#define PAB_EXT_REG_BLOCK_SIZE 4 > > +#define PAB_REG_BLOCK_SIZE 16 > > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > -#define PAB_REG_ADDR(offset, win) (offset + (win * > > PAB_REG_BLOCK_SIZE)) -#define PAB_EXT_REG_ADDR(offset, win) (offset > + > > (win * PAB_EXT_REG_BLOCK_SIZE)) > > +#define PAB_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_REG_BLOCK_SIZE)) > > +#define PAB_EXT_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > -#define LTSSM_STATUS 0x0404 > > -#define LTSSM_STATUS_L0_MASK 0x3f > > -#define LTSSM_STATUS_L0 0x2d > > +#define LTSSM_STATUS 0x0404 > > +#define LTSSM_STATUS_L0_MASK 0x3f > > +#define LTSSM_STATUS_L0 0x2d > > > > -#define PAB_CTRL 0x0808 > > -#define AMBA_PIO_ENABLE_SHIFT 0 > > -#define PEX_PIO_ENABLE_SHIFT 1 > > -#define PAGE_SEL_SHIFT13 > > -#define PAGE_SEL_MASK 0x3f > > -#define PAGE_LO_MASK 0x3ff > > -#define PAGE_SEL_OFFSET_SHIFT 10 > > +#define PAB_CTRL 0x0808 > > +#define AMBA_PIO_ENABLE_SHIFT 0 > > +#define PEX_PIO_ENABLE_SHIFT 1 > > +#define PAGE_SEL_SHIFT13 > > +#define PAGE_SEL_MASK 0x3f > > +#define PAGE_LO_MASK 0x3ff > > +#define PAGE_SEL_OFFSET_SHIFT 10 > > > > -#define PAB_AXI_PIO_CTRL 0x0840 > > -#define APIO_EN_MASK 0xf > > +#define PAB_AXI_PIO_CTRL 0x0840 > > +#define APIO_EN_MASK 0xf > > > > -#define PAB_PEX_PIO_CTRL 0x08c0 > > -#define PIO_ENABLE_SHIFT 0 > > +#define PAB_PEX_PIO_CTRL 0x08c0 > > +#define PIO_ENABLE_SHIFT 0 > > > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > > -#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > +#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > #define PAB_INTP_INTX_MASK0x01e0 > > #define PAB_INTP_MSI_MASK 0x8 > > > > -#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > -#define WIN_ENABLE_SHIFT 0 > > -#define WIN_TYPE_SHIFT1 > > +#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > +#define WIN_ENABLE_SHIFT 0 > > +#define WIN_TYPE_SHIFT1 > > > > #define PAB_EXT_AXI_AMAP_SIZE(win) PAB_EXT_REG_ADDR(0xbaf0, > win) > > > > @@ -70,16 +72,16 @@ > > #define AXI_WINDOW_ALIGN_MASK 3 > > > > #define PAB_AXI_AMAP_PEX_WIN_L(win)PAB_REG_ADDR(0x0ba8, > win) > > -#define PAB_BUS_SHIFT 24 > > -#define PAB_DEVICE_SHIFT 19 > > -#define PAB_FUNCTION_SHIFT16 > > +#define PAB_BUS_SHIFT 24 > > +#define PAB_DEVICE_SHIFT 19 > > +#define PAB_FUNCTION_SHIFT16 > > > > #define PAB_AXI_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x0bac, > win) > > #define PAB_INTP_AXI_PIO_CLASS 0x474 > > > > -#define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0, win) > > -#define AMAP_CTRL_EN_SHIFT0 > > -#define AMAP_CTRL_TYPE_SHIFT 1 > > +#define
RE: [PATCHv5 03/20] PCI: mobiveil: Correct the returned error number
Hi Lorenzo,
Thanks for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年7月3日 22:17
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 03/20] PCI: mobiveil: Correct the returned error
> number
>
> On Fri, Apr 12, 2019 at 08:35:30AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > This patch corrects the returned error number by convention, and
> > removes an unnecessary error check.
>
> Two distinct changes, two patches, please split and repost.
Yes, will split and rebase on the new branch.
Thanks,
Zhiqiang
>
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index b87471f08a40..563210e731d3 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -819,7 +819,7 @@ static int mobiveil_pcie_init_irq_domain(struct
> > mobiveil_pcie *pcie)
> >
> > if (!pcie->intx_domain) {
> > dev_err(dev, "Failed to get a INTx IRQ domain\n");
> > - return -ENODEV;
> > + return -ENOMEM;
> > }
> >
> > raw_spin_lock_init(>intx_mask_lock);
> > @@ -845,11 +845,9 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > /* allocate the PCIe port */
> > bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> > if (!bridge)
> > - return -ENODEV;
> > + return -ENOMEM;
> >
> > pcie = pci_host_bridge_priv(bridge);
> > - if (!pcie)
> > - return -ENOMEM;
> >
> > pcie->pdev = pdev;
> >
> > @@ -866,7 +864,7 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > >resources, );
> > if (ret) {
> > dev_err(dev, "Getting bridge resources failed\n");
> > - return -ENOMEM;
> > + return ret;
> > }
> >
> > /*
> > --
> > 2.17.1
> >
[Patch v2 10/10] platform/x86/asus-wmi: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/platform/x86/asus-wmi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 9b18a184e0aa..49049b02a015 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1353,8 +1353,7 @@ static umode_t asus_hwmon_sysfs_is_visible(struct kobject
*kobj,
struct attribute *attr, int idx)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct asus_wmi *asus = platform_get_drvdata(pdev);
+ struct asus_wmi *asus = dev_get_drvdata(dev->parent);
int dev_id = -1;
int fan_attr = -1;
u32 value = ASUS_WMI_UNSUPPORTED_METHOD;
--
2.11.0
[Patch v2 09/10] net/ethernet: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/net/ethernet/calxeda/xgmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/calxeda/xgmac.c
b/drivers/net/ethernet/calxeda/xgmac.c
index 11d4e91ea754..99f49d059414 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -1855,7 +1855,7 @@ static void xgmac_pmt(void __iomem *ioaddr, unsigned long
mode)
static int xgmac_suspend(struct device *dev)
{
- struct net_device *ndev = platform_get_drvdata(to_platform_device(dev));
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xgmac_priv *priv = netdev_priv(ndev);
u32 value;
@@ -1881,7 +1881,7 @@ static int xgmac_suspend(struct device *dev)
static int xgmac_resume(struct device *dev)
{
- struct net_device *ndev = platform_get_drvdata(to_platform_device(dev));
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xgmac_priv *priv = netdev_priv(ndev);
void __iomem *ioaddr = priv->base;
--
2.11.0
[Patch v2 08/10] net/can: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/net/can/softing/softing_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/softing/softing_main.c
b/drivers/net/can/softing/softing_main.c
index 68bb58a57f3b..8242fb287cbb 100644
--- a/drivers/net/can/softing/softing_main.c
+++ b/drivers/net/can/softing/softing_main.c
@@ -683,7 +683,7 @@ static void softing_netdev_cleanup(struct net_device
*netdev)
static ssize_t show_##name(struct device *dev, \
struct device_attribute *attr, char *buf) \
{ \
- struct softing *card = platform_get_drvdata(to_platform_device(dev)); \
+ struct softing *card = dev_get_drvdata(dev); \
return sprintf(buf, "%u\n", card->member); \
} \
static DEVICE_ATTR(name, 0444, show_##name, NULL)
@@ -692,7 +692,7 @@ static DEVICE_ATTR(name, 0444, show_##name, NULL)
static ssize_t show_##name(struct device *dev, \
struct device_attribute *attr, char *buf) \
{ \
- struct softing *card = platform_get_drvdata(to_platform_device(dev)); \
+ struct softing *card = dev_get_drvdata(dev); \
return sprintf(buf, "%s\n", card->member); \
} \
static DEVICE_ATTR(name, 0444, show_##name, NULL)
--
2.11.0
[Patch v2 05/10] iio: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/iio/adc/at91-sama5d2_adc.c | 12
drivers/iio/adc/at91_adc.c | 4 ++--
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
b/drivers/iio/adc/at91-sama5d2_adc.c
index d384cf0250ff..a2837a0e7cba 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -1578,8 +1578,7 @@ static void at91_adc_hw_init(struct at91_adc_state *st)
static ssize_t at91_adc_get_fifo_state(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct iio_dev *indio_dev =
- platform_get_drvdata(to_platform_device(dev));
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct at91_adc_state *st = iio_priv(indio_dev);
return scnprintf(buf, PAGE_SIZE, "%d\n", !!st->dma_st.dma_chan);
@@ -1588,8 +1587,7 @@ static ssize_t at91_adc_get_fifo_state(struct device *dev,
static ssize_t at91_adc_get_watermark(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct iio_dev *indio_dev =
- platform_get_drvdata(to_platform_device(dev));
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct at91_adc_state *st = iio_priv(indio_dev);
return scnprintf(buf, PAGE_SIZE, "%d\n", st->dma_st.watermark);
@@ -1841,8 +1839,7 @@ static int at91_adc_remove(struct platform_device *pdev)
static __maybe_unused int at91_adc_suspend(struct device *dev)
{
- struct iio_dev *indio_dev =
- platform_get_drvdata(to_platform_device(dev));
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct at91_adc_state *st = iio_priv(indio_dev);
/*
@@ -1862,8 +1859,7 @@ static __maybe_unused int at91_adc_suspend(struct device
*dev)
static __maybe_unused int at91_adc_resume(struct device *dev)
{
- struct iio_dev *indio_dev =
- platform_get_drvdata(to_platform_device(dev));
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct at91_adc_state *st = iio_priv(indio_dev);
int ret;
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index d23709ed9049..32f1c4a33b20 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -1359,7 +1359,7 @@ static int at91_adc_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int at91_adc_suspend(struct device *dev)
{
- struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
+ struct iio_dev *idev = dev_get_drvdata(dev);
struct at91_adc_state *st = iio_priv(idev);
pinctrl_pm_select_sleep_state(dev);
@@ -1370,7 +1370,7 @@ static int at91_adc_suspend(struct device *dev)
static int at91_adc_resume(struct device *dev)
{
- struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
+ struct iio_dev *idev = dev_get_drvdata(dev);
struct at91_adc_state *st = iio_priv(idev);
clk_prepare_enable(st->clk);
--
2.11.0
[Patch v2 07/10] mailbox: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/mailbox/bcm-flexrm-mailbox.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c
b/drivers/mailbox/bcm-flexrm-mailbox.c
index a64116586b4c..0cfdd53d04a1 100644
--- a/drivers/mailbox/bcm-flexrm-mailbox.c
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -1165,8 +1165,7 @@ static int flexrm_process_completions(struct flexrm_ring
*ring)
static int flexrm_debugfs_conf_show(struct seq_file *file, void *offset)
{
- struct platform_device *pdev = to_platform_device(file->private);
- struct flexrm_mbox *mbox = platform_get_drvdata(pdev);
+ struct flexrm_mbox *mbox = dev_get_drvdata(file->private);
/* Write config in file */
flexrm_write_config_in_seqfile(mbox, file);
@@ -1176,8 +1175,7 @@ static int flexrm_debugfs_conf_show(struct seq_file
*file, void *offset)
static int flexrm_debugfs_stats_show(struct seq_file *file, void *offset)
{
- struct platform_device *pdev = to_platform_device(file->private);
- struct flexrm_mbox *mbox = platform_get_drvdata(pdev);
+ struct flexrm_mbox *mbox = dev_get_drvdata(file->private);
/* Write stats in file */
flexrm_write_stats_in_seqfile(mbox, file);
--
2.11.0
[Patch v2 04/10] drm/panfrost: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 +++---
drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index db798532b0b6..bef5df4d99ac 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -18,7 +18,7 @@ static void panfrost_devfreq_update_utilization(struct
panfrost_device *pfdev, i
static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
{
- struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev));
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
struct dev_pm_opp *opp;
unsigned long old_clk_rate = pfdev->devfreq.cur_freq;
unsigned long target_volt, target_rate;
@@ -86,7 +86,7 @@ static void panfrost_devfreq_reset(struct panfrost_device
*pfdev)
static int panfrost_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
- struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev));
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
int i;
for (i = 0; i < NUM_JOB_SLOTS; i++) {
@@ -117,7 +117,7 @@ static int panfrost_devfreq_get_dev_status(struct device
*dev,
static int panfrost_devfreq_get_cur_freq(struct device *dev, unsigned long
*freq)
{
- struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev));
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
*freq = pfdev->devfreq.cur_freq;
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 3b2bced1b015..ed187648e6d8 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -227,8 +227,7 @@ const char *panfrost_exception_name(struct panfrost_device
*pfdev, u32 exception
#ifdef CONFIG_PM
int panfrost_device_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panfrost_device *pfdev = platform_get_drvdata(pdev);
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
panfrost_gpu_soft_reset(pfdev);
@@ -243,8 +242,7 @@ int panfrost_device_resume(struct device *dev)
int panfrost_device_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panfrost_device *pfdev = platform_get_drvdata(pdev);
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
if (!panfrost_job_is_idle(pfdev))
return -EBUSY;
--
2.11.0
[Patch v2 03/10] drm/omapdrm: using dev_get_drvdata directly
Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata().
To improve readability, these constructs can be simplified
by using dev_get_drvdata() directly.
Signed-off-by: Fuqian Huang
---
Changes in v2:
- Make the commit message more clearly.
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 8edef8ef23b0..53240da139b1 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -407,8 +407,7 @@ static const struct backlight_ops dsicm_bl_ops = {
static ssize_t dsicm_num_errors_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->src;
u8 errors = 0;
int r;
@@ -439,8 +438,7 @@ static ssize_t dsicm_num_errors_show(struct device *dev,
static ssize_t dsicm_hw_revision_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->src;
u8 id1, id2, id3;
int r;
@@ -506,8 +504,7 @@ static ssize_t dsicm_show_ulps(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct panel_drv_data *ddata = dev_get_drvdata(dev);
unsigned int t;
mutex_lock(>lock);
@@ -521,8 +518,7 @@ static ssize_t dsicm_store_ulps_timeout(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->src;
unsigned long t;
int r;
@@ -553,8 +549,7 @@ static ssize_t dsicm_show_ulps_timeout(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct panel_drv_data *ddata = dev_get_drvdata(dev);
unsigned int t;
mutex_lock(>lock);
--
2.11.0
RE: [PATCHv5 00/20] PCI: mobiveil: fixes for Mobiveil PCIe Host Bridge IP driver
Hi Lorenzo, Thanks a lot for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月3日 18:33 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 00/20] PCI: mobiveil: fixes for Mobiveil PCIe Host > Bridge IP driver > > On Fri, Apr 12, 2019 at 08:35:11AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > This patch set is to add fixes for Mobiveil PCIe Host driver. > > And these patches are splited from the thread below: > > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch > > > work.ozlabs.org%2Fproject%2Flinux-pci%2Flist%2F%3Fseries%3D96417 > p;d > > > ata=02%7C01%7Czhiqiang.hou%40nxp.com%7C0d32165274bf4c678b4808d > 6ffa1e42 > > > f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63697746817272 > 2471 > > > sdata=RLgfyNRBIRePuLFTCQe4RQYleeXDevwtVN4I6ZFkS1s%3Dreserv > ed=0 > > > > Hou Zhiqiang (20): > > PCI: mobiveil: Unify register accessors > > PCI: mobiveil: Format the code without functionality change > > PCI: mobiveil: Correct the returned error number > > PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI > > PCI: mobiveil: Correct PCI base address in MEM/IO outbound windows > > PCI: mobiveil: Replace the resource list iteration function > > PCI: mobiveil: Use WIN_NUM_0 explicitly for CFG outbound window > > PCI: mobiveil: Use the 1st inbound window for MEM inbound > transactions > > PCI: mobiveil: Correct inbound/outbound window setup routines > > PCI: mobiveil: Fix the INTx process errors > > PCI: mobiveil: Correct the fixup of Class Code field > > PCI: mobiveil: Move the link up waiting out of mobiveil_host_init() > > PCI: mobiveil: Move IRQ chained handler setup out of DT parse > > PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers > > PCI: mobiveil: Fix the checking of valid device > > PCI: mobiveil: Add link up condition check > > PCI: mobiveil: Complete initialization of host even if no PCIe link > > PCI: mobiveil: Disable IB and OB windows set by bootloader > > PCI: mobiveil: Add 8-bit and 16-bit register accessors > > dt-bindings: PCI: mobiveil: Change gpio_slave and apb_csr to > > optional > > > > .../devicetree/bindings/pci/mobiveil-pcie.txt | 2 + > > drivers/pci/controller/pcie-mobiveil.c| 578 +++--- > > 2 files changed, 368 insertions(+), 212 deletions(-) > > I am putting together a branch with the patches I would like to queue, for > the ones I requested to split please wait for me, I will publish the branch > and > will ask you to rebase on top of it. > Ok, will split them and rebase on the new branch. Thanks, Zhiqiang > Lorenzo
[PATCH] rtc: pcf85063: Add support for specifying the clkout frequency from device tree node.
Primarily this allows the clkout signal to be disabled and save some
power when running off battery backup. However, all hardware implemented
values are implemented. Uses default value of 32768Hz if node is not
specified.
Signed-off-by: Michael McCormick
---
drivers/rtc/rtc-pcf85063.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index 1afa6d9fa9fb..5c19381899ed 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/drivers/rtc/rtc-pcf85063.c
@@ -37,6 +37,9 @@
#define PCF85063_REG_CTRL2 0x01
#define PCF85063_CTRL2_AF BIT(6)
#define PCF85063_CTRL2_AIE BIT(7)
+#define PCF85063_CTRL2_COF2BIT(2)
+#define PCF85063_CTRL2_COF1BIT(1)
+#define PCF85063_CTRL2_COF0BIT(0)
#define PCF85063_REG_OFFSET0x02
#define PCF85063_OFFSET_SIGN_BIT 6 /* 2's complement sign bit */
@@ -369,6 +372,51 @@ static int pcf85063_load_capacitance(struct pcf85063
*pcf85063,
PCF85063_REG_CTRL1_CAP_SEL, reg);
}
+static int pcf85063_set_clkout_mode(struct pcf85063 *pcf85063,
+ const struct device_node *np)
+{
+ u32 load = 32768;
+ u8 reg = 0;
+
+ of_property_read_u32(np, "clockout-frequency", );
+ switch (load) {
+ case 0:
+ reg = PCF85063_CTRL2_COF2 | PCF85063_CTRL2_COF1 |
+ PCF85063_CTRL2_COF0;
+ break;
+ case 1:
+ reg = PCF85063_CTRL2_COF2 | PCF85063_CTRL2_COF1;
+ break;
+ case 1024:
+ reg = PCF85063_CTRL2_COF2 | PCF85063_CTRL2_COF0;
+ break;
+ case 2048:
+ reg = PCF85063_CTRL2_COF2;
+ break;
+ case 4096:
+ reg = PCF85063_CTRL2_COF1 | PCF85063_CTRL2_COF0;
+ break;
+ case 8192:
+ reg = PCF85063_CTRL2_COF1;
+ break;
+ case 16384:
+ reg = PCF85063_CTRL2_COF0;
+ break;
+ case 32768:
+ reg = 0;
+ break;
+ default:
+ dev_warn(>rtc->dev,
+ "Unknown clockout-frequency: %d. Assuming 32768", load);
+ reg = 0;
+ break;
+ }
+
+ return regmap_update_bits(pcf85063->regmap, PCF85063_REG_CTRL2,
+ PCF85063_CTRL2_COF2 | PCF85063_CTRL2_COF1 |
+ PCF85063_CTRL2_COF0, reg);
+}
+
static const struct pcf85063_config pcf85063a_config = {
.regmap = {
.reg_bits = 8,
@@ -443,6 +491,10 @@ static int pcf85063_probe(struct i2c_client *client)
dev_warn(>dev, "failed to set xtal load capacitance:
%d",
err);
+ err = pcf85063_set_clkout_mode(pcf85063, client->dev.of_node);
+ if (err < 0)
+ dev_warn(>dev, "failed to set clock out mode: %d", err);
+
pcf85063->rtc->ops = _rtc_ops;
pcf85063->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
pcf85063->rtc->range_max = RTC_TIMESTAMP_END_2099;
--
2.17.1
**CONFIDENTIALITY STATEMENT**
This message is intended for the sole use of the individual(s) and/or entity to
whom it is addressed, and may contain information that is legally privileged,
confidential, and exempt from disclosure under applicable law. If you are not
the intended addressee, nor authorized to receive for the intended addressee,
you are hereby notified that dissemination, distribution, copying or disclosure
of this message is strictly prohibited. If you have received this message in
error please immediately advise the sender by reply email, and delete the
message.
Re: [PATCH] soc: rockchip: work around clang warning
On Wed, Jul 03, 2019 at 05:30:59PM +0200, Arnd Bergmann wrote: > clang emits a warning about a negative shift count for an > unused part of a conditional constant expression: > > drivers/soc/rockchip/pm_domains.c:795:21: error: shift count is negative > [-Werror,-Wshift-count-negative] > [RK3328_PD_VIO] = DOMAIN_RK3328(-1, 8, 8, false), > ^~ > drivers/soc/rockchip/pm_domains.c:129:2: note: expanded from macro > 'DOMAIN_RK3328' > DOMAIN_M(pwr, pwr, req, (req) + 10, req, wakeup) > ^~~~ > drivers/soc/rockchip/pm_domains.c:105:33: note: expanded from macro 'DOMAIN_M' > .status_mask = (status >= 0) ? BIT(status) : 0, \ >^~~ > include/linux/bits.h:6:24: note: expanded from macro 'BIT' > > This is a bug in clang that will be fixed in the future, but in order > to build cleanly with clang-8, it would be helpful to shut up this > warning. This file is the only instance reported by kernelci at the > moment. > > The best solution I could come up with is to move the BIT() usage > out of the macro into the instantiation, so we can avoid using > BIT(-1). > > Link: https://bugs.llvm.org/show_bug.cgi?id=38789 > Signed-off-by: Arnd Bergmann Thanks, queued under arm/drivers now. -Olof
[PATCH v3] locking/spinlocks, paravirt, hyperv: Correct the hv_nopvspin case
With the boot parameter "hv_nopvspin" specified a Hyperv guest should
not make use of paravirt spinlocks, but behave as if running on bare
metal. This is not true, however, as the qspinlock code will fall back
to a test-and-set scheme when it is detecting a hypervisor.
In order to avoid this disable the virt_spin_lock_key.
Same change for XEN is already in Commit e6fd28eb3522
("locking/spinlocks, paravirt, xen: Correct the xen_nopvspin case")
Signed-off-by: Zhenzhong Duan
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Sasha Levin
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: linux-hyp...@vger.kernel.org
---
v3: remove unlikely() as suggested by Sasha
arch/x86/hyperv/hv_spinlock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index 07f21a0..210495b 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -64,6 +64,9 @@ __visible bool hv_vcpu_is_preempted(int vcpu)
void __init hv_init_spinlocks(void)
{
+ if (!hv_pvspin)
+ static_branch_disable(_spin_lock_key);
+
if (!hv_pvspin || !apic ||
!(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
!(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {
--
1.8.3.1
Re: [GIT PULL] tracing: A few fixes for this rc release
The pull request you sent on Wed, 3 Jul 2019 10:55:11 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > trace-v5.2-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/550d1f5bda33fa3b203d8cf8df1396825dbfd213 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] GPIO fix for v5.2
The pull request you sent on Wed, 3 Jul 2019 14:30:51 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > tags/gpio-v5.2-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/179c96d9f715a619811ded5dcbd35b1fee8caf69 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: linux-next: build failure after merge of the rdma tree
在 2019/7/4 10:04, Jason Gunthorpe 写道:
> On Thu, Jul 04, 2019 at 12:02:35PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 1 Jul 2019 14:14:31 +1000 Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> After merging the rdma tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> WARNING: modpost: missing MODULE_LICENSE() in
>>> drivers/infiniband/hw/hns/hns_roce_ah.o
>>> see include/linux/module.h for more information
>> .
>> .
>> .
>>> ERROR: "hns_roce_bitmap_cleanup"
>>> [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined!
>> .
>> .
>> .
>>> ERROR: "hns_roce_ib_destroy_cq"
>>> [drivers/infiniband/hw/hns/hns-roce-hw-v1.ko] undefined!
>>>
>>> Presumably caused by commit
>>>
>>> e9816ddf2a33 ("RDMA/hns: Cleanup unnecessary exported symbols")
>>>
>>> I have used the rdma tree from next-20190628 for today.
>> I am still getting these errors/warnings.
> I have not got a fixing patch from HNS team.
>
> At this late date I will revert the problematic HNS patch tomorrow.
>
> Jason
Hi， Jason
Sorry, our guys may not see your mail in time. I will fix it and send a
email in today.
Thanks
Lijun Ou
> .
>
RE: [EXT] [BUG BISECT] Net boot fails on VF50 after "dmaengine: fsl-edma: support little endian for edma driver"
Hi Krzysztof, I am sorry, It is my mistake to forget about VF50 used EDMA IP with little endian. The Register(CHCFG0 - CHCFG15) of our platform designed as follows: *---* | Offset | Big endian Register| Little endian Register| |-|--|-| | 0x0 | CHCFG0| CHCFG3 | |-|--|-| | 0x1 | CHCFG1| CHCFG2 | |-|--|-| | 0x2 | CHCFG2| CHCFG1 | |-|--|-| | 0x3 | CHCFG3| CHCFG0 | |-|--|-| | ... |.. | .. | |-|--|-| | 0xC | CHCFG12 | CHCFG15 | |-|--|-| | 0xD | CHCFG13 | CHCFG14 | |-|--|-| | 0xE | CHCFG14 | CHCFG13 | |-|--|-| | 0xF | CHCFG15 | CHCFG12 | *---* So we need this patch, I make some changes,Please help me to test attatchment on VF50 board, Thanks. Best Regards, Peng >-Original Message- >From: Krzysztof Kozłowski >Sent: 2019年7月2日 20:13 >To: Peng Ma ; Vinod Koul ; >dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org >Subject: [EXT] [BUG BISECT] Net boot fails on VF50 after "dmaengine: >fsl-edma: support little endian for edma driver" > >Caution: EXT Email > >Hi, > >Bisect pointed commit: >commit 002905eca5bedab08bafd9e32541670c7712 >Author: Peng Ma >Date: Thu Jun 13 10:27:08 2019 + >dmaengine: fsl-edma: support little endian for edma driver > >as a reason of NFSv4 root boot failures. Toradex Colibri VF50 (Cortex >A5) on Toradex Iris board. > >The user-space starts but hangs - a lot of messages are missing or seriously >delayed. > >Please revert the patch of fix it. If needed I can provide more details about >test >system - let me know. > >Full log attached. > >Best regards, >Krzysztof 0001-dmaengine-fsl-edma-support-little-endian-for-edma-dr.patch Description: 0001-dmaengine-fsl-edma-support-little-endian-for-edma-dr.patch
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/net/config
between commit:
ff95bf28c234 ("selftests/net: skip psock_tpacket test if KALLSYMS was not
enabled")
from the net tree and commit:
af5136f95045 ("selftests/net: SO_TXTIME with ETF and FQ")
509e56b37cc3 ("blackhole_dev: add a selftest")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/config
index 3dea2cba2325,e4b878d95ba0..
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@@ -25,4 -25,6 +25,7 @@@ CONFIG_NF_TABLES_IPV6=
CONFIG_NF_TABLES_IPV4=y
CONFIG_NFT_CHAIN_NAT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
+CONFIG_KALLSYMS=y
+ CONFIG_NET_SCH_FQ=m
+ CONFIG_NET_SCH_ETF=m
+ CONFIG_TEST_BLACKHOLE_DEV=m
pgpDArhwaPWli.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the rdma tree
On Thu, Jul 04, 2019 at 12:02:35PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 1 Jul 2019 14:14:31 +1000 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the rdma tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > WARNING: modpost: missing MODULE_LICENSE() in
> > drivers/infiniband/hw/hns/hns_roce_ah.o
> > see include/linux/module.h for more information
> .
> .
> .
> > ERROR: "hns_roce_bitmap_cleanup"
> > [drivers/infiniband/hw/hns/hns_roce_srq.ko] undefined!
> .
> .
> .
> > ERROR: "hns_roce_ib_destroy_cq"
> > [drivers/infiniband/hw/hns/hns-roce-hw-v1.ko] undefined!
> >
> > Presumably caused by commit
> >
> > e9816ddf2a33 ("RDMA/hns: Cleanup unnecessary exported symbols")
> >
> > I have used the rdma tree from next-20190628 for today.
>
> I am still getting these errors/warnings.
I have not got a fixing patch from HNS team.
At this late date I will revert the problematic HNS patch tomorrow.
Jason
Re: linux-next: build failure after merge of the rdma tree
Hi all,
On Mon, 1 Jul 2019 14:14:31 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/infiniband/hw/hns/hns_roce_ah.o
> see include/linux/module.h for more information
.
.
.
> ERROR: "hns_roce_bitmap_cleanup" [drivers/infiniband/hw/hns/hns_roce_srq.ko]
> undefined!
.
.
.
> ERROR: "hns_roce_ib_destroy_cq" [drivers/infiniband/hw/hns/hns-roce-hw-v1.ko]
> undefined!
>
> Presumably caused by commit
>
> e9816ddf2a33 ("RDMA/hns: Cleanup unnecessary exported symbols")
>
> I have used the rdma tree from next-20190628 for today.
I am still getting these errors/warnings.
--
Cheers,
Stephen Rothwell
pgpLRgdEXnWcm.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] ftrace/selftest: Test if set_event/ftrace_pid exists before writing
On Thu, 4 Jul 2019 10:51:26 +0900
Masami Hiramatsu wrote:
> > > diff --git a/tools/testing/selftests/ftrace/test.d/functions
> > > b/tools/testing/selftests/ftrace/test.d/functions
> > > index 779ec11f61bd..a7b06291e32c 100644
> > > --- a/tools/testing/selftests/ftrace/test.d/functions
> > > +++ b/tools/testing/selftests/ftrace/test.d/functions
> > > @@ -91,8 +91,8 @@ initialize_ftrace() { # Reset ftrace to initial-state
> > > reset_events_filter
> > > reset_ftrace_filter
> > > disable_events
> > > -echo > set_event_pid # event tracer is always on
> > > -echo > set_ftrace_pid
> > > +[ -f set_event_pid ] && echo > set_event_pid # event tracer is
> > > always on
> >
> > I probably should remove that comment, because I believe that was why
> > it wasn't tested :-/
>
> Hmm, OK. I think this comment means "the event tracer is always on if clearing
> set_event_pid filter". Would this need to be removed?
When this was added in commit 131f840d5b7 ("selftests: ftrace:
Initialize ftrace before each test"), we had this:
+echo > set_event_pid # event tracer is always on
+[ -f set_ftrace_filter ] && echo | tee set_ftrace_*
+[ -f set_graph_function ] && echo | tee set_graph_*
+[ -f stack_trace_filter ] && echo > stack_trace_filter
+[ -f kprobe_events ] && echo > kprobe_events
+[ -f uprobe_events ] && echo > uprobe_events
Where set_event_pid is the only file not tested for existence. I
figured that comment was the reason for not testing it. If that was the
case, then adding a test, I would think we should remove the comment.
Do you agree?
-- Steve
>
> Thank you,
>
> >
> > -- Steve
> >
> >
> > > +[ -f set_ftrace_pid ] && echo > set_ftrace_pid
> > > [ -f set_ftrace_filter ] && echo | tee set_ftrace_*
> > > [ -f set_graph_function ] && echo | tee set_graph_*
> > > [ -f stack_trace_filter ] && echo > stack_trace_filter
> >
>
>
Re: [PATCH 2/2] ftrace/selftest: Test if set_event/ftrace_pid exists before writing
On Wed, 3 Jul 2019 16:00:09 -0400
Steven Rostedt wrote:
> On Wed, 03 Jul 2019 15:50:01 -0400
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (VMware)"
> >
> > While testing on a very old kernel (3.5), the tests failed because the write
> > to set_event_pid in the setup code, did not exist. The tests themselves
> > could pass, but the setup failed causing an error.
> >
> > Other files test for existance before writing to them. Do the same for
> > set_event_pid and set_ftrace_pid.
> >
> > Signed-off-by: Steven Rostedt (VMware)
> > ---
> > tools/testing/selftests/ftrace/test.d/functions | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/ftrace/test.d/functions
> > b/tools/testing/selftests/ftrace/test.d/functions
> > index 779ec11f61bd..a7b06291e32c 100644
> > --- a/tools/testing/selftests/ftrace/test.d/functions
> > +++ b/tools/testing/selftests/ftrace/test.d/functions
> > @@ -91,8 +91,8 @@ initialize_ftrace() { # Reset ftrace to initial-state
> > reset_events_filter
> > reset_ftrace_filter
> > disable_events
> > -echo > set_event_pid # event tracer is always on
> > -echo > set_ftrace_pid
> > +[ -f set_event_pid ] && echo > set_event_pid # event tracer is always
> > on
>
> I probably should remove that comment, because I believe that was why
> it wasn't tested :-/
Hmm, OK. I think this comment means "the event tracer is always on if clearing
set_event_pid filter". Would this need to be removed?
Thank you,
>
> -- Steve
>
>
> > +[ -f set_ftrace_pid ] && echo > set_ftrace_pid
> > [ -f set_ftrace_filter ] && echo | tee set_ftrace_*
> > [ -f set_graph_function ] && echo | tee set_graph_*
> > [ -f stack_trace_filter ] && echo > stack_trace_filter
>
--
Masami Hiramatsu
Re: [PATCH 2/2] ftrace/selftest: Test if set_event/ftrace_pid exists before writing
On Wed, 03 Jul 2019 15:50:01 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> While testing on a very old kernel (3.5), the tests failed because the write
> to set_event_pid in the setup code, did not exist. The tests themselves
> could pass, but the setup failed causing an error.
>
Oops, I've missed it.
> Other files test for existance before writing to them. Do the same for
> set_event_pid and set_ftrace_pid.
Looks good to me,
Acked-by: Masami Hiramatsu
Thank you!
>
> Signed-off-by: Steven Rostedt (VMware)
> ---
> tools/testing/selftests/ftrace/test.d/functions | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/ftrace/test.d/functions
> b/tools/testing/selftests/ftrace/test.d/functions
> index 779ec11f61bd..a7b06291e32c 100644
> --- a/tools/testing/selftests/ftrace/test.d/functions
> +++ b/tools/testing/selftests/ftrace/test.d/functions
> @@ -91,8 +91,8 @@ initialize_ftrace() { # Reset ftrace to initial-state
> reset_events_filter
> reset_ftrace_filter
> disable_events
> -echo > set_event_pid # event tracer is always on
> -echo > set_ftrace_pid
> +[ -f set_event_pid ] && echo > set_event_pid # event tracer is always on
> +[ -f set_ftrace_pid ] && echo > set_ftrace_pid
> [ -f set_ftrace_filter ] && echo | tee set_ftrace_*
> [ -f set_graph_function ] && echo | tee set_graph_*
> [ -f stack_trace_filter ] && echo > stack_trace_filter
> --
> 2.20.1
>
>
--
Masami Hiramatsu
Re: [PATCH 1/2] ftrace/selftests: Return the skip code when tracing directory not configured in kernel
On Wed, 03 Jul 2019 15:50:00 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> If the kernel is not configured with ftrace enabled, the ftracetest
> selftests should return the error code of "4" as that is the kselftests
> "skip" code, and not "1" which means an error.
>
> To determine if ftrace is enabled, first the newer "tracefs" is searched for
> in /proc/mounts. If it is not found, then "debugfs" is searched for (as old
> kernels do not have tracefs). If that is not found, an attempt to mount the
> tracefs or debugfs is performed. This is done by seeing first if the
> /sys/kernel/tracing directory exists. If it does than tracefs is configured
> in the kernel and an attempt to mount it is performed.
>
> If /sys/kernel/tracing does not exist, then /sys/kernel/debug is tested to
> see if that directory exists. If it does, then an attempt to mount debugfs
> on that directory is performed. If it does not exist, then debugfs is not
> configured in the running kernel and the test exits with the skip code.
>
> If either mount fails, then a normal error is returned as they do exist in
> the kernel but something went wrong to mount them.
>
> This changes the test to always try the tracefs file system first as it has
> been in the kernel for some time now and it is better to test it if it is
> available instead of always testing debugfs.
>
> Link: http://lkml.kernel.org/r/20190702062358.7330-1-po-hsu@canonical.com
>
> Reported-by: Po-Hsu Lin
> Signed-off-by: Steven Rostedt (VMware)
> ---
> tools/testing/selftests/ftrace/ftracetest | 38 +++
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/tools/testing/selftests/ftrace/ftracetest
> b/tools/testing/selftests/ftrace/ftracetest
> index 136387422b00..edf5ea35d2a7 100755
> --- a/tools/testing/selftests/ftrace/ftracetest
> +++ b/tools/testing/selftests/ftrace/ftracetest
> @@ -23,9 +23,15 @@ echo " If is -, all logs
> output in console only"
> exit $1
> }
>
> +# default error
> +err_ret=1
> +
> +# kselftest skip code is 4
> +err_skip=4
> +
> errexit() { # message
>echo "Error: $1" 1>&2
> - exit 1
> + exit $err_ret
> }
>
> # Ensuring user privilege
> @@ -116,11 +122,31 @@ parse_opts() { # opts
> }
>
> # Parameters
> -DEBUGFS_DIR=`grep debugfs /proc/mounts | cut -f2 -d' ' | head -1`
> -if [ -z "$DEBUGFS_DIR" ]; then
> -TRACING_DIR=`grep tracefs /proc/mounts | cut -f2 -d' ' | head -1`
> -else
> -TRACING_DIR=$DEBUGFS_DIR/tracing
> +TRACING_DIR=`grep tracefs /proc/mounts | cut -f2 -d' ' | head -1`
> +if [ -z "$TRACING_DIR" ]; then
> +DEBUGFS_DIR=`grep debugfs /proc/mounts | cut -f2 -d' ' | head -1`
> +if [ -z "$DEBUGFS_DIR" ]; then
> + # If tracefs exists, then so does /sys/kernel/tracing
Ah, indeed. the mount point also may not exist on older kernel.
OK, this looks good to me.
Acked-by: Masami Hiramatsu
Thank you!
> + if [ -d "/sys/kernel/tracing" ]; then
> + mount -t tracefs nodev /sys/kernel/tracing ||
> + errexit "Failed to mount /sys/kernel/tracing"
> + TRACING_DIR="/sys/kernel/tracing"
> + # If debugfs exists, then so does /sys/kernel/debug
> + elif [ -d "/sys/kernel/debug" ]; then
> + mount -t debugfs nodev /sys/kernel/debug ||
> + errexit "Failed to mount /sys/kernel/debug"
> + TRACING_DIR="/sys/kernel/debug/tracing"
> + else
> + err_ret=$err_skip
> + errexit "debugfs and tracefs are not configured in this kernel"
> + fi
> +else
> + TRACING_DIR="$DEBUGFS_DIR/tracing"
> +fi
> +fi
> +if [ ! -d "$TRACING_DIR" ]; then
> +err_ret=$err_skip
> +errexit "ftrace is not configured in this kernel"
> fi
>
> TOP_DIR=`absdir $0`
> --
> 2.20.1
>
>
--
Masami Hiramatsu
Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
On Wed, Jul 03, 2019 at 12:31:57PM -0600, Alex Williamson wrote:
> On Wed, 3 Jul 2019 17:13:39 +0800
> Tiwei Bie wrote:
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 8f10748dac79..6c5718ab7eeb 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -201,6 +201,7 @@ struct vfio_device_info {
> > #define VFIO_DEVICE_FLAGS_AMBA (1 << 3) /* vfio-amba device */
> > #define VFIO_DEVICE_FLAGS_CCW (1 << 4)/* vfio-ccw device */
> > #define VFIO_DEVICE_FLAGS_AP (1 << 5)/* vfio-ap device */
> > +#define VFIO_DEVICE_FLAGS_VHOST(1 << 6)/* vfio-vhost device */
> > __u32 num_regions;/* Max region index + 1 */
> > __u32 num_irqs; /* Max IRQ index + 1 */
> > };
> > @@ -217,6 +218,7 @@ struct vfio_device_info {
> > #define VFIO_DEVICE_API_AMBA_STRING"vfio-amba"
> > #define VFIO_DEVICE_API_CCW_STRING "vfio-ccw"
> > #define VFIO_DEVICE_API_AP_STRING "vfio-ap"
> > +#define VFIO_DEVICE_API_VHOST_STRING "vfio-vhost"
> >
> > /**
> > * VFIO_DEVICE_GET_REGION_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 8,
> > @@ -573,6 +575,23 @@ enum {
> > VFIO_CCW_NUM_IRQS
> > };
> >
> > +/*
> > + * The vfio-vhost bus driver makes use of the following fixed region and
> > + * IRQ index mapping. Unimplemented regions return a size of zero.
> > + * Unimplemented IRQ types return a count of zero.
> > + */
> > +
> > +enum {
> > + VFIO_VHOST_CONFIG_REGION_INDEX,
> > + VFIO_VHOST_NOTIFY_REGION_INDEX,
> > + VFIO_VHOST_NUM_REGIONS
> > +};
> > +
> > +enum {
> > + VFIO_VHOST_VQ_IRQ_INDEX,
> > + VFIO_VHOST_NUM_IRQS
> > +};
> > +
>
> Note that the vfio API has evolved a bit since vfio-pci started this
> way, with fixed indexes for pre-defined region types. We now support
> device specific regions which can be identified by a capability within
> the REGION_INFO ioctl return data. This allows a bit more flexibility,
> at the cost of complexity, but the infrastructure already exists in
> kernel and QEMU to make it relatively easy. I think we'll have the
> same support for interrupts soon too. If you continue to pursue the
> vfio-vhost direction you might want to consider these before committing
> to fixed indexes. Thanks,
Thanks for the details! Will give it a try!
Thanks,
Tiwei
RE: [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
> > @@ -155,22 +171,26 @@ static int stmmac_mdio_read(struct mii_bus *bus,
> int phyaddr, int phyreg)
> > struct stmmac_priv *priv = netdev_priv(ndev);
> > unsigned int mii_address = priv->hw->mii.addr;
> > unsigned int mii_data = priv->hw->mii.data;
> > - u32 v;
> > - int data;
> > u32 value = MII_BUSY;
> > + int data = 0;
> > + u32 v;
> >
> > value |= (phyaddr << priv->hw->mii.addr_shift)
> > & priv->hw->mii.addr_mask;
> > value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw-
> >mii.reg_mask;
> > value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
> > & priv->hw->mii.clk_csr_mask;
> > - if (priv->plat->has_gmac4)
> > + if (priv->plat->has_gmac4) {
> > value |= MII_GMAC4_READ;
> > + if (phyreg & MII_ADDR_C45)
> > + stmmac_mdio_c45_setup(priv, phyreg, , );
> > + }
> >
> > if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v &
> MII_BUSY),
> >100, 1))
> > return -EBUSY;
> >
> > + writel(data, priv->ioaddr + mii_data);
>
> That looks odd. Could you explain why it is needed.
>
> Thanks
> Andrew
Hi Andrew,
This mdio c45 support needed to access DWC xPCS which is a Clause-45
MDIO Manageable Device (MMD). This is discuss in:
https://patchwork.ozlabs.org/patch/1109776/
https://patchwork.ozlabs.org/patch/1109777/
Since the patch is still WIP to make the xPCS as PHY driver for SGMII
to RGMII converter. So i decided to upstream this patch first.
Biao Huang also needed this patch and tested pass with this patch on
their platform.
https://patchwork.ozlabs.org/patch/1103861/
Biao Huang's patch on MDIO-c45 access
https://patchwork.ozlabs.org/patch/1092436/
Regards,
Weifeng
Re: [PATCH -next] integrity: Remove set but not used variable 'acl'
On 2019/7/3 21:57, David Howells wrote: > YueHaibing wrote: > >> Fixes gcc '-Wunused-but-set-variable' warning: >> >> security/integrity/digsig.c: In function 'integrity_init_keyring': >> security/integrity/digsig.c:99:18: warning: >> variable 'acl' set but not used [-Wunused-but-set-variable] >> >> It seems 'acl' is needed in __integrity_init_keyring > > I've folded this fix in, thanks. Thanks, also I write a wrong patch title. > > David > > . >
[PATCH v5 2/4] x86: Add "nopv" parameter to disable PV extensions
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. We have "xen_nopv" for that purpose
but only for XEN. For a consistent admin experience a common command
line parameter "nopv" set across all PV guest implementations is a
better choice.
There are guest types which just won't work without PV extensions,
like Xen PV, Xen PVH and jailhouse. add a "ignore_nopv" member to
struct hypervisor_x86 set to true for those guest types and call
the detect functions only if nopv is false or ignore_nopv is true.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Jan Kiszka
Cc: Boris Ostrovsky
Cc: Stefano Stabellini
---
Documentation/admin-guide/kernel-parameters.txt | 5 +
arch/x86/include/asm/hypervisor.h | 4
arch/x86/kernel/cpu/hypervisor.c| 11 +++
arch/x86/kernel/jailhouse.c | 1 +
arch/x86/xen/enlighten_pv.c | 1 +
5 files changed, 22 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 138f666..21e08af 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5268,6 +5268,11 @@
improve timer resolution at the expense of processing
more timer interrupts.
+ nopv= [X86,XEN,KVM,HYPER_V,VMWARE]
+ Disables the PV optimizations forcing the guest to run
+ as generic guest with no PV drivers. Currently support
+ XEN HVM, KVM, HYPER_V and VMWARE guest.
+
xirc2ps_cs= [NET,PCMCIA]
Format:
,[,[,[,]]]
diff --git a/arch/x86/include/asm/hypervisor.h
b/arch/x86/include/asm/hypervisor.h
index 8c5aaba..00240b0 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -52,8 +52,12 @@ struct hypervisor_x86 {
/* runtime callbacks */
struct x86_hyper_runtime runtime;
+
+ /* ignore nopv parameter */
+ bool ignore_nopv;
};
+extern bool nopv;
extern enum x86_hypervisor_type x86_hyper_type;
extern void init_hypervisor_platform(void);
static inline bool hypervisor_is_type(enum x86_hypervisor_type type)
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 479ca47..337ff07 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -54,6 +54,14 @@
enum x86_hypervisor_type x86_hyper_type;
EXPORT_SYMBOL(x86_hyper_type);
+bool __initdata nopv;
+static __init int parse_nopv(char *arg)
+{
+ nopv = true;
+ return 0;
+}
+early_param("nopv", parse_nopv);
+
static inline const struct hypervisor_x86 * __init
detect_hypervisor_vendor(void)
{
@@ -61,6 +69,9 @@
uint32_t pri, max_pri = 0;
for (p = hypervisors; p < hypervisors + ARRAY_SIZE(hypervisors); p++) {
+ if (unlikely(nopv) && !(*p)->ignore_nopv)
+ continue;
+
pri = (*p)->detect();
if (pri > max_pri) {
max_pri = pri;
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 1b2ee55..c52c4105 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -217,4 +217,5 @@ static bool jailhouse_x2apic_available(void)
.detect = jailhouse_detect,
.init.init_platform = jailhouse_init_platform,
.init.x2apic_available = jailhouse_x2apic_available,
+ .ignore_nopv= true,
};
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4722ba2..5d16824 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1463,4 +1463,5 @@ static uint32_t __init xen_platform_pv(void)
.detect = xen_platform_pv,
.type = X86_HYPER_XEN_PV,
.runtime.pin_vcpu = xen_pin_vcpu,
+ .ignore_nopv= true,
};
--
1.8.3.1
[PATCH v5 1/4] x86/xen: Mark xen_hvm_need_lapic() and xen_x2apic_para_available() as __init
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
arch/x86/include/asm/xen/hypervisor.h | 6 +++---
arch/x86/xen/enlighten_hvm.c | 3 +--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/xen/hypervisor.h
b/arch/x86/include/asm/xen/hypervisor.h
index 39171b3..42e1245 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -44,14 +44,14 @@ static inline uint32_t xen_cpuid_base(void)
}
#ifdef CONFIG_XEN
-extern bool xen_hvm_need_lapic(void);
+extern bool __init xen_hvm_need_lapic(void);
-static inline bool xen_x2apic_para_available(void)
+static inline bool __init xen_x2apic_para_available(void)
{
return xen_hvm_need_lapic();
}
#else
-static inline bool xen_x2apic_para_available(void)
+static inline bool __init xen_x2apic_para_available(void)
{
return (xen_cpuid_base() != 0);
}
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 0e75642..ac4943c 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -218,7 +218,7 @@ static __init int xen_parse_nopv(char *arg)
}
early_param("xen_nopv", xen_parse_nopv);
-bool xen_hvm_need_lapic(void)
+bool __init xen_hvm_need_lapic(void)
{
if (xen_nopv)
return false;
@@ -230,7 +230,6 @@ bool xen_hvm_need_lapic(void)
return false;
return true;
}
-EXPORT_SYMBOL_GPL(xen_hvm_need_lapic);
static uint32_t __init xen_platform_hvm(void)
{
--
1.8.3.1
[PATCH v5 4/4] x86/xen: Add "nopv" support for HVM guest
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore "nopv" parameter directly.
If PVH guest boots up via the normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time.
To handle that case, add a new function xen_hvm_nopv_guest_late_init()
to detect PVH at a late time and panic itself if nopv enabled for a
PVH guest.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
arch/x86/xen/enlighten_hvm.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 1756cf7..09a010a 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -231,11 +231,37 @@ bool __init xen_hvm_need_lapic(void)
return true;
}
+static __init void xen_hvm_nopv_guest_late_init(void)
+{
+#ifdef CONFIG_XEN_PVH
+ if (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga)
+ return;
+
+ /* PVH detected. */
+ xen_pvh = true;
+
+ panic("\"nopv\" and \"xen_nopv\" parameters are unsupported in PVH
guest.");
+#endif
+}
+
+
static uint32_t __init xen_platform_hvm(void)
{
if (xen_pv_domain())
return 0;
+ if (xen_pvh_domain() && nopv) {
+ /* Guest booting via the Xen-PVH boot entry goes here */
+ pr_info("\"nopv\" parameter is ignored in PVH guest\n");
+ nopv = false;
+ } else if (nopv) {
+ /*
+* Guest booting via normal boot entry (like via grub2) goes
+* here.
+*/
+ x86_init.hyper.guest_late_init = xen_hvm_nopv_guest_late_init;
+ return 0;
+ }
return xen_cpuid_base();
}
@@ -268,4 +294,5 @@ static __init void xen_hvm_guest_late_init(void)
.init.init_mem_mapping = xen_hvm_init_mem_mapping,
.init.guest_late_init = xen_hvm_guest_late_init,
.runtime.pin_vcpu = xen_pin_vcpu,
+ .ignore_nopv= true,
};
--
1.8.3.1
[PATCH v5 0/4] misc fixes to PV extentions code
Hi, In virtualization environment, PV extensions (drivers, interrupts, timers, etc) are enabled in the majority of use cases which is the best option. However, in some cases (kexec not fully working, benchmarking, etc) we want to disable PV extensions. We have xen_nopv for that purpose but only for XEN. For a consistent admin experience a common command line parameter set across all PV guest implementations is a better choice. To achieve this introduce a new 'nopv' parameter which is usable by most of PV guest implementation. Due to the limitation of some PV guests(XEN PV, XEN PVH and jailhouse), 'nopv' is ignored for XEN PV , jailhouse and XEN PVH if booting via Xen-PVH boot entry. If booting via normal boot entry(like grub2), PVH guest has to panic itself currently. While analyzing the PV guest code one bug were found and fixed. (Patches 1). It can be applied independent of the functional changes, but is kept in the series as the functional changes depend on them. For compatibility reason, "xen_nopv" is keeped and mapped to "nopv", this way also avoids an issue with xen_nopv when booting PVH guest. Build test passes with CONFIG_HYPERVISOR_GUEST enable and disabled. I didn't get env to test with jailhouse and Hyperv, the others work as expected. v5: PATCH2: update patch description per Boris add declaration of nopv variable in arch/x86/include/asm/hypervisor.h which will be used in PATCH3 and PATCH4 PATCH3 update xen_parse_nopv() per Boris PATCH4 add nopv=false per Boris Combine PATCH5 into PATCH3 v4: PATCH5 a new patch to add 'xen_nopv' back per Boris v3: Remove some unrelated patches from patchset as suggested by Tglx PATCH1 unchanged PATCH2 add Reviewed-by PATCH3 add Reviewed-by PATCH4 rewrite the patch as Jgross found an issue in old patch, description is also updated. v2: PATCH3 use 'ignore_nopv' for PVH/PV guest as suggested by Jgross. PATCH5 new added one, specifically for HVM guest Thanks Zhenzhong
[PATCH v5 3/4] xen: Map "xen_nopv" parameter to "nopv" and mark it obsolete
Clean up unnecessory code after that operation.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/xen/enlighten_hvm.c| 12 ++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 21e08af..8ab34a1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5254,6 +5254,8 @@
xen_nopv[X86]
Disables the PV optimizations forcing the HVM guest to
run as generic HVM guest with no PV drivers.
+ This option is obsoleted by the "nopv" option, which
+ has equivalent effect for XEN platform.
xen_scrub_pages=[XEN]
Boolean option to control scrubbing pages before giving
them back
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index ac4943c..1756cf7 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -210,18 +210,18 @@ static void __init xen_hvm_guest_init(void)
#endif
}
-static bool xen_nopv;
static __init int xen_parse_nopv(char *arg)
{
- xen_nopv = true;
- return 0;
+ pr_notice("\"xen_nopv\" is deprecated, please use \"nopv\" instead\n");
+
+ if (xen_cpuid_base())
+ nopv = true;
+ return 0;
}
early_param("xen_nopv", xen_parse_nopv);
bool __init xen_hvm_need_lapic(void)
{
- if (xen_nopv)
- return false;
if (xen_pv_domain())
return false;
if (!xen_hvm_domain())
@@ -233,7 +233,7 @@ bool __init xen_hvm_need_lapic(void)
static uint32_t __init xen_platform_hvm(void)
{
- if (xen_pv_domain() || xen_nopv)
+ if (xen_pv_domain())
return 0;
return xen_cpuid_base();
--
1.8.3.1
Re: [PATCH] builddeb: generate multi-arch friendly linux-libc-dev package
CCed a couple of people. On Mon, Jun 17, 2019 at 3:15 PM Cedric Hombourger wrote: > > Debian-based distributions place libc header files in a machine > specific directory (/usr/include/) instead of > /usr/include/asm to support installation of the linux-libc-dev > package from multiple architectures. Move headers installed by > "make headers_install" accordingly. > > Signed-off-by: Cedric Hombourger > Reviewed-by: Henning Schild > --- > scripts/package/builddeb | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/scripts/package/builddeb b/scripts/package/builddeb > index b03dd56a4782..8f7afb3a84e9 100755 > --- a/scripts/package/builddeb > +++ b/scripts/package/builddeb > @@ -132,6 +132,11 @@ fi > if [ "$ARCH" != "um" ]; then > $MAKE -f $srctree/Makefile headers_check > $MAKE -f $srctree/Makefile headers_install > INSTALL_HDR_PATH="$libc_headers_dir/usr" > + # move asm headers to /usr/include//asm to match the > structure > + # used by Debian-based distros (to support multi-arch) > + libc_mach=$($CC -dumpmachine) > + mkdir $libc_headers_dir/usr/include/$libc_mach > + mv $libc_headers_dir/usr/include/asm > $libc_headers_dir/usr/include/$libc_mach/ > fi > > # Install the maintainer scripts I am not sure but, I just worried about the backward compatibility... Was this previously broken? I guess debian is using own control file instead of the one in upstream kernel. So, this is almost a matter for developers, I think. How did debian-base distros managed this before, and will this introduce no breakage? Ben, Could you comment on this? -- Best Regards Masahiro Yamada
Re: [PATCH v4 1/2] KVM: LAPIC: Optimize timer latency consider world switch time
On Wed, 3 Jul 2019 at 22:13, Paolo Bonzini wrote: > > On 03/07/19 02:48, Wanpeng Li wrote: > > Hi Paolo, how about this patchset? Patch 2/2 is easy to take, do you > > have more concern about patch 1/2? > > I don't know. It seems somewhat hard to tune and in cyclictest it only > happens for preemption_timer=N. Are you using preemption_timer=N > together with the LAPIC-timer-on-service-CPU patches? A 25ns conservative value makes no benefit for cyclictest any more even when preemption_timer=N. Btw, maybe it is the time to merge the LAPIC-timer-on-service-CPU patches now. :) Regards, Wanpeng Li
Re: [PATCH -mm] autonuma: Fix scan period updating
Mel Gorman writes: > On Tue, Jun 25, 2019 at 09:23:22PM +0800, huang ying wrote: >> On Mon, Jun 24, 2019 at 10:25 PM Mel Gorman wrote: >> > >> > On Mon, Jun 24, 2019 at 10:56:04AM +0800, Huang Ying wrote: >> > > The autonuma scan period should be increased (scanning is slowed down) >> > > if the majority of the page accesses are shared with other processes. >> > > But in current code, the scan period will be decreased (scanning is >> > > speeded up) in that situation. >> > > >> > > This patch fixes the code. And this has been tested via tracing the >> > > scan period changing and /proc/vmstat numa_pte_updates counter when >> > > running a multi-threaded memory accessing program (most memory >> > > areas are accessed by multiple threads). >> > > >> > >> > The patch somewhat flips the logic on whether shared or private is >> > considered and it's not immediately obvious why that was required. That >> > aside, other than the impact on numa_pte_updates, what actual >> > performance difference was measured and on on what workloads? >> >> The original scanning period updating logic doesn't match the original >> patch description and comments. I think the original patch >> description and comments make more sense. So I fix the code logic to >> make it match the original patch description and comments. >> >> If my understanding to the original code logic and the original patch >> description and comments were correct, do you think the original patch >> description and comments are wrong so we need to fix the comments >> instead? Or you think we should prove whether the original patch >> description and comments are correct? >> > > I'm about to get knocked offline so cannot answer properly. The code may > indeed be wrong and I have observed higher than expected NUMA scanning > behaviour than expected although not enough to cause problems. A comment > fix is fine but if you're changing the scanning behaviour, it should be > backed up with data justifying that the change both reduces the observed > scanning and that it has no adverse performance implications. Got it! Thanks for comments! As for performance testing, do you have some candidate workloads? Best Regards, Huang, Ying
Re: [PATCH v2 0/8] pinctrl: aspeed: Preparation for AST2600
On Wed, 3 Jul 2019, at 18:40, Linus Walleij wrote: > Hi Andrew, > > On Fri, Jun 28, 2019 at 4:39 AM Andrew Jeffery wrote: > > > > Hello! > > > > The ASPEED AST2600 is in the pipeline, and we have enough information to > > start > > preparing to upstream support for it. This series lays some ground work; > > splitting the bindings and dicing the implementation up a little further to > > facilitate differences between the 2600 and previous SoC generations. > > > > v2 addresses Rob's comments on the bindings conversion patches. v1 can be > > found > > here: > > I have applied this series, I had to strip some changes of the header > because it was based on some SPDX cleanups upstream but no > big deal I think. Check the result please. Thanks. Have you pushed the branch yet? I just fetched your pinctrl tree and can't see the patches. Andrew
Re: [PATCH v2] powerpc/boot: pass CONFIG options in a simpler and more robust way
Masahiro Yamada writes:
> Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> with -j 1") was also wrong.
>
> The correct dependency is:
>
> $(obj)/serial.o: $(obj)/autoconf.h
>
> However, I do not see the reason why we need to copy autoconf.h to
> arch/power/boot/. Nor do I see consistency in the way of passing
> CONFIG options.
>
> decompress.c references CONFIG_KERNEL_GZIP and CONFIG_KERNEL_XZ, which
> are passed via the command line.
>
> serial.c includes autoconf.h to reference a couple of CONFIG options,
> but this is fragile because we often forget to include "autoconf.h"
> from source files.
>
> In fact, it is already broken.
>
> ppc_asm.h references CONFIG_PPC_8xx, but utils.S is not given any way
> to access CONFIG options. So, CONFIG_PPC_8xx is never defined here.
>
> Pass $(LINUXINCLUDE) to make sure CONFIG options are accessible from
> all .c and .S files in arch/powerpc/boot/.
This breaks our skiroot_defconfig, I don't know why yet:
In file included from
/kisskb/src/arch/powerpc/boot/../../../lib/decompress_unxz.c:236:0,
from /kisskb/src/arch/powerpc/boot/decompress.c:42:
/kisskb/src/arch/powerpc/boot/../../../lib/xz/xz_dec_bcj.c: In function
'bcj_powerpc':
/kisskb/src/arch/powerpc/boot/../../../lib/xz/xz_dec_bcj.c:166:11: warning:
implicit declaration of function 'get_unaligned_be32'
[-Wimplicit-function-declaration]
instr = get_unaligned_be32(buf + i);
http://kisskb.ellerman.id.au/kisskb/buildresult/13862914/
cheers
Re: [PATCH 2/3 linux,dev-5.1 v1] ARM: dts: aspeed: Add SGPIO driver
Hello Hongwei,
As this is patch is sent to the upstream lists (linux-gpio@ etc) please
drop the OpenBMC-specific "linux,dev-5.1" from the subject.
Also, it looks like you may have manually added the series revision (v1).
For the record you can make `git format-patch` do this for you with the
`-v`option (e.g. if you really want it here, `-v 1`).
On Thu, 4 Jul 2019, at 07:09, Hongwei Zhang wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang
> ---
> drivers/gpio/sgpio-aspeed.c | 470
>
> 1 file changed, 470 insertions(+)
> create mode 100644 drivers/gpio/sgpio-aspeed.c
>
> diff --git a/drivers/gpio/sgpio-aspeed.c b/drivers/gpio/sgpio-aspeed.c
> new file mode 100644
> index 000..108ed13
> --- /dev/null
> +++ b/drivers/gpio/sgpio-aspeed.c
> @@ -0,0 +1,470 @@
> +/*
> + * Copyright 2019 American Megatrends International LLC.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
You should use the SPDX license identifier here rather than the GPL
blurb, and it should be the first line of the file. Keep your copyright
line in place though:
// SPDX-License-Identifier: GPL-2.0-or-later
// Copyright 2019 American Megatrends International LLC.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NR_SGPIO80
> +
> +struct aspeed_sgpio {
> + struct gpio_chip chip;
> + spinlock_t lock;
> + void __iomem *base;
> + int irq;
> +};
> +
> +struct aspeed_sgpio_bank {
> + uint16_tval_regs;
> + uint16_trdata_reg;
> + uint16_tirq_regs;
> + const char names[4][3];
> +};
> +
> +/*
> + * Note: The "value" register returns the input value sampled on the
> + * line even when the GPIO is configured as an output. Since
> + * that input goes through synchronizers, writing, then reading
> + * back may not return the written value right away.
> + *
> + * The "rdata" register returns the content of the write latch
> + * and thus can be used to read back what was last written
> + * reliably.
> + */
> +
> +static const struct aspeed_sgpio_bank aspeed_sgpio_banks[] = {
> + {
> + .val_regs = 0x,
> + .rdata_reg = 0x0070,
> + .irq_regs = 0x0004,
> + .names = { "A", "B", "C", "D" },
> + },
> + {
> + .val_regs = 0x001C,
> + .rdata_reg = 0x0074,
> + .irq_regs = 0x0020,
> + .names = { "E", "F", "G", "H" },
> + },
> + {
> + .val_regs = 0x0038,
> + .rdata_reg = 0x0078,
> + .irq_regs = 0x003C,
> + .names = { "I", "J" },
> + },
> +};
> +
> +enum aspeed_sgpio_reg {
> + reg_val,
> + reg_rdata,
> + reg_irq_enable,
> + reg_irq_type0,
> + reg_irq_type1,
> + reg_irq_type2,
> + reg_irq_status,
> +};
> +
> +#define GPIO_VAL_VALUE 0x00
> +#define GPIO_VAL_DIR0x04
> +#define GPIO_IRQ_ENABLE 0x00
> +#define GPIO_IRQ_TYPE0 0x04
> +#define GPIO_IRQ_TYPE1 0x08
> +#define GPIO_IRQ_TYPE2 0x0C
> +#define GPIO_IRQ_STATUS 0x10
> +
> +/* This will be resolved at compile time */
> +static inline void __iomem *bank_reg(struct aspeed_sgpio *gpio,
> + const struct aspeed_sgpio_bank *bank,
> + const enum aspeed_sgpio_reg reg)
> +{
> + switch (reg) {
> + case reg_val:
> + return gpio->base + bank->val_regs + GPIO_VAL_VALUE;
> + case reg_rdata:
> + return gpio->base + bank->rdata_reg;
> + case reg_irq_enable:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_ENABLE;
> + case reg_irq_type0:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE0;
> + case reg_irq_type1:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE1;
> + case reg_irq_type2:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE2;
> + case reg_irq_status:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_STATUS;
> + }
> + BUG_ON(1);
This isn't appropriate - we shouldn't take down the kernel on a
faulty peripheral access. Please change this to WARN().
> +}
> +
> +#define GPIO_BANK(x)((x) >> 5)
> +#define GPIO_OFFSET(x) ((x) & 0x1f)
> +#define GPIO_BIT(x) BIT(GPIO_OFFSET(x))
> +
> +static const struct aspeed_sgpio_bank *to_bank(unsigned int offset)
> +{
> + unsigned int bank = GPIO_BANK(offset);
> +
> + WARN_ON(bank >= ARRAY_SIZE(aspeed_sgpio_banks));
> + return _sgpio_banks[bank];
> +}
> +
> +static inline bool have_gpio(struct aspeed_sgpio *gpio, unsigned
[PATCH] arm64: mm: free the initrd reserved memblock in a aligned manner
From: Junhua Huang
We should free the reserved memblock in an aligned manner
because the initrd reserves the memblock in an aligned manner
in arm64_memblock_init().
Otherwise there are some fragments in memblock_reserved regions. e.g.:
/sys/kernel/debug/memblock # cat reserved
0: 0x8008..0x817fafff
1: 0x8340..0x83ff
2: 0x9000..0x9000407f
3: 0xb000..0xb03f
4: 0xb26184ea..0xb2618fff
The fragments like the ranges from b000 to b03f and
from b26184ea to b2618fff should be freed.
And we can do free_reserved_area() after memblock_free(),
as free_reserved_area() calls __free_pages(), once we've done
that it could be allocated somewhere else,
but memblock and iomem still say this is reserved memory.
Signed-off-by: Junhua Huang
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index d2adffb81b5d..03774b8bd364 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -580,8 +580,13 @@ void free_initmem(void)
#ifdef CONFIG_BLK_DEV_INITRD
void __init free_initrd_mem(unsigned long start, unsigned long end)
{
+ unsigned long aligned_start, aligned_end;
+
+ aligned_start = __virt_to_phys(start) & PAGE_MASK;
+ aligned_end = PAGE_ALIGN(__virt_to_phys(end));
+ memblock_free(aligned_end, aligned_end - aligned_start);
free_reserved_area((void *)start, (void *)end, 0, "initrd");
- memblock_free(__virt_to_phys(start), end - start);
+
}
#endif
--
2.15.2
Re: [Question] Should direct reclaim time be bounded?
On 7/3/19 2:43 AM, Mel Gorman wrote:
> Indeed. I'm getting knocked offline shortly so I didn't give this the
> time it deserves but it appears that part of this problem is
> hugetlb-specific when one node is full and can enter into this continual
> loop due to __GFP_RETRY_MAYFAIL requiring both nr_reclaimed and
> nr_scanned to be zero.
Yes, I am not aware of any other large order allocations consistently made
with __GFP_RETRY_MAYFAIL. But, I did not look too closely. Michal believes
that hugetlb pages allocations should use __GFP_RETRY_MAYFAIL.
> Have you considered one of the following as an option?
>
> 1. Always use the on-stack nodes_allowed in __nr_hugepages_store_common
>and copy nodes_states if necessary. Add a bool parameter to
>alloc_pool_huge_page that is true when called from set_max_huge_pages.
>If an allocation from alloc_fresh_huge_page, clear the failing node
>from the mask so it's not retried, bail if the mask is empty. The
>consequences are that round-robin allocation of huge pages will be
>different if a node failed to allocate for transient reasons.
That seems to be a more aggressive form of 3 below.
> 2. Alter the condition in should_continue_reclaim for
>__GFP_RETRY_MAYFAIL to consider if nr_scanned < SWAP_CLUSTER_MAX.
>Either raise priority (will interfere with kswapd though) or
>bail entirely. Consequences may be that other __GFP_RETRY_MAYFAIL
>allocations do not want this behaviour. There are a lot of users.
Due to high number of users, I am avoiding such a change. It would be
hard to validate that such a change does not impact other users.
> 3. Move where __GFP_RETRY_MAYFAIL is set in a gfp_mask in mm/hugetlb.c.
>Strip the flag if an allocation fails on a node. Consequences are
>that setting the required number of huge pages is more likely to
>return without all the huge pages set.
We are actually using a form of this in our distro kernel. It works quite
well on the older (4.11 based) distro kernel. My plan was to push this
upstream. However, when I tested this on recent upstream kernels, I
encountered long stalls associated with the first __GFP_RETRY_MAYFAIL
allocation failure. That is what prompted me to ask this queastion/start
this thread. The distro kernel would see stalls taking tens of seconds,
upstream would see stalls of several minutes. Much has changed since 4.11,
so I was trying to figure out what might be causing this change in behavior.
BTW, here is the patch I was testing. It actually has additional code to
switch between __GFP_RETRY_MAYFAIL and __GFP_NORETRY and back to hopefully
take into account transient conditions.
>From 528c52397301f02acb614c610bd65f0f9a107481 Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Wed, 3 Jul 2019 13:36:24 -0700
Subject: [PATCH] hugetlbfs: don't retry when pool page allocations start to
fail
When allocating hugetlbfs pool pages via /proc/sys/vm/nr_hugepages,
the pages will be interleaved between all nodes of the system. If
nodes are not equal, it is quite possible for one node to fill up
before the others. When this happens, the code still attempts to
allocate pages from the full node. This results in calls to direct
reclaim and compaction which slow things down considerably.
When allocating pool pages, note the state of the previous allocation
for each node. If previous allocation failed, do not use the
aggressive retry algorithm on successive attempts. The allocation
will still succeed if there is memory available, but it will not try
as hard to free up memory.
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 87 ++--
1 file changed, 77 insertions(+), 10 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ede7e7f5d1ab..f3c50344a9b4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1405,12 +1405,27 @@ pgoff_t __basepage_index(struct page *page)
}
static struct page *alloc_buddy_huge_page(struct hstate *h,
- gfp_t gfp_mask, int nid, nodemask_t *nmask)
+ gfp_t gfp_mask, int nid, nodemask_t *nmask,
+ nodemask_t *node_alloc_noretry)
{
int order = huge_page_order(h);
struct page *page;
+ bool alloc_try_hard = true;
- gfp_mask |= __GFP_COMP|__GFP_RETRY_MAYFAIL|__GFP_NOWARN;
+ /*
+* By default we always try hard to allocate the page with
+* __GFP_RETRY_MAYFAIL flag. However, if we are allocating pages in
+* a loop (to adjust global huge page counts) and previous allocation
+* failed, do not continue to try hard on the same node. Use the
+* node_alloc_noretry bitmap to manage this state information.
+*/
+ if (node_alloc_noretry && node_isset(nid, *node_alloc_noretry))
+ alloc_try_hard = false;
+ gfp_mask |= __GFP_COMP|__GFP_NOWARN;
+ if (alloc_try_hard)
+ gfp_mask |= __GFP_RETRY_MAYFAIL;
+ else
+ gfp_mask |=
Re: [PATCH v2 2/2] nvmet-loop: Flush nvme_delete_wq when removing the port
Reviewed-by: Sagi Grimberg
Re: [PATCH v2 1/2] nvmet: Fix use-after-free bug when a port is removed
Reviewed-by: Sagi Grimberg
Re: [PATCH] kbuild: Add ability to test Clang's integrated assembler
On Fri, Jun 28, 2019 at 4:15 AM Nathan Chancellor
wrote:
>
> There are some people interested in experimenting with Clang's
> integrated assembler. To make it easy to do so without source
> modification, allow the user to specify 'AS=clang' as part of the
> make command to avoid adding '-no-integrated-as' to the {A,C}FLAGS.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/577
> Suggested-by: Dmitry Golovin
> Signed-off-by: Nathan Chancellor
Applied to linux-kbuild. Thanks.
> ---
> Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 5102b2bbd224..d77481129339 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -527,7 +527,9 @@ endif
> ifneq ($(GCC_TOOLCHAIN),)
> CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
> endif
> +ifeq ($(shell $(AS) --version 2>&1 | head -n 1 | grep clang),)
> CLANG_FLAGS+= -no-integrated-as
> +endif
> CLANG_FLAGS+= -Werror=unknown-warning-option
> KBUILD_CFLAGS += $(CLANG_FLAGS)
> KBUILD_AFLAGS += $(CLANG_FLAGS)
> --
> 2.22.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs
On 7/3/19 5:25 PM, Laurent Pinchart wrote: Hi Shuah, On Wed, Jul 03, 2019 at 10:52:17AM -0600, Shuah Khan wrote: On 7/3/19 10:17 AM, Niklas Söderlund wrote: On 2019-06-30 14:41:02 +0300, Laurent Pinchart wrote: On Fri, Jun 28, 2019 at 10:41:07AM -0600, Shuah Khan wrote: On 6/16/19 12:45 PM, Laurent Pinchart wrote: On Fri, Jun 14, 2019 at 05:26:46PM -0600, Shuah Khan wrote: On 6/13/19 7:24 AM, Helen Koike wrote: On 6/13/19 2:44 AM, Hans Verkuil wrote: On 5/24/19 5:31 AM, Shuah Khan wrote: media_device is embedded in struct vimc_device and when vimc is removed vimc_device and the embedded media_device goes with it, while the active stream and vimc_capture continue to access it. Fix the media_device lifetime problem by changing vimc to create shared media_device using Media Device Allocator API and vimc_capture getting a reference to vimc module. With this change, vimc module can be removed only when the references are gone. vimc can be removed after vimc_capture is removed. Media Device Allocator API supports just USB devices. Enhance it adding a genetic device allocate interface to support other media drivers. The new interface takes pointer to struct device instead and creates media device. This interface allows a group of drivers that have a common root device to share media device resource and ensure media device doesn't get deleted as long as one of the drivers holds its reference. The new interface has been tested with vimc component driver to fix panics when vimc module is removed while streaming is in progress. Helen, can you review this series? I'm not sure this is the right approach for a driver like vimc, and even if it is, then it is odd that vimc-capture is the only vimc module that's handled here. Hi Hans, Yes, I can take a look. Sorry, I've been a bit busy these days but I'll try to take a look at this patch series (and the others) asap. Helen My gut feeling is that this should be handled inside vimc directly and not using the media-dev-allocator. Hi Hans and Helen, I explored fixing the problem within vimc before I went down the path to use Media Device Allocator API. I do think that it is cleaner to go this way and easier to maintain. vimc is a group pf component drivers that rely on the media device vimc in vimc and falls into the use-case Media Device Allocator API is added to address. The release and life-time management happens without vimc component drivers being changed other than using the API to get and put media device reference. Our replies crossed each other, please see my reply to Hans. I would just like to comment here that if having multiple kernel modules causes issue, they can all be merged together. There's no need for vimc to be handled through multiple modules (I actually think it's quite counterproductive, it only makes it more complex, for no added value). There are several problems in this group of drivers as far as lifetime management is concerned. I explained some of it in the patch 2/2 If vimc module is removed while streaming is active, vimc_exit runs into NULL pointer dereference error when streaming thread tries to access and lock graph_mutex in the struct media_device. The primary reason for this is that: media_device is embedded in struct vimc_device and when vimc is removed vimc_device and the embedded media_device goes with it, while the active stream and vimc_capture continue to access it. The issue isn't so much that media_devic is embedded in vimc_device, but that vimc_device is released too early. Not only does the thread need to access the graph_mutex lock in the media_device structure, but it can potentially access fields of the device-specific structures as well. The proper solution is to propagate media_device_release() one level up, in order to only release the top-level structure containing media_device when the last reference to the media_device is dropped. Yes. vimc_device is the master device for all the component drivers and it being released early definitely causes problems. I tried to solve this by isolating the media_device embedded in it and taking that out of contention for release later. This problem could be solved by making sure vimc_device sticks around and I am on that solution now. Thank you :-) I have seen similar problems with rcar-vin, the device specific data is released to early. In my case it was not triggered by the struct media_device but with a struct v4l2_device embedded in the device specific data IIRC. This was when I tried to address the lifetime issues of the video device when binding/unbinding the device to the driver and not when unloading the module. This was quiet a while ago so I don't recall specifics, sorry about that. One finding was that there are also unsolved problems when it comes async notifiers and unloading/unbinding and then loading/binding subdevices as well as the driver controlling the video device. It was such a mess I gave up. Yes. You will find such
Re: [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs
Hi Shuah, On Wed, Jul 03, 2019 at 10:52:17AM -0600, Shuah Khan wrote: > On 7/3/19 10:17 AM, Niklas Söderlund wrote: > > On 2019-06-30 14:41:02 +0300, Laurent Pinchart wrote: > >> On Fri, Jun 28, 2019 at 10:41:07AM -0600, Shuah Khan wrote: > >>> On 6/16/19 12:45 PM, Laurent Pinchart wrote: > On Fri, Jun 14, 2019 at 05:26:46PM -0600, Shuah Khan wrote: > > On 6/13/19 7:24 AM, Helen Koike wrote: > >> On 6/13/19 2:44 AM, Hans Verkuil wrote: > >>> On 5/24/19 5:31 AM, Shuah Khan wrote: > media_device is embedded in struct vimc_device and when vimc is > removed > vimc_device and the embedded media_device goes with it, while the > active > stream and vimc_capture continue to access it. > > Fix the media_device lifetime problem by changing vimc to create > shared > media_device using Media Device Allocator API and vimc_capture > getting > a reference to vimc module. With this change, vimc module can be > removed > only when the references are gone. vimc can be removed after > vimc_capture > is removed. > > Media Device Allocator API supports just USB devices. Enhance it > adding a genetic device allocate interface to support other media > drivers. > > The new interface takes pointer to struct device instead and creates > media device. This interface allows a group of drivers that have a > common root device to share media device resource and ensure media > device doesn't get deleted as long as one of the drivers holds its > reference. > > The new interface has been tested with vimc component driver to fix > panics when vimc module is removed while streaming is in progress. > >>> > >>> Helen, can you review this series? I'm not sure this is the right > >>> approach > >>> for a driver like vimc, and even if it is, then it is odd that > >>> vimc-capture > >>> is the only vimc module that's handled here. > >> > >> Hi Hans, > >> > >> Yes, I can take a look. Sorry, I've been a bit busy these days but I'll > >> try to take a look at this patch series (and the others) asap. > >> > >> Helen > >> > >>> My gut feeling is that this should be handled inside vimc directly > >>> and not > >>> using the media-dev-allocator. > > > > Hi Hans and Helen, > > > > I explored fixing the problem within vimc before I went down the path to > > use Media Device Allocator API. I do think that it is cleaner to go this > > way and easier to maintain. > > > > vimc is a group pf component drivers that rely on the media device vimc > > in vimc and falls into the use-case Media Device Allocator API is added > > to address. The release and life-time management happens without vimc > > component drivers being changed other than using the API to get and put > > media device reference. > > Our replies crossed each other, please see my reply to Hans. I would > just like to comment here that if having multiple kernel modules causes > issue, they can all be merged together. There's no need for vimc to be > handled through multiple modules (I actually think it's quite > counterproductive, it only makes it more complex, for no added value). > >>> > >>> There are several problems in this group of drivers as far as lifetime > >>> management is concerned. I explained some of it in the patch 2/2 > >>> > >>> If vimc module is removed while streaming is active, vimc_exit runs > >>> into NULL pointer dereference error when streaming thread tries to > >>> access and lock graph_mutex in the struct media_device. > >>> > >>> The primary reason for this is that: > >>> > >>> media_device is embedded in struct vimc_device and when vimc is removed > >>> vimc_device and the embedded media_device goes with it, while the active > >>> stream and vimc_capture continue to access it. > >> > >> The issue isn't so much that media_devic is embedded in vimc_device, but > >> that vimc_device is released too early. Not only does the thread need to > >> access the graph_mutex lock in the media_device structure, but it can > >> potentially access fields of the device-specific structures as well. The > >> proper solution is to propagate media_device_release() one level up, in > >> order to only release the top-level structure containing media_device > >> when the last reference to the media_device is dropped. > > Yes. vimc_device is the master device for all the component drivers and > it being released early definitely causes problems. I tried to solve > this by isolating the media_device embedded in it and taking that out > of contention for release later. This problem could be solved by making > sure vimc_device sticks around and I am on that solution now. Thank you
Re: [PATCH v2 6/7] dt-bindings: net: realtek: Add property to configure LED mode
Hi Florian, On Wed, Jul 03, 2019 at 02:37:47PM -0700, Florian Fainelli wrote: > On 7/3/19 12:37 PM, Matthias Kaehlcke wrote: > > The LED behavior of some Realtek PHYs is configurable. Add the > > property 'realtek,led-modes' to specify the configuration of the > > LEDs. > > > > Signed-off-by: Matthias Kaehlcke > > --- > > Changes in v2: > > - patch added to the series > > --- > > .../devicetree/bindings/net/realtek.txt | 9 + > > include/dt-bindings/net/realtek.h | 17 + > > 2 files changed, 26 insertions(+) > > create mode 100644 include/dt-bindings/net/realtek.h > > > > diff --git a/Documentation/devicetree/bindings/net/realtek.txt > > b/Documentation/devicetree/bindings/net/realtek.txt > > index 71d386c78269..40b0d6f9ee21 100644 > > --- a/Documentation/devicetree/bindings/net/realtek.txt > > +++ b/Documentation/devicetree/bindings/net/realtek.txt > > @@ -9,6 +9,12 @@ Optional properties: > > > > SSC is only available on some Realtek PHYs (e.g. RTL8211E). > > > > +- realtek,led-modes: LED mode configuration. > > + > > + A 0..3 element vector, with each element configuring the operating > > + mode of an LED. Omitted LEDs are turned off. Allowed values are > > + defined in "include/dt-bindings/net/realtek.h". > > This should probably be made more general and we should define LED modes > that makes sense regardless of the PHY device, introduce a set of > generic functions for validating and then add new function pointer for > setting the LED configuration to the PHY driver. This would allow to be > more future proof where each PHY driver could expose standard LEDs class > devices to user-space, and it would also allow facilities like: ethtool > -p to plug into that. > > Right now, each driver invents its own way of configuring LEDs, that > does not scale, and there is not really a good reason for that other > than reviewing drivers in isolation and therefore making it harder to > extract the commonality. Yes, I realize that since you are the latest > person submitting something in that area, you are being selected :) I see the merit of your proposal to come up with a generic mechanism to configure Ethernet LEDs, however I can't justify spending much of my work time on this. If it is deemed useful I'm happy to send another version of the current patchset that addresses the reviewer's comments, but if the implementation of a generic LED configuration interface is a requirement I will have to abandon at least the LED configuration part of this series.
Re: [patch v3 1/5] AST2500 DMA UART driver
On Wed, 2019-07-03 at 19:49 +0200, Greg KH wrote:
> > +
> > + if (tx_sts & UART_SDMA0_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA0_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[0]));
> > + } else if (tx_sts & UART_SDMA1_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA1_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[1]));
> > + } else if (tx_sts & UART_SDMA2_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA2_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[2]));
> > + } else if (tx_sts & UART_SDMA3_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA3_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[3]));
> > + } else if (tx_sts & UART_SDMA4_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA4_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[4]));
> > + } else if (tx_sts & UART_SDMA5_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA5_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[5]));
> > + } else if (tx_sts & UART_SDMA6_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA6_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[6]));
> > + } else if (tx_sts & UART_SDMA7_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA7_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[7]));
> > + } else if (tx_sts & UART_SDMA8_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA8_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[8]));
> > + } else if (tx_sts & UART_SDMA9_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA9_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[9]));
> > + } else if (tx_sts & UART_SDMA10_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA10_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[10]));
> > + } else if (tx_sts & UART_SDMA11_INT) {
> > + ast_uart_sdma_write(sdma, UART_SDMA11_INT, UART_TX_SDMA_ISR);
> > + ast_sdma_bufffdone(&(sdma->dma_ch->tx_dma_info[11]));
> > + } else {
> > + }
Also this should be a for () loop...
Cheers,
Ben.
[PATCH] PM: sleep: Drop dev_pm_skip_next_resume_phases()
From: Rafael J. Wysocki
After recent hibernation-related changes, there are no more callers
of dev_pm_skip_next_resume_phases() except for the PM core itself
in which it is more straightforward to run the statements from
that function directly, so do that and drop it.
Signed-off-by: Rafael J. Wysocki
---
On top of the patch series at:
https://lore.kernel.org/linux-acpi/20190701162017.gb2...@lahna.fi.intel.com/T/#madf00de2d5a9b67e3c7bf51e882bd66ed7efc7ea
---
drivers/base/power/main.c | 19 +++
include/linux/pm.h|1 -
2 files changed, 3 insertions(+), 17 deletions(-)
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -530,21 +530,6 @@ static void dpm_watchdog_clear(struct dp
/*- Resume routines -*/
/**
- * dev_pm_skip_next_resume_phases - Skip next system resume phases for device.
- * @dev: Target device.
- *
- * Make the core skip the "early resume" and "resume" phases for @dev.
- *
- * This function can be called by middle-layer code during the "noirq" phase of
- * system resume if necessary, but not by device drivers.
- */
-void dev_pm_skip_next_resume_phases(struct device *dev)
-{
- dev->power.is_late_suspended = false;
- dev->power.is_suspended = false;
-}
-
-/**
* suspend_event - Return a "suspend" message for given "resume" one.
* @resume_msg: PM message representing a system-wide resume transition.
*/
@@ -681,6 +666,9 @@ Skip:
dev->power.is_noirq_suspended = false;
if (skip_resume) {
+ /* Make the next phases of resume skip the device. */
+ dev->power.is_late_suspended = false;
+ dev->power.is_suspended = false;
/*
* The device is going to be left in suspend, but it might not
* have been in runtime suspend before the system suspended, so
@@ -689,7 +677,6 @@ Skip:
* device again.
*/
pm_runtime_set_suspended(dev);
- dev_pm_skip_next_resume_phases(dev);
}
Out:
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -760,7 +760,6 @@ extern int pm_generic_poweroff_late(stru
extern int pm_generic_poweroff(struct device *dev);
extern void pm_generic_complete(struct device *dev);
-extern void dev_pm_skip_next_resume_phases(struct device *dev);
extern bool dev_pm_may_skip_resume(struct device *dev);
extern bool dev_pm_smart_suspend_and_suspended(struct device *dev);
Re: [PATCH v3 0/2] Hugetlbfs support for riscv
On Mon, Jul 01, 2019 at 01:58:58PM -0400, Alexandre Ghiti wrote: > - icache-hygiene succeeds after patch #3 of this series which lowers > > the base address of mmap. > I think іcache-hygiene will also need a call to riscv_flush_icache in cacheflush().
[PATCH v2 2/2] nvmet-loop: Flush nvme_delete_wq when removing the port
After calling nvme_loop_delete_ctrl(), the controllers will not
yet be deleted because nvme_delete_ctrl() only schedules work
to do the delete.
This means a race can occur if a port is removed but there
are still active controllers trying to access that memory.
To fix this, flush the nvme_delete_wq before returning from
nvme_loop_remove_port() so that any controllers that might
be in the process of being deleted won't access a freed port.
Signed-off-by: Logan Gunthorpe
---
drivers/nvme/target/loop.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
index 9e211ad6bdd3..da9cd07461fb 100644
--- a/drivers/nvme/target/loop.c
+++ b/drivers/nvme/target/loop.c
@@ -654,6 +654,14 @@ static void nvme_loop_remove_port(struct nvmet_port *port)
mutex_lock(_loop_ports_mutex);
list_del_init(>entry);
mutex_unlock(_loop_ports_mutex);
+
+ /*
+* Ensure any ctrls that are in the process of being
+* deleted are in fact deleted before we return
+* and free the port. This is to prevent active
+* ctrls from using a port after it's freed.
+*/
+ flush_workqueue(nvme_delete_wq);
}
static const struct nvmet_fabrics_ops nvme_loop_ops = {
--
2.20.1
[PATCH v2 1/2] nvmet: Fix use-after-free bug when a port is removed
When a port is removed through configfs, any connected controllers
are still active and can still send commands. This causes a
use-after-free bug which is detected by KASAN for any admin command
that dereferences req->port (like in nvmet_execute_identify_ctrl).
To fix this, disconnect all active controllers when a subsystem is
removed from a port. This ensures there are no active controllers
when the port is eventually removed.
Signed-off-by: Logan Gunthorpe
---
drivers/nvme/target/configfs.c | 1 +
drivers/nvme/target/core.c | 12
drivers/nvme/target/nvmet.h| 3 +++
3 files changed, 16 insertions(+)
diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
index 08dd5af357f7..3854363118cc 100644
--- a/drivers/nvme/target/configfs.c
+++ b/drivers/nvme/target/configfs.c
@@ -673,6 +673,7 @@ static void nvmet_port_subsys_drop_link(struct config_item
*parent,
found:
list_del(>entry);
+ nvmet_port_del_ctrls(port, subsys);
nvmet_port_disc_changed(port, subsys);
if (list_empty(>subsystems))
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index 7734a6acff85..e4db9a441168 100644
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -277,6 +277,18 @@ void nvmet_unregister_transport(const struct
nvmet_fabrics_ops *ops)
}
EXPORT_SYMBOL_GPL(nvmet_unregister_transport);
+void nvmet_port_del_ctrls(struct nvmet_port *port, struct nvmet_subsys *subsys)
+{
+ struct nvmet_ctrl *ctrl;
+
+ mutex_lock(>lock);
+ list_for_each_entry(ctrl, >ctrls, subsys_entry) {
+ if (ctrl->port == port)
+ ctrl->ops->delete_ctrl(ctrl);
+ }
+ mutex_unlock(>lock);
+}
+
int nvmet_enable_port(struct nvmet_port *port)
{
const struct nvmet_fabrics_ops *ops;
diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h
index c25d88fc9dec..b6b0d483e0c5 100644
--- a/drivers/nvme/target/nvmet.h
+++ b/drivers/nvme/target/nvmet.h
@@ -415,6 +415,9 @@ void nvmet_port_send_ana_event(struct nvmet_port *port);
int nvmet_register_transport(const struct nvmet_fabrics_ops *ops);
void nvmet_unregister_transport(const struct nvmet_fabrics_ops *ops);
+void nvmet_port_del_ctrls(struct nvmet_port *port,
+ struct nvmet_subsys *subsys);
+
int nvmet_enable_port(struct nvmet_port *port);
void nvmet_disable_port(struct nvmet_port *port);
--
2.20.1
[PATCH v2 0/2] Fix use-after-free bug when ports are removed
Hey, This is the second attempt at fixing this. Per Sagi's feedback on the first attempt, I've found an approach that disconnects active controllers when the subsys is removed from the port (Patch 1). Patch 2 fixes a race that still exists in the loop transport which requires us to flush the nvme_delete_wq before freeing the port to prevent the use-after-free bug. Logan -- NVME target ports can be removed while there are still active controllers. Largely this is fine, except some admin commands can access the req->port (for example, id-ctrl uses the port's inline date size as part of it's response). This was found while testing with KASAN. -- Logan Gunthorpe (2): nvmet: Fix use-after-free bug when a port is removed nvmet-loop: Flush nvme_delete_wq when removing the port drivers/nvme/target/configfs.c | 1 + drivers/nvme/target/core.c | 12 drivers/nvme/target/loop.c | 8 drivers/nvme/target/nvmet.h| 3 +++ 4 files changed, 24 insertions(+) -- 2.20.1
[PATCH] ACPI: PM: Unexport acpi_device_get_power()
From: Rafael J. Wysocki
Using acpi_device_get_power() outside of ACPI device initialization
and ACPI sysfs is problematic due to the way in which power resources
are handled by it, so unexport it and add a paragraph explaining the
pitfalls to its kerneldoc comment.
Signed-off-by: Rafael J. Wysocki
---
On top of the linux-next branch in the linux-pm.git tree.
---
drivers/acpi/device_pm.c |6 +-
drivers/acpi/internal.h |7 +++
include/acpi/acpi_bus.h |1 -
3 files changed, 12 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -66,6 +66,11 @@ static int acpi_dev_pm_explicit_get(stru
* This function does not update the device's power.state field, but it may
* update its parent's power.state field (when the parent's power state is
* unknown and the device's power state turns out to be D0).
+ *
+ * Also, it does not update power resource reference counters to ensure that
+ * the power state returned by it will be persistent and it may return a power
+ * state shallower than previously set by acpi_device_set_power() for @device
+ * (if that power state depends on any power resources).
*/
int acpi_device_get_power(struct acpi_device *device, int *state)
{
@@ -130,7 +135,6 @@ int acpi_device_get_power(struct acpi_de
return 0;
}
-EXPORT_SYMBOL(acpi_device_get_power);
static int acpi_dev_pm_explicit_set(struct acpi_device *adev, int state)
{
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -506,7 +506,6 @@ int acpi_bus_get_status(struct acpi_devi
int acpi_bus_set_power(acpi_handle handle, int state);
const char *acpi_power_state_string(int state);
-int acpi_device_get_power(struct acpi_device *device, int *state);
int acpi_device_set_power(struct acpi_device *device, int state);
int acpi_bus_init_power(struct acpi_device *device);
int acpi_device_fix_up_power(struct acpi_device *device);
Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -139,8 +139,15 @@ int acpi_power_get_inferred_state(struct
int acpi_power_on_resources(struct acpi_device *device, int state);
int acpi_power_transition(struct acpi_device *device, int state);
+/* --
+ Device Power Management
+ --
*/
+int acpi_device_get_power(struct acpi_device *device, int *state);
int acpi_wakeup_device_init(void);
+/* --
+ Processor
+ --
*/
#ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
void acpi_early_processor_set_pdc(void);
#else
[PATCH v5 2/4] drm/panel: set display info in panel attach
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function. These values
are stored from probe in the drm_panel struct.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 28
include/drm/drm_panel.h | 14 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 169bab54d52d..ca01095470a9 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
*/
int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
{
+ struct drm_display_info *info;
+
if (panel->connector)
return -EBUSY;
panel->connector = connector;
panel->drm = connector->dev;
+ info = >display_info;
+ info->width_mm = panel->width_mm;
+ info->height_mm = panel->height_mm;
+ info->bpc = panel->bpc;
+ info->panel_orientation = panel->orientation;
+ info->bus_flags = panel->bus_flags;
+ if (panel->bus_formats)
+ drm_display_info_set_bus_formats(>display_info,
+panel->bus_formats,
+panel->num_bus_formats);
return 0;
}
@@ -128,6 +140,22 @@ EXPORT_SYMBOL(drm_panel_attach);
*/
int drm_panel_detach(struct drm_panel *panel)
{
+ struct drm_display_info *info;
+
+ if (!panel->connector)
+ goto out;
+
+ info = >connector->display_info;
+ info->width_mm = 0;
+ info->height_mm = 0;
+ info->bpc = 0;
+ info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ info->bus_flags = 0;
+ kfree(info->bus_formats);
+ info->bus_formats = NULL;
+ info->num_bus_formats = 0;
+
+out:
panel->connector = NULL;
panel->drm = NULL;
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 3564952f1a4f..760ca5865962 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -37,6 +37,8 @@ struct display_timing;
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
+ * @detach: detach panel->connector (clear internal state, etc.)
+ * @attach: attach panel->connector (update internal state, etc.)
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
@@ -93,6 +95,18 @@ struct drm_panel {
const struct drm_panel_funcs *funcs;
+ /*
+* panel information to be set in the connector when the panel is
+* attached.
+*/
+ unsigned int width_mm;
+ unsigned int height_mm;
+ unsigned int bpc;
+ int orientation;
+ const u32 *bus_formats;
+ unsigned int num_bus_formats;
+ u32 bus_flags;
+
struct list_head list;
};
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v5 4/4] drm/mtk: add panel orientation property
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b91c4616644a..2920458ae2fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -790,10 +790,18 @@ static int mtk_dsi_create_connector(struct drm_device
*drm, struct mtk_dsi *dsi)
DRM_ERROR("Failed to attach panel to drm\n");
goto err_connector_cleanup;
}
+
+ ret = drm_connector_init_panel_orientation_property(>conn);
+ if (ret) {
+ DRM_ERROR("Failed to init panel orientation\n");
+ goto err_panel_detach;
+ }
}
return 0;
+err_panel_detach:
+ drm_panel_detach(dsi->panel);
err_connector_cleanup:
drm_connector_cleanup(>conn);
return ret;
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH] gpiolib: Preserve desc->flags when setting state
desc->flags may already have values set by of_gpiochip_add() so make
sure that this isn't undone when setting the initial direction.
Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning")
Signed-off-by: Chris Packham
---
drivers/gpio/gpiolib.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e013d417a936..cc651e3dea54 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1393,11 +1393,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip,
void *data,
struct gpio_desc *desc = >descs[i];
if (chip->get_direction && gpiochip_line_is_valid(chip, i))
- desc->flags = !chip->get_direction(chip, i) ?
- (1 << FLAG_IS_OUT) : 0;
+ if (!chip->get_direction(chip, i))
+ set_bit(FLAG_IS_OUT, >flags);
else
- desc->flags = !chip->direction_input ?
- (1 << FLAG_IS_OUT) : 0;
+ if (!chip->direction_input)
+ set_bit(FLAG_IS_OUT, >flags);
}
acpi_gpiochip_add(chip);
--
2.22.0
Re: [PATCH v1 OPT1] driver core: Fix use-after-free and double free on glue directory
On Wed, 2019-07-03 at 21:37 +0200, Greg KH wrote: > Ok, I guess I have to take this patch, as the other one is so bad :) > > But, I need a very large comment here saying why we are poking around in > a kref and why we need to do this, at the expense of anything else. > > So can you respin this patch with a comment here to help explain it so > we have a chance to understand it when we run across this line in 10 > years? Also are we confident that an open dir on the glue dir from userspace won't keep the kref up ? Cheers, Ben.
Re: [PATCH v4 OPT2] driver core: Fix use-after-free and double free on glue directory
On Wed, 2019-07-03 at 21:36 +0200, Greg KH wrote: > > > -static struct kobject *get_device_parent(struct device *dev, > > -struct device *parent) > > +/** > > + * __get_device_parent() - Get the parent device kobject. > > + * @dev: Pointer to the device structure. > > + * @parent: Pointer to the parent device structure. > > + * @lock: When we live in a glue directory, should we hold the > > + *gdp_mutex lock when this function returns? If @lock > > + *is true, this function returns with the gdp_mutex > > + *holed. Otherwise it will not. > > Ugh, if you are trying to get me to hate one version of these patches, > this is how you do it :) > > A function should not "sometimes takes a lock, sometimes does not, > depending on a parameter passed into it" That way lies madness... Yes, I prefer this approach to the fix but I dont like the patch either for the same reason... ... > Anyway, this is a mess. > > Ugh I hate glue dirs... Amen... Ben.
Re: [PATCH v3 0/2] Hugetlbfs support for riscv
Hi Alex,
Thanks for writing and testing these patches, and thanks for your patience
waiting for reviews and testing.
On Mon, 1 Jul 2019, Alexandre Ghiti wrote:
> This series introduces hugetlbfs support for both riscv 32/64. Riscv32
>
> is architecturally limited to huge pages of size 4MB whereas riscv64 has
>
> 2MB/1G huge pages support. Transparent huge page support is not
>
> implemented here, I will submit another series later.
>
>
>
[ ... ]
> This series was validated using libhugetlbfs testsuite ported to riscv64
>
> without linker script support.
>
> (https://github.com/AlexGhiti/libhugetlbfs.git, branch dev/alex/riscv).
>
>
>
> - libhugetlbfs testsuite on riscv64/2M:
>
> - brk_near_huge triggers an assert in malloc.c, does not on x86.
>
I was able to reproduce the 2MB megapages test results on rv64 QEMU. On a
HiFive Unleashed, though, a few more tests fail:
- icache_hygiene fails ("icache unclean")
# LD_LIBRARY_PATH=obj64 ./tests/obj64/icache-hygiene
Starting testcase "./tests/obj64/icache-hygiene", pid 732
SIGILL at 0x15559fff80 (sig_expected=0x15559fff80)
SIGILL at 0x1555dfff80 (sig_expected=0x1555dfff80)
SIGILL at 0x15561fff80 (sig_expected=0x15561fff80)
SIGILL at 0x15565fff80 (sig_expected=0x15565fff80)
SIGILL at 0x15569fff80 (sig_expected=0x15569fff80)
SIGILL at 0x1556dfff80 (sig_expected=(nil))
FAIL SIGILL somewhere unexpected
#
- One of the heapshrink tests fails ("Heap did not shrink")
# LD_PRELOAD="obj64/libhugetlbfs_privutils.so obj64/libhugetlbfs.so
tests/obj64/libheapshrink.so" HUGETLB_MORECORE_SHRINK=yes HUGETLB_MORECORE=yes
tests/obj64/heapshrink
Starting testcase "tests/obj64/heapshrink", pid 753
FAILHeap did not shrink
#
Some of these may be related to the top-down mmap work, but there might be
more work to do on actual hardware.
> - libhugetlbfs testsuite on riscv64/1G:
>
> - brk_near_huge triggers an assert in malloc.c, does not on x86.
>
> - mmap-gettest, mmap-cow: testsuite passes the number of default free
>
> pages as parameters and then fails for 1G which is not the default.
>
> Otherwise succeeds when given the right number of pages.
>
> - map_high_truncate_2 fails on x86 too: 0x6000 is not 1G aligned
>
> and fails at line 694 of fs/hugetlbfs/inode.c.
>
> - heapshrink on 1G fails on x86 too, not investigated.
>
> - counters.sh on 1G fails on x86 too: alloc_surplus_huge_page returns
>
> NULL in case of gigantic pages.
>
> - icache-hygiene succeeds after patch #3 of this series which lowers
>
> the base address of mmap.
>
> - fallocate_stress.sh on 1G never ends, on x86 too, not investigated.
>
I can reproduce some of these here on QEMU. But for reasons that are
unclear to me, 1G gigapages aren't working on the HiFive Unleashed here.
In any case, these patches are clearly a good start, so I've queued
them for v5.3.
- Paul
Re: [PATCH v2 4/7] net: phy: realtek: Enable accessing RTL8211E extension pages
On Wed, Jul 03, 2019 at 11:27:41PM +0200, Heiner Kallweit wrote: > On 03.07.2019 23:24, Matthias Kaehlcke wrote: > > On Wed, Jul 03, 2019 at 11:01:09PM +0200, Heiner Kallweit wrote: > >> On 03.07.2019 22:36, Matthias Kaehlcke wrote: > >>> On Wed, Jul 03, 2019 at 10:12:12PM +0200, Heiner Kallweit wrote: > On 03.07.2019 21:37, Matthias Kaehlcke wrote: > > The RTL8211E has extension pages, which can be accessed after > > selecting a page through a custom method. Add a function to > > modify bits in a register of an extension page and a helper for > > selecting an ext page. > > > > rtl8211e_modify_ext_paged() is inspired by its counterpart > > phy_modify_paged(). > > > > Signed-off-by: Matthias Kaehlcke > > --- > > Changes in v2: > > - assign .read/write_page handlers for RTL8211E > > Maybe this was planned, but it's not part of the patch. > >>> > >>> Oops, it was definitely there when I tested ... I guess this got > >>> somehow lost when changing the patch order and resolving minor > >>> conflicts, seems like I only build tested after that :/ > >>> > >> RTL8211E also supports normal pages (reg 0x1f = page). > >> See e.g. rtl8168e_2_hw_phy_config in the r8169 driver, this network > >> chip has an integrated RTL8211E PHY. There settings on page 3 and 5 > >> are done. > >> Therefore I would prefer to use .read/write_page for normal paging > >> in all Realtek PHY drivers. Means the code here would remain as it > >> is and just the changelog would need to be fixed. > > > > Do I understand correctly that you suggest an additional patch that > > assigns .read/write_page() for all entries of realtek_drvs? > > > > No, basically all the Realtek PHY drivers use the following already: > .read_page= rtl821x_read_page, > .write_page = rtl821x_write_page, > What I mean is that this should stay as it is, and not be overwritten > with the extended paging. I now see the source of our/my misunderstanding. I'm working on a 4.19 kernel, which doesn't have your recent patch: commit daf3ddbe11a2ff74c95bc814df8e5fe3201b4cb5 Author: Heiner Kallweit Date: Fri May 10 22:11:26 2019 +0200 net: phy: realtek: add missing page operations That's what I intended to do for RTL8211E, no need to overwrite it with the extended paging. Thanks Matthias
Re: [RFC PATCH 0/5] Add CONFIG symbol as module attribute
On Wed, Jul 03, 2019 at 09:31:33PM +0200, Enrico Weigelt, metux IT consult wrote: > On 03.07.19 19:35, Luis Chamberlain wrote: > > Hi, > > >> Okay, but IIRC this will add more boilerplate those modules. > > > > Just one module attribute. > > Yes, but still one per module. This raises the question whether > maintainers are willing to cope w/ tons of tiny patches for just > one line - for something that will take quite some time to become > actually useful (doesn't help much if only few drivers support it), > and is only helpful in a few use cases. This can be wrapped in kconfig and disabled by default. > And to make it really useful, we also need some way to automatically > derive which other symbols to enable (subsystems, etc), w/o auto- > enabling stuff one doesn't need here. (are the defaults sane for > this usecase ?) No, that's a separate problem. > > The main problem here, IMHO, is that the kconfig system doesn't really > know what makes up a module (it only knows that something w =y cant > depend on something thats =m). > > So it smalls like we'd need some config language that really understands > things like modules, subsystems, arches, etc with their properties and > is used by both kconfig and kbuild. Then we could put all metadata there > instead of the current macro calls. At that point we could also put > things like match tables in here, which would solve the problem of > finding the right driver by hardware descriptions. > > But that's really a *big* topic, it's not easy. Christoph's sugggestion goes along the lines with addressing some of this, yet 2 years havegone by and no one is working on it and its hugely intrusive. I'd welcome the patches. > >> And I wonder whether target binaries are the right place for those > >> things at all - IMHO that's something one wants to derive from the > >> source code / .config's. > > > > For the use cases mentioned for why the module attribute is being > > suggested it would help to not have to download kernel sources. > > Are we still talking about compiling custom kernels ? > (how to do that w/o source code ?) There is a difference between getting kernel sources for your current running kernel Vs getting kernel sources from say Linus' tree or the stable tree, or whatever subsystem you work on. I'm saying that with a module attribute being present you would *not* have to get the kernel sources for the current kernel you are running. > > The only question we want to answer is: for the hardware components > > present on this system, which configs options do I need to enable > > to support these components? > > What else would one need that data, if not compiling a custom kernel > (which in turn needs the source) ? One is compiling a custom kernel. > > At least for virtualization we decided to support at least these two to > > help: > > > > * make kvmconfig > > * make xenconfig > > These two are rather simple. Most times there isn't much variance in > virtual hardware (unless one starts directly mapping in pci or usb > devices ...) Actually no, there is huge variance on the qemu level and that problem is not solved by the above. > > Similar problem would be found if one wanted to find a desirable kernel > > config for a remote system. One should be able to somehow scrape some > > hardware information, dump that to a file, and then somehow generate > > a working config for that system. > > Yes. That's actually pretty much the same usecase (in my case I'd also > have dts, lspci/lsusb output, etc) > > > The module attribute being suggested would enable at least one way > > to gather some of the required config symbols: symbols for *hardware* > > and where one can run a modern kernel, with many features / hardware > > enabled already. > > But only for a pretty specific usecase. Two: build time, and backports. > I'm not opposed to this, but > I wonder whether maintainers are willing to accept that stuff for just > that specific usecase. This is why we are discussing this on this thread. Since we have 'make localmodconfig' already upstream, and since this would help both users of that and backports I'd argue it makes sense upstream. Otherwise I find it that having upstream 'make localmodconfig' but not wanting to improve that problem space rather odd. > > However, folks producing embedded systems *do* / *should* have a lot of > > knowledge of their systems, and so the type of scheme you have devised > > seems sensible for it. > > Usually we have (unless we need to do reverse engineering :o). But it's > a pretty time-consuming task. Especially if the requirements change > several times in the development or lifetime of a specific product. > > For example "oh, we now need eth", "naah, we don't wanna use usb > anymore", "let's take a different SoM", ... not that have pretty > orthogonal sets of configs we need to maintain: hardware- and non- > hardware-related ones. And hardware-related ones can fall into different >
Re: [PATCH 0/3] serdev support for n_gsm
Hi! > and sorry about the reply latency. This is quite a lot to think about. > > I'm also adding Kishon and Mark on CC (e.g. for the phy and ASoC > bits). I just wanted to ask... any news here? > > For some user space examples, I have posted scripts to send and receive > > SMS at [3], and Pavel has ofono patches [4] below. Seems like we can > > also add support to ModemManager along the similar lines. And for the > > serdev drivers, those implement standard Linux interfaces for apps > > to use. > > > > For PM, about a year ago I tried making things work with a user space > > solution and it sucked big time[5]. The power management makes sense > > to do in the kernel driver at least in this case as there are shared > > GPIO pins between the USB PHY and TS 27.010 UART. The shared GPIOs > > are handled by the phy-mapphone-mdm6600 driver. > > > > With the serdev n_gsm MFD driver, the only thing that needs to be done > > to idle the modem is to enable autosuspend for the OHCI interface. So > > no spefific coordination between various components is needed for PM > > beyond that. Things idle just fine using PM runtime. > > Yeah, I don't envy you trying to get this to work (and now I'm getting > dragged into it ;) ). Yeah, and now I'm in, too. I'd really like to have an useful phone. Droid4 seems like best candidate. > It would really help with a high-level outline of the modem and its > components. I've done my best to derive it from these patches and the > code you link to, but that info needs to go in the patch descriptions > (or cover letter). Are you ready for the crazyness? There are two modems in droid 4. I don't care about the LTE one. The GSM one is connected with few USB channels, and few multiplexed channels over UART. One of USB channels is standard AT commands. One of USB channels is QMI. But using USB means big power consumption, so it is better to use multiplexed channels over UART. Few of those look vaguely like AT commands, but voice and sms and ... are going over separate channels. One of those contains NMEA data (packet in AT lookalike). > > Sure that's doable. But notice that we actually need to kick the > > serdev GNSS interface to get more data. It's not a passive GNSS > > data feed in this case. So it's not going to be just a case of > > cat /dev/motmdm4 > /dev/ugnss. Without the serdev GNSS driver, > > it would be some-custom-app -i /dev/motmdm4 -o /dev/ugnss. > > Yeah, I remember us discussing that briefly off list. > > > And without the n_gsm serdev support, it's a mess of some app > > similar to [5] initializing n_gsm, trying to deal with the USB > > PHY PM, dealing with Motorola custom packet numbering, kicking > > GNSS device, feeding data to /dev/ugnss. Hmm I think I've already > > been there just to be able to type AT commands to the modem and > > it did not work :) > > It's a mess indeed, but I'd rather see user-space dealing with until we > figure out how best to do it in the kernel. ;) Userspace should be shielded from hardware-specific mess :-(. > > Anyways, for the serdev kernel drivers, the criteria I've tried > > to follow is: "Can this serdev device driver make user space > > apps use standard Linux interfaces for the hardware?" > > > > So for the serdev Alsa ASoC driver, user space can use the standard > > Alsa interface for setting voice call volume. And for the serdev > > GNSS driver, user space can use /dev/gnss0. > > I understand. Both drivers appears to be using AT commands for control. > It would be interesting to hear what Mark has to say about the codec > driver too. Moving AT handling into the kernel scares me a bit. If we > already have a telephony stack to deal with it in user-space, my > inclination is to let it continue to handle it. These "Motorola AT" commands are really a bit different from standard AT commands. I was working on userspace, and got something... but could not get SMSes to work. > Modem-managed GNSS is also different from receivers connected directly > to the host. It's really the modem that drives the GNSS receiver, and > offers a higher-level interface to the host, for example, by buffering > output which the host can later request. It may or may not be the > kernel's job to periodically poll the modem to recreate an NMEA feed so > to speak. > > But the end-result of having it accessible through a standard interface > is of course appealing. We'd really like unified interface for the GPS receivers, please. In the Droid4 case, there's separate channel on the UART that has just the GPS... so it is really quite similar to normal GPS. We won't have proper driver for the modem anytime soon, but it would be good to be able to use the GPS in the meantime. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital
Re: [PATCH 3/3] x86/mm, tracing: Fix CR2 corruption
On Wed, Jul 3, 2019 at 3:01 PM Peter Zijlstra wrote: > > On Wed, Jul 03, 2019 at 01:27:09PM -0700, Andy Lutomirski wrote: > > On Wed, Jul 3, 2019 at 3:28 AM root wrote: > > > > @@ -1338,18 +1347,9 @@ ENTRY(error_entry) > > > movq%rax, %rsp /* switch stack */ > > > ENCODE_FRAME_POINTER > > > pushq %r12 > > > - > > > - /* > > > -* We need to tell lockdep that IRQs are off. We can't do this > > > until > > > -* we fix gsbase, and we should do it before enter_from_user_mode > > > -* (which can take locks). > > > -*/ > > > - TRACE_IRQS_OFF > > > > This hunk looks wrong. Am I missing some other place that handles the > > case where we enter from kernel mode and IRQs were on? > > > > - CALL_enter_from_user_mode > > > ret > > > > > > .Lerror_entry_done: > > > - TRACE_IRQS_OFF > > > ret > > > > > > /* > > Did you perchance mean to complain about the .Lerror_entry_done one? Yes, duh. I would suggest compiling with DEBUG_LOCKDEP and running perf and the x86 selftests. IIRC that's what catches most of the IRQ flag tracing errors. > > Because I'm not seeing how the one before CALL_enter_from_user_mode can > ever be from-kernel. > > But yes, that .Lerror_entry_done one looks fishy.
[PATCH] kernel/cpu: hotplug; fix non-SYSFS build errors in arch/x86/power/
From: Randy Dunlap
Fix link errors when building almost-allmodconfig but CONFIG_SYSFS
is not set/enabled.
The missing functions should not be inside #if CONFIG_SYSFS/#endif.
The non-SYSFS stub for __store_smt_control() is no longer needed.
This is almost all code movement and a little ifdef-fery changes.
Fixes these build errors:
ld: arch/x86/power/cpu.o: in function `hibernate_resume_nonboot_cpu_disable':
cpu.c:(.text+0x9f4): undefined reference to `cpuhp_smt_enable'
ld: arch/x86/power/hibernate.o: in function `arch_resume_nosmt':
hibernate.c:(.text+0x7f7): undefined reference to `cpuhp_smt_enable'
ld: hibernate.c:(.text+0x809): undefined reference to `cpuhp_smt_disable'
Fixes: 98f8cdce1db5 ("cpu/hotplug: Add sysfs state interface")
Signed-off-by: Randy Dunlap
Cc: Thomas Gleixner
Cc: "Rafael J. Wysocki"
Cc: linux...@vger.kernel.org
---
kernel/cpu.c | 242 +++--
1 file changed, 118 insertions(+), 124 deletions(-)
--- lnx-52-rc7.orig/kernel/cpu.c
+++ lnx-52-rc7/kernel/cpu.c
@@ -376,7 +376,7 @@ static void lockdep_release_cpus_lock(vo
{
}
-#endif /* CONFIG_HOTPLUG_CPU */
+#endif /* CONFIG_HOTPLUG_CPU */
/*
* Architectures that need SMT-specific errata handling during SMT hotplug
@@ -1892,6 +1892,123 @@ void __cpuhp_remove_state(enum cpuhp_sta
}
EXPORT_SYMBOL(__cpuhp_remove_state);
+#ifdef CONFIG_HOTPLUG_CPU
+
+static void cpuhp_offline_cpu_device(unsigned int cpu)
+{
+ struct device *dev = get_cpu_device(cpu);
+
+ dev->offline = true;
+ /* Tell user space about the state change */
+ kobject_uevent(>kobj, KOBJ_OFFLINE);
+}
+
+static void cpuhp_online_cpu_device(unsigned int cpu)
+{
+ struct device *dev = get_cpu_device(cpu);
+
+ dev->offline = false;
+ /* Tell user space about the state change */
+ kobject_uevent(>kobj, KOBJ_ONLINE);
+}
+
+int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
+{
+ int cpu, ret = 0;
+
+ cpu_maps_update_begin();
+ for_each_online_cpu(cpu) {
+ if (topology_is_primary_thread(cpu))
+ continue;
+ ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
+ if (ret)
+ break;
+ /*
+* As this needs to hold the cpu maps lock it's impossible
+* to call device_offline() because that ends up calling
+* cpu_down() which takes cpu maps lock. cpu maps lock
+* needs to be held as this might race against in kernel
+* abusers of the hotplug machinery (thermal management).
+*
+* So nothing would update device:offline state. That would
+* leave the sysfs entry stale and prevent onlining after
+* smt control has been changed to 'off' again. This is
+* called under the sysfs hotplug lock, so it is properly
+* serialized against the regular offline usage.
+*/
+ cpuhp_offline_cpu_device(cpu);
+ }
+ if (!ret)
+ cpu_smt_control = ctrlval;
+ cpu_maps_update_done();
+ return ret;
+}
+
+int cpuhp_smt_enable(void)
+{
+ int cpu, ret = 0;
+
+ cpu_maps_update_begin();
+ cpu_smt_control = CPU_SMT_ENABLED;
+ for_each_present_cpu(cpu) {
+ /* Skip online CPUs and CPUs on offline nodes */
+ if (cpu_online(cpu) || !node_online(cpu_to_node(cpu)))
+ continue;
+ ret = _cpu_up(cpu, 0, CPUHP_ONLINE);
+ if (ret)
+ break;
+ /* See comment in cpuhp_smt_disable() */
+ cpuhp_online_cpu_device(cpu);
+ }
+ cpu_maps_update_done();
+ return ret;
+}
+
+#if defined(CONFIG_HOTPLUG_SMT) && defined(CONFIG_SYSFS)
+static ssize_t
+__store_smt_control(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int ctrlval, ret;
+
+ if (sysfs_streq(buf, "on"))
+ ctrlval = CPU_SMT_ENABLED;
+ else if (sysfs_streq(buf, "off"))
+ ctrlval = CPU_SMT_DISABLED;
+ else if (sysfs_streq(buf, "forceoff"))
+ ctrlval = CPU_SMT_FORCE_DISABLED;
+ else
+ return -EINVAL;
+
+ if (cpu_smt_control == CPU_SMT_FORCE_DISABLED)
+ return -EPERM;
+
+ if (cpu_smt_control == CPU_SMT_NOT_SUPPORTED)
+ return -ENODEV;
+
+ ret = lock_device_hotplug_sysfs();
+ if (ret)
+ return ret;
+
+ if (ctrlval != cpu_smt_control) {
+ switch (ctrlval) {
+ case CPU_SMT_ENABLED:
+ ret = cpuhp_smt_enable();
+ break;
+ case CPU_SMT_DISABLED:
+ case CPU_SMT_FORCE_DISABLED:
+ ret = cpuhp_smt_disable(ctrlval);
+ break;
Re: [PATCH v3 0/4] Solve postboot supplier cleanup and optimize probe ordering
On Tue, Jul 2, 2019 at 5:59 PM Saravana Kannan wrote: > > On Tue, Jul 2, 2019 at 5:03 PM David Collins wrote: > > > > Hello Saravana, > > > > On 7/1/19 5:48 PM, Saravana Kannan wrote: > > ... > > > TODO: > > > - For the case of consumer child sub-nodes being added by a parent > > > device after late_initcall_sync we might be able to address that by > > > recursively parsing all child nodes and adding all their suppliers as > > > suppliers of the parent node too. The parent probe will add the > > > children before its probe is completed and that will prevent the > > > supplier's sync_state from being executed before the children are > > > probed. > > > > > > But I'll write that part once I see how this series is received. > > > > I don't think that this scheme will work in all cases. It can also lead > > to probing deadlock. > > > > Here is an example: > > > > Three DT devices (top level A with subnodes B and C): > > /A > > /A/B > > /A/C > > C is a consumer of B. > > > > When device A is created, a search of its subnodes will find the link from > > C to B. Since device B hasn't been created yet, of_link_to_suppliers() > > will fail and add A to the wait_for_suppliers list. This will cause the > > probe of A to fail with -EPROBE_DEFER (thanks to the check in > > device_links_check_suppliers()). As a result device B will not be created > > and device A will never probe. > > > > You could try to resolve this situation by detecting the cycle and *not* > > adding A to the wait_for_suppliers list. However, that would get us back > > to the problem we had before. A would be allowed to probe which would > > then result in devices being added for B and C. If the device for B is > > added before C, then it would be allowed to immediately probe and > > (assuming this all takes place after late_initcall_sync thanks to modules) > > its sync_state() callback would be called since no consumer devices are > > linked to B. > > > > Please note that to change this example from theoretical to practical, > > replace "A" with apps_rsc, "B" with pmi8998-rpmh-regulators, and "C" with > > pm8998-rpmh-regulators in [1]. > > Interesting use case. > > First, to clarify my TODO: I was initially thinking of the recursive > "up-heritance" of suppliers from child to parent to handle cases where > the supplier is a device from some other top level device (or its > child). My thinking has evolved a bit on that. I think the parent > needs to inherit only from it's immediate children and not its > grandchildren (the child is responsible for handling grandchildren > suppliers). I'll also have to make sure I don't try to create a link > from a parent device to one of its child device nodes (should be easy > to check). > > Anyway, going back to your case, for dependencies between child nodes > of a parent, can't the parent just populate them in the right order? > You can loop through the children and add them in multiple stages. > > I'll continue to think if I can come up with anything nicer on the > drivers, but even if we can't come up with anything better, we can > still make sync_state() work. There's actually a much better way to handle this case where you won't have to handle ordering on the driver side. I just need to add one or two patches to my patch series. I'll send that out sometime next week. -Saravana
[PATCH] perf parse-events: Remove unused variable i
Remove int i because it is declared but not used in parse-events.y or in
the generated parse-events.c.
Signed-off-by: Luke Mujica
---
tools/perf/util/parse-events.y | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 6ad8d4914969..172dbb73941f 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -626,7 +626,6 @@ PE_TERM
PE_NAME array '=' PE_NAME
{
struct parse_events_term *term;
- int i;
ABORT_ON(parse_events_term__str(, PARSE_EVENTS__TERM_TYPE_USER,
$1, $4, &@1, &@4));
--
2.22.0.410.gd8fdbe21b5-goog
