Re: ftrace global trace_pipe_raw
Hi Steven, happy new year,
On 12/19/2018 05:37 PM, Steven Rostedt wrote:
> On Wed, 19 Dec 2018 12:32:41 +0100
> Claudio wrote:
>
I would imagine the core functionality is already available, since
trace_pipe
in the tracing directory already shows all events regardless of CPU, and so
it would be a matter of doing the same for trace_pipe_raw.
>>>
>>> The difference between trace_pipe and trace_pipe_raw is that trace_pipe
>>> is post processed, and reads the per CPU buffers and interleaves them
>>> one event at a time. The trace_pipe_raw just sends you the raw
>>> unprocessed data directly from the buffers, which are grouped per CPU.
>>
>> I think that what I am looking for, to improve the performance of our system,
>> is a post processed stream of binary entry data, already merged from all CPUs
>> and sorted per timestamp, in the same way that it is done for textual output
>> in __find_next_entry:
>>
>>for_each_tracing_cpu(cpu) {
>>
>> if (ring_buffer_empty_cpu(buffer, cpu))
>> continue;
>>
>> ent = peek_next_entry(iter, cpu, &ts, &lost_events);
>>
>> /*
>>
>> * Pick the entry with the smallest timestamp:
>>
>> */
>> if (ent && (!next || ts < next_ts)) {
>> next = ent;
>> next_cpu = cpu;
>> next_ts = ts;
>> next_lost = lost_events;
>> next_size = iter->ent_size;
>> }
>> }
>>
>> We first tried to use the textual output directly, but this lead to
>> unacceptable overheads in parsing the text.
>>
>> Please correct me if I do not understand, however it seems to me that it
>> would be possible do the same kind of post processing including generating
>> a sorted stream of entries, just avoiding the text output formatting,
>> and outputting the binary data of the entry directly, which would be way
>> more efficient to consume directly from user space correlators.
>>
>> But maybe this is not a general enough requirement to be acceptable for
>> implementing directly into the kernel?
>>
>> We have the requirement of using the OS tracing events, including
>> scheduling events, to react from software immediately
>> (vs doing after-the-fact analysis).
>
> Have you looked at using the perf event interface? I believe it uses a
> single buffer for all events. At least for tracing a single process.
>
> -- Steve
>
Indeed the perf event interface would be awesome, if only it would support
tracing all processes.
Unfortunately for my use case, it can only trace one process on any cpus, or
all processes on one (1) cpu.
I guess for some kind of security concerns..
I'll take a look at how much work it would be to extend the interface for the
any process/any cpu use case.
Ciao and thank you,
Claudio
Re: [PATCH v5 2/2] phy: zynqmp: Add phy driver for xilinx zynqmp phy core
Hi, On 18/12/18 7:15 PM, Anurag Kumar Vulisha wrote: > ZynqMP SoC has a Gigabit Transceiver with four lanes. All the high speed > peripherals such as USB, SATA, PCIE, Display Port and Ethernet SGMII can > rely on any of the four GT lanes for PHY layer. This patch adds driver > for that ZynqMP GT core. > > Signed-off-by: Anurag Kumar Vulisha > --- > Changes in v5: > 1. No functional changes. Added missing Author name > > Changes in v4: > 1. Moved include/dt-bindings/phy/phy.h into patch 1 as suggested by > "Rob Herring" > > Changes in v3: > 1. Corrected the Documentation as suggested by "Vivek Gautam" > > Changes in v2: > 1. Fixed the compilation error when compiled phy-zynqmp.c as a module > 2. Added CONFIG_PM macro in phy-zynqmp.c driver > --- > drivers/phy/Kconfig|8 + > drivers/phy/Makefile |1 + > drivers/phy/phy-zynqmp.c | 1582 > > include/linux/phy/phy-zynqmp.h | 52 ++ > 4 files changed, 1643 insertions(+) > create mode 100644 drivers/phy/phy-zynqmp.c > create mode 100644 include/linux/phy/phy-zynqmp.h > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 60f949e..7a3c900 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -40,6 +40,14 @@ config PHY_XGENE > help > This option enables support for APM X-Gene SoC multi-purpose PHY. > > +config PHY_XILINX_ZYNQMP > + tristate "Xilinx ZynqMP PHY driver" > + depends on ARCH_ZYNQMP > + select GENERIC_PHY > + help > + Enable this to support ZynqMP High Speed Gigabit Transceiver > + that is part of ZynqMP SoC. > + > source "drivers/phy/allwinner/Kconfig" > source "drivers/phy/amlogic/Kconfig" > source "drivers/phy/broadcom/Kconfig" > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 0301e25..2335e85 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o > obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o > obj-$(CONFIG_PHY_XGENE) += phy-xgene.o > obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o > +obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o > obj-$(CONFIG_ARCH_SUNXI) += allwinner/ > obj-$(CONFIG_ARCH_MESON) += amlogic/ > obj-$(CONFIG_LANTIQ) += lantiq/ > diff --git a/drivers/phy/phy-zynqmp.c b/drivers/phy/phy-zynqmp.c > new file mode 100644 > index 000..5caf4f2 > --- /dev/null > +++ b/drivers/phy/phy-zynqmp.c > @@ -0,0 +1,1582 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * phy-zynqmp.c - PHY driver for Xilinx ZynqMP GT. > + * > + * Copyright (C) 2018 Xilinx Inc. > + * > + * Author: Anurag Kumar Vulisha > + * Author: Subbaraya Sundeep > + * > + * This driver is tested for USB, SATA and Display Port currently. > + * Other controllers PCIe and SGMII should also work but that is > + * experimental as of now. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Inter Connect Matrix parameters */ > +#define ICM_CFG0 0x10010 > +#define ICM_CFG1 0x10014 > +#define ICM_CFG0_L0_MASK 0x07 > +#define ICM_CFG0_L1_MASK 0x70 > +#define ICM_CFG1_L2_MASK 0x07 > +#define ICM_CFG2_L3_MASK 0x70 > +#define ICM_CFG_SHIFT4 > + > +/* Inter Connect Matrix allowed protocols */ > +#define ICM_PROTOCOL_PD 0x0 > +#define ICM_PROTOCOL_PCIE0x1 > +#define ICM_PROTOCOL_SATA0x2 > +#define ICM_PROTOCOL_USB 0x3 > +#define ICM_PROTOCOL_DP 0x4 > +#define ICM_PROTOCOL_SGMII 0x5 > + > +/* Test Mode common reset control parameters */ > +#define TM_CMN_RST 0x10018 > +#define TM_CMN_RST_EN0x1 > +#define TM_CMN_RST_SET 0x2 > +#define TM_CMN_RST_MASK 0x3 > + > +/* Refclk selection parameters */ > +#define PLL_REF_SEL0 0x1 > +#define PLL_REF_OFFSET 0x4 > +#define PLL_FREQ_MASK0x1F > +#define PLL_STATUS_READ_OFFSET 0x4000 > +#define PLL_STATUS_LOCKED0x10 > + > +/* PLL SSC step size offsets */ > +#define L0_L0_REF_CLK_SEL0x2860 > +#define L0_PLL_SS_STEPS_0_LSB0x2368 > +#define L0_PLL_SS_STEPS_1_MSB0x236C > +#define L0_PLL_SS_STEP_SIZE_0_LSB0x2370 > +#define L0_PLL_SS_STEP_SIZE_10x2374 > +#define L0_PLL_SS_STEP_SIZE_20x2378 > +#define L0_PLL_SS_STEP_SIZE_3_MSB0x237C > +#define L0_PLL_STATUS_READ_1 0x23E4 > + > +/* SSC step size parameters */ > +#define
Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
On Mon, 14 Jan 2019, dmitry.torok...@gmail.com wrote: > On Fri, Dec 14, 2018 at 12:47:01PM +, Lee Jones wrote: > > On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote: > > > > > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC > > > from > > > STMicroelectronics. > > > The STPMIC1 regulators supply power to an application processor as well > > > as > > > to external system peripherals such as DDR, Flash memories and system > > > devices. It also features onkey button input and an hardware watchdog. > > > The STPMIC1 is controlled via I2C. > > > > > > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration > > > and > > > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd > > > as parent. > > > > > > STPMIC1 MFD and regulator drivers maybe mandatory at boot time. > > > > > > Pascal Paillet (7): > > > changes in v7: > > > * rebase on regul/for-next > > > > > > dt-bindings: mfd: document stpmic1 > > > mfd: stpmic1: add stpmic1 driver > > > dt-bindings: input: document stpmic1 pmic onkey > > > input: stpmic1: add stpmic1 onkey driver > > > dt-bindings: watchdog: document stpmic1 pmic watchdog > > > watchdog: stpmic1: add stpmic1 watchdog driver > > > regulator: stpmic1: fix regulator_lock usage > > > > Could you please remove any patches which have been applied and > > [RESEND]? > > > > Also, is Dmitry planning on Acking: > > > > dt-bindings: input: document stpmic1 pmic onkey > > > > ... or is Rob's Ack enough? > > For bindings I normally defer to Rob (unless I see something that really > bugs me and then I'll speak up). I usually do the opposite. Seeing as Rob is pretty heavily laden with DT patches, I tend to review/apply patches which do not add new DT properties and/or are obvious/trivial and leave Rob to the rest. Your train-set though of course, your decision. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/2] usb: dwc3: Add workaround for host mode VBUS glitch when boot
Hi,
Ran Wang writes:
> +static void dwc3_power_off_all_roothub_ports(struct dwc3 *dwc)
> +{
> + int i, port_num;
> + u32 reg, op_regs_base, offset;
> + void __iomem*xhci_regs;
> +
> + /* xhci regs is not mapped yet, do it temperary here */
> + if (dwc->xhci_resources[0].start) {
> + xhci_regs = ioremap(dwc->xhci_resources[0].start,
> + DWC3_XHCI_REGS_END);
> + if (IS_ERR(xhci_regs)) {
> + dev_err(dwc->dev, "Failed to ioremap xhci_regs\n");
> + return;
> + }
> +
> + op_regs_base = HC_LENGTH(readl(xhci_regs));
> + reg = readl(xhci_regs + XHCI_HCSPARAMS1);
> + port_num = HCS_MAX_PORTS(reg);
> +
> + for (i = 1; i <= port_num; i++) {
> + offset = op_regs_base + XHCI_PORTSC_BASE + 0x10*(i-1);
> + reg = readl(xhci_regs + offset);
> + reg &= ~PORT_POWER;
> + writel(reg, xhci_regs + offset);
> + }
> +
> + iounmap(xhci_regs);
why can't this be done during xhci_gen_setup()?
--
balbi
signature.asc
Description: PGP signature
Re: [alsa-devel] [PATCH v2 4/4] ASoC: add imx-audmix DT binding documentation
On Tue, Jan 15, 2019 at 10:58 PM Rob Herring wrote: > > On Tue, Jan 08, 2019 at 01:05:51PM +, Viorel Suman wrote: > > Add the DT binding documentation for Audio Mixer > > machine driver. > > > > Signed-off-by: Viorel Suman > > --- > > .../devicetree/bindings/sound/imx-audmix.txt | 24 > > ++ > > 1 file changed, 24 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sound/imx-audmix.txt > > > > diff --git a/Documentation/devicetree/bindings/sound/imx-audmix.txt > > b/Documentation/devicetree/bindings/sound/imx-audmix.txt > > new file mode 100644 > > index 000..6ac1230 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/sound/imx-audmix.txt > > @@ -0,0 +1,24 @@ > > +NXP Audio Mixer (AUDMIX) machine driver. > > + > > +Required properties: > > +=== > > + - compatible : Compatible list, contains "fsl,imx-audmix" > > + > > + - model: Short audio card description. > > + > > + - dais : Must contain a list of phandles to AUDMIX connected > > + DAIs. The current implementation requires two > > phandles > > + to SAI interfaces to be provided, the first SAI in > > the > > + list being used to route the AUDMIX output. > > + > > + - audmix-controller: Must contain the phandle to the AUDMIX > > device node. > > I don't think you need 2 nodes for this as this one is just a virtual > device. Just add the dais property to the audmix node. Hi Rob, Thanks for the suggestion. We want to understand better the reasoning behind this. Is it because dais are physically connected to AUDMIX node? In ALSA we usually add all the components inside the associated machine driver virtual node. thanks, Daniel.
Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
> On Jan 14, 2019, at 19:18, Jiri Kosina wrote: > > On Mon, 14 Jan 2019, Kai-Heng Feng wrote: > >> A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ >> but there's no input event from HID subsystem. >> >> Turns out it reports some invalid data: >> [ 22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 >> 00 >> >> After some trial and error, it's another device that doesn't work well >> with ON/SLEEP commands. Disable runtime PM to fix the issue. > > Thanks, I've now applied the patch to for-5.0/upstream-fixes. I am > wondering though we are we seeing these at all - do other OSes not do the > runtime PM on i2c at all? According to the vendor, Windows does use ON/SLEEP, but infrequently. We can use pm_runtime_use_autosuspend() to reduce the frequency of ON/SLEEP commands, but it’s just papering over the touchpad firmware bug. Kai-Heng > > -- > Jiri Kosina > SUSE Labs >
Re: broonie-regulator/for-next boot bisection: v5.0-rc2-20-g61b67608c6b9 on meson8b-odroidc1
On Mon, Jan 14, 2019 at 10:59 PM Mark Brown wrote: > Linus, I'm going to revert this whole series - not sure what's gone > wrong here but I guess we can test easily with kernelci which is good. That's fine and I'm onto it, I am trying to create a mock system to test the gpio-regulator so I have some confidence it's not breaking these boards before submitting again. Yours, Linus Walleij
Re: [RFC v2 6/6] cros_ec: differentiate SCP from EC by feature bit.
On Tue, 08 Jan 2019, Pi-Hsun Shih wrote: > Since a SCP and EC would both exist on a system, and use the cros_ec_dev > driver, we need to differentiate between them for the userspace, or they > would both be registered at /dev/cros_ec, causing a conflict. > > Cc: Enric Balletbo Serra > Cc: Guenter Roeck > Signed-off-by: Pi-Hsun Shih > --- > Changes from v1: > - New patch extracted from Patch 5. > --- > drivers/mfd/cros_ec_dev.c| 9 + > include/linux/mfd/cros_ec.h | 1 + > include/linux/mfd/cros_ec_commands.h | 2 ++ > 3 files changed, 12 insertions(+) The (other) Chromium guys are usually pretty active and are more familiar with this hardware and group of (MFD/Platform) drivers than I am. Thus I'm waiting for one of them to provide their thoughts before applying this. Just make sure you Cc:ed enough of them! -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 1/2] gpio: sprd: Fix the incorrect data register
śr., 16 sty 2019 o 06:06 Baolin Wang napisał(a):
>
> From: Neo Hou
>
> Since differnt type EICs have its own data register to read, thus fix the
> incorrect data register.
>
> Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
> Cc:
> Signed-off-by: Neo Hou
> Signed-off-by: Baolin Wang
> ---
> Changes from v1:
> - Add fix tag and CC stable.
> ---
> drivers/gpio/gpio-eic-sprd.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c
> index e0d6a0a..257df59 100644
> --- a/drivers/gpio/gpio-eic-sprd.c
> +++ b/drivers/gpio/gpio-eic-sprd.c
> @@ -180,7 +180,18 @@ static void sprd_eic_free(struct gpio_chip *chip,
> unsigned int offset)
>
> static int sprd_eic_get(struct gpio_chip *chip, unsigned int offset)
> {
> - return sprd_eic_read(chip, offset, SPRD_EIC_DBNC_DATA);
> + struct sprd_eic *sprd_eic = gpiochip_get_data(chip);
> +
> + switch (sprd_eic->type) {
> + case SPRD_EIC_DEBOUNCE:
> + return sprd_eic_read(chip, offset, SPRD_EIC_DBNC_DATA);
> + case SPRD_EIC_ASYNC:
> + return sprd_eic_read(chip, offset, SPRD_EIC_ASYNC_DATA);
> + case SPRD_EIC_SYNC:
> + return sprd_eic_read(chip, offset, SPRD_EIC_SYNC_DATA);
> + default:
> + return -ENOTSUPP;
> + }
> }
>
> static int sprd_eic_direction_input(struct gpio_chip *chip, unsigned int
> offset)
> --
> 1.7.9.5
>
Both applied for fixes, thanks!
Bartosz
[PATCH -next v2] binderfs: fix error return code in binderfs_fill_super()
Fix to return a negative error code -ENOMEM from the new_inode() and
d_make_root() error handling cases instead of 0, as done elsewhere in
this function.
Fixes: 3ad20fe393b3 ("binder: implement binderfs")
Signed-off-by: Wei Yongjun
---
v1 -> v2: move 'ret = -ENOMEM' out of if
---
drivers/android/binderfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 9518e2e..e4ff4c3 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -518,6 +518,7 @@ static int binderfs_fill_super(struct super_block *sb, void
*data, int silent)
sb->s_fs_info = info;
+ ret = -ENOMEM;
inode = new_inode(sb);
if (!inode)
goto err_without_dentry;
Re: [PATCH 0/4] phy: ti: Add AM654 USB2 support
On 09/01/19 2:44 PM, Roger Quadros wrote: > Hi Kishon, > > On 05/12/18 17:03, Roger Quadros wrote: >> Hi Kishon, >> >> This series extends omap-usb2 PHY driver to be used >> for AM654 USB2 PHY. > > Any comments on this series? If it looks fine, could you please > queue this for -next. Thanks. Sorry for the delay. Merged now to -next. Thanks Kishon > > cheers, > -roger > >> >> cheers, >> -roger >> >> Roger Quadros (4): >> phy: ti: usb2: Fix logic on -EPROBE_DEFER >> phy: ti: Don't depend on OMAP_OCP2SCP >> dt-bindings: phy: ti: Add support for AM654x USB2 PHY >> phy: ti: usb2: Add support for AM654 USB2 PHY >> >> Documentation/devicetree/bindings/phy/ti-phy.txt | 1 + >> drivers/phy/ti/Kconfig | 6 +- >> drivers/phy/ti/phy-omap-usb2.c | 105 >> ++- >> 3 files changed, 67 insertions(+), 45 deletions(-) >> >
[PATCH 1/3] drm/qxl: add mode/framebuffer check functions
Add a helper functions to check video modes. Also add a helper to check
framebuffer buffer objects, using the former for consistency. That way
we should not fail in qxl_primary_atomic_check() because video modes
which are too big will not be added to the mode list in the first place.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 1f8fddcc34..07a37d52c4 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -191,6 +191,21 @@ void qxl_display_read_client_monitors_config(struct
qxl_device *qdev)
}
}
+static int qxl_check_mode(struct qxl_device *qdev,
+ unsigned int width,
+ unsigned int height)
+{
+ if (width * height * 4 > qdev->vram_size)
+ return -ENOMEM;
+ return 0;
+}
+
+static int qxl_check_framebuffer(struct qxl_device *qdev,
+struct qxl_bo *bo)
+{
+ return qxl_check_mode(qdev, bo->surf.width, bo->surf.height);
+}
+
static int qxl_add_monitors_config_modes(struct drm_connector *connector,
unsigned *pwidth,
unsigned *pheight)
@@ -466,12 +481,7 @@ static int qxl_primary_atomic_check(struct drm_plane
*plane,
bo = gem_to_qxl_bo(state->fb->obj[0]);
- if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
- DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
- return -EINVAL;
- }
-
- return 0;
+ return qxl_check_framebuffer(qdev, bo);
}
static int qxl_primary_apply_cursor(struct drm_plane *plane)
@@ -941,20 +951,11 @@ static enum drm_mode_status qxl_conn_mode_valid(struct
drm_connector *connector,
{
struct drm_device *ddev = connector->dev;
struct qxl_device *qdev = ddev->dev_private;
- int i;
- /* TODO: is this called for user defined modes? (xrandr --add-mode)
-* TODO: check that the mode fits in the framebuffer */
+ if (qxl_check_mode(qdev, mode->hdisplay, mode->vdisplay) != 0)
+ return MODE_BAD;
- if (qdev->monitors_config_width == mode->hdisplay &&
- qdev->monitors_config_height == mode->vdisplay)
- return MODE_OK;
-
- for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
- if (common_modes[i].w == mode->hdisplay && common_modes[i].h ==
mode->vdisplay)
- return MODE_OK;
- }
- return MODE_BAD;
+ return MODE_OK;
}
static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
--
2.9.3
[PATCH 2/3] drm/qxl: add qxl_add_mode helper function
Add a helper function to add custom video modes to a connector.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 84 +++
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 07a37d52c4..b87f72f59e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -206,15 +206,36 @@ static int qxl_check_framebuffer(struct qxl_device *qdev,
return qxl_check_mode(qdev, bo->surf.width, bo->surf.height);
}
-static int qxl_add_monitors_config_modes(struct drm_connector *connector,
- unsigned *pwidth,
- unsigned *pheight)
+static int qxl_add_mode(struct drm_connector *connector,
+ unsigned int width,
+ unsigned int height,
+ bool preferred)
+{
+ struct drm_device *dev = connector->dev;
+ struct qxl_device *qdev = dev->dev_private;
+ struct drm_display_mode *mode = NULL;
+ int rc;
+
+ rc = qxl_check_mode(qdev, width, height);
+ if (rc != 0)
+ return 0;
+
+ mode = drm_cvt_mode(dev, width, height, 60, false, false, false);
+ if (preferred)
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+ mode->hdisplay = width;
+ mode->vdisplay = height;
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+ return 1;
+}
+
+static int qxl_add_monitors_config_modes(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct qxl_device *qdev = dev->dev_private;
struct qxl_output *output = drm_connector_to_qxl_output(connector);
int h = output->index;
- struct drm_display_mode *mode = NULL;
struct qxl_head *head;
if (!qdev->monitors_config)
@@ -229,19 +250,7 @@ static int qxl_add_monitors_config_modes(struct
drm_connector *connector,
head = &qdev->client_monitors_config->heads[h];
DRM_DEBUG_KMS("head %d is %dx%d\n", h, head->width, head->height);
- mode = drm_cvt_mode(dev, head->width, head->height, 60, false, false,
- false);
- mode->type |= DRM_MODE_TYPE_PREFERRED;
- mode->hdisplay = head->width;
- mode->vdisplay = head->height;
- drm_mode_set_name(mode);
- *pwidth = head->width;
- *pheight = head->height;
- drm_mode_probed_add(connector, mode);
- /* remember the last custom size for mode validation */
- qdev->monitors_config_width = mode->hdisplay;
- qdev->monitors_config_height = mode->vdisplay;
- return 1;
+ return qxl_add_mode(connector, head->width, head->height, true);
}
static struct mode_size {
@@ -267,22 +276,16 @@ static struct mode_size {
{1920, 1200}
};
-static int qxl_add_common_modes(struct drm_connector *connector,
-unsigned int pwidth,
-unsigned int pheight)
+static int qxl_add_common_modes(struct drm_connector *connector)
{
- struct drm_device *dev = connector->dev;
- struct drm_display_mode *mode = NULL;
- int i;
+ int i, ret = 0;
- for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
- mode = drm_cvt_mode(dev, common_modes[i].w, common_modes[i].h,
- 60, false, false, false);
- if (common_modes[i].w == pwidth && common_modes[i].h == pheight)
- mode->type |= DRM_MODE_TYPE_PREFERRED;
- drm_mode_probed_add(connector, mode);
- }
- return i - 1;
+ for (i = 0; i < ARRAY_SIZE(common_modes); i++)
+ ret += qxl_add_mode(connector,
+ common_modes[i].w,
+ common_modes[i].h,
+ false);
+ return ret;
}
static void qxl_send_monitors_config(struct qxl_device *qdev)
@@ -935,14 +938,25 @@ static int qdev_crtc_init(struct drm_device *dev, int
crtc_id)
static int qxl_conn_get_modes(struct drm_connector *connector)
{
+ struct drm_device *dev = connector->dev;
+ struct qxl_device *qdev = dev->dev_private;
+ struct qxl_output *output = drm_connector_to_qxl_output(connector);
unsigned int pwidth = 1024;
unsigned int pheight = 768;
int ret = 0;
- ret = qxl_add_monitors_config_modes(connector, &pwidth, &pheight);
- if (ret < 0)
- return ret;
- ret += qxl_add_common_modes(connector, pwidth, pheight);
+ if (qdev->client_monitors_config) {
+ struct qxl_head *head;
+ head = &qdev->client_monitors_config->heads[output->index];
+ if (head->width)
+ pwidth = head->width;
+ if (head->height)
+
Re: [PATCH v4 6/9] drm/bridge: cdns: Separate DSI and D-PHY configuration
Hi Maxime,
On 09/01/19 3:03 PM, Maxime Ripard wrote:
> The current configuration of the DSI bridge and its associated D-PHY is
> intertwined. In order to ease the future conversion to the phy framework
> for the D-PHY part, let's split the configuration in two.
>
> Signed-off-by: Maxime Ripard
Can we get Ack from DRM MAINTAINERS?
Thanks
Kishon
> ---
> drivers/gpu/drm/bridge/cdns-dsi.c | 96 ++--
> 1 file changed, 68 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index ce9496d13986..3ac6dd524b6d 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -545,6 +545,11 @@ bridge_to_cdns_dsi_input(struct drm_bridge *bridge)
> return container_of(bridge, struct cdns_dsi_input, bridge);
> }
>
> +static unsigned int mode_to_dpi_hfp(const struct drm_display_mode *mode)
> +{
> + return mode->crtc_hsync_start - mode->crtc_hdisplay;
> +}
> +
> static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
>struct cdns_dphy_cfg *cfg,
>unsigned int dpi_htotal,
> @@ -731,14 +736,12 @@ static unsigned int dpi_to_dsi_timing(unsigned int
> dpi_timing,
> static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
>const struct drm_display_mode *mode,
>struct cdns_dsi_cfg *dsi_cfg,
> - struct cdns_dphy_cfg *dphy_cfg,
>bool mode_valid_check)
> {
> - unsigned long dsi_htotal = 0, dsi_hss_hsa_hse_hbp = 0;
> struct cdns_dsi_output *output = &dsi->output;
> - unsigned int dsi_hfp_ext = 0, dpi_hfp, tmp;
> + unsigned int tmp;
> bool sync_pulse = false;
> - int bpp, nlanes, ret;
> + int bpp, nlanes;
>
> memset(dsi_cfg, 0, sizeof(*dsi_cfg));
>
> @@ -757,8 +760,6 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
> mode->crtc_hsync_end : mode->crtc_hsync_start);
>
> dsi_cfg->hbp = dpi_to_dsi_timing(tmp, bpp, DSI_HBP_FRAME_OVERHEAD);
> - dsi_htotal += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
> - dsi_hss_hsa_hse_hbp += dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
>
> if (sync_pulse) {
> if (mode_valid_check)
> @@ -768,49 +769,90 @@ static int cdns_dsi_mode2cfg(struct cdns_dsi *dsi,
>
> dsi_cfg->hsa = dpi_to_dsi_timing(tmp, bpp,
>DSI_HSA_FRAME_OVERHEAD);
> - dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
> - dsi_hss_hsa_hse_hbp += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
> }
>
> dsi_cfg->hact = dpi_to_dsi_timing(mode_valid_check ?
> mode->hdisplay : mode->crtc_hdisplay,
> bpp, 0);
> - dsi_htotal += dsi_cfg->hact;
> + dsi_cfg->hfp = dpi_to_dsi_timing(mode_to_dpi_hfp(mode), bpp,
> + DSI_HFP_FRAME_OVERHEAD);
>
> - if (mode_valid_check)
> - dpi_hfp = mode->hsync_start - mode->hdisplay;
> - else
> - dpi_hfp = mode->crtc_hsync_start - mode->crtc_hdisplay;
> + return 0;
> +}
> +
> +static int cdns_dphy_validate(struct cdns_dsi *dsi,
> + struct cdns_dsi_cfg *dsi_cfg,
> + struct cdns_dphy_cfg *dphy_cfg,
> + const struct drm_display_mode *mode,
> + bool mode_valid_check)
> +{
> + struct cdns_dsi_output *output = &dsi->output;
> + unsigned long dsi_htotal;
> + unsigned int dsi_hfp_ext = 0;
> +
> + int ret;
>
> - dsi_cfg->hfp = dpi_to_dsi_timing(dpi_hfp, bpp, DSI_HFP_FRAME_OVERHEAD);
> + dsi_htotal = dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
> + if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + dsi_htotal += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
> +
> + dsi_htotal += dsi_cfg->hact;
> dsi_htotal += dsi_cfg->hfp + DSI_HFP_FRAME_OVERHEAD;
>
> if (mode_valid_check)
> ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
> - mode->htotal, bpp,
> + mode->htotal,
> mode->clock * 1000,
> - dsi_htotal, nlanes,
> +
> mipi_dsi_pixel_format_to_bpp(output->dev->format),
> + dsi_htotal,
> + output->dev->lanes,
> &dsi_hfp_ext);
> else
> ret = cdns_dsi_get_dphy_pll_cfg(dsi->dphy, dphy_cfg,
> - mode->crtc_htotal, bpp,
> + mode->crtc_ht
[PATCH 3/3] drm/qxl: use kernel mode db
Add all standard modes from the kernel's video mode data base.
Keep a few non-standard modes in the qxl mode list.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index b87f72f59e..9e49472872 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -256,34 +256,20 @@ static int qxl_add_monitors_config_modes(struct
drm_connector *connector)
static struct mode_size {
int w;
int h;
-} common_modes[] = {
- { 640, 480},
+} extra_modes[] = {
{ 720, 480},
- { 800, 600},
- { 848, 480},
- {1024, 768},
{1152, 768},
- {1280, 720},
- {1280, 800},
{1280, 854},
- {1280, 960},
- {1280, 1024},
- {1440, 900},
- {1400, 1050},
- {1680, 1050},
- {1600, 1200},
- {1920, 1080},
- {1920, 1200}
};
-static int qxl_add_common_modes(struct drm_connector *connector)
+static int qxl_add_extra_modes(struct drm_connector *connector)
{
int i, ret = 0;
- for (i = 0; i < ARRAY_SIZE(common_modes); i++)
+ for (i = 0; i < ARRAY_SIZE(extra_modes); i++)
ret += qxl_add_mode(connector,
- common_modes[i].w,
- common_modes[i].h,
+ extra_modes[i].w,
+ extra_modes[i].h,
false);
return ret;
}
@@ -954,7 +940,8 @@ static int qxl_conn_get_modes(struct drm_connector
*connector)
pheight = head->height;
}
- ret += qxl_add_common_modes(connector);
+ ret += drm_add_modes_noedid(connector, 8192, 8192);
+ ret += qxl_add_extra_modes(connector);
ret += qxl_add_monitors_config_modes(connector);
drm_set_preferred_mode(connector, pwidth, pheight);
return ret;
--
2.9.3
Re: [PATCH v4 9/9] drm/bridge: cdns: Convert to phy framework
Hi,
On 09/01/19 3:03 PM, Maxime Ripard wrote:
> Now that we have everything we need in the phy framework to allow to tune
> the phy parameters, let's convert the Cadence DSI bridge to that API
> instead of creating a ad-hoc driver for its phy.
>
> Signed-off-by: Maxime Ripard
For this too, need ACKs from DRM MAINTAINERS.
Thanks
Kishon
> ---
> drivers/gpu/drm/bridge/Kconfig| 1 +-
> drivers/gpu/drm/bridge/cdns-dsi.c | 485 +++
> drivers/phy/cadence/cdns-dphy.c | 2 +-
> 3 files changed, 61 insertions(+), 427 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 2fee47b0d50b..8840f396a7b6 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -30,6 +30,7 @@ config DRM_CDNS_DSI
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL_BRIDGE
> + select GENERIC_PHY_MIPI_DPHY
> depends on OF
> help
> Support Cadence DPI to DSI bridge. This is an internal
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 3ac6dd524b6d..7b432257ffbe 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -21,6 +21,9 @@
> #include
> #include
>
> +#include
> +#include
> +
> #define IP_CONF 0x0
> #define SP_HS_FIFO_DEPTH(x) (((x) & GENMASK(30, 26)) >> 26)
> #define SP_LP_FIFO_DEPTH(x) (((x) & GENMASK(25, 21)) >> 21)
> @@ -419,44 +422,11 @@
> #define DSI_NULL_FRAME_OVERHEAD 6
> #define DSI_EOT_PKT_SIZE 4
>
> -#define REG_WAKEUP_TIME_NS 800
> -#define DPHY_PLL_RATE_HZ 10800
> -
> -/* DPHY registers */
> -#define DPHY_PMA_CMN(reg)(reg)
> -#define DPHY_PMA_LCLK(reg) (0x100 + (reg))
> -#define DPHY_PMA_LDATA(lane, reg)(0x200 + ((lane) * 0x100) + (reg))
> -#define DPHY_PMA_RCLK(reg) (0x600 + (reg))
> -#define DPHY_PMA_RDATA(lane, reg)(0x700 + ((lane) * 0x100) + (reg))
> -#define DPHY_PCS(reg)(0xb00 + (reg))
> -
> -#define DPHY_CMN_SSM DPHY_PMA_CMN(0x20)
> -#define DPHY_CMN_SSM_EN BIT(0)
> -#define DPHY_CMN_TX_MODE_EN BIT(9)
> -
> -#define DPHY_CMN_PWM DPHY_PMA_CMN(0x40)
> -#define DPHY_CMN_PWM_DIV(x) ((x) << 20)
> -#define DPHY_CMN_PWM_LOW(x) ((x) << 10)
> -#define DPHY_CMN_PWM_HIGH(x) (x)
> -
> -#define DPHY_CMN_FBDIV DPHY_PMA_CMN(0x4c)
> -#define DPHY_CMN_FBDIV_VAL(low, high)(((high) << 11) | ((low) << 22))
> -#define DPHY_CMN_FBDIV_FROM_REG (BIT(10) | BIT(21))
> -
> -#define DPHY_CMN_OPIPDIV DPHY_PMA_CMN(0x50)
> -#define DPHY_CMN_IPDIV_FROM_REG BIT(0)
> -#define DPHY_CMN_IPDIV(x)((x) << 1)
> -#define DPHY_CMN_OPDIV_FROM_REG BIT(6)
> -#define DPHY_CMN_OPDIV(x)((x) << 7)
> -
> -#define DPHY_PSM_CFG DPHY_PCS(0x4)
> -#define DPHY_PSM_CFG_FROM_REGBIT(0)
> -#define DPHY_PSM_CLK_DIV(x) ((x) << 1)
> -
> struct cdns_dsi_output {
> struct mipi_dsi_device *dev;
> struct drm_panel *panel;
> struct drm_bridge *bridge;
> + union phy_configure_opts phy_opts;
> };
>
> enum cdns_dsi_input_id {
> @@ -465,14 +435,6 @@ enum cdns_dsi_input_id {
> CDNS_DSC_INPUT,
> };
>
> -struct cdns_dphy_cfg {
> - u8 pll_ipdiv;
> - u8 pll_opdiv;
> - u16 pll_fbdiv;
> - unsigned long lane_bps;
> - unsigned int nlanes;
> -};
> -
> struct cdns_dsi_cfg {
> unsigned int hfp;
> unsigned int hsa;
> @@ -481,34 +443,6 @@ struct cdns_dsi_cfg {
> unsigned int htotal;
> };
>
> -struct cdns_dphy;
> -
> -enum cdns_dphy_clk_lane_cfg {
> - DPHY_CLK_CFG_LEFT_DRIVES_ALL = 0,
> - DPHY_CLK_CFG_LEFT_DRIVES_RIGHT = 1,
> - DPHY_CLK_CFG_LEFT_DRIVES_LEFT = 2,
> - DPHY_CLK_CFG_RIGHT_DRIVES_ALL = 3,
> -};
> -
> -struct cdns_dphy_ops {
> - int (*probe)(struct cdns_dphy *dphy);
> - void (*remove)(struct cdns_dphy *dphy);
> - void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
> - void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
> - enum cdns_dphy_clk_lane_cfg cfg);
> - void (*set_pll_cfg)(struct cdns_dphy *dphy,
> - const struct cdns_dphy_cfg *cfg);
> - unsigned long (*get_wakeup_time_ns)(struct cdns_dphy *dphy);
> -};
> -
> -struct cdns_dphy {
> - struct cdns_dphy_cfg cfg;
> - void __iomem *regs;
> - struct clk *psm_clk;
> - struct clk *pll_ref_clk;
> - const struct cdns_dphy_ops *ops;
> -};
> -
> struct cdns_dsi_input {
> enum cdns_dsi_input_id id;
> struct drm_bridge bridge;
> @@ -526,7 +460,7 @@ struct cdns_dsi {
> struct reset_control *dsi_p_rst;
> struct clk *dsi_sys_clk;
> bool link_initialized;
> - struct cdns_
Re: [PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
On 2019/1/16 15:51, Ard Biesheuvel wrote:
> On Wed, 16 Jan 2019 at 04:37, Yueyi Li wrote:
>> OK, thanks. But seems this mail be ignored, do i need re-sent the patch?
>>
>> On 2018/12/26 21:49, Ard Biesheuvel wrote:
>>> On Tue, 25 Dec 2018 at 03:30, Yueyi Li wrote:
Hi Ard,
On 2018/12/24 17:45, Ard Biesheuvel wrote:
> Does the following change fix your issue as well?
>
> index 9b432d9fcada..9dcf0ff75a11 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -447,7 +447,7 @@ void __init arm64_memblock_init(void)
> * memory spans, randomize the linear region as well.
> */
>if (memstart_offset_seed > 0 && range >=
> ARM64_MEMSTART_ALIGN) {
> - range = range / ARM64_MEMSTART_ALIGN + 1;
> + range /= ARM64_MEMSTART_ALIGN;
>memstart_addr -= ARM64_MEMSTART_ALIGN *
> ((range *
> memstart_offset_seed) >> 16);
>}
Yes, it can fix this also. I just think modify the first *range*
calculation would be easier to grasp, what do you think?
>>> I don't think there is a difference, to be honest, but I will leave it
>>> up to the maintainers to decide which approach they prefer.
> No it has been merged already. It is in v5.0-rc2 I think.
OK, thanks. :-)
Re: mtd: lpddr: Use struct_size() in kzalloc()
From: Boris Brezillon
On Tue, 2019-01-08 at 21:09:46 UTC, "Gustavo A. R. Silva" wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.
Boris
Re: mtd: cfi: cmdset_0001: Use struct_size() in kmalloc()
From: Boris Brezillon
On Tue, 2019-01-08 at 15:52:44 UTC, "Gustavo A. R. Silva" wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.
Boris
Re: mtd: gen_probe: Use struct_size() in kmalloc()
From: Boris Brezillon
On Tue, 2019-01-08 at 15:36:01 UTC, "Gustavo A. R. Silva" wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.
Boris
Re: [PATCH -next v2] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 08:34:02AM +, Wei Yongjun wrote:
> Fix to return a negative error code -ENOMEM from the new_inode() and
> d_make_root() error handling cases instead of 0, as done elsewhere in
> this function.
>
> Fixes: 3ad20fe393b3 ("binder: implement binderfs")
This should be:
Fixes: 849d540ddfcd ("binderfs: implement "max" mount option")
If you have added that feel free to also add my Reviewed-by.
Thanks!
Christian
> Signed-off-by: Wei Yongjun
> ---
> v1 -> v2: move 'ret = -ENOMEM' out of if
> ---
> drivers/android/binderfs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 9518e2e..e4ff4c3 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -518,6 +518,7 @@ static int binderfs_fill_super(struct super_block *sb,
> void *data, int silent)
>
> sb->s_fs_info = info;
>
> + ret = -ENOMEM;
> inode = new_inode(sb);
> if (!inode)
> goto err_without_dentry;
>
>
>
[PATCH v2] dt-bindings: imx8mq: Number clocks consecutively
This fixes a duplicate use of 232 and numbers the clocks without holes.
Fixes: 1cf3817bf1f5 ("dt-bindings: Add binding for i.MX8MQ CCM")
Signed-off-by: Guido Günther
---
include/dt-bindings/clock/imx8mq-clock.h | 26
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/include/dt-bindings/clock/imx8mq-clock.h
b/include/dt-bindings/clock/imx8mq-clock.h
index b53be41929be..04f7ac345984 100644
--- a/include/dt-bindings/clock/imx8mq-clock.h
+++ b/include/dt-bindings/clock/imx8mq-clock.h
@@ -350,7 +350,7 @@
#define IMX8MQ_CLK_VPU_G2_ROOT 241
/* SCCG PLL GATE */
-#define IMX8MQ_SYS1_PLL_OUT232
+#define IMX8MQ_SYS1_PLL_OUT242
#define IMX8MQ_SYS2_PLL_OUT243
#define IMX8MQ_SYS3_PLL_OUT244
#define IMX8MQ_DRAM_PLL_OUT245
@@ -372,24 +372,24 @@
/* txesc clock */
#define IMX8MQ_CLK_DSI_IPG_DIV 256
-#define IMX8MQ_CLK_TMU_ROOT265
+#define IMX8MQ_CLK_TMU_ROOT257
/* Display root clocks */
-#define IMX8MQ_CLK_DISP_AXI_ROOT 266
-#define IMX8MQ_CLK_DISP_APB_ROOT 267
-#define IMX8MQ_CLK_DISP_RTRM_ROOT 268
+#define IMX8MQ_CLK_DISP_AXI_ROOT 258
+#define IMX8MQ_CLK_DISP_APB_ROOT 259
+#define IMX8MQ_CLK_DISP_RTRM_ROOT 260
-#define IMX8MQ_CLK_OCOTP_ROOT 269
+#define IMX8MQ_CLK_OCOTP_ROOT 261
-#define IMX8MQ_CLK_DRAM_ALT_ROOT 270
-#define IMX8MQ_CLK_DRAM_CORE 271
+#define IMX8MQ_CLK_DRAM_ALT_ROOT 262
+#define IMX8MQ_CLK_DRAM_CORE 263
-#define IMX8MQ_CLK_MU_ROOT 272
-#define IMX8MQ_VIDEO2_PLL_OUT 273
+#define IMX8MQ_CLK_MU_ROOT 264
+#define IMX8MQ_VIDEO2_PLL_OUT 265
-#define IMX8MQ_CLK_CLKO2 274
+#define IMX8MQ_CLK_CLKO2 266
-#define IMX8MQ_CLK_NAND_USDHC_BUS_RAWNAND_CLK 275
+#define IMX8MQ_CLK_NAND_USDHC_BUS_RAWNAND_CLK 267
-#define IMX8MQ_CLK_END 276
+#define IMX8MQ_CLK_END 268
#endif /* __DT_BINDINGS_CLOCK_IMX8MQ_H */
--
2.20.1
[PATCH v2] arm64: defconfig: Add i.MX8MQ boot necessary configs
Enable all the i.MX8MQ configs necessary to boot. Cc: Catalin Marinas Cc: Will Deacon Cc: Shawn Guo Cc: Sascha Hauer Cc: Fabio Estevam Signed-off-by: Abel Vesa [aisheng.d...@nxp.com: add CONFIG_IMX_GPCV2_PM_DOMAINS] Signed-off-by: Dong Aisheng --- Changes since v1: * added the CONFIG_IMX_GPCV2_PM_DOMAINS config arch/arm64/configs/defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 032912e..7633fa4 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -323,6 +323,8 @@ CONFIG_SERIAL_MESON_CONSOLE=y CONFIG_SERIAL_SAMSUNG=y CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_TEGRA=y +CONFIG_SERIAL_IMX=y +CONFIG_SERIAL_IMX_CONSOLE=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_MSM=y CONFIG_SERIAL_MSM_CONSOLE=y @@ -371,6 +373,7 @@ CONFIG_SPI_SPIDEV=m CONFIG_SPMI=y CONFIG_PINCTRL_SINGLE=y CONFIG_PINCTRL_MAX77620=y +CONFIG_PINCTRL_IMX8MQ=y CONFIG_PINCTRL_IMX8QXP=y CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_MSM8916=y @@ -626,6 +629,7 @@ CONFIG_COMMON_CLK_RK808=y CONFIG_COMMON_CLK_SCPI=y CONFIG_COMMON_CLK_CS2000_CP=y CONFIG_COMMON_CLK_S2MPS11=y +CONFIG_CLK_IMX8MQ=y CONFIG_CLK_QORIQ=y CONFIG_COMMON_CLK_PWM=y CONFIG_CLK_IMX8QXP=y @@ -665,6 +669,7 @@ CONFIG_QCOM_COMMAND_DB=y CONFIG_QCOM_GENI_SE=y CONFIG_QCOM_GLINK_SSR=m CONFIG_QCOM_RPMH=y +CONFIG_IMX_GPCV2_PM_DOMAINS=y CONFIG_QCOM_SMEM=y CONFIG_QCOM_SMD_RPM=y CONFIG_QCOM_SMP2P=y -- 2.7.4
Re: [PATCH -next v2] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 09:41:08AM +0100, Christian Brauner wrote:
> On Wed, Jan 16, 2019 at 08:34:02AM +, Wei Yongjun wrote:
> > Fix to return a negative error code -ENOMEM from the new_inode() and
> > d_make_root() error handling cases instead of 0, as done elsewhere in
> > this function.
> >
> > Fixes: 3ad20fe393b3 ("binder: implement binderfs")
>
> This should be:
>
> Fixes: 849d540ddfcd ("binderfs: implement "max" mount option")
>
> If you have added that feel free to also add my Reviewed-by.
Also, this does need to go into char-misc-linus and not -next so you can
drop the -next prefix from the [PATCH ...] prefix. :) Greg will do the
right thing in any case but it's just clearer if you don't add it. :)
Thanks!
Christian
Re: [PATCH v2] phy: phy-rockchip-inno-usb2: drop reading the utmi-avalid property
Hi, On 10/01/19 5:56 PM, Heiko Stuebner wrote: > Am Mittwoch, 9. Januar 2019, 18:14:15 CET schrieb Enric Balletbo i Serra: >> That property is no used in mainline and is not documented. The only >> board using that property is the rk33-99-evb-rev1 and -rev2 in the >> vendor kernel. The existence of a further -rev3 (which also looks way >> better cared for compared rev1+2) indicates that the older ones are >> probably some sort of preproduction models, where some wiring (on the soc >> or board) may have gone wrong. >> >> It is also not clear why this is a hardware-description or a DT >> property, so, as noboby seems to care of this just drop reading that >> property. >> >> Signed-off-by: Enric Balletbo i Serra > > Reviewed-by: Heiko Stuebner For some reason, I don't seem to have the original patch in the inbox. Can you resend it please? Thanks Kishon
Re: [PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
On Tue, Jan 15, 2019 at 11:53:40PM -0700, Nathan Chancellor wrote:
> On Wed, Jan 16, 2019 at 07:42:02AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 15, 2019 at 11:03:02PM -0700, Nathan Chancellor wrote:
> > > When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
> > > '-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
> > > Clang failed at the modpost stage:
> > >
> > > ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > > undefined!
> > > ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > > undefined!
> > > ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > > undefined!
> > >
> > > These functions were marked as extern inline, meaning that if inlining
> > > doesn't happen, the function will be undefined, as it is above.
> > >
> > > This happens to work with GCC because the '-fno-inline-functions' option
> > > respects the __inline attribute so all instances of these functions are
> > > inlined as expected and the definition doesn't actually matter. However,
> > > with Clang and '-fno-inline-functions', a function has to be marked with
> > > the __always_inline attribute to be considered for inlining, which none
> > > of these functions are. Clang tries to find the symbol definition
> > > elsewhere as it was told and fails, which trickles down to modpost.
> > >
> > > To make sure that this code compiles regardless of compiler and make the
> > > intention of the code clearer, use 'static __always_inline' to ensure
> > > that these functions are always inlined. Some alternative solutions
> > > included 'extern __always_inline' or converting these functions to
> > > macros (so the preprocessor deals with them) but I would argue this is
> > > the more "standard" solution.
> > >
> > > Signed-off-by: Nathan Chancellor
> > > ---
> > > drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
> > > b/drivers/staging/rtl8723bs/include/ieee80211.h
> > > index bcc8dfa8e672..959e822315b5 100644
> > > --- a/drivers/staging/rtl8723bs/include/ieee80211.h
> > > +++ b/drivers/staging/rtl8723bs/include/ieee80211.h
> > > @@ -850,18 +850,18 @@ enum ieee80211_state {
> > > #define IP_FMT "%pI4"
> > > #define IP_ARG(x) (x)
> > >
> > > -extern __inline int is_multicast_mac_addr(const u8 *addr)
> > > +static __always_inline int is_multicast_mac_addr(const u8 *addr)
> >
> > Ick, really? This is in a .h file, the .c file sees this, so why isn't
> > clang picking it up? Worst case it just makes it a "normal" function
> > and doesn't inline it, right?
> >
>
> As I understand it, the meaning of 'extern inline' is basically use this
> defintion when inlining, otherwise use one from a different file or
> translation unit. See commit d0a8d9378d16 ("x86/paravirt: Make
> native_save_fl() extern inline"). These functions don't have any other
> declaration/definition so when they aren't inlined, they don't exist.
>
> > How about just replacing "extern" with "static", that should solve this,
> > adding "__always_inline" everywhere is not going to be fun and doesn't
> > make any sense.
> >
>
> Yes, that would work (and what I originally tested). My assumption with
> the code is that it was intended for this function to always be inlined
> but if you'd rather it just be 'static', I am happy to send a v2!
This code is not trying to be that smart, someone just put the extern in
there without realizing it. So making it static is the correct fix, so
a v2 would be great.
Odds are, almost all other places in the kernel that you hit with this
also needs the same fixup, no need to be fancy here :)
thanks,
greg k-h
Re: [PATCH] i2c: imx: defer probing on dma channel request
Hello, On 15.01.2019 23:55, Wolfram Sang wrote: > Hi, > > On Tue, Jan 15, 2019 at 04:03:32PM +0200, Laurentiu Tudor wrote: >> If the dma controller is not yet probed, defer i2c probe. >> The error path in probe was slightly modified (no functional change) >> to avoid triggering this WARN_ON(): >> "cg-pll0-div1 already disabled >> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0" >> >> Signed-off-by: Laurentiu Tudor > > I just applied this series to i2c/for-next: > > http://patchwork.ozlabs.org/project/linux-i2c/list/?series=85099&state=* > > I haven't checked carefully but maybe it fixes/changes your issue? Not really as it doesn't seem to defer probing until the dma controller gets probed. > If not, your patch most likely will need a rebase on top of the above. Will rebase on latest i2c tree and re-send. --- Best Regards, Laurentiu
Re: [PATCH v2 3/6] phy: qcom-qusb2: Add QUSB2 PHY support for msm8998
On 15/01/19 11:41 PM, Bjorn Andersson wrote:
> On Mon 14 Jan 08:36 PST 2019, Jeffrey Hugo wrote:
>
>> MSM8998 contains one QUSB2 PHY which is very similar to the existing
>> sdm845 support.
>>
>
I don't seem to have the dt-binding patch in my inbox. Can you send them as
well?
Thanks
Kishon
> Reviewed-by: Bjorn Andersson
>
>> Signed-off-by: Jeffrey Hugo
>> ---
>> drivers/phy/qualcomm/phy-qcom-qusb2.c | 41
>> +++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
>> b/drivers/phy/qualcomm/phy-qcom-qusb2.c
>> index 9177989f..e5e4f36 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
>> @@ -152,6 +152,32 @@ enum qusb2phy_reg_layout {
>> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>> };
>>
>> +static const unsigned int msm8998_regs_layout[] = {
>> +[QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
>> +[QUSB2PHY_PLL_STATUS] = 0x1a0,
>> +[QUSB2PHY_PORT_TUNE1] = 0x23c,
>> +[QUSB2PHY_PORT_TUNE2] = 0x240,
>> +[QUSB2PHY_PORT_TUNE3] = 0x244,
>> +[QUSB2PHY_PORT_TUNE4] = 0x248,
>> +[QUSB2PHY_PORT_TEST1] = 0x24c,
>> +[QUSB2PHY_PORT_TEST2] = 0x250,
>> +[QUSB2PHY_PORT_POWERDOWN] = 0x210,
>> +[QUSB2PHY_INTR_CTRL] = 0x22c,
>> +};
>> +
>> +static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
>> +QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x13),
>> +QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
>> +QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
>> +QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_LOCK_DELAY, 0x0a),
>> +
>> +QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xa5),
>> +QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x09),
>> +
>> +QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_DIGITAL_TIMERS_TWO, 0x19),
>> +};
>> +
>> +
>> static const unsigned int sdm845_regs_layout[] = {
>> [QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
>> [QUSB2PHY_PLL_STATUS] = 0x1a0,
>> @@ -221,6 +247,18 @@ struct qusb2_phy_cfg {
>> .autoresume_en = BIT(3),
>> };
>>
>> +static const struct qusb2_phy_cfg msm8998_phy_cfg = {
>> +.tbl= msm8998_init_tbl,
>> +.tbl_num= ARRAY_SIZE(msm8998_init_tbl),
>> +.regs = msm8998_regs_layout,
>> +
>> +.disable_ctrl = POWER_DOWN,
>> +.mask_core_ready = CORE_READY_STATUS,
>> +.has_pll_override = true,
>> +.autoresume_en = BIT(0),
>> +.update_tune1_with_efuse = true,
>> +};
>> +
>> static const struct qusb2_phy_cfg sdm845_phy_cfg = {
>> .tbl= sdm845_init_tbl,
>> .tbl_num= ARRAY_SIZE(sdm845_init_tbl),
>> @@ -734,6 +772,9 @@ static int qusb2_phy_exit(struct phy *phy)
>> .compatible = "qcom,msm8996-qusb2-phy",
>> .data = &msm8996_phy_cfg,
>> }, {
>> +.compatible = "qcom,msm8998-qusb2-phy",
>> +.data = &msm8998_phy_cfg,
>> +}, {
>> .compatible = "qcom,sdm845-qusb2-phy",
>> .data = &sdm845_phy_cfg,
>> },
>> --
>> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies,
>> Inc.
>> Qualcomm Technologies, Inc. is a member of the
>> Code Aurora Forum, a Linux Foundation Collaborative Project.
>>
Re: [PATCH v5 0/7] mfd / platform: cros_ec: move cros_ec sysfs attributes to its own drivers.
On Wed, 12 Dec 2018, Enric Balletbo i Serra wrote: > Hi, > > This is another patchset to try to cleanup a bit more the crossed > references for cros-ec driver between the MFD and the platform/chrome > subsystems. > > The purpose of these patches is get rid of the different cros-ec attributes > from mfd/cros_ec_dev to its own sub-driver in platform/chrome. cros_ec_dev > continues instantiating the sub-devices but the sysfs attributes are owned > by the platform driver.E.g. The lightbar driver should own his sysfs > attributes and be instantiated only if the Embedded Controller has a > lightbar. > > The patchset also adds the documentation of the sysfs attributes. > > Most of the patches touches mfd subsystem and platform/chrome so I'd > suggest go all using and inmutable branch. > > Best regards, > Enric [...] > Enric Balletbo i Serra (7): > mfd / platform: cros_ec: use devm_mfd_add_devices > mfd / platform: cros_ec: move lightbar attributes to its own driver > mfd / platform: cros_ec: move vbc attributes to its own driver > mfd / platform: cros_ec: move debugfs attributes to its own driver > mfd / platform: cros_ec: move device sysfs attributes to its own > driver > mfd / platform: cros_ec_vbc: instantiate only if the EC has a VBC > NVRAM > platform/chrome: cros_ec_lightbar: instantiate only if the EC has a > lightbar These patches have been applied to my local MFD tree. It will be pushed when 5.0-rc3 has been released. The MFD tree needs rebasing onto it since it contains all of the MFD patches due for v5.0. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] atm: he: fix sign-extension overflow on large shift
On Tue, Jan 15, 2019 at 06:03:38PM +, Colin King wrote: > From: Colin Ian King > > Shifting the 1 by exp by an int can lead to sign-extension overlow when > exp is 31 since 1 is an signed int and sign-extending this result to an > unsigned long long will set the upper 32 bits. Fix this by shifting an > unsigned long. You could just cast it to unsigned. rate_cps = (unsigned long long) (1U << exp) * (man + 512) >> 9; I don't think it makes a difference at runtime because we just pick buf = 4 either way... regards, dan carpenter
[BUG bisect] kernel BUG at block/bio.c:1833 and fail to mount disk
Hi, On today's next-20190116 I see a bug during boot: [ 6.843308] kernel BUG at ../block/bio.c:1833! [ 6.847723] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM ... [ 7.543824] [] (bio_split) from [<>] ( (null)) [ 7.549881] Code: 13833b01 11c630bc e1a6 e8bd8070 (e7f001f2) (not much in the calltrace) On all my boards. Also QEMU-arm fails. Ultimately the target fails to mount /home from SD card (although root is from NFSv4): Timed out waiting for device dev-disk-by\x2dlabel-home.device. Full console logs: https://krzk.eu/#/builders/25/builds/1079/steps/12/logs/serial0 https://krzk.eu/#/builders/1/builds/3031/steps/12/logs/serial0 1. Arch ARM Linux 2. exynos_defconfig - All my Odroid boards (ARMv7, Exynos) - Odroid HC1, U3, XU3, XU - Systemd 3. All boards boot from TFTP with NFS root (NFSv4) The QEMU arm fails with more information: [ 0.596078] loop: module loaded [ 0.601633] virtio_blk virtio0: [vda] 10240 512-byte logical blocks (5.24 MB/5.00 MiB) [ 0.603320] Internal error: Oops - undefined instruction: 0 [#1] ARM [ 0.603504] Modules linked in: [ 0.603784] CPU: 0 PID: 1 Comm: swapper Tainted: G W 5.0.0-rc2-next-20190116-gcbeb3db #1 [ 0.603905] Hardware name: ARM-Versatile Express [ 0.604329] PC is at bio_split+0x5c/0x64 [ 0.604461] LR is at blk_queue_split+0x47c/0x5f4 [ 0.604553] pc : [<8036e2c4>] lr : [<80376134>] psr: 6013 [ 0.604652] sp : 8681f878 ip : fp : 8699df00 [ 0.604750] r10: 8681f914 r9 : r8 : 007e [ 0.604838] r7 : r6 : 8547ac28 r5 : r4 : [ 0.604937] r3 : 8547b068 r2 : 0060 r1 : r0 : 8699df00 [ 0.605070] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 0.605185] Control: 10c5387d Table: 60004059 DAC: 0051 [ 0.605338] Process swapper (pid: 1, stack limit = 0x(ptrval)) ... [ 0.619332] [<8036e2c4>] (bio_split) from [<80376134>] (blk_queue_split+0x47c/0x5f4) [ 0.619480] [<80376134>] (blk_queue_split) from [<8037bee8>] (blk_mq_make_request+0x80/0x3bc) [ 0.619608] [<8037bee8>] (blk_mq_make_request) from [<80371840>] (generic_make_request+0x1b0/0x364) [ 0.619733] [<80371840>] (generic_make_request) from [<80371a8c>] (submit_bio+0x98/0x194) [ 0.619850] [<80371a8c>] (submit_bio) from [<8020e1b8>] (submit_bh_wbc.constprop.21+0x154/0x17c) [ 0.619980] [<8020e1b8>] (submit_bh_wbc.constprop.21) from [<80210634>] (block_read_full_page+0x3b0/0x3d0) [ 0.620109] [<80210634>] (block_read_full_page) from [<8019139c>] (do_read_cache_page+0x180/0x33c) [ 0.620237] [<8019139c>] (do_read_cache_page) from [<8019156c>] (read_cache_page+0x14/0x1c) [ 0.620388] [<8019156c>] (read_cache_page) from [<80383be4>] (read_dev_sector+0x2c/0xbc) [ 0.620508] [<80383be4>] (read_dev_sector) from [<80386e7c>] (read_lba+0x134/0x1b4) [ 0.620623] [<80386e7c>] (read_lba) from [<80387234>] (efi_partition+0xbc/0x8e8) [ 0.620741] [<80387234>] (efi_partition) from [<80386114>] (check_partition+0x11c/0x1e8) [ 0.620856] [<80386114>] (check_partition) from [<80384298>] (rescan_partitions+0x94/0x45c) [ 0.620971] [<80384298>] (rescan_partitions) from [<80213230>] (__blkdev_get+0x260/0x404) [ 0.621087] [<80213230>] (__blkdev_get) from [<802134d8>] (blkdev_get+0x104/0x2f4) [ 0.621206] [<802134d8>] (blkdev_get) from [<80382f9c>] (__device_add_disk+0x498/0x4fc) [ 0.621325] [<80382f9c>] (__device_add_disk) from [<804317f0>] (virtblk_probe+0x444/0x744) [ 0.621444] [<804317f0>] (virtblk_probe) from [<803d3df0>] (virtio_dev_probe+0x258/0x330) [ 0.621561] [<803d3df0>] (virtio_dev_probe) from [<80415864>] (really_probe+0xf4/0x2c8) [ 0.621675] [<80415864>] (really_probe) from [<80415b9c>] (driver_probe_device+0x60/0x16c) [ 0.621788] [<80415b9c>] (driver_probe_device) from [<80415d84>] (__driver_attach+0xdc/0xe0) [ 0.621911] [<80415d84>] (__driver_attach) from [<80413d3c>] (bus_for_each_dev+0x68/0xb4) [ 0.622024] [<80413d3c>] (bus_for_each_dev) from [<80414e04>] (bus_add_driver+0x100/0x20c) [ 0.622137] [<80414e04>] (bus_add_driver) from [<804166b0>] (driver_register+0x78/0x10c) [ 0.622253] [<804166b0>] (driver_register) from [<8091b5e4>] (init+0x70/0x9c) [ 0.622403] [<8091b5e4>] (init) from [<801025ec>] (do_one_initcall+0x54/0x194) [ 0.622525] [<801025ec>] (do_one_initcall) from [<80900e14>] (kernel_init_freeable+0x12c/0x1c8) [ 0.622658] [<80900e14>] (kernel_init_freeable) from [<80628c08>] (kernel_init+0x8/0x110) [ 0.622776] [<80628c08>] (kernel_init) from [<801010e8>] (ret_from_fork+0x14/0x2c) [ 0.622887] Exception stack(0x8681ffb0 to 0x8681fff8) [ 0.623021] ffa0: [ 0.623242] ffc0: 0
Re: [PATCH v1 5/8] scsi: ufs: qcom: Expose the reset controller for PHY
On 12/01/19 4:31 AM, Evan Green wrote:
> Expose a reset controller that the phy can use to perform its
> initialization in a single callback.
>
> Also, change the use of the phy functions from ufs-qcom such that
> phy_poweron actually fires up the phy, and phy_poweroff actually
> powers it down.
>
> Signed-off-by: Evan Green
Can I get Ack for this patch from SCSI MAINTAINERS?
Thanks
Kishon
>
> ---
> Note: This change depends on the remaining changes in this series,
> since UFS PHY reset now needs to be done by the PHY driver.
>
> drivers/scsi/ufs/Kconfig| 1 +
> drivers/scsi/ufs/ufs-qcom.c | 110 +---
> drivers/scsi/ufs/ufs-qcom.h | 4 ++
> 3 files changed, 71 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 2ddbb26d9c265..63c5c4115981f 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -100,6 +100,7 @@ config SCSI_UFS_QCOM
> tristate "QCOM specific hooks to UFS controller platform driver"
> depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
> select PHY_QCOM_UFS
> + select RESET_CONTROLLER
> help
> This selects the QCOM specific additions to UFSHCD platform driver.
> UFS host on QCOM needs some vendor specific configuration before
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index 3aeadb14aae1e..db46f9a64b54c 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ufshcd.h"
> #include "ufshcd-pltfrm.h"
> @@ -49,6 +50,11 @@ static void ufs_qcom_get_default_testbus_cfg(struct
> ufs_qcom_host *host);
> static int ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div(struct ufs_hba *hba,
> u32 clk_cycles);
>
> +static struct ufs_qcom_host *rcdev_to_ufs_host(struct reset_controller_dev
> *rcd)
> +{
> + return container_of(rcd, struct ufs_qcom_host, rcdev);
> +}
> +
> static void ufs_qcom_dump_regs_wrapper(struct ufs_hba *hba, int offset, int
> len,
> const char *prefix, void *priv)
> {
> @@ -255,11 +261,6 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba
> *hba)
> if (is_rate_B)
> phy_set_mode(phy, PHY_MODE_UFS_HS_B);
>
> - /* Assert PHY reset and apply PHY calibration values */
> - ufs_qcom_assert_reset(hba);
> - /* provide 1ms delay to let the reset pulse propagate */
> - usleep_range(1000, 1100);
> -
> /* phy initialization - calibrate the phy */
> ret = phy_init(phy);
> if (ret) {
> @@ -268,15 +269,6 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba
> *hba)
> goto out;
> }
>
> - /* De-assert PHY reset and start serdes */
> - ufs_qcom_deassert_reset(hba);
> -
> - /*
> - * after reset deassertion, phy will need all ref clocks,
> - * voltage, current to settle down before starting serdes.
> - */
> - usleep_range(1000, 1100);
> -
> /* power on phy - start serdes and phy's power and clocks */
> ret = phy_power_on(phy);
> if (ret) {
> @@ -290,7 +282,6 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> return 0;
>
> out_disable_phy:
> - ufs_qcom_assert_reset(hba);
> phy_exit(phy);
> out:
> return ret;
> @@ -554,21 +545,10 @@ static int ufs_qcom_suspend(struct ufs_hba *hba, enum
> ufs_pm_op pm_op)
> ufs_qcom_disable_lane_clks(host);
> phy_power_off(phy);
>
> - /* Assert PHY soft reset */
> - ufs_qcom_assert_reset(hba);
> - goto out;
> - }
> -
> - /*
> - * If UniPro link is not active, PHY ref_clk, main PHY analog power
> - * rail and low noise analog power rail for PLL can be switched off.
> - */
> - if (!ufs_qcom_is_link_active(hba)) {
> + } else if (!ufs_qcom_is_link_active(hba)) {
> ufs_qcom_disable_lane_clks(host);
> - phy_power_off(phy);
> }
>
> -out:
> return ret;
> }
>
> @@ -578,21 +558,26 @@ static int ufs_qcom_resume(struct ufs_hba *hba, enum
> ufs_pm_op pm_op)
> struct phy *phy = host->generic_phy;
> int err;
>
> - err = phy_power_on(phy);
> - if (err) {
> - dev_err(hba->dev, "%s: failed enabling regs, err = %d\n",
> - __func__, err);
> - goto out;
> - }
> + if (ufs_qcom_is_link_off(hba)) {
> + err = phy_power_on(phy);
> + if (err) {
> + dev_err(hba->dev, "%s: failed enabling regs, err =
> %d\n",
> + __func__, err);
> + return err;
> + }
>
> - err = ufs_qcom_enable_lane_clks(host);
> - if (err)
> - goto out;
> + err = ufs_qcom_enable_lane_clks(host);
> + if (err)
Re: [BUG bisect] kernel BUG at block/bio.c:1833 and fail to mount disk
On Wed, 16 Jan 2019 at 09:52, Krzysztof Kozlowski wrote: > > Hi, > > On today's next-20190116 I see a bug during boot: > [ 6.843308] kernel BUG at ../block/bio.c:1833! > [ 6.847723] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > ... > [ 7.543824] [] (bio_split) from [<>] ( (null)) > [ 7.549881] Code: 13833b01 11c630bc e1a6 e8bd8070 (e7f001f2) > > (not much in the calltrace) > On all my boards. Also QEMU-arm fails. > I forgot the bisect commit: 258cfdfaf7bd729e759a0a91fd00ac9794796ad3 is the first bad commit commit 258cfdfaf7bd729e759a0a91fd00ac9794796ad3 Author: Ming Lei Date: Fri Jan 11 19:01:15 2019 +0800 block: use bio_for_each_bvec() to compute multi-page bvec count :04 04 d79b2e71d308650df4764ff644f29d3a24dbab96 0a5d624843b805ee0c9fd9a7e2d5163f5b15b167 M block BR, Krzysztof
[PATCH net V4] vhost: log dirty page correctly
Vhost dirty page logging API is designed to sync through GPA. But we
try to log GIOVA when device IOTLB is enabled. This is wrong and may
lead to missing data after migration.
To solve this issue, when logging with device IOTLB enabled, we will:
1) reuse the device IOTLB translation result of GIOVA->HVA mapping to
get HVA, for writable descriptor, get HVA through iovec. For used
ring update, translate its GIOVA to HVA
2) traverse the GPA->HVA mapping to get the possible GPA and log
through GPA. Pay attention this reverse mapping is not guaranteed
to be unique, so we should log each possible GPA in this case.
This fix the failure of scp to guest during migration. In -next, we
will probably support passing GIOVA->GPA instead of GIOVA->HVA.
Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API")
Reported-by: Jintack Lim
Cc: Jintack Lim
Signed-off-by: Jason Wang
---
Changes from V3:
- make sure each part of the hva was logged when crossing the boundary
of memory regions
Changes from V2:
- check and log the case of range overlap
- remove unnecessary u64 cast
- use smp_wmb() for the case of device IOTLB as well
Changes from V1:
- return error instead of warn
---
drivers/vhost/net.c | 3 +-
drivers/vhost/vhost.c | 97 ---
drivers/vhost/vhost.h | 3 +-
3 files changed, 87 insertions(+), 16 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 36f3d0f49e60..bca86bf7189f 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1236,7 +1236,8 @@ static void handle_rx(struct vhost_net *net)
if (nvq->done_idx > VHOST_NET_BATCH)
vhost_net_signal_used(nvq);
if (unlikely(vq_log))
- vhost_log_write(vq, vq_log, log, vhost_len);
+ vhost_log_write(vq, vq_log, log, vhost_len,
+ vq->iov, in);
total_len += vhost_len;
if (unlikely(vhost_exceeds_weight(++recv_pkts, total_len))) {
vhost_poll_queue(&vq->poll);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 9f7942cbcbb2..babbb32b9bf0 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1733,13 +1733,87 @@ static int log_write(void __user *log_base,
return r;
}
+static int log_write_hva(struct vhost_virtqueue *vq, u64 hva, u64 len)
+{
+ struct vhost_umem *umem = vq->umem;
+ struct vhost_umem_node *u;
+ u64 start, end, l, min;
+ int r;
+ bool hit = false;
+
+ while (len) {
+ min = len;
+ /* More than one GPAs can be mapped into a single HVA. So
+* iterate all possible umems here to be safe.
+*/
+ list_for_each_entry(u, &umem->umem_list, link) {
+ if (u->userspace_addr > hva - 1 + len ||
+ u->userspace_addr - 1 + u->size < hva)
+ continue;
+ start = max(u->userspace_addr, hva);
+ end = min(u->userspace_addr - 1 + u->size,
+ hva - 1 + len);
+ l = end - start + 1;
+ r = log_write(vq->log_base,
+ u->start + start - u->userspace_addr,
+ l);
+ if (r < 0)
+ return r;
+ hit = true;
+ min = min(l, min);
+ }
+
+ if (!hit)
+ return -EFAULT;
+
+ len -= min;
+ hva += min;
+ }
+
+ return 0;
+}
+
+static int log_used(struct vhost_virtqueue *vq, u64 used_offset, u64 len)
+{
+ struct iovec iov[64];
+ int i, ret;
+
+ if (!vq->iotlb)
+ return log_write(vq->log_base, vq->log_addr + used_offset, len);
+
+ ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
+len, iov, 64, VHOST_ACCESS_WO);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < ret; i++) {
+ ret = log_write_hva(vq, (uintptr_t)iov[i].iov_base,
+ iov[i].iov_len);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
- unsigned int log_num, u64 len)
+ unsigned int log_num, u64 len, struct iovec *iov, int count)
{
int i, r;
/* Make sure data written is seen before log. */
smp_wmb();
+
+ if (vq->iotlb) {
+ for (i = 0; i < count; i++) {
+ r = log_write_hva(vq, (uintptr_t)iov[i].iov_base,
+ iov[i].iov_len);
+ if (r < 0)
+ return r;
+
Re: [PATCH v4] irqchip/mmp: only touch the PJ4 & FIQ bits on enable/disable
On Tue, 2019-01-15 at 11:22 +0100, Thomas Gleixner wrote:
> On Thu, 20 Dec 2018, Lubomir Rintel wrote:
>
> > On an OLPC XO 1.75 machine, the "security processor" handles the GPIO 71
> > and 72 interrupts. Don't reset the "route to SP" bit (4).
> >
> > I'm just assuming the bit 4 is the "route to SP" bit -- it fixes the
> > SP-based keyboard for me and defines
> > ICU_INT_ROUTE_SP_IRQ to be 1 << 4. When asked for a data sheet, Marvell
> > was not helpful.
> >
> > Signed-off-by: Lubomir Rintel
> > Acked-by: Pavel Machek
> >
> > ---
> > I'm not removing the defines from regs-icu.h at the moment.
> > Of the MPP2 defines there, only MMP2_ICU_INT4_MASK ends up actually
> > being used, in one place. That said, the header servers mostly as
> > a documentation, because the documentation for the platform is lacking.
> >
> > Changes since v3:
> > - Use #defined instead of integer literals
> >
> > Changes since v2:
> > - Correct subsystem maintainers on Cc (irqchip)
> >
> > Changes since v1:
> > - Adjusted wording & ack from Pavel
> > ---
> > drivers/irqchip/irq-mmp.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
> > index 25f32e1d7764..65fa5a1d8310 100644
> > --- a/drivers/irqchip/irq-mmp.c
> > +++ b/drivers/irqchip/irq-mmp.c
> > @@ -34,6 +34,10 @@
> > #define SEL_INT_PENDING(1 << 6)
> > #define SEL_INT_NUM_MASK 0x3f
> >
> > +#define MMP2_ICU_INT_ROUTE_SP_IRQ (1 << 4)
>
> Where is this used?
Nowhere really. I can remove it I guess.
> > +#define MMP2_ICU_INT_ROUTE_PJ4_IRQ (1 << 5)
> > +#define MMP2_ICU_INT_ROUTE_PJ4_FIQ (1 << 6)
> > +
> > struct icu_chip_data {
> > int nr_irqs;
> > unsigned intvirq_base;
> > @@ -190,7 +194,8 @@ static const struct mmp_intc_conf mmp_conf = {
> > static const struct mmp_intc_conf mmp2_conf = {
> > .conf_enable= 0x20,
> > .conf_disable = 0x0,
> > - .conf_mask = 0x7f,
> > + .conf_mask = MMP2_ICU_INT_ROUTE_PJ4_IRQ |
> > + MMP2_ICU_INT_ROUTE_PJ4_FIQ,
>
> So the mask changes from 0x7f to 0x60, but the changelog does not mention
> any of this. It only talks about bit 4
The subject line was supposed to say that.
The point was in general not to touch the bit whose meanings are not
interesting or not known. I'll try to figure out better wording (and
I'm thankful for suggestions).
>
> Thanks,
>
> tglx
Thank you
Lubo
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 07:25:47AM +0100, Christian Brauner wrote:
> On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> > Fix to return a negative error code -ENOMEM from the new_inode() and
> > d_make_root() error handling cases instead of 0, as done elsewhere in
> > this function.
> >
> > Fixes: 3ad20fe393b3 ("binder: implement binderfs")
> > Signed-off-by: Wei Yongjun
> > ---
> > drivers/android/binderfs.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > index 9518e2e..2bf4b2b 100644
> > --- a/drivers/android/binderfs.c
> > +++ b/drivers/android/binderfs.c
> > @@ -519,8 +519,10 @@ static int binderfs_fill_super(struct super_block *sb,
> > void *data, int silent)
> > sb->s_fs_info = info;
> >
> > inode = new_inode(sb);
> > - if (!inode)
> > + if (!inode) {
> > + ret = -ENOMEM;
>
> Hey, thanks for the patch. Just a nit:
> can you please just do?
>
> ret = -ENOMEM;
> inode = new_inode(sb);
>
> This is more consistent with how we do it everywhere else and let's us
> avoid shoving ret = -ENOMEM into two places.
>
Btw, your style is why you have this bug. I don't have strong feelings
about this either way, I'm just pointing it out.
regards,
dan carpenter
Re: [PATCH v2 1/6] dt-bindings: phy-qcom: Add support for msm8998 usb
On 15/01/19 11:38 PM, Bjorn Andersson wrote: > On Mon 14 Jan 08:36 PST 2019, Jeffrey Hugo wrote: > >> USB on msm8998 utilizes the QUSB2 and QMP phys, similar to sdm845. >> >> Signed-off-by: Jeffrey Hugo >> --- >> Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 5 + >> Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt | 1 + >> 2 files changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> index 41a1074..6061b6f 100644 >> --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt >> @@ -9,6 +9,7 @@ Required properties: >> "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 >> "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, >> "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, >> + "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, >> "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, >> "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, >> "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. >> @@ -42,6 +43,8 @@ Required properties: >> "aux", "cfg_ahb", "ref". >> For "qcom,msm8996-qmp-usb3-phy" must contain: >> "aux", "cfg_ahb", "ref". >> +For "qcom,msm8998-qmp-usb3-phy" must contain: >> +"aux", "cfg_ahb", "ref". >> For "qcom,sdm845-qmp-usb3-phy" must contain: >> "aux", "cfg_ahb", "ref", "com_aux". >> For "qcom,sdm845-qmp-usb3-uni-phy" must contain: >> @@ -60,6 +63,8 @@ Required properties: >> For "qcom,msm8996-qmp-pcie-phy" must contain: >> "phy", "common", "cfg". >> For "qcom,msm8996-qmp-usb3-phy" must contain >> + "phy", "common". > > Odd indentation. > > > Apart from this, you have my > > Reviewed-by: Bjorn Andersson Fixed the indentation and merged it. Thanks Kishon
Re: [PATCH v2 3/6] phy: qcom-qusb2: Add QUSB2 PHY support for msm8998
Hi,
On 16/01/19 2:20 PM, Kishon Vijay Abraham I wrote:
>
>
> On 15/01/19 11:41 PM, Bjorn Andersson wrote:
>> On Mon 14 Jan 08:36 PST 2019, Jeffrey Hugo wrote:
>>
>>> MSM8998 contains one QUSB2 PHY which is very similar to the existing
>>> sdm845 support.
>>>
>>
> I don't seem to have the dt-binding patch in my inbox. Can you send them as
> well?
Ignore my request. I found the patch.
Thanks
Kishon
>
> Thanks
> Kishon
>> Reviewed-by: Bjorn Andersson
>>
>>> Signed-off-by: Jeffrey Hugo
>>> ---
>>> drivers/phy/qualcomm/phy-qcom-qusb2.c | 41
>>> +++
>>> 1 file changed, 41 insertions(+)
>>>
>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
>>> b/drivers/phy/qualcomm/phy-qcom-qusb2.c
>>> index 9177989f..e5e4f36 100644
>>> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
>>> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
>>> @@ -152,6 +152,32 @@ enum qusb2phy_reg_layout {
>>> QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>>> };
>>>
>>> +static const unsigned int msm8998_regs_layout[] = {
>>> + [QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
>>> + [QUSB2PHY_PLL_STATUS] = 0x1a0,
>>> + [QUSB2PHY_PORT_TUNE1] = 0x23c,
>>> + [QUSB2PHY_PORT_TUNE2] = 0x240,
>>> + [QUSB2PHY_PORT_TUNE3] = 0x244,
>>> + [QUSB2PHY_PORT_TUNE4] = 0x248,
>>> + [QUSB2PHY_PORT_TEST1] = 0x24c,
>>> + [QUSB2PHY_PORT_TEST2] = 0x250,
>>> + [QUSB2PHY_PORT_POWERDOWN] = 0x210,
>>> + [QUSB2PHY_INTR_CTRL] = 0x22c,
>>> +};
>>> +
>>> +static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
>>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x13),
>>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
>>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
>>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_LOCK_DELAY, 0x0a),
>>> +
>>> + QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xa5),
>>> + QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x09),
>>> +
>>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_DIGITAL_TIMERS_TWO, 0x19),
>>> +};
>>> +
>>> +
>>> static const unsigned int sdm845_regs_layout[] = {
>>> [QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
>>> [QUSB2PHY_PLL_STATUS] = 0x1a0,
>>> @@ -221,6 +247,18 @@ struct qusb2_phy_cfg {
>>> .autoresume_en = BIT(3),
>>> };
>>>
>>> +static const struct qusb2_phy_cfg msm8998_phy_cfg = {
>>> + .tbl= msm8998_init_tbl,
>>> + .tbl_num= ARRAY_SIZE(msm8998_init_tbl),
>>> + .regs = msm8998_regs_layout,
>>> +
>>> + .disable_ctrl = POWER_DOWN,
>>> + .mask_core_ready = CORE_READY_STATUS,
>>> + .has_pll_override = true,
>>> + .autoresume_en = BIT(0),
>>> + .update_tune1_with_efuse = true,
>>> +};
>>> +
>>> static const struct qusb2_phy_cfg sdm845_phy_cfg = {
>>> .tbl= sdm845_init_tbl,
>>> .tbl_num= ARRAY_SIZE(sdm845_init_tbl),
>>> @@ -734,6 +772,9 @@ static int qusb2_phy_exit(struct phy *phy)
>>> .compatible = "qcom,msm8996-qusb2-phy",
>>> .data = &msm8996_phy_cfg,
>>> }, {
>>> + .compatible = "qcom,msm8998-qusb2-phy",
>>> + .data = &msm8998_phy_cfg,
>>> + }, {
>>> .compatible = "qcom,sdm845-qusb2-phy",
>>> .data = &sdm845_phy_cfg,
>>> },
>>> --
>>> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies,
>>> Inc.
>>> Qualcomm Technologies, Inc. is a member of the
>>> Code Aurora Forum, a Linux Foundation Collaborative Project.
>>>
[PATCH 3/5] staging: erofs: decrease the shrink count in erofs_workgroup_get
It is more suitable to update in erofs_workgroup_get since
it's actually the one matched with erofs_workgroup_put.
Signed-off-by: Gao Xiang
---
drivers/staging/erofs/utils.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index d24945aab133..5695efaeb43a 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -34,29 +34,29 @@ static atomic_long_t erofs_global_shrink_cnt;
#define __erofs_workgroup_get(grp) atomic_inc(&(grp)->refcount)
#define __erofs_workgroup_put(grp) atomic_dec(&(grp)->refcount)
-static int erofs_workgroup_get(struct erofs_workgroup *grp, int *ocnt)
+static int erofs_workgroup_get(struct erofs_workgroup *grp)
{
int o;
repeat:
o = erofs_wait_on_workgroup_freezed(grp);
-
if (unlikely(o <= 0))
return -1;
if (unlikely(atomic_cmpxchg(&grp->refcount, o, o + 1) != o))
goto repeat;
- *ocnt = o;
+ /* decrease refcount paired by erofs_workgroup_put */
+ if (unlikely(o == 1))
+ atomic_long_dec(&erofs_global_shrink_cnt);
return 0;
}
-struct erofs_workgroup *erofs_find_workgroup(
- struct super_block *sb, pgoff_t index, bool *tag)
+struct erofs_workgroup *erofs_find_workgroup(struct super_block *sb,
+pgoff_t index, bool *tag)
{
struct erofs_sb_info *sbi = EROFS_SB(sb);
struct erofs_workgroup *grp;
- int oldcount;
repeat:
rcu_read_lock();
@@ -65,15 +65,12 @@ struct erofs_workgroup *erofs_find_workgroup(
*tag = xa_pointer_tag(grp);
grp = xa_untag_pointer(grp);
- if (erofs_workgroup_get(grp, &oldcount)) {
+ if (erofs_workgroup_get(grp)) {
/* prefer to relax rcu read side */
rcu_read_unlock();
goto repeat;
}
- /* decrease refcount added by erofs_workgroup_put */
- if (unlikely(oldcount == 1))
- atomic_long_dec(&erofs_global_shrink_cnt);
DBG_BUGON(index != grp->index);
}
rcu_read_unlock();
--
2.14.4
[PATCH 1/5] staging: erofs: sunset erofs_workstation_cleanup_all
There is only one user calling erofs_workstation_cleanup_all,
and it is no likely that more users will use in that way
in the future.
Signed-off-by: Gao Xiang
---
Hi,
These 5 patches are all cleanup patches, no logic change.
Thanks,
Gao Xiang
drivers/staging/erofs/internal.h | 5 -
drivers/staging/erofs/super.c| 3 ++-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index c3de24e7fb67..80cc09ea787d 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -283,11 +283,6 @@ extern int erofs_register_workgroup(struct super_block *sb,
extern unsigned long erofs_shrink_workstation(struct erofs_sb_info *sbi,
unsigned long nr_shrink, bool cleanup);
-static inline void erofs_workstation_cleanup_all(struct super_block *sb)
-{
- erofs_shrink_workstation(EROFS_SB(sb), ~0UL, true);
-}
-
extern void erofs_workgroup_free_rcu(struct erofs_workgroup *grp);
#ifdef EROFS_FS_HAS_MANAGED_CACHE
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 45c7f6ddb9f5..69e1840d3842 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -494,7 +494,8 @@ static void erofs_put_super(struct super_block *sb)
mutex_lock(&sbi->umount_mutex);
#ifdef CONFIG_EROFS_FS_ZIP
- erofs_workstation_cleanup_all(sb);
+ /* clean up the compression space of this sb */
+ erofs_shrink_workstation(EROFS_SB(sb), ~0UL, true);
#endif
erofs_unregister_super(sb);
--
2.14.4
[PATCH 4/5] staging: erofs: staticize erofs_shrink_count, erofs_shrink_scan
Move erofs_shrinker_info to utils.c and therefore
no need to globalize erofs_shrink_count and erofs_shrink_scan.
Signed-off-by: Gao Xiang
---
drivers/staging/erofs/internal.h | 5 +
drivers/staging/erofs/super.c| 6 --
drivers/staging/erofs/utils.c| 14 ++
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 967ec1a56726..304c79d253ae 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -589,10 +589,7 @@ extern struct page *erofs_allocpage(struct list_head
*pool, gfp_t gfp);
extern void erofs_register_super(struct super_block *sb);
extern void erofs_unregister_super(struct super_block *sb);
-extern unsigned long erofs_shrink_count(struct shrinker *shrink,
- struct shrink_control *sc);
-extern unsigned long erofs_shrink_scan(struct shrinker *shrink,
- struct shrink_control *sc);
+extern struct shrinker erofs_shrinker_info;
#ifndef lru_to_page
#define lru_to_page(head) (list_entry((head)->prev, struct page, lru))
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 69e1840d3842..af5140eede18 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -539,12 +539,6 @@ static void erofs_kill_sb(struct super_block *sb)
kill_block_super(sb);
}
-static struct shrinker erofs_shrinker_info = {
- .scan_objects = erofs_shrink_scan,
- .count_objects = erofs_shrink_count,
- .seeks = DEFAULT_SEEKS,
-};
-
static struct file_system_type erofs_fs_type = {
.owner = THIS_MODULE,
.name = "erofs",
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index 5695efaeb43a..5f61f99f4c10 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -270,14 +270,14 @@ void erofs_unregister_super(struct super_block *sb)
spin_unlock(&erofs_sb_list_lock);
}
-unsigned long erofs_shrink_count(struct shrinker *shrink,
-struct shrink_control *sc)
+static unsigned long erofs_shrink_count(struct shrinker *shrink,
+ struct shrink_control *sc)
{
return atomic_long_read(&erofs_global_shrink_cnt);
}
-unsigned long erofs_shrink_scan(struct shrinker *shrink,
- struct shrink_control *sc)
+static unsigned long erofs_shrink_scan(struct shrinker *shrink,
+ struct shrink_control *sc)
{
struct erofs_sb_info *sbi;
struct list_head *p;
@@ -333,3 +333,9 @@ unsigned long erofs_shrink_scan(struct shrinker *shrink,
return freed;
}
+struct shrinker erofs_shrinker_info = {
+ .scan_objects = erofs_shrink_scan,
+ .count_objects = erofs_shrink_count,
+ .seeks = DEFAULT_SEEKS,
+};
+
--
2.14.4
[PATCH 2/5] staging: erofs: localize erofs_workgroup_get
Staticize erofs_workgroup_get since no external user
out of utils.c directly calls erofs_workgroup_get.
Signed-off-by: Gao Xiang
---
drivers/staging/erofs/internal.h | 21 -
drivers/staging/erofs/utils.c| 19 +++
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 80cc09ea787d..967ec1a56726 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -252,28 +252,7 @@ static inline int erofs_wait_on_workgroup_freezed(struct
erofs_workgroup *grp)
}
#endif
-static inline int erofs_workgroup_get(struct erofs_workgroup *grp, int *ocnt)
-{
- int o;
-
-repeat:
- o = erofs_wait_on_workgroup_freezed(grp);
-
- if (unlikely(o <= 0))
- return -1;
-
- if (unlikely(atomic_cmpxchg(&grp->refcount, o, o + 1) != o))
- goto repeat;
-
- *ocnt = o;
- return 0;
-}
-
-#define __erofs_workgroup_get(grp) atomic_inc(&(grp)->refcount)
-#define __erofs_workgroup_put(grp) atomic_dec(&(grp)->refcount)
-
extern int erofs_workgroup_put(struct erofs_workgroup *grp);
-
extern struct erofs_workgroup *erofs_find_workgroup(
struct super_block *sb, pgoff_t index, bool *tag);
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index aed211cd5875..d24945aab133 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -31,6 +31,25 @@ struct page *erofs_allocpage(struct list_head *pool, gfp_t
gfp)
static atomic_long_t erofs_global_shrink_cnt;
#ifdef CONFIG_EROFS_FS_ZIP
+#define __erofs_workgroup_get(grp) atomic_inc(&(grp)->refcount)
+#define __erofs_workgroup_put(grp) atomic_dec(&(grp)->refcount)
+
+static int erofs_workgroup_get(struct erofs_workgroup *grp, int *ocnt)
+{
+ int o;
+
+repeat:
+ o = erofs_wait_on_workgroup_freezed(grp);
+
+ if (unlikely(o <= 0))
+ return -1;
+
+ if (unlikely(atomic_cmpxchg(&grp->refcount, o, o + 1) != o))
+ goto repeat;
+
+ *ocnt = o;
+ return 0;
+}
struct erofs_workgroup *erofs_find_workgroup(
struct super_block *sb, pgoff_t index, bool *tag)
--
2.14.4
[PATCH 5/5] staging: erofs: drop the extern prefix for function definitions
Fix all `CHECK: extern prototypes should be avoided in .h files' reported by checkpatch.pl. Signed-off-by: Gao Xiang --- drivers/staging/erofs/internal.h | 47 +-- drivers/staging/erofs/unzip_vle.h | 24 ++-- 2 files changed, 33 insertions(+), 38 deletions(-) diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h index 304c79d253ae..3a27c255950b 100644 --- a/drivers/staging/erofs/internal.h +++ b/drivers/staging/erofs/internal.h @@ -252,23 +252,20 @@ static inline int erofs_wait_on_workgroup_freezed(struct erofs_workgroup *grp) } #endif -extern int erofs_workgroup_put(struct erofs_workgroup *grp); -extern struct erofs_workgroup *erofs_find_workgroup( - struct super_block *sb, pgoff_t index, bool *tag); - -extern int erofs_register_workgroup(struct super_block *sb, - struct erofs_workgroup *grp, bool tag); - -extern unsigned long erofs_shrink_workstation(struct erofs_sb_info *sbi, - unsigned long nr_shrink, bool cleanup); - -extern void erofs_workgroup_free_rcu(struct erofs_workgroup *grp); +int erofs_workgroup_put(struct erofs_workgroup *grp); +struct erofs_workgroup *erofs_find_workgroup(struct super_block *sb, +pgoff_t index, bool *tag); +int erofs_register_workgroup(struct super_block *sb, +struct erofs_workgroup *grp, bool tag); +unsigned long erofs_shrink_workstation(struct erofs_sb_info *sbi, + unsigned long nr_shrink, bool cleanup); +void erofs_workgroup_free_rcu(struct erofs_workgroup *grp); #ifdef EROFS_FS_HAS_MANAGED_CACHE -extern int erofs_try_to_free_all_cached_pages(struct erofs_sb_info *sbi, - struct erofs_workgroup *egrp); -extern int erofs_try_to_free_cached_page(struct address_space *mapping, - struct page *page); +int erofs_try_to_free_all_cached_pages(struct erofs_sb_info *sbi, + struct erofs_workgroup *egrp); +int erofs_try_to_free_cached_page(struct address_space *mapping, + struct page *page); #define MNGD_MAPPING(sbi) ((sbi)->managed_cache->i_mapping) #else @@ -495,8 +492,8 @@ static inline void __submit_bio(struct bio *bio, unsigned op, unsigned op_flags) #define EROFS_IO_MAX_RETRIES_NOFAILCONFIG_EROFS_FS_IO_MAX_RETRIES #endif -extern struct page *__erofs_get_meta_page(struct super_block *sb, - erofs_blk_t blkaddr, bool prio, bool nofail); +struct page *__erofs_get_meta_page(struct super_block *sb, erofs_blk_t blkaddr, + bool prio, bool nofail); static inline struct page *erofs_get_meta_page(struct super_block *sb, erofs_blk_t blkaddr, bool prio) @@ -510,7 +507,7 @@ static inline struct page *erofs_get_meta_page_nofail(struct super_block *sb, return __erofs_get_meta_page(sb, blkaddr, prio, true); } -extern int erofs_map_blocks(struct inode *, struct erofs_map_blocks *, int); +int erofs_map_blocks(struct inode *, struct erofs_map_blocks *, int); static inline struct page * erofs_get_inline_page(struct inode *inode, @@ -530,9 +527,6 @@ static inline unsigned long erofs_inode_hash(erofs_nid_t nid) #endif } -extern struct inode *erofs_iget(struct super_block *sb, - erofs_nid_t nid, bool dir); - extern const struct inode_operations erofs_generic_iops; extern const struct inode_operations erofs_symlink_iops; extern const struct inode_operations erofs_fast_symlink_iops; @@ -547,6 +541,8 @@ static inline bool is_inode_fast_symlink(struct inode *inode) return inode->i_op == &erofs_fast_symlink_iops; } +struct inode *erofs_iget(struct super_block *sb, erofs_nid_t nid, bool dir); + /* namei.c */ extern const struct inode_operations erofs_dir_iops; @@ -584,13 +580,12 @@ static inline void erofs_vunmap(const void *mem, unsigned int count) } /* utils.c */ -extern struct page *erofs_allocpage(struct list_head *pool, gfp_t gfp); - -extern void erofs_register_super(struct super_block *sb); -extern void erofs_unregister_super(struct super_block *sb); - extern struct shrinker erofs_shrinker_info; +struct page *erofs_allocpage(struct list_head *pool, gfp_t gfp); +void erofs_register_super(struct super_block *sb); +void erofs_unregister_super(struct super_block *sb); + #ifndef lru_to_page #define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) #endif diff --git a/drivers/staging/erofs/unzip_vle.h b/drivers/staging/erofs/unzip_vle.h index 5a4e1b62c0d1..9dafa8dc712c 100644 --- a/drivers/staging/erofs/unzip_vle.h +++ b/drivers/staging/erofs/unzip_vle.h @@ -212,18 +212,18 @@ static inline void z_erofs_onlinepage_endio(struct page *page) #define Z_EROFS_VLE_VMAP_GLOBAL_PAGES 2048 /* unzip_vle_lz4.c */ -extern int z_erofs_vle_plain_copy(struct page **compressed_pages, - unsigned clusterpages, struct page **pages, - unsigned nr_pages, unsigned short pageofs); -
Re: [PATCHv2 1/6] mfd: altera-sysmgr: Add SOCFPGA System Manager
On Fri, Dec 21, 2018 at 1:21 AM wrote:
>
> From: Thor Thayer
>
> The SOCFPGA System Manager register block aggregates different
> peripheral functions into one area.
> On 32 bit ARM parts, handle in the same way as syscon.
> On 64 bit ARM parts, the System Manager can only be accessed by
> EL3 secure mode. Since a SMC call to EL3 is required, this new
> driver uses regmaps similar to syscon to handle the SMC call.
>
> Since regmaps abstract out the underlying register access, the
> changes to drivers accessing the System Manager are minimal.
>
> Signed-off-by: Thor Thayer
> ---
> v2 Implement Arnd's changes.
>1. Change socfpga_is_s10() to check compatible string.
> Add new compatible string for Stratix10 in bindings
> and add proper detection method.
>2. Replace base cast with resource_size_t member.
>3. Change s10_sysmgr_regmap_cfg to altr_sysmgr_regmap_cfg to
> be generic.
>4. Always use 4 byte width.
>5. Initialize the .reg_read and .reg_write in S10 case only.
>6. Remove call to syscon in 32bit ARM case and handle both
> ARM32 and ARM64 in of_sysmgr_register().
>7. Replace IS_ERR_OR_NULL() with IS_ERR().
>8. Remove compatible check functions except phandle function.
These all look good, thanks for the good updates!
> +struct regmap *altr_sysmgr_node_to_regmap(struct device_node *np)
> +{
> + struct altr_sysmgr *sysmgr = NULL;
> +
> + if (!p_sysmgr)
> + sysmgr = of_sysmgr_register(np);
> + else
> + sysmgr = p_sysmgr;
> +
> + if (IS_ERR(sysmgr))
> + return ERR_CAST(sysmgr);
> +
> + return sysmgr->regmap;
> +}
> +EXPORT_SYMBOL_GPL(altr_sysmgr_node_to_regmap);
> +
> +struct regmap *altr_sysmgr_regmap_lookup_by_phandle(struct device_node *np,
> + const char *property)
> +{
> + struct device_node *sysmgr_np;
> + struct regmap *regmap;
> +
> + if (property)
> + sysmgr_np = of_parse_phandle(np, property, 0);
> + else
> + sysmgr_np = np;
> +
> + if (!sysmgr_np)
> + return ERR_PTR(-ENODEV);
> +
> + regmap = altr_sysmgr_node_to_regmap(sysmgr_np);
> + of_node_put(sysmgr_np);
> +
> + return regmap;
> +}
> +EXPORT_SYMBOL_GPL(altr_sysmgr_regmap_lookup_by_phandle);
> +
> +static int sysmgr_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct altr_sysmgr *sysmgr;
> + struct resource *res;
> +
> + /* Skip Initialization if already created */
> + if (p_sysmgr)
> + goto finish;
> +
> + sysmgr = of_sysmgr_register(pdev->dev.of_node);
> + if (IS_ERR(sysmgr)) {
> + dev_err(dev, "regmap init failed\n");
> + return -ENODEV;
> + }
It seems odd to still have these two ways of registering the sysmgr,
from either the probe function or the lookup.
Since the sysmgr should always get probed before its users, you could
try to change it like this:
- let only the probe() function register it and create the regmap, then
set the regmap as the private data of the device.
- In lookup_by_phandle(), use driver_find_device() to look up the
'struct device' based on its of_node(), by comparing dev->of_node
to of_parse_phandle(np, property).
- return the private data of the device.
That will also let you remove the global variable and make it (theoretically)
work with multiple sysmgr devices, which is generally the preferred way to
write a driver.
> +#ifdef CONFIG_MFD_ALTERA_SYSMGR
> +struct regmap *altr_sysmgr_node_to_regmap(struct device_node *np);
> +struct regmap *altr_sysmgr_regmap_lookup_by_compatible(const char *s);
> +struct regmap *altr_sysmgr_regmap_lookup_by_pdevname(const char *s);
> +struct regmap *altr_sysmgr_regmap_lookup_by_phandle(struct device_node *np,
> + const char *property);
> +
You seem to have some dead declarations from before the cleanup that
should be removed now. Please go through the header file one more time
to see what is actually still used.
Arnd
Re: [PATCH v10 00/27] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM)
On Thu, 3 Jan 2019 at 13:06, Sudeep Holla wrote:
>
> On Thu, Nov 29, 2018 at 06:46:33PM +0100, Ulf Hansson wrote:
> > Over the years this series have been iterated and discussed at various Linux
> > conferences and LKML. In this new v10, a quite significant amount of changes
> > have been made to address comments from v8 and v9. A summary is available
> > below, although let's start with a brand new clarification of the motivation
> > behind this series.
>
> I would like to raise few points, not blockers as such but need to be
> discussed and resolved before proceeding further.
> 1. CPU Idle Retention states
> - How will be deal with flattening (which brings back the DT bindings,
> i.e. do we have all we need) ? Because today there are no users of
> this binding yet. I know we all agreed and added after LPC2017 but
> I am not convinced about flattening with only valid states.
Not exactly sure I understand what you are concerned about here. When
it comes to users of the new DT binding, I am converting two new
platforms in this series to use of it.
Note, the flattened model is still a valid option to describe the CPU
idle states after these changes. Especially when there are no last man
standing activities to manage by Linux and no shared resource that
need to prevent cluster idle states, when it's active.
> - Will domain governor ensure not to enter deeper idles states based
> on its sub-domain states. E.g.: when CPUs are in retention, so
> called container/cluster domain can enter retention or below and not
> power off states.
I have tried to point this out as a known limitation in genpd of the
current series, possibly I have failed to communicate that clearly.
Anyway, I fully agree that this needs to be addressed in a future
step.
Note that, this isn't a specific limitation to how idle states are
selected for CPUs and CPU clusters by genpd, but is rather a
limitation to any hierarchical PM domain topology managed by genpd
that has multiple idle states.
Do note, I already started hacking on this and intend to post patches
on top of this series, as these changes isn't needed for those two
ARM64 platforms I have deployed support for.
> - Is the case of not calling cpu_pm_{enter,exit} handled now ?
It is still called, so no changes in regards to that as apart of this series.
When it comes to actually manage the "last man activities" as part of
selecting an idle state of the cluster, that is going to be addressed
on top as "optimizations".
In principle we should not need to call cpu_pm_enter|exit() in the
idle path at all, but rather only cpu_cluster_pm_enter|exit() when a
cluster idle state is selected. That should improve latency when
selecting an idle state for a CPU. However, to reach that point
additional changes are needed in various drivers, such as the gic
driver for example.
>
> 2. Now that we have SDM845 which may soon have platform co-ordinated idle
>support in mainline, I *really* would like to see some power comparison
>numbers(i.e. PC without cluster idle states). This has been the main theme
>for most of the discussion on this topic for years and now we are close
>to have some platform, we need to try.
I have quite recently been talking to Qcom folkz about this as well,
but no commitments are made.
Although I fully agree that some comparison would be great, it still
doesn't matter much, as we anyway need to support PSCI OSI mode in
Linux. Lorenzo have agreed to this as well.
>
> 3. Also, after adding such complexity, we really need a platform with an
>option to build and upgrade firmware easily. This will help to prevent
>this being not maintained for long without a platform to test, also
>avoid adding lots of quirks to deal with broken firmware so that newer
>platforms deal those issues in the firmware correctly.
I don't see how this series change anything from what we already have
today with the PSCI FW. No matter of OSI or PC mode is used, there are
complexity involved.
Although, of course I agree with you, that we should continue to try
to convince ARM vendors about moving to the public version of ATF and
avoid proprietary FW binaries as much as possible.
Kind regards
Uffe
Re: [PATCH v1] phy: qcom-ufs: Use iopoll.h readl_poll_timeout macro
On 28/12/2018 17:05, Andy Gross wrote: > On Fri, Dec 21, 2018 at 11:13:18AM +0100, Marc Gonzalez wrote: > >> The private copy of readl_poll_timeout is no longer needed. >> Use the implementation in iopoll.h instead. >> >> Signed-off-by: Marc Gonzalez > > Reviewed-by: Andy Gross Would this patch go through your tree or Kishon's tree? Regards.
Re: [PATCH v2] dt-bindings: imx8mq: Number clocks consecutively
Am Mittwoch, den 16.01.2019, 09:41 +0100 schrieb Guido Günther:
> This fixes a duplicate use of 232 and numbers the clocks without holes.
>
> Fixes: 1cf3817bf1f5 ("dt-bindings: Add binding for i.MX8MQ CCM")
>
> Signed-off-by: Guido Günther
I agree that this should be applied as a fix for 5.0-rc.
Reviewed-by: Lucas Stach
> ---
> include/dt-bindings/clock/imx8mq-clock.h | 26
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/include/dt-bindings/clock/imx8mq-clock.h
> b/include/dt-bindings/clock/imx8mq-clock.h
> index b53be41929be..04f7ac345984 100644
> --- a/include/dt-bindings/clock/imx8mq-clock.h
> +++ b/include/dt-bindings/clock/imx8mq-clock.h
> @@ -350,7 +350,7 @@
> > #define IMX8MQ_CLK_VPU_G2_ROOT 241
>
> /* SCCG PLL GATE */
> > -#define IMX8MQ_SYS1_PLL_OUT232
> > +#define IMX8MQ_SYS1_PLL_OUT242
> > #define IMX8MQ_SYS2_PLL_OUT243
> > #define IMX8MQ_SYS3_PLL_OUT244
> > #define IMX8MQ_DRAM_PLL_OUT245
> @@ -372,24 +372,24 @@
> /* txesc clock */
> #define IMX8MQ_CLK_DSI_IPG_DIV 256
>
> > -#define IMX8MQ_CLK_TMU_ROOT265
> > +#define IMX8MQ_CLK_TMU_ROOT257
>
> /* Display root clocks */
> > -#define IMX8MQ_CLK_DISP_AXI_ROOT 266
> > -#define IMX8MQ_CLK_DISP_APB_ROOT 267
> > -#define IMX8MQ_CLK_DISP_RTRM_ROOT 268
> > +#define IMX8MQ_CLK_DISP_AXI_ROOT 258
> > +#define IMX8MQ_CLK_DISP_APB_ROOT 259
> > +#define IMX8MQ_CLK_DISP_RTRM_ROOT 260
>
> > -#define IMX8MQ_CLK_OCOTP_ROOT 269
> > +#define IMX8MQ_CLK_OCOTP_ROOT 261
>
> > -#define IMX8MQ_CLK_DRAM_ALT_ROOT 270
> > -#define IMX8MQ_CLK_DRAM_CORE 271
> > +#define IMX8MQ_CLK_DRAM_ALT_ROOT 262
> > +#define IMX8MQ_CLK_DRAM_CORE 263
>
> > -#define IMX8MQ_CLK_MU_ROOT 272
> > -#define IMX8MQ_VIDEO2_PLL_OUT 273
> > +#define IMX8MQ_CLK_MU_ROOT 264
> > +#define IMX8MQ_VIDEO2_PLL_OUT 265
>
> > -#define IMX8MQ_CLK_CLKO2 274
> > +#define IMX8MQ_CLK_CLKO2 266
>
> > -#define IMX8MQ_CLK_NAND_USDHC_BUS_RAWNAND_CLK 275
> > +#define IMX8MQ_CLK_NAND_USDHC_BUS_RAWNAND_CLK 267
>
> > -#define IMX8MQ_CLK_END 276
> > +#define IMX8MQ_CLK_END 268
> #endif /* __DT_BINDINGS_CLOCK_IMX8MQ_H */
[PATCH v4 0/4] Reduce NUMA related overhead in perf record profiling on large server systems
It has been observed that trace reading thread runs on the same hw thread most of the time during perf record sampling collection. This scheduling layout leads up to 30% profiling overhead in case when some cpu intensive workload fully utilizes a large server system with NUMA. Overhead usually arises from remote (cross node) HW and memory references that have much longer latencies than local ones [1]. This patch set implements --affinity option that lowers 30% overhead completely for serial trace streaming (--affinity=cpu) and from 30% to 10% for AIO1 (--aio=1) trace streaming (--affinity=node|cpu). See OVERHEAD section below for more details. Implemented extension provides users with capability to instruct Perf tool to bounce trace reading thread's affinity mask between NUMA nodes (--affinity=node) or assign the thread to the exact cpu (--affinity=cpu) that trace buffer being processed belongs to. The extension brings improvement in case of full system utilization when Perf tool process contends with workload process on cpu cores. In case a system has free cores to execute Perf tool process during profiling the default system scheduling layout induces the lowest overhead. The patch set has been validated on BT benchmark from NAS Parallel Benchmarks [2] running on dual socket, 44 cores, 88 hw threads Broadwell system with kernels v4.4-21-generic (Ubuntu 16.04) and v4.20.0-rc5 (tip perf/core). OVERHEAD: BENCH REPORT BASED ELAPSED TIME BASED v4.20.0-rc5 (tip perf/core): (current) SERIAL-SYS / BASE : 1.27x (14.37/11.31), 1.29x (15.19/11.69) SERIAL-NODE / BASE : 1.15x (13.04/11.31), 1.17x (13.79/11.69) SERIAL-CPU / BASE : 1.00x (11.32/11.31), 1.01x (11.89/11.69) AIO1-SYS/ BASE : 1.29x (14.58/11.31), 1.29x (15.26/11.69) AIO1-NODE / BASE : 1.08x (12.23/11.31), 1,11x (13.01/11.69) AIO1-CPU/ BASE : 1.07x (12.14/11.31), 1.08x (12.83/11.69) v4.4.0-21-generic (Ubuntu 16.04 LTS): (current) SERIAL-SYS / BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) SERIAL-NODE / BASE : 1.19x (13.02/10.87), 1.23x (14.03/11.32) SERIAL-CPU / BASE : 1.03x (11.21/10.87), 1.07x (12.18/11.32) AIO1-SYS/ BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) AIO1-NODE / BASE : 1.10x (12.04/10.87), 1.15x (13.03/11.32) AIO1-CPU/ BASE : 1.12x (12.20/10.87), 1.15x (13.09/11.32) The patch set is generated for acme perf/core repository. --- Alexey Budankov (4): perf record: allocate affinity masks perf record: bind the AIO user space buffers to nodes perf record: apply affinity masks when reading mmap buffers perf record: implement --affinity=node|cpu option tools/perf/Documentation/perf-record.txt | 5 ++ tools/perf/builtin-record.c | 47 ++- tools/perf/perf.h| 8 ++ tools/perf/util/evlist.c | 10 ++- tools/perf/util/evlist.h | 2 +- tools/perf/util/mmap.c | 100 ++- tools/perf/util/mmap.h | 4 +- 7 files changed, 166 insertions(+), 10 deletions(-) --- Changes in v4: - fixed compilation issue converting pr_warn() to pr_warning() - implemented stop if mbind() fails - corrected mmap_params->cpu_map initialization to be based on /sys/devices/system/cpu/online - separated node cpu map generation into build_node_mask() Changes in v3: - converted PERF_AFFINITY_EOF to PERF_AFFINITY_MAX - corrected code style issues - adjusted __aio_alloc,__aio_bind,__aio_free() implementation - separated mask manipulations into __adjust_affinity() and __setup_affinity_mask() - implemented mapping of c index into online cpu index - adjusted indentation at record__parse_affinity() Changes in v2: - made debug affinity mode message user friendly - converted affinity mode defines to enum values - implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind and put HAVE_LIBNUMA_SUPPORT #ifdefs in there - separated AIO buffers binding to patch 2/4 --- [1] https://en.wikipedia.org/wiki/Non-uniform_memory_access [2] https://www.nas.nasa.gov/publications/npb.html [3] http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html [4] http://man7.org/linux/man-pages/man2/mbind.2.html --- ENVIRONMENT AND MEASUREMENTS: MACHINE: broadwell, dual socket, 44 core, 88 threads /proc/cpuinfo processor : 87 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz stepping: 1 microcode : 0xb19 cpu MHz : 1200.117 cache size : 56320 KB physical id : 1 siblings: 44 core id : 28 cpu cores : 22 apicid
Re: [PATCH 1/5] staging: erofs: sunset erofs_workstation_cleanup_all
On 2019/1/16 16:59, Gao Xiang wrote: > There is only one user calling erofs_workstation_cleanup_all, > and it is no likely that more users will use in that way > in the future. > > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,
Re: [PATCH 02/17] clocksource: davinci-timer: new driver
On 14/01/19 10:09 PM, Bartosz Golaszewski wrote: > pon., 14 sty 2019 o 13:20 Sekhar Nori napisał(a): >> >> Hi Bartosz, >> >> On 11/01/19 10:51 PM, Bartosz Golaszewski wrote: >>> From: Bartosz Golaszewski >>> >>> Currently the clocksource and clockevent support for davinci platforms >>> lives in mach-davinci. It hard-codes many things, used global variables, >>> implements functionalities unused by any platform and has code fragments >>> scattered across many (often unrelated) files. >>> >>> Implement a new, modern and simplified timer driver and put it into >>> drivers/clocksource. We still need to support legacy board files so >>> export a config structure and a function that allows machine code to >>> register the timer. >>> >>> We don't check the return values of regmap reads and writes since with >>> mmio it's only likely to fail due to programmer's errors. >>> >>> We also don't bother freeing resources on errors in >>> davinci_timer_register() as the system won't boot without a timer anyway. >>> >>> Signed-off-by: Bartosz Golaszewski >> >> With this series, DA830 fails to boot. Rest of the devices are okay from >> boot perspective. >> >> DA830 is pretty unique because it uses the same timer-half for both >> clocksource and clockevent. May be you can set the same configuration on >> your DA850 to see the same issue? Else, I will enable low-level debug >> and try to provide more debug data. >> > > I can't boot da850 with the same config as da830 (0x60 compare > register, compare irq 74) even with the old timer code. Just to make > sure: does da830 boot fine with mainline v5.0-rc2? Yeah, I did check that without the patch DA830 does boot. Thanks, Sekhar
Re: [PATCH 2/5] staging: erofs: localize erofs_workgroup_get
On 2019/1/16 16:59, Gao Xiang wrote: > Staticize erofs_workgroup_get since no external user > out of utils.c directly calls erofs_workgroup_get. > > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,
[PATCH v4 2/4] perf record: bind the AIO user space buffers to nodes
Allocate and bind AIO user space buffers to the memory nodes
that mmap kernel buffers are bound to.
Signed-off-by: Alexey Budankov
---
Changes in v4:
- fixed compilation issue converting pr_warn() to pr_warning()
- implemented stop if mbind() fails
Changes in v3:
- corrected code style issues
- adjusted __aio_alloc,__aio_bind,__aio_free() implementation
Changes in v2:
- implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind
and put HAVE_LIBNUMA_SUPPORT #ifdefs in there
---
tools/perf/util/mmap.c | 77 +++---
1 file changed, 73 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index e68ba754a8e2..34be9f900575 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -10,6 +10,9 @@
#include
#include
#include
+#ifdef HAVE_LIBNUMA_SUPPORT
+#include
+#endif
#include "debug.h"
#include "event.h"
#include "mmap.h"
@@ -154,9 +157,72 @@ void __weak auxtrace_mmap_params__set_idx(struct
auxtrace_mmap_params *mp __mayb
}
#ifdef HAVE_AIO_SUPPORT
+
+#ifdef HAVE_LIBNUMA_SUPPORT
+static int perf_mmap__aio_alloc(struct perf_mmap *map, int index)
+{
+ map->aio.data[index] = mmap(NULL, perf_mmap__mmap_len(map),
PROT_READ|PROT_WRITE,
+ MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
+ if (map->aio.data[index] == MAP_FAILED) {
+ map->aio.data[index] = NULL;
+ return -1;
+ }
+
+ return 0;
+}
+
+static void perf_mmap__aio_free(struct perf_mmap *map, int index)
+{
+ if (map->aio.data[index]) {
+ munmap(map->aio.data[index], perf_mmap__mmap_len(map));
+ map->aio.data[index] = NULL;
+ }
+}
+
+static int perf_mmap__aio_bind(struct perf_mmap *map, int index, int cpu, int
affinity)
+{
+ void *data;
+ size_t mmap_len;
+ unsigned long node_mask;
+
+ if (affinity != PERF_AFFINITY_SYS && cpu__max_node() > 1) {
+ data = map->aio.data[index];
+ mmap_len = perf_mmap__mmap_len(map);
+ node_mask = 1UL << cpu__get_node(cpu);
+ if (mbind(data, mmap_len, MPOL_BIND, &node_mask, 1, 0)) {
+ pr_err("Failed to bind [%p-%p] AIO buffer to node %d:
error %m\n",
+ data, data + mmap_len, cpu__get_node(cpu));
+ return -1;
+ }
+ }
+
+ return 0;
+}
+#else
+static int perf_mmap__aio_alloc(struct perf_mmap *map, int index)
+{
+ map->aio.data[index] = malloc(perf_mmap__mmap_len(map));
+ if (map->aio.data[index] == NULL)
+ return -1;
+
+ return 0;
+}
+
+static void perf_mmap__aio_free(struct perf_mmap *map, int index)
+{
+ zfree(&(map->aio.data[index]));
+}
+
+static int perf_mmap__aio_bind(struct perf_mmap *map __maybe_unused, int index
__maybe_unused,
+ int cpu __maybe_unused, int affinity __maybe_unused)
+{
+ return 0;
+}
+#endif
+
static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
{
- int delta_max, i, prio;
+ int delta_max, i, prio, ret;
map->aio.nr_cblocks = mp->nr_cblocks;
if (map->aio.nr_cblocks) {
@@ -177,11 +243,14 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map,
struct mmap_params *mp)
}
delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
for (i = 0; i < map->aio.nr_cblocks; ++i) {
- map->aio.data[i] = malloc(perf_mmap__mmap_len(map));
- if (!map->aio.data[i]) {
+ ret = perf_mmap__aio_alloc(map, i);
+ if (ret == -1) {
pr_debug2("failed to allocate data buffer area,
error %m");
return -1;
}
+ ret = perf_mmap__aio_bind(map, i, map->cpu,
mp->affinity);
+ if (ret == -1)
+ return -1;
/*
* Use cblock.aio_fildes value different from -1
* to denote started aio write operation on the
@@ -210,7 +279,7 @@ static void perf_mmap__aio_munmap(struct perf_mmap *map)
int i;
for (i = 0; i < map->aio.nr_cblocks; ++i)
- zfree(&map->aio.data[i]);
+ perf_mmap__aio_free(map, i);
if (map->aio.data)
zfree(&map->aio.data);
zfree(&map->aio.cblocks);
Re: [PATCH 1/2] pwm: sifive: Add DT documentation for SiFive PWM Controller
On Wed, Jan 16, 2019 at 1:41 AM Uwe Kleine-König
wrote:
>
> Hello,
>
> this is v3, right? It is helpful to point this out to ease reviewing.
Yes, it is v3. Will take care of this in v4.
>
> On Fri, Jan 11, 2019 at 01:52:43PM +0530, Yash Shah wrote:
> > DT documentation for PWM controller added with updated compatible
> > string.
>
> Not sure what was updated here. But assuming this is compared to v2 this
> is not a helpful info in the commit log.
Ok, will remove the 'updated compatible string' part.
>
> > Signed-off-by: Wesley W. Terpstra
> > [Atish: Compatible string update]
> > Signed-off-by: Atish Patra
> > Signed-off-by: Yash Shah
> > ---
> > .../devicetree/bindings/pwm/pwm-sifive.txt | 37
> > ++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > new file mode 100644
> > index 000..e0fc22a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> > @@ -0,0 +1,37 @@
> > +SiFive PWM controller
> > +
> > +Unlike most other PWM controllers, the SiFive PWM controller currently only
> > +supports one period for all channels in the PWM. This is set globally in
> > DTS.
> > +The period also has significant restrictions on the values it can achieve,
> > +which the driver rounds to the nearest achievable frequency.
> > +
> > +Required properties:
> > +- compatible: Please refer to sifive-blocks-ip-versioning.txt
>
> While the description was too verbose in v2, this is too short. You
> should at least mention something like "sifive,pwmX" and
> "sifive,$cpuname-pwm" (or how ever that scheme works).
Will mention the above.
>
> > +- reg: physical base address and length of the controller's registers
> > +- clocks: Should contain a clock identifier for the PWM's parent clock.
> > +- #pwm-cells: Should be 2.
> > + The first cell is the PWM channel number
> > + The second cell is the PWM polarity
>
> I'd drop these two lines and refer to bindings/pwm/pwm.txt instead.
Will be done.
>
> > +- sifive,approx-period-ns: the driver will get as close to this period as
> > it can
>
> As already said for v2: I'd drop "approx-".
Sure, will be done.
>
> > +- interrupts: one interrupt per PWM channel
> > +
> > +PWM RTL that corresponds to the IP block version numbers can be found
> > +here:
> > +
> > +https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm
> > +
> > +Further information on the format of the IP
> > +block-specific version numbers can be found in
> > +Documentation/devicetree/bindings/sifive/sifive-blocks-ip-versioning.txt
> > +
> > +Examples:
> > +
> > +pwm: pwm@1002 {
> > + compatible = "sifive,fu540-c000-pwm","sifive,pwm0";
> > + reg = <0x0 0x1002 0x0 0x1000>;
> > + clocks = <&tlclk>;
> > + interrupt-parent = <&plic>;
> > + interrupts = <42 43 44 45>;
> > + #pwm-cells = <2>;
> > + sifive,approx-period-ns = <100>;
> > +};
> > --
> > 1.9.1
> >
> >
>
> --
> Pengutronix e.K. | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/ |
Thanks for the comments.
[PATCH v4 3/4] perf record: apply affinity masks when reading mmap buffers
Build node cpu masks for mmap data buffers. Apply node cpu
masks to tool thread every time it references data buffers
cross node or cross cpu.
Signed-off-by: Alexey Budankov
---
Changes in v4:
- corrected mmap_params->cpu_map initialization to be based on
/sys/devices/system/cpu/online
- separated node cpu map generation into build_node_mask()
Changes in v3:
- separated mask manipulations into __adjust_affinity() and
__setup_affinity_mask()
- implemented mapping of c index into online cpu index
Changes in v2:
- separated AIO buffers binding to patch 2/4
---
tools/perf/builtin-record.c | 14 ++
tools/perf/util/evlist.c| 6 +-
tools/perf/util/mmap.c | 23 ++-
tools/perf/util/mmap.h | 1 +
4 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index e5a108b11d46..553c2fabf3c1 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -536,6 +536,9 @@ static int record__mmap_evlist(struct record *rec,
struct record_opts *opts = &rec->opts;
char msg[512];
+ if (opts->affinity != PERF_AFFINITY_SYS)
+ cpu__setup_cpunode_map();
+
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
opts->auxtrace_snapshot_mode,
@@ -728,6 +731,16 @@ static struct perf_event_header finished_round_event = {
.type = PERF_RECORD_FINISHED_ROUND,
};
+static void record__adjust_affinity(struct record *rec, struct perf_mmap *map)
+{
+ if (rec->opts.affinity != PERF_AFFINITY_SYS &&
+ !CPU_EQUAL(&rec->affinity_mask, &map->affinity_mask)) {
+ CPU_ZERO(&rec->affinity_mask);
+ CPU_OR(&rec->affinity_mask, &rec->affinity_mask,
&map->affinity_mask);
+ sched_setaffinity(0, sizeof(rec->affinity_mask),
&rec->affinity_mask);
+ }
+}
+
static int record__mmap_read_evlist(struct record *rec, struct perf_evlist
*evlist,
bool overwrite)
{
@@ -755,6 +768,7 @@ static int record__mmap_read_evlist(struct record *rec,
struct perf_evlist *evli
struct perf_mmap *map = &maps[i];
if (map->base) {
+ record__adjust_affinity(rec, map);
if (!record__aio_enabled(rec)) {
if (perf_mmap__push(map, rec, record__pushfn)
!= 0) {
rc = -1;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 08cedb643ea6..178d3280ba62 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1032,7 +1032,11 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* Its value is decided by evsel's write_backward.
* So &mp should not be passed through const pointer.
*/
- struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
affinity };
+ struct mmap_params mp = {
+ .nr_cblocks = nr_cblocks,
+ .affinity = affinity,
+ .cpu_map= cpu_map__new(NULL) /* from
/sys/devices/system/cpu/online */
+ };
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index 34be9f900575..8ff2f1c243a2 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -383,6 +383,27 @@ void perf_mmap__munmap(struct perf_mmap *map)
auxtrace_mmap__munmap(&map->auxtrace_mmap);
}
+static void build_node_mask(const struct cpu_map *cpu_map, int node, cpu_set_t
*mask)
+{
+ int c, cpu, nr_cpus;
+
+ nr_cpus = cpu_map__nr(cpu_map);
+ for (c = 0; c < nr_cpus; c++) {
+ cpu = cpu_map->map[c]; /* map c index to online cpu index */
+ if (cpu__get_node(cpu) == node)
+ CPU_SET(cpu, mask);
+ }
+}
+
+static void perf_mmap__setup_affinity_mask(struct perf_mmap *map, struct
mmap_params *mp)
+{
+ CPU_ZERO(&map->affinity_mask);
+ if (mp->affinity == PERF_AFFINITY_NODE && cpu__max_node() > 1 &&
mp->cpu_map)
+ build_node_mask(mp->cpu_map, cpu__get_node(map->cpu),
&map->affinity_mask);
+ else if (mp->affinity == PERF_AFFINITY_CPU)
+ CPU_SET(map->cpu, &map->affinity_mask);
+}
+
int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int
cpu)
{
/*
@@ -412,7 +433,7 @@ int perf_mmap__mmap(struct perf_mmap *map, struct
mmap_params *mp, int fd, int c
map->fd = fd;
map->cpu = cpu;
- CPU_ZERO(&map->affinity_mask);
+ perf_mmap__setup_affinity_mask(map, mp);
if (auxtrace_mmap__mmap(&map->auxtrace_mmap,
&mp->auxtrace_mp, map->base, fd))
diff --git a/tools/perf/util/mmap.h b/tools/perf/util/mmap.h
index e566c19b2
[PATCH v4 4/4] perf record: implement --affinity=node|cpu option
Implement --affinity=node|cpu option for the record mode defaulting
to system affinity mask bouncing.
Signed-off-by: Alexey Budankov
---
changes in v3:
- adjusted indentation at record__parse_affinity()
---
tools/perf/Documentation/perf-record.txt | 5 +
tools/perf/builtin-record.c | 20
2 files changed, 25 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index d232b13ea713..efb839784f32 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -440,6 +440,11 @@ Use control blocks in asynchronous (Posix AIO) trace
writing mode (default:
Asynchronous mode is supported only when linking Perf tool with libc library
providing implementation for Posix AIO API.
+--affinity=mode::
+Set affinity mask of trace reading thread according to the policy defined by
'mode' value:
+ node - thread affinity mask is set to NUMA node cpu mask of the processed
mmap buffer
+ cpu - thread affinity mask is set to cpu of the processed mmap buffer
+
--all-kernel::
Configure all used events to run in kernel space.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 553c2fabf3c1..94a966ba9a6f 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1659,6 +1659,23 @@ static int parse_clockid(const struct option *opt, const
char *str, int unset)
return -1;
}
+static int record__parse_affinity(const struct option *opt, const char *str,
int unset)
+{
+ struct record_opts *opts = (struct record_opts *)opt->value;
+
+ if (unset)
+ return 0;
+
+ if (str) {
+ if (!strcasecmp(str, "node"))
+ opts->affinity = PERF_AFFINITY_NODE;
+ else if (!strcasecmp(str, "cpu"))
+ opts->affinity = PERF_AFFINITY_CPU;
+ }
+
+ return 0;
+}
+
static int record__parse_mmap_pages(const struct option *opt,
const char *str,
int unset __maybe_unused)
@@ -1966,6 +1983,9 @@ static struct option __record_options[] = {
&nr_cblocks_default, "n", "Use control blocks in
asynchronous trace writing mode (default: 1, max: 4)",
record__aio_parse),
#endif
+ OPT_CALLBACK(0, "affinity", &record.opts, "node|cpu",
+"Set affinity mask of trace reading thread to NUMA node
cpu mask or cpu of processed mmap buffer",
+record__parse_affinity),
OPT_END()
};
Re: [PATCH 4.9 00/16] 4.9.151-stable review
On 15/01/2019 16:35, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.151 release. > There are 16 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jan 17 15:48:25 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.151-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. All tests are passing for Tegra ... Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 14 tests: 14 pass, 0 fail Linux version: 4.9.151-rc1-g1f10ba8 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
[PATCH v4 1/4] perf record: allocate affinity masks
Allocate affinity option and masks for mmap data buffers and
record thread as well as initialize allocated objects.
Signed-off-by: Alexey Budankov
---
Changes in v3:
- converted PERF_AFFINITY_EOF to PERF_AFFINITY_MAX
Changes in v2:
- made debug affinity mode message user friendly
- converted affinity mode defines to enum values
---
tools/perf/builtin-record.c | 13 -
tools/perf/perf.h | 8
tools/perf/util/evlist.c| 6 +++---
tools/perf/util/evlist.h| 2 +-
tools/perf/util/mmap.c | 2 ++
tools/perf/util/mmap.h | 3 ++-
6 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 882285fb9f64..e5a108b11d46 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -81,12 +81,17 @@ struct record {
booltimestamp_boundary;
struct switch_outputswitch_output;
unsigned long long samples;
+ cpu_set_t affinity_mask;
};
static volatile int auxtrace_record__snapshot_started;
static DEFINE_TRIGGER(auxtrace_snapshot_trigger);
static DEFINE_TRIGGER(switch_output_trigger);
+static const char *affinity_tags[PERF_AFFINITY_MAX] = {
+ "SYS", "NODE", "CPU"
+};
+
static bool switch_output_signal(struct record *rec)
{
return rec->switch_output.signal &&
@@ -533,7 +538,8 @@ static int record__mmap_evlist(struct record *rec,
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode,
opts->nr_cblocks) < 0) {
+opts->auxtrace_snapshot_mode,
+opts->nr_cblocks, opts->affinity) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
"Consider increasing "
@@ -1980,6 +1986,9 @@ int cmd_record(int argc, const char **argv)
# undef REASON
#endif
+ CPU_ZERO(&rec->affinity_mask);
+ rec->opts.affinity = PERF_AFFINITY_SYS;
+
rec->evlist = perf_evlist__new();
if (rec->evlist == NULL)
return -ENOMEM;
@@ -2143,6 +2152,8 @@ int cmd_record(int argc, const char **argv)
if (verbose > 0)
pr_info("nr_cblocks: %d\n", rec->opts.nr_cblocks);
+ pr_debug("affinity: %s\n", affinity_tags[rec->opts.affinity]);
+
err = __cmd_record(&record, argc, argv);
out:
perf_evlist__delete(rec->evlist);
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 388c6dd128b8..36d5cfe6362f 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -83,6 +83,14 @@ struct record_opts {
clockid_tclockid;
u64 clockid_res_ns;
int nr_cblocks;
+ int affinity;
+};
+
+enum perf_affinity {
+ PERF_AFFINITY_SYS = 0,
+ PERF_AFFINITY_NODE,
+ PERF_AFFINITY_CPU,
+ PERF_AFFINITY_MAX
};
struct option;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 8c902276d4b4..08cedb643ea6 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1022,7 +1022,7 @@ int perf_evlist__parse_mmap_pages(const struct option
*opt, const char *str,
*/
int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks)
+bool auxtrace_overwrite, int nr_cblocks, int affinity)
{
struct perf_evsel *evsel;
const struct cpu_map *cpus = evlist->cpus;
@@ -1032,7 +1032,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
* Its value is decided by evsel's write_backward.
* So &mp should not be passed through const pointer.
*/
- struct mmap_params mp = { .nr_cblocks = nr_cblocks };
+ struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity =
affinity };
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
@@ -1064,7 +1064,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist,
unsigned int pages,
int perf_evlist__mmap(struct perf_evlist *evlist, unsigned int pages)
{
- return perf_evlist__mmap_ex(evlist, pages, 0, false, 0);
+ return perf_evlist__mmap_ex(evlist, pages, 0, false, 0,
PERF_AFFINITY_SYS);
}
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 868294491194..72728d7f4432 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -162,7 +162,7 @@ unsigned long perf_event_mlock_kb_in_pages(void);
int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr
Re: [PATCH 4.14 00/27] 4.14.94-stable review
On 15/01/2019 16:35, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.94 release. > There are 27 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jan 17 15:48:28 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.94-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.14: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 14 tests: 14 pass, 0 fail Linux version: 4.14.94-rc1-gec31b1a Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH v1] phy: qcom-ufs: Use iopoll.h readl_poll_timeout macro
Hi, On 16/01/19 2:40 PM, Marc Gonzalez wrote: > On 28/12/2018 17:05, Andy Gross wrote: > >> On Fri, Dec 21, 2018 at 11:13:18AM +0100, Marc Gonzalez wrote: >> >>> The private copy of readl_poll_timeout is no longer needed. >>> Use the implementation in iopoll.h instead. >>> >>> Signed-off-by: Marc Gonzalez >> >> Reviewed-by: Andy Gross > > Would this patch go through your tree or Kishon's tree? I've merged this in phy -next. Thanks Kishon
Re: [Spice-devel] [PATCH 1/3] drm/qxl: add mode/framebuffer check functions
>
> Add a helper functions to check video modes. Also add a helper to check
> framebuffer buffer objects, using the former for consistency. That way
> we should not fail in qxl_primary_atomic_check() because video modes
> which are too big will not be added to the mode list in the first place.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 37 +++--
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 1f8fddcc34..07a37d52c4 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -191,6 +191,21 @@ void qxl_display_read_client_monitors_config(struct
> qxl_device *qdev)
> }
> }
>
> +static int qxl_check_mode(struct qxl_device *qdev,
> + unsigned int width,
> + unsigned int height)
> +{
> + if (width * height * 4 > qdev->vram_size)
Is someone checking for integer overflows already?
> + return -ENOMEM;
> + return 0;
> +}
> +
> +static int qxl_check_framebuffer(struct qxl_device *qdev,
> + struct qxl_bo *bo)
> +{
> + return qxl_check_mode(qdev, bo->surf.width, bo->surf.height);
> +}
> +
> static int qxl_add_monitors_config_modes(struct drm_connector *connector,
> unsigned *pwidth,
> unsigned *pheight)
> @@ -466,12 +481,7 @@ static int qxl_primary_atomic_check(struct drm_plane
> *plane,
>
> bo = gem_to_qxl_bo(state->fb->obj[0]);
>
> - if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
> - DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
> - return -EINVAL;
> - }
> -
> - return 0;
> + return qxl_check_framebuffer(qdev, bo);
> }
>
> static int qxl_primary_apply_cursor(struct drm_plane *plane)
> @@ -941,20 +951,11 @@ static enum drm_mode_status qxl_conn_mode_valid(struct
> drm_connector *connector,
> {
> struct drm_device *ddev = connector->dev;
> struct qxl_device *qdev = ddev->dev_private;
> - int i;
>
> - /* TODO: is this called for user defined modes? (xrandr --add-mode)
> - * TODO: check that the mode fits in the framebuffer */
> + if (qxl_check_mode(qdev, mode->hdisplay, mode->vdisplay) != 0)
> + return MODE_BAD;
>
> - if (qdev->monitors_config_width == mode->hdisplay &&
> - qdev->monitors_config_height == mode->vdisplay)
> - return MODE_OK;
> -
> - for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
> - if (common_modes[i].w == mode->hdisplay && common_modes[i].h ==
> mode->vdisplay)
> - return MODE_OK;
> - }
> - return MODE_BAD;
> + return MODE_OK;
> }
>
> static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
Frediano
Re: [PATCH] genirq/affinity: Assign default affinity to pre/post vectors
Chen, On Wed, 16 Jan 2019, 陈华才 wrote: please do not top-post and use line breaks around 78 char. > I'm not removing all return NULL of irq_create_affinity_masks(), so the .. Moved content to the place where it belongs so the context is preserved. > -- Original -- > From: "Thomas Gleixner"; > Date: Wed, Jan 16, 2019 03:10 AM > To: "Huacai Chen"; > Cc: "linux-kernel"; "Fuxin > Zhang"; "wuzhangjin"; > "stable"; "Christoph Hellwig"; "Michael > Hernandez"; > Subject: Re: [PATCH] genirq/affinity: Assign default affinity to pre/post > vectors And please configure your e-mail client to NOT copy the full headers into the reply. > > On Mon, 31 Dec 2018, Huacai Chen wrote: > > > > > Generally, irq_create_affinity_masks() assign default affinity to pre/ > > > post vectors correctly. However, it ignore the case that there are only > > > pre/post vectors (when nvecs == affd->pre_vectors + affd->post_vectors) > > > and return NULL. This case usually happens when nvecs = 1 (e.g. in nvme > > > driver when MSI-X is unavailable and fallback to MSI) and will trigger > > > the warning in pci_irq_get_affinity(). This patch fix the corner case. > > > > Errm. This is just wrong. When this function returns NULL, then it has > > failed and the caller or any subsequent code is not supposed to use the > > result. > > > > The function can return NULL for other reasons, e.g. when the memory > > allocation failed. How are you going to duct tape that one? > > I'm not removing all return NULL of irq_create_affinity_masks(), so the > memory allocation failure still return NULL. I just handle the case that > there are not enough irq vectors. E.g. in nvme driver, the caller may call > irq_create_affinity_masks() with nvecs=1,pre_vectors=1,post_vectors=0. In > this case, the only one vector's default affinity assigning is skipped. I did not say that you removed all NULL returns. I said that this function can return NULL for other reasons and then the same situation will happen. If the masks pointer returned is NULL then the calling code or any subsequent usage needs to handle it properly. Yes, I understand that this change makes the warning go away for that particular case, but that's not making it any more correct. Thanks, tglx
RE: [PATCH] arm64: dts: imx: Fix MU4_INT number
> From: Daniel Baluta > Sent: Wednesday, January 16, 2019 1:05 AM > Subject: [PATCH] arm64: dts: imx: Fix MU4_INT number > > MU4_INT correct number is 180, while 179 is for MU3_INT. > > Signed-off-by: Daniel Baluta Reviewed-by: Dong Aisheng Regards Dong Aisheng
Re: [PATCH 3/5] staging: erofs: decrease the shrink count in erofs_workgroup_get
On 2019/1/16 16:59, Gao Xiang wrote: > It is more suitable to update in erofs_workgroup_get since > it's actually the one matched with erofs_workgroup_put. > > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,
Re: [PATCH 4/5] staging: erofs: staticize erofs_shrink_count, erofs_shrink_scan
On 2019/1/16 16:59, Gao Xiang wrote: > Move erofs_shrinker_info to utils.c and therefore > no need to globalize erofs_shrink_count and erofs_shrink_scan. > > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,
Re: [PATCH 5/5] staging: erofs: drop the extern prefix for function definitions
On 2019/1/16 16:59, Gao Xiang wrote: > Fix all `CHECK: extern prototypes should be avoided in .h files' > reported by checkpatch.pl. > > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,
[PATCH 1/2] gpio: pca953x: reduce indentation level in pca953x_irq_setup()
The current design of pca953x_irq_setup() is:
if (all conditions to support IRQ are met) {
lots of code to support IRQs, which goes to a serious indentation
level.
}
return 0;
It makes more sense to handle this like this:
if (!all conditions to support IRQ are met)
return 0;
handle IRQ support
This commit does just this change, reducing by one tab the indentation
level of the IRQ setup code. Thanks to this reduced indentation level,
we are less restricted by the 80-column limit, and we can have more
function arguments on the same line.
Signed-off-by: Thomas Petazzoni
---
drivers/gpio/gpio-pca953x.c | 84 ++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 0dc96419efe3..4f91ce497dd1 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -702,53 +702,53 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
int reg_direction[MAX_BANK];
int ret, i;
- if (client->irq && irq_base != -1
- && (chip->driver_data & PCA_INT)) {
- ret = pca953x_read_regs(chip,
- chip->regs->input, chip->irq_stat);
- if (ret)
- return ret;
+ if (!client->irq)
+ return 0;
- /*
-* There is no way to know which GPIO line generated the
-* interrupt. We have to rely on the previous read for
-* this purpose.
-*/
- regmap_bulk_read(chip->regmap, chip->regs->direction,
-reg_direction, NBANK(chip));
- for (i = 0; i < NBANK(chip); i++)
- chip->irq_stat[i] &= reg_direction[i];
- mutex_init(&chip->irq_lock);
-
- ret = devm_request_threaded_irq(&client->dev,
- client->irq,
- NULL,
- pca953x_irq_handler,
- IRQF_TRIGGER_LOW | IRQF_ONESHOT |
- IRQF_SHARED,
- dev_name(&client->dev), chip);
- if (ret) {
- dev_err(&client->dev, "failed to request irq %d\n",
- client->irq);
- return ret;
- }
+ if (irq_base == -1)
+ return 0;
- ret = gpiochip_irqchip_add_nested(&chip->gpio_chip,
- &pca953x_irq_chip,
- irq_base,
- handle_simple_irq,
- IRQ_TYPE_NONE);
- if (ret) {
- dev_err(&client->dev,
- "could not connect irqchip to gpiochip\n");
- return ret;
- }
+ if (!(chip->driver_data & PCA_INT))
+ return 0;
- gpiochip_set_nested_irqchip(&chip->gpio_chip,
- &pca953x_irq_chip,
- client->irq);
+ ret = pca953x_read_regs(chip, chip->regs->input, chip->irq_stat);
+ if (ret)
+ return ret;
+
+ /*
+* There is no way to know which GPIO line generated the
+* interrupt. We have to rely on the previous read for
+* this purpose.
+*/
+ regmap_bulk_read(chip->regmap, chip->regs->direction, reg_direction,
+NBANK(chip));
+ for (i = 0; i < NBANK(chip); i++)
+ chip->irq_stat[i] &= reg_direction[i];
+ mutex_init(&chip->irq_lock);
+
+ ret = devm_request_threaded_irq(&client->dev, client->irq,
+ NULL, pca953x_irq_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT |
+ IRQF_SHARED,
+ dev_name(&client->dev), chip);
+ if (ret) {
+ dev_err(&client->dev, "failed to request irq %d\n",
+ client->irq);
+ return ret;
+ }
+
+ ret = gpiochip_irqchip_add_nested(&chip->gpio_chip, &pca953x_irq_chip,
+ irq_base, handle_simple_irq,
+ IRQ_TYPE_NONE);
+ if (ret) {
+ dev_err(&client->dev,
+ "could not connect irqchip to gpiochip\n");
+ return ret;
}
+ gpiochip_set_nested_irqchip(&chip->gpio_chip, &pca953x_irq_chip,
+ client->irq);
+
return 0;
}
--
2.20.1
[PATCH 2/2] gpio: pca953x: use a per instance irq_chip structure
When a system has two PCA953x GPIO expanders, the kernel complains with:
gpio gpiochip2: (0-0021): detected irqchip that is shared with multiple
gpiochips: please fix the driver.
Indeed, there is a single instance of "struct irq_chip" that gets
re-used for both PCA953x instance. This commit moves the "struct
irq_chip" to be part of the "struct pca953x_chip", so that we have one
"struct irq_chip" per PCA953X instance.
As part of this, the name of the irq_chip is also made different on a
per-instance basis, now using the dev_name() of the I2C device. This
changes what is visible in /proc/interrupts.
Before:
47: 0 0 pca953x 10 Edge e010.sdhci cd
48: 0 0 pca953x 6 Edge e0101000.sdhci cd
After:
47: 0 00-0020 10 Edge e010.sdhci cd
48: 2 00-0020 6 Edge e0101000.sdhci cd
Signed-off-by: Thomas Petazzoni
---
drivers/gpio/gpio-pca953x.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 4f91ce497dd1..de52f63863db 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -150,6 +150,7 @@ struct pca953x_chip {
u8 irq_stat[MAX_BANK];
u8 irq_trig_raise[MAX_BANK];
u8 irq_trig_fall[MAX_BANK];
+ struct irq_chip irq_chip;
#endif
struct i2c_client *client;
@@ -594,16 +595,6 @@ static void pca953x_irq_shutdown(struct irq_data *d)
chip->irq_trig_fall[d->hwirq / BANK_SZ] &= ~mask;
}
-static struct irq_chip pca953x_irq_chip = {
- .name = "pca953x",
- .irq_mask = pca953x_irq_mask,
- .irq_unmask = pca953x_irq_unmask,
- .irq_bus_lock = pca953x_irq_bus_lock,
- .irq_bus_sync_unlock= pca953x_irq_bus_sync_unlock,
- .irq_set_type = pca953x_irq_set_type,
- .irq_shutdown = pca953x_irq_shutdown,
-};
-
static bool pca953x_irq_pending(struct pca953x_chip *chip, u8 *pending)
{
u8 cur_stat[MAX_BANK];
@@ -699,6 +690,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
int irq_base)
{
struct i2c_client *client = chip->client;
+ struct irq_chip *irq_chip = &chip->irq_chip;
int reg_direction[MAX_BANK];
int ret, i;
@@ -737,7 +729,15 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
return ret;
}
- ret = gpiochip_irqchip_add_nested(&chip->gpio_chip, &pca953x_irq_chip,
+ irq_chip->name = dev_name(&chip->client->dev);
+ irq_chip->irq_mask = pca953x_irq_mask;
+ irq_chip->irq_unmask = pca953x_irq_unmask;
+ irq_chip->irq_bus_lock = pca953x_irq_bus_lock;
+ irq_chip->irq_bus_sync_unlock = pca953x_irq_bus_sync_unlock;
+ irq_chip->irq_set_type = pca953x_irq_set_type;
+ irq_chip->irq_shutdown = pca953x_irq_shutdown;
+
+ ret = gpiochip_irqchip_add_nested(&chip->gpio_chip, irq_chip,
irq_base, handle_simple_irq,
IRQ_TYPE_NONE);
if (ret) {
@@ -746,8 +746,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
return ret;
}
- gpiochip_set_nested_irqchip(&chip->gpio_chip, &pca953x_irq_chip,
- client->irq);
+ gpiochip_set_nested_irqchip(&chip->gpio_chip, irq_chip, client->irq);
return 0;
}
--
2.20.1
Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions
On 15/01/2019 20:33, Gerald Schaefer wrote:
On Tue, 15 Jan 2019 18:37:30 +0100
Pierre Morel wrote:
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_dma as
reserved regions using the appropriate callback in iommu_ops.
Signed-off-by: Pierre Morel
---
drivers/iommu/s390-iommu.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
index 22d4db3..5ca91a1 100644
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c
@@ -363,6 +363,33 @@ void zpci_destroy_iommu(struct zpci_dev *zdev)
iommu_device_sysfs_remove(&zdev->iommu_dev);
}
+static void s390_get_resv_regions(struct device *dev, struct list_head *head)
+{
+ struct iommu_resv_region *region;
+ struct zpci_dev *zdev = to_pci_dev(dev)->sysdata;
+
+ region = iommu_alloc_resv_region(0, zdev->start_dma,
+0, IOMMU_RESV_RESERVED);
+ if (!region)
+ return;
+ list_add_tail(®ion->list, head);
+
+ region = iommu_alloc_resv_region(zdev->end_dma + 1,
+~0UL - zdev->end_dma,
+0, IOMMU_RESV_RESERVED);
Can you guarantee that start_dma will never be 0 and end_dma never ~0UL,
even with future HW?
In any of these cases, your code would reserve strange ranges, and sysfs
would report broken reserved ranges.
Maybe add a check for start_dma > 0 and end_dma < ULONG_MAX?
Yes, thanks.
+ if (!region)
+ return;
+ list_add_tail(®ion->list, head);
+}
+
+static void s390_put_resv_regions(struct device *dev, struct list_head *head)
+{
+ struct iommu_resv_region *entry, *next;
+
+ list_for_each_entry_safe(entry, next, head, list)
+ kfree(entry);
+}
It looks very wrong that there is no matching list_del() for the previous
list_add_tail(). However, it seems to be done like this everywhere else,
and the calling functions (currently) only use temporary list_heads as
far as I can see, so I guess it should be OK (for now).
Still, a list_del() would be nice :-)
hum.
right.
+
static const struct iommu_ops s390_iommu_ops = {
.capable = s390_iommu_capable,
.domain_alloc = s390_domain_alloc,
@@ -376,6 +403,8 @@ static const struct iommu_ops s390_iommu_ops = {
.remove_device = s390_iommu_remove_device,
.device_group = generic_device_group,
.pgsize_bitmap = S390_IOMMU_PGSIZES,
+ .get_resv_regions = s390_get_resv_regions,
+ .put_resv_regions = s390_put_resv_regions,
};
static int __init s390_iommu_init(void)
With the start/end_dma issue addressed (if necessary):
Acked-by: Gerald Schaefer
Thanks.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
[PATCH] clk: mmp2: avoid disabling the SP clock when unused
There could be vital functionality running on the SP PJ1 core it can not be
restarted just by turning the clock back on.
On the OLPC laptop, the keyboard controller code runs there. It
wouldn't be possible to load the driver for it as a module if the clock
is disabled on boot.
Cc: sta...@vger.kernel.org # v4.18+
Fixes: commit fc27c2394d96 ("clk: mmp2: add SP clock")
Signed-off-by: Lubomir Rintel
---
drivers/clk/mmp/clk-of-mmp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/clk-of-mmp2.c b/drivers/clk/mmp/clk-of-mmp2.c
index f2a1c9bbaa63..3e33f1295f59 100644
--- a/drivers/clk/mmp/clk-of-mmp2.c
+++ b/drivers/clk/mmp/clk-of-mmp2.c
@@ -246,7 +246,7 @@ static struct mmp_param_gate_clk apmu_gate_clks[] = {
{MMP2_CLK_CCIC1, "ccic1_clk", "ccic1_mix_clk", CLK_SET_RATE_PARENT,
APMU_CCIC1, 0x1b, 0x1b, 0x0, 0, &ccic1_lock},
{MMP2_CLK_CCIC1_PHY, "ccic1_phy_clk", "ccic1_mix_clk",
CLK_SET_RATE_PARENT, APMU_CCIC1, 0x24, 0x24, 0x0, 0, &ccic1_lock},
{MMP2_CLK_CCIC1_SPHY, "ccic1_sphy_clk", "ccic1_sphy_div",
CLK_SET_RATE_PARENT, APMU_CCIC1, 0x300, 0x300, 0x0, 0, &ccic1_lock},
- {MMP2_CLK_SP, "sp_clk", NULL, CLK_SET_RATE_PARENT, APMU_SP, 0x1b, 0x1b,
0x0, 0, &sp_lock},
+ {MMP2_CLK_SP, "sp_clk", NULL, CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
APMU_SP, 0x1b, 0x1b, 0x0, 0, &sp_lock},
};
static void mmp2_axi_periph_clk_init(struct mmp2_clk_unit *pxa_unit)
--
2.20.1
Re: [PATCH v7 4/4] Bluetooth: btqca: inject command complete event during fw download
On 2019-01-15 06:50, Matthias Kaehlcke wrote:
On Mon, Jan 14, 2019 at 09:21:25PM +0530, Balakrishna Godavarthi wrote:
On 2019-01-12 04:42, Matthias Kaehlcke wrote:
> On Fri, Jan 11, 2019 at 07:53:43PM +0530, Balakrishna Godavarthi wrote:
> > Hi Matthias,
> >
> > On 2019-01-11 02:13, Matthias Kaehlcke wrote:
> > > Hi Balakrishna,
> > >
> > > On Thu, Jan 10, 2019 at 08:30:43PM +0530, Balakrishna Godavarthi wrote:
> > > > Hi Matthias,
> > > >
> > > > On 2019-01-03 03:45, Matthias Kaehlcke wrote:
> > > > > On Mon, Dec 31, 2018 at 11:34:46AM +0530, Balakrishna Godavarthi
wrote:
> > > > > > Hi Marcel,
> > > > > >
> > > > > > On 2018-12-30 13:40, Marcel Holtmann wrote:
> > > > > > > Hi Balakrishna,
> > > > > > >
> > > > > > > > > > Latest qualcomm chips are not sending an command complete
event for
> > > > > > > > > > every firmware packet sent to chip. They only respond with
a vendor
> > > > > > > > > > specific event for the last firmware packet. This
optimization will
> > > > > > > > > > decrease the BT ON time. Due to this we are seeing a
timeout error
> > > > > > > > > > message logs on the console during firmware download. Now
we are
> > > > > > > > > > injecting a command complete event once we receive an vendor
> > > > > > > > > > specific
> > > > > > > > > > event for the last RAM firmware packet.
> > > > > > > > > > Signed-off-by: Balakrishna Godavarthi
> > > > > > > > > > ---
> > > > > > > > > > drivers/bluetooth/btqca.c | 39
> > > > > > > > > > ++-
> > > > > > > > > > drivers/bluetooth/btqca.h | 3 +++
> > > > > > > > > > 2 files changed, 41 insertions(+), 1 deletion(-)
> > > > > > > > > > diff --git a/drivers/bluetooth/btqca.c
b/drivers/bluetooth/btqca.c
> > > > > > > > > > index ec9e03a6b778..0b533f65f652 100644
> > > > > > > > > > --- a/drivers/bluetooth/btqca.c
> > > > > > > > > > +++ b/drivers/bluetooth/btqca.c
> > > > > > > > > > @@ -144,6 +144,7 @@ static void qca_tlv_check_data(struct
> > > > > > > > > > rome_config *config,
> > > > > > > > > >* In case VSE is skipped, only the last
segment is acked.
> > > > > > > > > >*/
> > > > > > > > > > config->dnld_mode = tlv_patch->download_mode;
> > > > > > > > > > + config->dnld_type = config->dnld_mode;
> > > > > > > > > > BT_DBG("Total Length : %d bytes",
> > > > > > > > > > le32_to_cpu(tlv_patch->total_size));
> > > > > > > > > > @@ -264,6 +265,31 @@ static int qca_tlv_send_segment(struct
> > > > > > > > > > hci_dev *hdev, int seg_size,
> > > > > > > > > > return err;
> > > > > > > > > > }
> > > > > > > > > > +static int qca_inject_cmd_complete_event(struct hci_dev
*hdev)
> > > > > > > > > > +{
> > > > > > > > > > + struct hci_event_hdr *hdr;
> > > > > > > > > > + struct hci_ev_cmd_complete *evt;
> > > > > > > > > > + struct sk_buff *skb;
> > > > > > > > > > +
> > > > > > > > > > + skb = bt_skb_alloc(sizeof(*hdr) + sizeof(*evt) + 1,
GFP_KERNEL);
> > > > > > > > > > + if (!skb)
> > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > +
> > > > > > > > > > + hdr = skb_put(skb, sizeof(*hdr));
> > > > > > > > > > + hdr->evt = HCI_EV_CMD_COMPLETE;
> > > > > > > > > > + hdr->plen = sizeof(*evt) + 1;
> > > > > > > > > > +
> > > > > > > > > > + evt = skb_put(skb, sizeof(*evt));
> > > > > > > > > > + evt->ncmd = 1;
> > > > > > > > > > + evt->opcode = HCI_OP_NOP;
> > > > >
> > > > > After looking a bit more at it I realize HCI_OP_NOP is not a good
> > > > > value in this case:
> > > > >
> > > > > static void hci_cmd_complete_evt(...)
> > > > > {
> > > > > ...
> > > > >
> > > > > if (*opcode != HCI_OP_NOP)
> > > > > cancel_delayed_work(&hdev->cmd_timer);
> > > > >
> > > > > ...
> > > > > }
> > > > >
> > > > >
https://elixir.bootlin.com/linux/v4.19/source/net/bluetooth/hci_event.c#L3351
> > > > >
> > > > > Cancelling the command timeout is precisely what we want. Not sure why
> > > > > the patch with HCI_OP_NOP makes the timeouts go away in most cases
> > > > > (but not e.g. when inserting an msleep(1000) after downloading the
> > > > > NVM.
> > > > >
> > > > > I suggest to pass the opcode of the command to be completed.
> > > > >
> > > > > > > > > > +
> > > > > > > > > > + skb_put_u8(skb, QCA_HCI_CC_SUCCESS);
> > > > > > > > > > +
> > > > > > > > > > + hci_skb_pkt_type(skb) = HCI_EVENT_PKT;
> > > > > > > > > > +
> > > > > > > > > > + return hci_recv_frame(hdev, skb);
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > static int qca_download_firmware(struct hci_dev *hdev,
> > > > > > > > > > struct rome_config *config)
> > > > > > > > > > {
> > > > > > > > > > @@ -297,11 +323,22 @@ static int
> > > > > > > > > > qca_download_firmware(struct hci_dev *hdev,
> > > > > > > > > > ret = qca_tlv_send_segment(hdev, segsize,
segment,
> > > > > > > > > >
Re: [PATCH] PCI: fix using __initdata memory after free in disable_acs_redir parameter
Hi
On 1/15/19 7:32 PM, Logan Gunthorpe wrote:
The disable_acs_redir parameter stores a pointer to the string passed to
pci_setup(). However, the string passed to PCI setup is actually a
temporary copy allocated in static __initdata memory. After init, once
the memory is freed, it is no longer valid to reference this pointer.
This bug was noticed in v5.0-rc1 after a change in commit c5eb1190074c
("PCI / PM: Allow runtime PM without callback functions") caused
pci_disable_acs_redir() to be called during shutdown which manifested
as an unable to handle kernel paging request at:
RIP: 0010:pci_enable_acs+0x3f/0x1e0
Call Trace:
pci_restore_state.part.44+0x159/0x3c0
pci_restore_standard_config+0x33/0x40
pci_pm_runtime_resume+0x2b/0xd0
? pci_restore_standard_config+0x40/0x40
__rpm_callback+0xbc/0x1b0
rpm_callback+0x1f/0x70
? pci_restore_standard_config+0x40/0x40
rpm_resume+0x4f9/0x710
? pci_conf1_read+0xb6/0xf0
? pci_conf1_write+0xb2/0xe0
__pm_runtime_resume+0x47/0x70
pci_device_shutdown+0x1e/0x60
So this doesn't happen if you revert c5eb1190074c?
I guess this is due dev->state_saved being true set by
pci_pm_runtime_suspend() -> pci_save_state() after my patch and now
pci_pm_runtime_resume() -> pci_restore_standard_config() ->
pci_restore_state() reach the pci_enable_acs(). I think this is possible
to trigger also before my patch if device has the runtime PM callback
defined?
It was also likely possible to trigger this bug when hotplugging PCI
devices.
To fix this, instead of storing a pointer, we use kstrdup to copy the
disable_acs_redir_param to its own buffer which will never be freed.
I wasn't able to trigger this but I saw
"PCI: Can't parse disable_acs_redir parameter: " followed by a few lines
of junk during boot when I defined pci=disable_acs_redir=:00:xy.z
which disappear after your patch.
Tested-by: Jarkko Nikula
Reviewed-by: Jarkko Nikula
Re: [PATCH v2 4/4] usb: musb: Add support for MediaTek musb controller
Hi Bin, On Tue, 2019-01-15 at 14:38 -0600, Bin Liu wrote: > Hi Min, > > very close, thanks. > Below I tried to explain a further cleanup in musb_clearb/w() and > musb_get/set_toggle() implementation. Please let me know if it is not > clear. > > Basically, we don't need musb_default_clearb/w(), just assign the > musb_io function pointers to musb_readb/w(). > > Then the mtk platform musb_clearb/w() calls musb_readb/w() and > musb_writeb/w() to handle W1C. Sorry to bother you again, I encounter a problem when prepare the patch. The define of musb_clearb/w and musb_readb/w are difference as follow, and cannot be directly assigned: u8/u16 (*readb/w)(const void __iomem *addr, unsigned offset) void (*clearb/w)(void __iomem *addr, unsigned int offset)) if modify clearb/w as: u8/u16 (*clearb/w)(const void __iomem *addr, unsigned int offset)) then musb_clear needs writeb/w the const addr. Can I delete const in (*readb/w)? > regards, > -Bin.
[PATCH v3] arm64: defconfig: Add i.MX8MQ boot necessary configs
Enable all the i.MX8MQ configs necessary to boot. Cc: Catalin Marinas Cc: Will Deacon Cc: Shawn Guo Cc: Sascha Hauer Cc: Fabio Estevam Signed-off-by: Abel Vesa --- Changes since v2: * run savedefconfig to order the newly added configs arch/arm64/configs/defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 032912e..6e5af25 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -323,6 +323,8 @@ CONFIG_SERIAL_MESON_CONSOLE=y CONFIG_SERIAL_SAMSUNG=y CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_TEGRA=y +CONFIG_SERIAL_IMX=y +CONFIG_SERIAL_IMX_CONSOLE=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_MSM=y CONFIG_SERIAL_MSM_CONSOLE=y @@ -371,6 +373,7 @@ CONFIG_SPI_SPIDEV=m CONFIG_SPMI=y CONFIG_PINCTRL_SINGLE=y CONFIG_PINCTRL_MAX77620=y +CONFIG_PINCTRL_IMX8MQ=y CONFIG_PINCTRL_IMX8QXP=y CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_MSM8916=y @@ -628,6 +631,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y CONFIG_COMMON_CLK_S2MPS11=y CONFIG_CLK_QORIQ=y CONFIG_COMMON_CLK_PWM=y +CONFIG_CLK_IMX8MQ=y CONFIG_CLK_IMX8QXP=y CONFIG_TI_SCI_CLK=y CONFIG_COMMON_CLK_QCOM=y @@ -661,6 +665,7 @@ CONFIG_RPMSG_QCOM_GLINK_RPM=y CONFIG_RPMSG_QCOM_GLINK_SMEM=m CONFIG_RPMSG_QCOM_SMD=y CONFIG_RASPBERRYPI_POWER=y +CONFIG_IMX_GPCV2_PM_DOMAINS=y CONFIG_QCOM_COMMAND_DB=y CONFIG_QCOM_GENI_SE=y CONFIG_QCOM_GLINK_SSR=m -- 2.7.4
Re: [PATCH 06/25] mm, compaction: Skip pageblocks with reserved pages
On Tue, Jan 15, 2019 at 12:50:45PM +, Mel Gorman wrote: > > AFAICS memory allocator is not the only user of PageReserved. There > > seems to be some drivers as well, notably the DRM subsystem via > > drm_pci_alloc(). There's an effort to clean those up [1] but until then, > > there might be some false positives here. > > > > [1] https://marc.info/?l=linux-mm&m=154747078617898&w=2 > > > > Hmm, I'm tempted to leave this anyway. The reservations for PCI space are > likely to be persistent and I also do not expect them to grow much. While > I consider it to be partially abuse to use PageReserved like this, it > should get cleaned up slowly over time. If this turns out to be wrong, > I'll attempt to fix the responsible driver that is scattering > PageReserved around the place and at worst, revert this if it turns out > to be a major problem in practice. Any objections? > I decided to drop this anyway as the series does not hinge on it, it's a relatively minor improvement overall and I don't want to halt the entire series over it. The maintain that the system would recover even if the driver released the pages as the check would eventually fail and then be cleared after a reset. The only downside from the patch that I can see really is that it's a small maintenance overhead due to an apparent duplicated check. The CPU overhead of compaction will be slightly higher due to the revert but there are other options on the horizon that would bring down that overhead again. -- Mel Gorman SUSE Labs
[PATCH v8 0/3] sched/fair: update scale invariance of PELT
This new version of the scale invariance patchset adds an important change compare to v3 and before. It still scales the time to reflect the amount of work that has been done during the elapsed running time but this is now done at rq level instead of per entity and rt/dl/cfs_rq. The main advantage is that it is done once per clock update and we don't need to maintain per sched_avg's stolen_idle_time anymore. This also ensures that all pelt signals will be always synced for a rq. Changes since v7: - Add patch 3 to skip updating util_est when utilization is higher than cpu's capacity Vincent Guittot (3): sched/fair: move rq_of helper function sched/fair: update scale invariance of PELT sched/pelt: skip updating util_est when utilization is higher than cpu's capacity include/linux/sched.h | 23 +++--- kernel/sched/core.c | 1 + kernel/sched/deadline.c | 6 +-- kernel/sched/fair.c | 72 ++- kernel/sched/pelt.c | 45 +++- kernel/sched/pelt.h | 111 ++-- kernel/sched/rt.c | 6 +-- kernel/sched/sched.h| 28 +++- 8 files changed, 206 insertions(+), 86 deletions(-) -- 2.7.4
[PATCH v8 1/3] sched/fair: move rq_of helper function
Move rq_of() helper function so it can be used in pelt.c
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 13 -
kernel/sched/sched.h | 16
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ca46964..63b9151 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -248,13 +248,6 @@ const struct sched_class fair_sched_class;
*/
#ifdef CONFIG_FAIR_GROUP_SCHED
-
-/* cpu runqueue to which this cfs_rq is attached */
-static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
-{
- return cfs_rq->rq;
-}
-
static inline struct task_struct *task_of(struct sched_entity *se)
{
SCHED_WARN_ON(!entity_is_task(se));
@@ -411,12 +404,6 @@ static inline struct task_struct *task_of(struct
sched_entity *se)
return container_of(se, struct task_struct, se);
}
-static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
-{
- return container_of(cfs_rq, struct rq, cfs);
-}
-
-
#define for_each_sched_entity(se) \
for (; se; se = NULL)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 0ba0892..fd1bad2 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -951,6 +951,22 @@ struct rq {
#endif
};
+#ifdef CONFIG_FAIR_GROUP_SCHED
+
+/* cpu runqueue to which this cfs_rq is attached */
+static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
+{
+ return cfs_rq->rq;
+}
+
+#else /* !CONFIG_FAIR_GROUP_SCHED */
+
+static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
+{
+ return container_of(cfs_rq, struct rq, cfs);
+}
+#endif
+
static inline int cpu_of(struct rq *rq)
{
#ifdef CONFIG_SMP
--
2.7.4
[PATCH v8 3/3] sched/pelt: skip updating util_est when utilization is higher than cpu's capacity
util_est is mainly meant to be a lower-bound for tasks utilization.
That's why task_util_est() returns the actual util_avg when it's higher
than the estimated utilization.
With new invaraince signal and without any special check on samples
collection, if a task is limited because of thermal capping for
example, we could end up overestimating its utilization and thus
perhaps generating an unwanted frequency spike when the capping is
relaxed... and (even worst) it will take some more activations for the
estimated utilization to converge back to the actual utilization.
Since we cannot easily know if there is idle time in a CPU when a task
completes an activation with a utilization higher then the CPU capacity,
we skip the sampling when utilization is higher than cpu's capacity.
Suggested-by: Patrick Bellasi
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 14 +-
kernel/sched/sched.h | 7 +++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9332863..2262c8a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3639,6 +3639,7 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct
task_struct *p, bool task_sleep)
{
long last_ewma_diff;
struct util_est ue;
+ int cpu;
if (!sched_feat(UTIL_EST))
return;
@@ -3673,6 +3674,14 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct
task_struct *p, bool task_sleep)
return;
/*
+* To avoid overestimation of actual task utilization, skip updates if
+* we cannot grant there is idle time in this CPU.
+*/
+ cpu = cpu_of(rq_of(cfs_rq));
+ if (task_util(p) > capacity_orig_of(cpu))
+ return;
+
+ /*
* Update Task's estimated utilization
*
* When *p completes an activation we can consolidate another sample
@@ -5541,11 +5550,6 @@ static unsigned long capacity_of(int cpu)
return cpu_rq(cpu)->cpu_capacity;
}
-static unsigned long capacity_orig_of(int cpu)
-{
- return cpu_rq(cpu)->cpu_capacity_orig;
-}
-
static unsigned long cpu_avg_load_per_task(int cpu)
{
struct rq *rq = cpu_rq(cpu);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4c506ea..455745e 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2230,6 +2230,13 @@ static inline void cpufreq_update_util(struct rq *rq,
unsigned int flags) {}
# define arch_scale_freq_invariant() false
#endif
+#ifdef CONFIG_SMP
+static inline unsigned long capacity_orig_of(int cpu)
+{
+ return cpu_rq(cpu)->cpu_capacity_orig;
+}
+#endif
+
#ifdef CONFIG_CPU_FREQ_GOV_SCHEDUTIL
/**
* enum schedutil_type - CPU utilization type
--
2.7.4
[PATCH] mm: hwpoison: use do_send_sig_info() instead of force_sig() (Re: PMEM error-handling forces SIGKILL causes kernel panic)
[ CCed Andrew and linux-mm ]
On Fri, Jan 11, 2019 at 08:14:02AM +, Horiguchi Naoya(堀口 直也) wrote:
> Hi Dan, Jane,
>
> Thanks for the report.
>
> On Wed, Jan 09, 2019 at 03:49:32PM -0800, Dan Williams wrote:
> > [ switch to text mail, add lkml and Naoya ]
> >
> > On Wed, Jan 9, 2019 at 12:19 PM Jane Chu wrote:
> ...
> > > 3. The hardware consists the latest revision CPU and Intel NVDIMM, we
> > > suspected
> > >the CPU faulty because it generated MCE over PMEM UE in a unlikely high
> > >rate for any reasonable NVDIMM (like a few per 24hours).
> > >
> > > After swapping the CPU, the problem stopped reproducing.
> > >
> > > But one could argue that perhaps the faulty CPU exposed a small race
> > > window
> > > from collect_procs() to unmap_mapping_range() and to kill_procs(), hence
> > > caught the kernel PMEM error handler off guard.
> >
> > There's definitely a race, and the implementation is buggy as can be
> > seen in __exit_signal:
> >
> > sighand = rcu_dereference_check(tsk->sighand,
> > lockdep_tasklist_lock_is_held());
> > spin_lock(&sighand->siglock);
> >
> > ...the memory-failure path needs to hold the proper locks before it
> > can assume that de-referencing tsk->sighand is valid.
> >
> > > Also note, the same workload on the same faulty CPU were run on Linux
> > > prior to
> > > the 4.19 PMEM error handling and did not encounter kernel crash, probably
> > > because
> > > the prior HWPOISON handler did not force SIGKILL?
> >
> > Before 4.19 this test should result in a machine-check reboot, not
> > much better than a kernel crash.
> >
> > > Should we not to force the SIGKILL, or find a way to close the race
> > > window?
> >
> > The race should be closed by holding the proper tasklist and rcu read
> > lock(s).
>
> This reasoning and proposal sound right to me. I'm trying to reproduce
> this race (for non-pmem case,) but no luck for now. I'll investigate more.
I wrote/tested a patch for this issue.
I think that switching signal API effectively does proper locking.
Thanks,
Naoya Horiguchi
---
>From 16dbf6105ff4831f73276d79d5df238ab467de76 Mon Sep 17 00:00:00 2001
From: Naoya Horiguchi
Date: Wed, 16 Jan 2019 16:59:27 +0900
Subject: [PATCH] mm: hwpoison: use do_send_sig_info() instead of force_sig()
Currently memory_failure() is racy against process's exiting,
which results in kernel crash by null pointer dereference.
The root cause is that memory_failure() uses force_sig() to forcibly
kill asynchronous (meaning not in the current context) processes. As
discussed in thread https://lkml.org/lkml/2010/6/8/236 years ago for
OOM fixes, this is not a right thing to do. OOM solves this issue by
using do_send_sig_info() as done in commit d2d393099de2 ("signal:
oom_kill_task: use SEND_SIG_FORCED instead of force_sig()"), so this
patch is suggesting to do the same for hwpoison. do_send_sig_info()
properly accesses to siglock with lock_task_sighand(), so is free from
the reported race.
I confirmed that the reported bug reproduces with inserting some delay
in kill_procs(), and it never reproduces with this patch.
Note that memory_failure() can send another type of signal using
force_sig_mceerr(), and the reported race shouldn't happen on it
because force_sig_mceerr() is called only for synchronous processes
(i.e. BUS_MCEERR_AR happens only when some process accesses to the
corrupted memory.)
Reported-by: Jane Chu
Cc: Dan Williams
Cc: sta...@vger.kernel.org
Signed-off-by: Naoya Horiguchi
---
mm/memory-failure.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 7c72f2a95785..831be5ff5f4d 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -372,7 +372,8 @@ static void kill_procs(struct list_head *to_kill, int
forcekill, bool fail,
if (fail || tk->addr_valid == 0) {
pr_err("Memory failure: %#lx: forcibly killing
%s:%d because of failure to unmap corrupted page\n",
pfn, tk->tsk->comm, tk->tsk->pid);
- force_sig(SIGKILL, tk->tsk);
+ do_send_sig_info(SIGKILL, SEND_SIG_PRIV,
+tk->tsk, PIDTYPE_PID);
}
/*
--
2.7.5
Re: question about head_64.S
On 1/15/19 11:55 PM, Thomas Gleixner wrote:
> On Tue, 15 Jan 2019, Cao jin wrote:
>
>> Hi,
>> I have been digging into this file for a while, and I still have 2
>> questions unclear, hope to get your help.
>>
>> 1.
>> At the entry of startup_64, we set all the data segment registers to 0,
>> according to commit 08da5a2ca("x86_64: Early segment setup for VT"), it
>> is said to accelerate the decompression under VT. I don't know Intel VT,
>> but I did test under physical machine and virtual machine(with KVM, and
>> intel VT enabled in BIOS) with following patch:
>>
>> diff --git a/arch/x86/boot/compressed/head_64.S
>> b/arch/x86/boot/compressed/head_64.S
>> index 58f6a467f1fa..595f3c300173 100644
>> --- a/arch/x86/boot/compressed/head_64.S
>> +++ b/arch/x86/boot/compressed/head_64.S
>> @@ -260,12 +260,12 @@ ENTRY(startup_64)
>> */
>>
>> /* Setup data segments. */
>> - xorl%eax, %eax
>> - movl%eax, %ds
>> - movl%eax, %es
>> - movl%eax, %ss
>> - movl%eax, %fs
>> - movl%eax, %gs
>> +// xorl%eax, %eax
>> +// movl%eax, %ds
>> +// movl%eax, %es
>> +// movl%eax, %ss
>> +// movl%eax, %fs
>> +// movl%eax, %gs
>>
>> I don't see any obvious booting time difference, is there anything I missed?
>> Also, I don't find explicit document saying we should zero these
>> registers under VT.
>
> The decompressor is position independent code, so all segments have to be
> set to 0.
>
Thank you Thomas! But I've never heard that PIC is correlated with
segment register value, could you elaborate a little bit? Because as I
know, startup_64 is in long mode, and CPU will treat all segment(except
fs, gs) base as 0, no matter whatever in them. And until now, I only see
fs is touched when parsing command line, not see any explicit gs usage.
On the other hand, I test the patch above, it can boot up, so seems
segment register value here is not necessary to be 0?
> The patch you mentioned was just adding fs/gs to the list of segments
> which are cleared and the commit message is not very clear. Though if you
> dig further down then you find the original version of that patch:
>
> commit ffb6017563aa("[PATCH] x86-64: x86_64 - Fix FS/GS registers for VT
> execution")
>
> That one has a proper explantaion.
>
Oh, I still not reach to the real kernel itself yet. At first glance,
"but it is important to reload them in protected mode" make sense to me.
But more confusion rise up: under 64-bit boot protocol, we can have more
than one entry? startup_64 in both:
arch/x86/kernel/head_64.S
and
arch/x86/boot/compressed/head_64.S
can be jumped to via bootloader? Seems Documentation/x86/boot.txt
doesn't say that.
--
Sincerely,
Cao jin
[PATCH v8 2/3] sched/fair: update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/secondsops/seconds diff
cgroup
root59652(+/- 0.18%) 59876(+/- 0.24%)+0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%)+0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%)+0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec)diff
cgroup
root4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%)138ms not reachable276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%)13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot
---
include/linux/sched.h | 23 +++---
kernel/sched/core.c | 1 +
kernel/sched/deadline.c | 6 +--
kernel/sched/fair.c | 45 +++-
kernel/sched/pelt.c | 45 +++-
kernel/sched/pelt.h | 111 ++--
kernel/sched/rt.c | 6 +--
kernel/sched/sched.h| 5 ++-
8 files changed, 174 insertions(+), 68 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b8c7ba0..fbea56f 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -356,12 +356,6 @@ struct util_est {
* For cfs_rq, it is the aggregated load_avg of all runnable and
* blocked sched_entities.
*
- * load_avg may also take frequency scaling into account:
- *
- * load_avg = runnable% * scale_load_down(load) * freq%
- *
- * where freq% is the CPU frequency norm
Re: [PATCH] arm64: dts: sdm845: add video nodes
Hi Alex,
On 11/27/18 10:24 AM, Stanimir Varbanov wrote:
> Hi Alex,
>
> On 11/27/18 9:31 AM, Alexandre Courbot wrote:
>> On Tue, Nov 20, 2018 at 7:08 PM Malathi Gottam
>> wrote:
>>>
>>> This adds video nodes to sdm845 based on the examples
>>> in the bindings.
>>>
>>> Signed-off-by: Malathi Gottam
>>> ---
>>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 34
>>> ++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> index 0c9a2aa..d82487d 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -84,6 +84,10 @@
>>> reg = <0 0x8620 0 0x2d0>;
>>> no-map;
>>> };
>>> + venus_region: venus@9580 {
>>> + reg = <0x0 0x9580 0x0 0x50>;
>>
>> Note that the driver expects a size of 0x60 here and will fail to
>> probe if this is smaller.
>>
>
> I have to send a patch to fix that size mismatch as we discussed that it
> the other mail thread.
>
I sent the size mismatch patch here:
https://patchwork.kernel.org/patch/10753645/
--
regards,
Stan
[PATCH] Input: olpc_apsp - assign priv->dev earlier
The dev field needs to be set when serio_register_port() is called,
because the open callback may use it (in the error handling path).
Cc: sta...@vger.kernel.org # v4.18+
Fixes: commit af518342effd ("Input: olpc_apsp - check FIFO status on open(),
not probe()")
Signed-off-by: Lubomir Rintel
---
drivers/input/serio/olpc_apsp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
index 0aece9777087..554f4b8228d2 100644
--- a/drivers/input/serio/olpc_apsp.c
+++ b/drivers/input/serio/olpc_apsp.c
@@ -198,6 +198,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
+ priv->dev = &pdev->dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(priv->base)) {
@@ -261,7 +263,6 @@ static int olpc_apsp_probe(struct platform_device *pdev)
goto err_irq;
}
- priv->dev = &pdev->dev;
device_init_wakeup(priv->dev, 1);
platform_set_drvdata(pdev, priv);
--
2.20.1
Re: [PATCH v3 1/5] misc: dt-bindings: Add Qualcomm Fastrpc bindings
Thanks for the review!
On 15/01/2019 20:22, Rob Herring wrote:
On Mon, Jan 14, 2019 at 07:41:08PM +, Srinivas Kandagatla wrote:
The FastRPC driver implements an IPC (Inter-Processor Communication)
mechanism that allows for clients to transparently make remote method
invocations across DSP and APPS boundaries. This enables developers
to offload tasks to the DSP and free up the application processor for
other tasks.
Co-developed-by: Thierry Escande
Signed-off-by: Thierry Escande
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/misc/qcom,fastrpc.txt | 84 +++
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
new file mode 100644
index ..004e636b4133
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
@@ -0,0 +1,84 @@
+Qualcomm Technologies, Inc. FastRPC Driver
+
+The FastRPC driver implements an IPC (Inter-Processor Communication)
driver or this is a h/w block?
This is a software/firmware block in Hexagon DSP.
+mechanism that allows for clients to transparently make remote method
+invocations across DSP and APPS boundaries. This enables developers
+to offload tasks to the DSP and free up the application processor for
+other tasks.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,fastrpc"
+
+- label
+ Usage: required
+ Value type:
+ Definition: should specify the dsp domain name this fastrpc
+ corresponds to. must be one of this: "adsp", "mdsp", "sdsp", "cdsp"
+
+- #address-cells
+ Usage: required
+ Value type:
+ Definition: Must be 1
+
+- #size-cells
+ Usage: required
+ Value type:
+ Definition: Must be 0
+
+= COMPUTE BANKS
+Each subnode of the Fastrpc node represents compute context banks available
+on the dsp. The name of the nodes are not important. The properties of these
Please specify what the node names are.
Sure, these are compute context banks, will reword this accordingly.
+nodes are defined by the individual bindings for the specific service
+- All Compute context banks MUST contain the following property:
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,fastrpc-compute-cb"
+
+- reg
+ Usage: required
+ Value type:
+ Definition: Context Bank ID.
+
+- secured:
+ Usage: Optional
+ Value type:
+ Defination: Indicating context bank is secured
What does 'secured' mean here?
secured in TZ sense, this context requires secure buffers to work with.
+
+- nsessions:
+ Usage: Optional
+ Value type:
+ Defination: A value indicating how many sessions can share this
+ context bank. Defaults to 1 when this property
+ is not specified.
Needs a vendor prefix.
Sure, will do that in next version!
+
+Example:
+
+adsp-pil {
+ compatible = "qcom,msm8996-adsp-pil";
+ ...
+ smd-edge {
+ label = "lpass";
+ fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,smd-channels = "fastrpcsmd-apps-dsp";
+ lable = "adsp";
typo.
Thanks for spotting this.. will fix this!
--srini
Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote: > I didn't see a way to reuse things in that patch series, situation is > different, in that patch it needs to get RSDP in very early boot stage > so it did everything from scratch, in this patch kexec_file_load need > to get RSDP too, but everything is well setup so things are a lot > easier, just read from current boot_prams, efi and fallback to > acpi_find_root_pointer should be good. No no. Early code should find out that venerable RSDP thing once and will save it somewhere for further use. No gazillion parsings of it. Just once and share it with the rest of the code that needs it. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 09/25] mm, compaction: Use the page allocator bulk-free helper for lists of pages
On Tue, Jan 15, 2019 at 01:39:28PM +0100, Vlastimil Babka wrote:
> On 1/4/19 1:49 PM, Mel Gorman wrote:
> > release_pages() is a simpler version of free_unref_page_list() but it
> > tracks the highest PFN for caching the restart point of the compaction
> > free scanner. This patch optionally tracks the highest PFN in the core
> > helper and converts compaction to use it. The performance impact is
> > limited but it should reduce lock contention slightly in some cases.
> > The main benefit is removing some partially duplicated code.
> >
> > Signed-off-by: Mel Gorman
>
> ...
>
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2876,18 +2876,26 @@ void free_unref_page(struct page *page)
> > /*
> > * Free a list of 0-order pages
> > */
> > -void free_unref_page_list(struct list_head *list)
> > +void __free_page_list(struct list_head *list, bool dropref,
> > + unsigned long *highest_pfn)
> > {
> > struct page *page, *next;
> > unsigned long flags, pfn;
> > int batch_count = 0;
> >
> > + if (highest_pfn)
> > + *highest_pfn = 0;
> > +
> > /* Prepare pages for freeing */
> > list_for_each_entry_safe(page, next, list, lru) {
> > + if (dropref)
> > + WARN_ON_ONCE(!put_page_testzero(page));
>
> I've thought about it again and still think it can cause spurious
> warnings. We enter this function with one page pin, which means somebody
> else might be doing pfn scanning and get_page_unless_zero() with
> success, so there are two pins. Then we do the put_page_testzero() above
> and go back to one pin, and warn. You said "this function simply does
> not expect it and the callers do not violate the rule", but this is
> rather about potential parallel pfn scanning activity and not about this
> function's callers. Maybe there really is no parallel pfn scanner that
> would try to pin a page with a state the page has when it's processed by
> this function, but I wouldn't bet on it (any state checks preceding the
> pin might also be racy etc.).
>
Ok, I'll drop this patch because in theory you're right. I wouldn't think
that parallel PFN scanning is likely to trigger it but gup is a potential
issue. While this also will increase CPU usage slightly again, it'll be
no worse than it was before and again, I don't want to stall the entire
series over a relatively small optimisation.
Thanks Vlastimil!
--
Mel Gorman
SUSE Labs
[PATCH] tracing/uprobes: Fix output for multiple string arguments
When printing multiple uprobe arguments as strings the output for the
earlier arguments would also include all later string arguments.
This is best explained in an example:
Consider adding a uprobe to a function receiving two strings as
parameters which is at offset 0xa0 in strlib.so and we want to print
both parameters when the uprobe is hit (on x86_64):
$ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
/sys/kernel/debug/tracing/uprobe_events
When the function is called as func("foo", "bar") and we hit the probe,
the trace file shows a line like the following:
[...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
Note the extra "bar" printed as part of arg1. This behaviour stacks up
for additional string arguments.
The strings are stored in a dynamically growing part of the uprobe
buffer by fetch_store_string() after copying them from userspace via
strncpy_from_user(). The return value of strncpy_from_user() is then
directly used as the required size for the string. However, this does
not take the terminating null byte into account as the documentation
for strncpy_from_user() cleary states that it "[...] returns the
length of the string (not including the trailing NUL)" even though the
null byte will be copied to the destination.
Therefore, subsequent calls to fetch_store_string() will overwrite
the terminating null byte of the most recently fetched string with
the first character of the current string, leading to the
"accumulation" of strings in earlier arguments in the output.
Fix this by incrementing the return value of strncpy_from_user() by
one if we did not hit the maximum buffer size.
Signed-off-by: Andreas Ziegler
---
kernel/trace/trace_uprobe.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e335576b9411..dfb9bbc7fd82 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -160,6 +160,13 @@ fetch_store_string(unsigned long addr, void *dest, void
*base)
if (ret >= 0) {
if (ret == maxlen)
dst[ret - 1] = '\0';
+ else if (ret > 0)
+ /*
+* Include the terminating null byte. In this case it
+* was copied by strncpy_from_user but not accounted
+* for in ret.
+*/
+ ret++;
*(u32 *)dest = make_data_loc(ret, (void *)dst - base);
}
--
2.17.1
[PATCH] net: phy: mdio_bus: add missing device_del() in mdiobus_register() error handling
The current code in __mdiobus_register() doesn't properly handle
failures returned by the devm_gpiod_get_optional() call: it returns
immediately, without unregistering the device that was added by the
call to device_register() earlier in the function.
This leaves a stale device, which then causes a NULL pointer
dereference in the code that handles deferred probing:
[1.489982] Unable to handle kernel NULL pointer dereference at virtual
address 0074
[1.498110] pgd = (ptrval)
[1.500838] [0074] *pgd=
[1.504432] Internal error: Oops: 17 [#1] SMP ARM
[1.509133] Modules linked in:
[1.512192] CPU: 1 PID: 51 Comm: kworker/1:3 Not tainted
4.20.0-00039-g3b73a4cc8b3e-dirty #99
[1.520708] Hardware name: Xilinx Zynq Platform
[1.525261] Workqueue: events deferred_probe_work_func
[1.530403] PC is at klist_next+0x10/0xfc
[1.534403] LR is at device_for_each_child+0x40/0x94
[1.539361] pc : []lr : []psr: 200e0013
[1.545628] sp : ceeefe68 ip : 0001 fp : e000
[1.550863] r10: r9 : c0c66790 r8 :
[1.556079] r7 : c0457d44 r6 : r5 : ceeefe8c r4 : cfa2ec78
[1.562604] r3 : 0064 r2 : c0457d44 r1 : ceeefe8c r0 : 0064
[1.569129] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[1.576263] Control: 18c5387d Table: 0ed7804a DAC: 0051
[1.582013] Process kworker/1:3 (pid: 51, stack limit = 0x(ptrval))
[1.588280] Stack: (0xceeefe68 to 0xceef)
[1.592630] fe60: cfa2ec78 c0c03c08 c0457d44
c0c66790
[1.600814] fe80: c0455d90 ceeefeac 0064 0d7a542e
cee9d494 cfa2ec78
[1.608998] fea0: cfa2ec78 c0457d44 c0457d7c cee9d494 c0c03c08
c0455dac
[1.617182] fec0: cf98ba44 cf926a00 cee9d494 0d7a542e cf935a10
cf935a10 cf935a10
[1.625366] fee0: c0c4e9b8 c0457d7c c0c4e80c 0001 cf935a10 c0457df4
cf935a10 c0c4e99c
[1.633550] ff00: c0c4e99c c045a27c c0c4e9c4 ced63f80 cfde8a80 cfdebc00
c013893c
[1.641734] ff20: cfde8a80 cfde8a80 c07bd354 ced63f80 ced63f94 cfde8a80
0008 c0c02d00
[1.649936] ff40: cfde8a98 cfde8a80 e000 c0139a30 e000 c0c6624a
c07bd354
[1.658120] ff60: e000 cee9e780 ceebfe00 c000 ced63f80
c0139788 cf8cdea4
[1.666304] ff80: cee9e79c c013e598 0001 ceebfe00 c013e44c
[1.674488] ffa0: c01010e8
[1.682671] ffc0:
[1.690855] ffe0: 0013
[1.699058] [] (klist_next) from []
(device_for_each_child+0x40/0x94)
[1.707241] [] (device_for_each_child) from []
(device_reorder_to_tail+0x38/0x88)
[1.716476] [] (device_reorder_to_tail) from []
(device_for_each_child+0x5c/0x94)
[1.725692] [] (device_for_each_child) from []
(device_reorder_to_tail+0x38/0x88)
[1.734927] [] (device_reorder_to_tail) from []
(device_pm_move_to_tail+0x28/0x40)
[1.744235] [] (device_pm_move_to_tail) from []
(deferred_probe_work_func+0x58/0x8c)
[1.753746] [] (deferred_probe_work_func) from []
(process_one_work+0x210/0x4fc)
[1.762888] [] (process_one_work) from []
(worker_thread+0x2a8/0x5c0)
[1.771072] [] (worker_thread) from []
(kthread+0x14c/0x154)
[1.778482] [] (kthread) from []
(ret_from_fork+0x14/0x2c)
[1.785689] Exception stack(0xceeeffb0 to 0xceeefff8)
[1.790739] ffa0:
[1.798923] ffc0:
[1.807107] ffe0: 0013
[1.813724] Code: e92d47f0 e1a05000 e8900048 e1a3 (e5937010)
[1.819844] ---[ end trace 3c2c0c8b65399ec9 ]---
The actual error that we had from devm_gpiod_get_optional() was
-EPROBE_DEFER, due to the GPIO being provided by a driver that is
probed later than the Ethernet controller driver.
To fix this, we simply add the missing device_del() invocation in the
error path.
Fixes: 69226896ad636 ("mdio_bus: Issue GPIO RESET to PHYs")
Signed-off-by: Thomas Petazzoni
---
drivers/net/phy/mdio_bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 2e59a8419b17..66b9cfe692fc 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -390,6 +390,7 @@ int __mdiobus_register(struct mii_bus *bus, struct module
*owner)
if (IS_ERR(gpiod)) {
dev_err(&bus->dev, "mii_bus %s couldn't get reset GPIO\n",
bus->id);
+ device_del(&bus->dev);
return PTR_ERR(gpiod);
} else if (gpiod) {
bus->reset_gpiod = gpiod;
--
2.20.1
[PATCH 0/8] ARM: at91/dt: update to existing drivers for the sam9x60 SoC
Hi, This serries collects some little modifications to DT bindings and associated drivers changes for supporting the upcoming SAM9X60 SoC. I took the advantage of this series for fixing some of the leftovers in DT bindings for reset controller and Ethernet macb. These changes touch several sub-systems but I would like that these (mostly trivial) patches stay together for facilitating reviews, prevent breaking dependencies and facilitating the tracking of acceptance status. However, tell me if you think otherwise. My intentions are that the series would enter Mainline through arm-soc tree: sounds okay to everyone? If okay, I'm ready to collect Ack tags... For the first batch, I send the whole series to everyone. I'll try my best to reduce subsequent message deliveries if one part of the serries needs rework. Best regards, Nicolas Nicolas Ferre (8): dt-bindings: arm: atmel: add missing samx7 to reset controller dt-bindings: arm: atmel: add new sam9x60 reset controller binding dt-bindings: arm: atmel: add new sam9x60 SFR binding net/macb: bindings doc/trivial: fix documentation for sama5d3 10/100 interface net/macb: bindings doc: add sam9x60 binding power: reset: at91-reset: add support for sam9x60 SoC USB: host: ohci-at91: add sam9x60-sfr definition for ohci net: macb: add sam9x60-macb compatibility string .../devicetree/bindings/arm/atmel-sysregs.txt | 4 +++- Documentation/devicetree/bindings/net/macb.txt | 4 ++-- drivers/net/ethernet/cadence/macb_main.c| 1 + drivers/power/reset/at91-reset.c| 13 + drivers/usb/host/ohci-at91.c| 7 +-- 5 files changed, 24 insertions(+), 5 deletions(-) -- 2.17.1
[PATCH 5/8] net/macb: bindings doc: add sam9x60 binding
Add the compatibility sting documentation for sam9x60 10/100 interface.
Signed-off-by: Nicolas Ferre
---
Documentation/devicetree/bindings/net/macb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index f5c414b10e27..174f292d8a3e 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be "cdns,[-]{macb|gem}"
Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
+ Use "cdns,sam9x60-macb" for Microchip sam9x60 SoC.
Use "cdns,np4-macb" for NP4 SoC devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form:
"cdns,macb".
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
--
2.17.1
Re: [PATCH v6] arm64: implement ftrace with regs
Hi Torsten, On 04/01/2019 14:10, Torsten Duwe wrote: > Use -fpatchable-function-entry (gcc8) to add 2 NOPs at the beginning > of each function. Replace the first NOP thus generated with a quick LR > saver (move it to scratch reg x9), so the 2nd replacement insn, the call > to ftrace, does not clobber the value. Ftrace will then generate the > standard stack frames. > > Note that patchable-function-entry in GCC disables IPA-RA, which means > ABI register calling conventions are obeyed *and* scratch registers > such as x9 are available. > > Introduce and handle an ftrace_regs_trampoline for module PLTs, right > after ftrace_trampoline, and double the size of this special section. > > Signed-off-by: Torsten Duwe > I wanted to test this patch (and try to benchmark having the "mov x9, x30" always present in function prelude vs having two nops), but I cannot get this patch to apply (despite having a version including both commits below). Could you provide a git branch from which I could try to rebase the patch? (Or a new version of the series) > --- > > This patch applies on 4.20 with the additional changes > bdb85cd1d20669dfae813555dddb745ad09323ba > (arm64/module: switch to ADRP/ADD sequences for PLT entries) > and > 7dc48bf96aa0fc8aa5b38cc3e5c36ac03171e680 > (arm64: ftrace: always pass instrumented pc in x0) > along with their respective series, or alternatively on Linus' master, > which already has these. > > changes since v5: > > * fix mentioned pc in x0 to hold the start address of the call site, > not the return address or the branch address. > This resolves the problem found by Amit. > > --- > arch/arm64/Kconfig|2 > arch/arm64/Makefile |4 + > arch/arm64/include/asm/assembler.h|1 > arch/arm64/include/asm/ftrace.h | 13 +++ > arch/arm64/include/asm/module.h |3 > arch/arm64/kernel/Makefile|6 - > arch/arm64/kernel/entry-ftrace.S | 131 > ++ > arch/arm64/kernel/ftrace.c| 125 > arch/arm64/kernel/module-plts.c |3 > arch/arm64/kernel/module.c|2 > drivers/firmware/efi/libstub/Makefile |3 > include/asm-generic/vmlinux.lds.h |1 > include/linux/compiler_types.h|4 + > 13 files changed, 262 insertions(+), 36 deletions(-) [...] > --- a/arch/arm64/kernel/entry-ftrace.S > +++ b/arch/arm64/kernel/entry-ftrace.S [...] > @@ -122,6 +124,7 @@ skip_ftrace_call: // } > ENDPROC(_mcount) > > #else /* CONFIG_DYNAMIC_FTRACE */ > +#ifndef CONFIG_DYNAMIC_FTRACE_WITH_REGS > /* > * _mcount() is used to build the kernel with -pg option, but all the branch > * instructions to _mcount() are replaced to NOP initially at kernel start > up, > @@ -159,6 +162,124 @@ GLOBAL(ftrace_graph_call) // ftrace_gra > > mcount_exit > ENDPROC(ftrace_caller) > +#else /* CONFIG_DYNAMIC_FTRACE_WITH_REGS */ > + > +/* > + * Since no -pg or similar compiler flag is used, there should really be > + * no reference to _mcount; so do not define one. Only some value for > + * MCOUNT_ADDR is needed for comparison. Let it point here to have some > + * sort of magic value that can be recognised when debugging. > + */ > +GLOBAL(_mcount) > + ret /* make it differ from regs caller */ There's something I can't figure out. Since there are no callers to _mcount, how does the ftrace core builds up its record of patchable functions? I don't understand fully the core ftrace code but I've got the impression that without this record of struct dyn_ftrace, ftrace cannot patch in calls to tracers in the future. Am I missing something? Thanks, -- Julien Thierry
[PATCH 8/8] net: macb: add sam9x60-macb compatibility string
Add a new compatibility string for this product. It's using
at91sam9260-macb layout but has a newer hardware revision: it's safer
to use its own string.
Signed-off-by: Nicolas Ferre
---
drivers/net/ethernet/cadence/macb_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 66cc7927061a..a0889ef107a1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3941,6 +3941,7 @@ static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,np4-macb", .data = &np4_config },
{ .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
{ .compatible = "cdns,gem", .data = &pc302gem_config },
+ { .compatible = "cdns,sam9x60-macb", .data = &at91sam9260_config },
{ .compatible = "atmel,sama5d2-gem", .data = &sama5d2_config },
{ .compatible = "atmel,sama5d3-gem", .data = &sama5d3_config },
{ .compatible = "atmel,sama5d3-macb", .data = &sama5d3macb_config },
--
2.17.1
[PATCH 4/8] net/macb: bindings doc/trivial: fix documentation for sama5d3 10/100 interface
This removes a line left while adding the correct compatibility string for
sama5d3 10/100 interface. Now use the "atmel,sama5d3-macb" string.
Signed-off-by: Nicolas Ferre
---
Documentation/devicetree/bindings/net/macb.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index 3e17ac1d5d58..f5c414b10e27 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -3,8 +3,7 @@
Required properties:
- compatible: Should be "cdns,[-]{macb|gem}"
Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
- Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
- available on sama5d3 SoCs.
+ Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
Use "cdns,np4-macb" for NP4 SoC devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form:
"cdns,macb".
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
--
2.17.1
[PATCH 2/8] dt-bindings: arm: atmel: add new sam9x60 reset controller binding
Update the Reset Controller's binding to add new SoC compatibility string. Signed-off-by: Nicolas Ferre --- Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 36952cc39993..badce6ef3ab3 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -22,6 +22,7 @@ Its subnodes can be: RSTC Reset Controller required properties: - compatible: Should be "atmel,-rstc". can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7" + it also can be "microchip,sam9x60-rstc" - reg: Should contain registers location and length - clocks: phandle to input clock. -- 2.17.1
[PATCH 7/8] USB: host: ohci-at91: add sam9x60-sfr definition for ohci
Add this SFR compatible definition for the sam9x60 SoC and manage
its use in ohci-at91.c driver.
Signed-off-by: Nicolas Ferre
---
drivers/usb/host/ohci-at91.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index ec6739ef3129..fc35a7993b7b 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -141,8 +141,11 @@ static struct regmap *at91_dt_syscon_sfr(void)
struct regmap *regmap;
regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
- if (IS_ERR(regmap))
- regmap = NULL;
+ if (IS_ERR(regmap)) {
+ regmap =
syscon_regmap_lookup_by_compatible("microchip,sam9x60-sfr");
+ if (IS_ERR(regmap))
+ regmap = NULL;
+ }
return regmap;
}
--
2.17.1
[PATCH 6/8] power: reset: at91-reset: add support for sam9x60 SoC
Add support for additional reset causes and the proper compatibility
string for sam9x60 SoC. The restart function is the same as the samx7.
Signed-off-by: Nicolas Ferre
---
drivers/power/reset/at91-reset.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
index f44a9ffcc2ab..44ca983a49a1 100644
--- a/drivers/power/reset/at91-reset.c
+++ b/drivers/power/reset/at91-reset.c
@@ -44,6 +44,9 @@ enum reset_type {
RESET_TYPE_WATCHDOG = 2,
RESET_TYPE_SOFTWARE = 3,
RESET_TYPE_USER = 4,
+ RESET_TYPE_CPU_FAIL = 6,
+ RESET_TYPE_XTAL_FAIL= 7,
+ RESET_TYPE_ULP2 = 8,
};
static void __iomem *at91_ramc_base[2], *at91_rstc_base;
@@ -164,6 +167,15 @@ static void __init at91_reset_status(struct
platform_device *pdev)
case RESET_TYPE_USER:
reason = "user reset";
break;
+ case RESET_TYPE_CPU_FAIL:
+ reason = "CPU clock failure detection";
+ break;
+ case RESET_TYPE_XTAL_FAIL:
+ reason = "32.768 kHz crystal failure detection";
+ break;
+ case RESET_TYPE_ULP2:
+ reason = "ULP2 reset";
+ break;
default:
reason = "unknown reset";
break;
@@ -183,6 +195,7 @@ static const struct of_device_id at91_reset_of_match[] = {
{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
{ .compatible = "atmel,sama5d3-rstc", .data = sama5d3_restart },
{ .compatible = "atmel,samx7-rstc", .data = samx7_restart },
+ { .compatible = "microchip,sam9x60-rstc", .data = samx7_restart },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, at91_reset_of_match);
--
2.17.1
[PATCH 3/8] dt-bindings: arm: atmel: add new sam9x60 SFR binding
Add this SFR compatible definition for the sam9x60 SoC. Will be needed
in OHCI driver: ohci-at91.c.
Signed-off-by: Nicolas Ferre
---
Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index badce6ef3ab3..dfc91bc02b97 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -148,6 +148,7 @@ required properties:
- compatible: Should be "atmel,-sfr", "syscon" or
"atmel,-sfrbu", "syscon"
can be "sama5d3", "sama5d4" or "sama5d2".
+ it also can be "microchip,sam9x60-sfr", "syscon".
- reg: Should contain registers location and length
sfr@f0038000 {
--
2.17.1
[PATCH 1/8] dt-bindings: arm: atmel: add missing samx7 to reset controller
Add this missing compatibility string to the Reset Controller compatible string chip list. Signed-off-by: Nicolas Ferre --- Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 14f319f694b7..36952cc39993 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -21,7 +21,7 @@ Its subnodes can be: RSTC Reset Controller required properties: - compatible: Should be "atmel,-rstc". - can be "at91sam9260" or "at91sam9g45" or "sama5d3" + can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7" - reg: Should contain registers location and length - clocks: phandle to input clock. -- 2.17.1
Re: uprobes: bug in comm/string output?
On Tue, 15 Jan 2019 14:36:48 +0100
Andreas Ziegler wrote:
> Hi again,
>
> On 1/14/19 1:38 PM, Andreas Ziegler wrote:
> > Hi,
> >
> > I've been playing around with uprobes today and found the following weird
> > behaviour/output when using more than one string argument (or using the
> > $comm argument). This was run on a v4.20 mainline build on Ubuntu 18.04.
> >
> > root@ubuntu1810:~# uname -a
> > Linux ubuntu1810 4.20.0-042000-generic #201812232030 SMP Mon Dec 24
> > 01:32:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >
> > I'm trying to track calls to dlopen so I'm looking up the correct offset in
> > libdl.so:
> >
> > root@ubuntu1810:/sys/kernel/debug/tracing# readelf -s
> > /lib/x86_64-linux-gnu/libdl-2.28.so | grep dlopen
> > 34: 12a0 133 FUNCGLOBAL DEFAULT 14
> > dlopen@@GLIBC_2.2.5
> >
> > Then I'm creating a uprobe with two prints of $comm and two prints of the
> > first argument to dlopen, and enable that probe. The '/root/test' program
> > only does a dlopen("libc.so.6", RTLD_LAZY) in main().
> >
> > root@ubuntu1810:/sys/kernel/debug/tracing# echo 'p:dlopen
> > /lib/x86_64-linux-gnu/libdl-2.28.so:0x12a0 $comm $comm +0(%di):string
> > +0(%di):string' > uprobe_events
> > root@ubuntu1810:/sys/kernel/debug/tracing# echo 1 >
> > events/uprobes/dlopen/enable
> > root@ubuntu1810:/sys/kernel/debug/tracing# /root/test
> >
> > The trace output looks like this:
> >
> > root@ubuntu1810:/sys/kernel/debug/tracing# cat trace
> > # tracer: nop
> > #
> > # _-=> irqs-off
> > # / _=> need-resched
> > #| / _---=> hardirq/softirq
> > #|| / _--=> preempt-depth
> > #||| / delay
> > # TASK-PID CPU# TIMESTAMP FUNCTION
> > # | | | | |
> > test-1617 [000] d... 1237.959168: dlopen: (0x7fbd5272e2a0)
> > arg1=(fault) arg2=(fault) arg3="libc.so.6libc.so.6" arg4="libc.so.6"
> >
> > That's very weird for two reasons:
> > - fetching $comm seems to fail with an invalid pointer
> > - arg3 contains the text twice (if I add another print of the argument,
> > arg3 will contain the wanted string three times, arg4 two times and the
> > last argument will contain it once).
>
> at least for the second problem I think I found the answer, and for the
> first problem I have a suspicion (see last paragraph for that).
OK, this looks broken. Thank you very much for reporting it!
BTW, I tried to reproduce it with kprobe event, but it seems working well. e.g.
# echo 'p ksys_chdir $comm $comm +0(%di):string +0(%di):string' >
kprobe_events
# echo 1 > events/kprobes/enable
# cd /sys/kernel/debug/tracing
# cat trace
sh-812 [003] ...1 229.344360: p_ksys_chdir_0:
(ksys_chdir+0x0/0xc0) arg1="sh" arg2="sh" arg3="/sys/kernel/debug/tracing"
arg4="/sys/kernel/debug/tracing"
So, it might be an issue on uprobe_event.
>
> For this, I installed a uprobe for libdl.so/dlopen once again, the
> command would be
>
> 'p:dlopen /lib/x86_64-linux-gnu/libdl-2.28.so:0x12a0 $comm $comm'
>
> so it should print the process name twice (using a kernel v4.18 on
> Ubuntu 18.10).
>
> The code which prints the collected data (print_type_string, defined by
> PRINT_TYPE_FUNC_NAME(string) in kernel/trace/trace_probe.c) is the
> following, it simply passes the respective data to trace_seq_printf with
> a "%s" format string:
>
> int PRINT_TYPE_FUNC_NAME(string)(struct trace_seq *s, void *data, void *ent)
> {
> int len = *(u32 *)data >> 16;
>
> if (!len)
> trace_seq_puts(s, "(fault)");
> else
> trace_seq_printf(s, "\"%s\"",
> (const char *)get_loc_data(data, ent));
> return !trace_seq_has_overflowed(s);
> }
>
> I dug into that function with KGDB and found the following: 'data' holds
> the size and offset for the member in question, which is 0xf and 0x18,
> respectively. 'ent' holds the base address for event. When we print the
> string at ent + 0x18, we can see that the output for 'arg1' will be
> "update-notifierupdate-notifier"
>
> Thread 511 hit Breakpoint 6, print_type_string (s=0x880078fd1090,
> name=0x880078fe4458 "arg1", data=0x88007d01f05c,
> ent=0x88007d01f04c) at
> /build/linux-EsXT4r/linux-4.18.0/kernel/trace/trace_probe.c:67
> 67in /build/linux-EsXT4r/linux-4.18.0/kernel/trace/trace_probe.c
> gdb$ p *(uint32_t *) data
> $46 = 0xf0018
> gdb$ p ent
> $47 = (void *) 0x88007d01f04c
> gdb$ p ((char *)ent + 0x18)
> $48 = 0x88007d01f064 "update-notifierupdate-notifier"
>
> Moving on printing 'arg2' (e.g., the other $comm string). Here we see
> that the string in question is at offset 0x27, and if we print that, we
> see the correct "update-notifier".
>
> Thread 511 hit Breakpoint 6, print_type_string (s=0x880078fd1090
RE: [PATCH 1/3] arm64: dts: add dpaa2-console node for DPAA2 platforms
> Subject: Re: [PATCH 1/3] arm64: dts: add dpaa2-console node for DPAA2 > platforms > > On Fri, Dec 21, 2018 at 03:31:09PM +, Ioana Ciornei wrote: > > Add the dpaa2-console device tree node for the following > > DPAA2 based platforms: LS1088A, LS2080A and LS2088A. > > > > Signed-off-by: Ioana Ciornei > > DTS patch generally goes to the last in a series. Should I resend this with the DTS patch the last? Ioana > > Shawn
RE: [PATCH v3] arm64: defconfig: Add i.MX8MQ boot necessary configs
> From: Abel Vesa > Sent: Wednesday, January 16, 2019 5:42 PM > Subject: [PATCH v3] arm64: defconfig: Add i.MX8MQ boot necessary configs > > Enable all the i.MX8MQ configs necessary to boot. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Fabio Estevam > Signed-off-by: Abel Vesa Reviewed-by: Dong Aisheng Regards Dong Aisheng
