[PATCH v2] x86, mce: Fix machine_check_poll() tests for which errors
There has been a lurking "TBD" in the machine check poll routine ever
since it was first split out from the machine check handler. The potential
issue is that the poll routine may have just begun a read from the STATUS
register in a machine check bank when the hardware logs an error in that
bank and signals a machine check. That race used to be pretty small back
when machine checks were broadcast, but the addition of local machine check
means that the poll code could continue running and clear the error from the
bank before the local machine check handler on another CPU gets around to
reading it.
Fix the code to be sure to only process errors that need to be processed
in the poll code, leaving other logged errors alone for the machine check
handler to find and process.
Fixes: b79109c3bbcf ("x86, mce: separate correct machine check poller and fatal
exception handler")
Fixes: ed7290d0ee8f ("x86, mce: implement new status bits")
Reported-by: Ashok Raj
Signed-off-by: Tony Luck
---
V2: Update comment to make it clear that only Intel CPUs with software
error recovery reach the final few tests on whether to log.
arch/x86/kernel/cpu/mce/core.c | 44 --
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 6ce290c506d9..663e8b82eacc 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -712,19 +712,49 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
barrier();
m.status = mce_rdmsrl(msr_ops.status(i));
+
+ /* If this entry is not valid, ignore it */
if (!(m.status & MCI_STATUS_VAL))
continue;
/*
-* Uncorrected or signalled events are handled by the exception
-* handler when it is enabled, so don't process those here.
-*
-* TBD do the same check for MCI_STATUS_EN here?
+* If we are logging everything (at CPU online) or this
+* is a corrected error, then we must log it.
*/
- if (!(flags & MCP_UC) &&
- (m.status & (mca_cfg.ser ? MCI_STATUS_S : MCI_STATUS_UC)))
- continue;
+ if ((flags & MCP_UC) || (m.status & MCI_STATUS_UC) == 0)
+ goto log_it;
+
+ /*
+* Newer Intel systems that support software error
+* recovery need to make additional checks. Other
+* CPUs should skip over uncorrected errors, but log
+* everything else.
+*/
+ if (!mca_cfg.ser) {
+ if (m.status & MCI_STATUS_UC)
+ continue;
+ goto log_it;
+ }
+
+ /* Log "not enabled" (speculative) errors */
+ if (!(m.status & MCI_STATUS_EN))
+ goto log_it;
+
+ /*
+* Log UCNA (SDM: 15.6.3 "UCR Error Classification")
+* UC == 1 && PCC == 0 && S == 0
+*/
+ if (!(m.status & MCI_STATUS_PCC) && !(m.status & MCI_STATUS_S))
+ goto log_it;
+
+ /*
+* Skip anything else. Presumption is that our read of this
+* bank is racing with a machine check. Leave the log alone
+* for do_machine_check() to deal with it.
+*/
+ continue;
+log_it:
error_seen = true;
mce_read_aux(, i);
--
2.19.1
Re: [RFC PATCH 2/2] spi: spi-mem: Add support for Zynq QSPI controller
Hi,
On 11/03/19 10:02 AM, Naga Sureshkumar Relli wrote:
> Hi Vignesh,
>
>> -Original Message-
>> From: linux-spi-ow...@vger.kernel.org On
>> Behalf Of
>> Vignesh Raghavendra
>> Sent: Friday, March 8, 2019 10:20 AM
>> To: Naga Sureshkumar Relli ; broo...@kernel.org;
>> bbrezil...@kernel.org
>> Cc: linux-...@vger.kernel.org; dw...@infradead.org; marek.va...@gmail.com;
>> rich...@nod.at; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
>> Michal Simek
>> ; nagasures...@gmail.com
>> Subject: Re: [RFC PATCH 2/2] spi: spi-mem: Add support for Zynq QSPI
>> controller
>>
>>
>>
>> On 01/03/19 4:32 PM, Naga Sureshkumar Relli wrote:
> +static bool zynq_qspi_supports_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + int ret;
> +
> + ret = zynq_qspi_check_buswidth(op->cmd.buswidth);
> +
> + if (op->addr.nbytes)
> + ret |= zynq_qspi_check_buswidth(op->addr.buswidth);
> +
> + if (op->dummy.nbytes)
> + ret |= zynq_qspi_check_buswidth(op->dummy.buswidth);
> +
> + if (op->data.nbytes)
> + ret |= zynq_qspi_check_buswidth(op->data.buswidth);
> +
> + if (ret)
> + return false;
> +
spi_mem_default_supports_op() already has this code.
Could you change, spi_mem_supports_op() to call
spi_mem_default_supports_op() first before controller specific
->supports_op()? So that, above code can be dropped.
>>> Ok, I will update it.
> + /*
> + * The number of address bytes should be equal to or less than 3 bytes.
> + */
> + if (op->addr.nbytes > 3)
> + return false;
> +
Hmm, how does the driver handle flash devices >16MB in size? Not supported?
>>> Zynq QSPI controller doesn't support 4 byte addressing.
>>> So to support > 16MB size, we have to use EAR(extended address register).
>>> As it is initial version of driver, I haven't added this code. This needs
>>> to be added in spi-nor.c.
>>> Previously I have sent an RFC patch to support all these.
>>> But Boris suggested to upstream the basic one first under spi-mem frame
>>> work.
>>> Not only this support, there are other features like dual parallel and dual
>>> stacked.
>>> All these features require additional support from spi-nor framework.
>>> We have another QSPI controller on ZynqMP SOC, which is also similar(but it
>>> supports
>> 4Byte addressing).
>>> So by consolidating all these, I sent this patch.
>>>
>>> Please let me know your suggestion on this.
>>
>> Sounds fine to me. Support for > 16MB flash using EAR can come later.
> Thanks.
> Shall I wait for others to review or go ahead by addressing your previous
> comments?
>
Typically, for a new driver, I would wait at least 2 weeks from date of
posting so that other reviewers have sufficient time to look into the patch.
--
Regards
Vignesh
Re: [PATCH] tpm: Make timeout logic simpler and more robust
On Mon, 2019-03-11 at 16:54 -0700, Calvin Owens wrote:
> We're having lots of problems with TPM commands timing out, and we're
> seeing these problems across lots of different hardware (both v1/v2).
>
> I instrumented the driver to collect latency data, but I wasn't able to
> find any specific timeout to fix: it seems like many of them are too
> aggressive. So I tried replacing all the timeout logic with a single
> universal long timeout, and found that makes our TPMs 100% reliable.
>
> Given that this timeout logic is very complex, problematic, and appears
> to serve no real purpose, I propose simply deleting all of it.
Normally before sending such a massive change like this, included in
the bug report or patch description, there would be some indication as
to which kernel introduced a regression. Has this always been a
problem? Is this something new? How new?
Mimi
>
> Signed-off-by: Calvin Owens
> ---
> drivers/char/tpm/st33zp24/st33zp24.c | 28 +-
> drivers/char/tpm/tpm-interface.c | 41 +--
> drivers/char/tpm/tpm-sysfs.c | 34 ---
> drivers/char/tpm/tpm.h | 60 +---
> drivers/char/tpm/tpm1-cmd.c | 423 ++-
> drivers/char/tpm/tpm2-cmd.c | 120
> drivers/char/tpm/tpm_crb.c | 20 +-
> drivers/char/tpm/tpm_i2c_atmel.c | 6 -
> drivers/char/tpm/tpm_i2c_infineon.c | 33 +--
> drivers/char/tpm/tpm_i2c_nuvoton.c | 42 +--
> drivers/char/tpm/tpm_nsc.c | 6 +-
> drivers/char/tpm/tpm_tis_core.c | 96 +-
> drivers/char/tpm/xen-tpmfront.c | 17 +-
> 13 files changed, 108 insertions(+), 818 deletions(-)
>
> diff --git a/drivers/char/tpm/st33zp24/st33zp24.c
> b/drivers/char/tpm/st33zp24/st33zp24.c
> index 64dc560859f2..433b9a72f0ef 100644
> --- a/drivers/char/tpm/st33zp24/st33zp24.c
> +++ b/drivers/char/tpm/st33zp24/st33zp24.c
> @@ -154,13 +154,13 @@ static int request_locality(struct tpm_chip *chip)
> if (ret < 0)
> return ret;
>
> - stop = jiffies + chip->timeout_a;
> + stop = jiffies + TPM_UNIVERSAL_TIMEOUT_JIFFIES;
>
> /* Request locality is usually effective after the request */
> do {
> if (check_locality(chip))
> return tpm_dev->locality;
> - msleep(TPM_TIMEOUT);
> + msleep(TPM_TIMEOUT_POLL_MS);
> } while (time_before(jiffies, stop));
>
> /* could not get locality */
> @@ -193,7 +193,7 @@ static int get_burstcount(struct tpm_chip *chip)
> int burstcnt, status;
> u8 temp;
>
> - stop = jiffies + chip->timeout_d;
> + stop = jiffies + TPM_UNIVERSAL_TIMEOUT_JIFFIES;
> do {
> status = tpm_dev->ops->recv(tpm_dev->phy_id, TPM_STS + 1,
> , 1);
> @@ -209,7 +209,7 @@ static int get_burstcount(struct tpm_chip *chip)
> burstcnt |= temp << 8;
> if (burstcnt)
> return burstcnt;
> - msleep(TPM_TIMEOUT);
> + msleep(TPM_TIMEOUT_POLL_MS);
> } while (time_before(jiffies, stop));
> return -EBUSY;
> } /* get_burstcount() */
> @@ -248,11 +248,11 @@ static bool wait_for_tpm_stat_cond(struct tpm_chip
> *chip, u8 mask,
> * @param: check_cancel, does the command can be cancelled ?
> * @return: the tpm status, 0 if success, -ETIME if timeout is reached.
> */
> -static int wait_for_stat(struct tpm_chip *chip, u8 mask, unsigned long
> timeout,
> +static int wait_for_stat(struct tpm_chip *chip, u8 mask,
> wait_queue_head_t *queue, bool check_cancel)
> {
> struct st33zp24_dev *tpm_dev = dev_get_drvdata(>dev);
> - unsigned long stop;
> + unsigned long stop, timeout;
> int ret = 0;
> bool canceled = false;
> bool condition;
> @@ -264,7 +264,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask,
> unsigned long timeout,
> if ((status & mask) == mask)
> return 0;
>
> - stop = jiffies + timeout;
> + stop = jiffies + TPM_UNIVERSAL_TIMEOUT_JIFFIES;
>
> if (chip->flags & TPM_CHIP_FLAG_IRQ) {
> cur_intrs = tpm_dev->intrs;
> @@ -296,7 +296,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask,
> unsigned long timeout,
>
> } else {
> do {
> - msleep(TPM_TIMEOUT);
> + msleep(TPM_TIMEOUT_POLL_MS);
> status = chip->ops->status(chip);
> if ((status & mask) == mask)
> return 0;
> @@ -321,7 +321,6 @@ static int recv_data(struct tpm_chip *chip, u8 *buf,
> size_t count)
> while (size < count &&
> wait_for_stat(chip,
>TPM_STS_DATA_AVAIL | TPM_STS_VALID,
> - chip->timeout_c,
>_dev->read_queue, true) == 0) {
> burstcnt = get_burstcount(chip);
> if
Re: [GIT PULL] chrome-platform updates for v5.1
The pull request you sent on Mon, 11 Mar 2019 21:39:08 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git > tags/tag-chrome-platform-for-v5.1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f47d633134f7033e3d0c667419d9f8afd69e308d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v3 2/2] dt-bindings: net: bluetooth: Add device tree bindings for QTI chip wcn3998
+DT folks
Please add them in future versions (script/scripts/get_maintainer.pl
should have listed them)
On Tue, Mar 12, 2019 at 05:52:59PM +0530, Harish Bandi wrote:
> This patch enables regulators for the Qualcomm Bluetooth wcn3998
> controller.
No, it doesn't.
The next version should probably say something like "Add compatible
string for the Qualcomm WCN3998 Bluetooth controller.
Is there any particular reason why QCA drivers folks use 'wcn' instead
of 'WCN'? The QCA documentations calls it WCN399x, so I'd suggest to
consistently use the uppercase name in comments and documentation (and
log messages?).
> Signed-off-by: Harish Bandi
> ---
> changes in v3:
> - updated to latest code base.
This comment is useless, please describe what changed wrt the previous
version.
> ---
> .../devicetree/bindings/net/qualcomm-bluetooth.txt| 15
> +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> index 824c0e2..1221535 100644
> --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
> @@ -53,3 +53,18 @@ serial@898000 {
> max-speed = <320>;
> };
> };
> +
> +_uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart3_default>;
> + status = "okay";
> +
> + bluetooth: wcn3998-bt {
> + compatible = "qcom,wcn3998-bt";
> + vddio-supply = <_l6_1p8>;
> + vddxo-supply = <_l5_1p8>;
> + vddrf-supply = <_s5_1p35>;
> + vddch0-supply = <_ch0_3p3>;
> + max-speed = <320>;
> + };
> +};
> \ No newline at end of file
I think the example isn't really needed since it's essentially the
same as the one for 'qcom,wcn3990-bt'.
But the important part is missing: add the new compatible string under
´Required properties´. You also want to update the documentation that
mentiones 'qcom,wcn3990-bt' to 'qcom,wcn399x-bt' (assuming for now
that other possible WCN399x chips would be similar).
You mentioned in an earlier version of the series that there are
multiple WCN3998 variants with different requirements for
voltage/current. This seems to suggests that multiple compatible
strings are needed to distinguish between them.
Thanks
Matthias
Re: [PATCH] tpm: Make timeout logic simpler and more robust
On Tue, 2019-03-12 at 07:42 -0700, James Bottomley wrote: > On Tue, 2019-03-12 at 14:50 +0200, Jarkko Sakkinen wrote: > > On Mon, Mar 11, 2019 at 05:27:43PM -0700, James Bottomley wrote: > > > On Mon, 2019-03-11 at 16:54 -0700, Calvin Owens wrote: > > > > e're having lots of problems with TPM commands timing out, and > > > > we're seeing these problems across lots of different hardware > > > > (both v1/v2). > > > > > > > > I instrumented the driver to collect latency data, but I wasn't > > > > able to find any specific timeout to fix: it seems like many of > > > > them are too aggressive. So I tried replacing all the timeout > > > > logic with a single universal long timeout, and found that makes > > > > our TPMs 100% reliable. > > > > > > > > Given that this timeout logic is very complex, problematic, and > > > > appears to serve no real purpose, I propose simply deleting all > > > > of it. > > > > > > "no real purpose" is a bit strong given that all these timeouts are > > > standards mandated. The purpose stated by the standards is that > > > there needs to be a way of differentiating the TPM crashed from the > > > TPM is taking a very long time to respond. For a normally > > > functioning TPM it looks complex and unnecessary, but for a > > > malfunctioning one it's a lifesaver. > > > > Standards should be only followed when they make practical sense and > > ignored when not. The range is only up to 2s anyway. > > I don't disagree ... and I'm certainly not going to defend the TCG > because I do think the complexity of some of its standards contributed > to the lack of use of TPM 1.2. > > However, I am saying we should root cause this problem rather than take > a blind shot at the apparent timeout complexity. My timeout > instability is definitely related to the polling adjustments, so it's > not unreasonable to think Facebooks might be as well. James, I thought Peter sent you a tis "debug" tool to help you debug the problem you're seeing. Whatever happened? Mimi
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 09:37:41, Sultan Alsawaf wrote: > I have not had a chance to look at PSI yet, but > unless a PSI-enabled solution allows allocations to reach the same point as > when > the OOM killer is invoked (which is contradictory to what it sets out to do), > then it cannot take advantage of all of the alternative memory-reclaim means > employed in the slowpath, and will result in killing a process before it is > _really_ necessary. One more note. The above is true, but you can also hit one of the thrashing reclaim behaviors and reclaim last few pages again and again with the whole system really sluggish. That is what PSI is trying to help with. -- Michal Hocko SUSE Labs
Re: [PATCH 02/25] leds: core: Add support for composing LED class device names
Two auto corrections: On 3/10/19 7:28 PM, Jacek Anaszewski wrote: Add public led_compose_name() API for composing LED class device name basing on fwnode_handle data. The function composes device name according to either a new pattern or the legacy pattern. The decision on using the particular pattern is made basing on whether fwnode contains new "function" and "color" properties, or the legacy "label" proeprty. Backwards compatibility with in-driver hard-coded LED class device names is assured thanks to the default_desc argument. In case none of the aforementioned properties was found, then, for OF nodes, the node name is adopted for LED class device name. Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh. The tool allows retrieving details of a LED class device's parent device, which proves that getting rid of a devicename section from LED name pattern is justified since this information is already available in sysfs. Signed-off-by: Jacek Anaszewski Cc: Baolin Wang Cc: Daniel Mack Cc: Dan Murphy Cc: Linus Walleij Cc: Oleh Kravchenko Cc: Sakari Ailus --- Documentation/leds/leds-class.txt | 20 +- drivers/leds/led-core.c | 82 +++ include/linux/leds.h | 31 +++ tools/leds/get_led_device_info.sh | 81 ++ 4 files changed, 213 insertions(+), 1 deletion(-) create mode 100755 tools/leds/get_led_device_info.sh diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index 8b39cc6b03ee..866fe87063d4 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -43,7 +43,22 @@ LED Device Naming Is currently of the form: -"devicename:colour:function" +"colour:function" + +There might be still LED class drivers around using "devicename:colour:function" +naming pattern, but the "devicename" section is now deprecated since it used +to convey information that was already available in the sysfs, like product +name. There is a tool (tools/leds/get_led_device_info.sh) available for +retrieving that information per a LED class device. + +Associations with other devices, like network ones, should be defined +via LED triggr mechanism. This approach is applied by some of wireless s/triggr/trigger/ +network drivers that create triggers dynamically and incorporate phy +name into its name. On the other hand input subsystem offers LED - input s/its name/the trigger name/ +bridge (drivers/input/input-leds.c) for exposing keyboard LEDs as LED class +devices. The get_led_device_info.sh script has support for retrieving related +input device node name. Should it support discovery of associations between +LEDs and other subsystems, please don't hesitate to submit a relevant patch. There have been calls for LED properties such as colour to be exported as individual led class attributes. As a solution which doesn't incur as much @@ -51,6 +66,9 @@ overhead, I suggest these become part of the device name. The naming scheme above leaves scope for further attributes should they be needed. If sections of the name don't apply, just leave that section blank. +Please also keep in mind that LED subsystem has a protection against LED name +conflict. It adds numerical suffix (e.g. "_1", "_2", "_3" etc.) to the requested +LED class device name in case it is already in use. -- Best regards, Jacek Anaszewski
Re: [PATCH] tpm: Make timeout logic simpler and more robust
On Tue, 2019-03-12 at 14:36 +0200, Jarkko Sakkinen wrote: > On Mon, Mar 11, 2019 at 04:54:04PM -0700, Calvin Owens wrote: > > We're having lots of problems with TPM commands timing out, and we're > > seeing these problems across lots of different hardware (both v1/v2). > > > > I instrumented the driver to collect latency data, but I wasn't able to > > find any specific timeout to fix: it seems like many of them are too > > aggressive. So I tried replacing all the timeout logic with a single > > universal long timeout, and found that makes our TPMs 100% reliable. > > > > Given that this timeout logic is very complex, problematic, and appears > > to serve no real purpose, I propose simply deleting all of it. > > > > Signed-off-by: Calvin Owens > > Have been thinking about this and I do agree. It has been like that > before my times with this subsystem so when I did the original TPM2 > patches I carried this logic albeit even at that point I did not get it. > Now that I've been maintaining for over three years I'm confident that > this the Right Thing to do. Please really consider this impact on IMA, before making this change. Mimi
Re: [GIT PULL] chrome-platform updates for v5.1
On Mon, Mar 11, 2019 at 9:39 PM Benson Leung wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git > tags/tag-chrome-platform-for-v5.1 No diffstat in the pull request? And the shortlog looks truncated too, with Nick Crews being reported as having four commits, but only two visible. (And yes, there are four commits in the pull itself). Finally, you say: > 2. Cleanup series between mfd and chrome/platform, moving >cros-ec attributes from mfd/cros_ec_dev to sub-drivers in platform/chrome. which I don't see at all in that pull. But that turns out to be because it already came through the mfd tree. Things look otherwise sane and I did the pull, but please fix your script and/or workflow. The "it already came through the mfd tree" issue is fine, but diffstat and truncated shortlog is bad. Linus
Re: [RFC PATCH v3 3/5] tracing: Use tracing error_log with hist triggers
Hi Masami, On Wed, 2019-03-13 at 00:46 +0900, Masami Hiramatsu wrote: > On Mon, 4 Mar 2019 17:36:46 -0600 > Tom Zanussi wrote: > > > From: Tom Zanussi > > > > Replace hist_err() and hist_err_event() with tracing_log_err() from > > the new tracing error_log mechanism. > > > > Also add a couple related helper functions and remove most of the > > old > > hist_err()-related code. > > > > With this change, users no longer read the hist files for hist > > trigger > > error information, but instead look at tracing/error_log for the > > same > > information. > > Could you also add a patch which update its testcase? > > test.d/trigger/inter-event/trigger-extended-error-support.tc > > will fail after this patch. > Yeah, good point, will do (and documentation too). Thanks, Tom
Re: [RFC PATCH v3 0/5] tracing: common error_log for ftrace
Hi Masami, On Tue, 2019-03-12 at 15:26 +0900, Masami Hiramatsu wrote: > Hi Tom, > > On Tue, 5 Mar 2019 23:06:46 +0900 > Masami Hiramatsu wrote: > > > On Mon, 4 Mar 2019 17:36:43 -0600 > > > Changes from v2: > > > > > > - Added [n] numbering as suggested by Masami > > Hmm, this seems a bit different what I suggested. > > I'm trying to port probe event's error report on > your error log, and I found that the number is > just shifted as below. > > When I filled the log with errors. > = > /sys/kernel/debug/tracing # cat error_log > [1] trace_kprobe: error: Invalid unsigned integer string > Command: r10aa00:foo/bar vfs > ^ > ... > > [7] trace_kprobe: error: Group name must follow C naming convention > Command: p:a-b/bar vfs_read > ^ > [8] trace_kprobe: error: Event name is too long > Command: > p:a/barrr > rrr vfs_read > = > > And do one more error, > > = > /sys/kernel/debug/tracing # cat error_log > [1] trace_kprobe: error: Maxactive is too big > Command: r0xaa00:foo/bar vfs > > > > [7] trace_kprobe: error: Event name is too long > Command: > p:a/barrr > rrr vfs_read >^ > [8] trace_kprobe: error: Event name must follow C naming convention > Command: p:a/bar.c vfs_read >^ > = > > The number of logs are changed :( This can confuse users. > I think it is better to keep the number as a unique number for > each entry as below. > Hmm, that makes sense, but I wonder if that will also confuse users, when the log wraps around and no longer starts at [1] and there's no way to retrieve the previous errors. I took your suggestion as a way mainly to clearly delineate each error, since without the [number] or something similar, they all kind of run together. Not sure what advantage numbering itself provides - would some other non-numbered separator work? Thanks, Tom > = > /sys/kernel/debug/tracing # cat error_log > [2] trace_kprobe: error: Maxactive is too big > Command: r0xaa00:foo/bar vfs > > > > [8] trace_kprobe: error: Event name is too long > Command: > p:a/barrr > rrr vfs_read >^ > [9] trace_kprobe: error: Event name must follow C naming convention > Command: p:a/bar.c vfs_read >^ > = > > Thank you, >
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 09:37:41, Sultan Alsawaf wrote: > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > The only way to control the OOM behavior pro-actively is to throttle > > allocation speed. We have memcg high limit for that purpose. Along with > > PSI, I can imagine a reasonably working user space early oom > > notifications and reasonable acting upon that. > > The issue with pro-active memory management that prompted me to create this > was > poor memory utilization. All of the alternative means of reclaiming pages in > the > page allocator's slow path turn out to be very useful for maximizing memory > utilization, which is something that we would have to forgo by relying on a > purely pro-active solution. I have not had a chance to look at PSI yet, but > unless a PSI-enabled solution allows allocations to reach the same point as > when > the OOM killer is invoked (which is contradictory to what it sets out to do), > then it cannot take advantage of all of the alternative memory-reclaim means > employed in the slowpath, and will result in killing a process before it is > _really_ necessary. If you really want to reach the real OOM situation then you can very well rely on the in-kernel OOM killer. The only reason you want a customized oom killer is the tasks clasification. And that is a different story. User space hints on the victim selection has been a topic for quite while. It never get to any conclusion as interested parties have always lost an interest because it got hairy quickly. > > If you design is relies on the speed of killing then it is fundamentally > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > It might be blocked in an uninterruptible sleep or performin an > > operation which takes some time. Sure, oom_reaper might help here but > > still. > > In theory we could instantly zap any process that is not trapped in the kernel > at the time that the OOM killer is invoked without any consequences though, > no? No, this is not so simple. Have a look at the oom_reaper and hops it has to go through. -- Michal Hocko SUSE Labs
Re: [PATCH] mm: compaction: some tracepoints should be defined only when CONFIG_COMPACTION is set
On Wed, Mar 13, 2019 at 12:44 AM Michal Hocko wrote:
>
> On Wed 13-03-19 00:29:57, Yafang Shao wrote:
> > On Wed, Mar 13, 2019 at 12:18 AM Michal Hocko wrote:
> > >
> > > On Sat 02-03-19 12:38:58, Yafang Shao wrote:
> > > > Only mm_compaction_isolate_{free, migrate}pages may be used when
> > > > CONFIG_COMPACTION is not set.
> > > > All others are used only when CONFIG_COMPACTION is set.
> > >
> > > Why is this an improvement?
> > >
> >
> > After this change, if CONFIG_COMPACTION is not set, the tracepoints
> > that only work when CONFIG_COMPACTION is set will not be exposed to
> > the usespace.
> > Without this change, they will always be expose in debugfs no matter
> > CONFIG_COMPACTION is set or not.
>
> And this is exactly something that the changelog should mention. I
> wasn't aware that we do export tracepoints even when they are not used
> by any code path. This whole macro based programming is just a black
> magic.
> --
Sure, I will modify the changelog and send v2.
Thanks
Yafang
Re: [PATCH][v2] ipc: prevent lockup on alloc_msg and free_msg
On 2019-03-07 23:12, Li RongQing wrote: From: Li Rongqing msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is enabled on large memory SMP systems, the pages initialization can take a long time, if msgctl10 requests a huge block memory, and it will block rcu scheduler, so release cpu actively. After adding schedule() in free_msg, free_msg can not be called when holding spinlock, so adding msg to a tmp list, and free it out of spinlock [79441.630467] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [79441.637566] rcu: Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505 [79441.645355] rcu: Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978 [79441.653149] rcu: (detected by 11, t=35024 jiffies, g=44237529, q=16542267) [79441.661247] msgctl10R running task21608 32505 2794 0x0082 [79441.669455] Call Trace: [79441.736659] preempt_schedule_irq+0x4c/0xb0 [79441.741578] retint_kernel+0x1b/0x2d [79441.745796] RIP: 0010:__is_insn_slot_addr+0xfb/0x250 [79441.751595] Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48 [79441.773232] RSP: 0018:88bce041f758 EFLAGS: 0246 ORIG_RAX: ff13 [79441.782071] RAX: dc00 RBX: 8471bc50 RCX: 828a2a57 [79441.790337] RDX: dc00 RSI: dc00 RDI: 88bce041f780 [79441.798612] RBP: 88bce041f828 R08: ed15f3f4c5b3 R09: ed15f3f4c5b3 [79441.806877] R10: 0001 R11: ed15f3f4c5b2 R12: 00318aee9b73 [79441.815139] R13: 8471bc50 R14: 11179c083ef0 R15: 11179c083eec [79441.848618] kernel_text_address+0xc1/0x100 [79441.853542] __kernel_text_address+0xe/0x30 [79441.858453] unwind_get_return_address+0x2f/0x50 [79441.863864] __save_stack_trace+0x92/0x100 [79441.868742] create_object+0x380/0x650 [79441.911831] __kmalloc+0x14c/0x2b0 [79441.915874] load_msg+0x38/0x1a0 [79441.919726] do_msgsnd+0x19e/0xcf0 [79442.006475] do_syscall_64+0x117/0x400 [79442.037964] entry_SYSCALL_64_after_hwframe+0x49/0xbe [79386.022357] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [79386.029455] rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170 [79386.037146] rcu: (detected by 14, t=35016 jiffies, g=44237525, q=12423063) [79386.045242] msgctl10R running task21608 32170 32155 0x0082 [79386.053447] Call Trace: [79386.107584] preempt_schedule_irq+0x4c/0xb0 [79386.112495] retint_kernel+0x1b/0x2d [79386.116712] RIP: 0010:lock_acquire+0x4d/0x340 [79386.121816] Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82 [79386.143446] RSP: 0018:88af83417738 EFLAGS: 0282 ORIG_RAX: ff13 [79386.152278] RAX: dc00 RBX: 88bd335f3080 RCX: 0002 [79386.160543] RDX: RSI: RDI: 88bd335f3d64 [79386.168798] RBP: 88af83417758 R08: R09: [79386.177049] R10: 0001 R11: ed13f3f745b2 R12: [79386.185308] R13: 0002 R14: R15: [79386.213791] is_bpf_text_address+0x32/0xe0 [79386.223516] kernel_text_address+0xec/0x100 [79386.233532] __kernel_text_address+0xe/0x30 [79386.238448] unwind_get_return_address+0x2f/0x50 [79386.243858] __save_stack_trace+0x92/0x100 [79386.252648] save_stack+0x32/0xb0 [79386.357923] __kasan_slab_free+0x130/0x180 [79386.362745] kfree+0xfa/0x2d0 [79386.366291] free_msg+0x24/0x50 [79386.370020] do_msgrcv+0x508/0xe60 [79386.446596] do_syscall_64+0x117/0x400 [79386.478122] entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Li RongQing Signed-off-by: Zhang Yu --- v1 -->v2: move free_msg out of spinlock in mqueue_evict_inode move schedule() from loop end to loop start, since it does not isolate two kmallocs in loop end ipc/mqueue.c | 10 -- ipc/msgutil.c | 6 ++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/ipc/mqueue.c b/ipc/mqueue.c index c0d58f390..bce7af154 100644 --- a/ipc/mqueue.c +++ b/ipc/mqueue.c @@ -391,7 +391,8 @@ static void mqueue_evict_inode(struct inode *inode) struct user_struct *user; unsigned long mq_bytes, mq_treesize; struct ipc_namespace *ipc_ns; - struct msg_msg *msg; + struct msg_msg *msg, *nmsg; + LIST_HEAD(tmp_msg); clear_inode(inode); @@ -402,10 +403,15 @@ static void mqueue_evict_inode(struct inode *inode) info = MQUEUE_I(inode); spin_lock(>lock); while ((msg = msg_get(info)) != NULL) - free_msg(msg); + list_add_tail(>m_list, _msg); kfree(info->node_cache); spin_unlock(>lock); So after releasing
Re: [PATCH] mm: compaction: some tracepoints should be defined only when CONFIG_COMPACTION is set
On Wed 13-03-19 00:29:57, Yafang Shao wrote:
> On Wed, Mar 13, 2019 at 12:18 AM Michal Hocko wrote:
> >
> > On Sat 02-03-19 12:38:58, Yafang Shao wrote:
> > > Only mm_compaction_isolate_{free, migrate}pages may be used when
> > > CONFIG_COMPACTION is not set.
> > > All others are used only when CONFIG_COMPACTION is set.
> >
> > Why is this an improvement?
> >
>
> After this change, if CONFIG_COMPACTION is not set, the tracepoints
> that only work when CONFIG_COMPACTION is set will not be exposed to
> the usespace.
> Without this change, they will always be expose in debugfs no matter
> CONFIG_COMPACTION is set or not.
And this is exactly something that the changelog should mention. I
wasn't aware that we do export tracepoints even when they are not used
by any code path. This whole macro based programming is just a black
magic.
--
Michal Hocko
SUSE Labs
Re: [PATCH v1 05/10] perf, report: Show all sort keys in help output
> that line goes forever now, please provide some formating
> into multiple lines
Here's an updated patch with line wrapping.
---
perf report: Show all sort keys in help output
Show all the supported sort keys in the command line help output,
so that it's not needed to refer to the manpage.
Signed-off-by: Andi Kleen
---
v2: Now line wrap output.
---
tools/perf/builtin-report.c | 5 ++--
tools/perf/util/sort.c | 52 +
tools/perf/util/sort.h | 2 ++
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 1532ebde6c4b..6317c38762dd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -1044,10 +1044,9 @@ int cmd_report(int argc, const char **argv)
OPT_BOOLEAN(0, "header-only", _only,
"Show only data header."),
OPT_STRING('s', "sort", _order, "key[,key2...]",
- "sort by key(s): pid, comm, dso, symbol, parent, cpu,
srcline, ..."
- " Please refer the man page for the complete list."),
+ sort_help("sort by key(s):")),
OPT_STRING('F', "fields", _order, "key[,keys...]",
- "output field(s): overhead, period, sample plus all of sort
keys"),
+ sort_help("output field(s): overhead, period, sample,")),
OPT_BOOLEAN(0, "show-cpu-utilization",
_conf.show_cpu_utilization,
"Show sample percentage for different cpu modes"),
OPT_BOOLEAN_FLAG(0, "showcpuutilization",
_conf.show_cpu_utilization,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index d2299e912e59..ea71d3732a50 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -12,6 +12,7 @@
#include "evsel.h"
#include "evlist.h"
#include "strlist.h"
+#include "strbuf.h"
#include
#include "mem-events.h"
#include "annotate.h"
@@ -3068,3 +3069,54 @@ void reset_output_field(void)
reset_dimensions();
perf_hpp__reset_output_field(_hpp_list);
}
+
+#define INDENT (3*8 + 1)
+
+static void add_key(struct strbuf *sb, const char *str, int *llen)
+{
+ if (*llen >= 75) {
+ strbuf_addstr(sb, "\n\t\t\t ");
+ *llen = INDENT;
+ }
+ strbuf_addf(sb, " %s", str);
+ *llen += strlen(str) + 1;
+}
+
+static void add_sort_string(struct strbuf *sb, struct sort_dimension *s, int n,
+ int *llen)
+{
+ int i;
+
+ for (i = 0; i < n; i++)
+ add_key(sb, s[i].name, llen);
+}
+
+static void add_hpp_sort_string(struct strbuf *sb, struct hpp_dimension *s,
int n,
+ int *llen)
+{
+ int i;
+
+ for (i = 0; i < n; i++)
+ add_key(sb, s[i].name, llen);
+}
+
+const char *sort_help(const char *prefix)
+{
+ struct strbuf sb;
+ char *s;
+ int len = strlen(prefix) + INDENT;
+
+ strbuf_init(, 300);
+ strbuf_addstr(, prefix);
+ add_hpp_sort_string(, hpp_sort_dimensions,
+ ARRAY_SIZE(hpp_sort_dimensions), );
+ add_sort_string(, common_sort_dimensions,
+ ARRAY_SIZE(common_sort_dimensions), );
+ add_sort_string(, bstack_sort_dimensions,
+ ARRAY_SIZE(bstack_sort_dimensions), );
+ add_sort_string(, memory_sort_dimensions,
+ ARRAY_SIZE(memory_sort_dimensions), );
+ s = strbuf_detach(, NULL);
+ strbuf_release();
+ return s;
+}
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index 2fbee0b1011c..93d1b25da341 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -286,6 +286,8 @@ void reset_output_field(void);
void sort__setup_elide(FILE *fp);
void perf_hpp__set_elide(int idx, bool elide);
+const char *sort_help(const char *prefix);
+
int report_parse_ignore_callees_opt(const struct option *opt, const char *arg,
int unset);
bool is_strict_order(const char *order);
--
2.20.1
Re: [PATCH 05/25] dt-bindings: leds: Add function and color properties
On 3/11/19 6:24 PM, Jacek Anaszewski wrote:
Dan,
On 3/11/19 1:26 PM, Dan Murphy wrote:
On 3/10/19 1:28 PM, Jacek Anaszewski wrote:
Introduce dedicated properties for conveying information about
LED function and color. Mark old "label" property as deprecated.
Signed-off-by: Jacek Anaszewski
Cc: Baolin Wang
Cc: Daniel Mack
Cc: Dan Murphy
Cc: Linus Walleij
Cc: Oleh Kravchenko
Cc: Sakari Ailus
Cc: Simon Shields
---
Documentation/devicetree/bindings/leds/common.txt | 55
+++
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index aa1399814a2a..3402b0e1cec9 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -10,14 +10,23 @@ can influence the way of the LED device
initialization, the LED components
have to be tightly coupled with the LED device binding. They are
represented
by child nodes of the parent LED device binding.
+
Optional properties for child nodes:
- led-sources : List of device current outputs the LED is connected
to. The
outputs are identified by the numbers that must be defined
in the LED device binding documentation.
+- function: LED functon. Use one of the LED_FUNCTION_* prefixed
definitions
+ from the header include/dt-bindings/leds/common.h.
+ If there is no matching LED_FUNCTION available, add a new one.
+- color : Color of the LED. Use one of the LED_COLOR_NAME_* prefixed
definitions
+ from the header include/dt-bindings/leds/common.h.
+ If there is no matching LED_COLOR_NAME available, add a new
one.
+
I am assuming multi color can re-use this property as well?
I intended it to be a string, but indeed it would be better if we will
make it an integer to be consistent with the discussed LED multi color
design.
Going further, I wonder if it would make sense to make function also
an integer. This way we could enforce use of LED functions known
to kernel.
Additionally, if we introduced a property like function-enum-val
(better name suggestions are welcome), then we could easily solve the
problem of string concatenation limitation in dtc compiler mentioned
in the cover letter, since the concatenation would be done in the LED core.
- label : The label for this LED. If omitted, the label is taken
from the node
name (excluding the unit address). It has to uniquely identify
a device, i.e. no other LED class device can be assigned the
same
- label.
+ label. This property is deprecated - use 'function' and 'color'
+ properties instead.
- default-state : The initial state of the LED. Valid values are
"on", "off",
and "keep". If the LED is already on or off and the default-state
property is
@@ -87,29 +96,59 @@ Required properties for trigger source:
* Examples
-gpio-leds {
+#include
+
+led-controller@0 {
compatible = "gpio-leds";
- system-status {
- label = "Status";
+ led0 {
+ function = LED_FUNCTION_STATUS;
Missing color for example unless there is a reason to omit it for GPIO
LEDs
It is on purpose - to show that it is an optional property for
monochrome LEDs.
Also missing reg here
Also on purpose. leds-gpio bindings don't require reg here.
And when reg is absent the unit address in the node name should
be omitted as Rob stated in one of recent reviews.
linux,default-trigger = "heartbeat";
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
- usb {
+ led1 {
+ function = LED_FUNCTION_USB;
Same as above
Also missing reg here
gpios = < 1 GPIO_ACTIVE_HIGH>;
trigger-sources = <_port1>, <_port1>;
};
};
-max77693-led {
+led-controller@0 {
compatible = "maxim,max77693-led";
- camera-flash {
- label = "Flash";
+ led {
+ function = LED_FUNCTION_FLASH;
+ color = LED_COLOR_NAME_WHITE;
led-sources = <0>, <1>;
led-max-microamp = <5>;
flash-max-microamp = <32>;
flash-max-timeout-us = <50>;
};
};
+
+led-controller@30 {
+ compatible = "panasonic,an30259a";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ linux,default-trigger = "heartbeat";
+ function = LED_FUNCTION_INDICATOR;
+ color = LED_COLOR_NAME_RED;
+ };
+
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_INDICATOR;
+ color = LED_COLOR_NAME_GREEN;
+ };
+
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_INDICATOR;
+ color = LED_COLOR_NAME_BLUE;
+ };
+};
--
Best regards,
Jacek Anaszewski
[GIT PULL] Kconfig updates for v5.1
Hi Linus,
Please pull Kconfig updates for v5.1.
Thanks.
The following changes since commit f17b5f06cb92ef2250513a1e154c47b78df07d40:
Linux 5.0-rc4 (2019-01-27 15:18:05 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kconfig-v5.1
for you to fetch changes up to 8741908b3e29d35a33eeab6de60175958db8e54b:
kconfig: fix 'Save As' menu of xconfig (2019-03-12 02:50:24 +0900)
Kconfig updates for v5.1
- rename lexer and parse files
- fix 'Save as' menu of xconfig
Masahiro Yamada (3):
kconfig: rename zconf.l to lexer.l
kconfig: rename zconf.y to parser.y
kconfig: fix 'Save As' menu of xconfig
scripts/kconfig/Makefile | 9
scripts/kconfig/expr.h| 2 +-
scripts/kconfig/{zconf.l => lexer.l} | 2 +-
scripts/kconfig/lkc.h | 2 +-
scripts/kconfig/{zconf.y => parser.y} | 0
scripts/kconfig/qconf.cc | 42 +--
scripts/kconfig/qconf.h | 1 +
7 files changed, 44 insertions(+), 14 deletions(-)
rename scripts/kconfig/{zconf.l => lexer.l} (99%)
rename scripts/kconfig/{zconf.y => parser.y} (100%)
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 2/4] dt-bindings: maxbotix,i2cxl: Add MaxBotix i2c ultrasonic rangers
On Sat, Mar 02, 2019 at 06:26:39PM +, Jonathan Cameron wrote: > On Fri, 1 Mar 2019 14:42:27 +0100 > Andreas Klinger wrote: > > > Add doc for dt binding maxbotix,i2cxl. This binding is for MaxBotix > > I2CXL-MaxSonar ultrasonic rangers which share a common i2c interface. > > I'm a bit confused on the naming. Certainly the binding should have > separate entries for each supported part, rather than a group one > for their i2cxl naming. Having said that they do have a wide > range of parts with only the one datasheet. > > Rob, what do you think? Go with this i2cxl naming > or list the individual supported parts? Looks like the difference is mainly just the range. Is that something s/w needs to know about? > > mb1202, mb1212, mb1222, mb1232, mb1242, mb7040, > mb7137? OTOH, that's not really too many. Rob
Re: [PATCH v3 4/9] drivers: irqchip: add PDC irqdomain for wakeup capable GPIOs
On Mon, Mar 11 2019 at 04:42 -0600, Marc Zyngier wrote:
On 22/02/2019 22:18, Lina Iyer wrote:
Introduce a new domain for wakeup capable GPIOs. The domain can be
requested using the bus token DOMAIN_BUS_WAKEUP. In the following
patches, we will specify PDC as the wakeup-parent for the TLMM GPIO
irqchip. Requesting a wakeup GPIO will setup the GPIO and the
corresponding PDC interrupt as its parent.
Co-developed-by: Stephen Boyd
Signed-off-by: Lina Iyer
---
Changes in v3:
- Remove PDC GPIO map data (moved to DT)
- hwirq passed in .alloc() is a PDC pin now
Changes in v2:
- Remove separate file for PDC GPIO map data
- Error checks and return
- Whitespace fixes
---
drivers/irqchip/qcom-pdc.c | 106 ---
include/linux/soc/qcom/irq.h | 23
2 files changed, 120 insertions(+), 9 deletions(-)
create mode 100644 include/linux/soc/qcom/irq.h
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index faa7d61b9d6c..5a64cbeec410 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -13,12 +13,13 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
#define PDC_MAX_IRQS 126
+#define PDC_MAX_GPIO_IRQS 256
#define CLEAR_INTR(reg, intr) (reg & ~(1 << intr))
#define ENABLE_INTR(reg, intr) (reg | (1 << intr))
@@ -32,6 +33,16 @@ struct pdc_pin_region {
u32 cnt;
};
+struct pdc_gpio_pin_map {
+ unsigned int gpio;
+ u32 pdc_pin;
+};
+
+struct pdc_gpio_pin_data {
+ size_t size;
+ const struct pdc_gpio_pin_map *map;
+};
I can't see this being used anywhere.
Thanks for catching this.
This and the ULONG_MAX changes are from a previous idea. We don't need
them anymore.. I will remove them.
+
static DEFINE_RAW_SPINLOCK(pdc_lock);
static void __iomem *pdc_base;
static struct pdc_pin_region *pdc_region;
@@ -47,9 +58,8 @@ static u32 pdc_reg_read(int reg, u32 i)
return readl_relaxed(pdc_base + reg + i * sizeof(u32));
}
-static void pdc_enable_intr(struct irq_data *d, bool on)
+static void pdc_enable_intr(irq_hw_number_t pin_out, bool on)
{
- int pin_out = d->hwirq;
Why do you need this change? As far as I can tell, you can always use
the irq_data here, and it would reduce the size of the patch.
Agreed
u32 index, mask;
u32 enable;
@@ -65,13 +75,23 @@ static void pdc_enable_intr(struct irq_data *d, bool on)
static void qcom_pdc_gic_mask(struct irq_data *d)
{
- pdc_enable_intr(d, false);
+ irq_hw_number_t hwirq = d->hwirq;
+
+ if (hwirq == ULONG_MAX)
Can you define a specific constant here? PDC_WAKEUP_IRQ? Or something?
Also, I can't work out where d->hwirq gets set to such value.
With an earlier approach, it could, not with this. We could remove them
all.
+ return;
+
+ pdc_enable_intr(hwirq, false);
irq_chip_mask_parent(d);
}
static void qcom_pdc_gic_unmask(struct irq_data *d)
{
- pdc_enable_intr(d, true);
+ irq_hw_number_t hwirq = d->hwirq;
+
+ if (hwirq == ULONG_MAX)
+ return;
+
+ pdc_enable_intr(hwirq, true);
irq_chip_unmask_parent(d);
}
@@ -111,9 +131,12 @@ enum pdc_irq_config_bits {
*/
static int qcom_pdc_gic_set_type(struct irq_data *d, unsigned int type)
{
- int pin_out = d->hwirq;
+ irq_hw_number_t pin_out = d->hwirq;
enum pdc_irq_config_bits pdc_type;
+ if (pin_out == ULONG_MAX)
+ return 0;
+
It is quite odd that you're accepting any odd trigger, even if they are
illegal. The API should be consistent, even if you're not applying any
change.
Ok. This should be remvoed.
switch (type) {
case IRQ_TYPE_EDGE_RISING:
pdc_type = PDC_EDGE_RISING;
@@ -157,7 +180,7 @@ static struct irq_chip qcom_pdc_gic_chip = {
.irq_set_affinity = irq_chip_set_affinity_parent,
};
-static irq_hw_number_t get_parent_hwirq(int pin)
+static irq_hw_number_t get_parent_hwirq(irq_hw_number_t pin)
{
int i;
struct pdc_pin_region *region;
@@ -169,7 +192,6 @@ static irq_hw_number_t get_parent_hwirq(int pin)
return (region->parent_base + pin - region->pin_base);
}
- WARN_ON(1);
return ~0UL;
Above, you're using ULONG_MAX, and here ~0UL. You need to make up your
mind and use one single identifier. Or maybe these are not the same
thing? In any case, you need to lift the ambiguity.
Will do.
}
@@ -232,6 +254,60 @@ static const struct irq_domain_ops qcom_pdc_ops = {
.free = irq_domain_free_irqs_common,
};
+static int qcom_pdc_gpio_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *data)
+{
+ struct qcom_irq_fwspec *qcom_fwspec = data;
+ struct irq_fwspec *fwspec = _fwspec->fwspec;
+ struct irq_fwspec parent_fwspec;
+ irq_hw_number_t
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > The only way to control the OOM behavior pro-actively is to throttle > allocation speed. We have memcg high limit for that purpose. Along with > PSI, I can imagine a reasonably working user space early oom > notifications and reasonable acting upon that. The issue with pro-active memory management that prompted me to create this was poor memory utilization. All of the alternative means of reclaiming pages in the page allocator's slow path turn out to be very useful for maximizing memory utilization, which is something that we would have to forgo by relying on a purely pro-active solution. I have not had a chance to look at PSI yet, but unless a PSI-enabled solution allows allocations to reach the same point as when the OOM killer is invoked (which is contradictory to what it sets out to do), then it cannot take advantage of all of the alternative memory-reclaim means employed in the slowpath, and will result in killing a process before it is _really_ necessary. > If you design is relies on the speed of killing then it is fundamentally > flawed AFAICT. You cannot assume anything about how quickly a task dies. > It might be blocked in an uninterruptible sleep or performin an > operation which takes some time. Sure, oom_reaper might help here but > still. In theory we could instantly zap any process that is not trapped in the kernel at the time that the OOM killer is invoked without any consequences though, no? Thanks, Sultan
Re: [PATCH v3 6/9] drivers: pinctrl: msm: setup GPIO irqchip hierarchy
On Mon, Mar 11 2019 at 04:55 -0600, Marc Zyngier wrote:
On 22/02/2019 22:18, Lina Iyer wrote:
To allow GPIOs to wakeup the system from suspend or deep idle, the
wakeup capable GPIOs are setup in hierarchy with interrupts from the
wakeup-parent irqchip.
In older SoC's, the TLMM will handover detection to the parent irqchip
and in newer SoC's, the parent irqchip may also be active as well as the
TLMM and therefore the GPIOs need to be masked at TLMM to avoid
duplicate interrupts. To enable both these configurations to exist,
allow the parent irqchip to dictate the TLMM irqchip's behavior when
masking/unmasking the interrupt.
Co-developed-by: Stephen Boyd
Signed-off-by: Lina Iyer
[...]
@@ -986,6 +1093,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
chip->need_valid_mask = msm_gpio_needs_valid_mask(pctrl);
pctrl->irq_chip.name = "msmgpio";
+ pctrl->irq_chip.irq_eoi = irq_chip_eoi_parent;
pctrl->irq_chip.irq_mask = msm_gpio_irq_mask;
pctrl->irq_chip.irq_unmask = msm_gpio_irq_unmask;
pctrl->irq_chip.irq_ack = msm_gpio_irq_ack;
@@ -994,6 +1102,22 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
pctrl->irq_chip.irq_request_resources = msm_gpio_irq_reqres;
pctrl->irq_chip.irq_release_resources = msm_gpio_irq_relres;
+ chip->irq.chip = >irq_chip;
+ chip->irq.domain_ops = _gpio_domain_ops;
+ chip->irq.handler = handle_edge_irq;
+ chip->irq.default_type = IRQ_TYPE_NONE;
I know you're only moving this around, but can you explain why you're
setting IRQ_TYPE_NONE in combination with handle_edge_irq? The two
really should go together. If this doesn't work for some reason, please
document it.
Yes, it was a carry-over from the existing code. I am not sure why that
seems to be a common practice among GPIO drivers.
IRQ_TYPE_EDGE_RISING would be a better option ?
+
+ dn = of_parse_phandle(pctrl->dev->of_node, "wakeup-parent", 0);
+ if (dn) {
+ chip->irq.parent_domain = irq_find_matching_host(dn,
+DOMAIN_BUS_WAKEUP);
+ of_node_put(dn);
+ if (!chip->irq.parent_domain)
+ return -EPROBE_DEFER;
+
+ chip->to_irq = msm_gpio_to_irq;
+ }
+
ret = gpiochip_add_data(>chip, pctrl);
if (ret) {
dev_err(pctrl->dev, "Failed register gpiochip\n");
@@ -1015,26 +1139,17 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
dev_name(pctrl->dev), 0, 0, chip->ngpio);
if (ret) {
dev_err(pctrl->dev, "Failed to add pin range\n");
- gpiochip_remove(>chip);
- return ret;
+ goto fail;
}
}
- ret = gpiochip_irqchip_add(chip,
- >irq_chip,
- 0,
- handle_edge_irq,
- IRQ_TYPE_NONE);
- if (ret) {
- dev_err(pctrl->dev, "Failed to add irqchip to gpiochip\n");
- gpiochip_remove(>chip);
- return -ENOSYS;
- }
-
gpiochip_set_chained_irqchip(chip, >irq_chip, pctrl->irq,
msm_gpio_irq_handler);
return 0;
+fail:
+ gpiochip_remove(>chip);
+ return ret;
}
Thanks,
Lina
[PATCH 1/4] regulator: wm831x-isink: Select maximum current in specific range
.set_current_limit callback should select the current closest to max_uA.
Signed-off-by: Axel Lin
---
drivers/regulator/wm831x-isink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/wm831x-isink.c b/drivers/regulator/wm831x-isink.c
index 6dd891d7eee3..676a4701c986 100644
--- a/drivers/regulator/wm831x-isink.c
+++ b/drivers/regulator/wm831x-isink.c
@@ -99,7 +99,7 @@ static int wm831x_isink_set_current(struct regulator_dev
*rdev,
struct wm831x *wm831x = isink->wm831x;
int ret, i;
- for (i = 0; i < ARRAY_SIZE(wm831x_isinkv_values); i++) {
+ for (i = ARRAY_SIZE(wm831x_isinkv_values) - 1; i >= 0; i--) {
int val = wm831x_isinkv_values[i];
if (min_uA <= val && val <= max_uA) {
ret = wm831x_set_bits(wm831x, isink->reg,
--
2.17.1
[PATCH 2/4] regulator: wm8350: Select maximum current in specific range
.set_current_limit callback should select the current closest to max_uA.
Signed-off-by: Axel Lin
---
drivers/regulator/wm8350-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/wm8350-regulator.c
b/drivers/regulator/wm8350-regulator.c
index a1c7dfee5c37..d1758a2bc769 100644
--- a/drivers/regulator/wm8350-regulator.c
+++ b/drivers/regulator/wm8350-regulator.c
@@ -99,7 +99,7 @@ static int get_isink_val(int min_uA, int max_uA, u16 *setting)
{
int i;
- for (i = 0; i < ARRAY_SIZE(isink_cur); i++) {
+ for (i = ARRAY_SIZE(isink_cur) - 1; i >= 0; i--) {
if (min_uA <= isink_cur[i] && max_uA >= isink_cur[i]) {
*setting = i;
return 0;
--
2.17.1
[PATCH 4/4] regulator: wm8350: Convert to use regulator_set/get_current_limit_regmap
Use regulator_set/get_current_limit_regmap helpers to save some code.
Signed-off-by: Axel Lin
---
drivers/regulator/wm8350-regulator.c | 81
1 file changed, 11 insertions(+), 70 deletions(-)
diff --git a/drivers/regulator/wm8350-regulator.c
b/drivers/regulator/wm8350-regulator.c
index d1758a2bc769..0eb3f3a33caa 100644
--- a/drivers/regulator/wm8350-regulator.c
+++ b/drivers/regulator/wm8350-regulator.c
@@ -28,7 +28,7 @@
#define WM8350_DCDC_MAX_VSEL 0x66
/* Microamps */
-static const int isink_cur[] = {
+static const unsigned int isink_cur[] = {
4,
5,
6,
@@ -95,73 +95,6 @@ static const int isink_cur[] = {
223191
};
-static int get_isink_val(int min_uA, int max_uA, u16 *setting)
-{
- int i;
-
- for (i = ARRAY_SIZE(isink_cur) - 1; i >= 0; i--) {
- if (min_uA <= isink_cur[i] && max_uA >= isink_cur[i]) {
- *setting = i;
- return 0;
- }
- }
- return -EINVAL;
-}
-
-static int wm8350_isink_set_current(struct regulator_dev *rdev, int min_uA,
- int max_uA)
-{
- struct wm8350 *wm8350 = rdev_get_drvdata(rdev);
- int isink = rdev_get_id(rdev);
- u16 val, setting;
- int ret;
-
- ret = get_isink_val(min_uA, max_uA, );
- if (ret != 0)
- return ret;
-
- switch (isink) {
- case WM8350_ISINK_A:
- val = wm8350_reg_read(wm8350, WM8350_CURRENT_SINK_DRIVER_A) &
- ~WM8350_CS1_ISEL_MASK;
- wm8350_reg_write(wm8350, WM8350_CURRENT_SINK_DRIVER_A,
-val | setting);
- break;
- case WM8350_ISINK_B:
- val = wm8350_reg_read(wm8350, WM8350_CURRENT_SINK_DRIVER_B) &
- ~WM8350_CS1_ISEL_MASK;
- wm8350_reg_write(wm8350, WM8350_CURRENT_SINK_DRIVER_B,
-val | setting);
- break;
- default:
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int wm8350_isink_get_current(struct regulator_dev *rdev)
-{
- struct wm8350 *wm8350 = rdev_get_drvdata(rdev);
- int isink = rdev_get_id(rdev);
- u16 val;
-
- switch (isink) {
- case WM8350_ISINK_A:
- val = wm8350_reg_read(wm8350, WM8350_CURRENT_SINK_DRIVER_A) &
- WM8350_CS1_ISEL_MASK;
- break;
- case WM8350_ISINK_B:
- val = wm8350_reg_read(wm8350, WM8350_CURRENT_SINK_DRIVER_B) &
- WM8350_CS1_ISEL_MASK;
- break;
- default:
- return 0;
- }
-
- return isink_cur[val];
-}
-
/* turn on ISINK followed by DCDC */
static int wm8350_isink_enable(struct regulator_dev *rdev)
{
@@ -982,8 +915,8 @@ static const struct regulator_ops wm8350_ldo_ops = {
};
static const struct regulator_ops wm8350_isink_ops = {
- .set_current_limit = wm8350_isink_set_current,
- .get_current_limit = wm8350_isink_get_current,
+ .set_current_limit = regulator_set_current_limit_regmap,
+ .get_current_limit = regulator_get_current_limit_regmap,
.enable = wm8350_isink_enable,
.disable = wm8350_isink_disable,
.is_enabled = wm8350_isink_is_enabled,
@@ -1138,6 +1071,10 @@ static const struct regulator_desc
wm8350_reg[NUM_WM8350_REGULATORS] = {
.irq = WM8350_IRQ_CS1,
.type = REGULATOR_CURRENT,
.owner = THIS_MODULE,
+ .curr_table = isink_cur,
+ .n_current_limits = ARRAY_SIZE(isink_cur),
+ .csel_reg = WM8350_CURRENT_SINK_DRIVER_A,
+ .csel_mask = WM8350_CS1_ISEL_MASK,
},
{
.name = "ISINKB",
@@ -1146,6 +1083,10 @@ static const struct regulator_desc
wm8350_reg[NUM_WM8350_REGULATORS] = {
.irq = WM8350_IRQ_CS2,
.type = REGULATOR_CURRENT,
.owner = THIS_MODULE,
+ .curr_table = isink_cur,
+ .n_current_limits = ARRAY_SIZE(isink_cur),
+ .csel_reg = WM8350_CURRENT_SINK_DRIVER_B,
+ .csel_mask = WM8350_CS2_ISEL_MASK,
},
};
--
2.17.1
[PATCH 3/4] regulator: wm831x-isink: Convert to use regulator_set/get_current_limit_regmap
Use regulator_set/get_current_limit_regmap helpers to save some code.
Signed-off-by: Axel Lin
---
drivers/mfd/wm831x-core.c| 2 +-
drivers/regulator/wm831x-isink.c | 45 +---
include/linux/mfd/wm831x/regulator.h | 2 +-
3 files changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/mfd/wm831x-core.c b/drivers/mfd/wm831x-core.c
index 25fbbaf39cb9..21bae64e0451 100644
--- a/drivers/mfd/wm831x-core.c
+++ b/drivers/mfd/wm831x-core.c
@@ -34,7 +34,7 @@
/* Current settings - values are 2*2^(reg_val/4) microamps. These are
* exported since they are used by multiple drivers.
*/
-int wm831x_isinkv_values[WM831X_ISINK_MAX_ISEL + 1] = {
+const unsigned int wm831x_isinkv_values[WM831X_ISINK_MAX_ISEL + 1] = {
2,
2,
3,
diff --git a/drivers/regulator/wm831x-isink.c b/drivers/regulator/wm831x-isink.c
index 676a4701c986..c4bc3d3361aa 100644
--- a/drivers/regulator/wm831x-isink.c
+++ b/drivers/regulator/wm831x-isink.c
@@ -92,48 +92,12 @@ static int wm831x_isink_is_enabled(struct regulator_dev
*rdev)
return 0;
}
-static int wm831x_isink_set_current(struct regulator_dev *rdev,
- int min_uA, int max_uA)
-{
- struct wm831x_isink *isink = rdev_get_drvdata(rdev);
- struct wm831x *wm831x = isink->wm831x;
- int ret, i;
-
- for (i = ARRAY_SIZE(wm831x_isinkv_values) - 1; i >= 0; i--) {
- int val = wm831x_isinkv_values[i];
- if (min_uA <= val && val <= max_uA) {
- ret = wm831x_set_bits(wm831x, isink->reg,
- WM831X_CS1_ISEL_MASK, i);
- return ret;
- }
- }
-
- return -EINVAL;
-}
-
-static int wm831x_isink_get_current(struct regulator_dev *rdev)
-{
- struct wm831x_isink *isink = rdev_get_drvdata(rdev);
- struct wm831x *wm831x = isink->wm831x;
- int ret;
-
- ret = wm831x_reg_read(wm831x, isink->reg);
- if (ret < 0)
- return ret;
-
- ret &= WM831X_CS1_ISEL_MASK;
- if (ret > WM831X_ISINK_MAX_ISEL)
- ret = WM831X_ISINK_MAX_ISEL;
-
- return wm831x_isinkv_values[ret];
-}
-
static const struct regulator_ops wm831x_isink_ops = {
.is_enabled = wm831x_isink_is_enabled,
.enable = wm831x_isink_enable,
.disable = wm831x_isink_disable,
- .set_current_limit = wm831x_isink_set_current,
- .get_current_limit = wm831x_isink_get_current,
+ .set_current_limit = regulator_set_current_limit_regmap,
+ .get_current_limit = regulator_get_current_limit_regmap,
};
static irqreturn_t wm831x_isink_irq(int irq, void *data)
@@ -187,10 +151,15 @@ static int wm831x_isink_probe(struct platform_device
*pdev)
isink->desc.ops = _isink_ops;
isink->desc.type = REGULATOR_CURRENT;
isink->desc.owner = THIS_MODULE;
+ isink->desc.curr_table = wm831x_isinkv_values,
+ isink->desc.n_current_limits = ARRAY_SIZE(wm831x_isinkv_values),
+ isink->desc.csel_reg = isink->reg,
+ isink->desc.csel_mask = WM831X_CS1_ISEL_MASK,
config.dev = pdev->dev.parent;
config.init_data = pdata->isink[id];
config.driver_data = isink;
+ config.regmap = wm831x->regmap;
isink->regulator = devm_regulator_register(>dev, >desc,
);
diff --git a/include/linux/mfd/wm831x/regulator.h
b/include/linux/mfd/wm831x/regulator.h
index 955d30fc6a27..30c587a0624c 100644
--- a/include/linux/mfd/wm831x/regulator.h
+++ b/include/linux/mfd/wm831x/regulator.h
@@ -1213,6 +1213,6 @@
#define WM831X_LDO1_OK_WIDTH 1 /* LDO1_OK */
#define WM831X_ISINK_MAX_ISEL 55
-extern int wm831x_isinkv_values[WM831X_ISINK_MAX_ISEL + 1];
+extern const unsigned int wm831x_isinkv_values[WM831X_ISINK_MAX_ISEL + 1];
#endif
--
2.17.1
Re: [PATCH 1/8] drivers: tty: serial: 8250_bcm2835aux: use devm_platform_ioremap_resource()
On Tue, Mar 12, 2019 at 03:57:33PM +0100, Enrico Weigelt, metux IT consult wrote: > --- > drivers/tty/serial/8250/8250_bcm2835aux.c | 12 > 1 file changed, 4 insertions(+), 8 deletions(-) No changelog or signed-off-by, sorry, please fix up the series and resend. thanks, greg k-h
Re: [PATCH v8 1/2] dt-bindings: serial: Add compatible for Mediatek MT8183
On Tue, Mar 12, 2019 at 03:41:57PM +0100, Matthias Brugger wrote: > > > On 11/03/2019 09:54, Erin Lo wrote: > > This adds dt-binding documentation of uart for Mediatek MT8183 SoC > > Platform. > > > > Signed-off-by: Erin Lo > > Acked-by: Rob Herring > > --- > > Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt > > b/Documentation/devicetree/bindings/serial/mtk-uart.txt > > index 742cb47..bcfb131 100644 > > --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt > > +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt > > @@ -16,6 +16,7 @@ Required properties: > >* "mediatek,mt8127-uart" for MT8127 compatible UARTS > >* "mediatek,mt8135-uart" for MT8135 compatible UARTS > >* "mediatek,mt8173-uart" for MT8173 compatible UARTS > > + * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible > > UARTS > >* "mediatek,mt6577-uart" for MT6577 and all of the above > > > > - reg: The base address of the UART register bank. > > > > Acked-by: Matthias Brugger > > Greg will you take this through your branch or do you prefer me to queue it? I can take it, let's wait for 5.1-rc1 to come out first please. thanks, greg k-h
Re: [PATCH 0/2] L2 Cache EDAC Support for HiFive Unleashed
Hello Yash, On Tue, 12 Mar 2019, Yash Shah wrote: > This patch series adds a L2 Cache EDAC driver and DT documentation > for HiFive Unleashed board. This should also reference the "FU540-C000 chip" since there isn't anything board-specific about it. Also - could you please describe in your patch 0 message what kernel commit this driver has been tested on; or, if it's not a mainline commit, what additional patches are needed to test it? thanks, - Paul
Re: [PATCH 2/2] sifive: edac: Add EDAC driver for Sifive l2 Cache Controller
Hello Yash, On Tue, 12 Mar 2019, Yash Shah wrote: > Add driver for the SiFive L2 cache controller > on the HiFive Unleashed board This should read "for the SiFive FU540-C000 chip" or something similar. The L2 cache controller is not specific to the HiFive Unleashed board. Could you also please describe in your patch description: 1. what features this driver supports - in other words, why would it be used 2. and, if this driver was written based on any other drivers, please just briefly credit them. For example, the use of the "teardown_*" function names suggest that this driver is at least partially based on i10nm_base.c, skx_base.c, or pnd2_edac.c ? thanks, - Paul
Re: [PATCH v3] powerpc/pseries: Only wait for dying CPU after call to rtas_stop_self()
Gautham R Shenoy writes: >> Signed-off-by: Thiago Jung Bauermann > > Thanks for this version. I have tested the patch and we no longer see > the "Querying DEAD? cpu X (Y) shows 2" message. > > > Tested-and-Reviewed-by: Gautham R. Shenoy Thanks for reviewing and testing the patch! -- Thiago Jung Bauermann IBM Linux Technology Center
[PATCH v7 1/2] dt-bindings: misc: aspeed-p2a-ctrl: add support
Document the ast2400, ast2500 PCI-to-AHB bridge control driver bindings.
Signed-off-by: Patrick Venture
---
Changes for v7:
- Moved node under the syscon node it requires
Changes for v6:
- None
Changes for v5:
- None
Changes for v4:
- None
Changes for v3:
- None
Changes for v2:
- Added comment about syscon required parameter.
---
.../bindings/misc/aspeed-p2a-ctrl.txt | 48 +++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
new file mode 100644
index ..088cc4e3dc54
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
@@ -0,0 +1,48 @@
+==
+Device tree bindings for Aspeed AST2400/AST2500 PCI-to-AHB Bridge Control
Driver
+==
+
+The bridge is available on platforms with the VGA enabled on the Aspeed device.
+In this case, the host has access to a 64KiB window into all of the BMC's
+memory. The BMC can disable this bridge. If the bridge is enabled, the host
+has read access to all the regions of memory, however the host only has read
+and write access depending on a register controlled by the BMC.
+
+Required properties:
+===
+
+ - compatible: must be one of:
+ - "aspeed,ast2400-p2a-ctrl"
+ - "aspeed,ast2500-p2a-ctrl"
+
+ - syscon: handle to syscon device node controlling PCI.
+
+Optional properties:
+===
+
+- memory-region: A phandle to a reserved_memory region to be used for the PCI
+ to AHB mapping
+
+The p2a-control node should be the child of a syscon node with the required
+property:
+
+- compatible : Should be one of the following:
+ "aspeed,ast2400-scu", "syscon", "simple-mfd"
+ "aspeed,g4-scu", "syscon", "simple-mfd"
+ "aspeed,ast2500-scu", "syscon", "simple-mfd"
+ "aspeed,g5-scu", "syscon", "simple-mfd"
+
+Example:
+
+g4 Example
+--
+
+syscon: scu@1e6e2000 {
+ compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
+ reg = <0x1e6e2000 0x1a8>;
+
+ p2a: p2a-control {
+ compatible = "aspeed,ast2400-p2a-ctrl";
+ memory-region = <_memory>;
+ };
+};
--
2.21.0.360.g471c308f928-goog
[PATCH v7 2/2] drivers/misc: Add Aspeed P2A control driver
The ASPEED AST2400, and AST2500 in some configurations include a PCI-to-AHB MMIO bridge. This bridge allows a server to read and write in the BMC's physical address space. This feature is especially useful when using this bridge to send large files to the BMC. The host may use this to send down a firmware image by staging data at a specific memory address, and in a coordinated effort with the BMC's software stack and kernel, transmit the bytes. This driver enables the BMC to unlock the PCI bridge on demand, and configure it via ioctl to allow the host to write bytes to an agreed upon location. In the primary use-case, the region to use is known apriori on the BMC, and the host requests this information. Once this request is received, the BMC's software stack will enable the bridge and the region and then using some software flow control (possibly via IPMI packets), copy the bytes down. Once the process is complete, the BMC will disable the bridge and unset any region involved. The default behavior of this bridge when present is: enabled and all regions marked read-write. This driver will fix the regions to be read-only and then disable the bridge entirely. The memory regions protected are: * BMC flash MMIO window * System flash MMIO windows * SOC IO (peripheral MMIO) * DRAM The DRAM region itself is all of DRAM and cannot be further specified. Once the PCI bridge is enabled, the host can read all of DRAM, and if the DRAM section is write-enabled, then it can write to all of it. Signed-off-by: Patrick Venture --- Changes for v7: - Moved node under the syscon node and changed therefore how it grabs the phandle for the regmap. Changes for v6: - Cleaned up documentation - Added missing machine-readable copyright lines. - Fixed over 80 chars instances. - Changed error from invalid memory-region node to ENODEV. Changes for v5: - Fixup missing exit condition and remove extra jump. Changes for v4: - Added ioctl for reading back the memory-region configuration. - Cleaned up some unused variables. Changes for v3: - Deleted unused read and write methods. Changes for v2: - Dropped unused reads. - Moved call to disable bridge to before registering device. - Switch from using regs to using a syscon regmap. <<< IN PROGRESS - Updated the commit message. <<< TODO - Updated the bit flipped for SCU180_ENP2A - Dropped boolean region_specified variable. - Renamed p2a_ctrl in _probe to misc_ctrl per suggestion. - Renamed aspeed_p2a_region_search to aspeed_p2a_region_acquire - Updated commit message. --- drivers/misc/Kconfig | 8 + drivers/misc/Makefile| 1 + drivers/misc/aspeed-p2a-ctrl.c | 440 +++ include/uapi/linux/aspeed-p2a-ctrl.h | 62 4 files changed, 511 insertions(+) create mode 100644 drivers/misc/aspeed-p2a-ctrl.c create mode 100644 include/uapi/linux/aspeed-p2a-ctrl.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index f417b06e11c5..9de1bafe5606 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -485,6 +485,14 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config ASPEED_P2A_CTRL + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON + tristate "Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC bridge control" + help + Control Aspeed ast2400/2500 HOST P2A VGA MMIO to BMC mappings through + ioctl()s, the driver also provides an interface for userspace mappings to + a pre-defined region. + config ASPEED_LPC_CTRL depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index e39ccbbc1b3a..57577aee354f 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -55,6 +55,7 @@ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o obj-$(CONFIG_CXL_BASE) += cxl/ obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o +obj-$(CONFIG_ASPEED_P2A_CTRL) += aspeed-p2a-ctrl.o obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o obj-$(CONFIG_OCXL) += ocxl/ obj-y += cardreader/ diff --git a/drivers/misc/aspeed-p2a-ctrl.c b/drivers/misc/aspeed-p2a-ctrl.c new file mode 100644 index ..9b9f831ef334 --- /dev/null +++ b/drivers/misc/aspeed-p2a-ctrl.c @@ -0,0 +1,440 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2019 Google Inc + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Provides a simple driver to control the ASPEED P2A interface which allows + * the host to read and
Re: [PATCH] mm: compaction: some tracepoints should be defined only when CONFIG_COMPACTION is set
On Wed, Mar 13, 2019 at 12:18 AM Michal Hocko wrote:
>
> On Sat 02-03-19 12:38:58, Yafang Shao wrote:
> > Only mm_compaction_isolate_{free, migrate}pages may be used when
> > CONFIG_COMPACTION is not set.
> > All others are used only when CONFIG_COMPACTION is set.
>
> Why is this an improvement?
>
After this change, if CONFIG_COMPACTION is not set, the tracepoints
that only work when CONFIG_COMPACTION is set will not be exposed to
the usespace.
Without this change, they will always be expose in debugfs no matter
CONFIG_COMPACTION is set or not.
That's an improvement.
> > Signed-off-by: Yafang Shao
> > ---
> > include/trace/events/compaction.h | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/trace/events/compaction.h
> > b/include/trace/events/compaction.h
> > index 6074eff..3e42078 100644
> > --- a/include/trace/events/compaction.h
> > +++ b/include/trace/events/compaction.h
> > @@ -64,6 +64,7 @@
> > TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
> > );
> >
> > +#ifdef CONFIG_COMPACTION
> > TRACE_EVENT(mm_compaction_migratepages,
> >
> > TP_PROTO(unsigned long nr_all,
> > @@ -132,7 +133,6 @@
> > __entry->sync ? "sync" : "async")
> > );
> >
> > -#ifdef CONFIG_COMPACTION
> > TRACE_EVENT(mm_compaction_end,
> > TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
> > unsigned long free_pfn, unsigned long zone_end, bool sync,
> > @@ -166,7 +166,6 @@
> > __entry->sync ? "sync" : "async",
> > __print_symbolic(__entry->status, COMPACTION_STATUS))
> > );
> > -#endif
> >
> > TRACE_EVENT(mm_compaction_try_to_compact_pages,
> >
> > @@ -195,7 +194,6 @@
> > __entry->prio)
> > );
> >
> > -#ifdef CONFIG_COMPACTION
> > DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
> >
> > TP_PROTO(struct zone *zone,
> > @@ -296,7 +294,6 @@
> >
> > TP_ARGS(zone, order)
> > );
> > -#endif
> >
> > TRACE_EVENT(mm_compaction_kcompactd_sleep,
> >
> > @@ -352,6 +349,7 @@
> >
> > TP_ARGS(nid, order, classzone_idx)
> > );
> > +#endif
> >
> > #endif /* _TRACE_COMPACTION_H */
> >
> > --
> > 1.8.3.1
> >
>
> --
> Michal Hocko
> SUSE Labs
Re: [PATCH v3 1/2] Bluetooth: hci_qca: Added support for wcn3998
Hi Harish,
On Tue, Mar 12, 2019 at 05:52:58PM +0530, Harish Bandi wrote:
> Added new compatible for wcn3998 and corresponding voltage
> and current values to wcn3998 compatible.
> Changed driver code to support wcn3998
>
> Signed-off-by: Harish Bandi
> ---
> changes in v3:
> - updated to latest code base.
This is not useful, for future versions please describe what changed
(e.g. 'specify regulator constraints in the driver instead of the DT')
> ---
> drivers/bluetooth/btqca.c | 4 ++--
> drivers/bluetooth/btqca.h | 3 ++-
> drivers/bluetooth/hci_qca.c | 40 ++--
> 3 files changed, 30 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index 6122685..70cab13 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -344,7 +344,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>
> /* Download rampatch file */
> config.type = TLV_TYPE_PATCH;
> - if (soc_type == QCA_WCN3990) {
> + if (soc_type >= QCA_WCN3990) {
That works, but isn't super-clear and might need to be adapted when
future non-WCN399x controllers are added.
Some possible alternatives:
- is_wcn399x(soc_type)
- have a family (Rome, Cherokee (IIRC this name was used for WCN3990))
and a chip id (QCA6174, WCN3990, WCN3998, ...)
> /* Firmware files to download are based on ROM version.
>* ROM version is derived from last two bytes of soc_ver.
>*/
> @@ -365,7 +365,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>
> /* Download NVM configuration */
> config.type = TLV_TYPE_NVM;
> - if (soc_type == QCA_WCN3990)
> + if (soc_type >= QCA_WCN3990)
> snprintf(config.fwname, sizeof(config.fwname),
>"qca/crnv%02x.bin", rom_ver);
> else
> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> index c72c56e..f03d96e 100644
> --- a/drivers/bluetooth/btqca.h
> +++ b/drivers/bluetooth/btqca.h
> @@ -132,7 +132,8 @@ enum qca_btsoc_type {
> QCA_INVALID = -1,
> QCA_AR3002,
> QCA_ROME,
> - QCA_WCN3990
> + QCA_WCN3990,
> + QCA_WCN3998
nit: if you add a comma after the last value the line doesn't need to
be changed when a new type is added in the future.
Is 'WCN3998' specific enough? You mentioned earlier that there are
multiple WCN3998 variants with different requirements for regulator
voltages/max currents. Which names does Qualcomm use to distinguish
between them (e.g. WCN3998-A, WCN3998-B, ...)?
Thanks
Matthias
Re: [PATCH] mm/slab: protect cache_reap() against CPU and memory hot plug operations
Le 12/03/2019 à 15:58, Michal Hocko a écrit :
On Mon 11-03-19 20:17:01, Laurent Dufour wrote:
The commit 95402b382901 ("cpu-hotplug: replace per-subsystem mutexes with
get_online_cpus()") remove the CPU_LOCK_ACQUIRE operation which was use to
grap the cache_chain_mutex lock which was protecting cache_reap() against
CPU hot plug operations.
Later the commit 18004c5d4084 ("mm, sl[aou]b: Use a common mutex
definition") changed cache_chain_mutex to slab_mutex but this didn't help
fixing the missing the cache_reap() protection against CPU hot plug
operations.
Here we are stopping the per cpu worker while holding the slab_mutex to
ensure that cache_reap() is not running in our back and will not be
triggered anymore for this cpu.
This patch fixes that race leading to SLAB's data corruption when CPU
hotplug are triggered. We hit it while doing partition migration on PowerVM
leading to CPU reconfiguration through the CPU hotplug mechanism.
What is the actual race? slab_offline_cpu calls cancel_delayed_work_sync
so it removes a pending item and waits for the item to finish if they run
concurently. So why do we need an additional lock?
You're right.
Reading cancel_delayed_work_sync() again I can't see how this could help.
The tests done with that patch were successful, while we were seeing a
SLAB data corruption without it, but this needs to be investigated
further since this one should not help. This was perhaps a lucky side
effect.
Please forgot about this one.
This fix is covering kernel containing to the commit 6731d4f12315 ("slab:
Convert to hotplug state machine"), ie 4.9.1, earlier kernel needs a
slightly different patch.
Cc: sta...@vger.kernel.org
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Signed-off-by: Laurent Dufour
---
mm/slab.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/slab.c b/mm/slab.c
index 28652e4218e0..ba499d90f27f 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1103,6 +1103,7 @@ static int slab_online_cpu(unsigned int cpu)
static int slab_offline_cpu(unsigned int cpu)
{
+ mutex_lock(_mutex);
/*
* Shutdown cache reaper. Note that the slab_mutex is held so
* that if cache_reap() is invoked it cannot do anything
@@ -1112,6 +1113,7 @@ static int slab_offline_cpu(unsigned int cpu)
cancel_delayed_work_sync(_cpu(slab_reap_work, cpu));
/* Now the cache_reaper is guaranteed to be not running. */
per_cpu(slab_reap_work, cpu).work.func = NULL;
+ mutex_unlock(_mutex);
return 0;
}
--
2.21.0
Re: [PATCH] mm: compaction: some tracepoints should be defined only when CONFIG_COMPACTION is set
On Sat 02-03-19 12:38:58, Yafang Shao wrote:
> Only mm_compaction_isolate_{free, migrate}pages may be used when
> CONFIG_COMPACTION is not set.
> All others are used only when CONFIG_COMPACTION is set.
Why is this an improvement?
> Signed-off-by: Yafang Shao
> ---
> include/trace/events/compaction.h | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/include/trace/events/compaction.h
> b/include/trace/events/compaction.h
> index 6074eff..3e42078 100644
> --- a/include/trace/events/compaction.h
> +++ b/include/trace/events/compaction.h
> @@ -64,6 +64,7 @@
> TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
> );
>
> +#ifdef CONFIG_COMPACTION
> TRACE_EVENT(mm_compaction_migratepages,
>
> TP_PROTO(unsigned long nr_all,
> @@ -132,7 +133,6 @@
> __entry->sync ? "sync" : "async")
> );
>
> -#ifdef CONFIG_COMPACTION
> TRACE_EVENT(mm_compaction_end,
> TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
> unsigned long free_pfn, unsigned long zone_end, bool sync,
> @@ -166,7 +166,6 @@
> __entry->sync ? "sync" : "async",
> __print_symbolic(__entry->status, COMPACTION_STATUS))
> );
> -#endif
>
> TRACE_EVENT(mm_compaction_try_to_compact_pages,
>
> @@ -195,7 +194,6 @@
> __entry->prio)
> );
>
> -#ifdef CONFIG_COMPACTION
> DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
>
> TP_PROTO(struct zone *zone,
> @@ -296,7 +294,6 @@
>
> TP_ARGS(zone, order)
> );
> -#endif
>
> TRACE_EVENT(mm_compaction_kcompactd_sleep,
>
> @@ -352,6 +349,7 @@
>
> TP_ARGS(nid, order, classzone_idx)
> );
> +#endif
>
> #endif /* _TRACE_COMPACTION_H */
>
> --
> 1.8.3.1
>
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm: compaction: show gfp flag names in try_to_compact_pages tracepoint
On Sat 02-03-19 12:38:57, Yafang Shao wrote:
> show the gfp flag names instead of the gfp_mask could make the trace
> more convenient.
Agreed
> Signed-off-by: Yafang Shao
Acked-by: Michal Hocko
> ---
> include/trace/events/compaction.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/compaction.h
> b/include/trace/events/compaction.h
> index 6074eff..e66afb818 100644
> --- a/include/trace/events/compaction.h
> +++ b/include/trace/events/compaction.h
> @@ -189,9 +189,9 @@
> __entry->prio = prio;
> ),
>
> - TP_printk("order=%d gfp_mask=0x%x priority=%d",
> + TP_printk("order=%d gfp_mask=%s priority=%d",
> __entry->order,
> - __entry->gfp_mask,
> + show_gfp_flags(__entry->gfp_mask),
> __entry->prio)
> );
>
> --
> 1.8.3.1
>
--
Michal Hocko
SUSE Labs
Re: nbd, nbdkit, loopback mounts and memory management
We have a good example of deadlock when using an XFS filesystem on an nbd loopback device regardless of mlockall and MCL_FUTURE. Below I'll paste the hung task traces but I'll try to summarize the steps that caused the problem. The setup is an nbd loopback device with an XFS filesystem that is then mounted on the local server (ubuntu 18.04 bionic, kernel 4.15). Heavy load on the server is putting the kernel in a state where it has exhausted its free pages list and new page allocation requests will attempt to first free allocated pages -- mm/vmscan.c try_to_free_pages(). XFS registers a pair of functions in the super_operations struct (nr_cached_objects and free_cached_objects) that causes the try_to_free_pages() to perform a synchronous write of dirty inodes to the block device -- fs/xfs/xfs_icache.c xfs_reclaim_inodes_nr(). A resource loop deadlock can occur if the nbd userland process needs to allocate memory to make forward progress and the allocation causes the kernel to call try_to_free_pages() which then leads to XFS issuing a blocking synchronous write of a dirty inode page destined back to the nbd loopback device. A more common deadlock we see (traces below) is when another process on the system is blocked in try_to_free_pages() waiting for the nbd device to perform the synchronous write and then the nbd userland process also triggers try_to_free_pages() and blocks on a mutex waiting for the first process to complete its synchronous write. >From a kernel implemented device driver, which pages should not be freed during a page allocation can be controlled using the GFP_ flags. (GFP_NOIO, GFP_NOFS). From userland (as far as I can tell) we do not have a way to control which pages the kernel is allowed to free in try_to_free_pages(). Below are some traces where we have hit this deadlock. 0) A process on the server needs to allocate a page and triggers the kernel to attempt to free pages and XFS issues a synchronous write to the nbd loopback device; 1) within the nbd loopback userland process, a memory allocation request triggers a malloc arena pool to expand its heap and call mprotect which causes the kernel to try to allocate pages and call try_to_free_pages(), and proceed down the XFS reclaim inodes path where it blocks trying to acquire the mutex that is held by that process from trace 0 waiting for us to make progress; 2) an example of another thread within the nbd userland process hitting the same problem when attempting to write to a tcp socket and also blocking on the XFS reclaim inodes mutex. So far the problem has been avoided by using ext4 instead of XFS as ext4 does not provide the super_operations struct functions (nr_cached_objects, free_cached_objects) and does not issue writes in the try_to_free_pages() code path. Ideally, the nbd userland process could set a process flag to tell the kernel to use GFP_NOIO or GFP_NOFS for its allocations to avoid this resource deadlock. Kernel hung tasks 0) A process somewhere on the server has triggered a syscall that causes the kernel to attempt to free pages and eventually call xfs_reclaim_inodes, acquire xfs inode reclaim mutex, and wait for a write to the nbd loopback device Mar 06 04:54:14 ip-172-16-9-203 kernel: INFO: task glfs_epoll000:4535 blocked for more than 30 seconds. Mar 06 04:54:14 ip-172-16-9-203 kernel: Not tainted 4.15.0-1032-aws #34-Ubuntu Mar 06 04:54:14 ip-172-16-9-203 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Mar 06 04:54:14 ip-172-16-9-203 kernel: glfs_epoll000 D0 4535 1 0x Mar 06 04:54:14 ip-172-16-9-203 kernel: Call Trace: Mar 06 04:54:14 ip-172-16-9-203 kernel: __schedule+0x291/0x8a0 Mar 06 04:54:14 ip-172-16-9-203 kernel: schedule+0x2c/0x80 Mar 06 04:54:14 ip-172-16-9-203 kernel: schedule_timeout+0x1cf/0x350 Mar 06 04:54:14 ip-172-16-9-203 kernel: ? _xfs_buf_ioapply+0x396/0x4e0 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: ? radix_tree_gang_lookup+0xc6/0x110 Mar 06 04:54:14 ip-172-16-9-203 kernel: wait_for_completion+0xba/0x140 Mar 06 04:54:14 ip-172-16-9-203 kernel: ? wake_up_q+0x80/0x80 Mar 06 04:54:14 ip-172-16-9-203 kernel: ? xfs_bwrite+0x24/0x60 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: xfs_buf_submit_wait+0x81/0x210 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: xfs_bwrite+0x24/0x60 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: xfs_reclaim_inode+0x31d/0x350 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: xfs_reclaim_inodes_ag+0x1e6/0x350 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: ? radix_tree_gang_lookup_tag+0xd9/0x160 Mar 06 04:54:14 ip-172-16-9-203 kernel: ? __list_lru_walk_one.isra.5+0x37/0x140 Mar 06 04:54:14 ip-172-16-9-203 kernel: ? iput+0x220/0x220 Mar 06 04:54:14 ip-172-16-9-203 kernel: xfs_reclaim_inodes_nr+0x33/0x40 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: xfs_fs_free_cached_objects+0x19/0x20 [xfs] Mar 06 04:54:14 ip-172-16-9-203 kernel: super_cache_scan+0x165/0x1b0 Mar 06 04:54:14 ip-172-16-9-203 kernel:
Re: [PATCH v2 1/4] dt-bindings: Add vendor prefix for MaxBotix
On Fri, 1 Mar 2019 14:41:57 +0100, Andreas Klinger wrote: > Add MaxBotix, which is a vendor of ultrasonic rangers in different > varieties and interfaces. > > Signed-off-by: Andreas Klinger > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring
Re: [PATCH v2 mailbox 2/3] dt-bindings: mailbox: Document armada-37xx-rwtm-mailbox binding
On Fri, 1 Mar 2019 05:23:40 +0100, =?UTF-8?q?Marek=20Beh=C3=BAn?= wrote: > This adds device tree binding documentation for the rWTM BIU mailbox > driver on the Armada 37xx SOC (EspressoBin, Turris Mox). > > Signed-off-by: Marek Behún > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > --- > .../mailbox/armada-37xx-rwtm-mailbox.txt | 16 > 1 file changed, 16 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt > Reviewed-by: Rob Herring
HELLO DEAR
Hello Dear, Please forgive me for stressing you with my predicaments as I know that this letter may come to you as big surprise. Actually, I came across your E-mail from my personal search afterward I decided to email you directly believing that you will be honest to fulfill my final wish before i die. Meanwhile, I am Mrs. Louisa Benson, 62 years old, from America, and I am suffering from a long time cancer and from all indication my condition is really deteriorating as my doctors have confirmed and courageously advised me that I may not live beyond twomonths from now for the reason that my tumor has reached a critical stage which has defiled all forms of medical treatment. As a matter of fact, registered nurse by profession while my husband was dealing on Gold Dust and Gold Dory Bars in Burkina Faso till his sudden death the year 2008 then I took over his business till date. In fact, at this moment I have a deposit sum of eight million five hundred thousand US dollars [$8,500,000.00] with one of the leading bank in Burkina Faso but unfortunately I cannot visit the bank since I m critically sick and powerless to do anything myself but my bank account officer advised me to assign any of my trustworthy relative, friends or partner with authorization letter to stand as the recipient of my money but sorrowfully I don t have any reliable relative and no child. Therefore, I want you to receive the money and take 30% to take care of yourself and family while 70% should be use basically on humanitarian purposes mostly to orphanages home, Motherless babies home, less privileged and disable citizens and widows around the world. and as soon as I receive your I shall send you my pictures, banking records and with full contacts of my banking institution to If you are interested in carrying out this task please contact me for more details on this. mrslouisabenson2...@mail.com Hope to hear from you soon. Yours Faithfully, Mrs. Louisa Benson
Re: [PATCH v2 1/6] dt-bindings: nvmem: Add STM32 factory-programmed romem
On Thu, 28 Feb 2019 11:19:51 +0100, Fabrice Gasnier wrote: > Add documentation for STMicroelectronics STM32 Factory-programmed > read only memory area. > > Signed-off-by: Fabrice Gasnier > --- > Changes in v2: > - update "st,stm32f4-otp" compatible as discussed with Rob > --- > .../devicetree/bindings/nvmem/st,stm32-romem.txt | 31 > ++ > 1 file changed, 31 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt > Reviewed-by: Rob Herring
[PATCH v5 3/3] arm64: dts: Add USB DT nodes for Stingray SoC
Add DT nodes for
- Two xHCI host controllers
- Two BDC Broadcom USB device controller
- Five USB PHY controllers
[xHCI0] [BDC0][xHCI1][BDC1]
| | | |
--- ---
| | | | |
[SS-PHY0] [HS-PHY0][SS-PHY1] [HS-PHY2] [HS-PHY1]
[SS-PHY0/HS-PHY0] and [SS-PHY1/HS-PHY1] are combo PHYs has one SS and
one HS PHYs. [HS-PHY2] is a single HS PHY.
xHCI use SS-PHY to detect SS devices and HS-PHY to detect HS/FS/LS
devices. BDC use SS-PHY in SS mode and HS-PHY in HS mode.
xHCI0 port1 is SS-PHY0, port2 is HS-PHY0.
xHCI1 port1 is SS-PHY1, port2 is HS-PHY2 and port3 is HS-PHY1.
Signed-off-by: Srinath Mannam
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 78 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
2 files changed, 79 insertions(+)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
new file mode 100644
index 000..a5d3354
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *Copyright(c) 2018 Broadcom
+ */
+ usb {
+ compatible = "simple-bus";
+ dma-ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x6850 0x0040>;
+
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ xhci0: usb@1000 {
+ compatible = "generic-xhci";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ phys = < 1>, < 0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc0: usb@2000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ phys = < 0>, < 1>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ xhci1: usb@11000 {
+ compatible = "generic-xhci";
+ reg = <0x00011000 0x1000>;
+ interrupts = ;
+ phys = < 1>, <>, < 0>;
+ phy-names = "phy0", "phy1", "phy2";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc1: usb@21000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x00021000 0x1000>;
+ interrupts = ;
+ phys = <>;
+ phy-names = "phy0";
+ dma-coherent;
+ status = "disabled";
+ };
+ };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index cfeaa85..21dbb12 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -287,6 +287,7 @@
#include "stingray-fs4.dtsi"
#include "stingray-sata.dtsi"
#include "stingray-pcie.dtsi"
+ #include "stingray-usb.dtsi"
hsls {
compatible = "simple-bus";
--
2.7.4
[PATCH v5 2/3] phy: sr-usb: Add Stingray USB PHY driver
USB PHY driver supports two types of stingray USB PHYs
- Type 1 is a combo PHY contains two PHYs, one SS and one HS.
- Type 2 is a single HS PHY.
These two PHY versons support both Generic xHCI host controller driver
and BDC Broadcom device controller driver.
Signed-off-by: Srinath Mannam
---
drivers/phy/broadcom/Kconfig | 11 +
drivers/phy/broadcom/Makefile | 1 +
drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 ++
3 files changed, 405 insertions(+)
create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index aa917a6..f30f481 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_BCM_SR_USB
+ tristate "Broadcom Stingray USB PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Stingray USB PHY
+ driver. It supports all versions of Superspeed and
+ Highspeed PHYs.
+ If unsure, say N.
+
config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
index 0f60184..f453c7d 100644
--- a/drivers/phy/broadcom/Makefile
+++ b/drivers/phy/broadcom/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)+= phy-brcm-usb-dvr.o
phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
obj-$(CONFIG_PHY_BCM_SR_PCIE) += phy-bcm-sr-pcie.o
+obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
b/drivers/phy/broadcom/phy-bcm-sr-usb.c
new file mode 100644
index 000..bfe8237
--- /dev/null
+++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
@@ -0,0 +1,393 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum bcm_usb_phy_version {
+ BCM_SR_USB_COMBO_PHY,
+ BCM_SR_USB_HS_PHY,
+};
+
+enum bcm_usb_phy_reg {
+ PLL_NDIV_FRAC,
+ PLL_NDIV_INT,
+ PLL_CTRL,
+ PHY_CTRL,
+ PHY_PLL_CTRL,
+};
+
+/* USB PHY registers */
+
+static const u8 bcm_usb_combo_phy_ss[] = {
+ [PLL_CTRL] = 0x18,
+ [PHY_CTRL] = 0x14,
+};
+
+static const u8 bcm_usb_combo_phy_hs[] = {
+ [PLL_NDIV_FRAC] = 0x04,
+ [PLL_NDIV_INT] = 0x08,
+ [PLL_CTRL] = 0x0c,
+ [PHY_CTRL] = 0x10,
+};
+
+#define HSPLL_NDIV_INT_VAL 0x13
+#define HSPLL_NDIV_FRAC_VAL0x1005
+
+static const u8 bcm_usb_hs_phy[] = {
+ [PLL_NDIV_FRAC] = 0x0,
+ [PLL_NDIV_INT] = 0x4,
+ [PLL_CTRL] = 0x8,
+ [PHY_CTRL] = 0xc,
+};
+
+enum pll_ctrl_bits {
+ PLL_RESETB,
+ SSPLL_SUSPEND_EN,
+ PLL_SEQ_START,
+ PLL_LOCK,
+ PLL_PDIV,
+};
+
+static const u8 u3pll_ctrl[] = {
+ [PLL_RESETB]= 0,
+ [SSPLL_SUSPEND_EN] = 1,
+ [PLL_SEQ_START] = 2,
+ [PLL_LOCK] = 3,
+};
+
+#define HSPLL_PDIV_MASK0xF
+#define HSPLL_PDIV_VAL 0x1
+
+static const u8 u2pll_ctrl[] = {
+ [PLL_PDIV] = 1,
+ [PLL_RESETB]= 5,
+ [PLL_LOCK] = 6,
+};
+
+enum bcm_usb_phy_ctrl_bits {
+ CORERDY,
+ AFE_LDO_PWRDWNB,
+ AFE_PLL_PWRDWNB,
+ AFE_BG_PWRDWNB,
+ PHY_ISO,
+ PHY_RESETB,
+ PHY_PCTL,
+};
+
+#define PHY_PCTL_MASK 0x
+/*
+ * 0x0806 of PCTL_VAL has below bits set
+ * BIT-8 : refclk divider 1
+ * BIT-3:2: device mode; mode is not effect
+ * BIT-1: soft reset active low
+ */
+#define HSPHY_PCTL_VAL 0x0806
+#define SSPHY_PCTL_VAL 0x0006
+
+static const u8 u3phy_ctrl[] = {
+ [PHY_RESETB]= 1,
+ [PHY_PCTL] = 2,
+};
+
+static const u8 u2phy_ctrl[] = {
+ [CORERDY] = 0,
+ [AFE_LDO_PWRDWNB] = 1,
+ [AFE_PLL_PWRDWNB] = 2,
+ [AFE_BG_PWRDWNB]= 3,
+ [PHY_ISO] = 4,
+ [PHY_RESETB]= 5,
+ [PHY_PCTL] = 6,
+};
+
+struct bcm_usb_phy_cfg {
+ uint32_t type;
+ uint32_t version;
+ void __iomem *regs;
+ struct phy *phy;
+ const u8 *offset;
+};
+
+#define PLL_LOCK_RETRY_COUNT 1000
+
+enum bcm_usb_phy_type {
+ USB_HS_PHY,
+ USB_SS_PHY,
+};
+
+#define NUM_BCM_SR_USB_COMBO_PHYS 2
+
+static inline void bcm_usb_reg32_clrbits(void __iomem *addr, uint32_t clear)
+{
+ writel(readl(addr) & ~clear, addr);
+}
+
+static inline void bcm_usb_reg32_setbits(void __iomem *addr, uint32_t set)
+{
+ writel(readl(addr) | set, addr);
+}
+
+static int bcm_usb_pll_lock_check(void __iomem *addr, u32 bit)
+{
+ int retry;
+
[PATCH v5 0/3] Stingray USB PHY driver support
These patches add Stingray USB PHY driver and its corresponding DT nodes with documentation. This patch set is based on Linux-5.0-rc2. Changes from v4: - Addressed Rob Herring review comments - Removed child nodes and added #phy-cells 1 - Added xlate function to get phy using phandle argument. Changes from v3: - Addressed Rob Herring review comments - Changed compatible strings. - updated driver based on new compatible strings. Changes from v2: - Addressed Kishon review comments - Updated patchset to Linux-5.0-rc2 Changes from v1: - Addressed Kishon review comments - phy init call return value handle Srinath Mannam (3): dt-bindings: phy: Add Stingray USB PHY binding document phy: sr-usb: Add Stingray USB PHY driver arm64: dts: Add USB DT nodes for Stingray SoC .../bindings/phy/brcm,stingray-usb-phy.txt | 40 +++ .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 78 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + drivers/phy/broadcom/Kconfig | 11 + drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 + 6 files changed, 524 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c -- 2.7.4
[PATCH v5 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Add DT binding document for Stingray USB PHY.
Signed-off-by: Srinath Mannam
---
.../bindings/phy/brcm,stingray-usb-phy.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
new file mode 100644
index 000..51c3d73
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
@@ -0,0 +1,40 @@
+Broadcom Stingray USB PHY
+
+Required properties:
+ - compatible : should be one of the listed compatibles
+ - "brcm,sr-usb-combo-phy" is combo PHY has two PHYs, one SS and one HS.
+ - "brcm,sr-usb-hs-phy" is a single HS PHY.
+ - reg: offset and length of the PHY blocks registers
+ - address-cells: should be 1
+ - size-cells: should be 0
+ - #phy-cells:
+ - Must be 1 for brcm,sr-usb-combo-phy as it expects one argument to indicate
+ the PHY number of two PHYs. 0 for HS PHY and 1 for SS PHY.
+ - Must be 0 for brcm,sr-usb-hs-phy.
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ };
--
2.7.4
Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem
On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote: > > On Mon, Mar 11, 2019 at 08:13:53PM -0700, Dan Williams wrote: > > On Thu, Mar 7, 2019 at 10:56 AM Jerome Glisse wrote: > > > > > > On Thu, Mar 07, 2019 at 09:46:54AM -0800, Andrew Morton wrote: > > > > On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams > > > > wrote: > > > > > > > > > My hesitation would be drastically reduced if there was a plan to > > > > > avoid dangling unconsumed symbols and functionality. Specifically one > > > > > or more of the following suggestions: > > > > > > > > > > * EXPORT_SYMBOL_GPL on all exports to avoid a growing liability > > > > > surface for out-of-tree consumers to come grumble at us when we > > > > > continue to refactor the kernel as we are wont to do. > > > > > > > > The existing patches use EXPORT_SYMBOL() so that's a sticking point. > > > > Jerome, what would happen is we made these EXPORT_SYMBOL_GPL()? > > > > > > So Dan argue that GPL export solve the problem of out of tree user and > > > my personnal experience is that it does not. The GPU sub-system has tons > > > of GPL drivers that are not upstream and we never felt that we were bound > > > to support them in anyway. We always were very clear that if you are not > > > upstream that you do not have any voice on changes we do. > > > > > > So my exeperience is that GPL does not help here. It is just about being > > > clear and ignoring anyone who does not have an upstream driver ie we have > > > free hands to update HMM in anyway as long as we keep supporting the > > > upstream user. > > > > > > That being said if the GPL aspect is that much important to some then > > > fine let switch all HMM symbol to GPL. > > > > I should add that I would not be opposed to moving symbols to > > non-GPL-only over time, but that should be based on our experience > > with the stability and utility of the implementation. For brand new > > symbols there's just no data to argue that we can / should keep the > > interface stable, or that the interface exposes something fragile that > > we'd rather not export at all. That experience gathering and thrash is > > best constrained to upstream GPL-only drivers that are signing up to > > participate in that maturation process. > > > > So I think it is important from a practical perspective and is a lower > > risk way to run this HMM experiment of "merge infrastructure way in > > advance of an upstream user". > > > > > > > * A commitment to consume newly exported symbols in the same merge > > > > > window, or the following merge window. When that goal is missed revert > > > > > the functionality until such time that it can be consumed, or > > > > > otherwise abandoned. > > > > > > > > It sounds like we can tick this box. > > > > > > I wouldn't be too strick either, when adding something in release N > > > the driver change in N+1 can miss N+1 because of bug or regression > > > and be push to N+2. > > > > > > I think a better stance here is that if we do not get any sign-off > > > on the feature from driver maintainer for which the feature is intended > > > then we just do not merge. > > > > Agree, no driver maintainer sign-off then no merge. > > > > > If after few release we still can not get > > > the driver to use it then we revert. > > > > As long as it is made clear to the driver maintainer that they have > > one cycle to consume it then we can have a conversation if it is too > > early to merge the infrastructure. If no one has time to consume the > > feature, why rush dead code into the kernel? Also, waiting 2 cycles > > means the infrastructure that was hard to review without a user is now > > even harder to review because any review momentum has been lost by the > > time the user show up, so we're better off keeping them close together > > in time. > > Miss-understanding here, in first post the infrastructure and the driver > bit get posted just like have been doing lately. So that you know that > you have working user with the feature and what is left is pushing the > driver bits throught the appropriate tree. So driver maintainer support > is about knowing that they want the feature and have some confidence > that it looks ready. > > It also means you can review the infrastructure along side user of it. Sounds good. > > > It just feels dumb to revert at N+1 just to get it back in N+2 as > > > the driver bit get fix. > > > > No, I think it just means the infrastructure went in too early if a > > driver can't consume it in a development cycle. Lets revisit if it > > becomes a problem in practice. > > Well that's just dumb to have hard guideline like that. Many things > can lead to missing deadline. For instance bug i am refering too might > have nothing to do with the feature, it can be something related to > integrating the feature an unforseen side effect. So i believe a better > guideline is that driver maintainer rejecting the feature rather than > just failure to meet one deadline. The history of the Linux kernel
Re: [PATCH] platform/chrome: Add Wilco EC keyboard backlight LEDs support
> > > Some Wilco devices do not support a keyboard backlight. This > > > is checked in probe(), and in this case the sysfs entry will > > > not appear, and everything will behave normally. > > > > It would be even better if we did not register platform device if EC > > does not support backlight. Good point Dmitry. I would imagine this would entail exposing the keyboard_leds_exist() function. What is the best practice for doing that? I could either imagine EXPORT_SYMBOL_GPL()ing that function, but that would require making the core driver dependent upon this keyboard backlight driver in a circular dependency, so there would have to be some refactoring. The other option I see would be to add this entire driver to the core module. Just so I learn something, I don't see performance or stability concerns with adding one unused platform device, is your rationale that it would just be cleaner code? > > > > > + data->led.brightness_set = keyboard_led_set_brightness; > > > + data->led.brightness_get = keyboard_led_get_brightness; > > > > wilco_ec_mailbox() may sleep, so you need to assign it to > > led.brightness_set_blocking. Yes, thanks for the catch. > > Hmm. Seeing get method there... can the EC change the brightness > without command from kernel? No, the EC will never do that, good point. Therefore it looks like I can just remove the get_brightness() function and the core library will do the right thing. Thanks, Nick
Re: [PATCHv2 2/5] Documentation: dt: edac: Add Stratix10 Peripheral bindings
On Wed, Feb 27, 2019 at 11:27:22AM -0600, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> Add peripheral bindings for Stratix10 EDAC to capture
> the differences between the ARM64 and ARM32 architecture.
What's the difference? Sounds like 2 different chips, so Stratix10 or
s10 is not specific enough perhaps.
>
> Signed-off-by: Thor Thayer
> ---
> v2 No change
> ---
> .../devicetree/bindings/edac/socfpga-eccmgr.txt| 106
> +
> 1 file changed, 106 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> index a0ac50e15912..a0fa80c53d2a 100644
> --- a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> +++ b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> @@ -258,6 +258,49 @@ Required Properties:
> - compatible : Should be "altr,sdram-edac-s10"
> - interrupts : Should be single bit error interrupt.
>
> +On-Chip RAM ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-s10-ocram-ecc"
> +- reg : Address and size for ECC block registers.
> +- altr,ecc-parent : phandle to parent OCRAM node.
> +- interrupts : Should be single bit error interrupt.
> +
> +Ethernet FIFO ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-s10-eth-mac-ecc"
> +- reg : Address and size for ECC block registers.
> +- altr,ecc-parent : phandle to parent Ethernet node.
> +- interrupts : Should be single bit error interrupt.
> +
> +NAND FIFO ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-s10-nand-ecc"
> +- reg : Address and size for ECC block registers.
> +- altr,ecc-parent : phandle to parent NAND node.
> +- interrupts : Should be single bit error interrupt.
> +
> +DMA FIFO ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-s10-dma-ecc"
> +- reg : Address and size for ECC block registers.
> +- altr,ecc-parent : phandle to parent DMA node.
> +- interrupts : Should be single bit error interrupt.
> +
> +USB FIFO ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-s10-usb-ecc"
> +- reg : Address and size for ECC block registers.
> +- altr,ecc-parent : phandle to parent USB node.
> +- interrupts : Should be single bit error interrupt.
> +
> +SDMMC FIFO ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-s10-sdmmc-ecc"
> +- reg : Address and size for ECC block registers.
> +- altr,ecc-parent : phandle to parent SD/MMC node.
> +- interrupts : Should be single bit error interrupt for port A
> + and then single bit error interrupt for port B.
> +
> Example:
>
> eccmgr {
> @@ -274,4 +317,67 @@ Example:
> compatible = "altr,sdram-edac-s10";
> interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> + ocram-ecc@ff8cc000 {
> + compatible = "altr,socfpga-s10-ocram-ecc";
> + reg = ;
> + altr,ecc-parent = <>;
> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + emac0-rx-ecc@ff8c {
> + compatible = "altr,socfpga-s10-eth-mac-ecc";
> + reg = <0xff8c 0x100>;
> + altr,ecc-parent = <>;
> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + emac0-tx-ecc@ff8c0400 {
> + compatible = "altr,socfpga-s10-eth-mac-ecc";
> + reg = <0xff8c0400 0x100>;
> + altr,ecc-parent = <>;
> + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>'
> + };
> +
> + nand-buf-ecc@ff8c8000 {
> + compatible = "altr,socfpga-s10-nand-ecc";
> + reg = <0xff8c8000 0x100>;
> + altr,ecc-parent = <>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + nand-rd-ecc@ff8c8400 {
> + compatible = "altr,socfpga-s10-nand-ecc";
> + reg = <0xff8c8400 0x100>;
> + altr,ecc-parent = <>;
> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + nand-wr-ecc@ff8c8800 {
> + compatible = "altr,socfpga-s10-nand-ecc";
> + reg = <0xff8c8800 0x100>;
> + altr,ecc-parent = <>;
> + interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + dma-ecc@ff8c9000 {
> + compatible = "altr,socfpga-s10-dma-ecc";
> + reg = <0xff8c9000 0x100>;
> + altr,ecc-parent = <>;
> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
> +
> + usb0-ecc@ff8c4000 {
> +
[Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller
Hi,
I hit the following issue when running syzkaller in arm64. It is hardly to
reproduce the issue by the attached log.
[ 206.633857] Injecting memory failure for pfn 0x38c7e0 at process virtual
address 0x201e
[ 206.766875] WARNING: CPU: 1 PID: 738 at mm/rmap.c:1571
try_to_unmap_one+0x1004/0x17d8
[ 206.768476] Kernel panic - not syncing: panic_on_warn set ...
[ 206.768476]
[ 206.769981] CPU: 1 PID: 738 Comm: syz-executor.0 Not tainted 4.19.27 #9
[ 206.771510] Hardware name: linux,dummy-virt (DT)
[ 206.772673] Call trace:
[ 206.773230] dump_backtrace+0x0/0x3c0
[ 206.774021] show_stack+0x28/0x38
[ 206.774761] dump_stack+0x120/0x188
[ 206.775483] panic+0x21c/0x48c
[ 206.776152] __warn+0x280/0x2cc
[ 206.776838] report_bug+0x1c8/0x2c8
[ 206.777612] bug_handler+0x8c/0x178
[ 206.778394] call_break_hook+0x238/0x338
[ 206.779410] brk_handler+0x3c/0xe8
[ 206.780186] do_debug_exception+0x12c/0x378
[ 206.781059] el1_dbg+0x18/0x84
[ 206.781732] try_to_unmap_one+0x1004/0x17d8
[ 206.782624] rmap_walk_anon+0x2b4/0x7a8
[ 206.783454] rmap_walk+0xfc/0x180
[ 206.784165] try_to_unmap+0x290/0x360
[ 206.784946] hwpoison_user_mappings.isra.5+0x5ec/0x1478
[ 206.786045] memory_failure+0x8c0/0xf00
[ 206.786872] __arm64_sys_madvise+0xc90/0x1278
[ 206.787786] el0_svc_handler+0x13c/0x308
[ 206.788626] el0_svc+0x8/0xc
[ 206.791030] SMP: stopping secondary CPUs
[ 206.792168] Dumping ftrace buffer:
[ 206.796278](ftrace buffer empty)
[ 206.797065] Kernel Offset: disabled
[ 206.797811] CPU features: 0x0,a1806000
[ 206.798625] Memory Limit: none
[ 206.800300] Rebooting in 86400 seconds..
Minchan has changed the conditon check from BUG_ON to WARN_ON_ONCE in
try_to_unmap_one.
However, It is still an abnormal condition when PageSwapBacked is not equal to
PageSwapCache.
But Is there any case it will meet the conditon in the mainline.
It is assumed that PageSwapBacked(page) is true in the anonymous page, This
is to say, PageSwapcache
is false. however, That is impossible because we will update the pte for
hwpoison entry.
Because page is locked , Its page flags should not be changed except for
PageSwapBacked.
Thanks,
zhong jiang
[ 16.918386] random: sshd: uninitialized urandom read (32 bytes read)
[ 17.159274] random: fast init done
[ 18.025596] urandom_read: 1 callbacks suppressed
[ 18.025610] random: sshd: uninitialized urandom read (32 bytes read)
[ 18.039828] random: sshd: uninitialized urandom read (32 bytes read)
[ 18.429823] random: sshd: uninitialized urandom read (32 bytes read)
Warning: Permanently added '[localhost]:38995' (ECDSA) to the list of known
hosts.
2019/03/11 11:34:22 fuzzer started
2019/03/11 11:34:23 dialing manager at 10.0.2.10:39705
2019/03/11 11:34:24 syscalls: 1
2019/03/11 11:34:24 code coverage: enabled
2019/03/11 11:34:24 comparison tracing: CONFIG_KCOV_ENABLE_COMPARISONS is not
enabled
2019/03/11 11:34:24 extra coverage: extra coverage is not supported by the
kernel
2019/03/11 11:34:24 setuid sandbox: enabled
2019/03/11 11:34:24 namespace sandbox: enabled
2019/03/11 11:34:24 Android sandbox: /sys/fs/selinux/policy does not exist
2019/03/11 11:34:24 fault injection: enabled
2019/03/11 11:34:24 leak checking: KMEMLEAK disabled: increase
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE or unset CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF
2019/03/11 11:34:24 net packet injection: /dev/net/tun does not exist
2019/03/11 11:34:24 net device setup: enabled
[ 111.797207] random: crng init done
11:37:24 executing program 1:
r0 = openat$zero(0xff9c, &(0x7f00)='/dev/zero\x00', 0x80,
0x0)
ioctl$TIOCNOTTY(r0, 0x5422)
syncfs(r0)
ioctl$KDGKBENT(r0, 0x4b46, &(0x7f40)={0x8000, 0x0, 0x3a})
r1 = accept4$packet(r0, &(0x7f80)={0x11, 0x0, 0x0, 0x1, 0x0, 0x6,
@random}, &(0x7fc0)=0x14, 0x80800)
getsockopt$inet6_IPV6_XFRM_POLICY(r0, 0x29, 0x23,
&(0x7f000100)={{{@in6=@dev, @in=@loopback, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}}, {{@in6=@mcast2}, 0x0, @in=@multicast2}},
&(0x7f000200)=0xe8)
fallocate(r0, 0x0, 0x4, 0xf80a)
r3 = openat$vcs(0xff9c, &(0x7f000240)='/dev/vcs\x00', 0x2001,
0x0)
munlockall()
fcntl$F_SET_RW_HINT(r1, 0x40c, &(0x7f000280)=0x3)
setsockopt$packet_fanout_data(r0, 0x107, 0x16, &(0x7f000300)={0x2,
&(0x7f0002c0)=[{0x4, 0x7, 0x1, 0x8}, {0x1ff, 0x0, 0x10001}]}, 0x10)
r4 = syz_genetlink_get_family_id$ipvs(&(0x7f000380)='IPVS\x00')
sendmsg$IPVS_CMD_ZERO(r3, &(0x7f000440)={&(0x7f000340)={0x10, 0x0, 0x0,
0x808081}, 0xc, &(0x7f000400)={&(0x7f0003c0)={0x1c, r4, 0x208,
0x70bd28, 0x25dfdbff, {}, [@IPVS_CMD_ATTR_TIMEOUT_TCP={0x8, 0x4, 0x7fff}]},
0x1c}, 0x1, 0x0, 0x0, 0x4000}, 0x4)
ioctl$sock_inet6_SIOCSIFADDR(r3, 0x8916, &(0x7f000480)={@dev={0xfe, 0x80,
[], 0x1d}, 0x7a, r2})
r5 = semget(0x2, 0x2, 0x40)
semctl$SEM_INFO(r5, 0x4, 0x13, &(0x7f0004c0)=""/87)
getsockopt$inet6_int(r0, 0x29, 0xa, &(0x7f000540),
Re: [PATCH 38/42] drivers: gpio: vr41xx: use devm_platform_ioremap_resource()
On 3/12/2019 8:42 AM, Enrico Weigelt, metux IT consult wrote: > On 12.03.19 12:37, Thierry Reding wrote: > >> The driver currently doesn't request the memory described in the >> resource, so technically you're changing behaviour here and with your >> change the driver could now fail if somebody else has already claimed >> the memory. > > hmm, using w/o requesting/claiming - isn't that a bug ? Not necessarily, before regmap existed, you could have very well delegated a subset of a larger resource to a specific driver while a driver requesting that larger resource would be responsible for doing the request_mem_region(). As long as both drivers don't stomp on each other, this is a perfectly valid way to delegate, yet keep things modular/separate. -- Florian
Re: [PATCH v2] hid: logitech: check the return value of create_singlethread_workqueue
On Tue, 12 Mar 2019 01:16:28 -0500
Kangjie Lu wrote:
> create_singlethread_workqueue may fail and return NULL. The fix
> checks if it is NULL to avoid NULL pointer dereference.
> Also, the fix moves the call of create_singlethread_workqueue
> earlier to avoid resource-release issues.
>
> Signed-off-by: Kangjie Lu
So I don't know this code at all, but...
> drivers/hid/hid-logitech-hidpp.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 15ed6177a7a3..1b7c336cae6d 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2106,6 +2106,12 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
> u8 feature_index)
> data = kzalloc(sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
> +
> + /* init the hardware command queue */
> + data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
> + if (!data->wq)
> + return -ENOMEM;
It's clear just from the diff that this return will leak 'data'. You also
break the error handling just below:
> data->effect_ids = kcalloc(num_slots, sizeof(int), GFP_KERNEL);
> if (!data->effect_ids) {
> kfree(data);
It's also worth asking: how are you testing these error path changes?
Thanks,
jon
Re: [PATCHv2 1/5] Documentation: dt: edac: Fix Stratix10 IRQ bindings
On Wed, Feb 27, 2019 at 11:27:21AM -0600, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> Fix Stratix10 ECC bindings to specify only the single
> bit error. On Stratix10 double bit errors are handled
> as SErrors instead of interrupts.
> Indicate the differences between the ARM64 and ARM32
> EDAC architecture in the bindings.
>
> Signed-off-by: Thor Thayer
> ---
> v2 No change
> ---
> .../devicetree/bindings/edac/socfpga-eccmgr.txt| 23
> +++---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> index 5626560a6cfd..a0ac50e15912 100644
> --- a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> +++ b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
> @@ -236,33 +236,42 @@ Stratix10 SoCFPGA ECC Manager
> The Stratix10 SoC ECC Manager handles the IRQs for each peripheral
> in a shared register similar to the Arria10. However, ECC requires
> access to registers that can only be read from Secure Monitor with
> -SMC calls. Therefore the device tree is slightly different.
> +SMC calls. Therefore the device tree is slightly different. Note that
> +only 1 interrupt is sent because the double bit errors are treated as
> +SErrors instead of IRQ.
>
> Required Properties:
> - compatible : Should be "altr,socfpga-s10-ecc-manager"
> -- interrupts : Should be single bit error interrupt, then double bit error
> - interrupt.
> +- altr,sysgr-syscon : phandle to Stratix10 System Manager Block
> + containing the ECC manager registers.
Seems this was already in use, but why not just make this node a child
of the System Manager Block and remove this phandle?
> +- interrupts : Should be single bit error interrupt.
> - interrupt-controller : boolean indicator that ECC Manager is an interrupt
> controller
> - #interrupt-cells : must be set to 2.
> +- #address-cells: must be 1
> +- #size-cells: must be 1
> +- ranges : standard definition, should translate from local addresses
>
> Subcomponents:
>
> SDRAM ECC
> Required Properties:
> - compatible : Should be "altr,sdram-edac-s10"
> -- interrupts : Should be single bit error interrupt, then double bit error
> - interrupt, in this order.
> +- interrupts : Should be single bit error interrupt.
>
> Example:
>
> eccmgr {
> compatible = "altr,socfpga-s10-ecc-manager";
> - interrupts = <0 15 4>, <0 95 4>;
> + altr,sysmgr-syscon = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupts = <0 15 4>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + ranges;
>
> sdramedac {
> compatible = "altr,sdram-edac-s10";
> - interrupts = <16 4>, <48 4>;
> + interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
> --
> 2.7.4
>
Re: [RESEND PATCH] mm/hotplug: don't reset pagetype flags for offline
On Tue 12-03-19 16:35:06, Oscar Salvador wrote: [...] > One thing I noticed when looking at start_isolate_page_range and > undo_isolate_page_range functions, is that start_isolate_page_range increments > the number of isolated pageblocks, while undo_isolate_page_range does the > counter > part. > Since undo_isolate_page_range is really never called during offlining, > we leave zone->nr_isolate_pageblock with a stale value. > > I __think__ this does not matter much. > We only get to check whether a zone got isolated pageblocks in > has_isolate_pageblock(), and this is called from: > > free_one_page > free_pcppages_bulk > __free_one_page It forces those into slow(er) path. So it makes a difference. > With a quick glance, the only difference in has_isolate_pageblock() returning > true or false, seems to be that those functions perform some extra checks in > case the zone reports to have isolated pageblocks. > > I wonder if we should set nr_isolate_pageblock back to its original value > before start_isolate_page_range. Yes. And that would be a fixup to my 2ce13640b3f4. -- Michal Hocko SUSE Labs
Re: [PATCH v3 0/1] mm: introduce put_user_page*(), placeholder versions
On Tue, Mar 12, 2019 at 11:35:29AM -0400, Jerome Glisse wrote: > > > > Yes you now have the filesystem as well as the GUP pinner claiming > > > > authority over the contents of a single memory segment. Maybe better not > > > > allow that? > > > > > > This goes back to regressing existing driver with existing users. > > > > There is no regression if that behavior never really worked. > > Well RDMA driver maintainer seems to report that this has been a valid > and working workload for their users. I think it is more O_DIRECT that is the history here.. In RDMA land long term GUPs of file backed pages tend to crash the kernel (what John is trying to fix here) so I'm not sure there are actual real & tested users, only people that wish they could do this.. Jason
Re: [PATCH v1] Bluetooth: hci_qca: Enable the ldisc for ROME for x86 platforms.
Hi Rocky,
On Tue, Mar 12, 2019 at 05:01:59PM +0800, rjl...@codeaurora.org wrote:
> 在 2019-03-09 02:52，Matthias Kaehlcke 写道：
> > On Fri, Mar 08, 2019 at 10:43:14AM +0530, Balakrishna Godavarthi wrote:
> > > Hi Matthias,
> > >
> > > On 2019-03-08 02:12, Matthias Kaehlcke wrote:
> > > > Hi Balakrishna,
> > > >
> > > > On Thu, Mar 07, 2019 at 03:47:22PM +0530, Balakrishna Godavarthi wrote:
> > > > > When using btattach to setup Rome over ldisc we observed a crash
> > > > > in qca_setup as it will try to access the serdev which is not
> > > > > available in the ldisc proto. This patch will fix the crash by
> > > > > support both the ldisc and serdev way in the qca hci_uart driver.
> > > > >
> > > > > Signed-off-by: Balakrishna Godavarthi
> > > >
> > > > Oh, I wasn't aware of the instantiation through ldisc and was actually
> > > > considering to *remove* some of the seemingly unnecessary serdev
> > > > checks.
> > > >
> > > > > ---
> > > > > drivers/bluetooth/hci_qca.c | 47
> > > > > ++---
> > > > > 1 file changed, 28 insertions(+), 19 deletions(-)
> > > > >
> > > > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > > > index 237aea34b69f..0a5c98d46864 100644
> > > > > --- a/drivers/bluetooth/hci_qca.c
> > > > > +++ b/drivers/bluetooth/hci_qca.c
> > > > > @@ -963,7 +963,7 @@ static int qca_set_baudrate(struct hci_dev
> > > > > *hdev, uint8_t baudrate)
> > > > > {
> > > > > struct hci_uart *hu = hci_get_drvdata(hdev);
> > > > > struct qca_data *qca = hu->priv;
> > > > > - struct qca_serdev *qcadev;
> > > > > + struct qca_serdev *qcadev = NULL;
> > > >
> > > > In many cases the only field that is accessed is qcadev->btsoc_type. I
> > > > think something like 'qca_get_soc_type(struct hci_dev *hdev / struct
> > > > hci_uart *hu)' would make things more readable.
> > > >
> > > [Bala]: sure will update this in other patch once this change is
> > > landed as
> > > this has to
> > > go in priority as we have crash coming.
> >
> > That's not how things should work, especially for fairly trivial
> > changes. It requires reviewers to first spent time to review the patch
> > that adds clutter and later spend more time to review the one that
> > removes it. It's also easier to get a clean patch merged in the first
> > place, rather than a noisy one.
> >
> > Anyway, here is my take at it:
> > https://lore.kernel.org/patchwork/patch/1049014/
> >
> > Please help with testing for ROME, unless you disagree with the
> > approach.
> >
> > Thanks
> >
> > Matthias
>
> Hi Matthias,
>
> I will test your patch and update to you, and you are correct that AR3002 is
> not part of Rome family, you should use QCA_ROME as the default return of
> qca_soc_type.
Thanks for the confirmation!
> Could you also loop me in
> https://lore.kernel.org/patchwork/patch/1049014/?
This patch has been superseded by a newer version:
https://lore.kernel.org/patchwork/patch/1049696/
It already landed in bluetooth-next.
Testing with Rome and ldisc would still be appreciated, since I don't
have such a configuration.
Thanks
Matthias
[PATCH] regulator: max14577: Get rid of match_init_data/match_of_node functions
This driver has been converted to use regulator core's simplified DT
parsing code. So the match_init_data/match_of_node functions are not
necessary now, remove them.
Signed-off-by: Axel Lin
---
drivers/regulator/max14577-regulator.c | 55 --
1 file changed, 55 deletions(-)
diff --git a/drivers/regulator/max14577-regulator.c
b/drivers/regulator/max14577-regulator.c
index 85a88a9e4d42..07a150c9bbf2 100644
--- a/drivers/regulator/max14577-regulator.c
+++ b/drivers/regulator/max14577-regulator.c
@@ -155,58 +155,6 @@ static const struct regulator_desc
max77836_supported_regulators[] = {
[MAX77836_LDO2] = MAX77836_LDO_REG(2),
};
-#ifdef CONFIG_OF
-static struct of_regulator_match max14577_regulator_matches[] = {
- { .name = "SAFEOUT", },
- { .name = "CHARGER", },
-};
-
-static struct of_regulator_match max77836_regulator_matches[] = {
- { .name = "SAFEOUT", },
- { .name = "CHARGER", },
- { .name = "LDO1", },
- { .name = "LDO2", },
-};
-
-static inline struct regulator_init_data *match_init_data(int index,
- enum maxim_device_type dev_type)
-{
- switch (dev_type) {
- case MAXIM_DEVICE_TYPE_MAX77836:
- return max77836_regulator_matches[index].init_data;
-
- case MAXIM_DEVICE_TYPE_MAX14577:
- default:
- return max14577_regulator_matches[index].init_data;
- }
-}
-
-static inline struct device_node *match_of_node(int index,
- enum maxim_device_type dev_type)
-{
- switch (dev_type) {
- case MAXIM_DEVICE_TYPE_MAX77836:
- return max77836_regulator_matches[index].of_node;
-
- case MAXIM_DEVICE_TYPE_MAX14577:
- default:
- return max14577_regulator_matches[index].of_node;
- }
-}
-#else /* CONFIG_OF */
-static inline struct regulator_init_data *match_init_data(int index,
- enum maxim_device_type dev_type)
-{
- return NULL;
-}
-
-static inline struct device_node *match_of_node(int index,
- enum maxim_device_type dev_type)
-{
- return NULL;
-}
-#endif /* CONFIG_OF */
-
/**
* Registers for regulators of max77836 use different I2C slave addresses so
* different regmaps must be used for them.
@@ -265,9 +213,6 @@ static int max14577_regulator_probe(struct platform_device
*pdev)
if (pdata && pdata->regulators) {
config.init_data = pdata->regulators[i].initdata;
config.of_node = pdata->regulators[i].of_node;
- } else {
- config.init_data = match_init_data(i, dev_type);
- config.of_node = match_of_node(i, dev_type);
}
config.regmap = max14577_get_regmap(max14577,
supported_regulators[i].id);
--
2.17.1
Re: sun6i MIPI DSI driver EoTp
Hi, On Mon, Mar 11, 2019 at 09:43:36PM +0300, Sergey Suloev wrote: > according to MIPI DSI spec chapter 8.8.2 the EoTp packet can be enabled or > disabled on the protocol level. > It seems like that it might be required for the panel I am working on (Himax > HX8379A-based panel). > Here is some crappy driver I found on github showing that it might be an > issue [1] > > May I ask you if this feature supported by sun6i MIPI DSI driver and > where ? > As there is no datasheet available, could you please help to support this > feature (if not yet) ? I haven't seen any panel that used it so far, so I have no idea. I guess this would be controlled through SUN6I_DSI_BASIC_CTL0_HS_EOTP_EN in the driver. > The second point is that the panel requires NON-BURST-WITH-SYNC-EVENTS mode. > Could it be a problem with the current driver? That should be supported in -next Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v7 01/15] sched/core: uclamp: Add CPU's clamp buckets refcounting
On 12-Mar 16:20, Peter Zijlstra wrote:
> On Fri, Feb 08, 2019 at 10:05:40AM +, Patrick Bellasi wrote:
> > +/* Integer ceil-rounded range for each bucket */
> > +#define UCLAMP_BUCKET_DELTA ((SCHED_CAPACITY_SCALE / UCLAMP_BUCKETS) + 1)
>
> Uhm, should that not me ((x+y-1)/y), aka. DIV_ROUND_UP(x,y) ?
Well, there is certainly some rounding to be done...
> The above would give 4 for 9/3, which is clearly buggered.
.. still the math above should work fine within the boundaries we
define for UCLAMP_BUCKET_DELTA (5..20 groups) and considering that
SCHED_CAPACITY_SCALE will never be smaller then 1024.
The above is designed to shrink the topmost bucket wrt all the others
but it will never be smaller than ~30%.
Here are the start values computed for each bucket using the math
above and the computed shrinking percentage for the topmost bucket:
bukets size: 205, top bucket start@820 (err: 0.49%), buckets: {0: 0, 1: 205,
2: 410, 3: 615, 4: 820}
bukets size: 171, top bucket start@855 (err: 1.17%), buckets: {0: 0, 1: 171,
2: 342, 3: 513, 4: 684, 5: 855}
bukets size: 147, top bucket start@882 (err: 3.40%), buckets: {0: 0, 1: 147,
2: 294, 3: 441, 4: 588, 5: 735, 6: 882}
bukets size: 129, top bucket start@903 (err: 6.20%), buckets: {0: 0, 1: 129,
2: 258, 3: 387, 4: 516, 5: 645, 6: 774, 7: 903}
bukets size: 114, top bucket start@912 (err: 1.75%), buckets: {0: 0, 1: 114,
2: 228, 3: 342, 4: 456, 5: 570, 6: 684, 7: 798, 8: 912}
bukets size: 103, top bucket start@927 (err: 5.83%), buckets: {0: 0, 1: 103,
2: 206, 3: 309, 4: 412, 5: 515, 6: 618, 7: 721, 8: 824, 9: 927}
bukets size: 94, top bucket start@940 (err: 10.64%), buckets: {0: 0, 1: 94,
2: 188, 3: 282, 4: 376, 5: 470, 6: 564, 7: 658, 8: 752, 9: 846, 10: 940}
bukets size: 86, top bucket start@946 (err: 9.30%), buckets: {0: 0, 1: 86,
2: 172, 3: 258, 4: 344, 5: 430, 6: 516, 7: 602, 8: 688, 9: 774, 10: 860, 11:
946}
bukets size: 79, top bucket start@948 (err: 3.80%), buckets: {0: 0, 1: 79,
2: 158, 3: 237, 4: 316, 5: 395, 6: 474, 7: 553, 8: 632, 9: 711, 10: 790, 11:
869, 12: 948}
bukets size: 74, top bucket start@962 (err: 16.22%), buckets: {0: 0, 1: 74,
2: 148, 3: 222, 4: 296, 5: 370, 6: 444, 7: 518, 8: 592, 9: 666, 10: 740, 11:
814, 12: 888, 13: 962}
bukets size: 69, top bucket start@966 (err: 15.94%), buckets: {0: 0, 1: 69,
2: 138, 3: 207, 4: 276, 5: 345, 6: 414, 7: 483, 8: 552, 9: 621, 10: 690, 11:
759, 12: 828, 13: 897, 14: 966}
bukets size: 65, top bucket start@975 (err: 24.62%), buckets: {0: 0, 1: 65,
2: 130, 3: 195, 4: 260, 5: 325, 6: 390, 7: 455, 8: 520, 9: 585, 10: 650, 11:
715, 12: 780, 13: 845, 14: 910, 15: 975}
bukets size: 61, top bucket start@976 (err: 21.31%), buckets: {0: 0, 1: 61,
2: 122, 3: 183, 4: 244, 5: 305, 6: 366, 7: 427, 8: 488, 9: 549, 10: 610, 11:
671, 12: 732, 13: 793, 14: 854, 15: 915, 16: 976}
bukets size: 57, top bucket start@969 (err: 3.51%), buckets: {0: 0, 1: 57,
2: 114, 3: 171, 4: 228, 5: 285, 6: 342, 7: 399, 8: 456, 9: 513, 10: 570, 11:
627, 12: 684, 13: 741, 14: 798, 15: 855, 16: 912, 17: 969}
bukets size: 54, top bucket start@972 (err: 3.70%), buckets: {0: 0, 1: 54,
2: 108, 3: 162, 4: 216, 5: 270, 6: 324, 7: 378, 8: 432, 9: 486, 10: 540, 11:
594, 12: 648, 13: 702, 14: 756, 15: 810, 16: 864, 17: 918, 18: 972}
bukets size: 52, top bucket start@988 (err: 30.77%), buckets: {0: 0, 1: 52,
2: 104, 3: 156, 4: 208, 5: 260, 6: 312, 7: 364, 8: 416, 9: 468, 10: 520, 11:
572, 12: 624, 13: 676, 14: 728, 15: 780, 16: 832, 17: 884, 18: 936, 19: 988}
Does that makes sense?
--
#include
Patrick Bellasi
Re: [PATCH v2 1/2] dt-bindings: power: supply: gpio-charger: Add status-gpios property
On Tue, 26 Feb 2019 16:04:36 +0100, Artur Rojek wrote: > Add documentation for the "status-gpios" property. > Update the "gpios" property with a valid example. > > Signed-off-by: Artur Rojek > --- > > Changes: > > v2: - add a better description for the "status-gpios" property, > - add valid examples for the "gpios" and "status-gpios" properties > > .../devicetree/bindings/power/supply/gpio-charger.txt | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH] KVM: arm/arm64: Set ICH_HCR_EN in guest anyway when using gicv4
Nianyao,
Please do not send patches as HTML. Or any email as HTML. Please make
sure that you only send plain text emails on any mailing list (see point
#6 in Documentation/process/submitting-patches.rst).
On 12/03/2019 12:22, Tangnianyao (ICT) wrote:
> In gicv4, direct vlpi may be forward to PE without using LR or ap_list. If
>
> ICH_HCR_EL2.En is 0 in guest, direct vlpi cannot be accepted by PE.
>
> It will take long time for direct vlpi to be forwarded in some cases.
>
> Direct vlpi has to wait for ICH_HCR_EL2.En=1 where some other interrupts
>
> using LR need to be forwarded, because in kvm_vgic_flush_hwstate,
>
> if ap_list is empty, it will return quickly not setting ICH_HCR_EL2.En.
>
> To fix this, set ICH_HCR_EL2.En to 1 before returning to guest when
>
> using GICv4.
>
>
>
> Signed-off-by: Nianyao Tang
>
> ---
>
> arch/arm64/include/asm/kvm_asm.h | 1 +
>
> virt/kvm/arm/hyp/vgic-v3-sr.c | 10 ++
>
> virt/kvm/arm/vgic/vgic-v4.c | 8
>
> 3 files changed, 19 insertions(+)
>
>
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h
> b/arch/arm64/include/asm/kvm_asm.h
>
> index f5b79e9..0581c4d 100644
>
> --- a/arch/arm64/include/asm/kvm_asm.h
>
> +++ b/arch/arm64/include/asm/kvm_asm.h
>
> @@ -79,6 +79,7 @@
>
> extern void __vgic_v3_init_lrs(void);
>
> extern u32 __kvm_get_mdcr_el2(void);
>
> +extern void __vgic_v3_write_hcr(u32 vmcr);
>
> /* Home-grown __this_cpu_{ptr,read} variants that always work at HYP */
>
> #define
> __hyp_this_cpu_ptr(sym)
> \
>
> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
>
> index 264d92d..12027af 100644
>
> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
>
> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
>
> @@ -434,6 +434,16 @@ void __hyp_text __vgic_v3_write_vmcr(u32 vmcr)
>
> write_gicreg(vmcr, ICH_VMCR_EL2);
>
> }
>
> +u64 __hyp_text __vgic_v3_read_hcr(void)
>
> +{
>
> + return read_gicreg(ICH_HCR_EL2);
>
> +}
>
> +
>
> +void __hyp_text __vgic_v3_write_hcr(u32 vmcr)
>
> +{
>
> + write_gicreg(vmcr, ICH_HCR_EL2);
>
> +}
This is HYP code...
>
> +
>
> #ifdef CONFIG_ARM64
>
> static int __hyp_text __vgic_v3_bpr_min(void)
>
> diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c
>
> index 1ed5f22..515171a 100644
>
> --- a/virt/kvm/arm/vgic/vgic-v4.c
>
> +++ b/virt/kvm/arm/vgic/vgic-v4.c
>
> @@ -208,6 +208,8 @@ int vgic_v4_sync_hwstate(struct kvm_vcpu *vcpu)
>
> if (!vgic_supports_direct_msis(vcpu->kvm))
>
> return 0;
>
> + __vgic_v3_write_hcr(vcpu->arch.vgic_cpu.vgic_v3.vgic_hcr &
> ~ICH_HCR_EN);
And you've now crashed your non-VHE system by branching directly to code
that cannot be executed at EL1.
>
> +
>
> return its_schedule_vpe(>arch.vgic_cpu.vgic_v3.its_vpe, false);
>
> }
>
> @@ -220,6 +222,12 @@ int vgic_v4_flush_hwstate(struct kvm_vcpu *vcpu)
>
> return 0;
>
> /*
>
> + * Enable ICH_HCR_EL.En so that guest can accpet and handle direct
>
> + * vlpi.
>
> + */
>
> + __vgic_v3_write_hcr(vcpu->arch.vgic_cpu.vgic_v3.vgic_hcr);
>
> +
>
> + /*
>
> * Before making the VPE resident, make sure the redistributor
>
> * corresponding to our current CPU expects us here. See the
>
> * doc in drivers/irqchip/irq-gic-v4.c to understand how this
>
> --
>
> 1.9.1
>
>
>
>
>
Overall, this looks like the wrong approach. It is not the GICv4 code's
job to do this, but the low-level code (either the load/put code for VHE
or the save/restore code for non-VHE).
It would certainly help if you could describe which context you're in
(VHE, non-VHE). I suppose the former...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[PATCH 2/2] regulator: da9055: Convert to regulator core's simplified DT parsing code
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
---
drivers/regulator/da9055-regulator.c | 67 +++-
1 file changed, 6 insertions(+), 61 deletions(-)
diff --git a/drivers/regulator/da9055-regulator.c
b/drivers/regulator/da9055-regulator.c
index 3c6fac793658..b7b4dddf5509 100644
--- a/drivers/regulator/da9055-regulator.c
+++ b/drivers/regulator/da9055-regulator.c
@@ -338,6 +338,8 @@ static const struct regulator_ops da9055_ldo_ops = {
{\
.reg_desc = {\
.name = #_id,\
+ .of_match = of_match_ptr(#_id),\
+ .regulators_node = of_match_ptr("regulators"),\
.ops = _ldo_ops,\
.type = REGULATOR_VOLTAGE,\
.id = DA9055_ID_##_id,\
@@ -366,6 +368,8 @@ static const struct regulator_ops da9055_ldo_ops = {
{\
.reg_desc = {\
.name = #_id,\
+ .of_match = of_match_ptr(#_id),\
+ .regulators_node = of_match_ptr("regulators"),\
.ops = _buck_ops,\
.type = REGULATOR_VOLTAGE,\
.id = DA9055_ID_##_id,\
@@ -507,59 +511,6 @@ static inline struct da9055_regulator_info
*find_regulator_info(int id)
return NULL;
}
-#ifdef CONFIG_OF
-static struct of_regulator_match da9055_reg_matches[] = {
- { .name = "BUCK1", },
- { .name = "BUCK2", },
- { .name = "LDO1", },
- { .name = "LDO2", },
- { .name = "LDO3", },
- { .name = "LDO4", },
- { .name = "LDO5", },
- { .name = "LDO6", },
-};
-
-static int da9055_regulator_dt_init(struct platform_device *pdev,
- struct da9055_regulator *regulator,
- struct regulator_config *config,
- int regid)
-{
- struct device_node *nproot, *np;
- int ret;
-
- nproot = of_node_get(pdev->dev.parent->of_node);
- if (!nproot)
- return -ENODEV;
-
- np = of_get_child_by_name(nproot, "regulators");
- if (!np)
- return -ENODEV;
-
- ret = of_regulator_match(>dev, np, _reg_matches[regid], 1);
- of_node_put(nproot);
- if (ret < 0) {
- dev_err(>dev, "Error matching regulator: %d\n", ret);
- return ret;
- }
-
- config->init_data = da9055_reg_matches[regid].init_data;
- config->of_node = da9055_reg_matches[regid].of_node;
-
- if (!config->of_node)
- return -ENODEV;
-
- return 0;
-}
-#else
-static inline int da9055_regulator_dt_init(struct platform_device *pdev,
- struct da9055_regulator *regulator,
- struct regulator_config *config,
- int regid)
-{
- return -ENODEV;
-}
-#endif /* CONFIG_OF */
-
static int da9055_regulator_probe(struct platform_device *pdev)
{
struct regulator_config config = { };
@@ -580,18 +531,12 @@ static int da9055_regulator_probe(struct platform_device
*pdev)
}
regulator->da9055 = da9055;
- config.dev = >dev;
+ config.dev = da9055->dev;
config.driver_data = regulator;
config.regmap = da9055->regmap;
- if (pdata) {
+ if (pdata)
config.init_data = pdata->regulators[pdev->id];
- } else {
- ret = da9055_regulator_dt_init(pdev, regulator, ,
- pdev->id);
- if (ret < 0)
- return ret;
- }
ret = da9055_gpio_init(regulator, , pdata, pdev->id);
if (ret < 0)
--
2.17.1
[PATCH 1/2] regulator: da9052: Convert to regulator core's simplified DT parsing code
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
---
Hi,
I don't have this h/w, so please help testing it.
Thanks,
Axel
drivers/regulator/da9052-regulator.c | 33 +---
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/drivers/regulator/da9052-regulator.c
b/drivers/regulator/da9052-regulator.c
index cefa3558236d..98d486372b8c 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -294,6 +294,8 @@ static const struct regulator_ops da9052_ldo_ops = {
{\
.reg_desc = {\
.name = #_name,\
+ .of_match = of_match_ptr(#_name),\
+ .regulators_node = of_match_ptr("regulators"),\
.ops = _ldo_ops,\
.type = REGULATOR_VOLTAGE,\
.id = DA9052_ID_##_id,\
@@ -314,6 +316,8 @@ static const struct regulator_ops da9052_ldo_ops = {
{\
.reg_desc = {\
.name = #_name,\
+ .of_match = of_match_ptr(#_name),\
+ .regulators_node = of_match_ptr("regulators"),\
.ops = _dcdc_ops,\
.type = REGULATOR_VOLTAGE,\
.id = DA9052_ID_##_id,\
@@ -417,36 +421,11 @@ static int da9052_regulator_probe(struct platform_device
*pdev)
return -EINVAL;
}
- config.dev = >dev;
+ config.dev = da9052->dev;
config.driver_data = regulator;
config.regmap = da9052->regmap;
- if (pdata) {
+ if (pdata)
config.init_data = pdata->regulators[cell->id];
- } else {
-#ifdef CONFIG_OF
- struct device_node *nproot = da9052->dev->of_node;
- struct device_node *np;
-
- if (!nproot)
- return -ENODEV;
-
- nproot = of_get_child_by_name(nproot, "regulators");
- if (!nproot)
- return -ENODEV;
-
- for_each_child_of_node(nproot, np) {
- if (of_node_name_eq(np,
-regulator->info->reg_desc.name)) {
- config.init_data = of_get_regulator_init_data(
- >dev, np,
- >info->reg_desc);
- config.of_node = np;
- break;
- }
- }
- of_node_put(nproot);
-#endif
- }
regulator->rdev = devm_regulator_register(>dev,
>info->reg_desc,
--
2.17.1
Re: [PATCH 3/3] auxdisplay: charlcd: make backlight initial state configurable
Andy Shevchenko writes: > On Fri, Mar 1, 2019 at 9:14 PM Mans Rullgard wrote: >> >> The charlcd driver currently flashes the backlight once on init. >> This may not be desirable. Thus, add options for turning the >> backlight off or on as well. >> >> Signed-off-by: Mans Rullgard >> --- >> drivers/auxdisplay/Kconfig | 21 + >> drivers/auxdisplay/charlcd.c | 10 +- >> 2 files changed, 30 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig >> index 7d3fe27d6868..c52c738e554a 100644 >> --- a/drivers/auxdisplay/Kconfig >> +++ b/drivers/auxdisplay/Kconfig >> @@ -445,6 +445,27 @@ config PANEL_BOOT_MESSAGE >> An empty message will only clear the display at driver init time. >> Any other >> printf()-formatted message is valid with newline and escape codes. >> >> +choice >> + prompt "Backlight initial state" >> + default CHARLCD_BL_FLASH > > LGTM, but I don't agree on this default. I would prefer either on or > off, not flashing for sure. > Though it seems the case before the patch... The current code unconditionally flashes the light once. I though it best to keep that behaviour as default, even if it's not seen as ideal. -- Måns Rullgård
Re: [PATCH v2 0/5] auxdisplay: Introduce charlcd_free()
On Tue, Mar 12, 2019 at 04:11:36PM +0100, Miguel Ojeda wrote: > On Tue, Mar 12, 2019 at 3:44 PM Andy Shevchenko > wrote: > > > > I have found a memory leak in hd44780 and it becomes that we have no > > counterpart to charlcd_alloc() that developers can easily miss. > > Side-note now that I see these patches: I forgot to CC you in a series > for charlcd that we got from Mans a week or two ago -- please take a > chance to review them if you want! Also pinging Geert & Willy again in > case they want to take a look. Done. It seems these two series are orthogonal to each other, so, can be applied separately. -- With Best Regards, Andy Shevchenko
Re: [RFC PATCH v3 3/5] tracing: Use tracing error_log with hist triggers
On Mon, 4 Mar 2019 17:36:46 -0600
Tom Zanussi wrote:
> From: Tom Zanussi
>
> Replace hist_err() and hist_err_event() with tracing_log_err() from
> the new tracing error_log mechanism.
>
> Also add a couple related helper functions and remove most of the old
> hist_err()-related code.
>
> With this change, users no longer read the hist files for hist trigger
> error information, but instead look at tracing/error_log for the same
> information.
Could you also add a patch which update its testcase?
test.d/trigger/inter-event/trigger-extended-error-support.tc
will fail after this patch.
Thank you,
>
> Signed-off-by: Tom Zanussi
> ---
> kernel/trace/trace_events_hist.c | 206
> ---
> 1 file changed, 104 insertions(+), 102 deletions(-)
>
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
> index 231f9e4379d2..562306265c9d 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -22,6 +22,57 @@
>
> #define STR_VAR_LEN_MAX 32 /* must be multiple of sizeof(u64) */
>
> +#define ERRORS
> \
> + C(NONE, "No error"),\
> + C(DUPLICATE_VAR,"Variable already defined"),\
> + C(VAR_NOT_UNIQUE, "Variable name not unique, need to use fully
> qualified name (subsys.event.var) for variable"), \
> + C(TOO_MANY_VARS,"Too many variables defined"), \
> + C(MALFORMED_ASSIGNMENT, "Malformed assignment"),\
> + C(NAMED_MISMATCH, "Named hist trigger doesn't match existing
> named trigger (includes variables)"), \
> + C(TRIGGER_EEXIST, "Hist trigger already exists"), \
> + C(TRIGGER_ENOENT_CLEAR, "Can't clear or continue a nonexistent hist
> trigger"), \
> + C(SET_CLOCK_FAIL, "Couldn't set trace_clock"),\
> + C(BAD_FIELD_MODIFIER, "Invalid field modifier"), \
> + C(TOO_MANY_SUBEXPR, "Too many subexpressions (3 max)"), \
> + C(TIMESTAMP_MISMATCH, "Timestamp units in expression don't match"), \
> + C(TOO_MANY_FIELD_VARS, "Too many field variables defined"),\
> + C(EVENT_FILE_NOT_FOUND, "Event file not found"),\
> + C(HIST_NOT_FOUND, "Matching event histogram not found"), \
> + C(HIST_CREATE_FAIL, "Couldn't create histogram for field"), \
> + C(SYNTH_VAR_NOT_FOUND, "Couldn't find synthetic variable"),\
> + C(SYNTH_EVENT_NOT_FOUND,"Couldn't find synthetic event"), \
> + C(SYNTH_TYPE_MISMATCH, "Param type doesn't match synthetic event field
> type"), \
> + C(SYNTH_COUNT_MISMATCH, "Param count doesn't match synthetic event
> field count"), \
> + C(FIELD_VAR_PARSE_FAIL, "Couldn't parse field variable"), \
> + C(VAR_CREATE_FIND_FAIL, "Couldn't create or find variable"),\
> + C(ONX_NOT_VAR, "For onmax(x) or onchange(x), x must be a
> variable"), \
> + C(ONX_VAR_NOT_FOUND,"Couldn't find onmax or onchange variable"), \
> + C(ONX_VAR_CREATE_FAIL, "Couldn't create onmax or onchange variable"), \
> + C(FIELD_VAR_CREATE_FAIL,"Couldn't create field variable"), \
> + C(TOO_MANY_PARAMS, "Too many action params"), \
> + C(PARAM_NOT_FOUND, "Couldn't find param"), \
> + C(INVALID_PARAM,"Invalid action param"),\
> + C(ACTION_NOT_FOUND, "No action found"), \
> + C(NO_SAVE_PARAMS, "No params found for save()"), \
> + C(TOO_MANY_SAVE_ACTIONS,"Can't have more than one save() action per
> hist"), \
> + C(ACTION_MISMATCH, "Handler doesn't support action"), \
> + C(NO_CLOSING_PAREN, "No closing paren found"), \
> + C(SUBSYS_NOT_FOUND, "Missing subsystem"), \
> + C(INVALID_SUBSYS_EVENT, "Invalid subsystem or event name"), \
> + C(INVALID_REF_KEY, "Using variable references as keys not
> supported"), \
> + C(VAR_NOT_FOUND,"Couldn't find variable"), \
> + C(FIELD_NOT_FOUND, "Couldn't find field"),
> +
> +#undef C
> +#define C(a, b) HIST_ERR_##a
> +
> +enum { ERRORS };
> +
> +#undef C
> +#define C(a, b) b
> +
> +static const char *err_text[] = { ERRORS };
> +
> struct hist_field;
>
> typedef u64 (*hist_field_fn_t) (struct hist_field *field,
> @@ -538,7 +589,10 @@ static struct track_data *track_data_alloc(unsigned int
> key_len,
> static char last_cmd[MAX_FILTER_STR_VAL];
> static char last_cmd_loc[MAX_FILTER_STR_VAL];
>
> -static char hist_err_str[MAX_FILTER_STR_VAL];
> +static int errpos(char *str)
> +{
> + return err_pos(last_cmd, str);
> +}
>
> static void last_cmd_set(struct trace_event_file *file, char *str)
> {
> @@ -565,55 +619,17 @@
Re: [PATCH 3/3] auxdisplay: charlcd: make backlight initial state configurable
On Fri, Mar 1, 2019 at 9:14 PM Mans Rullgard wrote:
>
> The charlcd driver currently flashes the backlight once on init.
> This may not be desirable. Thus, add options for turning the
> backlight off or on as well.
>
> Signed-off-by: Mans Rullgard
> ---
> drivers/auxdisplay/Kconfig | 21 +
> drivers/auxdisplay/charlcd.c | 10 +-
> 2 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
> index 7d3fe27d6868..c52c738e554a 100644
> --- a/drivers/auxdisplay/Kconfig
> +++ b/drivers/auxdisplay/Kconfig
> @@ -445,6 +445,27 @@ config PANEL_BOOT_MESSAGE
> An empty message will only clear the display at driver init time.
> Any other
> printf()-formatted message is valid with newline and escape codes.
>
> +choice
> + prompt "Backlight initial state"
> + default CHARLCD_BL_FLASH
LGTM, but I don't agree on this default. I would prefer either on or
off, not flashing for sure.
Though it seems the case before the patch...
> +
> + config CHARLCD_BL_OFF
> + bool "Off"
> + help
> + Backlight is initially turned off
> +
> + config CHARLCD_BL_ON
> + bool "On"
> + help
> + Backlight is initially turned on
> +
> + config CHARLCD_BL_FLASH
> + bool "Flash"
> + help
> + Backlight is flashed briefly on init
> +
> +endchoice
> +
> endif # AUXDISPLAY
>
> config PANEL
> diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c
> index db0356dca2d7..ff8c53c082ff 100644
> --- a/drivers/auxdisplay/charlcd.c
> +++ b/drivers/auxdisplay/charlcd.c
> @@ -769,6 +769,14 @@ static void charlcd_puts(struct charlcd *lcd, const char
> *s)
> #define LCD_INIT_TEXT "Linux-" UTS_RELEASE "\n"
> #endif
>
> +#ifdef CONFIG_CHARLCD_BL_ON
> +#define LCD_INIT_BL "\x1b[L+"
> +#elif defined (CONFIG_CHARLCD_BL_FLASH)
> +#define LCD_INIT_BL "\x1b[L*"
> +#else
I would rather put here defined(_OFF)...
> +#define LCD_INIT_BL "\x1b[L-"
...and do
#else
#define LCD_INIT_BL "" // or whatever stands for as-is
> +#endif
> +
> /* initialize the LCD driver */
> static int charlcd_init(struct charlcd *lcd)
> {
> @@ -790,7 +798,7 @@ static int charlcd_init(struct charlcd *lcd)
> return ret;
>
> /* display a short message */
> - charlcd_puts(lcd, "\x1b[Lc\x1b[Lb\x1b[L*" LCD_INIT_TEXT);
> + charlcd_puts(lcd, "\x1b[Lc\x1b[Lb" LCD_INIT_BL LCD_INIT_TEXT);
>
> /* clear the display on the next device opening */
> priv->must_clear = true;
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 38/42] drivers: gpio: vr41xx: use devm_platform_ioremap_resource()
On 12.03.19 12:37, Thierry Reding wrote: > The driver currently doesn't request the memory described in the > resource, so technically you're changing behaviour here and with your > change the driver could now fail if somebody else has already claimed > the memory. hmm, using w/o requesting/claiming - isn't that a bug ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
lening aanvragen
-- Goedendag, Het is ons een genoegen u te schrijven met betrekking tot het verstrekken van leningen per postadvertentie. Simple Federal Credit Union, We opereren onder een korte, duidelijke en begrijpelijke algemene voorwaarden. We verstrekken leningen tegen een lage rente van 3%. Geachte lezers moeten opmerken dat dit aanbod is voor serieuze individuen, bedrijven en bedrijven. Krijg uw lening om uw financiële problemen op te lossen, zoals rekeningen betalen, nieuwe bedrijven vestigen, oude bedrijven herstellen. geïnteresseerde personen, bedrijven en bedrijven moeten contact met ons opnemen via dit e-mailadres: i...@simplefederalcreditunion.com Laat deze kans niet voorbijgaan. Krijg uw lening om uw financiële problemen op te lossen. Als u geïnteresseerd bent in onze lening vul dan onmiddellijk dit leningsaanvraagformulier in. Jullie namen: Adres: Telefoonnummer: Lening bedrag nodig: Looptijd: Bezetting: Maandelijks inkomensniveau: Geslacht: Geboortedatum: Staat: land: Postcode: Doel: We wachten op je snelle reactie. Eric
Re: [PATCH] tpm: Make timeout logic simpler and more robust
On Tue, Mar 12, 2019 at 07:42:46AM -0700, James Bottomley wrote: > On Tue, 2019-03-12 at 14:50 +0200, Jarkko Sakkinen wrote: > > On Mon, Mar 11, 2019 at 05:27:43PM -0700, James Bottomley wrote: > > > On Mon, 2019-03-11 at 16:54 -0700, Calvin Owens wrote: > > > > e're having lots of problems with TPM commands timing out, and > > > > we're seeing these problems across lots of different hardware > > > > (both v1/v2). > > > > > > > > I instrumented the driver to collect latency data, but I wasn't > > > > able to find any specific timeout to fix: it seems like many of > > > > them are too aggressive. So I tried replacing all the timeout > > > > logic with a single universal long timeout, and found that makes > > > > our TPMs 100% reliable. > > > > > > > > Given that this timeout logic is very complex, problematic, and > > > > appears to serve no real purpose, I propose simply deleting all > > > > of it. > > > > > > "no real purpose" is a bit strong given that all these timeouts are > > > standards mandated. The purpose stated by the standards is that > > > there needs to be a way of differentiating the TPM crashed from the > > > TPM is taking a very long time to respond. For a normally > > > functioning TPM it looks complex and unnecessary, but for a > > > malfunctioning one it's a lifesaver. > > > > Standards should be only followed when they make practical sense and > > ignored when not. The range is only up to 2s anyway. > > I don't disagree ... and I'm certainly not going to defend the TCG > because I do think the complexity of some of its standards contributed > to the lack of use of TPM 1.2. > > However, I am saying we should root cause this problem rather than take > a blind shot at the apparent timeout complexity. My timeout > instability is definitely related to the polling adjustments, so it's > not unreasonable to think Facebooks might be as well. Yeah, referring to my review comment, I think the very first thing that should be done is to split patch into two. Then we can probably give better feedback. /Jarkko
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 16:33:15, Michal Hocko wrote: > On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > > Yeah, killing speed is a well-known problem which we are considering > > > > in LMKD. For example the recent LMKD change to assign process being > > > > killed to a cpuset cgroup containing big cores cuts the kill time > > > > considerably. This is not ideal and we are thinking about better ways > > > > to expedite the cleanup process. > > > > > > If you design is relies on the speed of killing then it is fundamentally > > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > > It might be blocked in an uninterruptible sleep or performin an > > > operation which takes some time. Sure, oom_reaper might help here but > > > still. > > > > Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just > > needs someone to do the work. > > They can and should as much as possible. No question about that. But not > all of them can and that is why nobody should be relying on that. That > is the whole point of having the oom_reaper and async oom victim tear > down. Let me clarify a bit. LMK obviously doesn't need any guarantee like the core oom killer because it is more of a pro-active measure than the last resort. I merely wanted to say that relying on a design which assumes anything about time victim needs to exit is flawed and it will fail under different workloads. On the other hand this might work good enough on very specific workloads to be usable. I am not questioning that. The point is that this is not generic enough to be accepted to the upstream kernel. -- Michal Hocko SUSE Labs
Re: [PATCH] pinctrl: baytrail: Fix potential NULL pointer dereference
On Tue, Mar 12, 2019 at 10:05:52AM -0500, Aditya Pakki wrote:
> saved-context in byt_gpio_probe is allocated via devm_kcalloc and is
> used without checking for NULL in later functions. This patch avoids
> such a scenario.
>
Thanks.
I take it to our branch after merge window will be finished.
> Signed-off-by: Aditya Pakki
> ---
> drivers/pinctrl/intel/pinctrl-baytrail.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c
> b/drivers/pinctrl/intel/pinctrl-baytrail.c
> index 241384ead4ed..18d9ad504194 100644
> --- a/drivers/pinctrl/intel/pinctrl-baytrail.c
> +++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
> @@ -1710,6 +1710,8 @@ static int byt_gpio_probe(struct byt_gpio *vg)
> #ifdef CONFIG_PM_SLEEP
> vg->saved_context = devm_kcalloc(>pdev->dev, gc->ngpio,
> sizeof(*vg->saved_context), GFP_KERNEL);
> + if (!vg->saved_context)
> + return -ENOMEM;
> #endif
> ret = devm_gpiochip_add_data(>pdev->dev, gc, vg);
> if (ret) {
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 04/14] pinctrl: sunxi: v3: really introduce support for V3
On Tue, Mar 12, 2019 at 11:22:46PM +0800, Icenowy Zheng wrote:
> Introduce the GPIO pins that is only available on V3 (not on V3s) to the
> V3 pinctrl driver.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c | 291 +--
> drivers/pinctrl/sunxi/pinctrl-sunxi.h| 2 +
> 2 files changed, 275 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
> index 6704ce8e5e3d..54c210871a95 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
> @@ -1,5 +1,5 @@
> /*
> - * Allwinner V3s SoCs pinctrl driver.
> + * Allwinner V3/V3s SoCs pinctrl driver.
> *
> * Copyright (C) 2016 Icenowy Zheng
> *
> @@ -23,7 +23,7 @@
>
> #include "pinctrl-sunxi.h"
>
> -static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
> +static const struct sunxi_desc_pin sun8i_v3_v3s_pins[] = {
I'm not sure all that remaining is worth it to be honest. It adds a
lot of noise for no particular reason (and the same goes for renaming
the file itself).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH] rcu/tree: Fix self wakeups for grace period kthread
On Tue, Mar 12, 2019 at 10:56:08AM -0400, Steven Rostedt wrote: > On Tue, 12 Mar 2019 07:09:23 -0700 > "Paul E. McKenney" wrote: > > > On Tue, Mar 12, 2019 at 05:25:28PM +0530, Neeraj Upadhyay wrote: > > > On 3/12/19 7:20 AM, Steven Rostedt wrote: > > > >On Fri, 8 Mar 2019 15:16:18 +0530 > > > >Neeraj Upadhyay wrote: > > > > > > > >>Update the code to match the comment that self wakeup of > > > >>grace period kthread is allowed from interrupt handler, and > > > >>softirq handler, running in the grace period kthread's > > > >>context. Present code allows self wakeups from all > > > >>interrupt contexts - nmi, softirq and hardirq contexts. > > > > > > > >That's not actually the issue. But it appears that we return if we > > > >simply have BH disabled, which I don't think we want, and we don't care > > > >about NMI as NMI should never call this code. > > > > > > > >I think your patch is correct, but the change log is not. > > > > How about this? > > > > The current rcu_gp_kthread_wake() function uses in_interrupt() > > and thus does a self-wakeup from all interrupt contexts, > > including the pointless case where the GP kthread happens to be > > running with bottom halves disabled, along with the impossible > > case where the GP kthread is running within an NMI handler (you > > are not supposed to invoke rcu_gp_kthread_wake() from within an > > NMI handler. This commit therefore replaces the in_interrupt() > > with in_irq(), so that the self-wakeups happen only from handlers > > for hardware interrupts and softirqs. This also makes the code > > match the comment. > > Acked-by: Steven Rostedt (VMware) Applied, thank you! Thanx, Paul > > > >-- Steve > > > > > > > > > > Hi Steve, sorry, I don't understand fully, why we want to not return > > > in BH disabled case. From the commit logs and lkml discussion, there > > > is a case where GP kthread is interrupted in the wait event path and > > > rcu_gp_kthread_wake() is called in softirq handler (I am not sure > > > about interrupt handler case; how rcu_gp_kthread_wake() is called > > > from that path). > > BH disabled case isn't a case where the kthread is preempted. It's just > that the kthread disabled BH, and thus we want to return. > > -- Steve >
RE: [PATCH] infiniband: i40iw: fix potential NULL pointer dereferences
>Subject: [PATCH] infiniband: i40iw: fix potential NULL pointer dereferences
>
>alloc_ordered_workqueue may fail and return NULL. Let's check its return value
>to ensure it is not NULL so as to avoid potential NULL pointer dereferences.
>
>Signed-off-by: Kangjie Lu
>---
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 12
> 1 file changed, 12 insertions(+)
>
>diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>index 206cfb0016f8..ad9b4f235e30 100644
>--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>@@ -3256,9 +3256,21 @@ void i40iw_setup_cm_core(struct i40iw_device
>*iwdev)
>
> cm_core->event_wq = alloc_ordered_workqueue("iwewq",
> WQ_MEM_RECLAIM);
>+ if (!cm_core->event_wq) {
>+ i40iw_debug(cm_core->dev,
>+ I40IW_DEBUG_CM,
>+ "%s allocate event work queue failed\n",
>+ __func__);
>+ }
>
> cm_core->disconn_wq = alloc_ordered_workqueue("iwdwq",
> WQ_MEM_RECLAIM);
>+ if (!cm_core->disconn_wq) {
>+ i40iw_debug(cm_core->dev,
>+ I40IW_DEBUG_CM,
>+ "%s allocate disconnect work queue failed\n",
>+ __func__);
>+ }
> }
Hi Kangjie - Just doing a debug print doesn't suffice. We need to fail the
i40iw_open() and unwind correctly.
Perhaps something like this would be required.
diff --git a/drivers/infiniband/hw/i40iw/i40iw.h
b/drivers/infiniband/hw/i40iw/i40iw.h
index 2f2b442..8feec35 100644
--- a/drivers/infiniband/hw/i40iw/i40iw.h
+++ b/drivers/infiniband/hw/i40iw/i40iw.h
@@ -552,7 +552,7 @@ enum i40iw_status_code i40iw_obj_aligned_mem(struct
i40iw_device *iwdev,
void i40iw_request_reset(struct i40iw_device *iwdev);
void i40iw_destroy_rdma_device(struct i40iw_ib_device *iwibdev);
-void i40iw_setup_cm_core(struct i40iw_device *iwdev);
+int i40iw_setup_cm_core(struct i40iw_device *iwdev);
void i40iw_cleanup_cm_core(struct i40iw_cm_core *cm_core);
void i40iw_process_ceq(struct i40iw_device *, struct i40iw_ceq *iwceq);
void i40iw_process_aeq(struct i40iw_device *);
diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 206cfb0..dcc5fea 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -3237,7 +3237,7 @@ void i40iw_receive_ilq(struct i40iw_sc_vsi *vsi, struct
i40iw_puda_buf *rbuf)
* core
* @iwdev: iwarp device structure
*/
-void i40iw_setup_cm_core(struct i40iw_device *iwdev)
+int i40iw_setup_cm_core(struct i40iw_device *iwdev)
{
struct i40iw_cm_core *cm_core = >cm_core;
@@ -3256,9 +3256,20 @@ void i40iw_setup_cm_core(struct i40iw_device *iwdev)
cm_core->event_wq = alloc_ordered_workqueue("iwewq",
WQ_MEM_RECLAIM);
-
+ if (!cm_core->event_wq)
+ goto error;
+
cm_core->disconn_wq = alloc_ordered_workqueue("iwdwq",
WQ_MEM_RECLAIM);
+ if (!cm_core->disconn_wq)
+ goto error;
+
+ return 0;
+error:
+ i40iw_cleanup_cm_core(>cm_core);
+ i40iw_pr_err("fail to setup CM core");
+
+ return -ENOMEM;
}
/**
@@ -3278,8 +3289,10 @@ void i40iw_cleanup_cm_core(struct i40iw_cm_core *cm_core)
del_timer_sync(_core->tcp_timer);
spin_unlock_irqrestore(_core->ht_lock, flags);
- destroy_workqueue(cm_core->event_wq);
- destroy_workqueue(cm_core->disconn_wq);
+ if (cm_core->event_wq)
+ destroy_workqueue(cm_core->event_wq);
+ if (cm_core->disconn_wq)
+ destroy_workqueue(cm_core->disconn_wq);
}
/**
diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c
b/drivers/infiniband/hw/i40iw/i40iw_main.c
index 68095f0..10932ba 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_main.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_main.c
@@ -1641,7 +1641,10 @@ static int i40iw_open(struct i40e_info *ldev, struct
i40e_client *client)
iwdev = >device;
iwdev->hdl = hdl;
dev = >sc_dev;
- i40iw_setup_cm_core(iwdev);
+ if (i40iw_setup_cm_core(iwdev)) {
+ kfree(iwdev->hdl);
+ return -ENOMEM;
+ }
dev->back_dev = (void *)iwdev;
iwdev->ldev = >ldev;
--
1.8.3.1
Shiraz
Re: [PATCH v3 0/1] mm: introduce put_user_page*(), placeholder versions
On Tue, Mar 12, 2019 at 04:52:07AM +, Christopher Lameter wrote: > On Fri, 8 Mar 2019, Jerome Glisse wrote: > > > > > > > It would good if that understanding would be enforced somehow given the > > > problems > > > that we see. > > > > This has been discuss extensively already. GUP usage is now widespread in > > multiple drivers, removing that would regress userspace ie break existing > > application. We all know what the rules for that is. > > The applications that work are using anonymous memory and memory > filesystems. I have never seen use cases with a real filesystem and would > have objected if someone tried something crazy like that. > > Because someone was able to get away with weird ways of abusing the system > it not an argument that we should continue to allow such things. In fact > we have repeatedly ensured that the kernel works reliably by improving the > kernel so that a proper failure is occurring. Driver doing GUP on mmap of regular file is something that seems to already have widespread user (in the RDMA devices at least). So they are active users and they were never told that what they are doing was illegal. Note that i am personaly fine with breaking device driver that can not abide by mmu notifier but the consensus seems that it is not fine to do so. > > > > In fact, the GUP documentation even recommends that pattern. > > > > > > Isnt that pattern safe for anonymous memory and memory filesystems like > > > hugetlbfs etc? Which is the common use case. > > > > Still an issue in respect to swapout ie if anon/shmem page was map > > read only in preparation for swapout and we do not report the page > > as dirty what endup in swap might lack what was written last through > > GUP. > > Well swapout cannot occur if the page is pinned and those pages are also > often mlocked. I would need to check the swapout code but i believe the write to disk can happen before the pin checks happens. I believe the event flow is: map read only, allocate swap, write to disk, try to free page which checks for pin. So that you could write stale data to disk and the GUP going away before you perform the pin checks. They are other thing to take into account and that need proper page dirtying, like soft dirtyness for instance. > > > > > > Yes you now have the filesystem as well as the GUP pinner claiming > > > authority over the contents of a single memory segment. Maybe better not > > > allow that? > > > > This goes back to regressing existing driver with existing users. > > There is no regression if that behavior never really worked. Well RDMA driver maintainer seems to report that this has been a valid and working workload for their users. > > > Two filesystem trying to sync one memory segment both believing to have > > > exclusive access and we want to sort this out. Why? Dont allow this. > > > > This is allowed, it always was, forbidding that case now would regress > > existing application and it would also means that we are modifying the > > API we expose to userspace. So again this is not something we can block > > without regressing existing user. > > We have always stopped the user from doing obviously stupid and risky > things. It would be logical to do it here as well. While i would rather only allow device that can handle mmu notifier it is just not acceptable to regress existing user and they do seem to exist and had working setup going on for a while. Cheers, Jérôme
Re: [RESEND PATCH] mm/hotplug: don't reset pagetype flags for offline
On Sun, Mar 10, 2019 at 04:01:02PM -0400, Qian Cai wrote:
> The commit f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded
> memory to zones until online") introduced move_pfn_range_to_zone() which
> calls memmap_init_zone() during onlining a memory block.
> memmap_init_zone() will reset pagetype flags and makes migrate type to
> be MOVABLE.
>
> However, in __offline_pages(), it also call undo_isolate_page_range()
> after offline_isolated_pages() to do the same thing. Due to
> the commit 2ce13640b3f4 ("mm: __first_valid_page skip over offline
> pages") changed __first_valid_page() to skip offline pages,
> undo_isolate_page_range() here just waste CPU cycles looping around the
> offlining PFN range while doing nothing, because __first_valid_page()
> will return NULL as offline_isolated_pages() has already marked all
> memory sections within the pfn range as offline via
> offline_mem_sections().
>
> Also, after calling the "useless" undo_isolate_page_range() here, it
> reaches the point of no returning by notifying MEM_OFFLINE. Those pages
> will be marked as MIGRATE_MOVABLE again once onlining. In addition, fix
> an incorrect comment along the way.
>
> Signed-off-by: Qian Cai
Reviewed-by: Oscar Salvador
One thing I noticed when looking at start_isolate_page_range and
undo_isolate_page_range functions, is that start_isolate_page_range increments
the number of isolated pageblocks, while undo_isolate_page_range does the
counter
part.
Since undo_isolate_page_range is really never called during offlining,
we leave zone->nr_isolate_pageblock with a stale value.
I __think__ this does not matter much.
We only get to check whether a zone got isolated pageblocks in
has_isolate_pageblock(), and this is called from:
free_one_page
free_pcppages_bulk
__free_one_page
With a quick glance, the only difference in has_isolate_pageblock() returning
true or false, seems to be that those functions perform some extra checks in
case the zone reports to have isolated pageblocks.
I wonder if we should set nr_isolate_pageblock back to its original value
before start_isolate_page_range.
> ---
> mm/memory_hotplug.c | 2 --
> mm/sparse.c | 2 +-
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 6b05576fb4ec..46017040b2f8 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1655,8 +1655,6 @@ static int __ref __offline_pages(unsigned long
> start_pfn,
> /* Ok, all of our target is isolated.
> We cannot do rollback at this point. */
> offline_isolated_pages(start_pfn, end_pfn);
> - /* reset pagetype flags and makes migrate type to be MOVABLE */
> - undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
> /* removal success */
> adjust_managed_page_count(pfn_to_page(start_pfn), -offlined_pages);
> zone->present_pages -= offlined_pages;
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 77a0554fa5bd..b3771f35a0ed 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -556,7 +556,7 @@ void online_mem_sections(unsigned long start_pfn,
> unsigned long end_pfn)
> }
>
> #ifdef CONFIG_MEMORY_HOTREMOVE
> -/* Mark all memory sections within the pfn range as online */
> +/* Mark all memory sections within the pfn range as offline */
> void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> {
> unsigned long pfn;
> --
> 2.17.2 (Apple Git-113)
>
--
Oscar Salvador
SUSE L3
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > Yeah, killing speed is a well-known problem which we are considering > > > in LMKD. For example the recent LMKD change to assign process being > > > killed to a cpuset cgroup containing big cores cuts the kill time > > > considerably. This is not ideal and we are thinking about better ways > > > to expedite the cleanup process. > > > > If you design is relies on the speed of killing then it is fundamentally > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > It might be blocked in an uninterruptible sleep or performin an > > operation which takes some time. Sure, oom_reaper might help here but > > still. > > Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just > needs someone to do the work. They can and should as much as possible. No question about that. But not all of them can and that is why nobody should be relying on that. That is the whole point of having the oom_reaper and async oom victim tear down. -- Michal Hocko SUSE Labs
[PATCH 13/14] ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support
The Allwinner V3/V3s/S3L/SoChip S3 Ethernet MAC and internal PHY is quite
similar to the ones on Allwinner H3, except for V3s the external MII is
not wired out.
Add ethernet support to V3/V3s/S3/S3L.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3.dtsi | 13
arch/arm/boot/dts/sun8i-v3s.dtsi | 52
2 files changed, 65 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3.dtsi b/arch/arm/boot/dts/sun8i-v3.dtsi
index 6ae8645ade50..ca4672ed2e02 100644
--- a/arch/arm/boot/dts/sun8i-v3.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3.dtsi
@@ -9,6 +9,19 @@
compatible = "allwinner,sun8i-v3-ccu";
};
+ {
+ /delete-property/ phy-handle;
+ /delete-property/ phy-mode;
+};
+
+_mux {
+ external_mdio: mdio@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
+
{
compatible = "allwinner,sun8i-v3-pinctrl";
};
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 10795b5ec376..0f179785be81 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -141,6 +141,15 @@
};
};
+ syscon: system-control@1c0 {
+ compatible = "allwinner,sun8i-v3s-system-control",
+"allwinner,sun8i-h3-system-control";
+ reg = <0x01c0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun8i-v3s-tcon";
reg = <0x01c0c000 0x1000>;
@@ -411,6 +420,49 @@
#size-cells = <0>;
};
+ emac: ethernet@1c3 {
+ compatible = "allwinner,sun8i-v3s-emac";
+ syscon = <>;
+ reg = <0x01c3 0x1>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ resets = < RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = < CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ phy-handle = <_mii_phy>;
+ phy-mode = "mii";
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
+
+ mdio_mux: mdio-mux {
+ compatible = "allwinner,sun8i-h3-mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-parent-bus = <>;
+ /* Only one MDIO is usable at the time */
+ internal_mdio: mdio@1 {
+ compatible =
"allwinner,sun8i-h3-mdio-internal";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ int_mii_phy: ethernet-phy@1 {
+ compatible =
"ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = < CLK_BUS_EPHY>;
+ resets = < RST_BUS_EPHY>;
+ };
+ };
+ };
+ };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.18.1
Re: [PATCH v2 2/5] auxdisplay: charlcd: Move to_priv() to charlcd namespace
On Tue, Mar 12, 2019 at 04:07:37PM +0100, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Tue, Mar 12, 2019 at 3:44 PM Andy Shevchenko
> wrote:
> > In order to be more particular in names, rename to_priv() macro
> > to charlcd_to_priv().
>
> As this is a macro, not a function, the name doesn't end up as a symbol in
> the binary anyway, and it's for internal use by the driver only.
I understand this, and I did in order to avoid potential collisions
in the future.
>
> > No functional change intended.
> >
> > Cc: Geert Uytterhoeven
> > Signed-off-by: Andy Shevchenko
>
> Regardless:
> Reviewed-by: Geert Uytterhoeven
Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] arm64: tegra: dts: enable aconnect, adma and agic
On 12/03/2019 14:25, Sameer Pujar wrote:
> Enable aconnect, adma and agic for Tegra Jetson TX1.
>
> Signed-off-by: Sameer Pujar
> ---
> arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> b/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> index 9fad0d2..5a57396 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> @@ -99,4 +99,16 @@
> pinctrl-0 = <_pwm_active_state>;
> pinctrl-1 = <_pwm_inactive_state>;
> };
> +
> + aconnect@702c {
> + status = "okay";
> +
> + dma@702e2000 {
> + status = "okay";
> + };
> +
> + agic@702f9000 {
> + status = "okay";
> + };
> + };
> };
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
Re: [PATCH] bus: tegra-aconnect: use devm_clk_*() helpers
On 12/03/2019 14:34, Sameer Pujar wrote: > aconnect bus driver is using pm_clk_*() for managing required clocks. With > this, clocks seem to be always ON. This happens because, the clock prepare > count is incremented in pm_clock_acquire() which is called during device > probe(). The count is decremented during remove(). Hence the prepare_count > for the clock is non-zero till the remove() gets executed. This is true for > BPMP managed clock sources, where clock enable and disable happens during > prepare and unprepare phases respectively. Thus clocks remain ON always and > that is why pm_clk_*() cannot be used on Tegra. Same comments here as for the ADMA patch. This is not completely true for all devices. > This patch replaces pm_clk_*() with devm_clk_*() and runtime PM callbacks > reflect this. System suspend/resume can use pm_runtime_force_suspend/resume You need to explain the last bit more. In fact I don't believe it belongs in this patch. Cheers Jon -- nvpublic
Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem
On Mon, Mar 11, 2019 at 08:13:53PM -0700, Dan Williams wrote: > On Thu, Mar 7, 2019 at 10:56 AM Jerome Glisse wrote: > > > > On Thu, Mar 07, 2019 at 09:46:54AM -0800, Andrew Morton wrote: > > > On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams > > > wrote: > > > > > > > My hesitation would be drastically reduced if there was a plan to > > > > avoid dangling unconsumed symbols and functionality. Specifically one > > > > or more of the following suggestions: > > > > > > > > * EXPORT_SYMBOL_GPL on all exports to avoid a growing liability > > > > surface for out-of-tree consumers to come grumble at us when we > > > > continue to refactor the kernel as we are wont to do. > > > > > > The existing patches use EXPORT_SYMBOL() so that's a sticking point. > > > Jerome, what would happen is we made these EXPORT_SYMBOL_GPL()? > > > > So Dan argue that GPL export solve the problem of out of tree user and > > my personnal experience is that it does not. The GPU sub-system has tons > > of GPL drivers that are not upstream and we never felt that we were bound > > to support them in anyway. We always were very clear that if you are not > > upstream that you do not have any voice on changes we do. > > > > So my exeperience is that GPL does not help here. It is just about being > > clear and ignoring anyone who does not have an upstream driver ie we have > > free hands to update HMM in anyway as long as we keep supporting the > > upstream user. > > > > That being said if the GPL aspect is that much important to some then > > fine let switch all HMM symbol to GPL. > > I should add that I would not be opposed to moving symbols to > non-GPL-only over time, but that should be based on our experience > with the stability and utility of the implementation. For brand new > symbols there's just no data to argue that we can / should keep the > interface stable, or that the interface exposes something fragile that > we'd rather not export at all. That experience gathering and thrash is > best constrained to upstream GPL-only drivers that are signing up to > participate in that maturation process. > > So I think it is important from a practical perspective and is a lower > risk way to run this HMM experiment of "merge infrastructure way in > advance of an upstream user". > > > > > * A commitment to consume newly exported symbols in the same merge > > > > window, or the following merge window. When that goal is missed revert > > > > the functionality until such time that it can be consumed, or > > > > otherwise abandoned. > > > > > > It sounds like we can tick this box. > > > > I wouldn't be too strick either, when adding something in release N > > the driver change in N+1 can miss N+1 because of bug or regression > > and be push to N+2. > > > > I think a better stance here is that if we do not get any sign-off > > on the feature from driver maintainer for which the feature is intended > > then we just do not merge. > > Agree, no driver maintainer sign-off then no merge. > > > If after few release we still can not get > > the driver to use it then we revert. > > As long as it is made clear to the driver maintainer that they have > one cycle to consume it then we can have a conversation if it is too > early to merge the infrastructure. If no one has time to consume the > feature, why rush dead code into the kernel? Also, waiting 2 cycles > means the infrastructure that was hard to review without a user is now > even harder to review because any review momentum has been lost by the > time the user show up, so we're better off keeping them close together > in time. Miss-understanding here, in first post the infrastructure and the driver bit get posted just like have been doing lately. So that you know that you have working user with the feature and what is left is pushing the driver bits throught the appropriate tree. So driver maintainer support is about knowing that they want the feature and have some confidence that it looks ready. It also means you can review the infrastructure along side user of it. > > > > It just feels dumb to revert at N+1 just to get it back in N+2 as > > the driver bit get fix. > > No, I think it just means the infrastructure went in too early if a > driver can't consume it in a development cycle. Lets revisit if it > becomes a problem in practice. Well that's just dumb to have hard guideline like that. Many things can lead to missing deadline. For instance bug i am refering too might have nothing to do with the feature, it can be something related to integrating the feature an unforseen side effect. So i believe a better guideline is that driver maintainer rejecting the feature rather than just failure to meet one deadline. > > > > * No new symbol exports and functionality while existing symbols go > > > > unconsumed. > > > > > > Unsure about this one? > > > > With nouveau upstream now everything is use. ODP will use some of the > > symbol too. PPC has patchset posted to use lot of HMM too. I
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > Yeah, killing speed is a well-known problem which we are considering > > in LMKD. For example the recent LMKD change to assign process being > > killed to a cpuset cgroup containing big cores cuts the kill time > > considerably. This is not ideal and we are thinking about better ways > > to expedite the cleanup process. > > If you design is relies on the speed of killing then it is fundamentally > flawed AFAICT. You cannot assume anything about how quickly a task dies. > It might be blocked in an uninterruptible sleep or performin an > operation which takes some time. Sure, oom_reaper might help here but > still. Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just needs someone to do the work.
Re: [PATCH 085/114] drivers: auxdisplay: Kconfig: pedantic formatting
Hi Enrico, On Mon, Mar 11, 2019 at 2:21 PM Enrico Weigelt, metux IT consult wrote: > > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. I am all for humor in the right places, but this does not even explain why this is being done nor what is being done. :) Also, "pretty" is not really a good description. Instead, please simply state that you are replacing spaces with tabs, or whatever you feel it is best, and if possible, what triggered this change (e.g. a reference to some discussion, or at least the motivation). > Signed-off-by: Enrico Weigelt, metux IT consult That Signed-off-by line looks wrong. It should only be your legal name. Thanks, Miguel
Re: [PATCH] dmaengine: tegra210-adma: use devm_clk_*() helpers
On 12/03/2019 14:35, Sameer Pujar wrote: > Usage of pm_clk_*() results in non-zero prepare_count for clocks and hence > module clocks remain ON always. This is not desired as it will leak power > unncessarily. This patch replaces pm_clk_*() with devm_clk_*() interface. Technically, this is not true for all devices. The actual problem here is that for some Tegra devices that use the BPMP co-processor to manage clocks, the clock are actually enabled during the prepare-phase and hence when using the pm-clocks framework they are never disabled for these devices. However, this is not the case for Tegra210 which does not use the BPMP for managing clocks. It maybe worth highlighting the fact the BPMP has to enable clocks during the prepare phase because calls to the BPMP are always blocking. > This helps to keep refcounts balanced when device is not in use and runtime > PM callbacks help to enable or disable clocks. System suspend/resume calls > can use pm_runtime_force_suspend/resume. I think that this last bit should be a separate patch as it has nothing to do with the $subject. Cheers Jon -- nvpublic
Re: [PATCH] kernel/trace/trace_kprobe.c - fix comment format
On Tue, 12 Mar 2019 05:08:30 -0400 valdis.kletni...@vt.edu wrote: > On Tue, 12 Mar 2019 04:58:32 -0400, "Valdis Klētnieks" said: > > > > CC kernel/trace/trace_kprobe.o > > kernel/trace/trace_kprobe.c:41: warning: cannot understand function > > prototype: 'struct trace_kprobe ' > > > > The real problem is that a comment looked like kerneldoc when it shouldn't > > be... > > After finding another case of this, it's debatable whether the *REAL* real > problem is that gcc is buggy/incomplete and doesn't know that kerneldoc > comments can be applied to structure definitions as well > > What's the consensus? Should I go yell at the gcc people instead, or? Nevermind, I mistook your patch as adding a kernel doc comment. It's fine, I'll take it. Thanks! -- Steve
Re: [PATCH] kernel/trace/trace_kprobe.c - fix comment format
On Tue, 12 Mar 2019 08:14:52 -0700 Randy Dunlap wrote: > > NACK. > > > > This isn't a kernel doc comment, and I don't want to make it one when > > it is not. Just ignore that warning. > > > > -- Steve > > Huh? The patch doesn't do that -- it does the opposite of that. > I.e., begin a non-kernel-doc comment with /* instead of /**. Ah, my head swapped the "-" to the "+". I thought the patch was adding the extra '*'. Nevermind, I'll take it. Thanks for pointing that out. Also, I'll change the subject to: trace/probes: Remove kernel doc style from non kernel doc comment -- Steve
Re: [PATCH tip/core/rcu 06/19] rcu: Add warning to detect half-interrupts
On Tue, Mar 12, 2019 at 11:05:14AM -0400, Joel Fernandes wrote:
> On Mon, Mar 11, 2019 at 03:29:03PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 11, 2019 at 09:39:39AM -0400, Joel Fernandes wrote:
> > > On Wed, Aug 29, 2018 at 03:20:34PM -0700, Paul E. McKenney wrote:
> > > > RCU's dyntick-idle code is written to tolerate half-interrupts, that it,
> > > > either an interrupt that invokes rcu_irq_enter() but never invokes the
> > > > corresponding rcu_irq_exit() on the one hand, or an interrupt that never
> > > > invokes rcu_irq_enter() but does invoke the "corresponding"
> > > > rcu_irq_exit()
> > > > on the other. These things really did happen at one time, as evidenced
> > > > by this ca-2011 LKML post:
> > > >
> > > > http://lkml.kernel.org/r/20111014170019.ge2...@linux.vnet.ibm.com
> > > >
> > > > The reason why RCU tolerates half-interrupts is that usermode helpers
> > > > used exceptions to invoke a system call from within the kernel such that
> > > > the system call did a normal return (not a return from exception) to
> > > > the calling context. This caused rcu_irq_enter() to be invoked without
> > > > a matching rcu_irq_exit(). However, usermode helpers have since been
> > > > rewritten to make much more housebroken use of workqueues, kernel
> > > > threads,
> > > > and do_execve(), and therefore should no longer produce half-interrupts.
> > > > No one knows of any other source of half-interrupts, but then again,
> > > > no one seems insane enough to go audit the entire kernel to verify that
> > > > half-interrupts really are a relic of the past.
> > > >
> > > > This commit therefore adds a pair of WARN_ON_ONCE() calls that will
> > > > trigger in the presence of half interrupts, which the code will continue
> > > > to handle correctly. If neither of these WARN_ON_ONCE() trigger by
> > > > mid-2021, then perhaps RCU can stop handling half-interrupts, which
> > > > would be a considerable simplification.
> > >
> > > Hi Paul and everyone,
> > > I was thinking some more about this patch and whether we can simplify
> > > this code
> > > much in 2021. Since 2021 is a bit far away, I thought working on it in
> > > again to
> > > keep it fresh in memory is a good idea ;-)
> >
> > Indeed, easy to forget. ;-)
> >
> > > To me it seems we cannot easily combine the counters (dynticks_nesting and
> > > dynticks_nmi_nesting) even if we confirmed that there is no possibility
> > > of a
> > > half-interrupt scenario (assuming simplication means counter combining
> > > like
> > > Byungchul tried to do in https://goo.gl/X1U77X). The reason is because
> > > these
> > > 2 counters need to be tracked separately as they are used differently in
> > > the
> > > following function:
> > >
> > > static int rcu_is_cpu_rrupt_from_idle(void)
> > > {
> > > return __this_cpu_read(rcu_data.dynticks_nesting) <= 0 &&
> > >__this_cpu_read(rcu_data.dynticks_nmi_nesting) <= 1;
> > > }
> > >
> > > dynticks_nesting actually tracks if we entered/exited idle or user mode.
> >
> > True, though it tracks user mode only in CONFIG_NO_HZ_FULL kernels.
> >
> > > dynticks_nmi_nesting tracks if we entered/exited interrupts.
> >
> > Including NMIs, yes.
> >
> > > We have to do the "dynticks_nmi_nesting <= 1" check because
> > > rcu_is_cpu_rrupt_from_idle() can possibly be called from an interrupt
> > > itself
> > > (like timer) so we discount 1 interrupt, and, the "dynticks_nesting <= 0"
> > > check is because the CPU MUST be in user or idle for the check to return
> > > true. We can't really combine these two into one counter then I think
> > > because
> > > they both convey different messages.
> > >
> > > The only simplication we can do, is probably the "crowbar" updates to
> > > dynticks_nmi_nesting can be removed from rcu_eqs_enter/exit once we
> > > confirm
> > > no more half-interrupts are possible. Which might still be a worthwhile
> > > thing
> > > to do (while still keeping both counters separate).
> > >
> > > However, I think we could combine the counters and lead to simplying the
> > > code
> > > in case we implement rcu_is_cpu_rrupt_from_idle differently such that it
> > > does
> > > not need the counters but NOHZ_FULL may take issue with that since it
> > > needs
> > > rcu_user_enter->rcu_eqs_enter to convey that the CPU is "RCU"-idle.
> >
> > I haven't gone through it in detail, but it seems like we should be able
> > to treat in-kernel process-level execution like an interrupt from idle
> > or userspace, as the case might be. If we did that, shouldn't we be
> > able to just do this?
> >
> > static int rcu_is_cpu_rrupt_from_idle(void)
> > {
> > return __this_cpu_read(rcu_data.dynticks_nmi_nesting) <= 1;
> > }
>
> I think that would work only if this function is always called from an
> interrupt:
>
> The comments on this function says:
> * If the current CPU is idle or running at a first-level (not nested)
> * interrupt from idle, return true. The caller
Re: [PATCH v7 01/15] sched/core: uclamp: Add CPU's clamp buckets refcounting
On Fri, Feb 08, 2019 at 10:05:40AM +, Patrick Bellasi wrote: > +/* Integer ceil-rounded range for each bucket */ > +#define UCLAMP_BUCKET_DELTA ((SCHED_CAPACITY_SCALE / UCLAMP_BUCKETS) + 1) Uhm, should that not me ((x+y-1)/y), aka. DIV_ROUND_UP(x,y) ? The above would give 4 for 9/3, which is clearly buggered.
[PATCH] pinctrl: axp209: Fix NULL pointer dereference after allocation
axp20x_build_funcs_groups allocates groups via devm_kcalloc and tries to dereference without checking for NULL. This patch avoids such a scenario. Signed-off-by: Aditya Pakki --- drivers/pinctrl/pinctrl-axp209.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pinctrl/pinctrl-axp209.c b/drivers/pinctrl/pinctrl-axp209.c index afd0b533c40a..4fcf7262bed9 100644 --- a/drivers/pinctrl/pinctrl-axp209.c +++ b/drivers/pinctrl/pinctrl-axp209.c @@ -366,6 +366,8 @@ static int axp20x_build_funcs_groups(struct platform_device *pdev) pctl->funcs[i].groups = devm_kcalloc(>dev, npins, sizeof(char *), GFP_KERNEL); + if (!pctl->funcs[i].groups) + return -ENOMEM; for (pin = 0; pin < npins; pin++) pctl->funcs[i].groups[pin] = pctl->desc->pins[pin].name; } -- 2.17.1
Re: [RFC PATCH v1 00/25] printk: new implementation
On 2019-03-12, Petr Mladek wrote: > Per-console kthread sounds interesting but there is the problem with > reliability. I mean that kthread need not get scheduled. > > Some of these problems might get solved by the per-console loglevel > patchset. > > Sigh, any feature might be useful in some situation. But we always > have to consider the cost and the gain. I wonder how common is > to actively use two consoles at the same time and what would > be the motivation. The following is from the linux-serial mailing list: "Re: Serial console is causing system lock-up" [0] I'm responding to it here because it really belongs in this thread. On 2019-03-12, Petr Mladek wrote: > On Tue 2019-03-12 09:17:49, John Ogness wrote: >> The current printk implementation is handling all console printing as >> best effort. Trying hard enough to dramatically affect the system, but >> not trying hard enough to guarantee success. > > I agree that direct output is more reliable. It might be very useful > for debugging some types of problems. The question is if it is worth > the cost (code complexity, serializing CPUs == slowing down the > entire system). > > But it is is possible that a reasonable offloading (in the direction > of last Sergey's approach) might be a better deal. > > > I suggest the following way forward (separate patchsets): > > 1. Replace log buffer (least controversial thing) Yes. I will post a series that only implements the ringbuffer using your simplified API. That will be enough to remove printk_safe and actually does most of the work of updating devkmsg, kmsg_dump, and syslog. > 2. Reliable offload to kthread (would be useful anyway) Yes. I would like to implement per-console kthreads for this series. I think the advantages are obvious. For PREEMPT_RT the offloading will need to be always active. (PREEMPT_RT cannot call the console->write() from atomic contexts.) But I think this would be acceptable at first. It would certainly be better than what PREEMPT_RT is doing now. > 3. Atomic consoles (a lot of tricky code, might not be > worth the effort) I think this will be necessary. PREEMPT_RT cannot support reliable emergency console messages without it. And for kernel developers this is also very helpful. People like PeterZ are using their own patches because the mainline kernel is not providing this functionality. The decision about _when_ to use it is still in the air. But I guess we'll worry about that when we get that far. There's enough to do until then. > Could we agree on this? I think this is a sane path forward. Thank you for providing some direction here. John Ogness [0] https://marc.info/?l=linux-serial=155239250721543
Re: [PATCH 1/2] Staging: rtl8723bs: os_dep: Fix several coding style errors
No problem. In a previous patch I had one for each item, but I thought it could be packed in a single one - and avoid '[PATCH n/m]'. Thanks. On 3/12/19, Dan Carpenter wrote: > On Tue, Mar 12, 2019 at 11:39:13AM -0300, Guilherme T Maeoka wrote: >> From: Guilherme T Maeoka >> >> Fix coding style errors and warns complained by checkpatck.pl. To list: >> >> - remove braces for single statements blocks, >> - add space required around operators, >> - replace spaces with tabs to indent, >> - add blank line after declarations, >> - fix braces and 'else' poistions in selection statements. >> > > I'm sorry you're going to have to break this up into multiple patches. > Probably one for each item on your list. > > regards, > dan carpenter > >
Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
Hi Geert, On 3/11/19 4:03 AM, Geert Uytterhoeven wrote: [ snip ] OK. Now about the actual solution: what is your opinion on embedding e.g. a squashfs image in the kernel instead, which would be a more generic solution, not adding more ABI to /proc? I'm not familiar enough with the intricacies of squashfs to have an educated opinion, but I hear that it's got its quirks (need for user-space tools, etc.) and possibly security issues. Also, I wonder whether it's a generalized solution that still kicks the ABI can down the road -- ultimately the kernel would still have a path/format/foo for making kheaders available in that squashfs image and that convention would become ABI. The only "benefit" being that said ABI wouldn't appear under /proc, and, tbh, I'm not sure that that's actually a benefit or is even idiomatic since kconfig.gz is already under /proc. To an extent, the precedent set by kconfig favors kheaders to also be available in the same location using a similar mechanism ... i.e. bonus points for consistency. But that's my hand-wavy gut-reaction response to your question. I'm sure others on this thread have far more informed opinions about the specifics than I could have. My priority was to clarify the basis for the need being addressed. Cheers, -- Karim Yaghmour CEO - Opersys inc. / www.opersys.com http://twitter.com/karimyaghmour
Re: [PATCH] kernel/trace/trace_kprobe.c - fix comment format
On 3/12/19 8:01 AM, Steven Rostedt wrote:
> On Tue, 12 Mar 2019 04:58:32 -0400
> "Valdis Klētnieks" wrote:
>
>> CC kernel/trace/trace_kprobe.o
>> kernel/trace/trace_kprobe.c:41: warning: cannot understand function
>> prototype: 'struct trace_kprobe '
>>
>> The real problem is that a comment looked like kerneldoc when it shouldn't
>> be...
>>
>> Signed-off-by: Valdis Kletnieks
>>
>> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
>> index 9eaf07f99212..c825c591553a 100644
>> --- a/kernel/trace/trace_kprobe.c
>> +++ b/kernel/trace/trace_kprobe.c
>> @@ -35,7 +35,7 @@ static struct dyn_event_operations trace_kprobe_ops = {
>> .match = trace_kprobe_match,
>> };
>>
>> -/**
>> +/*
>
> NACK.
>
> This isn't a kernel doc comment, and I don't want to make it one when
> it is not. Just ignore that warning.
>
> -- Steve
Huh? The patch doesn't do that -- it does the opposite of that.
I.e., begin a non-kernel-doc comment with /* instead of /**.
>
>> * Kprobe event core functions
>> */
>> struct trace_kprobe {
>
--
~Randy
[GIT PULL] UBI/UBIFS updates for 5.1-rc1
Linus, The following changes since commit a3b22b9f11d9fbc48b0291ea92259a5a810e9438: Linux 5.0-rc7 (2019-02-17 18:46:40 -0800) are available in the Git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-5.1-rc1 for you to fetch changes up to 5578e48e5c0bf4684e68ae08caa2293bfb3f5307: ubi: wl: Silence uninitialized variable warning (2019-03-05 21:21:07 +0100) This pull request contains updates for both UBI and UBIFS: - A new interface for UBI to deal better with read disturb - Reject unsupported ioctl flags in UBIFS (xfstests found it) Dan Carpenter (1): ubi: wl: Silence uninitialized variable warning Hou Tao (1): ubifs: Reject unsupported ioctl flags explicitly Richard Weinberger (2): ubi: Introduce in_pq() ubi: Expose the bitrot interface drivers/mtd/ubi/cdev.c | 30 drivers/mtd/ubi/ubi.h | 1 + drivers/mtd/ubi/wl.c| 174 ++-- fs/ubifs/ioctl.c| 8 ++ include/uapi/mtd/ubi-user.h | 5 ++ 5 files changed, 211 insertions(+), 7 deletions(-)
Re: [PATCH v9 perf,bpf 09/15] perf, bpf: save btf information as headers to perf.data
Em Mon, Mar 11, 2019 at 10:30:45PM -0700, Song Liu escreveu:
> This patch enables perf-record to save btf information as headers to
> perf.data A new header type HEADER_BPF_BTF is introduced for this data.
>
> Signed-off-by: Song Liu
> ---
> tools/perf/util/header.c | 101 ++-
> tools/perf/util/header.h | 1 +
> 2 files changed, 101 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index a4ef8f657ad0..7decd2d1dbda 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -905,6 +905,39 @@ static int write_bpf_prog_info(struct feat_fd *ff,
> return ret;
> }
>
> +static int write_bpf_btf(struct feat_fd *ff,
> + struct perf_evlist *evlist __maybe_unused)
> +{
> + struct perf_env *env = >ph->env;
> + struct rb_root *root;
> + struct rb_node *next;
> + int ret;
> +
> + down_read(>bpf_progs.lock);
> +
> + ret = do_write(ff, >bpf_progs.btfs_cnt,
> +sizeof(env->bpf_progs.btfs_cnt));
> +
> + if (ret < 0)
> + goto out;
> +
> + root = >bpf_progs.btfs;
> + next = rb_first(root);
> + while (next) {
> + struct btf_node *node;
> +
> + node = rb_entry(next, struct btf_node, rb_node);
> + next = rb_next(>rb_node);
> + ret = do_write(ff, >id,
> +sizeof(u32) * 2 + node->data_size);
> + if (ret < 0)
> + goto out;
> + }
> +out:
> + up_read(>bpf_progs.lock);
> + return ret;
> +}
> +
> static int cpu_cache_level__sort(const void *a, const void *b)
> {
> struct cpu_cache_level *cache_a = (struct cpu_cache_level *)a;
> @@ -1408,6 +1441,28 @@ static void print_bpf_prog_info(struct feat_fd *ff,
> FILE *fp)
> up_read(>bpf_progs.lock);
> }
>
> +static void print_bpf_btf(struct feat_fd *ff, FILE *fp)
> +{
> + struct perf_env *env = >ph->env;
> + struct rb_root *root;
> + struct rb_node *next;
> +
> + down_read(>bpf_progs.lock);
> +
> + root = >bpf_progs.btfs;
> + next = rb_first(root);
> +
> + while (next) {
> + struct btf_node *node;
> +
> + node = rb_entry(next, struct btf_node, rb_node);
> + next = rb_next(>rb_node);
> + fprintf(fp, "# btf info of id %u\n", node->id);
So, I couldn't get this to work right now, and I have BPF programs that
are loaded and that have BTF info:
[root@quaco ~]# bpftool prog | tail -6
208: tracepoint name sys_enter tag 819967866022f1e1 gpl
loaded_at 2019-03-12T11:16:55-0300 uid 0
xlated 528B jited 381B memlock 4096B map_ids 107,106,105
209: tracepoint name sys_exit tag c1bd85c092d6e4aa gpl
loaded_at 2019-03-12T11:16:55-0300 uid 0
xlated 256B jited 191B memlock 4096B map_ids 107,106
[root@quaco ~]#
[root@quaco ~]# bpftool map | tail -6
105: perf_event_array name __augmented_sys flags 0x0
key 4B value 4B max_entries 8 memlock 4096B
106: array name syscalls flags 0x0
key 4B value 1B max_entries 512 memlock 8192B
107: hash name pids_filtered flags 0x0
key 4B value 1B max_entries 64 memlock 8192B
[root@quaco ~]#
[root@quaco ~]# bpftool map dump id 107
[{
"key": 8104,
"value": true
},{
"key": 18868,
"value": true
}
]
[root@quaco ~]# ps ax|egrep 8104\|18868 | grep -v grep
8104 pts/8S+ 0:07 trace -e recvmmsg
18868 ?Ssl 21:21 /usr/libexec/gnome-terminal-server
[root@quaco ~]#
So I was expecting to see those btf lines there :-\
All the patches up to this point I have already merged and tested in my
local branch.
Will continue right after lunch to try to figure out why this BTF info
isn't landing on this new header feature...
- Arnaldo
> + }
> +
> + up_read(>bpf_progs.lock);
> +}
> +
> static void free_event_desc(struct perf_evsel *events)
> {
> struct perf_evsel *evsel;
> @@ -2509,6 +2564,49 @@ static int process_bpf_prog_info(struct feat_fd *ff,
> return err;
> }
>
> +static int process_bpf_btf(struct feat_fd *ff, void *data __maybe_unused)
> +{
> + struct perf_env *env = >ph->env;
> + u32 count, i;
> +
> + if (ff->ph->needs_swap) {
> + pr_warning("interpreting btf from systems with endianity is not
> yet supported\n");
> + return 0;
> + }
> +
> + if (do_read_u32(ff, ))
> + return -1;
> +
> + down_write(>bpf_progs.lock);
> +
> + for (i = 0; i < count; ++i) {
> + struct btf_node *node;
> + u32 id, data_size;
> +
> + if (do_read_u32(ff, ))
> + return -1;
> + if (do_read_u32(ff, _size))
> + return -1;
> +
> + node = malloc(sizeof(struct btf_node) + data_size);
> + if (!node)
> + return -1;
> +
> + node->id = id;
>
[GIT PULL] UML updates for 5.1-rc1
Linus, The following changes since commit 1c163f4c7b3f621efff9b28a47abb36f7378d783: Linux 5.0 (2019-03-03 15:21:29 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-5.1-rc1 for you to fetch changes up to aea05eb56e47046de1e5b508d40931dca969f1e5: um: Fix for a possible OOPS in ubd initialization (2019-03-06 22:39:18 +0100) This pull request contains updates for UML: - Bugfix for the UML block device driver Anton Ivanov (1): um: Fix for a possible OOPS in ubd initialization YueHaibing (1): um: Remove duplicated include from vector_user.c arch/um/drivers/ubd_kern.c| 6 +++--- arch/um/drivers/vector_user.c | 3 --- 2 files changed, 3 insertions(+), 6 deletions(-)
