Re: [PATCH] mfd: cros_ec: Add support for MKBP more event flags

2018-12-07 Thread Brian Norris
at is not necessarily something resolve in this patch), but with at least the cros_ec.h comment fixup, feel free to add my: Reviewed-by: Brian Norris > --- > drivers/mfd/cros_ec.c | 20 +-- > drivers/platform/chrome/cros_ec_proto.c | 33 +++--

Re: [PATCH v2] mwifiex: debugfs: correct histogram spacing, formatting

2018-12-06 Thread Brian Norris
On Tue, Dec 04, 2018 at 08:37:30AM +0200, Kalle Valo wrote: > Brian Norris writes: > > > Here's a v2 that combines both sets of strings in that way. I'm not > > resending the other patches, since they were only related in concept > > (since I was referring to debugfs for

[PATCH v3] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2018-11-14 Thread Brian Norris
ki Sky Cc: Christian Kujau Cc: Guenter Roeck Suggested-by: Alexander Kapshuk Signed-off-by: Brian Norris --- v1 -> v2: * handle empty (non-dirty) results properly, where echo "${empty_variable}" | grep -qv "${something_else}" always has a 0 exit status (a blank l

Re: [PATCH v2] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2018-11-14 Thread Brian Norris
On Tue, Nov 13, 2018 at 2:03 PM Andreas Schwab wrote: > > On Nov 13 2018, Brian Norris wrote: > > > + } | grep -qv '^\(.. \)\?scripts/package'; then > > \? is a GNU extension, so if you want to stay portable you need to > switch to ERE. Ack. That's what I get

[PATCH v2] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2018-11-13 Thread Brian Norris
ki Sky Cc: Christian Kujau Cc: Guenter Roeck Suggested-by: Alexander Kapshuk Signed-off-by: Brian Norris --- On Tue, Nov 13, 2018 at 10:32:16AM -0800, Brian Norris wrote: > I can submit it. I expect Masahiro-san would prefer a proper v2 patch > for review, given how much would change fro

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2018-11-13 Thread Brian Norris
Hi Alexander, On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk wrote: > > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris wrote: > > > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote: > > > An even simpler approach would be: > > > > >

Re: [PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2018-11-12 Thread Brian Norris
On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote: > An even simpler approach would be: > > { > git --no-optional-locks status -uno --porcelain 2>/dev/null || > git diff-index --name-only HEAD > } | grep -qv scripts/package && > printf '%s' -dirty > >

[PATCH] scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks

2018-11-09 Thread Brian Norris
er Roeck Signed-off-by: Brian Norris --- On Fri, Nov 09, 2018 at 11:55:26AM +0900, Masahiro Yamada wrote: > > On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson wrote: > > > On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote: > > > > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roec

Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check more robust"

2018-11-07 Thread Brian Norris
On Wed, Nov 7, 2018 at 1:18 PM Doug Anderson wrote: > On Wed, Nov 7, 2018 at 1:07 PM Genki Sky wrote: > > On Wed, 7 Nov 2018 12:55:14 -0800, Guenter Roeck wrote: > > > Ubuntu 16.04 ships with git version 2.7.4. > > > > Okay. I guess --no-optional-locks is a no-go then. > > In theory you could

[PATCH v2 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup

2018-11-07 Thread Brian Norris
/sys/power/wakeup_count to increase very frequently, often needlessly interrupting our ability to suspend the system. Signed-off-by: Brian Norris --- v1 -> v2: * no change --- drivers/platform/chrome/cros_ec_proto.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) d

[PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes

2018-11-07 Thread Brian Norris
). And fix the documentation of cros_ec_get_host_event() and cros_ec_get_next_event() to accurately describe their behavior. Signed-off-by: Brian Norris --- v1 -> v2: * don't make as many changes to the API -- just fix the documentation and a few corner cases instead --- drivers/platform/chrome/cr

Re: [PATCH 1/2] platform/chrome: fixup cros_ec_get_next_event() error codes

2018-11-07 Thread Brian Norris
On Wed, Nov 7, 2018 at 5:30 PM Brian Norris wrote: > > cros_ec_get_next_event() is documented to return 0 for success and > negative for errors. It currently returns negative for some errors, and > non-negative (number of bytes received) for success (including some "no > data

[PATCH 1/2] platform/chrome: fixup cros_ec_get_next_event() error codes

2018-11-07 Thread Brian Norris
(including EC_RES_UNAVAILABLE) are treated as "no data available." Signed-off-by: Brian Norris --- This barely touches MFD code, but overall this series should probably go through the platform/chrome maintenance, IMO. --- drivers/mfd/cros_ec.c | 4 ++-- drivers/platform/chrome/

[PATCH 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup

2018-11-07 Thread Brian Norris
/sys/power/wakeup_count to increase very frequently, often needlessly interrupting our ability to suspend the system. Signed-off-by: Brian Norris --- drivers/platform/chrome/cros_ec_proto.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/platform

[PATCH] input: cros_ec_keyb: fix button/switch capability reports

2018-11-07 Thread Brian Norris
OS kernel to be upstreamed. Fixes: cdd7950e7aa4 ("input: cros_ec_keyb: Add non-matrix buttons and switches") Cc: Cc: Douglas Anderson Cc: Enric Balletbo i Serra Signed-off-by: Brian Norris --- drivers/input/keyboard/cros_ec_keyb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH] input: cros_ec_keyb: fix button/switch capability reports

2018-11-07 Thread Brian Norris
OS kernel to be upstreamed. Fixes: cdd7950e7aa4 ("input: cros_ec_keyb: Add non-matrix buttons and switches") Cc: Cc: Douglas Anderson Cc: Enric Balletbo i Serra Signed-off-by: Brian Norris --- drivers/input/keyboard/cros_ec_keyb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check more robust"

2018-11-07 Thread Brian Norris
On Tue, Nov 06, 2018 at 08:00:36PM -0800, Brian Norris wrote: > On a different tangent: how about the --no-optional-locks (see > git(1))? Will this get you your "up-to-date" result without writing to > the .git directory? I've only read the documentation, but not tested >

Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check more robust"

2018-11-06 Thread Brian Norris
On Tue, Nov 6, 2018 at 6:58 PM Christian Kujau wrote: > FWIW, the issue I reported back in 2013[0] was not an ill-configured NFS > export, but a read-only NFS export (and then a read-write exported NFS > export, but the user compiling the kernel did not have write permission) > and so "test -w

Re: [PATCH] Revert "scripts/setlocalversion: git: Make -dirty check more robust"

2018-11-06 Thread Brian Norris
ev/null && ...) instead of $(test -w .git) to handle misconfigured > NFS setups. But not sure if that has its own problems. Trying to 'touch' the source tree will also break us. No matter whether you redirect stderr, our sandbox will still notice the build is doing something fishy and complain. In any case, I'd be very happy with a Revert for now (for 4.20, and even -stable), and a follow-up replacement, so: Reviewed-by: Brian Norris for the $subject patch.

Re: [PATCH] ath10k: avoid -Wmaybe-uninitialized warning

2018-11-02 Thread Brian Norris
Hi, On Fri, Nov 2, 2018 at 9:19 AM Arnd Bergmann wrote: > > In some configurations the inlining in gcc is suboptimal, causing > a false-positive warning: > > drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_init_rd': > drivers/net/wireless/ath/ath10k/mac.c:8374:39: error: 'rd' may

Re: [RFC PATCH v2] soc: qcom: rmtfs_mem: Control remoteproc from rmtfs_mem

2018-10-17 Thread Brian Norris
Hi Sibi, On Sun, Sep 30, 2018 at 09:26:46PM +0530, Sibi Sankar wrote: > From: Bjorn Andersson > > rmtfs_mem provides access to physical storage and is crucial for the > operation of the Qualcomm modem subsystem. > > The rmtfs_mem implementation must be available before the modem > subsystem is

Re: [RFC PATCH] soc: qcom: rmtfs_mem: Control remoteproc from rmtfs_mem

2018-10-17 Thread Brian Norris
Hi Sibi, On Sun, Sep 30, 2018 at 08:58:49PM +0530, Sibi Sankar wrote: > On 2018-09-25 22:59, Brian Norris wrote: > > On Tue, Sep 25, 2018 at 01:06:07AM -0700, Bjorn Andersson wrote: > > So rather than looking for open(), I think somebody needs to be looking > &g

Re: [RFC PATCH] soc: qcom: rmtfs_mem: Control remoteproc from rmtfs_mem

2018-10-17 Thread Brian Norris
Hi Bjorn, Sorry for getting back to this late. On Tue, Oct 02, 2018 at 12:34:45PM -0700, Bjorn Andersson wrote: > On Tue 25 Sep 10:29 PDT 2018, Brian Norris wrote: > For the record; I did consider making the rmtfs implementation the one > driving the remoteproc state through /

Re: [PATCH] remoteproc: qcom: q6v5: shore up resource probe handling

2018-10-09 Thread Brian Norris
On Tue, Oct 9, 2018 at 4:34 PM Doug Anderson wrote: > On Tue, Oct 9, 2018 at 3:33 PM Brian Norris wrote: > > + if (q6v5->wdog_irq < 0) { > > + if (q6v5->wdog_irq != -EPROBE_DEFER) > > + dev_err(>dev, > >

[PATCH] remoteproc: qcom: q6v5: shore up resource probe handling

2018-10-09 Thread Brian Norris
explicitly. Fixes: d5269c4553a6 ("remoteproc: qcom: q6v5: Propagate EPROBE_DEFER") Signed-off-by: Brian Norris --- drivers/remoteproc/qcom_q6v5.c | 44 +++--- 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/re

Re: [PATCH] remoteproc: qcom: q6v5-pil: add SCM probe dependency

2018-10-09 Thread Brian Norris
On Mon, Oct 08, 2018 at 11:21:25PM -0700, Bjorn Andersson wrote: > On Mon 08 Oct 19:08 PDT 2018, Brian Norris wrote: > > > Similar to qcom_q6v5_pas and qcom_wcnss drivers, probe will fail if SCM > > is not up. > > > > Thanks Brian, this dependency was introd

[PATCH] remoteproc: qcom: q6v5-pil: add SCM probe dependency

2018-10-08 Thread Brian Norris
Similar to qcom_q6v5_pas and qcom_wcnss drivers, probe will fail if SCM is not up. Signed-off-by: Brian Norris --- drivers/remoteproc/qcom_q6v5_mss.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c index

Re: [RFC PATCH] soc: qcom: rmtfs_mem: Control remoteproc from rmtfs_mem

2018-09-25 Thread Brian Norris
Hi Bjorn, On Tue, Sep 25, 2018 at 01:06:07AM -0700, Bjorn Andersson wrote: > rmtfs_mem provides access to physical storage and is crucial for the > operation of the Qualcomm modem subsystem. > > The rmtfs_mem implementation must be available before the modem > subsystem is booted and a solution

Re: [PATCH v3 2/7] firmware: coreboot: Unmap ioregion on failure

2018-08-09 Thread Brian Norris
Hi, On Thu, Aug 09, 2018 at 12:40:31PM -0700, Stephen Boyd wrote: > Quoting Brian Norris (2018-08-09 10:49:38) > > On Thu, Aug 09, 2018 at 10:17:17AM -0700, Stephen Boyd wrote: > > > Both callers of coreboot_table_init() ioremap the pointer that comes in > > > but

Re: [PATCH v3 0/7] firmware: coreboot: Fix probe and simplify code

2018-08-09 Thread Brian Norris
latform driver change > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > > Stephen Boyd (7): > firmware: coreboot: Let OF core populate platform device > firmware: coreboot: Unmap ioregion on failure > firmware: coreboot:

Re: [PATCH v3 2/7] firmware: coreboot: Unmap ioregion on failure

2018-08-09 Thread Brian Norris
mapping when it fails. Plug the leak so the mapping isn't left unused. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > Fixes: 570d30c2823f ("firmware: coreboot: Expose the coreboot table as a bus") I suppose this is fair,

Re: [PATCH v3 1/7] firmware: coreboot: Let OF core populate platform device

2018-08-09 Thread Brian Norris
e_node() which was originally done in probe(), and then of_find_node_by_path() in __init when it was upstreamed, and now it's no longer needed. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris > Cc: Samuel Holland > Reviewed-by: Sudeep Holla > F

Re: [PATCH] firmware: coreboot: Let OF core populate platform device

2018-08-09 Thread Brian Norris
On Tue, Aug 07, 2018 at 11:00:50PM -0700, Stephen Boyd wrote: > Quoting Brian Norris (2018-08-07 14:41:04) > > On Mon, Aug 06, 2018 at 10:10:47AM -0700, Stephen Boyd wrote: > > > @@ -44,8 +43,9 @@ static int coreboot_table_of_remove(struct > > > platform_device *pdev)

Re: [PATCH] firmware: coreboot: Let OF core populate platform device

2018-08-07 Thread Brian Norris
the same time, we can > move this driver to use platform device APIs instead of DT specific ones > and drop the of_node handling that was presumably placed there to hold a > reference to the DT node created during module init. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc:

Re: [PATCH] firmware: coreboot: Let OF core populate platform device

2018-08-06 Thread Brian Norris
resumably placed there to hold a > reference to the DT node created during module init. > > Cc: Wei-Ning Huang > Cc: Julius Werner > Cc: Brian Norris Reviewed-by: Brian Norris > Cc: Samuel Holland > Cc: Thierry Escande > Signed-off-by: Stephen Boyd > --- > driver

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

2018-07-25 Thread Brian Norris
Hi, On Wed, Jul 25, 2018 at 07:48:21AM +1000, NeilBrown wrote: > On Tue, Jul 24 2018, Brian Norris wrote: > > On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote: > >> On Tue, Jul 24 2018, Boris Brezillon wrote: > >> > On Tue, 24 Jul 2018 08:46:33 +1000 > &

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

2018-07-24 Thread Brian Norris
Hi Boris, On Tue, Jul 24, 2018 at 01:18:11AM +0200, Boris Brezillon wrote: > On Mon, 23 Jul 2018 15:06:43 -0700 > Brian Norris wrote: > > On Mon, Jul 23, 2018 at 1:10 PM, Boris Brezillon > > wrote: > > > but it still seems to improve things. Of course, that means the

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

2018-07-24 Thread Brian Norris
Hi, On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote: > On Tue, Jul 24 2018, Boris Brezillon wrote: > > On Tue, 24 Jul 2018 08:46:33 +1000 > > NeilBrown wrote: > >> One possibility that occurred to me when I was exploring this issue is > >> to revert to 3-byte mode whenever 4-byte was

Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to 3-byte addressing.

2018-07-23 Thread Brian Norris
Hi Neil, On Mon, Jul 23, 2018 at 2:45 PM, NeilBrown wrote: > On Mon, Jul 23 2018, Brian Norris wrote: >> On Mon, Apr 9, 2018 at 6:05 PM, NeilBrown wrote: >>> On Mon, Apr 09 2018, Marek Vasut wrote: >>>> On 04/08/2018 11:56 PM, NeilBrown wrote: >>&

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

2018-07-23 Thread Brian Norris
Hi Boris, On Mon, Jul 23, 2018 at 1:10 PM, Boris Brezillon wrote: > On Mon, 23 Jul 2018 11:13:50 -0700 > Brian Norris wrote: >> I noticed this got merged, but I wanted to put my 2 cents in here: > > I wish you had replied to this thread when it was posted (more than > 6 m

Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to 3-byte addressing.

2018-07-23 Thread Brian Norris
Hi, I'm a little late to this thread, but I recently noticed (and complained about) commit: 59b356ffd0b0 ("mtd: m25p80: restore the status of SPI flash when exiting"). On Mon, Apr 9, 2018 at 6:05 PM, NeilBrown wrote: > On Mon, Apr 09 2018, Marek Vasut wrote: > >> On 04/08/2018 11:56 PM,

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

2018-07-23 Thread Brian Norris
Hello, I noticed this got merged, but I wanted to put my 2 cents in here: On Wed, Dec 06, 2017 at 10:53:42AM +0800, Zhiqiang Hou wrote: > From: Hou Zhiqiang > > Restore the status to be compatible with legacy devices. > Take Freescale eSPI boot for example, it copies (in 3 Byte > addressing

Re: [PATCH] cfg80211: use IDA to allocate wiphy indeces

2018-06-29 Thread Brian Norris
Hi Johannes, On Fri, Jun 29, 2018 at 09:42:20AM +0200, Johannes Berg wrote: > On Wed, 2018-06-20 at 18:29 -0700, Brian Norris wrote: > > It's annoying to see the phy index increase arbitrarily, just because a > > device got removed and re-probed (e.g., during a device reset, or d

Re: [PATCH v4 12/12] mfd: cros_ec: Add throttler sub-device

2018-06-21 Thread Brian Norris
On Wed, Jun 20, 2018 at 06:52:37PM -0700, Matthias Kaehlcke wrote: > Instantiate the CrOS EC throttler if it is enabled in the kernel > configuration. > > Signed-off-by: Matthias Kaehlcke Reviewed-by: Brian Norris > --- > Changes in v4: > - register throttler in

Re: [PATCH v4 10/12] misc: throttler: Add core support for non-thermal throttling

2018-06-21 Thread Brian Norris
Hi, A few more things I noticed; probably my last thoughts on this particular patch; and I think I reviewed the rest: On Wed, Jun 20, 2018 at 06:52:35PM -0700, Matthias Kaehlcke wrote: > The purpose of the throttler is to provide support for non-thermal > throttling. Throttling is triggered by

[PATCH] ACPI / processor: Finish making acpi_processor_ppc_has_changed() void

2018-06-19 Thread Brian Norris
Commit bca5f557dcea ("ACPI / processor: Make acpi_processor_ppc_has_changed() void") changed one of the declarations of acpi_processor_ppc_has_changed() to return void, but the !CPU_FREQ version still return int. Let's return void to be consistent. Signed-off-by: Brian Norris --- in

Re: [PATCH v3 11/12] misc: throttler: Add Chrome OS EC throttler

2018-06-18 Thread Brian Norris
c Balletbo i Serra One suggestion, and otherwise: Reviewed-by: Brian Norris > --- > Changes in v3: > - change module license to GPL v2 as in the SPDX identifier > - don't instantiate the throttler through the DT (instantiation > by CrOS EC MFD in a separate patch) >

Re: [PATCH v3 12/12] mfd: cros_ec: Add throttler sub-device

2018-06-18 Thread Brian Norris
Hi, On Thu, Jun 14, 2018 at 12:47:12PM -0700, Matthias Kaehlcke wrote: > Instantiate the CrOS EC throttler if it is enabled in the kernel > configuration. > > Signed-off-by: Matthias Kaehlcke > --- > Changes in v3: > - patch added to series > > drivers/mfd/cros_ec.c | 16 > 1

Re: [PATCH v3 10/12] misc: throttler: Add core support for non-thermal throttling

2018-06-18 Thread Brian Norris
Hi Matthias, On Thu, Jun 14, 2018 at 12:47:10PM -0700, Matthias Kaehlcke wrote: > The purpose of the throttler is to provide support for non-thermal > throttling. Throttling is triggered by external event, e.g. the > detection of a high battery discharge current, close to the OCP limit > of the

Re: [PATCH v3 02/12] PM / devfreq: Fix handling of min/max_freq == 0

2018-06-18 Thread Brian Norris
devfreq bugfixes and features, and a small cpufreq helper fixup), and they seem pretty clear and good to me, aside from a minor error in the current subject (s/devfreg/devfreq/). So: Reviewed-by: Brian Norris

Re: [PATCH v3 01/12] PM / devfreq: Init user limits from OPP limits, not viceversa

2018-06-15 Thread Brian Norris
bility. > --- BTW, putting the '---' here means that stuff below it usually gets dropped when applied (e.g., with git-am). So it'll drop your Signed-off-by and Reviewed-by. Not a huge problem if the maintainers look out for that. > Signed-off-by: Matthias Kaehlcke > Reviewed-by: Chanwoo Ch

Re: [PATCH v2 10/11] dt-bindings: misc: add bindings for cros_ec_throttler

2018-06-12 Thread Brian Norris
Hi Rob, On Tue, Jun 12, 2018 at 01:10:11PM -0600, Rob Herring wrote: > On Thu, Jun 07, 2018 at 11:12:13AM -0700, Matthias Kaehlcke wrote: > > The cros_ec_throttler monitors events from the Chrome OS Embedded > > Controller to throttle the system if needed, using the mechanisms > > provided by the

Re: [PATCH 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-12 Thread Brian Norris
Eek, sorry this series should have subjects "[PATCH v5 X/2] ...". I can resend if really needed, but hopefully by now this is ready to go... Brian On Tue, Jun 12, 2018 at 1:20 PM, Brian Norris wrote: > This driver was originally submitted for the TI BQ20Z75 battery IC > (com

[PATCH 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"

2018-06-12 Thread Brian Norris
ng, so we can handle vendor specifics -- so document this. Language borrowed mostly from Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt Also fixup the example to use this property (it's already implying that it's "bq20z75@b"); fixup the node name to be generic ("battery&q

[PATCH 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-12 Thread Brian Norris
ue to use the existing TI command behaviors, and we effectively revert commit 17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess optional") to again make these commands required. [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf Signed-off-by: Brian Norris

Re: [PATCH v2 09/11] misc: throttler: Add core support for non-thermal throttling

2018-06-12 Thread Brian Norris
Hi, On Tue, Jun 12, 2018 at 10:11:40AM -0700, Matthias Kaehlcke wrote: > On Mon, Jun 11, 2018 at 06:49:13PM -0700, Brian Norris wrote: > > On Thu, Jun 07, 2018 at 11:12:12AM -0700, Matthias Kaehlcke wrote: > > > The purpose of the throttler is to provide support for non-therma

Re: [PATCH v2 09/11] misc: throttler: Add core support for non-thermal throttling

2018-06-11 Thread Brian Norris
Hi! A few comments, but I didn't get to finish a thorough review yet. On Thu, Jun 07, 2018 at 11:12:12AM -0700, Matthias Kaehlcke wrote: > The purpose of the throttler is to provide support for non-thermal > throttling. Throttling is triggered by external event, e.g. the > detection of a high

[PATCH v4 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-08 Thread Brian Norris
ue to use the existing TI command behaviors, and we effectively revert commit 17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess optional") to again make these commands required. [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf Signed-off-by: Brian Norris

[PATCH v4 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"

2018-06-08 Thread Brian Norris
", and because we've noticed there are some lingering TI specifics (in the manufacturer-specific portion of the SBS spec), we'd like to start using this property again to differentiate. Signed-off-by: Brian Norris Acked-by: Rhyland Klein Reviewed-by: Rob Herring --- v2: add Rhyland's Acked-by v3:

Re: [PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-06 Thread Brian Norris
Hi Phil, On Wed, Jun 06, 2018 at 10:03:59AM +0800, Phil Reid wrote: > On 2/06/2018 09:28, Brian Norris wrote: > > drivers/power/supply/sbs-battery.c | 54 +- > > 1 file changed, 46 insertions(+), 8 deletions(-) > > > > diff --git

Re: [PATCH V2] cros_ec_keyb: Mark cros_ec_keyb driver as wake enabled device.

2018-06-04 Thread Brian Norris
case EC_MKBP_EVENT_SWITCH: > /* > - * If EC is not the wake source, discard key state > + * If keyb is not wake enabled, discard key state s/keyb/keyboard/ Or, since this is talking about buttons and switches (which don't technically require th

[PATCH v3 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"

2018-06-01 Thread Brian Norris
", and because we've noticed there are some lingering TI specifics (in the manufacturer-specific portion of the SBS spec), we'd like to start using this property again to differentiate. Signed-off-by: Brian Norris Acked-by: Rhyland Klein --- v2: add Rhyland's Acked-by v3: no change --- .../devicet

[PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-01 Thread Brian Norris
etain the existing TI command behaviors. [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Acked-by: Rhyland Klein --- v2: * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[] * use if/else instead of switch/case v3: * pull 'return 0'

Re: [PATCH v2 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-01 Thread Brian Norris
Hi, On Fri, Jun 01, 2018 at 10:34:34AM -0700, Guenter Roeck wrote: > On Fri, Jun 01, 2018 at 10:23:59AM -0700, Brian Norris wrote: > > drivers/power/supply/sbs-battery.c | 54 +- > > 1 file changed, 46 insertions(+), 8 deletions(-) > > > >

[PATCH v2 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"

2018-06-01 Thread Brian Norris
", and because we've noticed there are some lingering TI specifics (in the manufacturer-specific portion of the SBS spec), we'd like to start using this property again to differentiate. Signed-off-by: Brian Norris Acked-by: Rhyland Klein --- v2: add Rhyland's Acked-by --- .../devicetree/bindings

[PATCH v2 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-06-01 Thread Brian Norris
etain the existing TI command behaviors. [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf Signed-off-by: Brian Norris --- v2: * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[] * use if/else instead of switch/case --- drivers/power/supply/sbs-battery.c | 54 +-

[PATCH 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"

2018-05-31 Thread Brian Norris
", and because we've noticed there are some lingering TI specifics (in the manufacturer-specific portion of the SBS spec), we'd like to start using this property again to differentiate. Cc: Rhyland Klein Signed-off-by: Brian Norris --- .../devicetree/bindings/power/supply/sbs_sbs-battery.txt

[PATCH 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

2018-05-31 Thread Brian Norris
etain the existing TI command behaviors. [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf Signed-off-by: Brian Norris --- drivers/power/supply/sbs-battery.c | 61 +- 1 file changed, 52 insertions(+), 9 deletions(-) diff --git a/drivers/power/supply/sbs-battery.c b/driv

[PATCH] mfd: cros_ec: retry commands when EC is known to be busy

2018-05-22 Thread Brian Norris
lues Fixes: 001dde9400d5 ("mfd: cros ec: spi: Fix "in progress" error signaling") Signed-off-by: Brian Norris <briannor...@chromium.org> --- drivers/mfd/cros_ec_spi.c | 24 drivers/platform/chrome/cros_ec_proto.c | 2 ++ 2 files changed

[PATCH] rtc: report time-retrieval errors when updating alarm

2018-05-21 Thread Brian Norris
propagate the error instead. Signed-off-by: Brian Norris <briannor...@chromium.org> --- drivers/rtc/interface.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index 7cbdc9228dd5..a4bdd8b5fe2e 100644 --- a/drivers/rtc/inter

Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware

2018-05-17 Thread Brian Norris
On Thu, May 17, 2018 at 6:41 PM, hl wrote: > On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote: >> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote: >>> DP firmware uses fixed phy config values to do training, but some >>> boards need to adjust these values to fit

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

2018-05-16 Thread Brian Norris
+ Kishon Hi, On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

2018-05-16 Thread Brian Norris
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead of relying on

Re: [PATCH 4.14 49/62] Bluetooth: btusb: Only check needs_reset_resume DMI table for QCA rome chipsets

2018-05-15 Thread Brian Norris
+ Guenter On Mon, May 14, 2018 at 08:49:05AM +0200, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. FYI, this backport is wrong. See below. > -- > > From: Hans de Goede > > commit

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

2018-05-10 Thread Brian Norris
+ irqchip maintainers [ irqchip is weird -- it's all over drivers/{pinctrl,gpio,irqchip}/ :D ] Hi Doug, On Tue, May 08, 2018 at 10:18:18PM -0700, Doug Anderson wrote: > On Tue, May 8, 2018 at 7:21 PM, JeffyChen wrote: > > On 05/09/2018 03:46 AM, Doug Anderson wrote:

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

2018-05-07 Thread Brian Norris
On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote: > On 05/08/2018 06:15 AM, Brian Norris wrote: > > On the other hand...this also implies there may be a race condition > > there, where we might lose an interrupt if there is an edge between the > > re-configur

Re: [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability

2018-05-07 Thread Brian Norris
upt capability, edge-sensitive > or level-sensitive interrupts, and interrupt polarity should be > completed prior to enabling the interrupts on Port A in order to prevent > spurious glitches on the interrupt lines to the interrupt controller." > > Reported-by: Brian Norris <briannor

Re: [PATCH] arm64: dts: rockchip: use canonical compatible for touchpad/touchscreen

2018-05-02 Thread Brian Norris
: Dmitry Torokhov <dmitry.torok...@gmail.com> I guess the other IDs are in the driver just for non-DT usage? Anyway, seems fine: Reviewed-by: Brian Norris <briannor...@chromium.org>

Re: [PATCH for-4.16 1/3] sysfs: improve devices-coredump description with user-space perspective

2018-03-15 Thread Brian Norris
On Thu, Mar 15, 2018 at 10:55:23AM +0100, Arend van Spriel wrote: > Instead of referring to kernel internals, describe the ABI from user-space > perspective to clarify what can be expected when using it. > > Signed-off-by: Arend van Spriel > --- >

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

2018-03-13 Thread Brian Norris
On Tue, Mar 13, 2018 at 1:50 PM, Anatolij Gustschin wrote: > On Tue, 13 Mar 2018 16:23:10 +0100 > Daniel Vetter dan...@ffwll.ch wrote: > ... >> Shouldn't we patch the drivers/gpu/drm/stm driver instead of the >> drivers/video one? fbdev is kinda a dead end and not for adding new hw

Re: [PATCH 1/2] watchdog: dw: RMW the control register

2018-03-09 Thread Brian Norris
On Fri, Mar 9, 2018 at 8:02 PM, Guenter Roeck <li...@roeck-us.net> wrote: > On 03/09/2018 07:28 PM, Brian Norris wrote: >> I guess I could mention it. I was assuming that was an intended behavior >> of the existing driver: that we set resp_mode=0 (via clobber), so we >>

[PATCH v2 2/2] watchdog: dw: save/restore control and timeout across suspend/resume

2018-03-09 Thread Brian Norris
Some platforms lose this state in suspend. It should be safe to do this unconditionally. Signed-off-by: Brian Norris <briannor...@chromium.org> Reviewed-by: Guenter Roeck <li...@roeck-us.net> --- v2: no change --- drivers/watchdog/dw_wdt.c | 9 + 1 file changed, 9 inserti

[PATCH v2 1/2] watchdog: dw: RMW the control register

2018-03-09 Thread Brian Norris
the response mode previously, to ensure we performed a system reset (we don't support an interrupt notification), so retain that explicitly. Signed-off-by: Brian Norris <briannor...@chromium.org> --- v2: * factor out helper * handle both start() and restart() cases * note the RESP_MODE ha

Re: [PATCH 1/2] watchdog: dw: RMW the control register

2018-03-09 Thread Brian Norris
Hi, On Fri, Mar 09, 2018 at 07:20:38PM -0800, Guenter Roeck wrote: > On 03/09/2018 06:44 PM, Brian Norris wrote: > > RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length > > of pulse to issue for system reset. We shouldn't clobber this value, > > be

Re: [PATCH 1/2] watchdog: dw: RMW the control register

2018-03-09 Thread Brian Norris
+ linux-rockchip (probably should have included in the first place) On Fri, Mar 9, 2018 at 6:44 PM, Brian Norris <briannor...@chromium.org> wrote: > RK3399 has rst_pulse_length in CONTROL_REG[4:2], determining the length > of pulse to issue for system reset. We shouldn't clobbe

[PATCH 2/2] watchdog: dw: save/restore control and timeout across suspend/resume

2018-03-09 Thread Brian Norris
Some platforms lose this state in suspend. It should be safe to do this unconditionally. Signed-off-by: Brian Norris <briannor...@chromium.org> --- drivers/watchdog/dw_wdt.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c

[PATCH 1/2] watchdog: dw: RMW the control register

2018-03-09 Thread Brian Norris
, and so we only fully reset after the watchdog fires a second time. If we retain the system default (010b, or 8 clock cycles), then the watchdog reset is much more reliable. Read-modify-write retains the system value and improves reset reliability. Signed-off-by: Brian Norris <brian

Re: [PATCH] usb: dwc3: core: power on PHYs before initializing core

2018-03-08 Thread Brian Norris
Hi, On Thu, Mar 08, 2018 at 12:43:40PM +0200, Felipe Balbi wrote: > William Wu writes: > > The dwc3_core_init() gets the PHYs and initializes the PHYs with > > the usb_phy_init() and phy_init() functions before initializing > > core, and power on the PHYs after core

Re: [PATCH v3 1/3] Input: gpio-keys - add support for wakeup event action

2018-03-02 Thread Brian Norris
gpio-keys input device for pen insert, may only want to wakeup > the system when ejecting the pen. > > Suggested-by: Brian Norris <briannor...@chromium.org> > Signed-off-by: Jeffy Chen <jeffy.c...@rock-chips.com> > --- > > Changes in v3: > Adding more comment

Re: [PATCH v2 05/10] video: add MIPI DSI host controller bridge

2018-03-02 Thread Brian Norris
On Fri, Mar 02, 2018 at 10:57:59AM -0800, Brian Norris wrote: > Hi, > > On Fri, Mar 02, 2018 at 04:44:06PM +0100, yannick fertre wrote: > > Add a Synopsys Designware MIPI DSI host bridge driver, based on the > > Rockchip version from rockchip/dw-mipi-dsi.c with phy & b

Re: [PATCH v2 05/10] video: add MIPI DSI host controller bridge

2018-03-02 Thread Brian Norris
Hi, On Fri, Mar 02, 2018 at 04:44:06PM +0100, yannick fertre wrote: > Add a Synopsys Designware MIPI DSI host bridge driver, based on the > Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. How many times are we going to allow copy-and-pasting the same driver? Last time we

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

2018-03-01 Thread Brian Norris
Hi, On Fri, Feb 23, 2018 at 06:04:22PM +0800, Jeffy Chen wrote: > On 02/13/2018 06:13 AM, Brian Norris wrote: > > > > > > > > if (bdata->gpiod) { > > > >+int active_low = gpiod_is_active_low(bdata->gpiod); > > > &g

Re: [PATCH 4.4 095/108] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

2018-02-28 Thread Brian Norris
eck wrote: >> > > On Fri, Feb 16, 2018 at 10:10:44AM -0800, Brian Norris wrote: >> > > > On Fri, Feb 16, 2018 at 07:48:50AM +0100, Greg Kroah-Hartman wrote: >> > > > > On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote: >> &

Re: [RESEND PATCH v3] rtc: cros-ec: return -ETIME when refused to set alarms in the past

2018-02-26 Thread Brian Norris
through a bit more testing to ensure it has resolved all the races I saw, but it's good on several of them: Reviewed-by: Brian Norris <briannor...@chromium.org> Tested-by: Brian Norris <briannor...@chromium.org> > --- > > Changes in v3: > Fix alarm time comparing. > > C

Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

2018-02-26 Thread Brian Norris
On Thu, Feb 22, 2018 at 11:14 PM, Hans de Goede <hdego...@redhat.com> wrote: > On 23-02-18 04:12, Brian Norris wrote: >> Hmm? I'm not sure I completely follow here when you say "he was not >> hitting the firmware loading race". If things were function

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

2018-02-26 Thread Brian Norris
Hi, On Fri, Feb 23, 2018 at 2:51 AM, Johannes Berg wrote: > On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote: > > > > > Well, that depends on the eye of the beholder I guess. From user-space > > > > perspective it is asynchronous regardless. A write access to

Re: [PATCH] rtc: cros-ec: return -ETIME when refused to set alarms in the past

2018-02-26 Thread Brian Norris
One last note: On Sun, Feb 25, 2018 at 04:18:02PM +0800, Jeffy Chen wrote: > We have a check in __rtc_set_alarm() to return -ETIME when the alarm > is in the past. > > Since accessing a Chrome OS EC based rtc is a slow operation, we should > do that check again inside of the EC rtc driver's

Re: [PATCH] rtc: cros-ec: return -ETIME when refused to set alarms in the past

2018-02-26 Thread Brian Norris
Hi Jeffy, A few corrections here. (Sorry, I didn't completely reread the driver here before sending.) On Mon, Feb 26, 2018 at 10:01:15AM -0800, Brian Norris wrote: > On Sun, Feb 25, 2018 at 04:18:02PM +0800, Jeffy Chen wrote: > > We have a check in __rtc_set_alarm() to return -E

Re: [PATCH] rtc: cros-ec: return -ETIME when refused to set alarms in the past

2018-02-26 Thread Brian Norris
Hi Jeffy, On Sun, Feb 25, 2018 at 04:18:02PM +0800, Jeffy Chen wrote: > We have a check in __rtc_set_alarm() to return -ETIME when the alarm > is in the past. > > Since accessing a Chrome OS EC based rtc is a slow operation, we should > do that check again inside of the EC rtc driver's

Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

2018-02-22 Thread Brian Norris
Hi Hans, Sorry if I'm a little slow to follow up here. This hasn't been my top priority... On Mon, Feb 19, 2018 at 11:17:24AM +0100, Hans de Goede wrote: > On 16-02-18 18:59, Brian Norris wrote: > > On Fri, Feb 16, 2018 at 01:10:20PM +0100, Hans de Goede wrote: > > > Ok, I've

  1   2   3   4   5   6   7   8   9   10   >