* Re: PATCH scripts/kernel-doc
From: Jonathan Corbet @ 2018-07-23 15:32 UTC (permalink / raw)
To: valdis.kletnieks; +Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel
In-Reply-To: <50400.1531846649@turing-police.cc.vt.edu>
On Tue, 17 Jul 2018 12:57:29 -0400
valdis.kletnieks@vt.edu wrote:
> Fix a warning whinge from Perl introduced by "scripts: kernel-doc: parse next structs/unions"
>
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE [^\{\}]*})/ at ./scripts/kernel-doc line 1155.
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/({ <-- HERE )/ at ./scripts/kernel-doc line 1179.
Applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH i-g-t v3 2/4] lib/igt_pm: Find HDA device when attempting to enable runtime PM
From: Tvrtko Ursulin @ 2018-07-23 15:31 UTC (permalink / raw)
To: igt-dev; +Cc: intel-gfx
In-Reply-To: <153235048851.26238.17694902495417158505@skylake-alporthouse-com>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
HDA audio device can be present at various PCI paths on different systems
which the existing code did not account for.
Furthermore the failure to enable runtime PM was silent leaving callers
in the dark.
Improve it by auto-locating the PCI path and logging a warning when
something is not as expected.
v2:
* If there is no audio hw/driver there is no failure.
v3
* Comment.
* Skip non-symlinks.
* Free path on failure and restore.
* Simplify with asprintf. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
lib/igt_pm.c | 76 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 59 insertions(+), 17 deletions(-)
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6f3b0a2d897d..fd2880c9df11 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -33,6 +33,7 @@
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
+#include <dirent.h>
#include "drmtest.h"
#include "igt_pm.h"
@@ -64,6 +65,7 @@ enum {
#define MAX_POLICY_STRLEN strlen(MAX_PERFORMANCE_STR)
static char __igt_pm_audio_runtime_power_save[64];
+static char * __igt_pm_audio_runtime_control_path;
static char __igt_pm_audio_runtime_control[64];
static int __igt_pm_audio_restore_runtime_pm(void)
@@ -86,7 +88,7 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
- fd = open("/sys/bus/pci/devices/0000:00:03.0/power/control", O_WRONLY);
+ fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
return errno;
@@ -100,6 +102,8 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
__igt_pm_audio_runtime_power_save[0] = 0;
+ free(__igt_pm_audio_runtime_control_path);
+ __igt_pm_audio_runtime_control_path = NULL;
return 0;
}
@@ -130,36 +134,74 @@ static void strchomp(char *str)
*/
void igt_pm_enable_audio_runtime_pm(void)
{
+ char *path = NULL;
+ struct dirent *de;
+ DIR *dir;
int fd;
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
return;
- fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
- if (fd >= 0) {
- igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
- sizeof(__igt_pm_audio_runtime_power_save)) > 0);
- strchomp(__igt_pm_audio_runtime_power_save);
- igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
- igt_assert_eq(write(fd, "1\n", 2), 2);
- close(fd);
- }
- fd = open("/sys/bus/pci/devices/0000:00:03.0/power/control", O_RDWR);
- if (fd >= 0) {
- igt_assert(read(fd, __igt_pm_audio_runtime_control,
- sizeof(__igt_pm_audio_runtime_control)) > 0);
- strchomp(__igt_pm_audio_runtime_control);
- igt_assert_eq(write(fd, "auto\n", 5), 5);
- close(fd);
+ dir = opendir("/sys/bus/pci/drivers/snd_hda_intel");
+ if (!dir)
+ return;
+
+ /* Find PCI device claimed by snd_hda_intel. */
+ while ((de = readdir(dir))) {
+ const char *match = "0000:00:";
+
+ if (de->d_type != DT_LNK ||
+ strncmp(de->d_name, match, strlen(match)))
+ continue;
+
+ igt_assert(asprintf(&path,
+ "/sys/bus/pci/devices/%s/power/control",
+ de->d_name));
+
+ igt_debug("Audio device PCI path is %s\n", path);
+
+ break;
}
+ if (!path)
+ goto err;
+
+ fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
+ if (fd < 0)
+ goto err;
+
+ igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+ sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+ strchomp(__igt_pm_audio_runtime_power_save);
+ igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
+ igt_assert_eq(write(fd, "1\n", 2), 2);
+ close(fd);
+
+ fd = open(path, O_RDWR);
+ if (fd < 0)
+ goto err;
+
+ igt_assert(read(fd, __igt_pm_audio_runtime_control,
+ sizeof(__igt_pm_audio_runtime_control)) > 0);
+ strchomp(__igt_pm_audio_runtime_control);
+ igt_assert_eq(write(fd, "auto\n", 5), 5);
+ close(fd);
+
+ __igt_pm_audio_runtime_control_path = path;
+
igt_debug("Saved audio power management as '%s' and '%s'\n",
__igt_pm_audio_runtime_power_save,
__igt_pm_audio_runtime_control);
/* Give some time for it to react. */
sleep(1);
+
+ return;
+
+err:
+ igt_warn("Failed to enable audio runtime PM! (%d)", errno);
+ free(path);
}
/**
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t v3 2/4] lib/igt_pm: Find HDA device when attempting to enable runtime PM
From: Tvrtko Ursulin @ 2018-07-23 15:31 UTC (permalink / raw)
To: igt-dev; +Cc: intel-gfx, Tvrtko Ursulin
In-Reply-To: <153235048851.26238.17694902495417158505@skylake-alporthouse-com>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
HDA audio device can be present at various PCI paths on different systems
which the existing code did not account for.
Furthermore the failure to enable runtime PM was silent leaving callers
in the dark.
Improve it by auto-locating the PCI path and logging a warning when
something is not as expected.
v2:
* If there is no audio hw/driver there is no failure.
v3
* Comment.
* Skip non-symlinks.
* Free path on failure and restore.
* Simplify with asprintf. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
lib/igt_pm.c | 76 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 59 insertions(+), 17 deletions(-)
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6f3b0a2d897d..fd2880c9df11 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -33,6 +33,7 @@
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
+#include <dirent.h>
#include "drmtest.h"
#include "igt_pm.h"
@@ -64,6 +65,7 @@ enum {
#define MAX_POLICY_STRLEN strlen(MAX_PERFORMANCE_STR)
static char __igt_pm_audio_runtime_power_save[64];
+static char * __igt_pm_audio_runtime_control_path;
static char __igt_pm_audio_runtime_control[64];
static int __igt_pm_audio_restore_runtime_pm(void)
@@ -86,7 +88,7 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
- fd = open("/sys/bus/pci/devices/0000:00:03.0/power/control", O_WRONLY);
+ fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
return errno;
@@ -100,6 +102,8 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
__igt_pm_audio_runtime_power_save[0] = 0;
+ free(__igt_pm_audio_runtime_control_path);
+ __igt_pm_audio_runtime_control_path = NULL;
return 0;
}
@@ -130,36 +134,74 @@ static void strchomp(char *str)
*/
void igt_pm_enable_audio_runtime_pm(void)
{
+ char *path = NULL;
+ struct dirent *de;
+ DIR *dir;
int fd;
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
return;
- fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
- if (fd >= 0) {
- igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
- sizeof(__igt_pm_audio_runtime_power_save)) > 0);
- strchomp(__igt_pm_audio_runtime_power_save);
- igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
- igt_assert_eq(write(fd, "1\n", 2), 2);
- close(fd);
- }
- fd = open("/sys/bus/pci/devices/0000:00:03.0/power/control", O_RDWR);
- if (fd >= 0) {
- igt_assert(read(fd, __igt_pm_audio_runtime_control,
- sizeof(__igt_pm_audio_runtime_control)) > 0);
- strchomp(__igt_pm_audio_runtime_control);
- igt_assert_eq(write(fd, "auto\n", 5), 5);
- close(fd);
+ dir = opendir("/sys/bus/pci/drivers/snd_hda_intel");
+ if (!dir)
+ return;
+
+ /* Find PCI device claimed by snd_hda_intel. */
+ while ((de = readdir(dir))) {
+ const char *match = "0000:00:";
+
+ if (de->d_type != DT_LNK ||
+ strncmp(de->d_name, match, strlen(match)))
+ continue;
+
+ igt_assert(asprintf(&path,
+ "/sys/bus/pci/devices/%s/power/control",
+ de->d_name));
+
+ igt_debug("Audio device PCI path is %s\n", path);
+
+ break;
}
+ if (!path)
+ goto err;
+
+ fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
+ if (fd < 0)
+ goto err;
+
+ igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+ sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+ strchomp(__igt_pm_audio_runtime_power_save);
+ igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
+ igt_assert_eq(write(fd, "1\n", 2), 2);
+ close(fd);
+
+ fd = open(path, O_RDWR);
+ if (fd < 0)
+ goto err;
+
+ igt_assert(read(fd, __igt_pm_audio_runtime_control,
+ sizeof(__igt_pm_audio_runtime_control)) > 0);
+ strchomp(__igt_pm_audio_runtime_control);
+ igt_assert_eq(write(fd, "auto\n", 5), 5);
+ close(fd);
+
+ __igt_pm_audio_runtime_control_path = path;
+
igt_debug("Saved audio power management as '%s' and '%s'\n",
__igt_pm_audio_runtime_power_save,
__igt_pm_audio_runtime_control);
/* Give some time for it to react. */
sleep(1);
+
+ return;
+
+err:
+ igt_warn("Failed to enable audio runtime PM! (%d)", errno);
+ free(path);
}
/**
--
2.17.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: media: i2c: Document MT9V111 bindings
From: Sakari Ailus @ 2018-07-23 14:29 UTC (permalink / raw)
To: Jacopo Mondi
Cc: mchehab, robh, devicetree, linux-media, linux-kernel,
linux-renesas-soc
In-Reply-To: <1528730253-25135-2-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Mon, Jun 11, 2018 at 05:17:32PM +0200, Jacopo Mondi wrote:
> Add documentation for Aptina MT9V111 image sensor.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> .../bindings/media/i2c/aptina,mt9v111.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
> new file mode 100644
> index 0000000..bac4bf0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
> @@ -0,0 +1,46 @@
> +* Aptina MT9V111 CMOS sensor
> +----------------------------
> +
> +The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
> +based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
> +
> +The sensor has an active pixel array of 649x489 pixels and can output a number
640x480 ?
> +of image resolution and formats controllable through a simple two-wires
> +interface.
> +
> +Required properties:
> +--------------------
> +
> +- compatible: shall be "aptina,mt9v111".
> +- clocks: reference to the system clock input provider.
> +
> +Optional properties:
> +--------------------
> +
> +- enable-gpios: output enable signal, pin name "OE#". Active low.
> +- standby-gpios: low power state control signal, pin name "STANDBY".
> + Active high.
> +- reset-gpios: chip reset signal, pin name "RESET#". Active low.
> +
> +The device node must contain one 'port' child node with one 'endpoint' child
> +sub-node for its digital output video port, in accordance with the video
> +interface bindings defined in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +--------
> +
> + &i2c1 {
> + camera@48 {
> + compatible = "aptina,mt9v111";
> + reg = <0x48>;
> +
> + clocks = <&camera_clk>;
> +
> + port {
> + mt9v111_out: endpoint {
> + remote-endpoint = <&ceu_in>;
> + };
> + };
> + };
> + };
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply
* Re: [stable-4.14 00/23] block/scsi multiqueue performance enhancement and
From: Jens Axboe @ 2018-07-23 15:31 UTC (permalink / raw)
To: Jack Wang
Cc: Greg Kroah-Hartman, linux-scsi, linux-block, Wang Jinpu, stable,
Jinpu Wang
In-Reply-To: <CA+res+Txma6FcZtCZ4yhWiQgRJY+0b8BdgJ67uzYodfDyevC-g@mail.gmail.com>
On 7/23/18 9:28 AM, Jack Wang wrote:
> Jens Axboe <axboe@kernel.dk> 于2018年7月23日周一 下午5:05写道：
>>
>> On 7/23/18 9:00 AM, Jack Wang wrote:
>>> Hi Greg,
>>>
>>> Thanks for quick reply. Please see reply inline.
>>>
>>>
>>>
>>> Greg KH <gregkh@linuxfoundation.org> 于2018年7月23日周一 下午3:34写道：
>>>>
>>>> On Mon, Jul 23, 2018 at 03:24:22PM +0200, Jack Wang wrote:
>>>>> Hi Greg,
>>>>>
>>>>> Please consider this patchset, which include block/scsi multiqueue performance
>>>>> enhancement and bugfix.
>>>>
>>>> What exactly is the performance enhancement? How can you measure it?
>>>> How did you measure it?
>>> I'm testing on SRP/IBNBD using fio, I've seen +10% with mix IO load,
>>> and 50% improvement on small IO (bs=512.) with the patchset.
>>
>> Big nak on backporting this huge series, it's a lot of core changes.
>> It's way beyond the scope of a stable fix backport.
>>
>> --
>> Jens Axboe
>>
> OK, could you shed light on how could we fix the queue stall problem on 4.14?
> My colleague Roman reported to upstream:
> https://lkml.org/lkml/2017/10/18/263
>
> It's still there on latest 4.14.
The proposed patch is a helluva lot simpler than doing a 23 patch selective
backport.
--
Jens Axboe
^ permalink raw reply
* [PATCH v2] mmc: sunxi: remove output of virtual base address
From: Andre Przywara @ 2018-07-23 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720141728.6te2ffbqsiisoein@flea>
Hi,
On 20/07/18 15:17, Maxime Ripard wrote:
> On Thu, Jul 19, 2018 at 04:10:50PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 19/07/18 15:46, Maxime Ripard wrote:
>>> On Thu, Jul 19, 2018 at 02:35:54PM +0100, Andre Przywara wrote:
>>>> Recent Linux versions refuse to print actual virtual kernel addresses,
>>>> to not give a hint about the location of the kernel in a randomized virtual
>>>> address space. This affects the output of the sunxi MMC controller
>>>> driver, which now produces the rather uninformative line:
>>>>
>>>> [ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
>>>>
>>>> Since the virtual base address is not really interesting in the first
>>>> place, let's just drop this value. The same applies to Linux' notion of
>>>> the interrupt number, which is independent from the GIC SPI number.
>>>> We have the physical address as part of the DT node name, which is way
>>>> more useful for debugging purposes.
>>>> To keep a success message in the driver, we print some information that
>>>> is not too obvious and that we learned while probing the device:
>>>> the maximum request size and whether it uses the new timing mode.
>>>> So the output turns into:
>>>> sunxi-mmc 1c0f000.mmc: max request size: 16384 KB, uses new timings mode
>>>> sunxi-mmc 1c11000.mmc: max request size: 2048 KB
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>> Changelog v1 ... v2:
>>>> - dropped output of Linux interrupt number
>>>> - added max request size and timings mode output
>>>>
>>>> drivers/mmc/host/sunxi-mmc.c | 5 ++++-
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>>> index 8e7f3e35ee3d..fbbc09d82338 100644
>>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>>> @@ -1407,7 +1407,10 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>>>> if (ret)
>>>> goto error_free_dma;
>>>>
>>>> - dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
>>>> + dev_info(&pdev->dev, "max request size: %u KB%s\n",
>>>> + mmc->max_req_size >> 10,
>>>> + host->use_new_timings ? ", uses new timings mode" : "");
>>>
>>> I really don't know how to feel about this one.
>>>
>>> This isn't more useful to the regular user wanting to see if the
>>> driver is probed, which is what this message should be about.
>>>
>>> And this one isn't clearer or more obvious than the previous one
>>> (which was already pretty bad). I really think having some message
>>> that basically says "MMC controller initialized" or something along
>>> those lines would work better.
>>
>> I see your point, and am happy to change that.
>> On the other hand there might be people that complain about chatty
>> drivers, and printing a line just to says "Success!!!!!" is a bit BSP
>> kernel like ;-).
>
> Well, we're currently printing copyright notices, so I guess we're
> worse than the BSPs :)
>
>> That dmesg line could as well be used to print something useful, and
>> transport the "success" message along with that. So basically I
>> scanned the probe function for some information that would justify
>> an output (something non-obvious or information probed), to avoid
>> dropping this at all (as you initially said yesterday).
>> MMC_CAP_1_8V_DDR was another candidate, btw.
>>
>>> However, I can also see value in having this printed, for developers,
>>> but maybe as dev_dbg?
>>
>> I think it's useful to have this in non-debug kernels as well, because
>> this is what people tend to use. And this would allow developers to much
>> easier debug user problems, for instance when they create board DTs:
>> When this line doesn't appear, there might be a regulator missing, for
>> instance. If it's there, the MMC driver is happy and we have one less
>> thing to worry about.
>>
>> So why not combine the benefit of the success message and the
>> information for developers, if we have that one line of output anyway?
>> I think we have way more chattier drivers and way more cryptic messages
>> in the dmesg, so a single line with some technical details does not
>> hurt, especially if we have that already.
>>
>> But I don't have a strong opinion on that, so leave it up for Ulf and
>> you to decide: keep this patch (or print some other info); replace the
>> output with a success message or drop the line at all.
>
> How about both then?
>
> Something like "initialized with %d request size and new timings\n" ?
>
> It makes it obvious enough for someone that doesn't really has an
> idea, while outputting the proper informations you wanted.
Excellent idea. Changed it in this direction.
Thanks,
Andre.
^ permalink raw reply
* Re: [PATCH v2] mmc: sunxi: remove output of virtual base address
From: Andre Przywara @ 2018-07-23 15:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Ulf Hansson, Chen-Yu Tsai, Robin Murphy,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180720141728.6te2ffbqsiisoein@flea>
Hi,
On 20/07/18 15:17, Maxime Ripard wrote:
> On Thu, Jul 19, 2018 at 04:10:50PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 19/07/18 15:46, Maxime Ripard wrote:
>>> On Thu, Jul 19, 2018 at 02:35:54PM +0100, Andre Przywara wrote:
>>>> Recent Linux versions refuse to print actual virtual kernel addresses,
>>>> to not give a hint about the location of the kernel in a randomized virtual
>>>> address space. This affects the output of the sunxi MMC controller
>>>> driver, which now produces the rather uninformative line:
>>>>
>>>> [ 1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8
>>>>
>>>> Since the virtual base address is not really interesting in the first
>>>> place, let's just drop this value. The same applies to Linux' notion of
>>>> the interrupt number, which is independent from the GIC SPI number.
>>>> We have the physical address as part of the DT node name, which is way
>>>> more useful for debugging purposes.
>>>> To keep a success message in the driver, we print some information that
>>>> is not too obvious and that we learned while probing the device:
>>>> the maximum request size and whether it uses the new timing mode.
>>>> So the output turns into:
>>>> sunxi-mmc 1c0f000.mmc: max request size: 16384 KB, uses new timings mode
>>>> sunxi-mmc 1c11000.mmc: max request size: 2048 KB
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
>>>> ---
>>>> Changelog v1 ... v2:
>>>> - dropped output of Linux interrupt number
>>>> - added max request size and timings mode output
>>>>
>>>> drivers/mmc/host/sunxi-mmc.c | 5 ++++-
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>>> index 8e7f3e35ee3d..fbbc09d82338 100644
>>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>>> @@ -1407,7 +1407,10 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>>>> if (ret)
>>>> goto error_free_dma;
>>>>
>>>> - dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
>>>> + dev_info(&pdev->dev, "max request size: %u KB%s\n",
>>>> + mmc->max_req_size >> 10,
>>>> + host->use_new_timings ? ", uses new timings mode" : "");
>>>
>>> I really don't know how to feel about this one.
>>>
>>> This isn't more useful to the regular user wanting to see if the
>>> driver is probed, which is what this message should be about.
>>>
>>> And this one isn't clearer or more obvious than the previous one
>>> (which was already pretty bad). I really think having some message
>>> that basically says "MMC controller initialized" or something along
>>> those lines would work better.
>>
>> I see your point, and am happy to change that.
>> On the other hand there might be people that complain about chatty
>> drivers, and printing a line just to says "Success!!!!!" is a bit BSP
>> kernel like ;-).
>
> Well, we're currently printing copyright notices, so I guess we're
> worse than the BSPs :)
>
>> That dmesg line could as well be used to print something useful, and
>> transport the "success" message along with that. So basically I
>> scanned the probe function for some information that would justify
>> an output (something non-obvious or information probed), to avoid
>> dropping this at all (as you initially said yesterday).
>> MMC_CAP_1_8V_DDR was another candidate, btw.
>>
>>> However, I can also see value in having this printed, for developers,
>>> but maybe as dev_dbg?
>>
>> I think it's useful to have this in non-debug kernels as well, because
>> this is what people tend to use. And this would allow developers to much
>> easier debug user problems, for instance when they create board DTs:
>> When this line doesn't appear, there might be a regulator missing, for
>> instance. If it's there, the MMC driver is happy and we have one less
>> thing to worry about.
>>
>> So why not combine the benefit of the success message and the
>> information for developers, if we have that one line of output anyway?
>> I think we have way more chattier drivers and way more cryptic messages
>> in the dmesg, so a single line with some technical details does not
>> hurt, especially if we have that already.
>>
>> But I don't have a strong opinion on that, so leave it up for Ulf and
>> you to decide: keep this patch (or print some other info); replace the
>> output with a success message or drop the line at all.
>
> How about both then?
>
> Something like "initialized with %d request size and new timings\n" ?
>
> It makes it obvious enough for someone that doesn't really has an
> idea, while outputting the proper informations you wanted.
Excellent idea. Changed it in this direction.
Thanks,
Andre.
^ permalink raw reply
* Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller
From: Tejun Heo @ 2018-07-23 15:30 UTC (permalink / raw)
To: Patrick Bellasi
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Viresh Kumar, Vincent Guittot, Paul Turner,
Dietmar Eggemann, Morten Rasmussen, Juri Lelli, Todd Kjos,
Joel Fernandes, Steve Muckle, Suren Baghdasaryan
In-Reply-To: <20180716082906.6061-9-patrick.bellasi@arm.com>
Hello,
On Mon, Jul 16, 2018 at 09:29:02AM +0100, Patrick Bellasi wrote:
> The cgroup's CPU controller allows to assign a specified (maximum)
> bandwidth to the tasks of a group. However this bandwidth is defined and
> enforced only on a temporal base, without considering the actual
> frequency a CPU is running on. Thus, the amount of computation completed
> by a task within an allocated bandwidth can be very different depending
> on the actual frequency the CPU is running that task.
> The amount of computation can be affected also by the specific CPU a
> task is running on, especially when running on asymmetric capacity
> systems like Arm's big.LITTLE.
One basic problem I have with this patchset is that what's being
described is way more generic than what actually got implemented.
What's described is computation bandwidth control but what's
implemented is just frequency clamping. So, there are fundamental
discrepancies between description+interface vs. what it actually does.
I really don't think that's something we can fix up later.
> These attributes:
>
> a) are available only for non-root nodes, both on default and legacy
> hierarchies
> b) do not enforce any constraints and/or dependency between the parent
> and its child nodes, thus relying on the delegation model and
> permission settings defined by the system management software
cgroup does host attributes which only concern the cgroup itself and
thus don't need any hierarchical behaviors on their own, but what's
being implemented does control resource allocation, and what you're
describing inherently breaks the delegation model.
> c) allow to (eventually) further restrict task-specific clamps defined
> via sched_setattr(2)
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH net] ipv6: use fib6_info_hold_safe() when necessary
From: David Ahern @ 2018-07-23 14:28 UTC (permalink / raw)
To: Wei Wang, David Miller, netdev; +Cc: Eric Dumazet, Martin KaFai Lau
In-Reply-To: <20180722035632.136090-1-tracywwnj@gmail.com>
On 7/21/18 9:56 PM, Wei Wang wrote:
> From: Wei Wang <weiwan@google.com>
>
> In the code path where only rcu read lock is held, e.g. in the route
> lookup code path, it is not safe to directly call fib6_info_hold()
> because the fib6_info may already have been deleted but still exists
> in the rcu grace period. Holding reference to it could cause double
> free and crash the kernel.
>
> This patch adds a new function fib6_info_hold_safe() and replace
> fib6_info_hold() in all necessary places.
>
> Syzbot reported 3 crash traces because of this. One of them is:
> 8021q: adding VLAN 0 to HW filter on device team0
> IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
> dst_release: dst:(____ptrval____) refcnt:-1
> dst_release: dst:(____ptrval____) refcnt:-2
> WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 dst_hold include/net/dst.h:239 [inline]
> WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
> dst_release: dst:(____ptrval____) refcnt:-1
> Kernel panic - not syncing: panic_on_warn set ...
>
...
>
> Fixes: 93531c674315 (net/ipv6: separate handling of FIB entries from dst based routes)
> Reported-by: syzbot+902e2a1bcd4f7808cef5@syzkaller.appspotmail.com
> Reported-by: syzbot+8ae62d67f647abeeceb9@syzkaller.appspotmail.com
> Reported-by: syzbot+3f08feb14086930677d0@syzkaller.appspotmail.com
> Signed-off-by: Wei Wang <weiwan@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> ---
> include/net/ip6_fib.h | 5 +++++
> net/ipv6/addrconf.c | 3 ++-
> net/ipv6/route.c | 41 +++++++++++++++++++++++++++++++----------
> 3 files changed, 38 insertions(+), 11 deletions(-)
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for fixing.
^ permalink raw reply
* Re: [PATCH 0/6] Symbol namespaces
From: Arnd Bergmann @ 2018-07-23 14:28 UTC (permalink / raw)
To: Martijn Coenen
Cc: Linux Kernel Mailing List, Masahiro Yamada, Michal Marek,
Geert Uytterhoeven, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
the arch/x86 maintainers, Alan Stern, Greg Kroah-Hartman,
Oliver Neukum, Jessica Yu, Stephen Boyd, Philippe Ombredanne,
Kate Stewart, Sam Ravnborg, Linux Kbuild mailing list, linux-m68k,
linux-usb, usb-storage, linux-scsi, linux-arch, Martijn Coenen,
Sandeep Patil, malchev, Joel Fernandes
In-Reply-To: <20180716122125.175792-1-maco@android.com>
On Mon, Jul 16, 2018 at 2:21 PM, Martijn Coenen <maco@android.com> wrote:
> As of Linux 4.17, there are more than 30000 exported symbols
> in the kernel. There seems to be some consensus amongst
> kernel devs that the export surface is too large, and hard
> to reason about.
>
> Generally, these symbols fall in one of these categories:
> 1) Symbols actually meant for drivers
> 2) Symbols that are only exported because functionality is
> split over multiple modules, yet they really shouldn't
> be used by modules outside of their own subsystem
> 3) Symbols really only meant for in-tree use
>
> When module developers try to upstream their code, it
> regularly turns out that they are using exported symbols
> that they really shouldn't be using. This problem is even
> bigger for drivers that are currently out-of-tree, which
> may be using many symbols that they shouldn't be using,
> and that break when those symbols are removed or modified.
>
> This patch allows subsystem maintainers to partition their
> exported symbols into separate namespaces, and module
> authors to import such namespaces only when needed.
>
> This allows subsystem maintainers to more easily limit
> availability of these namespaced symbols to other parts of
> the kernel. It can also be used to partition the set of
> exported symbols for documentation purposes; for example,
> a set of symbols that is really only used for debugging
> could be in a "SUBSYSTEM_DEBUG" namespace.
This looks nice. I don't want to overload you with additional
requests, but it might be good to think about how this can
be taken further, if we want to actually convert large
parts of the kernel to it. I have two ideas:
- It would be nice to have a simple mechanism in Kconfig
to put all symbols in a module into a namespace that is
derived from KBUILD_MODNAME, to avoid having to
annotate every symbol separately. This could be similar
to how we ended up dealing with EXPORT_NO_SYMBOLS
in the linux-2.4 days, with the goal of eventually having
a namespace for each symbol. Similarly, we could pass
a number of default namespaces through the Makefile,
e.g. if we have a directory that has lots of drivers that all
import the symbols from a common subsystem module.
- If this is possible to implement, it would be great to have
a way to limit the globally visible symbols in a module
to the ones that are explicitly exported even when a that
module is built-in rather than loadable. Not sure how this
is best done though. A couple of things can be done with
objcopy, or possibly by reintroducing partial linking (which
was removed not too long ago).
Arnd
^ permalink raw reply
* Re: [PATCH v2 1/3] clk: meson: add DT documentation for emmc clock controller
From: Yixun Lan @ 2018-07-23 14:28 UTC (permalink / raw)
To: Kevin Hilman
Cc: yixun.lan, Rob Herring, Jerome Brunet, Neil Armstrong,
Carlo Caione, Michael Turquette, Stephen Boyd, Miquèl Raynal,
Boris Brezillon, Martin Blumenstingl, Liang Yang, Qiufang Dai,
Jian Hu, linux-clk, linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, devicetree
In-Reply-To: <7hbmay3ut6.fsf@baylibre.com>
HI Kevin
On 07/23/2018 10:12 PM, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
> [...]
>
>>>
>>>> Second, we might like to convert eMMC driver to also use mmc-clkc model.
>>>
>>> IMO, this should be done as part of merging this series. Otherwise, we
>>> have duplicated code for the same thing.
>>
>> IMO, I'd leave this out of this series, since this patch series is quite
>> complete as itself. Although, the downside is code duplication.
>>
>> Still, I need to hear Jerome, or Kevin's option, to see if or how we
>> should proceed the eMMC's clock conversion.
>>
>> I could think of three option myself
>> 1) don't do the conversion, downside is code duplication, upside is NO
>> DT change, no compatibility issue
>> 2) add a syscon node into eMMC DT node, then only convert clock part
>> into this mmc-clkc model, while still leave other eMMC register access
>> as the usual iomap way (still no race condition)
>> 3) convert all eMMC register access by using regmap interface.
>>
>> both 2) and 3) need to update the DT.
>>
>> and probably 2) is a compromise way, and 1) is also OK, 3) is probably
>> the worst way due to dramatically change (I think this was already
>> rejected in the previous discussion)
>
> Because the devices (NAND and eMMC_C) are mutually exclusive, taking the
> step-by-step approach is fine (and preferred) by me.
>
> Phase 1:
> - add new mmc-clk provider
> - add NAND driver using new mmc-clk provider
> - boards using NAND should ensure emmc_c is disabled in DT
>
> This allows us to not touch the MMC driver or existing upstream
> bindings. Yes, this means there is duplicate code in the MMC driver and
> the new mmc-clk provider, but that can be removed in the next phase.
>
Great, the approach to address this issue is reasonable.
We'd like to focus on phase 1 first, thanks
> Phase 2:
> - convert MMC driver to use new mmc-clk provider
> - update MMC users in DT and bindings
>
Ok.
Yixun
^ permalink raw reply
* [Eas-dev] Computing the dynamic-power-coefficient on Exynos5422
From: Dietmar Eggemann @ 2018-07-23 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8966420ddb4d4f40bbbc44b58da2881b@MSX-L106.msx.ad.zih.tu-dresden.de>
Hi Oliver,
On 07/20/2018 04:15 PM, Oliver Effland wrote:
> Hello everyone,
>
> I hope this is the right place to ask, otherwise please just point me in the right direction.
>
> I'm currently testing the EAS patches [v4] on an ODROID-XU3 board, which has an Exynos5422 SoC. However, the corresponding DT is missing the "dynamic-power-coefficient" that is needed for an appropriate EM.
> So I'm trying to compute the dynamic-power-coefficient according to the formula:
>
> Pdyn = dynamic-power-coefficient * V^2 * f
>
> The frequency f is given by the DT.The actual Voltage and Power are determined by means of the on-chip sensors (returns the values for the specific cluster). When using the Voltage given in the DT, the differences for the d-p-coefficient are negligible.
>
> So I'm calculating the d-p-coefficient (mW/MHz/uV^2) by reading out the following SoC sensor values.
>
> For the little cluster (A7):
> frequency(MHz) Voltage(V) Power(mW) Dynamic-power-coefficient
> 200 0.9175 49.470 ~2.938*10^-13
> 400 0.9165 91.892 ~2.736*10^-13
> 600 0.9638 149.454 ~2.682*10^-13
> 800 1.0263 223.453 ~2.652*10^-13
> 1000 1.1000 327.707 ~2.708*10^-13
> 1200 1.1725 445.899 ~2.703*10^-13
> 1400 1.2713 627.010 ~2.771*10^-13
>
> For the big cluster (A15):
> frequency(MHz) Voltage(V) Power(mW) Dynamic-power-coefficient
> 200 0.9162 159.676 ~9.510*10^-13
> 500 0.9138 325.480 ~7.797*10^-13
> 800 0.9288 511.360 ~7.410*10^-13
> 1100 1.0063 828.020 ~7.434*10^-13
> 1400 1.0713 1209.774 ~7.530*10^-13
> 1700 1.1750 1835.784 ~7.822*10^-13
> 2000 1.2700 2661.849 ~8.252*10^-13
We do support Arm's TC2 platform (2xA15 and 3xA7) with the EAS project.
The latest EAS mainline integration includes Quentin's "[RFC PATCH v4
00/12] Energy Aware Scheduling" https://lkml.org/lkml/2018/6/28/301 .
You can find the appropriate patch for TC2 dynamic-power-coefficient
integration "arm: dts: vexpress-v2p-ca15_a7: Add
dynamic-power-coefficient properties" under
https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-development
. Follow the 'eas/next/integration' link. The patch header has a little
bit of documentation about how we did it. We used the build-in TC2
Energy Meter.
This is all in sync with what Russel and Steve posted on this thread before.
Thanks for taking EAS for a spin on another Arm 32bit machine!
-- Dietmar
[...]
^ permalink raw reply
* Re: [PATCH 0/5] Misc Coccinelle-related improvements
From: Duy Nguyen @ 2018-07-23 15:29 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Git Mailing List, René Scharfe,
Derrick Stolee
In-Reply-To: <20180723135100.24288-1-szeder.dev@gmail.com>
On Mon, Jul 23, 2018 at 3:51 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
>
> Just a couple of minor Coccinelle-related improvements:
>
> - The first two patches are small cleanups.
>
> - The last three could make life perhaps just a tad bit easier for
> devs running 'make coccicheck'.
I'm not a heavy cocci user and probably won't spot any corner case
problems. With that in mind, I've read this though and the series
looks good to me.
--
Duy
^ permalink raw reply
* [Cluster-devel] [GFS2 PATCH] gfs2: Return all reservations when rgrp_brelse is called
From: Bob Peterson @ 2018-07-23 15:29 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <85954133-6611-1665-c0b6-d422d16f4d9c@redhat.com>
----- Original Message -----
> > Before this patch, function gfs2_rgrp_brelse would release its
> > buffer_heads for the rgrp bitmaps, but it did not release its
> > reservations. The problem is: When we need to call brelse, we're
> > basically letting go of the bitmaps, which means our reservations
> > are no longer valid: someone on another node may have reserved those
> > blocks and even used them. This patch makes the function returns all
> > the block reservations held for the rgrp whose buffer_heads are
> > being released.
> What advantage does this give us? The reservations are intended to be
> hints, so this should not be a problem,
>
> Steve.
Hi Steve,
I've been working toward a block reservation system that allows multiple
writers to allocate blocks while sharing resource groups (rgrps) that
are locked for EX. The goal, of course, is to improve write concurrency
and eliminate intra-node write imbalances.
My patches all work reasonably well until rgrps fill up and get down
to their last few blocks, in which case the spans of free blocks aren't
long enough for a minimum reservation, due to rgrp fragmentation. With
today's current code, multiple processes doing block allocations can't
bump heads and interfere with one another because they each lock the
rgrp in EX for a span that covers from the block reservation all the
way up to block allocation. But when we enable multiple processes to
share the rgrp, we need to ensure they can't over-commit the rgrp.
So the problem is over-commitment of rgrps.
For example, let's say you have 10 processes that each want to write
5 blocks. The rgrp glock is locked in EX and they begin sharing it.
When they check the rgrp's free space in inplace_reserve, each one of
the 10, in turn, asks the question, "Does this rgrp have 5 free blocks
available?" Let's say the rgrp has 20 free blocks, so of course the
answer is "yes" for all 10 processes. But when they go to actually
allocate those blocks, the first 4 processes use up those 20 free
blocks. At that point, the rgrp is completely full, but the other 6
processes are over-committed to use that rgrp based on their
requirements. Now we have 6 processes that are unable to allocate
a single block from an rgrp that had previously deemed to have enough.
So basically, the problem is that our current block reservations system
has a concept of (a) "This rgrp has X reservations," and (b) "there are
Y blocks leftover that cannot be reserved for general use." That allows
for rgrps to be over-committed.
(1) My proposed solution
To allow for rgrp sharing, I'm trying to tighten things up and
eliminate the "slop". I'm trying to transition the system from a simple
hint to an actual "promise", i.e. an accounting system so that
over-committing is not possible. With this new system there is still a
concept of (a) "This rgrp has X reservations," but (b) now becomes
"This rgrp has X of my remaining blocks promised to various processes."
So accounting is done to keep track of how many of the free blocks are
promised for allocations outside of reservations. After all block
allocations have been done for a transaction, any remaining blocks that
have been promised from the rgrp to that process are then rescinded,
which means they go back to the general pool of free blocks for
other processes to use.
There are, of course, other ways we can do this. For example, we can:
(2) Alternate solution 1 - "the rest goes to process n"
Automatically assign "all remaining unreserved blocks" to
the first process needing them and force all the others to a different
rgrp. But after years of use, when the rgrps become severely
fragmented, that system would cause much more of a slowdown.
(3) Alternate solution 2 - "hold the lock from reservation to allocation"
Of course, we could also block other processes from the rgrp from
reservation to allocation, but that would have almost no advantage
over what we do today: it would pretty much negate rgrp sharing
and we'd end up with the write imbalance problems we have today.
(4) Alternate solution 3 - "Hint with looping"
We could also put a system in place whereby we still use "hints".
Processes that had called inplace_reserve for a given rgrp, but
are now out of free blocks because of over-commitment (we had a
hint, not a promise) must then loop back around and call function
inplace_reserve again, searching for a different rgrp that might
work instead, in which case it could run into the same situation
multiple times. That would most likely be a performance disaster.
(5) Alternate solution 4 - "One (or small) block reservations"
We could allow for one-block (or at least small-block) reservations
and keep a queue of them or something to fulfill a multi-block
allocation requirement. I suspect this would be a nightmare of
kmem_cache_alloc requests and have a lot more overhead than simply
making promises.
(6) Alternate solution 5 - "assign unique rgrps"
We could go back to a system where multiple allocators are
given unique rgrps to work on (which I've proposed in the past,
but been rejected) but it's pretty much what RHEL6 and prior
releases do by using "try" locks on rgrps. (Which is why
simultaneous allocators often perform better on RHEL6 and older.)
In my opinion, there's no advantage to using a hint when we can
do actual accounting to keep track of spans of blocks too small
to be considered for a reservation.
Regards,
Bob Peterson
Red Hat File Systems
^ permalink raw reply
* Synaptics Driver Problem
From: o at goosey.org @ 2018-07-23 15:29 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAMwyc-Sf6VzfTSHPa66Lwn1ye+SbV8Mvi3Xe=b_-hKpvD9VYZg@mail.gmail.com>
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180723/aef96270/attachment.html>
^ permalink raw reply
* Re: [stable-4.14 00/23] block/scsi multiqueue performance enhancement and
From: Jack Wang @ 2018-07-23 15:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Greg Kroah-Hartman, linux-scsi, linux-block, Wang Jinpu, stable,
Jinpu Wang
In-Reply-To: <f67eedb1-e78e-36a9-b3f5-f2192e9d079a@kernel.dk>
Jens Axboe <axboe@kernel.dk> 于2018年7月23日周一 下午5:05写道：
>
> On 7/23/18 9:00 AM, Jack Wang wrote:
> > Hi Greg,
> >
> > Thanks for quick reply. Please see reply inline.
> >
> >
> >
> > Greg KH <gregkh@linuxfoundation.org> 于2018年7月23日周一 下午3:34写道：
> >>
> >> On Mon, Jul 23, 2018 at 03:24:22PM +0200, Jack Wang wrote:
> >>> Hi Greg,
> >>>
> >>> Please consider this patchset, which include block/scsi multiqueue performance
> >>> enhancement and bugfix.
> >>
> >> What exactly is the performance enhancement? How can you measure it?
> >> How did you measure it?
> > I'm testing on SRP/IBNBD using fio, I've seen +10% with mix IO load,
> > and 50% improvement on small IO (bs=512.) with the patchset.
>
> Big nak on backporting this huge series, it's a lot of core changes.
> It's way beyond the scope of a stable fix backport.
>
> --
> Jens Axboe
>
OK, could you shed light on how could we fix the queue stall problem on 4.14?
My colleague Roman reported to upstream:
https://lkml.org/lkml/2017/10/18/263
It's still there on latest 4.14.
Thanks,
Jack
^ permalink raw reply
* Re: [stable-4.14 00/23] block/scsi multiqueue performance enhancement and
From: Jack Wang @ 2018-07-23 15:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Greg Kroah-Hartman, linux-scsi, linux-block, Wang Jinpu, stable,
Jinpu Wang
In-Reply-To: <f67eedb1-e78e-36a9-b3f5-f2192e9d079a@kernel.dk>
Jens Axboe <axboe@kernel.dk> =E4=BA=8E2018=E5=B9=B47=E6=9C=8823=E6=97=A5=E5=
=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=885:05=E5=86=99=E9=81=93=EF=BC=9A
>
> On 7/23/18 9:00 AM, Jack Wang wrote:
> > Hi Greg,
> >
> > Thanks for quick reply. Please see reply inline.
> >
> >
> >
> > Greg KH <gregkh@linuxfoundation.org> =E4=BA=8E2018=E5=B9=B47=E6=9C=8823=
=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=883:34=E5=86=99=E9=81=93=EF=BC=
=9A
> >>
> >> On Mon, Jul 23, 2018 at 03:24:22PM +0200, Jack Wang wrote:
> >>> Hi Greg,
> >>>
> >>> Please consider this patchset, which include block/scsi multiqueue pe=
rformance
> >>> enhancement and bugfix.
> >>
> >> What exactly is the performance enhancement? How can you measure it?
> >> How did you measure it?
> > I'm testing on SRP/IBNBD using fio, I've seen +10% with mix IO load,
> > and 50% improvement on small IO (bs=3D512.) with the patchset.
>
> Big nak on backporting this huge series, it's a lot of core changes.
> It's way beyond the scope of a stable fix backport.
>
> --
> Jens Axboe
>
OK, could you shed light on how could we fix the queue stall problem on 4.1=
4?
My colleague Roman reported to upstream:
https://lkml.org/lkml/2017/10/18/263
It's still there on latest 4.14.
Thanks,
Jack
^ permalink raw reply
* Re: [PATCH] of: irq: Add a helper function for irq_of_parse_and_map
From: Rob Herring @ 2018-07-23 15:28 UTC (permalink / raw)
To: liu.xiang6
Cc: Frank Rowand, devicetree, linux-kernel@vger.kernel.org,
liuxiang_1999
In-Reply-To: <1532187494-2704-1-git-send-email-liu.xiang6@zte.com.cn>
On Sat, Jul 21, 2018 at 9:38 AM Liu Xiang <liu.xiang6@zte.com.cn> wrote:
>
> Implement a resource managed irq_of_parse_and_map function.
That is obvious from the diff. Why do you need this?
Anything that is a platform device should use platform_get_irq. The
mapping is created by the core Also, of_irq_get() is preferred over
irq_of_parse_and_map() for new users as it has better error return
handling.
>
> Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
> ---
> drivers/of/irq.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/linux/of_irq.h | 7 +++++++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 02ad93a..947fe41 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -45,6 +45,44 @@ unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
> }
> EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
>
> +static void devm_irq_dispose_mapping(struct device *dev, void *res)
> +{
> + irq_dispose_mapping(*(unsigned int *)res);
We don't ref count creating mappings, so this would break for any shared irq.
Rob
^ permalink raw reply
* Re: Query about the handling of a bug reported before
From: Xu, Wen @ 2018-07-23 14:27 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-xfs@vger.kernel.org, Dave Chinner, Darrick J. Wong
In-Reply-To: <20180723123239.GA46987@bfoster>
Hi Brian,
Yeah I tested it which is fixed in latest kernel. I just wonder if there is a specific patch
for this.
Thanks,
Wen
> On Jul 23, 2018, at 8:32 AM, Brian Foster <bfoster@redhat.com> wrote:
>
> On Sun, Jul 22, 2018 at 06:30:03AM +0000, Xu, Wen wrote:
>> Hi XFS developers,
>>
>> I wonder if this bug
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=200127
>>
>> has already been resolved by any patch.
>>
>
> It looks like you're on a kernel that already has the agfl reset
> mechanism. I'm not aware of anything else in that area off the top of my
> head, but FWIW, I don't see the KASAN error with a quick check on a
> KASAN-enabled latest for-next (4.18.0-rc4) kernel. Have you given that a
> try?
>
> Brian
>
>> Thanks,
>> Wen
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [tpm2] getting segfaults with tss-2.0.0, abrmd-2.0.0, tools-3.1.0
From: Scheie, Peter M @ 2018-07-23 15:28 UTC (permalink / raw)
To: tpm2
[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]
-----Original Message-----
From: Philip Tricca [mailto:flihp(a)twobit.org]
Sent: Monday, July 23, 2018 10:24 AM
To: Scheie, Peter M
Cc: Joshua Lock; tpm2(a)lists.01.org
Subject: Re: [tpm2] getting segfaults with tss-2.0.0, abrmd-2.0.0, tools-3.1.0
On 07/20/2018 06:33 AM, Scheie, Peter M wrote:
> -----Original Message-----
> From: Joshua Lock [mailto:joshua.g.lock(a)linux.intel.com]
> Sent: Friday, July 20, 2018 6:00 AM
> To: Scheie, Peter M; tpm2(a)lists.01.org
> Subject: Re: [tpm2] getting segfaults with tss-2.0.0, abrmd-2.0.0, tools-3.1.0
>
> On 19/07/2018 17:08, Scheie, Peter M wrote:
>>
>> -----Original Message-----
>> From: tpm2 [mailto:tpm2-bounces(a)lists.01.org] On Behalf Of Joshua Lock
>> Sent: Thursday, July 19, 2018 5:24 AM
>> To: tpm2(a)lists.01.org
>> Subject: Re: [tpm2] getting segfaults with tss-2.0.0, abrmd-2.0.0, tools-3.1.0
>>
>>
>>
>> On 18/07/2018 22:17, Scheie, Peter M wrote:
>>> By the way, does abrmd default to trying to connect to /dev/tpm0? When
>>> working with the emulator on my laptop, I have to start abrmd with
>>> '--tcti=libtss2-tcti-mssim.so' but I assume that's just for when there
>>> is no TPM device, right?
>>
>> Correct, if no --tcti value is passed abrmd defaults to using the device
>> tcti:
>> https://github.com/tpm2-software/tpm2-abrmd/blob/2296d48a1004aff5f93d6ec23a50819f2a5c5584/src/tcti-dynamic.c#L138
>>
>> At line 142 you can see where the default value of the TCTI library file
>> property is set to "libtss2-tcti-device.so".
>>
>>> So, with tpm2-abrmd running, if I call, say, tpm2_pcrlist or
>>> tpm2_nvlist, to just query the TPM, it will display the PCRs or the NV
>>> indexes but then follow that with a "Segmentation fault", and syslog
>>> shows things like this:
>>>
>>> Jun 27 22:32:42 localhost audit[1432]: ANOM_ABEND auid=1000 uid=1000
>>> gid=1000 ses=1 pid=1432 comm="gdbus" exe="/usr/bin/tpm2_pcrlist" sig=11
>>>
>>> Jun 27 22:32:42 localhost kernel: gdbus[1432]: segfault at 7f8327acc750
>>> ip 00007f8327acc750 sp 00007f8326ab2c38 error 14 in
>>> libtss2-mu.so.0.0.0[7f8328284000+3f000]
>>>
>>> Jun 27 22:32:42 localhost kernel[363]: gdbus[1432]: segfault at
>>> 7f8327acc750 ip 00007f8327acc750 sp 00007f8326ab2c38 error 14 in
>>> libtss2-mu.so.0.0.0[7f8328284000+3f000]
>>>
>>> Trying to write to the TPM, e.g., take ownership, doesn't work at all:
>>>
>>> localhost:~$ tpm2_takeownership -o ownerpass -e endorsepass -l lockpass
>>>
>>> ERROR: Could not change hierarchy for Owner. TPM Error:0x9a2
>>
>> I just recently learned about tpm2_rc_decode[1], it tells me:
>>
>> $ ./tools/aux/tpm2_rc_decode 0x9a2
>> tpm:session(1):authorization failure without DA implications
>>
>> Is this TPM already configured? Have you replicated on more than one system?
>>
>> Joshua
>>
>> ***********************************************************
>> Oops, you are correct: I had already taken ownership of the TPM previously, but was not supplying the owner password when trying to write to it. With that in mind, I can write/configure the TPM as expected. However, I'm still getting a segfault message after each operation.
>>
>
> Glad to hear, though the segfault is worrying. Could you install debug
> packages and find out more about the segfault?
>
> Thanks,
> Joshua
>
> ************************************************************
> Wind River has suggested that since it appears the segfaults are appearing on the "gdbus" process, it may be dbus related. One possibility is that the dbus version in WRL8 is not in sync with the newer tpm2 utilities.
Does WRL9 ship with SELinux or some other security policy enforced?
Philip
*************************************************************
No, or at least we're not using SELinux in this case.
Peter
^ permalink raw reply
* Re: [PATCH 1/4] sched/topology: SD_ASYM_CPUCAPACITY flag detection
From: Morten Rasmussen @ 2018-07-23 15:27 UTC (permalink / raw)
To: Qais Yousef
Cc: vincent.guittot, peterz, linux-kernel, dietmar.eggemann, mingo,
valentin.schneider, linux-arm-kernel
In-Reply-To: <dbd8deec-a79d-5697-0c50-ea1a9ab7e5c9@arm.com>
On Mon, Jul 23, 2018 at 02:25:34PM +0100, Qais Yousef wrote:
> Hi Morten
>
> On 20/07/18 14:32, Morten Rasmussen wrote:
> >The SD_ASYM_CPUCAPACITY sched_domain flag is supposed to mark the
> >sched_domain in the hierarchy where all cpu capacities are visible for
> >any cpu's point of view on asymmetric cpu capacity systems. The
> >scheduler can then take to take capacity asymmetry into account when
>
> Did you mean "s/take to take/try to take/"?
Yes.
[...]
> >+ /*
> >+ * Examine topology from all cpu's point of views to detect the lowest
> >+ * sched_domain_topology_level where a highest capacity cpu is visible
> >+ * to everyone.
> >+ */
> >+ for_each_cpu(i, cpu_map) {
> >+ unsigned long max_capacity = arch_scale_cpu_capacity(NULL, i);
> >+ int tl_id = 0;
> >+
> >+ for_each_sd_topology(tl) {
> >+ if (tl_id < asym_level)
> >+ goto next_level;
> >+
>
> I think if you increment and then continue here you might save the extra
> branch. I didn't look at any disassembly though to verify the generated
> code.
>
> I wonder if we can introduce for_each_sd_topology_from(tl, starting_level)
> so that you can start searching from a provided level - which will make this
> skipping logic unnecessary? So the code will look like
>
> for_each_sd_topology_from(tl, asymc_level) {
> ...
> }
Both options would work. Increment+contrinue instead of goto would be
slightly less readable I think since we would still have the increment
at the end of the loop, but easy to do. Introducing
for_each_sd_topology_from() improve things too, but I wonder if it is
worth it.
> >@@ -1647,18 +1707,27 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
> > struct s_data d;
> > struct rq *rq = NULL;
> > int i, ret = -ENOMEM;
> >+ struct sched_domain_topology_level *tl_asym;
> > alloc_state = __visit_domain_allocation_hell(&d, cpu_map);
> > if (alloc_state != sa_rootdomain)
> > goto error;
> >+ tl_asym = asym_cpu_capacity_level(cpu_map);
> >+
>
> Or maybe this is not a hot path and we don't care that much about optimizing
> the search since you call it unconditionally here even for systems that
> don't care?
It does increase the cost of things like hotplug slightly and
repartitioning of root_domains a slightly but I don't see how we can
avoid it if we want generic code to set this flag. If the costs are not
acceptable I think the only option is to make the detection architecture
specific.
In any case, AFAIK rebuilding the sched_domain hierarchy shouldn't be a
normal and common thing to do. If checking for the flag is not
acceptable on SMP-only architectures, I can move it under arch/arm[,64]
although it is not as clean.
Morten
^ permalink raw reply
* [U-Boot] [PATCH] tegra: Indicate that binman makes all three output files
From: Stephen Warren @ 2018-07-23 15:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180721014927.241479-1-sjg@chromium.org>
On 07/20/2018 07:49 PM, Simon Glass wrote:
> Use GNU make pattern rules to indicate that a single run of binman
> produces all three Tegra output files. The avoids make running binman
> three times (perhaps in parallel) and those instances inteferring with
> each other.
>
> See http://patchwork.ozlabs.org/patch/944611/ for the bug report.
Tested-by: Stephen Warren <swarren@nvidia.com>
(This make feature is very odd; specifying n targets without a % means
they're separate rules, but specifying n targets with a % means it's a
single rule that generates n targets. Nice inconsistency on make's part!)
^ permalink raw reply
* [PATCH 1/4] sched/topology: SD_ASYM_CPUCAPACITY flag detection
From: Morten Rasmussen @ 2018-07-23 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dbd8deec-a79d-5697-0c50-ea1a9ab7e5c9@arm.com>
On Mon, Jul 23, 2018 at 02:25:34PM +0100, Qais Yousef wrote:
> Hi Morten
>
> On 20/07/18 14:32, Morten Rasmussen wrote:
> >The SD_ASYM_CPUCAPACITY sched_domain flag is supposed to mark the
> >sched_domain in the hierarchy where all cpu capacities are visible for
> >any cpu's point of view on asymmetric cpu capacity systems. The
> >scheduler can then take to take capacity asymmetry into account when
>
> Did you mean "s/take to take/try to take/"?
Yes.
[...]
> >+ /*
> >+ * Examine topology from all cpu's point of views to detect the lowest
> >+ * sched_domain_topology_level where a highest capacity cpu is visible
> >+ * to everyone.
> >+ */
> >+ for_each_cpu(i, cpu_map) {
> >+ unsigned long max_capacity = arch_scale_cpu_capacity(NULL, i);
> >+ int tl_id = 0;
> >+
> >+ for_each_sd_topology(tl) {
> >+ if (tl_id < asym_level)
> >+ goto next_level;
> >+
>
> I think if you increment and then continue here you might save the extra
> branch. I didn't look at any disassembly though to verify the generated
> code.
>
> I wonder if we can introduce for_each_sd_topology_from(tl, starting_level)
> so that you can start searching from a provided level - which will make this
> skipping logic unnecessary? So the code will look like
>
> ??? ??? ??? for_each_sd_topology_from(tl, asymc_level) {
> ??? ??? ??? ??? ...
> ??? ??? ??? }
Both options would work. Increment+contrinue instead of goto would be
slightly less readable I think since we would still have the increment
at the end of the loop, but easy to do. Introducing
for_each_sd_topology_from() improve things too, but I wonder if it is
worth it.
> >@@ -1647,18 +1707,27 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
> > struct s_data d;
> > struct rq *rq = NULL;
> > int i, ret = -ENOMEM;
> >+ struct sched_domain_topology_level *tl_asym;
> > alloc_state = __visit_domain_allocation_hell(&d, cpu_map);
> > if (alloc_state != sa_rootdomain)
> > goto error;
> >+ tl_asym = asym_cpu_capacity_level(cpu_map);
> >+
>
> Or maybe this is not a hot path and we don't care that much about optimizing
> the search since you call it unconditionally here even for systems that
> don't care?
It does increase the cost of things like hotplug slightly and
repartitioning of root_domains a slightly but I don't see how we can
avoid it if we want generic code to set this flag. If the costs are not
acceptable I think the only option is to make the detection architecture
specific.
In any case, AFAIK rebuilding the sched_domain hierarchy shouldn't be a
normal and common thing to do. If checking for the flag is not
acceptable on SMP-only architectures, I can move it under arch/arm[,64]
although it is not as clean.
Morten
^ permalink raw reply
* Re: [PATCH 0/2] Documentation: trace: improve probe documentation
From: Jonathan Corbet @ 2018-07-23 15:26 UTC (permalink / raw)
To: Andreas Ziegler
Cc: Changbin Du, Steven Rostedt, Tom Zanussi, linux-doc, linux-kernel
In-Reply-To: <1531739158-31133-1-git-send-email-andreas.ziegler@fau.de>
On Mon, 16 Jul 2018 13:05:56 +0200
Andreas Ziegler <andreas.ziegler@fau.de> wrote:
> This series improves the documentation for uprobes and
> kprobes.
>
> The filename for enabling/disabling single events is 'enable',
> not 'enabled'. kprobetrace.rst lists the files present in the
> per-event directories but missed 'trigger' so far.
I've applied the pair, thanks.
jon
^ permalink raw reply
* python-btrfs & btrfs-heatmap ebuilds now available for Gentoo
From: Holger Hoffstätte @ 2018-07-23 14:25 UTC (permalink / raw)
To: linux-btrfs
I wanted to migrate my collection of questionable shell scripts for btrfs
maintenance/inspection to a more stable foundation and therefore created
Gentoo ebuilds for Hans van Kranenburg's excellent python-btrfs [1] and
btrfs-heatmap [2] packages.
They can be found in my overlay at:
https://github.com/hhoffstaette/portage/tree/master/sys-fs/python-btrfs
https://github.com/hhoffstaette/portage/tree/master/sys-fs/btrfs-heatmap
Both are curently only available for python-3.6 since a change in 3.7
broke the existing python API [3]. As soon as that is fixed I'll add 3.7
to the PYTHON_COMPAT entries.
btrfs-heatmap properly uses the python-exec wrapper and therefore works
regardless of currently selected default python version. :)
I hope this is useful to someone.
cheers,
Holger
[1] https://github.com/knorrie/python-btrfs
[2] https://github.com/knorrie/btrfs-heatmap
[3] https://github.com/knorrie/python-btrfs/issues/13
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.