Re: [PATCH 1/3] serial: imx: fix error handling in console_setup

[Uwe Kleine-König]

On Wed, Nov 14, 2018 at 06:49:38PM +0100, Stefan Agner wrote:
> The ipg clock only needs to be unprepared in case preparing
> per clock fails. The ipg clock has already disabled at the point.
> 
> Fixes: 1cf93e0d5488 ("serial: imx: remove the uart_console() check")
> Signed-off-by: Stefan Agner 
> ---
>  drivers/tty/serial/imx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 0f67197a3783..313c3b1900a8 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -2068,7 +2068,7 @@ imx_uart_console_setup(struct console *co, char 
> *options)
>  
>   retval = clk_prepare(sport->clk_per);
>   if (retval)
> - clk_disable_unprepare(sport->clk_ipg);
> + clk_unprepare(sport->clk_ipg);

good catch,

Reviewed-by: Uwe Kleine-König 

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH 2/3] serial: imx: unprepare console clocks on remove

[Uwe Kleine-König]

On Wed, Nov 14, 2018 at 06:49:39PM +0100, Stefan Agner wrote:
> Currently imx_uart_console_setup() prepares clocks which do not
> get unprepared anywhere. Check whether the console has been used
> by testing if index is set and unprepare clocks in this case.
> 
> This makes sure that clocks are properly unprepared after the
> console device has been unbound.
> 
> Signed-off-by: Stefan Agner 
> ---
>  drivers/tty/serial/imx.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 313c3b1900a8..757c91e5105a 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -2085,7 +2085,7 @@ static struct console imx_uart_console = {
>   .data   = &imx_uart_uart_driver,
>  };
>  
> -#define IMX_CONSOLE  &imx_uart_console
> +#define IMX_CONSOLE  (&imx_uart_console)
>  
>  #ifdef CONFIG_OF
>  static void imx_uart_console_early_putchar(struct uart_port *port, int ch)
> @@ -2378,8 +2378,17 @@ static int imx_uart_probe(struct platform_device *pdev)
>  static int imx_uart_remove(struct platform_device *pdev)
>  {
>   struct imx_port *sport = platform_get_drvdata(pdev);
> + int ret;
> +
> + ret = uart_remove_one_port(&imx_uart_uart_driver, &sport->port);
> +
> + if (IS_ENABLED(CONFIG_SERIAL_IMX_CONSOLE) && IMX_CONSOLE->index >= 0) {
> + clk_unprepare(sport->clk_ipg);
> + clk_unprepare(sport->clk_per);
> + IMX_CONSOLE->index = -1;
> + }
>  
> - return uart_remove_one_port(&imx_uart_uart_driver, &sport->port);
> + return ret;

I doubt this is right. imx_uart_console_setup is called once, and
if the console is on (say) ttymxc0 you don't want to unprepare the
clocks if ttymxc3 gets unbound.

So I think this cleanup must go into imx_uart_exit().

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

[GIT PULL] GPIO fixes for the v4.20 series

[Linus Walleij]

Hi Linus,

here are a few collected GPIO fixes for the v4.20 series.
Minor stuff except the IDA leak which was kind of important
to fix. Also new maintainers, yay.

Please pull it in!

Yours,
Linus Walleij

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v4.20-2

for you to fetch changes up to 10547d956d590fbb846a7bd053a1dfc30e8f9a68:

  MAINTAINERS: Do maintain Intel GPIO drivers via separate tree
(2018-11-16 23:06:51 +0100)


GPIO fixes for the v4.20 series:

- Do not lose an IDA on the gpiochip register errorpath.

- Fix the PXA non-pincontrol GPIO-using platforms.

- Fix the direction on the mockup GPIO driver.

- Add some MAINTAINERS stuff: Bartosz stepped up as GPIO
  co-maintainer, and Andy established an Intel git tree.


Andy Shevchenko (1):
  MAINTAINERS: Do maintain Intel GPIO drivers via separate tree

Bartosz Golaszewski (2):
  MAINTAINERS: add myself as co-maintainer of gpiolib
  gpio: mockup: fix indicated direction

Robert Jarzmik (1):
  gpio: pxa: fix legacy non pinctrl aware builds again

Vladimir Zapolskiy (1):
  gpio: don't free unallocated ida on gpiochip_add_data_with_key()
error path

 MAINTAINERS| 34 ++
 drivers/gpio/gpio-mockup.c |  6 +++---
 drivers/gpio/gpio-pxa.c|  4 ++--
 drivers/gpio/gpiolib.c |  5 +++--
 4 files changed, 30 insertions(+), 19 deletions(-)

Re: [PATCH 4.19 00/42] 4.19.4-stable review

[Naresh Kamboju]

On Thu, 22 Nov 2018 at 00:36, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.19.4 release.
> There are 42 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Nov 23 18:31:31 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.4-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.4-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 2b8db8734888b00156c6afb235eda91aa71da503
git describe: v4.19.3-43-g2b8db8734888
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.3-43-g2b8db8734888


No regressions (compared to build v4.19.2-206-g73aa1c86c6ec)

No fixes (compared to build v4.19.2-206-g73aa1c86c6ec)

Ran 18944 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-hugetlb-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 1/1] ACPI / tables: add DSDT AmlCode new declaration name support

[Wang, Dongsheng]

Hello Robert,

Do you have any comments about this patch?
Thanks.


Cheers
Dongsheng

On 2018/11/13 18:46, Wang, Dongsheng wrote:
> The new naming rule is added in acpica version 20180427.
> So the dsdt aml code name changes from "AmlCode" to "dsdt_aml_code".
>
> The patch that introduces naming rules is:
> https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63b29626852a0b5f37
>
> Tested:
> ACPICA release version 20180427+.
> ARM64: QCOM QDF2400
> GCC: 4.8.5 20150623
>
> Signed-off-by: Wang Dongsheng 
> ---
>  drivers/acpi/Kconfig  |  2 +-
>  drivers/acpi/tables.c | 10 --
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 9705fc986da9..15ab53a52fdc 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -336,7 +336,7 @@ config ACPI_CUSTOM_DSDT_FILE
> See Documentation/acpi/dsdt-override.txt
>  
> Enter the full path name to the file which includes the AmlCode
> -   declaration.
> +   or dsdt_aml_code declaration.
>  
> If unsure, don't enter a file name.
>  
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index a3d012b08fc5..297020bbaade 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -713,6 +713,9 @@ acpi_os_physical_table_override(struct acpi_table_header 
> *existing_table,
> table_length);
>  }
>  
> +static void *amlcode __attribute__ ((weakref("AmlCode")));
> +static void *dsdt_amlcode __attribute__ ((weakref("dsdt_aml_code")));
> +
>  acpi_status
>  acpi_os_table_override(struct acpi_table_header *existing_table,
>  struct acpi_table_header **new_table)
> @@ -723,8 +726,11 @@ acpi_os_table_override(struct acpi_table_header 
> *existing_table,
>   *new_table = NULL;
>  
>  #ifdef CONFIG_ACPI_CUSTOM_DSDT
> - if (strncmp(existing_table->signature, "DSDT", 4) == 0)
> - *new_table = (struct acpi_table_header *)AmlCode;
> + if (!strncmp(existing_table->signature, "DSDT", 4)) {
> + *new_table = (struct acpi_table_header *)&amlcode;
> + if (!(*new_table))
> + *new_table = (struct acpi_table_header *)&dsdt_amlcode;
> + }
>  #endif
>   if (*new_table != NULL)
>   acpi_table_taint(existing_table);

Re: [PATCH] phy: mvebu-cp110-comphy: fix spelling in structure name

[Antoine Tenart]

Hi Miquel,

On Thu, Nov 22, 2018 at 09:19:09PM +0100, Miquel Raynal wrote:
> Rename the mvebu_comhy_conf structure to be mvebu_comphy_conf, which is
> probably what the original author meant.
> 
> Fixes: d0438bd6aa09 ("phy: add the mvebu cp110 comphy driver")

Could you drop the Fixes tag and send it again? The patch is not fixing
any bug within the driver.

> Signed-off-by: Miquel Raynal 
> ---
> 
> Sorry for such a trivial patch. As I used this driver as a base for
> another comphy driver (Armada 3700, coming soon) I spot this mistake
> but I would understand if you ignore the patch!

It's improving the readability of the code, so it's useful :)

Thanks!
Antoine

>  drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
> b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> index 86a5f7b9448b..31b9a1c18345 100644
> --- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -114,7 +114,7 @@
>  #define MVEBU_COMPHY_LANES   6
>  #define MVEBU_COMPHY_PORTS   3
>  
> -struct mvebu_comhy_conf {
> +struct mvebu_comphy_conf {
>   enum phy_mode mode;
>   unsigned lane;
>   unsigned port;
> @@ -129,7 +129,7 @@ struct mvebu_comhy_conf {
>   .mux = _mux,\
>   }
>  
> -static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> +static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
>   /* lane 0 */
>   MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
>   MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
> -- 
> 2.19.1
> 

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API

[Arnd Bergmann]

On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros  wrote:

> +
> +   if (IS_ERR_OR_NULL(rproc))
> +   return ERR_PTR(-EINVAL);


Any usage of  IS_ERR_OR_NULL() tends to be an indication of a badly
designed API. Please change this to allow only one of the two to be passed
around.

   Arnd

Re: [PATCH v2 1/3] thermal: tegra: continue if sensor register fails

[Wei Ni]

On 23/11/2018 2:51 PM, Daniel Lezcano wrote:
> 
> Hi wei,
> 
> On 23/11/2018 07:15, Wei Ni wrote:
>>
>>
>> On 22/11/2018 9:07 PM, Daniel Lezcano wrote:
>>> On 22/11/2018 08:10, Wei Ni wrote:


 On 21/11/2018 8:51 PM, Daniel Lezcano wrote:
> On 21/11/2018 11:23, Wei Ni wrote:
>>
>>
>> On 21/11/2018 4:55 PM, Daniel Lezcano wrote:
>>> On 13/11/2018 11:06, Wei Ni wrote:
 Don't bail when a sensor fails to register with the
 thermal zone and allow other sensors to register.
 This allows other sensors to register with thermal
 framework even if one sensor fails registration.
>>>
>>> I'm not sure if ignoring the error is really safe. Can you describe the
>>> real situation you want to overcome ? How do you differentiate critical
>>> sensors ?
>>
>> The driver will always try to register 4 thermal zones, including cpu,
>> gpu, mem and pll, but if the dts file doesn't set the corresponding
>> sensors, then the register will be failed.
>> Normally, the dts file will set all 4 sensors, but there may have some
>> platform doesn't support them all. So we post this patch.
>
> Ignoring errors is not the way to go to support different platforms. Fix
> the DT.

 The issue isn't in DT file. The Tegra soc thermal include 4 sensors:
 cpu, gpu, mem, pll. But in some platforms, for example, we may only need
 to support 2 sensors, such as cpu and gpu, so we only configure these
 two senors in DT file. But the driver will always try to register 4
 sensors, cpu/gpu/mem/pll, so mem and pll will be registered failed. So
 in this case we need to ignoring the failure, and continue to enable the
 driver.
>>>
>>> You can fix this by changing the driver to support the platform and
>>> register the sensor you are interested in.
>>>
>>> Ignoring errors is not a good idea.
>>
>> If hit the errors, the driver will print out the warning. In current
>> code, the driver probe routine will return failure directly, indeed it
>> didn't do anything either except print out warnings.
>> I think this error should not block other sensors' registration. Let's
>> consider this case, we have four sensors, if the one sensor register
>> failed, then the driver return probe failure, so the drive will not be
>> enabled, and other sensor can't work either, it mean the device may boot
>> up without any thermal sensors.
>> Or if the error is the -ENODEV, that mean the we didn't set
>> corresponding sensor id in the dt file, so we can continue to register.
>> If the error is other value, then we can return directly.
> 
> It is a possibility but may be there are a couple of alternatives:
> 
> 1. If there is a compatible string for the platform variant, use it to
> probe the right sensors
> 
> or
> 
> 2. Use the qoriq driver approach by reparsing the DT and find out the
> thermal zone and their respective sensor id.

Daniel, thanks for your comments, will consider it in my next version.

Wei.
> 
> 
>> BTW, what do you mean "critical sensors"? We will set critical trip temp
>> for all sensors.
>
> I meant sensor for thermal zone getting really high temperature.

 We doesn't have the critical sensors. We set the critical trip temp for
 all registered sensors. And these trip temp is set to the Tegra
 hardware. So it mean if the temperature reached the critical trip point,
 then the system will be shutdown directly.

>
>
 Signed-off-by: Wei Ni 
 ---
  drivers/thermal/tegra/soctherm.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/thermal/tegra/soctherm.c 
 b/drivers/thermal/tegra/soctherm.c
 index ed28110a3535..a824d2e63af3 100644
 --- a/drivers/thermal/tegra/soctherm.c
 +++ b/drivers/thermal/tegra/soctherm.c
 @@ -1370,9 +1370,9 @@ static int tegra_soctherm_probe(struct 
 platform_device *pdev)
 
 &tegra_of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
 -  dev_err(&pdev->dev, "failed to register sensor: 
 %d\n",
 -  err);
 -  goto disable_clocks;
 +  dev_warn(&pdev->dev, "failed to register sensor 
 %s: %d\n",
 +   soc->ttgs[i]->name, err);
 +  continue;
}
  
zone->tz = z;
 @@ -1434,6 +1434,8 @@ static int __maybe_unused soctherm_resume(struct 
 device *dev)
struct thermal_zone_device *tz;
  
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
 +  if (!tz)
 +  

FROM UPS DELIVERY

[UPS DELIVERY]

Contact UPS for your Donation visa card of 1 million usd

Re: [PATCH 2/2] clk: core: link consumer with clock driver

[kbuild test robot]

Hi Miquel,

I love your patch! Yet something to improve:

[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.20-rc3 next-20181122]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Miquel-Raynal/Link-consumer-with-clock-driver/20181123-113833
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: sh-titan_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   drivers//clk/clkdev.c: In function 'clk_get':
>> drivers//clk/clkdev.c:209:3: error: implicit declaration of function 
>> '__clk_device_link'; did you mean '__clk_free_clk'? 
>> [-Werror=implicit-function-declaration]
  __clk_device_link(dev, clk);
  ^
  __clk_free_clk
   drivers//clk/clkdev.c: In function 'clk_put':
>> drivers//clk/clkdev.c:217:2: error: implicit declaration of function 
>> '__clk_device_unlink'; did you mean 'device_online'? 
>> [-Werror=implicit-function-declaration]
 __clk_device_unlink(clk);
 ^~~
 device_online
   cc1: some warnings being treated as errors

vim +209 drivers//clk/clkdev.c

   193  
   194  struct clk *clk_get(struct device *dev, const char *con_id)
   195  {
   196  const char *dev_id = dev ? dev_name(dev) : NULL;
   197  struct clk *clk = NULL;
   198  
   199  if (dev && dev->of_node) {
   200  clk = __of_clk_get_by_name(dev->of_node, dev_id, 
con_id);
   201  if (PTR_ERR(clk) == -EPROBE_DEFER)
   202  return clk;
   203  }
   204  
   205  if (IS_ERR_OR_NULL(clk))
   206  clk = clk_get_sys(dev_id, con_id);
   207  
   208  if (!IS_ERR(clk))
 > 209  __clk_device_link(dev, clk);
   210  
   211  return clk;
   212  }
   213  EXPORT_SYMBOL(clk_get);
   214  
   215  void clk_put(struct clk *clk)
   216  {
 > 217  __clk_device_unlink(clk);
   218  __clk_put(clk);
   219  }
   220  EXPORT_SYMBOL(clk_put);
   221  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/6] phy: add A3700 COMPHY support

[Miquel Raynal]

Hello,

+ Adding people concerned by this driver that I forgot when initially
  sending the driver, will update the Cc: list if there is a v2.

One question below.

Miquel Raynal  wrote on Thu, 22 Nov 2018
22:04:16 +0100:

> Add a driver to support COMPHY, a hardware block providing shared
> serdes PHYs on Marvell Armada 3700. This driver uses SMC calls and
> rely on having an up-to-date firmware.
> 
> SATA, PCie and USB3 host mode have been tested successfully with an
> ESPRESSObin. SGMII mode cannot be tested with this platform.
> 
> Co-Developed-by: Evan Wang 
> Signed-off-by: Evan Wang 
> Signed-off-by: Miquel Raynal 
> ---
>  drivers/phy/marvell/Kconfig  |  10 +
>  drivers/phy/marvell/Makefile |   1 +
>  drivers/phy/marvell/phy-mvebu-a3700-comphy.c | 276 +++
>  3 files changed, 287 insertions(+)
>  create mode 100644 drivers/phy/marvell/phy-mvebu-a3700-comphy.c

[...]

> +
> +static int mvebu_a3700_comphy_power_on(struct phy *phy)
> +{
> + struct mvebu_a3700_comphy_lane *lane = phy_get_drvdata(phy);
> + u32 fw_param;
> + int fw_mode;
> +
> + fw_mode = mvebu_a3700_comphy_get_fw_mode(lane->id, lane->port,
> +  lane->mode);
> + if (fw_mode < 0) {
> + dev_err(lane->dev, "invalid COMPHY mode\n");
> + return fw_mode;
> + }
> +
> + switch (lane->mode) {
> + case PHY_MODE_USB_HOST_SS:
> + dev_dbg(lane->dev, "set lane %d to USB3 host mode\n", lane->id);
> + fw_param = COMPHY_FW_MODE(fw_mode);
> + break;
> + case PHY_MODE_SATA:
> + dev_dbg(lane->dev, "set lane %d to SATA mode\n", lane->id);
> + fw_param = COMPHY_FW_MODE(fw_mode);
> + break;
> + case PHY_MODE_SGMII:
> + dev_dbg(lane->dev, "set lane %d to SGMII mode\n", lane->id);
> + fw_param = COMPHY_FW_NET(fw_mode, lane->port,
> +  COMPHY_FW_SPEED_1_25G);
> + break;
> + case PHY_MODE_PCIE:
> + dev_dbg(lane->dev, "set lane %d to PCIe mode\n", lane->id);
> + fw_param = COMPHY_FW_PCIE(fw_mode, lane->port,
> +   COMPHY_FW_SPEED_5G,
> +   phy->attrs.bus_width);
> + break;
> + default:
> + dev_err(lane->dev, "unsupported PHY mode (%d)\n", lane->mode);
> + return -ENOTSUPP;
> + }
> +
> + return mvebu_a3700_comphy_smc(COMPHY_SIP_POWER_ON, lane->id, fw_param);

This call might fail because the firmware is not up-to-date. In this
case, I wonder what is the appropriate behavior. Here I just return the
error; this means drivers may fail to probe when enabling their PHY.

Shall I ignore a "not supported by the firmware" code and return 0 to
the caller (with a printed warning) so it will continue probing? Doing
so is lying as the PHY might not be configured as expected and S2RAM
will always fail in this case. 

Thanks,
Miquèl

[PATCH V6 0/2] can: flexcan: add can self wakeup support

[Joakim Zhang]

This patch series intends to add CAN self wakeup support. The CAN controller
can parse "fsl,stop-mode" property from device tree to enable self wakeup 
feature.

Aisheng Dong (2):
  Documentation: can: flexcan: add stop mode property to device tree
  can: flexcan: add self wakeup support

 .../bindings/net/can/fsl-flexcan.txt  |   8 +
 drivers/net/can/flexcan.c | 172 +-
 2 files changed, 171 insertions(+), 9 deletions(-)

-- 
2.17.1

[PATCH V6 1/2] Documentation: can: flexcan: add stop mode property to device tree

[Joakim Zhang]

From: Aisheng Dong 

The FlexCAN controller can parse the stop mode property to enable CAN
self wakeup feature.

Signed-off-by: Aisheng Dong 
Signed-off-by: Joakim Zhang 
---
ChangeLog:
V1->V2:
*add a vendor prefix in property (stop-mode -> fsl,stop-mode).
V2->V6:
*no change.
---
 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt 
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index bfc0c433654f..bc77477c6878 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -24,6 +24,14 @@ Optional properties:
   if this property is present then controller is assumed to be big
   endian.
 
+- fsl,stop-mode: register bits of stop mode control, the format is
+<&gpr req_gpr req_bit ack_gpr ack_bit>.
+gpr is the phandle to general purpose register node.
+req_gpr is the gpr register offset of CAN stop request.
+req_bit is the bit offset of CAN stop request.
+ack_gpr is the gpr register offset of CAN stop acknowledge.
+ack_bit is the bit offset of CAN stop acknowledge.
+
 Example:
 
can@1c000 {
-- 
2.17.1

[PATCH V6 2/2] can: flexcan: add self wakeup support

[Joakim Zhang]

From: Aisheng Dong 

If wakeup is enabled, enter stop mode, else enter disabled mode. Self wake
can only work on stop mode.

Starting from IMX6, the flexcan stop mode control bits is SoC specific,
move it out of IP driver and parse it from devicetree.

Signed-off-by: Aisheng Dong 
Signed-off-by: Joakim Zhang 
---
ChangeLog:
V1->V2:
*add a vendor prefix in property (stop-mode -> fsl,stop-mode).
V2->V3:
*add FLEXCAN_QUIRK_SETUP_STOP_MODE quirk.
*rename function.
*fix system can't be wakeuped during suspend.
V3->V4:
*normalize the code following Aisheng Dong's comments.
V4->V5:
*move enable/disable self wakeup feature into
 enter/exit_stop_mode() function.
V5->V6:
*exchange the order of flexcan_enable_wakeup_irq(priv, false)
 and disable_irq_wake(dev->irq).
---
 drivers/net/can/flexcan.c | 172 --
 1 file changed, 163 insertions(+), 9 deletions(-)

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 8e972ef08637..da08a8c113d2 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -19,11 +19,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #define DRV_NAME   "flexcan"
 
@@ -131,7 +134,8 @@
(FLEXCAN_ESR_ERR_BUS | FLEXCAN_ESR_ERR_STATE)
 #define FLEXCAN_ESR_ALL_INT \
(FLEXCAN_ESR_TWRN_INT | FLEXCAN_ESR_RWRN_INT | \
-FLEXCAN_ESR_BOFF_INT | FLEXCAN_ESR_ERR_INT)
+   FLEXCAN_ESR_BOFF_INT | FLEXCAN_ESR_ERR_INT | \
+   FLEXCAN_ESR_WAK_INT)
 
 /* FLEXCAN interrupt flag register (IFLAG) bits */
 /* Errata ERR005829 step7: Reserve first valid MB */
@@ -190,6 +194,7 @@
 #define FLEXCAN_QUIRK_USE_OFF_TIMESTAMPBIT(5) /* Use timestamp based 
offloading */
 #define FLEXCAN_QUIRK_BROKEN_PERR_STATEBIT(6) /* No interrupt for 
error passive */
 #define FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN   BIT(7) /* default to BE 
register access */
+#define FLEXCAN_QUIRK_SETUP_STOP_MODE  BIT(8) /* Setup stop mode to 
support wakeup */
 
 /* Structure of the message buffer */
 struct flexcan_mb {
@@ -254,6 +259,14 @@ struct flexcan_devtype_data {
u32 quirks; /* quirks needed for different IP cores */
 };
 
+struct flexcan_stop_mode {
+   struct regmap *gpr;
+   u8 req_gpr;
+   u8 req_bit;
+   u8 ack_gpr;
+   u8 ack_bit;
+};
+
 struct flexcan_priv {
struct can_priv can;
struct can_rx_offload offload;
@@ -270,6 +283,7 @@ struct flexcan_priv {
struct clk *clk_per;
const struct flexcan_devtype_data *devtype_data;
struct regulator *reg_xceiver;
+   struct flexcan_stop_mode stm;
 
/* Read and Write APIs */
u32 (*read)(void __iomem *addr);
@@ -293,7 +307,8 @@ static const struct flexcan_devtype_data 
fsl_imx28_devtype_data = {
 
 static const struct flexcan_devtype_data fsl_imx6q_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
-   FLEXCAN_QUIRK_USE_OFF_TIMESTAMP | 
FLEXCAN_QUIRK_BROKEN_PERR_STATE,
+   FLEXCAN_QUIRK_USE_OFF_TIMESTAMP | 
FLEXCAN_QUIRK_BROKEN_PERR_STATE |
+   FLEXCAN_QUIRK_SETUP_STOP_MODE,
 };
 
 static const struct flexcan_devtype_data fsl_vf610_devtype_data = {
@@ -353,6 +368,49 @@ static inline void flexcan_write_le(u32 val, void __iomem 
*addr)
iowrite32(val, addr);
 }
 
+static void flexcan_enable_wakeup_irq(struct flexcan_priv *priv, bool enable)
+{
+   struct flexcan_regs __iomem *regs = priv->regs;
+   u32 reg_mcr;
+
+   reg_mcr = priv->read(®s->mcr);
+
+   if (enable)
+   reg_mcr |= FLEXCAN_MCR_WAK_MSK;
+   else
+   reg_mcr &= ~FLEXCAN_MCR_WAK_MSK;
+
+   priv->write(reg_mcr, ®s->mcr);
+}
+
+static inline void flexcan_enter_stop_mode(struct flexcan_priv *priv)
+{
+   struct flexcan_regs __iomem *regs = priv->regs;
+   u32 reg_mcr;
+
+   reg_mcr = priv->read(®s->mcr);
+   reg_mcr |= FLEXCAN_MCR_SLF_WAK;
+   priv->write(reg_mcr, ®s->mcr);
+
+   /* enable stop request */
+   regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
+  1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
+}
+
+static inline void flexcan_exit_stop_mode(struct flexcan_priv *priv)
+{
+   struct flexcan_regs __iomem *regs = priv->regs;
+   u32 reg_mcr;
+
+   /* remove stop request */
+   regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
+  1 << priv->stm.req_bit, 0);
+
+   reg_mcr = priv->read(®s->mcr);
+   reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
+   priv->write(reg_mcr, ®s->mcr);
+}
+
 static inline void flexcan_error_irq_enable(const struct flexcan_priv *priv)
 {
struct flexcan_regs __iomem *regs = priv->regs;
@@ -1244,6 +1302,57 @@ static void unregister_flexcandev(struct net_device *dev)
unregister_candev(dev);

Re: Linux 4.9.139

[Rainer Fiebig]

Am Freitag, 23. November 2018, 08:47:31 schrieb Greg KH:
> I'm announcing the release of the 4.9.139 kernel.
> 
> All users of the 4.9 kernel series must upgrade.
> 
> The updated 4.9.y git tree can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> linux-4.9.y and can be browsed at the normal kernel.org git web browser:
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> 
> thanks,
> 
> greg k-h
> 
Just *in case* this was an oversight: STIBP is still active in 4.9.139.

Not that I would mind because for my modest Core i3 that I mainly use for 
office-work I don't see *any* difference in performance compared to 4.9.136 
(no STIBP).

So long!

Rainer Fiebig

> 
> 
>  .gitignore|1
>  Kbuild|   25 
>  Makefile  |   27 +++-
>  arch/arm/include/asm/assembler.h  |   12 ++
>  arch/arm/include/asm/barrier.h|   32 +
>  arch/arm/include/asm/bugs.h   |6 -
>  arch/arm/include/asm/cp15.h   |3
>  arch/arm/include/asm/cputype.h|8 +
>  arch/arm/include/asm/kvm_asm.h|2
>  arch/arm/include/asm/kvm_host.h   |   14 ++
>  arch/arm/include/asm/kvm_mmu.h|   23 +++
>  arch/arm/include/asm/proc-fns.h   |4
>  arch/arm/include/asm/system_misc.h|   15 ++
>  arch/arm/include/asm/thread_info.h|4
>  arch/arm/include/asm/uaccess.h|   26 +++-
>  arch/arm/kernel/Makefile  |1
>  arch/arm/kernel/bugs.c|   18 +++
>  arch/arm/kernel/entry-common.S|   18 +--
>  arch/arm/kernel/entry-header.S|   25 
>  arch/arm/kernel/signal.c  |   55 +
>  arch/arm/kernel/smp.c |4
>  arch/arm/kernel/suspend.c |2
>  arch/arm/kernel/sys_oabi-compat.c |8 -
>  arch/arm/kvm/hyp/hyp-entry.S  |  112 ++-
>  arch/arm/lib/copy_from_user.S |9 +
>  arch/arm/mm/Kconfig   |   23 +++
>  arch/arm/mm/Makefile  |2
>  arch/arm/mm/fault.c   |3
>  arch/arm/mm/proc-macros.S |3
>  arch/arm/mm/proc-v7-2level.S  |6 -
>  arch/arm/mm/proc-v7-bugs.c|  174
> ++ arch/arm/mm/proc-v7.S | 
> 154 +- arch/arm/vfp/vfpmodule.c  | 
>  17 +-
>  arch/arm64/crypto/sha1-ce-core.S  |6 -
>  arch/arm64/crypto/sha1-ce-glue.c  |   11 -
>  arch/arm64/crypto/sha2-ce-core.S  |6 -
>  arch/arm64/crypto/sha2-ce-glue.c  |   13 --
>  arch/arm64/include/asm/efi.h  |3
>  arch/arm64/include/asm/uaccess.h  |4
>  arch/ia64/kernel/Makefile |   26 
>  arch/x86/Makefile |   39 +-
>  arch/x86/boot/string.c|9 +
>  arch/x86/crypto/aes_ctrby8_avx-x86_64.S   |7 -
>  drivers/firmware/efi/libstub/Makefile |   26 ++--
>  drivers/firmware/efi/libstub/arm64-stub.c |   10 +
>  drivers/net/ethernet/broadcom/tg3.c   |   18 ++-
>  drivers/net/usb/smsc95xx.c|7 +
>  drivers/xen/Makefile  |3
>  include/linux/kbuild.h|6 -
>  include/linux/module.h|4
>  net/core/dev.c|4
>  net/core/flow_dissector.c |4
>  net/ipv4/inet_fragment.c  |   28 ++--
>  net/ipv4/ip_tunnel_core.c |2
>  net/ipv6/route.c  |7 -
>  net/sctp/socket.c |   26 
>  scripts/Kbuild.include|   18 ++-
>  scripts/Makefile.build|8 +
>  scripts/Makefile.extrawarn|1
>  scripts/Makefile.host |6 -
>  scripts/Makefile.lib  |   31 +
>  scripts/mod/Makefile  |   28 
>  62 files changed, 901 insertions(+), 296 deletions(-)
> 
> Ard Biesheuvel (5):
>   crypto: arm64/sha - avoid non-standard inline asm tricks
>   efi/libstub/arm64: Use hidden attribute for struct screen_info
> reference efi/libstub/arm64: Force 'hidden' visibility for section markers
> efi/libstub: Preserve .debug sections after absolute relocation check
> efi/libstub/arm64: Set -fpie when building the EFI stub
> 
> Arnd Bergmann (2):
>   modules: mark __inittest/__exittest as __maybe_unused
>   Kbuild: use -fshort-wchar globally
> 
> Behan Webster (2):
>   kbuild: Add better clang cross build support
>   kbuild: use -Oz instead of -Os when using clang
> 
> David Ahern (1):
>   ipv6: Fix PMTU updates for UDP/raw sockets in presence of VRF
> 
> Eric 

RE: [PATCH V6 0/2] can: flexcan: add can self wakeup support

[Aisheng DONG]

> -Original Message-
> From: Joakim Zhang
> Sent: Friday, November 23, 2018 4:35 PM
> To: linux-...@vger.kernel.org; m...@pengutronix.de; robh...@kernel.org
> Cc: w...@grandegger.com; mark.rutl...@arm.com; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx ; Joakim
> Zhang 
> Subject: [PATCH V6 0/2] can: flexcan: add can self wakeup support
> 
> This patch series intends to add CAN self wakeup support. The CAN controller
> can parse "fsl,stop-mode" property from device tree to enable self wakeup
> feature.
> 

As I'm already authored, this is just to tell this version looks good to me.
Reviewed-by: Dong Aisheng 

Regards
Dong Aisheng

Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API

[Tero Kristo]

On 23/11/2018 10:20, Arnd Bergmann wrote:

On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros  wrote:


+
+   if (IS_ERR_OR_NULL(rproc))
+   return ERR_PTR(-EINVAL);



Any usage of  IS_ERR_OR_NULL() tends to be an indication of a badly
designed API. Please change this to allow only one of the two to be passed
around.


Should this be deprecated then?

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v5 6/8] mfd: lochnagar: Add support for the Cirrus Logic Lochnagar

[kbuild test robot]

Hi Charles,

I love your patch! Yet something to improve:

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.20-rc3]
[cannot apply to next-20181122]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Charles-Keepax/regulator-lochnagar-Move-driver-to-binding-from-DT/20181123-133943
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   In file included from arch/sh/include/asm/string.h:3:0,
from include/linux/string.h:20,
from include/linux/bitmap.h:9,
from include/linux/nodemask.h:95,
from include/linux/mmzone.h:17,
from include/linux/gfp.h:6,
from include/linux/umh.h:4,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/staging/media/bcm2048/radio-bcm2048.c:33:
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_vidioc_g_audio':
   arch/sh/include/asm/string_32.h:50:42: warning: array subscript is above 
array bounds [-Warray-bounds]
  : "0" (__dest), "1" (__src), "r" (__src+__n)
~^~~~
   drivers/staging/iio/adc/ad7606_par.c: In function 'ad7606_par16_read_block':
   drivers/staging/iio/adc/ad7606_par.c:22:23: warning: unused variable 'st' 
[-Wunused-variable]
 struct ad7606_state *st = iio_priv(indio_dev);
  ^~
   drivers/staging/iio/adc/ad7606_par.c: In function 'ad7606_par8_read_block':
   drivers/staging/iio/adc/ad7606_par.c:37:23: warning: unused variable 'st' 
[-Wunused-variable]
 struct ad7606_state *st = iio_priv(indio_dev);
  ^~
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_vidioc_g_tuner':
   arch/sh/include/asm/string_32.h:50:42: warning: array subscript is above 
array bounds [-Warray-bounds]
  : "0" (__dest), "1" (__src), "r" (__src+__n)
~^~~~
   drivers/thermal/broadcom/ns-thermal.c: In function 'ns_thermal_remove':
   drivers/thermal/broadcom/ns-thermal.c:81:21: warning: unused variable 
'ns_thermal' [-Wunused-variable]
 struct ns_thermal *ns_thermal = platform_get_drvdata(pdev);
^~
   In file included from arch/sh/include/asm/string.h:3:0,
from include/linux/string.h:20,
from include/linux/bitmap.h:9,
from include/linux/nodemask.h:95,
from include/linux/mmzone.h:17,
from include/linux/gfp.h:6,
from include/linux/umh.h:4,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/scsi/ch.c:10:
   drivers/scsi/ch.c: In function 'ch_ioctl':
   arch/sh/include/asm/string_32.h:50:42: warning: array subscript is above 
array bounds [-Warray-bounds]
  : "0" (__dest), "1" (__src), "r" (__src+__n)
~^~~~
   arch/sh/include/asm/string_32.h:50:42: warning: array subscript is above 
array bounds [-Warray-bounds]
  : "0" (__dest), "1" (__src), "r" (__src+__n)
~^~~~
   arch/sh/include/asm/string_32.h:50:42: warning: array subscript is above 
array bounds [-Warray-bounds]
  : "0" (__dest), "1" (__src), "r" (__src+__n)
~^~~~
   arch/sh/include/asm/string_32.h:50:42: warning: array subscript is above 
array bounds [-Warray-bounds]
  : "0" (__dest), "1" (__src), "r" (__src+__n)
~^~~~
   drivers/regulator/lochnagar-regulator.c: In function 
'lochnagar_micbias_of_parse':
>> drivers/regulator/lochnagar-regulator.c:115:7: error: 
>> 'LOCHNAGAR2_P2_MICBIAS_SRC_SHIFT' undeclared (first use in this function); 
>> did you mean 'LOCHNAGAR_DEVICE_ID_SHIFT'?
  LOCHNAGAR2_P2_MICBIAS_SRC_SHIFT;
  ^~~
  LOCHNAGAR_DEVICE_ID_SHIFT
   drivers/regulator/lochnagar-regulator.c:115:7: note: e

[PATCH] hfs: do not free node before using

[Pan Bian]

The function hfs_bmap_free frees node via hfs_bnode_put(node). However,
it then reads node->this when dumping error message on an error path,
which may result in a use-after-free bug. This patch frees node only
when it is never used.

Fixes: d614267329f("hfs/hfsplus: convert printks to pr_")

Signed-off-by: Pan Bian 
---
 fs/hfs/btree.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
index 98b96ff..19017d2 100644
--- a/fs/hfs/btree.c
+++ b/fs/hfs/btree.c
@@ -338,13 +338,14 @@ void hfs_bmap_free(struct hfs_bnode *node)
 
nidx -= len * 8;
i = node->next;
-   hfs_bnode_put(node);
if (!i) {
/* panic */;
pr_crit("unable to free bnode %u. bmap not found!\n",
node->this);
+   hfs_bnode_put(node);
return;
}
+   hfs_bnode_put(node);
node = hfs_bnode_find(tree, i);
if (IS_ERR(node))
return;
-- 
2.7.4

Re: [for-next][PATCH 08/18] parisc: function_graph: Simplify with function_graph_entry()

[Helge Deller]

HI Sasha,

On 23.11.18 08:30, Sasha Levin wrote:

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 03274a3ffb44 tracing/fgraph: Adjust fgraph depth before calling 
trace return callback.

The bot has tested the following trees: v4.19.3, v4.14.82, v4.9.138, v4.4.164, 
v3.18.126.

v4.19.3: Build OK!
v4.14.82: Build OK!
v4.9.138: Build OK!
v4.4.164: Failed to apply! Possible dependencies:
 Unable to calculate

v3.18.126: Failed to apply! Possible dependencies:
 Unable to calculate

How should we proceed with this patch?


My suggestion, although I didn't looked too much on it:
Apply it to v4.9 and higher only.
I think I started fixing trace functionality on parisc around 4.6,
which is probably why applying it fails on v4.4 and v3.x

Helge

[PATCH] dt-bindings: timer: gpt: update binding doc

[Anson Huang]

The i.MX GPT timer driver binding doc is out of date,
the "interrupts", "clocks" and "clock-names" do NOT match
current GPT driver implementation, update it and use i.MX6SX
as example.

Signed-off-by: Anson Huang 
---
 .../devicetree/bindings/timer/fsl,imxgpt.txt   | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt 
b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
index 9809b11..4e9fa16 100644
--- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
@@ -2,17 +2,21 @@ Freescale i.MX General Purpose Timer (GPT)
 
 Required properties:
 
-- compatible : should be "fsl,-gpt"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : A list of 4 interrupts; one per timer channel.
-- clocks : The clocks provided by the SoC to drive the timer.
+- compatible : should be "fsl,-gpt".
+- reg : specifies base physical address and size of the registers.
+- interrupts : should be the clock event device interrupt.
+- clocks : the clocks provided by the SoC to drive the timer, must contain
+   an entry for each entry in clock-names.
+- clock-names : must include an "per" or "osc_per" entry, and "ipg" entry
+is optional according to SoC design.
 
 Example:
 
-gpt1: timer@10003000 {
-   compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
-   reg = <0x10003000 0x1000>;
-   interrupts = <26>;
-   clocks = <&clks 46>, <&clks 61>;
+gpt: gpt@2098000 {
+   compatible = "fsl,imx6sx-gpt", "fsl,imx31-gpt";
+   reg = <0x02098000 0x4000>;
+   interrupts = ;
+   clocks = <&clks IMX6SX_CLK_GPT_BUS>,
+<&clks IMX6SX_CLK_GPT_3M>;
clock-names = "ipg", "per";
 };
-- 
2.7.4

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

[Viresh Kumar]

On 22-11-18, 11:38, Viresh Kumar wrote:
> So there are few complexities in the case where an OPP table points to itself 
> in
> the required-opp field. I looked at solving it up in the opp core but that 
> gets
> more and more messy.
> 
> Now there is actually a assumption within the OPP core. Your Mx domain should
> get initialized before the Cx domain, as that is when the OPP tables are 
> created
> as well. This is because Cx's OPP table will point to Mx's OPP table (doesn't
> matter if they share the same table or not) and so Mx's OPP table should come
> first.
> 
> Can you check if that is already the case for you? If not, please try doing it
> and lemme know if it works. It should.
> 
> I just want to avoid too much complexity in OPP core without much use.

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 7f338d39809a..09df3fbdb555 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1734,7 +1734,7 @@ unsigned int dev_pm_opp_xlate_performance_state(struct 
opp_table *src_table,
int i;
 
for (i = 0; i < src_table->required_opp_count; i++) {
-   if (src_table->required_opp_tables[i] == dst_table)
+   if (src_table->required_opp_tables[i]->np == dst_table->np)
break;
}

Try this fix and it should make it work for you.

Having said that, the way you are representing all your domains with a
single OPP table look incorrect. You are using the same OPP table for
around 10 power domains, all provided by a single provider. This is
absolutely fine. But the Mx domain doesn't have any dependency on any
other domain actually and so its OPPs should never have the
"required-opps" property, but it has those properties in your setup as
you are trying to use the same OPP table. That may all work fine with
the above patch (which is required anyway as it fixes a valid issue),
but you may see a error warning that something failed for Mx domain,
as it has required-opps property but no required device or genpd.

Anyway, please test above first and then you can fix your tables :)

-- 
viresh

Re: [PATCH 2/2] clk: core: link consumer with clock driver

[Miquel Raynal]

Hello,

kbuild test robot  wrote on Fri, 23 Nov 2018 16:30:00
+0800:

> Hi Miquel,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on clk/clk-next]
> [also build test ERROR on v4.20-rc3 next-20181122]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Miquel-Raynal/Link-consumer-with-clock-driver/20181123-113833
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> config: sh-titan_defconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=sh 
> 
> All errors (new ones prefixed by >>):
> 
>drivers//clk/clkdev.c: In function 'clk_get':
> >> drivers//clk/clkdev.c:209:3: error: implicit declaration of function 
> >> '__clk_device_link'; did you mean '__clk_free_clk'? 
> >> [-Werror=implicit-function-declaration]  
>   __clk_device_link(dev, clk);
>   ^
>   __clk_free_clk
>drivers//clk/clkdev.c: In function 'clk_put':
> >> drivers//clk/clkdev.c:217:2: error: implicit declaration of function 
> >> '__clk_device_unlink'; did you mean 'device_online'? 
> >> [-Werror=implicit-function-declaration]  
>  __clk_device_unlink(clk);
>  ^~~
>  device_online
>cc1: some warnings being treated as errors

I figured thanks to this report that this code won't compile with
architectures not compliant to the common clock framework. I see there
is the following block in clkdev.c.

#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
#else
#endif

Would you agree with me adding dummy functions in the #else section
like:

static inline void __clk_device_link(struct device *consumer, struct clk *clk)
{
   return;
}

static inline void __clk_device_unlink(struct clk *clk)
{
   return;
}

Do you want me to also declare these functions in the #if section
(with the external keyword) to balance the above declarations?

Thanks for your input.
Miquèl

> 
> vim +209 drivers//clk/clkdev.c
> 
>193
>194struct clk *clk_get(struct device *dev, const char *con_id)
>195{
>196const char *dev_id = dev ? dev_name(dev) : NULL;
>197struct clk *clk = NULL;
>198
>199if (dev && dev->of_node) {
>200clk = __of_clk_get_by_name(dev->of_node, 
> dev_id, con_id);
>201if (PTR_ERR(clk) == -EPROBE_DEFER)
>202return clk;
>203}
>204
>205if (IS_ERR_OR_NULL(clk))
>206clk = clk_get_sys(dev_id, con_id);
>207
>208if (!IS_ERR(clk))
>  > 209__clk_device_link(dev, clk);  
>210
>211return clk;
>212}
>213EXPORT_SYMBOL(clk_get);
>214
>215void clk_put(struct clk *clk)
>216{
>  > 217__clk_device_unlink(clk);  
>218__clk_put(clk);
>219}
>220EXPORT_SYMBOL(clk_put);
>221
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v5 6/8] mfd: lochnagar: Add support for the Cirrus Logic Lochnagar

[Charles Keepax]

On Fri, Nov 23, 2018 at 05:00:57PM +0800, kbuild test robot wrote:
> Hi Charles,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on ljones-mfd/for-mfd-next]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181122]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>drivers/regulator/lochnagar-regulator.c: In function 
> 'lochnagar_micbias_of_parse':

> >> drivers/regulator/lochnagar-regulator.c:115:7: error: 
> >> 'LOCHNAGAR2_P2_MICBIAS_SRC_SHIFT' undeclared (first use in this function); 
> >> did you mean 'LOCHNAGAR_DEVICE_ID_SHIFT'?
>   LOCHNAGAR2_P2_MICBIAS_SRC_SHIFT;
>   ^~~

These issues will resolve themselves in the merge, this patch is
already merged in Mark's tree and will resolve the issue:

fa2bb8b97d77 ("regulator: lochnagar: Explicitly include register headers")

Thanks,
Charles

[PATCH v2] phy: mvebu-cp110-comphy: fix spelling in structure name

[Miquel Raynal]

Rename the mvebu_comhy_conf structure to be mvebu_comphy_conf, which is
probably what the original author meant.

Signed-off-by: Miquel Raynal 
---

Changes since v1

* Removed the Fixes: tag after Antoine's request.


 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 86a5f7b9448b..31b9a1c18345 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -114,7 +114,7 @@
 #define MVEBU_COMPHY_LANES 6
 #define MVEBU_COMPHY_PORTS 3
 
-struct mvebu_comhy_conf {
+struct mvebu_comphy_conf {
enum phy_mode mode;
unsigned lane;
unsigned port;
@@ -129,7 +129,7 @@ struct mvebu_comhy_conf {
.mux = _mux,\
}
 
-static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
+static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
-- 
2.19.1

Re: Linux 4.9.139

[Greg KH]

On Fri, Nov 23, 2018 at 09:55:47AM +0100, Rainer Fiebig wrote:
> Am Freitag, 23. November 2018, 08:47:31 schrieb Greg KH:
> > I'm announcing the release of the 4.9.139 kernel.
> > 
> > All users of the 4.9 kernel series must upgrade.
> > 
> > The updated 4.9.y git tree can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > linux-4.9.y and can be browsed at the normal kernel.org git web browser:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> > 
> > thanks,
> > 
> > greg k-h
> > 
> Just *in case* this was an oversight: STIBP is still active in 4.9.139.
> 
> Not that I would mind because for my modest Core i3 that I mainly use for 
> office-work I don't see *any* difference in performance compared to 4.9.136 
> (no STIBP).
> 
> So long!

Wait, really?  I thought I reverted the patch.  Oh crap, I only did it
for 4.14.y and 4.19.y, my fault :(

I'll go queue up the revert now, so sorry about that.

greg k-h

Re: [PATCH 1/3] regulator: wm8994: Revert back to using devres

[Marek Szyprowski]

Hi Charles,

On 2018-11-22 18:30, Charles Keepax wrote:
> This reverts commit 466affa06703 ("regulator: wm8994: Don't
> use devres for enable GPIOs"). Whilst that did work around the
> issue in question there are complications on the error paths of
> regulator_register. In the success case clearly the regulator
> core owns the GPIO, however, in the failure case it is unclear
> what should happen. The regulator core could always free the
> GPIO but that may not make sense from the perspective of the
> calling code. Alternatively the regulator core could never free
> the GPIO but that makes the handling in the regulator core rather
> complex. Ultimately it makes more sense to handle the shared GPIO
> in the core.
>
> Reported-by: Marek Szyprowski 
> Signed-off-by: Charles Keepax 

Thanks for sorting this out! Works fine on Trats2:

Tested-by: Marek Szyprowski 

> ---
>  drivers/regulator/wm8994-regulator.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/regulator/wm8994-regulator.c 
> b/drivers/regulator/wm8994-regulator.c
> index 46e6b4ee1491a..d7fec533c4032 100644
> --- a/drivers/regulator/wm8994-regulator.c
> +++ b/drivers/regulator/wm8994-regulator.c
> @@ -147,14 +147,11 @@ static int wm8994_ldo_probe(struct platform_device 
> *pdev)
>   config.regmap = wm8994->regmap;
>   config.init_data = &ldo->init_data;
>  
> - /*
> -  * Look up LDO enable GPIO from the parent device node, we don't
> -  * use devm because the regulator core will free the GPIO
> -  */
> - gpiod = gpiod_get_optional(pdev->dev.parent,
> -id ? "wlf,ldo2ena" : "wlf,ldo1ena",
> -GPIOD_OUT_LOW |
> -GPIOD_FLAGS_BIT_NONEXCLUSIVE);
> + /* Look up LDO enable GPIO from the parent device node */
> + gpiod = devm_gpiod_get_optional(pdev->dev.parent,
> + id ? "wlf,ldo2ena" : "wlf,ldo1ena",
> + GPIOD_OUT_LOW |
> + GPIOD_FLAGS_BIT_NONEXCLUSIVE);
>   if (IS_ERR(gpiod))
>   return PTR_ERR(gpiod);
>   config.ena_gpiod = gpiod;
> @@ -187,7 +184,6 @@ static int wm8994_ldo_probe(struct platform_device *pdev)
>   return 0;
>  
>  err:
> - gpiod_put(gpiod);
>   return ret;
>  }
>  

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH 2/3] regulator: Only free GPIOs if the core requested them

[Marek Szyprowski]

Hi Charles,

On 2018-11-22 18:30, Charles Keepax wrote:
> Currently, the regulator core will take ownership of any GPIO passed
> into it. Makes end driver code fairly error prone as the normal devm_
> patterns of allocation don't work. Update the regulator core to only
> free the GPIO if it requested it, this allows the drivers to manage the
> GPIO lifetime as they normally would.
>
> Reported-by: Marek Szyprowski 
> Signed-off-by: Charles Keepax 

Tested-by: Marek Szyprowski 

> ---
>  drivers/regulator/core.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index dbe2f2e6e6254..9da7d27c7145e 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -83,6 +83,7 @@ struct regulator_enable_gpio {
>   u32 enable_count;   /* a number of enabled shared GPIO */
>   u32 request_count;  /* a number of requested shared GPIO */
>   unsigned int ena_gpio_invert:1;
> + unsigned int locally_requested:1;
>  };
>  
>  /*
> @@ -2233,19 +2234,20 @@ static int regulator_ena_gpio_request(struct 
> regulator_dev *rdev,
>   }
>   }
>  
> + pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
> + if (pin == NULL)
> + return -ENOMEM;
> +
>   if (!config->ena_gpiod) {
>   ret = gpio_request_one(config->ena_gpio,
>  GPIOF_DIR_OUT | config->ena_gpio_flags,
>  rdev_get_name(rdev));
> - if (ret)
> + if (ret) {
> + kfree(pin);
>   return ret;
> - }
> + }
>  
> - pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
> - if (pin == NULL) {
> - if (!config->ena_gpiod)
> - gpio_free(config->ena_gpio);
> - return -ENOMEM;
> + pin->locally_requested = 1;
>   }
>  
>   pin->gpiod = gpiod;
> @@ -2270,7 +2272,8 @@ static void regulator_ena_gpio_free(struct 
> regulator_dev *rdev)
>   if (pin->gpiod == rdev->ena_pin->gpiod) {
>   if (pin->request_count <= 1) {
>   pin->request_count = 0;
> - gpiod_put(pin->gpiod);
> + if (pin->locally_requested)
> + gpiod_put(pin->gpiod);
>   list_del(&pin->list);
>   kfree(pin);
>   rdev->ena_pin = NULL;

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs

[Marek Szyprowski]

Hi Charles,

On 2018-11-22 18:30, Charles Keepax wrote:
> Currently, a GPIO can be requested multiple times when the
> NONEXCLUSIVE flag is set, however it must still be freed a single
> time. This makes client code rather complex, since multiple drivers
> may request the GPIO but only a single one can free it. Rather than
> manually handling this in each driver add some basic reference
> counting into the core.  Currently, this is fairly primitive but
> so is the support for the NONEXCLUSIVE flag and the implementation
> covers those use-cases.
>
> Reported-by: Marek Szyprowski 
> Signed-off-by: Charles Keepax 
Tested-by: Marek Szyprowski 
> ---
>  drivers/gpio/gpiolib.c | 13 -
>  drivers/gpio/gpiolib.h |  2 ++
>  2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 230e41562462b..42ba86fb495a5 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2407,6 +2407,13 @@ static bool gpiod_free_commit(struct gpio_desc *desc)
>  
>   might_sleep();
>  
> + if (desc->n_users > 1) {
> + desc->n_users--;
> + return true;
> + } else {
> + desc->n_users = 0;
> + }
> +
>   gpiod_unexport(desc);
>  
>   spin_lock_irqsave(&gpio_lock, flags);
> @@ -4142,7 +4149,8 @@ struct gpio_desc *__must_check gpiod_get_index(struct 
> device *dev,
>*/
>   dev_info(dev, "nonexclusive access to GPIO for %s\n",
>con_id ? con_id : devname);
> - return desc;
> +
> + goto done;
>   } else {
>   return ERR_PTR(status);
>   }
> @@ -4155,6 +4163,9 @@ struct gpio_desc *__must_check gpiod_get_index(struct 
> device *dev,
>   return ERR_PTR(status);
>   }
>  
> +done:
> + desc->n_users++;
> +
>   return desc;
>  }
>  EXPORT_SYMBOL_GPL(gpiod_get_index);
> diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
> index 087d865286a0c..f96eda90281a3 100644
> --- a/drivers/gpio/gpiolib.h
> +++ b/drivers/gpio/gpiolib.h
> @@ -230,6 +230,8 @@ struct gpio_desc {
>   const char  *label;
>   /* Name of the GPIO */
>   const char  *name;
> +
> + unsigned intn_users;
>  };
>  
>  int gpiod_request(struct gpio_desc *desc, const char *label);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Sleeping in user_access section

[Julien Thierry]

Hi,

I made an attempt at implementing the 
user_access_begin()/user_access_end() macros along with the 
get/put_user_unsafe() for arm64 by toggling the status of PAN (more or 
less similar to x86's STAC/CTAC).


With a small mistake in my patch, we realized that directly calling 
function that could reschedule while in a user_access section could lead to:


- scheduling another task keeping the user_access status enabled despite 
the task never calling user_access_begin()


- when re-scheduling the task that was mid user_access section, 
user_access would be disabled and the task would fault on the next 
get/put_user_unsafe.



This is because __switch_to does not alter the user_access status when 
switching from next to prev (at least on arm64 we currently don't, and 
by looking at the x86 code I don't think this is done either).



From my understanding, this is not an issue when the task in 
user_access mode gets scheduled out/in as a result of an interrupt as 
PAN and EFLAGS.AC get saved/restore on exception entry/exit (at least I 
know it is the case for PAN, I am less sure for the x86 side).



So, the question is, should __switch_to take care of the user_access 
status when scheduling new tasks? Or should there be a restriction about 
scheduling out a task with user_access mode enabled and maybe add a 
warning if we can detect this?


(Or did we miss something and this is not an issue on x86?)

Thanks,

--
Julien Thierry

[PATCH v2 41/43] drm/sun4i: Make COEF_RDY conditional

[Paul Kocialkowski]

From: Maxime Ripard 

The COEF_RDY bit isn't found in all the SoCs featuring some variant of the
frontend.

Add it to our quirks structure.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 9 +
 drivers/gpu/drm/sun4i/sun4i_frontend.h | 1 +
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 0e92f59efd49..f50507ee6d75 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -95,10 +95,11 @@ static void sun4i_frontend_scaler_init(struct 
sun4i_frontend *frontend)
 sun4i_frontend_vert_coef[i]);
}
 
-   regmap_write_bits(frontend->regs,
- SUN4I_FRONTEND_FRM_CTRL_REG,
- SUN4I_FRONTEND_FRM_CTRL_COEF_RDY,
- SUN4I_FRONTEND_FRM_CTRL_COEF_RDY);
+   if (frontend->data->has_coef_rdy)
+   regmap_write_bits(frontend->regs,
+ SUN4I_FRONTEND_FRM_CTRL_REG,
+ SUN4I_FRONTEND_FRM_CTRL_COEF_RDY,
+ SUN4I_FRONTEND_FRM_CTRL_COEF_RDY);
 }
 
 int sun4i_frontend_init(struct sun4i_frontend *frontend)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h 
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index daf3fa5d01ba..3618993f8e49 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -102,6 +102,7 @@ struct reset_control;
 
 struct sun4i_frontend_data {
boolhas_coef_access_ctrl;
+   boolhas_coef_rdy;
 };
 
 struct sun4i_frontend {
-- 
2.19.1

[PATCH v2 43/43] drm/sun4i: frontend: Add A20-specific device-tree compatible and quirks

[Paul Kocialkowski]

This adds the appropriate device-tree compatible and quirk data for
hooking frontend support for the A20. It supports the FIR coefficients
ready bit but not the access control bit. It also takes different phase
values than the A33 for these coefficients.

The compatible is already used in the A20 device-tree and already
documented in the device-tree bindings.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 427c51029a9c..4a9cb478167f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -676,6 +676,20 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
.runtime_suspend= sun4i_frontend_runtime_suspend,
 };
 
+static const struct sun4i_frontend_data sun7i_a20_frontend = {
+   .ch_phase   = {
+   {
+   .horzphase = 0,
+   .vertphase = { 0, 0 },
+   },
+   {
+   .horzphase = 0xfc000,
+   .vertphase = { 0xfc000, 0xfc000 },
+   },
+   },
+   .has_coef_rdy   = true,
+};
+
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
.ch_phase   = {
{
@@ -691,6 +705,10 @@ static const struct sun4i_frontend_data sun8i_a33_frontend 
= {
 };
 
 const struct of_device_id sun4i_frontend_of_table[] = {
+   {
+   .compatible = "allwinner,sun7i-a20-display-frontend",
+   .data = &sun7i_a20_frontend
+   },
{
.compatible = "allwinner,sun8i-a33-display-frontend",
.data = &sun8i_a33_frontend
-- 
2.19.1

[PATCH v2 26/43] drm/sun4i: frontend: Add support for packed YUV422 input formats

[Paul Kocialkowski]

This introduces support for packed YUV formats with 4:2:2 sampling using
the frontend. Definitions are introduced for the data format and pixel
sequence input format register values.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 22 ++
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  5 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 4700133b96e0..f443e8e1d8ec 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -130,6 +130,8 @@ static int sun4i_frontend_drm_format_to_input_fmt(uint32_t 
fmt, u32 *val)
 {
if (!drm_format_is_yuv(fmt))
*val = SUN4I_FRONTEND_INPUT_FMT_DATA_FMT_RGB;
+   else if (drm_format_is_yuv_sampling_422(fmt))
+   *val = SUN4I_FRONTEND_INPUT_FMT_DATA_FMT_YUV422;
else
return -EINVAL;
 
@@ -153,10 +155,26 @@ static int 
sun4i_frontend_drm_format_to_input_sequence(uint32_t fmt, u32 *val)
*val = SUN4I_FRONTEND_INPUT_FMT_DATA_PS_BGRX;
return 0;
 
+   case DRM_FORMAT_UYVY:
+   *val = SUN4I_FRONTEND_INPUT_FMT_DATA_PS_UYVY;
+   return 0;
+
+   case DRM_FORMAT_VYUY:
+   *val = SUN4I_FRONTEND_INPUT_FMT_DATA_PS_VYUY;
+   return 0;
+
case DRM_FORMAT_XRGB:
*val = SUN4I_FRONTEND_INPUT_FMT_DATA_PS_XRGB;
return 0;
 
+   case DRM_FORMAT_YUYV:
+   *val = SUN4I_FRONTEND_INPUT_FMT_DATA_PS_YUYV;
+   return 0;
+
+   case DRM_FORMAT_YVYU:
+   *val = SUN4I_FRONTEND_INPUT_FMT_DATA_PS_YVYU;
+   return 0;
+
default:
return -EINVAL;
}
@@ -180,7 +198,11 @@ static int 
sun4i_frontend_drm_format_to_output_fmt(uint32_t fmt, u32 *val)
 
 static const uint32_t sun4i_frontend_formats[] = {
DRM_FORMAT_BGRX,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
 };
 
 bool sun4i_frontend_format_is_supported(uint32_t fmt)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h 
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index fb097c34e160..399755939a28 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -27,7 +27,12 @@
 
 #define SUN4I_FRONTEND_INPUT_FMT_REG   0x04c
 #define SUN4I_FRONTEND_INPUT_FMT_DATA_MOD_PACKED   (1 << 8)
+#define SUN4I_FRONTEND_INPUT_FMT_DATA_FMT_YUV422   (1 << 4)
 #define SUN4I_FRONTEND_INPUT_FMT_DATA_FMT_RGB  (5 << 4)
+#define SUN4I_FRONTEND_INPUT_FMT_DATA_PS_UYVY  0
+#define SUN4I_FRONTEND_INPUT_FMT_DATA_PS_YUYV  1
+#define SUN4I_FRONTEND_INPUT_FMT_DATA_PS_VYUY  2
+#define SUN4I_FRONTEND_INPUT_FMT_DATA_PS_YVYU  3
 #define SUN4I_FRONTEND_INPUT_FMT_DATA_PS_BGRX  0
 #define SUN4I_FRONTEND_INPUT_FMT_DATA_PS_XRGB  1
 
-- 
2.19.1

Re: [RESEND PATCH v17 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Tomasz Figa]

Hi Vivek, Will,

On Fri, Nov 23, 2018 at 6:13 PM Vivek Gautam
 wrote:
>
> Hi Will,
>
> On Wed, Nov 21, 2018 at 11:09 PM Will Deacon  wrote:
> >
> > [+Thor]
> >
> > On Fri, Nov 16, 2018 at 04:54:30PM +0530, Vivek Gautam wrote:
> > > qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> > > clock and power requirements.
> > > On msm8996, multiple cores, viz. mdss, video, etc. use this
> > > smmu. On sdm845, this smmu is used with gpu.
> > > Add bindings for the same.
> > >
> > > Signed-off-by: Vivek Gautam 
> > > Reviewed-by: Rob Herring 
> > > Reviewed-by: Tomasz Figa 
> > > Tested-by: Srinivas Kandagatla 
> > > Reviewed-by: Robin Murphy 
> > > ---
> > >  drivers/iommu/arm-smmu.c | 13 +
> > >  1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > index 2098c3141f5f..d315ca637097 100644
> > > --- a/drivers/iommu/arm-smmu.c
> > > +++ b/drivers/iommu/arm-smmu.c
> > > @@ -120,6 +120,7 @@ enum arm_smmu_implementation {
> > >   GENERIC_SMMU,
> > >   ARM_MMU500,
> > >   CAVIUM_SMMUV2,
> > > + QCOM_SMMUV2,
> > >  };
> > >
> > >  struct arm_smmu_s2cr {
> > > @@ -2026,6 +2027,17 @@ ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, 
> > > GENERIC_SMMU);
> > >  ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
> > >  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
> > >
> > > +static const char * const qcom_smmuv2_clks[] = {
> > > + "bus", "iface",
> > > +};
> > > +
> > > +static const struct arm_smmu_match_data qcom_smmuv2 = {
> > > + .version = ARM_SMMU_V2,
> > > + .model = QCOM_SMMUV2,
> > > + .clks = qcom_smmuv2_clks,
> > > + .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
> > > +};
> >
> > These seems redundant if we go down the route proposed by Thor, where we
> > just pull all of the clocks out of the device-tree. In which case, why
> > do we need this match_data at all?
>
> Which is better? Driver relying solely on the device tree to tell
> which all clocks
> are required to be enabled,
> or, the driver deciding itself based on the platform's match data,
> that it should
> have X, Y, & Z clocks that should be supplied from the device tree.

The former would simplify the driver, but would also make it
impossible to spot mistakes in DT, which would ultimately surface out
as very hard to debug bugs (likely complete system lockups).

For qcom_smmuv2, I believe we're eventually going to end up with
platform-specific quirks anyway, so specifying the clocks too wouldn't
hurt. Given that, I'd recommend sticking to the latter, i.e. what this
patch does.

Best regards,
Tomasz

Re: [PATCH v2] pwm: kconfig: enable kona pwm to be built for cygnus arch

[Clément Péron]

Hi,

On Thu, 22 Nov 2018 at 21:05, Uwe Kleine-König
 wrote:
>
> Hello Clément,
>
> On Wed, Nov 21, 2018 at 01:35:08PM +0100, Clément Péron wrote:
> > The Cygnus architecture use a Kona PWM. This is already present
> > in the device tree but can't be built actually. Hence, allow the
> > Kona PWM to be built for Cygnus arch.
> >
> > Signed-off-by: Clément Péron 
> > ---
> >  drivers/pwm/Kconfig | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > index 27e5dd47a01f..982f4059f4e8 100644
> > --- a/drivers/pwm/Kconfig
> > +++ b/drivers/pwm/Kconfig
> > @@ -88,7 +88,9 @@ config PWM_BCM_IPROC
> >
> >  config PWM_BCM_KONA
> >   tristate "Kona PWM support"
> > - depends on ARCH_BCM_MOBILE
> > + depends on ARCH_BCM_MOBILE || ARCH_BCM_CYGNUS || COMPILE_TEST
> > + depends on HAVE_CLK && HAS_IOMEM
> > + default ARCH_BCM_CYGNUS
>
> This looks good. As pointed out before the default is a bit strange
> and could include ARCH_BCM_MOBILE for symmetry.

Ok, let me resend a v3

>
> Anyhow:
>
> Acked-by: Uwe Kleine-König 
>
> Related to this driver I have a set of questions: If the disable
> callback completed, does the hardware still drive the pin? If yes, would
> it be possible to disable the pin driver such that the pin gets high-Z?
> If yes, how?

The output pin type is configured with the bit "21:16 PWMOUT_TYPE RW
default 0x3F" in the Control register
PWM_CONTROL_TYPE_SHIFT macro in the driver
Datasheets says : "When set to 1 the PWM Output signal will have a
push/pull type.When set to 0 the PWM Output signal will have an open
drain output type.Recommend to leave it push/pull type."

In the driver we actually set push/pull mode for all channels :
/* Set push/pull for all channels */
for (chan = 0; chan < kp->chip.npwm; chan++)
value |= (1 << PWM_CONTROL_TYPE_SHIFT(chan));

Regards,
Clement

>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | http://www.pengutronix.de/  |

[PATCH v2 08/43] drm/fourcc: Add helper to check if a format uses a YUV colorspace

[Paul Kocialkowski]

This adds a new helper to check whether the format described by its
fourcc code uses a YUV colorspace, by returning the is_yuv entry for
the DRM info entry matching that format.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/drm_fourcc.c | 19 +++
 include/drm/drm_fourcc.h |  1 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index f523948c82b1..f85650c3463a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -413,6 +413,25 @@ int drm_format_plane_height(int height, uint32_t format, 
int plane)
 }
 EXPORT_SYMBOL(drm_format_plane_height);
 
+/**
+ * drm_format_is_yuv - check that the format uses a YUV colorspace
+ * @format: pixel format
+ *
+ * Returns:
+ * A boolean indicating whether the format uses a YUV colorspace.
+ */
+bool drm_format_is_yuv(uint32_t format)
+{
+   const struct drm_format_info *info;
+
+   info = drm_format_info(format);
+   if (!info)
+   return false;
+
+   return info->is_yuv;
+}
+EXPORT_SYMBOL(drm_format_is_yuv);
+
 /**
  * drm_format_info_block_width - width in pixels of block.
  * @info: pixel format info
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bcb389f04618..569b70483505 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -157,6 +157,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
+bool drm_format_is_yuv(uint32_t format);
 unsigned int drm_format_info_block_width(const struct drm_format_info *info,
 int plane);
 unsigned int drm_format_info_block_height(const struct drm_format_info *info,
-- 
2.19.1

[PATCH v2 00/43] drm/sun4i: Support for linear and tiled YUV formats with the frontend

[Paul Kocialkowski]

This series implements support for YUV formats using the display engine
frontend in the sun4i DRM driver, with various fixes along the way.
Scaling is supported for every format handled by the frontend.

The tiling mode used by the VPU on Allwinner platforms is also supported
by this series and a dedicated fourcc modifier is introduced, along with
a specific ioctl for allocating tiled buffers.

New common fourcc helpers are also introduced in this series, especially
related to YUV formats.

This was tested on the A33 and A20 platforms and all supported features
work properly on both. Framebuffer offsets and source positions are not
supported at this point.

Changes since v1:
* Extended source selected cleanup to both YUV and video channels;
* Split and reworded comment about backend scaling;
* Sorted newly-introduced lists alphabetically;
* Simplified functions to check if a format is supported;
* Reworked frontend selection logic as discussed;
* Made YUV helpers common, with fourcc and drm_info fashions;
* Changed the CREATE_TILED ioctl flags to match the CREATE_DUMB ioctl;
* Reworked YUV dimensions calculations to use drm_format_info;
* Dropped MB32 part in modifier to match V4L2 definition name;
* Improved the description of the tiling modifier;
* Avoided splitting CSC coefficients to avoid introducing a new module;
* Fixed building the driver as modules;
* Various code simplifications and cleanups;
* Split commits into logical changes.

Maxime Ripard (5):
  drm/sun4i: Move access control before setting the register as
documented
  drm/sun4i: frontend: Add a quirk structure
  drm/sun4i: Set the coef_rdy bit right after the coef have been set
  drm/sun4i: Make COEF_RDY conditional
  drm/sun4i: frontend: Move the FIR filter phases to our quirks

Paul Kocialkowski (38):
  drm/sun4i: Cleanup video/YUV source before enabling a layer
  drm/sun4i: frontend: Replace ARGB with XRGB as supported format
  drm/sun4i: Add TODO comment about supporting scaling with the backend
  drm/sun4i: backend: Add a helper and a list for supported formats
  drm/sun4i: frontend: Add a helper and a list for supported formats
  drm/sun4i: backend: Refine the logic behind using the frontend
  drm/sun4i: backend: Use a specific function to check if a plane is
supported
  drm/fourcc: Add helper to check if a format uses a YUV colorspace
  drm/fourcc: Add format info helpers for checking YUV planes
disposition
  drm/fourcc: Add format helpers for checking YUV planes disposition
  drm/fourcc: Add format info helpers for checking YUV sub-sampling
  drm/fourcc: Add format helpers for checking YUV sub-sampling
  drm/sun4i: backend: Use explicit fourcc helpers for packed YUV422
check
  drm/sun4i: backend: Avoid counting YUV planes that use the frontend
  drm/sun4i: Rename sun4i_backend_layer_formats to sun4i_layer_formats
  drm/sun4i: frontend: Move CSC bypass setup to format update routine
  drm/sun4i: frontend: Add helpers for input data mode and pixel
sequence
  drm/sun4i: frontend: Add proper definitions for format registers
  drm/sun4i: frontend: Determine input mode based on the number of
planes
  drm/sun4i: frontend: Determine input format based on colorspace
  drm/sun4i: frontend: Add support for the BGRX input format
  drm/sun4i: frontend: Add support for the BGRX output format
  drm/sun4i: backend: Detail the YUV to RGB values coding explanation
  drm/sun4i: frontend: Configure and enable YUV to RGB CSC when needed
  drm/sun4i: frontend: Apply format sub-sampling to CH1 dimensions
  drm/sun4i: frontend: Add support for packed YUV422 input formats
  drm/sun4i: frontend: Add support for semi-planar YUV input formats
  drm/sun4i: frontend: Add support for planar YUV input formats
  drm/sun4i: Make pitch even for GEM dumb alloc as per hardware
constraint
  drm/fourcc: Add definitions for Allwinner vendor and VPU tiled format
  drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers
  drm/sun4i: Pass modifier to backend and frontend format support
helpers
  drm/sun4i: frontend: Add support for tiled YUV input mode
configuration
  drm/sun4i: Add buffer stride and offset configuration for tiling mode
  drm/sun4i: frontend: Add and use helper for checking tiling support
  drm/sun4i: layer: Add tiled modifier support and helper
  drm/sun4i: drv: Allow framebuffer modifiers in mode config
  drm/sun4i: frontend: Add A20-specific device-tree compatible and
quirks

 drivers/gpu/drm/drm_fourcc.c   | 184 +++
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 109 ++-
 drivers/gpu/drm/sun4i/sun4i_backend.h  |   3 +
 drivers/gpu/drm/sun4i/sun4i_drv.c  | 102 +-
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 415 ++---
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  50 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.c|  41 ++-
 include/drm/drm_fourcc.h   | 126 
 include/uapi/drm/drm_fourcc.h  |  16 +
 include/uapi/drm/sun4i_drm.h   | 

Re: [PATCH v2] phy: mvebu-cp110-comphy: fix spelling in structure name

[Antoine Tenart]

Hi Miquel,

On Fri, Nov 23, 2018 at 10:21:15AM +0100, Miquel Raynal wrote:
> Rename the mvebu_comhy_conf structure to be mvebu_comphy_conf, which is
> probably what the original author meant.
> 
> Signed-off-by: Miquel Raynal 

Acked-by: Antoine Tenart 

Thanks!
Antoine

> ---
> 
> Changes since v1
> 
> * Removed the Fixes: tag after Antoine's request.
> 
> 
>  drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
> b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> index 86a5f7b9448b..31b9a1c18345 100644
> --- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -114,7 +114,7 @@
>  #define MVEBU_COMPHY_LANES   6
>  #define MVEBU_COMPHY_PORTS   3
>  
> -struct mvebu_comhy_conf {
> +struct mvebu_comphy_conf {
>   enum phy_mode mode;
>   unsigned lane;
>   unsigned port;
> @@ -129,7 +129,7 @@ struct mvebu_comhy_conf {
>   .mux = _mux,\
>   }
>  
> -static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> +static const struct mvebu_comphy_conf mvebu_comphy_cp110_modes[] = {
>   /* lane 0 */
>   MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
>   MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
> -- 
> 2.19.1
> 

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

[David Laight]

From: Linus Torvalds
> Sent: 22 November 2018 18:58
...
> Oh, and I just noticed that on x86 we expressly use our old "safe and
> sane" functions: see __inline_memcpy(), and its use in
> __memcpy_{from,to}io().
> 
> So the "falls back to memcpy" was always a red herring. We don't
> actually do that.
> 
> Which explains why things work.

It doesn't explain why I've seen single byte PCIe TLP generated
by memcpy_to/fromio().

I've had to change code to use readq/writeq loops because the
byte accesses are so slow - even when PIO performance should
be 'good enough'.

It might have been changed since last time I tested it.
But I don't remember seeing a commit go by.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH v3] pwm: kconfig: enable kona pwm to be built for cygnus arch

[Clément Péron]

The Cygnus architecture use a Kona PWM. This is already present
in the device tree but can't be built actually. Hence, allow the
Kona PWM to be built for Cygnus arch.

Signed-off-by: Clément Péron 
Reviewed-by: Florian Fainelli 
Reviewed-by: Scott Branden 
Acked-by: Uwe Kleine-König 
---
 drivers/pwm/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 27e5dd47a01f..a8f47df0655a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -88,7 +88,9 @@ config PWM_BCM_IPROC
 
 config PWM_BCM_KONA
tristate "Kona PWM support"
-   depends on ARCH_BCM_MOBILE
+   depends on ARCH_BCM_MOBILE || ARCH_BCM_CYGNUS || COMPILE_TEST
+   depends on HAVE_CLK && HAS_IOMEM
+   default ARCH_BCM_MOBILE || ARCH_BCM_CYGNUS
help
  Generic PWM framework driver for Broadcom Kona PWM block.
 
-- 
2.19.1

[PATCH v2 net] phy: Micrel KSZ8061: link failure after cable connect

[Onnasch, Alexander (EXT)]

With Micrel KSZ8061 PHY, the link may occasionally not come up after
Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
sheet 8688A.pdf describes the problem and possible workarounds in
detail, see below.
The patch implements workaround 1, which permanently fixes the issue.

DESCRIPTION
Link-up may not occur properly when the Ethernet cable is initially
connected. This issue occurs more commonly when the cable is connected
slowly, but it may occur any time a cable is connected. This issue occurs
in the auto-negotiation circuit, and will not occur if auto-negotiation
is disabled (which requires that the two link partners be set to the
same speed and duplex).

END USER IMPLICATIONS
When this issue occurs, link is not established. Subsequent cable
plug/unplug cycles will not correct the issue.

WORK AROUND
There are four approaches to work around this issue:
1.  This issue can be prevented by setting bit 15 in MMD device address 1,
register 2, prior to connecting the  cable or prior to setting the
Restart Auto-Negotiation bit in register 0h.The MMD registers are
accessed via the indirect access registers Dh and Eh, or via the Micrel
EthUtil utility as shown here:
•  If using the EthUtil utility (usually with a Micrel KSZ8061
   Evaluation Board), type the following commands:
   > address 1
   > mmd 1
   > iw 2 b61a
•  Alternatively, write the following registers to write to the
   indirect MMD register:
   Write register Dh, data 0001h
   Write register Eh, data 0002h
   Write register Dh, data 4001h
   Write register Eh, data B61Ah
2.  The issue can be avoided by disabling auto-negotiation in the KSZ8061,
either by the strapping option, or by clearing bit 12 in register 0h.
Care must be taken to ensure that the KSZ8061 and the link partner
will link with the same speed and duplex. Note that the KSZ8061
defaults to full-duplex when auto-negotiation is off, but other
devices may default to half-duplex in the event of failed
auto-negotiation.
3.  The issue can be avoided by connecting the cable prior to powering-up
or resetting the KSZ8061, and leaving it plugged in thereafter.
4.  If the above measures are not taken and the problem occurs, link can
be recovered by setting the Restart Auto-Negotiation bit in
register 0h, or by resetting or power cycling the device. Reset may
be either hardware reset or software reset (register 0h, bit 15).

PLAN
This errata will not be corrected in a future revision.

Signed-off-by: Alexander Onnasch 
Reviewed-by: Andrew Lunn 
---
 drivers/net/phy/micrel.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 6c45ff6..eb85cf4 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -339,6 +339,17 @@ static int ksz8041_config_aneg(struct phy_device *phydev)
return genphy_config_aneg(phydev);
 }
 
+static int ksz8061_config_init(struct phy_device *phydev)
+{
+   int ret;
+
+   ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_DEVID1, 0xB61A);
+   if (ret)
+   return ret;
+
+   return kszphy_config_init(phydev);
+}
+
 static int ksz9021_load_values_from_of(struct phy_device *phydev,
   const struct device_node *of_node,
   u16 reg,
@@ -938,7 +949,7 @@ static struct phy_driver ksphy_driver[] = {
.phy_id_mask= MICREL_PHY_ID_MASK,
.features   = PHY_BASIC_FEATURES,
.flags  = PHY_HAS_INTERRUPT,
-   .config_init= kszphy_config_init,
+   .config_init= ksz8061_config_init,
.config_aneg= genphy_config_aneg,
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
-- 
2.7.4

Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API

[Roger Quadros]

On 23/11/18 10:20, Arnd Bergmann wrote:
> On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros  wrote:
> 
>> +
>> +   if (IS_ERR_OR_NULL(rproc))
>> +   return ERR_PTR(-EINVAL);
> 
> 
> Any usage of  IS_ERR_OR_NULL() tends to be an indication of a badly
> designed API. Please change this to allow only one of the two to be passed
> around.

The user of this API has to call pru_rproc_get() which never returns NULL.
So IS_ERR() should suffice here.

> 
>Arnd
> 

cheers,
-roger

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs

[Linus Walleij]

On Thu, Nov 22, 2018 at 6:30 PM Charles Keepax
 wrote:

> Currently, a GPIO can be requested multiple times when the
> NONEXCLUSIVE flag is set, however it must still be freed a single
> time. This makes client code rather complex, since multiple drivers
> may request the GPIO but only a single one can free it. Rather than
> manually handling this in each driver add some basic reference
> counting into the core.  Currently, this is fairly primitive but
> so is the support for the NONEXCLUSIVE flag and the implementation
> covers those use-cases.
>
> Reported-by: Marek Szyprowski 
> Signed-off-by: Charles Keepax 

This patch is not fixing anything right now, correct?

I discussed the notion of pulling reference counting for
nonexclusive GPIOs into gpiolib with Mark but the benefit is
a bit unclear: if the subsystem using nonexeclusive GPIOs
(currently only regulators) would still have to keep its own
reference count or somehow semantically know when
the last user is gone, the point is kind of moot.

I haven't looked closely at the regulators case but I got
the impression that it is more complex than just reference
counting so, currently I don't know if this is such a good
idea.

Anyway I would like to push this until we have cleaned
up with the rest of the series I have boiling, if you don't
mind.

(Patch 1+2 should be fine anyway.)

Yours,
Linus Walleij

Re: [PATCH] pinctrl: rzn1: Fix check for used MDIO bus

[Geert Uytterhoeven]

Hi Phil,

Thanks for your patch!

On Mon, Nov 19, 2018 at 5:18 PM Phil Edworthy  wrote:
> This fixes the check for unused mdio bus setting and the following static
> checker warning:
>  drivers/pinctrl/pinctrl-rzn1.c:198 rzn1_pinctrl_mdio_select()
>  warn: always true condition '(ipctl->mdio_func[mdio] >= 0) => (0-u32max >= 
> 0)'
>
> It also fixes the return var when calling of_get_child_count()

I think this should be a separate patch.

> Reported-by: Dan Carpenter 
> Signed-off-by: Phil Edworthy 

Reviewed-by: Geert Uytterhoeven 

BTW, I have a question about rzn1_pinctrl_mdio_select():

static void rzn1_pinctrl_mdio_select(struct rzn1_pinctrl *ipctl, int mdio,
 u32 func)
{
if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] != func)
dev_warn(ipctl->dev, "conflicting setting for mdio%d!\n", mdio);
ipctl->mdio_func[mdio] = func;

dev_dbg(ipctl->dev, "setting mdio%d to %u\n", mdio, func);

writel(func, &ipctl->lev2->l2_mdio[mdio]);
}

The check warns the user if it overrides an already initialized MDIO function
with a different value.
However, there is no method to uninitialize (reset to -1) mdio_func[], to
avoid getting the warning.

For a use case, I was thinking about a DT overlay that would cause the
MDIO function to be initialized on loading, and needs to uninitialize the
MDIO function on removing.

Perhaps that is very unlikely or even impossible, given the function of the
pins controlled by the MDIO function?

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

Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API

[Roger Quadros]

On 23/11/18 04:47, kbuild test robot wrote:
> Hi Tero,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on keystone/next]
> [also build test ERROR on v4.20-rc3 next-20181122]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Roger-Quadros/Add-support-for-TI-PRU-ICSS/20181123-083903
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
> next
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from drivers/soc/ti/pruss_intc.c:16:0:
>>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside 
>>> parameter list will not be visible outside of this definition or declaration
> struct pruss *pruss_get(struct rproc *rproc);
>^

This was my bad due to re-ordering of patches. Fixed now.

cheers,
-roger

> --
>In file included from drivers/soc/ti/pruss.c:15:0:
>>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside 
>>> parameter list will not be visible outside of this definition or declaration
> struct pruss *pruss_get(struct rproc *rproc);
>^
>>> drivers/soc/ti/pruss.c:34:15: error: conflicting types for 'pruss_get'
> struct pruss *pruss_get(struct rproc *rproc)
>   ^
>In file included from drivers/soc/ti/pruss.c:15:0:
>include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was 
> here
> struct pruss *pruss_get(struct rproc *rproc);
>   ^
>In file included from include/linux/linkage.h:7:0,
> from include/linux/kernel.h:7,
> from include/linux/list.h:9,
> from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from include/linux/dma-mapping.h:7,
> from drivers/soc/ti/pruss.c:10:
>drivers/soc/ti/pruss.c:58:19: error: conflicting types for 'pruss_get'
> EXPORT_SYMBOL_GPL(pruss_get);
>   ^
>include/linux/export.h:79:21: note: in definition of macro 
> '___EXPORT_SYMBOL'
>  extern typeof(sym) sym;  \
> ^~~
>>> drivers/soc/ti/pruss.c:58:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
> EXPORT_SYMBOL_GPL(pruss_get);
> ^
>In file included from drivers/soc/ti/pruss.c:15:0:
>include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was 
> here
> struct pruss *pruss_get(struct rproc *rproc);
>   ^
> --
>In file included from drivers/soc//ti/pruss.c:15:0:
>>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside 
>>> parameter list will not be visible outside of this definition or declaration
> struct pruss *pruss_get(struct rproc *rproc);
>^
>drivers/soc//ti/pruss.c:34:15: error: conflicting types for 'pruss_get'
> struct pruss *pruss_get(struct rproc *rproc)
>   ^
>In file included from drivers/soc//ti/pruss.c:15:0:
>include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was 
> here
> struct pruss *pruss_get(struct rproc *rproc);
>   ^
>In file included from include/linux/linkage.h:7:0,
> from include/linux/kernel.h:7,
> from include/linux/list.h:9,
> from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from include/linux/dma-mapping.h:7,
> from drivers/soc//ti/pruss.c:10:
>drivers/soc//ti/pruss.c:58:19: error: conflicting types for 'pruss_get'
> EXPORT_SYMBOL_GPL(pruss_get);
>   ^
>include/linux/export.h:79:21: note: in definition of macro 
> '___EXPORT_SYMBOL'
>  extern typeof(sym) sym;  \
> ^~~
>drivers/soc//ti/pruss.c:58:1: note: in expansion of macro 
> 'EXPOR

Re: [PATCH] mtd: spi-nor: fix erase_type array to indicate current map conf

[Sverdlin, Alexander (Nokia - DE/Ulm)]

Hello Tudor,

On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus 
> 
> Bug reported for the out-of-tree S25FS128S flash memory.
> 
> BFPT table advertises all the erase types supported by all the
> possible map configurations. Update the erase_type array to indicate
> which erase types are applicable to the current map configuration.
> 
> Backward compatibility test done on sst26vf064b.
> 
> Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
> Reported-by: Alexander Sverdlin 
> Signed-off-by: Tudor Ambarus 

I've tested this patch and it fixes the erasesize for S25FS128S and
our 128k partitions are writeable again with this patch.

Nevertheless, I think this is coincidence. I don't think that it
makes sense to OR all the erase types from all regions in one
bitmask and derive any uniform erasesize out of it.
This makes little sense for me in case of non-uniform maps.

I believe, the culprit here is one level higher, in the MTD partitioning
code (mtdpart.c) which has to be taught about non-uniform maps
but there is no infrastructure for this currently.

What is possible to fix still is to choose smallest, not biggest
erasesize for uniform case. I have such a patch, but I need hands
on on a S25FS128S configured in uniform mode.

Non uniform case requires MTD layer rework. We just cannot handle
this hardware with just one erasesize in mind. 

> ---
>  drivers/mtd/spi-nor/spi-nor.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 93c9bc8931fc..a71adcd6ddfa 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -3000,7 +3000,8 @@ static int spi_nor_init_non_uniform_erase_map(struct 
> spi_nor *nor,
>   u64 offset;
>   u32 region_count;
>   int i, j;
> - u8 erase_type, uniform_erase_type;
> + u8 uniform_erase_type, save_uniform_erase_type;
> + u8 erase_type, regions_erase_type;
>  
>   region_count = SMPT_MAP_REGION_COUNT(*smpt);
>   /*
> @@ -3014,6 +3015,7 @@ static int spi_nor_init_non_uniform_erase_map(struct 
> spi_nor *nor,
>   map->regions = region;
>  
>   uniform_erase_type = 0xff;
> + regions_erase_type = 0;
>   offset = 0;
>   /* Populate regions. */
>   for (i = 0; i < region_count; i++) {
> @@ -3030,13 +3032,38 @@ static int spi_nor_init_non_uniform_erase_map(struct 
> spi_nor *nor,
>*/
>   uniform_erase_type &= erase_type;
>  
> + /*
> +  * regions_erase_type mask will indicate all the erase types
> +  * supported in this configuration map.
> +  */
> + regions_erase_type |= erase_type;
> +
>   offset = (region[i].offset & ~SNOR_ERASE_FLAGS_MASK) +
>region[i].size;
>   }
>  
> + save_uniform_erase_type = map->uniform_erase_type;
>   map->uniform_erase_type = spi_nor_sort_erase_mask(map,
> uniform_erase_type);
>  
> + if (!regions_erase_type) {
> + /*
> +  * Roll back to the previous uniform_erase_type mask, SMPT is
> +  * broken.
> +  */
> + map->uniform_erase_type = save_uniform_erase_type;
> + return -EINVAL;
> + }
> +
> + /*
> +  * BFPT table advertises all the erase types supported by all the
> +  * possible map configurations. Update the erase_type array to indicate
> +  * which erase types are applicable to the current map configuration.
> +  */
> + for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++)
> + if (!(regions_erase_type & BIT(erase[i].idx)))
> + spi_nor_set_erase_type(&erase[i], 0, 0xFF);
> +
>   spi_nor_region_mark_end(®ion[i - 1]);
>  
>   return 0;

-- 
Best regards,
Alexander Sverdlin.

[PATCH 3/3] ARM: dts: Add g3d bus nodes using VDD_INT for Exynos542x SoC

[Anand Moon]

Add missing Netwwork on chip for g3d bus node using VDD_INI
for Exynos542x SoC.

- CLK_DOUT_ACLK_G3D for G3D's AXI

Cc: Chanwoo Choi 
Signed-off-by: Anand Moon 
---
 arch/arm/boot/dts/exynos5420.dtsi | 57 +--
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi |  5 ++
 2 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index aaff15880761..bc7203bb1282 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -1047,6 +1047,14 @@
status = "disabled";
};
 
+   bus_g3d: bus_g3d {
+   compatible = "samsung,exynos-bus";
+   clocks = <&clock CLK_DOUT_ACLK_G3D>;
+   clock-names = "bus";
+   operating-points-v2 = <&bus_g3d_opp_table>;
+   status = "disabled";
+   };
+
bus_jpeg: bus_jpeg {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK300_JPEG>;
@@ -1245,7 +1253,44 @@
};
};
 
-   bus_jpeg_opp_table: opp_table11 {
+   bus_g3d_opp_table: opp_table11 {
+   compatible = "operating-points-v2";
+
+   opp@6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <1025000>;
+   };
+   opp@54300 {
+   opp-hz = /bits/ 64 <54300>;
+   opp-microvolt = <987500>;
+   };
+   opp@48000 {
+   opp-hz = /bits/ 64 <48000>;
+   opp-microvolt = <95>;
+   };
+   opp@42000 {
+   opp-hz = /bits/ 64 <42000>;
+   opp-microvolt = <937500>;
+   };
+   opp@35000 {
+   opp-hz = /bits/ 64 <35000>;
+   opp-microvolt = <90>;
+   };
+   opp@26600 {
+   opp-hz = /bits/ 64 <26600>;
+   opp-microvolt = <862500>;
+   };
+   opp@17700 {
+   opp-hz = /bits/ 64 <17700>;
+   opp-microvolt = <862500>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <862500>;
+   };
+   };
+
+   bus_jpeg_opp_table: opp_table12 {
compatible = "operating-points-v2";
 
opp00 {
@@ -1262,7 +1307,7 @@
};
};
 
-   bus_jpeg_apb_opp_table: opp_table12 {
+   bus_jpeg_apb_opp_table: opp_table13 {
compatible = "operating-points-v2";
 
opp00 {
@@ -1279,7 +1324,7 @@
};
};
 
-   bus_disp1_fimd_opp_table: opp_table13 {
+   bus_disp1_fimd_opp_table: opp_table14 {
compatible = "operating-points-v2";
 
opp00 {
@@ -1290,7 +1335,7 @@
};
};
 
-   bus_disp1_opp_table: opp_table14 {
+   bus_disp1_opp_table: opp_table15 {
compatible = "operating-points-v2";
 
opp00 {
@@ -1304,7 +1349,7 @@
};
};
 
-   bus_gscl_opp_table: opp_table15 {
+   bus_gscl_opp_table: opp_table16 {
compatible = "operating-points-v2";
 
opp00 {
@@ -1318,7 +1363,7 @@
};
};
 
-   bus_mscl_opp_table: opp_table16 {
+   bus_mscl_opp_table: opp_table17 {
compatible = "operating-points-v2";
 
opp00 {
diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi 
b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index 2fac4baf1eb4..6e39e4594502 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -89,6 +89,11 @@
status = "okay";
 };
 
+&bus_g3d {
+   devfreq = <&bus_wcore>;
+   status = "okay";
+};
+
 &bus_jpeg {
devfreq = <&bus_wcore>;
status = "okay";
-- 
2.17.1

[PATCH 2/3] clk: samsung: exynos5420: Add CLK_SET_RATE_PARENT flag to mout_sclk_vpll

[Anand Moon]

This allows changing the VPLL output frequency through the g3d subsystem
clock tree leaf clocks.

Cc: Andrzej Hajda 
Cc: Chanwoo Choi 
Signed-off-by: Anand Moon 
---
 drivers/clk/samsung/clk-exynos5420.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 34156bdfd0d2..6bf1b2e89106 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -647,7 +647,8 @@ static const struct samsung_mux_clock exynos5x_mux_clks[] 
__initconst = {
mout_user_aclk300_gscl_p, SRC_TOP5, 28, 1),
 
MUX(0, "mout_sclk_mpll", mout_mpll_p, SRC_TOP6, 0, 1),
-   MUX(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
+   MUX_F(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1,
+   CLK_SET_RATE_PARENT, 0),
MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
MUX(0, "mout_sclk_ipll", mout_ipll_p, SRC_TOP6, 12, 1),
MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
-- 
2.17.1

[PATCH 1/3] clk: samsung: exynos5420: add VPLL rate table for g3d clock

[Anand Moon]

From: Marian Mihailescu 

A specific clock rate table is added for VPLL so it is possible
to set frequency of the VPLL output clock that used by the g3d clock.

Cc: Andrzej Hajda 
Cc: Chanwoo Choi 
Signed-off-by: Marian Mihailescu 
Signed-off-by: Anand Moon 
---
 drivers/clk/samsung/clk-exynos5420.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 34cce3c5898f..34156bdfd0d2 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1303,6 +1303,18 @@ static const struct samsung_pll_rate_table 
exynos5420_epll_24mhz_tbl[] = {
PLL_36XX_RATE(24 * MHZ,  32768001U, 131, 3, 5, 4719),
 };
 
+static const struct samsung_pll_rate_table exynos5420_vpll_24mhz_tbl[] 
__initconst = {
+   PLL_35XX_RATE(24 * MHZ, 6U, 200, 2, 2),
+   PLL_35XX_RATE(24 * MHZ, 54300U, 181, 2, 2),
+   PLL_35XX_RATE(24 * MHZ, 53300U, 533, 6, 2),
+   PLL_35XX_RATE(24 * MHZ, 48000U, 320, 4, 2),
+   PLL_35XX_RATE(24 * MHZ, 42000U, 140, 2, 2),
+   PLL_35XX_RATE(24 * MHZ, 35000U, 175, 3, 2),
+   PLL_35XX_RATE(24 * MHZ, 26600U, 266, 3, 3),
+   PLL_35XX_RATE(24 * MHZ, 17700U, 118, 2, 3),
+   PLL_35XX_RATE(24 * MHZ, 1U, 200, 3, 4),
+};
+
 static struct samsung_pll_clock exynos5x_plls[nr_plls] __initdata = {
[apll] = PLL(pll_2550, CLK_FOUT_APLL, "fout_apll", "fin_pll", APLL_LOCK,
APLL_CON0, NULL),
@@ -1428,6 +1440,7 @@ static void __init exynos5x_clk_init(struct device_node 
*np,
exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
+   exynos5x_plls[vpll].rate_table = exynos5420_vpll_24mhz_tbl;
}
 
samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
-- 
2.17.1

Re: [PATCH v2] kmemleak: Turn kmemleak_lock to raw spinlock on RT

[Sebastian Andrzej Siewior]

On 2018-11-22 17:04:19 [+0800], zhe...@windriver.com wrote:
> From: He Zhe 
> 
> kmemleak_lock, as a rwlock on RT, can possibly be held in atomic context and
> causes the follow BUG.
> 
> BUG: scheduling while atomic: migration/15/132/0x0002
…
> Preemption disabled at:
> [] cpu_stopper_thread+0x71/0x100
> CPU: 15 PID: 132 Comm: migration/15 Not tainted 4.19.0-rt1-preempt-rt #1
> Hardware name: Intel Corp. Harcuvar/Server, BIOS 
> HAVLCRB1.X64.0015.D62.1708310404 08/31/2017
> Call Trace:
>  dump_stack+0x4f/0x6a
>  ? cpu_stopper_thread+0x71/0x100
>  __schedule_bug.cold.16+0x38/0x55
>  __schedule+0x484/0x6c0
>  schedule+0x3d/0xe0
>  rt_spin_lock_slowlock_locked+0x118/0x2a0
>  rt_spin_lock_slowlock+0x57/0x90
>  __rt_spin_lock+0x26/0x30
>  __write_rt_lock+0x23/0x1a0
>  ? intel_pmu_cpu_dying+0x67/0x70
>  rt_write_lock+0x2a/0x30
>  find_and_remove_object+0x1e/0x80
>  delete_object_full+0x10/0x20
>  kmemleak_free+0x32/0x50
>  kfree+0x104/0x1f0
>  ? x86_pmu_starting_cpu+0x30/0x30
>  intel_pmu_cpu_dying+0x67/0x70
>  x86_pmu_dying_cpu+0x1a/0x30
>  cpuhp_invoke_callback+0x92/0x700
>  take_cpu_down+0x70/0xa0
>  multi_cpu_stop+0x62/0xc0
>  ? cpu_stop_queue_work+0x130/0x130
>  cpu_stopper_thread+0x79/0x100
>  smpboot_thread_fn+0x20f/0x2d0
>  kthread+0x121/0x140
>  ? sort_range+0x30/0x30
>  ? kthread_park+0x90/0x90
>  ret_from_fork+0x35/0x40

If this is the only problem? kfree() from a preempt-disabled section
should cause a warning even without kmemleak.

> And on v4.18 stable tree the following call trace, caused by grabbing
> kmemleak_lock again, is also observed.
> 
> kernel BUG at kernel/locking/rtmutex.c:1048! 
> invalid opcode:  [#1] PREEMPT SMP PTI 
> CPU: 5 PID: 689 Comm: mkfs.ext4 Not tainted 4.18.16-rt9-preempt-rt #1 
…
> Call Trace: 
>  ? preempt_count_add+0x74/0xc0 
>  rt_spin_lock_slowlock+0x57/0x90 
>  ? __kernel_text_address+0x12/0x40 
>  ? __save_stack_trace+0x75/0x100 
>  __rt_spin_lock+0x26/0x30 
>  __write_rt_lock+0x23/0x1a0 
>  rt_write_lock+0x2a/0x30 
>  create_object+0x17d/0x2b0 
…

is this an RT-only problem? Because mainline should not allow read->read
locking or read->write locking for reader-writer locks. If this only
happens on v4.18 and not on v4.19 then something must have fixed it.
 

Sebastian

Re: [PATCH 1/4] OPP: Add dev_pm_opp_xlate_performance_state() helper

[Viresh Kumar]

On 23-11-18, 14:41, Viresh Kumar wrote:
> On 22-11-18, 11:38, Viresh Kumar wrote:
> > So there are few complexities in the case where an OPP table points to 
> > itself in
> > the required-opp field. I looked at solving it up in the opp core but that 
> > gets
> > more and more messy.
> > 
> > Now there is actually a assumption within the OPP core. Your Mx domain 
> > should
> > get initialized before the Cx domain, as that is when the OPP tables are 
> > created
> > as well. This is because Cx's OPP table will point to Mx's OPP table 
> > (doesn't
> > matter if they share the same table or not) and so Mx's OPP table should 
> > come
> > first.
> > 
> > Can you check if that is already the case for you? If not, please try doing 
> > it
> > and lemme know if it works. It should.
> > 
> > I just want to avoid too much complexity in OPP core without much use.
> 
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 7f338d39809a..09df3fbdb555 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -1734,7 +1734,7 @@ unsigned int dev_pm_opp_xlate_performance_state(struct 
> opp_table *src_table,
> int i;
>  
> for (i = 0; i < src_table->required_opp_count; i++) {
> -   if (src_table->required_opp_tables[i] == dst_table)
> +   if (src_table->required_opp_tables[i]->np == dst_table->np)
> break;
> }
> 
> Try this fix and it should make it work for you.
> 
> Having said that, the way you are representing all your domains with a
> single OPP table look incorrect. You are using the same OPP table for
> around 10 power domains, all provided by a single provider. This is
> absolutely fine. But the Mx domain doesn't have any dependency on any
> other domain actually and so its OPPs should never have the
> "required-opps" property, but it has those properties in your setup as
> you are trying to use the same OPP table. That may all work fine with
> the above patch (which is required anyway as it fixes a valid issue),
> but you may see a error warning that something failed for Mx domain,
> as it has required-opps property but no required device or genpd.
> 
> Anyway, please test above first and then you can fix your tables :)

Here is the fix you need for the case where cx and mx have 1:1 mapping
and we don't need to duplicate OPP tables in DT.

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index ad944d75b40b..99b71f60b6d8 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1727,6 +1727,16 @@ unsigned int dev_pm_opp_xlate_performance_state(struct 
opp_table *src_table,
unsigned int dest_pstate = 0;
int i;
 
+   /*
+* Normally the src_table will have the "required_opps" property set to
+* point to one of the OPPs in the dst_table, but in some cases the
+* genpd and its master have one to one mapping of performance states
+* and so none of them have the "required-opps" property set. Return the
+* pstate of the src_table as it is in such cases.
+*/
+   if (!src_table->required_opp_count)
+   return pstate;
+
for (i = 0; i < src_table->required_opp_count; i++) {
if (src_table->required_opp_tables[i]->np == dst_table->np)
break;

-- 
viresh

Re: [PATCH v4 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver

[Kishon Vijay Abraham I]

Hi,

On 19/11/18 4:38 PM, Shawn Guo wrote:
> It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> 
> Signed-off-by: Shawn Guo 
> ---
>  drivers/phy/qualcomm/Kconfig  |  10 +
>  drivers/phy/qualcomm/Makefile |   1 +
>  .../phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c  | 535 ++
>  3 files changed, 546 insertions(+)
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> 
> diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
> index 32f7d34eb784..c7b5ee82895d 100644
> --- a/drivers/phy/qualcomm/Kconfig
> +++ b/drivers/phy/qualcomm/Kconfig
> @@ -82,3 +82,13 @@ config PHY_QCOM_USB_HSIC
>   select GENERIC_PHY
>   help
> Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
> +
> +config PHY_QCOM_USB_HS_SNPS_28NM
> + tristate "Qualcomm Synopsys 28nm USB HS PHY driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in
> + select GENERIC_PHY
> + help
> +   Enable this to support the Synopsys 28nm Femto USB PHY on Qualcomm
> +   chips. This driver supports the high-speed PHY which is usually
> +   paired with either the ChipIdea or Synopsys DWC3 USB IPs on MSM SOCs.
> diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
> index c56efd3af205..dc238d95b18c 100644
> --- a/drivers/phy/qualcomm/Makefile
> +++ b/drivers/phy/qualcomm/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_QCOM_UFS_14NM)   += 
> phy-qcom-ufs-qmp-14nm.o
>  obj-$(CONFIG_PHY_QCOM_UFS_20NM)  += phy-qcom-ufs-qmp-20nm.o
>  obj-$(CONFIG_PHY_QCOM_USB_HS)+= phy-qcom-usb-hs.o
>  obj-$(CONFIG_PHY_QCOM_USB_HSIC)  += phy-qcom-usb-hsic.o
> +obj-$(CONFIG_PHY_QCOM_USB_HS_SNPS_28NM)  += phy-qcom-usb-hs-snsp-28nm.o
> diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c 
> b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> new file mode 100644
> index ..ee52bb6df6da
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-usb-hs-snsp-28nm.c
> @@ -0,0 +1,535 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2009-2018, Linux Foundation. All rights reserved.
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* PHY register and bit definitions */
> +#define PHY_CTRL_COMMON0 0x078
> +#define SIDDQBIT(2)
> +#define PHY_IRQ_CMD  0x0d0
> +#define PHY_INTR_MASK0   0x0d4
> +#define PHY_INTR_CLEAR0  0x0dc
> +#define DPDM_MASK0x1e
> +#define DP_1_0   BIT(4)
> +#define DP_0_1   BIT(3)
> +#define DM_1_0   BIT(2)
> +#define DM_0_1   BIT(1)
> +
> +enum hsphy_voltage {
> + VOL_NONE,
> + VOL_MIN,
> + VOL_MAX,
> + VOL_NUM,
> +};
> +
> +enum hsphy_vreg {
> + VDD,
> + VDDA_1P8,
> + VDDA_3P3,
> + VREG_NUM,
> +};
> +
> +struct hsphy_init_seq {
> + int offset;
> + int val;
> + int delay;
> +};
> +
> +struct hsphy_data {
> + const struct hsphy_init_seq *init_seq;
> + unsigned int init_seq_num;
> +};
> +
> +struct hsphy_priv {
> + void __iomem *base;
> + struct clk_bulk_data *clks;
> + int num_clks;
> + struct reset_control *phy_reset;
> + struct reset_control *por_reset;
> + struct regulator_bulk_data vregs[VREG_NUM];
> + unsigned int voltages[VREG_NUM][VOL_NUM];
> + const struct hsphy_data *data;
> + bool cable_connected;
> + struct extcon_dev *vbus_edev;
> + struct notifier_block vbus_notify;
> + enum phy_mode mode;
> +};
> +
> +static int qcom_snps_hsphy_config_regulators(struct hsphy_priv *priv, int 
> high)
> +{
> + int old_uV[VREG_NUM];
> + int min, ret, i;
> +
> + min = high ? 1 : 0; /* low or none? */
> +
> + for (i = 0; i < VREG_NUM; i++) {
> + old_uV[i] = regulator_get_voltage(priv->vregs[i].consumer);
> + ret = regulator_set_voltage(priv->vregs[i].consumer,
> + priv->voltages[i][min],
> + priv->voltages[i][VOL_MAX]);
> + if (ret)
> + goto roll_back;
> + }
> +
> + return 0;
> +
> +roll_back:
> + for (; i >= 0; i--)
> + regulator_set_voltage(priv->vregs[i].consumer,
> +   old_uV[i], old_uV[i]);
> + return ret;
> +}
> +
> +static int qcom_snps_hsphy_enable_regulators(struct hsphy_priv *priv)
> +{
> + int ret;
> +
> + ret = qcom_snps_hsphy_config_regulators(priv, 1);

Re: [PATCH 4.9 00/59] 4.9.139-stable review

[Jon Hunter]

On 21/11/2018 19:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.139 release.
> There are 59 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Nov 23 18:34:55 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.139-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
All tests are passing for Tegra ...

Test results for stable-v4.9:
8 builds:   8 pass, 0 fail
15 boots:   15 pass, 0 fail
14 tests:   14 pass, 0 fail

Linux version:  4.9.139-rc1-g70b1395
Boards tested:  tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

Re: [PATCH] procfs: fix the output format in /proc/PID/wchan

[Yafang Shao]

On Thu, Nov 22, 2018 at 9:38 PM Alexey Dobriyan  wrote:
>
> On Thu, Nov 22, 2018 at 09:29:52PM +0800, Yafang Shao wrote:
> > On Thu, Nov 22, 2018 at 7:40 PM Alexey Dobriyan  wrote:
> > >
> > > On Wed, Nov 21, 2018 at 07:28:44PM -0800, Andrew Morton wrote:
> > > > On Mon, 19 Nov 2018 19:17:52 +0800 Yafang Shao  
> > > > wrote:
> > > >
> > > > > Just add the missing newline.
> > > > >
> > > > > ...
> > > > >
> > > > > --- a/fs/proc/base.c
> > > > > +++ b/fs/proc/base.c
> > > > > @@ -370,11 +370,12 @@ static int proc_pid_wchan(struct seq_file *m, 
> > > > > struct pid_namespace *ns,
> > > > > wchan = get_wchan(task);
> > > > > if (wchan && !lookup_symbol_name(wchan, symname)) {
> > > > > seq_puts(m, symname);
> > > > > +   seq_putc(m, '\n');
> > > > > return 0;
> > > > > }
> > > > >
> > > > >  print0:
> > > > > -   seq_putc(m, '0');
> > > > > +   seq_puts(m, "0\n");
> > > > > return 0;
> > > > >  }
> > > > >  #endif /* CONFIG_KALLSYMS */
> > > >
> > > > What is presently wrong with the wchan output?  The changelog
> > > > should explain such things, please.
> > >
> > > It is just newline to make "cat /proc/*/wchan" output look cool.
> > > But newline can break something.
> >
> > Could you pls. show some examples for what the newline may break ?
>
> char buf[16];
> rv = read(fd, buf, sizeof(buf));
> assert(rv == 1);

That's really a break, so we can't apply this patch.

Hi Andrew,
I found that you have applied this patch to -mm tree, could you pls.
help revert it as it may break something ?

Thanks
Yafang

Re: Sleeping in user_access section

[hpa]

On November 23, 2018 1:27:02 AM PST, Julien Thierry  
wrote:
>Hi,
>
>I made an attempt at implementing the 
>user_access_begin()/user_access_end() macros along with the 
>get/put_user_unsafe() for arm64 by toggling the status of PAN (more or 
>less similar to x86's STAC/CTAC).
>
>With a small mistake in my patch, we realized that directly calling 
>function that could reschedule while in a user_access section could
>lead to:
>
>- scheduling another task keeping the user_access status enabled
>despite 
>the task never calling user_access_begin()
>
>- when re-scheduling the task that was mid user_access section, 
>user_access would be disabled and the task would fault on the next 
>get/put_user_unsafe.
>
>
>This is because __switch_to does not alter the user_access status when 
>switching from next to prev (at least on arm64 we currently don't, and 
>by looking at the x86 code I don't think this is done either).
>
>
> From my understanding, this is not an issue when the task in 
>user_access mode gets scheduled out/in as a result of an interrupt as 
>PAN and EFLAGS.AC get saved/restore on exception entry/exit (at least I
>
>know it is the case for PAN, I am less sure for the x86 side).
>
>
>So, the question is, should __switch_to take care of the user_access 
>status when scheduling new tasks? Or should there be a restriction
>about 
>scheduling out a task with user_access mode enabled and maybe add a 
>warning if we can detect this?
>
>(Or did we miss something and this is not an issue on x86?)
>
>Thanks,

You should never call a sleeping function from a user_access section. It is 
intended for very limited regions.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH 2/6] devfreq: refactor set_target frequency function

[Lukasz Luba]

Hi Chanwoo Choi,

On 11/23/18 12:45 AM, Chanwoo Choi wrote:
> Hi Lukasz,
> 
> On 2018년 11월 22일 19:40, Lukasz Luba wrote:
>> Hi Chanwoo Choi
>>
>> On 11/22/18 3:52 AM, Chanwoo Choi wrote:
>>> On 2018년 11월 22일 03:01, Lukasz Luba wrote:
 The refactoring is needed for the new client in devfreq: suspend.
 To avoid code duplication, move it to the new local function
 devfreq_set_target.

 The patch draws on Tobias Jakobi's work posted ~2 years ago, who tried to
 solve issue with devfreq device's frequency during suspend/resume.
 During the discussion on LKML some corner cases and comments appeared
 related to the design. This patch address them keeping in mind suggestions
 from Chanwoo Choi.
>>>
>>> As I commented on patch1, please remove it.
>> OK
>>>

 Suggested-by: Tobias Jakobi 
 Suggested-by: Chanwoo Choi 
 Signed-off-by: Lukasz Luba 
 ---
drivers/devfreq/devfreq.c | 62 
 ---
1 file changed, 37 insertions(+), 25 deletions(-)

 diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
 index e20e7e4..cf9c643 100644
 --- a/drivers/devfreq/devfreq.c
 +++ b/drivers/devfreq/devfreq.c
 @@ -285,6 +285,42 @@ static int devfreq_notify_transition(struct devfreq 
 *devfreq,
return 0;
}

 +static int devfreq_set_target(struct devfreq *devfreq, unsigned long 
 new_freq,
 +unsigned long *prev_freq, u32 flags)
>>>
>>> Please remove the unused space in front of 'unsigned long *prev_freq'.
>>> Use tab only for indentation.
>> OK
>>>
 +{
 +  struct devfreq_freqs freqs;
 +  unsigned long cur_freq;
 +  int err = 0;
 +
 +  if (devfreq->profile->get_cur_freq)
 +  devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
 +  else
 +  cur_freq = devfreq->previous_freq;
 +
 +  freqs.old = cur_freq;
 +  freqs.new = new_freq;
 +  devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
 +
 +  err = devfreq->profile->target(devfreq->dev.parent, &new_freq, flags);
 +  if (err) {
 +  freqs.new = cur_freq;
 +  devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
 +  return err;
 +  }
 +
 +  freqs.new = new_freq;
 +  devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
 +
 +  if (devfreq_update_status(devfreq, new_freq))
 +  dev_err(&devfreq->dev,
 +  "Couldn't update frequency transition information.\n");
 +
 +  devfreq->previous_freq = new_freq;
 +  *prev_freq = cur_freq;
 +
 +  return err;
 +}
 +
/* Load monitoring helper functions for governors use */

/**
 @@ -296,7 +332,6 @@ static int devfreq_notify_transition(struct devfreq 
 *devfreq,
 */
int update_devfreq(struct devfreq *devfreq)
{
 -  struct devfreq_freqs freqs;
unsigned long freq, cur_freq, min_freq, max_freq;
>>>
>>>
>>> cur_freq is not used after modification. Remove it.
>>>
int err = 0;
u32 flags = 0;
 @@ -333,31 +368,8 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}

 -  if (devfreq->profile->get_cur_freq)
 -  devfreq->profile->get_cur_freq(devfreq->dev.parent, &cur_freq);
 -  else
 -  cur_freq = devfreq->previous_freq;
 -
 -  freqs.old = cur_freq;
 -  freqs.new = freq;
 -  devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
 +  return devfreq_set_target(devfreq, freq, &cur_freq, flags);
>>>
>>> You get the 'cur_freq' from devfreq_set_taget() for 
>>> devfreq_suspend_device() on patch3.
>>> But, update_devfreq() and devfreq_resume_device() don't use the 'cur_freq' 
>>> value
>>> from devfreq_set_target().
>>>
>>> Instead, getting 'cur_freq' for 'devfreq->resume_freq' in the 
>>> devfreq_set_target().
>>> Please remove the 'cur_freq' parameter from devfreq_set_target.
>>
>> I can remove the 3rd parameter from devfreq_set_target(),
>> but it implies that patch 1 and 3 cannot be merged. The function
>> devfreq_set_target will use 'devfreq->resume_freq' so it must be in
>> devfreq struct.
>> So, in v2 version there will be still 6 patches, with the 1st patch
>> defining needed fields in devfreq struct.
>> Do you agree for that?
> 
> So, I replied again as following on my other reply[1] of patch2:
> [1] https://lkml.org/lkml/2018/11/22/507
> 
> But, you have to add following new code on patch3 instead of patch2.
> patch2 doesn't contain the following codes and then
> patch3 adds 'resume_freq' variable and adds the following code on patch3.
> 
> +
> +   if (devfreq->suspend_freq)
> +   devfreq->resume_freq = cur_freq;
> 
OK, I will add th

Re: [PATCH 4.14 00/21] 4.14.83-stable review

[Jon Hunter]

On 21/11/2018 19:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.83 release.
> There are 21 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Nov 23 18:34:13 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.83-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
All tests are passing for Tegra ...

Test results for stable-v4.14:
8 builds:   8 pass, 0 fail
16 boots:   16 pass, 0 fail
14 tests:   14 pass, 0 fail

Linux version:  4.14.83-rc1-gaa2838d
Boards tested:  tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

-- 
nvpublic

[RFC PATCH] net: macb: Apply RXUBR workaround only to versions with errata

[Harini Katakam]

The interrupt handler contains a workaround for RX hang applicable
to Zynq and AT91 only. Subsequent versions do not need this
workaround. This workaround unecessarily reset RX whenever RX used
bit read is observed, which can be often under heavy traffic.Hence
introduce an errata field and a check to enable this workaround.

Signed-off-by: Harini Katakam 
---
Note: Enabled the errata in zynq and at91 configs only.
Please advise if any other versions are affected by this errata.

 drivers/net/ethernet/cadence/macb.h  | 6 ++
 drivers/net/ethernet/cadence/macb_main.c | 9 +++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 3d45f4c..f6903d6 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -648,6 +648,9 @@
 #define MACB_CAPS_SG_DISABLED  0x4000
 #define MACB_CAPS_MACB_IS_GEM  0x8000
 
+/* Errata mask bits */
+#define MACB_ERRATA_RXLOCKUP   0x0001
+
 /* LSO settings */
 #define MACB_LSO_UFO_ENABLE0x01
 #define MACB_LSO_TSO_ENABLE0x02
@@ -1085,6 +1088,7 @@ struct macb_config {
struct clk **rx_clk);
int (*init)(struct platform_device *pdev);
int jumbo_max_len;
+   u32 errata;
 };
 
 struct tsu_incr {
@@ -1214,6 +1218,8 @@ struct macb {
 
int rx_bd_rd_prefetch;
int tx_bd_rd_prefetch;
+
+   u32 errata;
 };
 
 #ifdef CONFIG_MACB_USE_HWSTAMP
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 1d86b4d..f0bb8a4 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1379,7 +1379,8 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
 * the at91 manual, section 41.3.1 or the Zynq manual
 * section 16.7.4 for details.
 */
-   if (status & MACB_BIT(RXUBR)) {
+   if ((bp->errata & MACB_ERRATA_RXLOCKUP) &&
+   (status & MACB_BIT(RXUBR))) {
ctrl = macb_readl(bp, NCR);
macb_writel(bp, NCR, ctrl & ~MACB_BIT(RE));
wmb();
@@ -3835,6 +3836,7 @@ static const struct macb_config at91sam9260_config = {
.caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
.clk_init = macb_clk_init,
.init = macb_init,
+   .errata = MACB_ERRATA_RXLOCKUP,
 };
 
 static const struct macb_config sama5d3macb_config = {
@@ -3900,6 +3902,7 @@ static const struct macb_config zynq_config = {
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
+   .errata = MACB_ERRATA_RXLOCKUP,
 };
 
 static const struct of_device_id macb_dt_ids[] = {
@@ -4005,8 +4008,10 @@ static int macb_probe(struct platform_device *pdev)
bp->hclk = hclk;
bp->tx_clk = tx_clk;
bp->rx_clk = rx_clk;
-   if (macb_config)
+   if (macb_config) {
bp->jumbo_max_len = macb_config->jumbo_max_len;
+   bp->errata = macb_config->errata;
+   }
 
bp->wol = 0;
if (of_get_property(np, "magic-packet", NULL))
-- 
2.7.4

[PATCH] perf symbols: Cannot disassemble some routines when debuginfo present

[Eric Saint-Etienne]

When the kernel is compiled with -ffunction-sections and perf uses the
kernel debuginfo, perf fails the very first symbol lookup and ends up with
an hex offset inside [kernel.vmlinux]. It's due to how perf loads the maps.

Indeed only .text gets loaded by map_groups__find() into al->map.
Consequently al->map address range encompass the whole code.
But map__load() has just loaded many function maps by splitting al->map,
which reduced al->map range drastically. Very likely the target address is
now in one of those newly created function maps, so we need to lookup the
map again to find that new map.

This issue is not specific to the kernel but to how the image is linked.
For the kernel, when we're not using the kernel debuginfo, perf will
fallback to using kallsyms and then the first lookup will work.

This patch makes sure that the event address we're looking-up is indeed
within the map we've found, otherwise we lookup another map again.
Only one extra lookup at most is required for the proper map to be found,
if it exists.

Signed-off-by: Eric Saint-Etienne 
Reviewed-by: Darren Kenny 
---
 tools/perf/util/event.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index e9c108a..a69ef52 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1571,7 +1571,28 @@ struct map *thread__find_map(struct thread *thread, u8 
cpumode, u64 addr,
 */
if (load_map)
map__load(al->map);
-   al->addr = al->map->map_ip(al->map, al->addr);
+
+   /*
+* When using -ffunction-sections, only .text gets loaded by
+* map_groups__find() into al->map. Consequently al->map address
+* range encompass the whole code.
+*
+* But map__load() has just loaded many function maps by
+* splitting al->map, which reduced al->map range drastically.
+* Very likely the target address is now in one of those newly
+* created function maps, so we need to lookup the map again
+* to find that new map.
+*/
+   if (al->addr < al->map->start || al->addr >= al->map->end)
+   al->map = map_groups__find(mg, al->addr);
+
+   /*
+* The new map *ought* to exist because the initial al->map
+* contained that address and subsequently has been split into
+* many *contiguous* maps.
+*/
+   if (al->map != NULL)
+   al->addr = al->map->map_ip(al->map, al->addr);
}
 
return al->map;
-- 
1.8.3.1

Re: [PATCH 3/6] devfreq: add support for suspend/resume of a devfreq device

[Lukasz Luba]

Hi Chanwoo Choi,

On 11/23/18 12:54 AM, Chanwoo Choi wrote:
> Hi Lukasz,
> 
> I add one more comment about devfreq_resume_device().
> 
> On 2018년 11월 22일 20:00, Lukasz Luba wrote:
>>
>>
>> On 11/22/18 3:58 AM, Chanwoo Choi wrote:
>>> On 2018년 11월 22일 03:01, Lukasz Luba wrote:
 The patch adds support for handling suspend/resume process.
 It uses atomic variables to make sure no race condition
 affects the process.

 The patch draws on Tobias Jakobi's work posted ~2 years ago, who tried to
 solve issue with devfreq device's frequency during suspend/resume.
 During the discussion on LKML some corner cases and comments appeared
 related to the design. This patch address them keeping in mind suggestions
 from Chanwoo Choi.
>>>
>>> Please remove the duplicate information about patch history.
>>>

 Suggested-by: Tobias Jakobi 
 Suggested-by: Chanwoo Choi 
 Signed-off-by: Lukasz Luba 
 ---
drivers/devfreq/devfreq.c | 45 
 +++--
1 file changed, 39 insertions(+), 6 deletions(-)

 diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
 index cf9c643..7e09de8 100644
 --- a/drivers/devfreq/devfreq.c
 +++ b/drivers/devfreq/devfreq.c
 @@ -872,14 +872,33 @@ EXPORT_SYMBOL(devm_devfreq_remove_device);
 */
int devfreq_suspend_device(struct devfreq *devfreq)
{
 -  if (!devfreq)
 -  return -EINVAL;
 +int ret;
>>>
>>> Move 'ret' definition under 'if (devfreq->suspend_freq) {'
>>> because 'ret' is used if suspend_freq isn't zero.
>> Not only there, 6 lines above 'ret' is used for
>> devfreq->governor->event_handler().
> 
> OK.
> 
>>>
 +unsigned long prev_freq;
 +u32 flags = 0;
 +
 +if (!devfreq)
 +return -EINVAL;
 +
 +if (devfreq->governor) {
 +  ret = devfreq->governor->event_handler(devfreq,
 +  DEVFREQ_GOV_SUSPEND, NULL);
 +  if (ret)
 +  return ret;
 +  }

 -  if (!devfreq->governor)
 -  return 0;
 +  if (devfreq->suspend_freq) {
 +  if (atomic_inc_return(&devfreq->suspend_count) > 1)
 +  return 0;

 -  return devfreq->governor->event_handler(devfreq,
 -  DEVFREQ_GOV_SUSPEND, NULL);
 +  ret = devfreq_set_target(devfreq, devfreq->suspend_freq,
 +   &prev_freq, flags);
>>>
>>> Remove the 'prev_freq' parameter.
>> OK
>>>
 +  if (ret)
 +  return ret;
 +
 +  devfreq->resume_freq = prev_freq;
>>>
>>> As I commented on patch2, if devfreq_set_taget save the current frequency
>>> to 'devfreq->resume_freq', this line is not needed.
>> OK
>>>
>>>
 +  }
 +
 +return 0;
}
EXPORT_SYMBOL(devfreq_suspend_device);

 @@ -893,9 +912,23 @@ EXPORT_SYMBOL(devfreq_suspend_device);
 */
int devfreq_resume_device(struct devfreq *devfreq)
{
 +int ret;
>>>
>>> Move 'ret' definition under 'if (devfreq->suspend_freq) {'
>>> because 'ret' is used if suspend_freq isn't zero.
>> OK
> 
> If you change the devfreq_resume_device() according to my new comment,
> please ignore it.
> 
>>>
 +unsigned long prev_freq;
>>>
>>> Remove prev_freq variable which is not used on this function.
>>> After calling devfreq_set_target, prev_freq is not used.
>> OK
>>>
 +u32 flags = 0;
 +
if (!devfreq)
return -EINVAL;

 +  if (devfreq->suspend_freq) {
 +  if (atomic_dec_return(&devfreq->suspend_count) >= 1)
 +  return 0;
 +
 +  ret = devfreq_set_target(devfreq, devfreq->resume_freq,
 +   &prev_freq, flags);
>>>
>>> Remove the 'prev_freq' parameter.
>> OK
>>>
 +  if (ret)
 +  return ret;
 +  }
 +
if (!devfreq->governor)
return 0;
> 
> Please change the code as following because you uses the following type
> in the devfreq_suspend_device(). If there is any special issue, please
> keep the same format in order to improve the readability.
> 
>   if (devfreq->governor) {
>   ret = devfreq->governor->event_handler(devfreq,
>   DEVFREQ_GOV_RESUME, NULL);
>   if (ret)
>   return ret;
>   }
> 
> 
OK, I will change the code to keep the same format.
Thank you for the review.

Regards,
Lukasz

RE: [PATCH] pinctrl: rzn1: Fix check for used MDIO bus

[Phil Edworthy]

Hi Geert,

On 23 November 2018 09:41 Geert Uytterhoeven wrote:
> Subject: Re: [PATCH] pinctrl: rzn1: Fix check for used MDIO bus
> On Mon, Nov 19, 2018 at 5:18 PM Phil Edworthy wrote:
> > This fixes the check for unused mdio bus setting and the following
> > static checker warning:
> >  drivers/pinctrl/pinctrl-rzn1.c:198 rzn1_pinctrl_mdio_select()
> >  warn: always true condition '(ipctl->mdio_func[mdio] >= 0) => (0-u32max
> >= 0)'
> >
> > It also fixes the return var when calling of_get_child_count()
> 
> I think this should be a separate patch.
Ok, I'll split them.


> > Reported-by: Dan Carpenter 
> > Signed-off-by: Phil Edworthy 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> BTW, I have a question about rzn1_pinctrl_mdio_select():
> 
> static void rzn1_pinctrl_mdio_select(struct rzn1_pinctrl *ipctl, int mdio,
>  u32 func) {
> if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] != func)
> dev_warn(ipctl->dev, "conflicting setting for mdio%d!\n", 
> mdio);
> ipctl->mdio_func[mdio] = func;
> 
> dev_dbg(ipctl->dev, "setting mdio%d to %u\n", mdio, func);
> 
> writel(func, &ipctl->lev2->l2_mdio[mdio]); }
> 
> The check warns the user if it overrides an already initialized MDIO function
> with a different value.
> However, there is no method to uninitialize (reset to -1) mdio_func[], to
> avoid getting the warning.
> 
> For a use case, I was thinking about a DT overlay that would cause the MDIO
> function to be initialized on loading, and needs to uninitialize the MDIO
> function on removing.
> 
> Perhaps that is very unlikely or even impossible, given the function of the
> pins controlled by the MDIO function?
I hadn't considered that DT overlay possibility...
Since this MDIO muxing selects one of several different IP blocks as the
MDIO master, I guess it could happen. However, this is pretty unlikely!

I can't see any way via the pinctrl_ops or pinconf_ops to 'undo' a pin
setting, how would this work?
If a DT overlay causes remove() then probe() to be called again, the driver
resets mdio_func[] in probe(), so it'll work.

Thanks!
Phil

Re: [PATCH V2 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

[Viresh Kumar]

On 22-11-18, 13:36, Daniel Lezcano wrote:
> In the case of asymmetric SoC with the same micro-architecture, we
> have a group of CPUs with smaller OPPs than the other group. One
> example is the 96boards dragonboard 820c. There is no dmips/MHz
> difference between both groups, so no need to specify the values in
> the DT. Unfortunately, without these defined, there is no scaling
> capacity computation triggered, so we need to write
> 'capacity-dmips-mhz' for each CPU with the same value in order to
> force the scaled capacity computation.
> 
> Fix this by setting a default capacity to SCHED_CAPACITY_SCALE, if no
> 'capacity-dmips-mhz' is defined in the DT.

We aren't doing this anymore. You should rather explain that we just
allocate raw_capacity now and rest is left for
init_cpu_capacity_callback() to fix.

-- 
viresh

[GIT PULL] Power management fixes for v4.20-rc4

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.20-rc4

with top-most commit 1d50088ca3956e5dcd2751a658e7869b9af10bb4

 Merge branches 'pm-cpufreq' and 'pm-sleep'

on top of commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6

 Linux 4.20-rc3

to receive power management fixes for 4.20-rc4.

These fix two issues in the Operating Performance Points (OPP)
framework, one cpufreq driver issue, one problem related to the
tasks freezer and a few build-related issues in the cpupower
utility.

Specifics:

 - Fix tasks freezer deadlock in de_thread() that occurs if one
   of its sub-threads has been frozen already (Chanho Min).

 - Avoid registering a platform device by the ti-cpufreq driver
   on platforms that cannot use it (Dave Gerlach).

 - Fix a mistake in the ti-opp-supply operating performance points
   (OPP) driver that caused an incorrect reference voltage to be
   used and make it adjust the minimum voltage dynamically to avoid
   hangs or crashes in some cases (Keerthy).

 - Fix issues related to compiler flags in the cpupower utility
   and correct a linking problem in it by renaming a file with
   a duplicate name (Jiri Olsa, Konstantin Khlebnikov).

Thanks!


---

Chanho Min (1):
  exec: make de_thread() freezable

Dave Gerlach (1):
  cpufreq: ti-cpufreq: Only register platform_device when supported

Jiri Olsa (2):
  tools cpupower debug: Allow to use outside build flags
  tools cpupower: Override CFLAGS assignments

Keerthy (2):
  opp: ti-opp-supply: Dynamically update u_volt_min
  opp: ti-opp-supply: Correct the supply in _get_optimal_vdd_voltage call

Konstantin Khlebnikov (1):
  tools/power/cpupower: fix compilation with STATIC=true

---

 drivers/cpufreq/ti-cpufreq.c   | 26 +-
 drivers/opp/ti-opp-supply.c|  5 -
 fs/exec.c  |  5 +++--
 tools/power/cpupower/Makefile  | 12 ++--
 tools/power/cpupower/bench/Makefile|  2 +-
 tools/power/cpupower/debug/x86_64/Makefile |  4 ++--
 tools/power/cpupower/lib/cpufreq.c |  2 +-
 tools/power/cpupower/lib/cpuidle.c |  2 +-
 tools/power/cpupower/lib/cpupower.c|  4 ++--
 tools/power/cpupower/lib/cpupower_intern.h |  2 +-
 10 files changed, 42 insertions(+), 22 deletions(-)

[GIT PULL] ACPI fix for v4.20-rc4

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.20-rc4

with top-most commit 2bbb5fa37475d7aa5fa62f34db1623f3da2dfdfa

 ACPI / platform: Add SMB0001 HID to forbidden_id_list

on top of commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6

 Linux 4.20-rc3

to receive an ACPI fix for 4.20-rc4.

This prevents the ACPI core from registering a platform device for
the SMB0001 HID to avoid IRQ allocation issues (Hans de Goede).

Thanks!


---

Hans de Goede (1):
  ACPI / platform: Add SMB0001 HID to forbidden_id_list

---

 drivers/acpi/acpi_platform.c | 1 +
 1 file changed, 1 insertion(+)

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

[David Laight]

From: David Laight
> Sent: 23 November 2018 09:35
> From: Linus Torvalds
> > Sent: 22 November 2018 18:58
> ...
> > Oh, and I just noticed that on x86 we expressly use our old "safe and
> > sane" functions: see __inline_memcpy(), and its use in
> > __memcpy_{from,to}io().
> >
> > So the "falls back to memcpy" was always a red herring. We don't
> > actually do that.
> >
> > Which explains why things work.
> 
> It doesn't explain why I've seen single byte PCIe TLP generated
> by memcpy_to/fromio().
> 
> I've had to change code to use readq/writeq loops because the
> byte accesses are so slow - even when PIO performance should
> be 'good enough'.
> 
> It might have been changed since last time I tested it.
> But I don't remember seeing a commit go by.

I've just patched my driver and redone the test on a 4.13 (ubuntu) kernel.
Calling memcpy_fromio(kernel_buffer, PCIe_address, length)
generates a lot of single byte TLP.

What the code normally does is 64bit aligned PCIe reads with
multiple writes and shifts to avoid writing beyond the end of
the kernel buffer for 'odd' length transfers.

Most of our PIO copies are actually direct to/from userspace.
While copy_to/from_user() will work on PCIe memory, it is 'rep mosvb'.
We also mmap() the PCIe space into process memory - and have be
careful not to use memcpy() in usespace.

On suitable systems userspace can use the AVX256 instructions to
get wide reads. Much harder and more expensive in the kernel.

In practise most of the bulk data transfers are requested by the PCIe slave.
But there are times when PIO ones are needed, and 64 bit transfers are
8 times faster than 8 bit ones.
This is all made more significant because it takes our fpga about 500ns
to complete a single word PCIe read.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH 1/3] dt-bindings: define vendor prefix for whwave, Inc.

[zoro]

Introduce vendor prefix for whwave, Inc.
for SD3078 rtc device.

Signed-off-by: zoro 
---
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4b1a2a8..7d2e9b01 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -423,6 +423,7 @@ vot Vision Optical Technology Co., Ltd.
 wd Western Digital Corp.
 wetek  WeTek Electronics, limited.
 wexler Wexler
+whwave Shenzhen whwave Electronics crop
 wi2wi  Wi2Wi, Inc.
 winbond Winbond Electronics corp.
 winstarWinstar Display Corp.
-- 
1.7.9.5

[PATCH 2/3] rtc: sd3078: new driver.

[zoro]

The sd3078 is a combination RTC and SRAM device with I2C interface.

Signed-off-by: zoro 
---
 MAINTAINERS  |6 ++
 drivers/rtc/Kconfig  |9 ++
 drivers/rtc/Makefile |1 +
 drivers/rtc/rtc-sd3078.c |  232 ++
 4 files changed, 248 insertions(+)
 create mode 100644 drivers/rtc/rtc-sd3078.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 2f3eba4..002fcd7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16125,6 +16125,12 @@ L: linux-g...@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-wcove.c
 
+WHWAVE RTC DRIVER
+M: Zoro Li 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/rtc/rtc-sd3078.c
+
 WIIMOTE HID DRIVER
 M: David Herrmann 
 L: linux-in...@vger.kernel.org
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a819ef0..5b4b1b4 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -646,6 +646,15 @@ config RTC_DRV_S5M
  This driver can also be built as a module. If so, the module
  will be called rtc-s5m.
 
+config RTC_DRV_SD3078
+tristate "ZXW Crystal SD3078"
+help
+  If you say yes here you get support for the ZXW Crystal
+  SD3078 RTC chips.
+
+  This driver can also be built as a module. If so, the module
+  will be called rtc-sd3078.
+
 endif # I2C
 
 comment "SPI RTC drivers"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 290c173..f973bd0 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -148,6 +148,7 @@ obj-$(CONFIG_RTC_DRV_S3C)   += rtc-s3c.o
 obj-$(CONFIG_RTC_DRV_S5M)  += rtc-s5m.o
 obj-$(CONFIG_RTC_DRV_SA1100)   += rtc-sa1100.o
 obj-$(CONFIG_RTC_DRV_SC27XX)   += rtc-sc27xx.o
+obj-$(CONFIG_RTC_DRV_SD3078)   += rtc-sd3078.o
 obj-$(CONFIG_RTC_DRV_SH)   += rtc-sh.o
 obj-$(CONFIG_RTC_DRV_SIRFSOC)  += rtc-sirfsoc.o
 obj-$(CONFIG_RTC_DRV_SNVS) += rtc-snvs.o
diff --git a/drivers/rtc/rtc-sd3078.c b/drivers/rtc/rtc-sd3078.c
new file mode 100644
index 000..9428a33
--- /dev/null
+++ b/drivers/rtc/rtc-sd3078.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Real Time Clock (RTC) Driver for sd3078
+ * Copyright (C) 2018 Zoro Li
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SD3078_REG_SC  0x00
+#define SD3078_REG_MN  0x01
+#define SD3078_REG_HR  0x02
+#define SD3078_REG_DW  0x03
+#define SD3078_REG_DM  0x04
+#define SD3078_REG_MO  0x05
+#define SD3078_REG_YR  0x06
+
+#define SD3078_REG_CTRL1   0x0f
+#define SD3078_REG_CTRL2   0x10
+#define SD3078_REG_CTRL3   0x11
+
+#define KEY_WRITE1 0x80
+#define KEY_WRITE2 0x04
+#define KEY_WRITE3 0x80
+
+#define NUM_TIME_REGS   (SD3078_REG_YR - SD3078_REG_SC + 1)
+
+/*
+ * The sd3078 has write protection
+ * and we can choose whether or not to use it.
+ * Write protection is turned off by default.
+ */
+#define WRITE_PROTECT_EN   0
+
+struct sd3078 {
+   struct rtc_device   *rtc;
+   struct regmap   *regmap;
+};
+
+/*
+ * In order to prevent arbitrary modification of the time register,
+ * when modification of the register,
+ * the "write" bit needs to be written in a certain order.
+ * 1. set WRITE1 bit
+ * 2. set WRITE2 bit
+ * 3. set WRITE3 bit
+ */
+static void sd3078_enable_reg_write(struct sd3078 *sd3078)
+{
+   regmap_update_bits(sd3078->regmap, SD3078_REG_CTRL2,
+  KEY_WRITE1, KEY_WRITE1);
+   regmap_update_bits(sd3078->regmap, SD3078_REG_CTRL1,
+  KEY_WRITE2, KEY_WRITE2);
+   regmap_update_bits(sd3078->regmap, SD3078_REG_CTRL1,
+  KEY_WRITE3, KEY_WRITE3);
+}
+
+#if WRITE_PROTECT_EN
+/*
+ * In order to prevent arbitrary modification of the time register,
+ * we should disable the write function.
+ * when disable write,
+ * the "write" bit needs to be clear in a certain order.
+ * 1. clear WRITE2 bit
+ * 2. clear WRITE3 bit
+ * 3. clear WRITE1 bit
+ */
+static void sd3078_disable_reg_write(struct sd3078 *sd3078)
+{
+   regmap_update_bits(sd3078->regmap, SD3078_REG_CTRL1,
+  KEY_WRITE2, 0);
+   regmap_update_bits(sd3078->regmap, SD3078_REG_CTRL1,
+  KEY_WRITE3, 0);
+   regmap_update_bits(sd3078->regmap, SD3078_REG_CTRL2,
+  KEY_WRITE1, 0);
+}
+#endif
+
+static int sd3078_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+   unsigned char hour;
+   unsigned char rtc_data[NUM_TIME_REGS] = {0};
+   struct i2c_client *client = to_i2c_client(dev);
+   struct sd3078 *sd3078 = i2c_get_clientdata(client);
+   int ret;
+
+   ret = regmap_bulk_read(sd3078->regmap, SD3078_REG_SC, rtc_data,
+  NUM_TIME_REGS);
+   if (ret < 0) {
+   dev_err(dev, "reading from RTC failed 

[PATCH 3/3] dt-bindings: rtc: sd3078: add device tree documentation

[zoro]

The devicetree documentation for the SD3078 device tree
binding is added with a short example.

Signed-off-by: zoro 
---
 .../devicetree/bindings/rtc/rtc-sd3078.txt |   13 +
 1 file changed, 13 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-sd3078.txt

diff --git a/Documentation/devicetree/bindings/rtc/rtc-sd3078.txt 
b/Documentation/devicetree/bindings/rtc/rtc-sd3078.txt
new file mode 100644
index 000..676cee8
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-sd3078.txt
@@ -0,0 +1,13 @@
+SD3078 Real Time Clock
+
+
+Required properties:
+- compatible: Should contain "whwave,sd3078".
+- reg: I2C address for chip.
+
+Example:
+
+sd3078: sd3078@32 {
+   compatible = "whwave,sd3078";
+   reg = <0x32>;
+};
-- 
1.7.9.5

Re: Sleeping in user_access section

[Julien Thierry]

On 23/11/18 09:57, h...@zytor.com wrote:

On November 23, 2018 1:27:02 AM PST, Julien Thierry  
wrote:

Hi,

I made an attempt at implementing the
user_access_begin()/user_access_end() macros along with the
get/put_user_unsafe() for arm64 by toggling the status of PAN (more or
less similar to x86's STAC/CTAC).

With a small mistake in my patch, we realized that directly calling
function that could reschedule while in a user_access section could
lead to:

- scheduling another task keeping the user_access status enabled
despite
the task never calling user_access_begin()

- when re-scheduling the task that was mid user_access section,
user_access would be disabled and the task would fault on the next
get/put_user_unsafe.


This is because __switch_to does not alter the user_access status when
switching from next to prev (at least on arm64 we currently don't, and
by looking at the x86 code I don't think this is done either).


 From my understanding, this is not an issue when the task in
user_access mode gets scheduled out/in as a result of an interrupt as
PAN and EFLAGS.AC get saved/restore on exception entry/exit (at least I

know it is the case for PAN, I am less sure for the x86 side).


So, the question is, should __switch_to take care of the user_access
status when scheduling new tasks? Or should there be a restriction
about
scheduling out a task with user_access mode enabled and maybe add a
warning if we can detect this?

(Or did we miss something and this is not an issue on x86?)

Thanks,


You should never call a sleeping function from a user_access section. It is 
intended for very limited regions.



Thanks for the clarification.

Would it be worth documenting this somewhere? And add a check to detect 
such issues?


Also, those limited regions can be interrupted and preempted, but I 
guess you could consider the interrupted region being split into 
separate user_access regions, before and after the interrupt. Should it 
be stated that an exception/interrupt constitutes implicit 
user_access_end()/begin() when taken from/returning to a user_access region?


Thanks,

--
Julien Thierry

[PATCH] perf map: remove extra indirection from map__find()

[Eric Saint-Etienne]

A double pointer is used in map__find() where a single pointer is enough
because the function doesn't affect the rbtree and the rbtree is locked.

Signed-off-by: Eric Saint-Etienne 
---
 tools/perf/util/map.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 354e545..3dac766 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -846,19 +846,18 @@ void maps__remove(struct maps *maps, struct map *map)
 
 struct map *maps__find(struct maps *maps, u64 ip)
 {
-   struct rb_node **p, *parent = NULL;
+   struct rb_node *p;
struct map *m;
 
down_read(&maps->lock);
 
-   p = &maps->entries.rb_node;
-   while (*p != NULL) {
-   parent = *p;
-   m = rb_entry(parent, struct map, rb_node);
+   p = maps->entries.rb_node;
+   while (p != NULL) {
+   m = rb_entry(p, struct map, rb_node);
if (ip < m->start)
-   p = &(*p)->rb_left;
+   p = p->rb_left;
else if (ip >= m->end)
-   p = &(*p)->rb_right;
+   p = p->rb_right;
else
goto out;
}
-- 
1.8.3.1

Re: [PATCH] mtd: spi-nor: fix erase_type array to indicate current map conf

[Boris Brezillon]

On Fri, 23 Nov 2018 09:42:55 +
"Sverdlin, Alexander (Nokia - DE/Ulm)" 
wrote:

> Hello Tudor,
> 
> On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> > From: Tudor Ambarus 
> > 
> > Bug reported for the out-of-tree S25FS128S flash memory.
> > 
> > BFPT table advertises all the erase types supported by all the
> > possible map configurations. Update the erase_type array to indicate
> > which erase types are applicable to the current map configuration.
> > 
> > Backward compatibility test done on sst26vf064b.
> > 
> > Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
> > Reported-by: Alexander Sverdlin 
> > Signed-off-by: Tudor Ambarus   
> 
> I've tested this patch and it fixes the erasesize for S25FS128S and
> our 128k partitions are writeable again with this patch.
> 
> Nevertheless, I think this is coincidence. I don't think that it
> makes sense to OR all the erase types from all regions in one
> bitmask and derive any uniform erasesize out of it.
> This makes little sense for me in case of non-uniform maps.
> 
> I believe, the culprit here is one level higher, in the MTD partitioning
> code (mtdpart.c) which has to be taught about non-uniform maps
> but there is no infrastructure for this currently.

Keep in mind that mtdpart is only one part of the issue. As I said
previously, some MTD users (UBI) expect a single eraseblock size, so
it's not only mtdpart that you'd need to fix, but basically all MTD
users that don't check ->eraseregions.

> 
> What is possible to fix still is to choose smallest, not biggest
> erasesize for uniform case.

Yep, I agree. But we also have to be careful here, if some NORs were
already supported and were picking the biggest erasesize, we have to
preserve this behavior, otherwise we'll break things.

> I have such a patch, but I need hands
> on on a S25FS128S configured in uniform mode.
> 
> Non uniform case requires MTD layer rework.

There's already the concept of ->eraseregions. Maybe I'm wrong but I
thought it would fit the non-uniform erase scheme we have in SPI NOR. 

> We just cannot handle
> this hardware with just one erasesize in mind.

We can, if we decide to always use the biggest non-uniform erasesize.
Of course that only works if the biggest erase size is always a
multiple of smaller ones, but I'm pretty sure this is always true.

> 
> > ---
> >  drivers/mtd/spi-nor/spi-nor.c | 29 -
> >  1 file changed, 28 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index 93c9bc8931fc..a71adcd6ddfa 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -3000,7 +3000,8 @@ static int spi_nor_init_non_uniform_erase_map(struct 
> > spi_nor *nor,
> > u64 offset;
> > u32 region_count;
> > int i, j;
> > -   u8 erase_type, uniform_erase_type;
> > +   u8 uniform_erase_type, save_uniform_erase_type;
> > +   u8 erase_type, regions_erase_type;
> >  
> > region_count = SMPT_MAP_REGION_COUNT(*smpt);
> > /*
> > @@ -3014,6 +3015,7 @@ static int spi_nor_init_non_uniform_erase_map(struct 
> > spi_nor *nor,
> > map->regions = region;
> >  
> > uniform_erase_type = 0xff;
> > +   regions_erase_type = 0;
> > offset = 0;
> > /* Populate regions. */
> > for (i = 0; i < region_count; i++) {
> > @@ -3030,13 +3032,38 @@ static int 
> > spi_nor_init_non_uniform_erase_map(struct spi_nor *nor,
> >  */
> > uniform_erase_type &= erase_type;
> >  
> > +   /*
> > +* regions_erase_type mask will indicate all the erase types
> > +* supported in this configuration map.
> > +*/
> > +   regions_erase_type |= erase_type;
> > +
> > offset = (region[i].offset & ~SNOR_ERASE_FLAGS_MASK) +
> >  region[i].size;
> > }
> >  
> > +   save_uniform_erase_type = map->uniform_erase_type;
> > map->uniform_erase_type = spi_nor_sort_erase_mask(map,
> >   uniform_erase_type);
> >  
> > +   if (!regions_erase_type) {
> > +   /*
> > +* Roll back to the previous uniform_erase_type mask, SMPT is
> > +* broken.
> > +*/
> > +   map->uniform_erase_type = save_uniform_erase_type;
> > +   return -EINVAL;
> > +   }
> > +
> > +   /*
> > +* BFPT table advertises all the erase types supported by all the
> > +* possible map configurations. Update the erase_type array to indicate
> > +* which erase types are applicable to the current map configuration.
> > +*/
> > +   for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++)
> > +   if (!(regions_erase_type & BIT(erase[i].idx)))
> > +   spi_nor_set_erase_type(&erase[i], 0, 0xFF);
> > +
> > spi_nor_region_mark_end(®ion[i - 1]);
> >  
> > return 0;  
> 

Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions

[Tero Kristo]

On 20/11/2018 12:44, Vignesh R wrote:

On 20/11/18 4:07 PM, Tero Kristo wrote:

On 20/11/2018 12:09, Vignesh R wrote:

On 19/11/18 12:49 PM, Tero Kristo wrote:

On 17/11/2018 18:05, Nishanth Menon wrote:

On 11:31-20181113, Vignesh R wrote:

The dt-bindings header for TI K3 AM6 SoCs define a set of macros for



[...]


Thanks for reducing the combinations down to the minimum needed. We can
worry about the DS and isolation bits when we have a real user for
them.

Acked-by: Nishanth Menon 

Tero: v4.21-rc1 perhaps ?



Yeah, looks fine, queueing up for 4.21.



Thank you all for the review!

Tero,

Is there a branch with these patches that I can use as base for my next
set of DT patches?


Don't have a branch for these atm, but I can create one if you need it.


Yes, that would be great. Thanks!



Pushed 4.20-rc1-am65x-queue into my public tree.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

kernelci.org automated boot bisection reports

[Guillaume Tucker]

tl;dr automatic bisection reports are enabled for mainline and stable

In case you're not already familiar with it, the kernelci.org project
is a community effort to build and test upstream kernel trees on a
variety of hardware platforms.  Reports are mostly sent to the
kernel-build-reports mailing list[1] and all the results can be seen
on https://kernelci.org.

When a boot test regression is detected on mainline or stable
branches, a bisection is automatically run.  Starting from today, an
email report will be automatically sent to a list of recipients based
on the commit the bisection has found (author, trailers, maintainers
and lists associated with the code changed by the commit).  Until
now, the results were manually curated and only reported more widely
when they seemed valid.  Some automated checks are now used, they
have been showing good results for a while with no false positives.

There shouldn't be many bisection reports yet, typically one or two
every month.  As we'll start bisecting other trees such as linux-next
and other test results than just plain boots, the volume may start
increasing gradually over the coming months.

Please let us know if you would like the report format to be changed
when you get one, or if you have any suggestions at all.

Hope this helps!

Guillaume

[1] https://lists.linaro.org/mailman/listinfo/kernel-build-reports

Re: [PATCH v2] pwm: kconfig: enable kona pwm to be built for cygnus arch

[Uwe Kleine-König]

Hello Clément,

On Fri, Nov 23, 2018 at 10:31:18AM +0100, Clément Péron wrote:
> On Thu, 22 Nov 2018 at 21:05, Uwe Kleine-König
>  wrote:
> > Related to this driver I have a set of questions: If the disable
> > callback completed, does the hardware still drive the pin? If yes, would
> > it be possible to disable the pin driver such that the pin gets high-Z?
> > If yes, how?
> 
> The output pin type is configured with the bit "21:16 PWMOUT_TYPE RW
> default 0x3F" in the Control register
> PWM_CONTROL_TYPE_SHIFT macro in the driver
> Datasheets says : "When set to 1 the PWM Output signal will have a
> push/pull type.When set to 0 the PWM Output signal will have an open
> drain output type.Recommend to leave it push/pull type."
> 
> In the driver we actually set push/pull mode for all channels :
> /* Set push/pull for all channels */
> for (chan = 0; chan < kp->chip.npwm; chan++)
> value |= (1 << PWM_CONTROL_TYPE_SHIFT(chan));

So if disabling the output driver was part of the requirements for
.disable the bcm-kona driver could not implement this for both inverted
and uninverted PWMs. (At least not without resorting to pinmuxing.)

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH] mtd: spi-nor: fix erase_type array to indicate current map conf

[Boris Brezillon]

On Fri, 23 Nov 2018 11:17:29 +0100
Boris Brezillon  wrote:

> On Fri, 23 Nov 2018 09:42:55 +
> "Sverdlin, Alexander (Nokia - DE/Ulm)" 
> wrote:
> 
> > Hello Tudor,
> > 
> > On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> > > From: Tudor Ambarus 
> > > 
> > > Bug reported for the out-of-tree S25FS128S flash memory.
> > > 
> > > BFPT table advertises all the erase types supported by all the
> > > possible map configurations. Update the erase_type array to indicate
> > > which erase types are applicable to the current map configuration.
> > > 
> > > Backward compatibility test done on sst26vf064b.
> > > 
> > > Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter 
> > > Table")
> > > Reported-by: Alexander Sverdlin 
> > > Signed-off-by: Tudor Ambarus   
> > 
> > I've tested this patch and it fixes the erasesize for S25FS128S and
> > our 128k partitions are writeable again with this patch.
> > 
> > Nevertheless, I think this is coincidence. I don't think that it
> > makes sense to OR all the erase types from all regions in one
> > bitmask and derive any uniform erasesize out of it.
> > This makes little sense for me in case of non-uniform maps.
> > 
> > I believe, the culprit here is one level higher, in the MTD partitioning
> > code (mtdpart.c) which has to be taught about non-uniform maps
> > but there is no infrastructure for this currently.
> 
> Keep in mind that mtdpart is only one part of the issue. As I said
> previously, some MTD users (UBI) expect a single eraseblock size, so
> it's not only mtdpart that you'd need to fix, but basically all MTD
> users that don't check ->eraseregions.

Just checked, and it seems mtdpart already supports eraseregions [1].
It picks the biggest erasesize of the regions covered by the partition,
which is exactly what we want. So all we'd have to do is make spi-nor.c
define those regions.

[1]https://elixir.bootlin.com/linux/v4.20-rc3/source/drivers/mtd/mtdpart.c#L482

[GIT PULL] PHY: for 4.20 -rc

[Kishon Vijay Abraham I]

Hi Greg,

Please find the pull request for 4.20 -rc below.

It includes tuning parameter fix in qcom-qusb2 PHY driver, dt-bindings fix
for phy-qcom-qmp and a fix for randconfig error in uniphier-pcie.

Consider merging this in the -rc cycle.

Thanks
Kishon

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.20-rc

for you to fetch changes up to c88520db18ba0b9a41326c3b8680e7c09eb4c381:

  phy: qcom-qusb2: Fix HSTX_TRIM tuning with fused value for SDM845 (2018-11-21 
13:13:58 +0530)


phy: for 4.20-rc

 *) Fix updating HSTX_TRIM tuning parameter in qcom-qusb2 PHY driver
 *) Fix inconsistencies between dt-bindings and the driver
 *) Add "Depend on HAS_IOMEM" uniphier-pcie to avoid randconfig errors

Signed-off-by: Kishon Vijay Abraham I 


Douglas Anderson (1):
  dt-bindings: phy-qcom-qmp: Fix several mistakes from prior commits

Kunihiko Hayashi (1):
  phy: uniphier-pcie: Depend on HAS_IOMEM

Manu Gautam (2):
  phy: qcom-qusb2: Use HSTX_TRIM fused value as is
  phy: qcom-qusb2: Fix HSTX_TRIM tuning with fused value for SDM845

 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 31 
+++
 drivers/phy/qualcomm/phy-qcom-qusb2.c  | 20 
+++-
 drivers/phy/socionext/Kconfig  |  3 ++-
 3 files changed, 36 insertions(+), 18 deletions(-)
-- 
2.17.1

RE: [patch 8/9] posix-clocks: Remove license boiler plate

[Thomas Gleixner]

On Fri, 23 Nov 2018, Manfred Rudigier wrote:

> Acked-by: Manfred Rudigier 

Thanks Manfred! Very appreciated!

   Thomas

Re: [PATCH V2 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT

[Daniel Lezcano]

On 23/11/2018 11:04, Viresh Kumar wrote:
> On 22-11-18, 13:36, Daniel Lezcano wrote:
>> In the case of asymmetric SoC with the same micro-architecture, we
>> have a group of CPUs with smaller OPPs than the other group. One
>> example is the 96boards dragonboard 820c. There is no dmips/MHz
>> difference between both groups, so no need to specify the values in
>> the DT. Unfortunately, without these defined, there is no scaling
>> capacity computation triggered, so we need to write
>> 'capacity-dmips-mhz' for each CPU with the same value in order to
>> force the scaled capacity computation.
>>
>> Fix this by setting a default capacity to SCHED_CAPACITY_SCALE, if no
>> 'capacity-dmips-mhz' is defined in the DT.
> 
> We aren't doing this anymore. You should rather explain that we just
> allocate raw_capacity now and rest is left for
> init_cpu_capacity_callback() to fix.

What about?

"In the case of asymmetric SoC with the same micro-architecture, we
have a group of CPUs with smaller OPPs than the other group. One
example is the 96boards dragonboard 820c. There is no dmips/MHz
difference between both groups, so no need to specify the values in
the DT. Unfortunately, without these defined, there is no scaling
capacity computation triggered, so we need to write
'capacity-dmips-mhz' for each CPU with the same value in order to
force the scaled capacity computation.

In order to fix this situation, allocate 'raw_capacity' so the pointer
is set and the init_cpu_capacity_callback() function can be called."

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] mtd: spi-nor: fix erase_type array to indicate current map conf

[Tudor.Ambarus]

Hi, Alexander,

On 11/23/2018 11:42 AM, Sverdlin, Alexander (Nokia - DE/Ulm) wrote:
> Hello Tudor,
> 
> On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
>> From: Tudor Ambarus 
>>
>> Bug reported for the out-of-tree S25FS128S flash memory.
>>
>> BFPT table advertises all the erase types supported by all the
>> possible map configurations. Update the erase_type array to indicate
>> which erase types are applicable to the current map configuration.
>>
>> Backward compatibility test done on sst26vf064b.
>>
>> Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
>> Reported-by: Alexander Sverdlin 
>> Signed-off-by: Tudor Ambarus 
> 
> I've tested this patch and it fixes the erasesize for S25FS128S and
> our 128k partitions are writeable again with this patch.

Good. You said that the flash is configured in non-uniform mapping (hybrid
sector option). There is no uniform erase type that can erase the entire
flash memory by its own, so the erase should be done using the non-uniform
erase code (spi_nor_has_uniform_erase() should return false). Does the
non-uniform erase work as expected? 

For example, if the hybrid section is at the top of the address space, when
using mtd_utils:
$ mtd_debug erase /dev/your_mtd 4096 126976
I would expect the use of the following erase types: 7*4k, 32k, 64k
Then write and read back to check if the erase was done correctly:
$ dd if=/dev/urandom of=in bs=4096 count=31
$ mtd_debug write /dev/your_mtd 4096 126976 in
$ mtd_debug read /dev/your_mtd 4096 126976 out
$ sha1sum in out
the output should be the same.

Feel free to add some prints in the code to be sure that non-uniform erase code
selects the correct erase types.

> 
> Nevertheless, I think this is coincidence. I don't think that it
> makes sense to OR all the erase types from all regions in one
> bitmask and derive any uniform erasesize out of it.
> This makes little sense for me in case of non-uniform maps.

I just masked out the erase types that are not supported by the current
configuration map. We should not use an erase type that is not supported
by any of the map regions. SMPT, if present, should have precedence over
BFPT when indicating supported erase types.

Cheers,
ta

> 
> I believe, the culprit here is one level higher, in the MTD partitioning
> code (mtdpart.c) which has to be taught about non-uniform maps
> but there is no infrastructure for this currently.
> 
> What is possible to fix still is to choose smallest, not biggest
> erasesize for uniform case. I have such a patch, but I need hands
> on on a S25FS128S configured in uniform mode.
> 
> Non uniform case requires MTD layer rework. We just cannot handle
> this hardware with just one erasesize in mind. 
> 
>> ---
>>  drivers/mtd/spi-nor/spi-nor.c | 29 -
>>  1 file changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index 93c9bc8931fc..a71adcd6ddfa 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -3000,7 +3000,8 @@ static int spi_nor_init_non_uniform_erase_map(struct 
>> spi_nor *nor,
>>  u64 offset;
>>  u32 region_count;
>>  int i, j;
>> -u8 erase_type, uniform_erase_type;
>> +u8 uniform_erase_type, save_uniform_erase_type;
>> +u8 erase_type, regions_erase_type;
>>  
>>  region_count = SMPT_MAP_REGION_COUNT(*smpt);
>>  /*
>> @@ -3014,6 +3015,7 @@ static int spi_nor_init_non_uniform_erase_map(struct 
>> spi_nor *nor,
>>  map->regions = region;
>>  
>>  uniform_erase_type = 0xff;
>> +regions_erase_type = 0;
>>  offset = 0;
>>  /* Populate regions. */
>>  for (i = 0; i < region_count; i++) {
>> @@ -3030,13 +3032,38 @@ static int spi_nor_init_non_uniform_erase_map(struct 
>> spi_nor *nor,
>>   */
>>  uniform_erase_type &= erase_type;
>>  
>> +/*
>> + * regions_erase_type mask will indicate all the erase types
>> + * supported in this configuration map.
>> + */
>> +regions_erase_type |= erase_type;
>> +
>>  offset = (region[i].offset & ~SNOR_ERASE_FLAGS_MASK) +
>>   region[i].size;
>>  }
>>  
>> +save_uniform_erase_type = map->uniform_erase_type;
>>  map->uniform_erase_type = spi_nor_sort_erase_mask(map,
>>uniform_erase_type);
>>  
>> +if (!regions_erase_type) {
>> +/*
>> + * Roll back to the previous uniform_erase_type mask, SMPT is
>> + * broken.
>> + */
>> +map->uniform_erase_type = save_uniform_erase_type;
>> +return -EINVAL;
>> +}
>> +
>> +/*
>> + * BFPT table advertises all the erase types supported by all the
>> + * possible map configurations. Update the erase_type array to indicate
>> + * which erase types are applicable to the current map configuration.

[RFC/RFT][PATCH v6] cpuidle: New timer events oriented governor for tickless systems

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The venerable menu governor does some thigns that are quite
questionable in my view.

First, it includes timer wakeups in the pattern detection data and
mixes them up with wakeups from other sources which in some cases
causes it to expect what essentially would be a timer wakeup in a
time frame in which no timer wakeups are possible (becuase it knows
the time until the next timer event and that is later than the
expected wakeup time).

Second, it uses the extra exit latency limit based on the predicted
idle duration and depending on the number of tasks waiting on I/O,
even though those tasks may run on a different CPU when they are
woken up.  Moreover, the time ranges used by it for the sleep length
correction factors depend on whether or not there are tasks waiting
on I/O, which again doesn't imply anything in particular, and they
are not correlated to the list of available idle states in any way
whatever.

Also, the pattern detection code in menu may end up considering
values that are too large to matter at all, in which cases running
it is a waste of time.

A major rework of the menu governor would be required to address
these issues and the performance of at least some workloads (tuned
specifically to the current behavior of the menu governor) is likely
to suffer from that.  It is thus better to introduce an entirely new
governor without them and let everybody use the governor that works
better with their actual workloads.

The new governor introduced here, the timer events oriented (TEO)
governor, uses the same basic strategy as menu: it always tries to
find the deepest idle state that can be used in the given conditions.
However, it applies a different approach to that problem.

First, it doesn't use "correction factors" for the time till the
closest timer, but instead it tries to correlate the measured idle
duration values with the available idle states and use that
information to pick up the idle state that is most likely to "match"
the upcoming CPU idle interval.

Second, it doesn't take the number of "I/O waiters" into account at
all and the pattern detection code in it avoids taking timer wakeups
into account.  It also only uses idle duration values less than the
current time till the closest timer (with the tick excluded) for that
purpose.

Signed-off-by: Rafael J. Wysocki 
---

v5 -> v6:
 * Avoid applying poll_time_limit to non-polling idle states by mistake.
 * Use idle duration measured by the governor for everything (as it likely is
   more accurate than the one measured by the core).
 * Rename SPIKE to PULSE.
 * Do not run pattern detection upfront.  Instead, use recent idle duration
   values to refine the state selection after finding a candidate idle state.
 * Do not use the expected idle duration as an extra latency constraint
   (exit latency is less than the target residency for all of the idle states
   known to me anyway, so this doesn't change anything in practice).

v4 -> v5:
 * Avoid using shallow idle states when the tick has been stopped already.

v3 -> v4:
 * Make the pattern detection avoid returning too early if the minimum
   sample is too far from the average.
 * Reformat the changelog (as requested by Peter).

v2 -> v3:
 * Simplify the pattern detection code and make it return a value
lower than the time to the closest timer if the majority of recent
idle intervals are below it regardless of their variance (that should
cause it to be slightly more aggressive).
 * Do not count wakeups from state 0 due to the time limit in poll_idle()
   as non-timer.

---
 drivers/cpuidle/Kconfig|   11 
 drivers/cpuidle/governors/Makefile |1 
 drivers/cpuidle/governors/teo.c|  450 +
 3 files changed, 462 insertions(+)

Index: linux-pm/drivers/cpuidle/governors/teo.c
===
--- /dev/null
+++ linux-pm/drivers/cpuidle/governors/teo.c
@@ -0,0 +1,450 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Timer events oriented CPU idle governor
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Rafael J. Wysocki 
+ *
+ * The idea of this governor is based on the observation that on many systems
+ * timer events are two or more orders of magnitude more frequent than any
+ * other interrupts, so they are likely to be the most significant source of 
CPU
+ * wakeups from idle states.  Moreover, information about what happened in the
+ * (relatively recent) past can be used to estimate whether or not the deepest
+ * idle state with target residency within the time to the closest timer is
+ * likely to be suitable for the upcoming idle time of the CPU and, if not, 
then
+ * which of the shallower idle states to choose.
+ *
+ * Of course, non-timer wakeup sources are more important in some use cases and
+ * they can be covered by taking a few most recent idle time intervals of the
+ * CPU into account.  However, even in that case it is no

Re: [PATCH 6/7] mfd / platform: cros_ec: instantiate only if th EC has a VBC NVRAM.

[Enric Balletbo i Serra]

Hi Guenter,

On 22/11/18 20:14, Guenter Roeck wrote:
> On Thu, Nov 22, 2018 at 12:33:55PM +0100, Enric Balletbo i Serra wrote:
>> The cros-ec-vbc driver is DT-only and there is a DT property that
>> indicates if the EC has the VCB NVRAM, in such case instantiate the
>> driver but don't instantiate on the other cases.
>>
>> To do this move the check code to its parent instead of play with the
>> attribute group visibility. This changes a bit the actual behaviour.
>> Before the patch if an EC doesn't have a VBC NVRAM an empty vbc folder
>> is created in /sys/class/chromeos/, after the patch the empty
>> folder is not created, so, the folder is only created if the vbc is set.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>>  drivers/mfd/cros_ec_dev.c | 24 +++-
>>  drivers/platform/chrome/cros_ec_vbc.c | 16 
>>  2 files changed, 23 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
>> index fc235af6da65..a63588953760 100644
>> --- a/drivers/mfd/cros_ec_dev.c
>> +++ b/drivers/mfd/cros_ec_dev.c
>> @@ -21,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -400,7 +401,10 @@ static const struct mfd_cell cros_ec_platform_cells[] = 
>> {
>>  { .name = "cros-ec-debugfs" },
>>  { .name = "cros-ec-lightbar" },
>>  { .name = "cros-ec-sysfs" },
>> -{ .name = "cros-ec-vbc" },
>> +};
>> +
>> +static const struct mfd_cell cros_ec_vbc_cells[] = {
>> +{ .name = "cros-ec-vbc" }
>>  };
>>  
>>  static int ec_device_probe(struct platform_device *pdev)
>> @@ -409,6 +413,7 @@ static int ec_device_probe(struct platform_device *pdev)
>>  struct device *dev = &pdev->dev;
>>  struct cros_ec_platform *ec_platform = dev_get_platdata(dev);
>>  struct cros_ec_dev *ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
>> +struct device_node *node;
>>  
>>  if (!ec)
>>  return retval;
>> @@ -492,6 +497,23 @@ static int ec_device_probe(struct platform_device *pdev)
>>  dev_err(ec->dev,
>>  "failed to add cros-ec platform devices: %d\n", retval);
>>  
>> +/* Check whether this EC instance has a VBC NVRAM */
>> +node = ec->ec_dev->dev->of_node;
>> +if (IS_ENABLED(CONFIG_OF) && node) {
> 
> Is IS_ENABLED() necessary here ? Seems to me node should always be NULL
> in this case.
> 
>> +if (of_property_read_bool(node, "google,has-vbc-nvram")) {
>> +dev_err(dev, "device VBC found.\n");
> 
> dev_err ?
> 

Ups, I added this message only for debugging puposes, I think doesn't make sense
here so I'll remove.

>> +retval = devm_mfd_add_devices(ec->dev,
>> +PLATFORM_DEVID_AUTO,
>> +cros_ec_vbc_cells,
>> +ARRAY_SIZE(cros_ec_vbc_cells),
>> +NULL, 0, NULL);
>> +if (retval)
>> +dev_err(ec->dev,
>> +"failed to add VBC devices: %d\n",
>> +retval);
> 
> Since the error is ignored, maybe better dev_warn() ?
> 

Done in next version.

>> +}
>> +}
>> +
>>  return 0;
>>  
>>  failed:
>> diff --git a/drivers/platform/chrome/cros_ec_vbc.c 
>> b/drivers/platform/chrome/cros_ec_vbc.c
>> index 374153e3dc13..b7b81fe0fb25 100644
>> --- a/drivers/platform/chrome/cros_ec_vbc.c
>> +++ b/drivers/platform/chrome/cros_ec_vbc.c
>> @@ -108,21 +108,6 @@ static ssize_t vboot_context_write(struct file *filp, 
>> struct kobject *kobj,
>>  return data_sz;
>>  }
>>  
>> -static umode_t cros_ec_vbc_is_visible(struct kobject *kobj,
>> -  struct bin_attribute *a, int n)
>> -{
>> -struct device *dev = container_of(kobj, struct device, kobj);
>> -struct cros_ec_dev *ec = to_cros_ec_dev(dev);
>> -struct device_node *np = ec->ec_dev->dev->of_node;
>> -
>> -if (IS_ENABLED(CONFIG_OF) && np) {
>> -if (of_property_read_bool(np, "google,has-vbc-nvram"))
>> -return a->attr.mode;
>> -}
>> -
>> -return 0;
>> -}
>> -
>>  static BIN_ATTR_RW(vboot_context, 16);
>>  
>>  static struct bin_attribute *cros_ec_vbc_bin_attrs[] = {
>> @@ -133,7 +118,6 @@ static struct bin_attribute *cros_ec_vbc_bin_attrs[] = {
>>  struct attribute_group cros_ec_vbc_attr_group = {
>>  .name = "vbc",
>>  .bin_attrs = cros_ec_vbc_bin_attrs,
>> -.is_bin_visible = cros_ec_vbc_is_visible,
>>  };
>>  
>>  static int cros_ec_vbc_probe(struct platform_device *pd)

Page Replacement Algo Enhancement to Flush lest recently used memory page

[Rishi]

I'm looking for right kernel API to be able to flush the least
recently used memory page from inactive memory.

I want to develop a kernel module such that it will free least
recently used memory every n seconds untill inactive memory is 0.

This is to reduce the memory allocated to a linux VM dynamically and
make it available to other vms of the host or hypervisor itself.

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

[Dr. Greg]

On Thu, Nov 22, 2018 at 12:56:23PM -0800, Andy Lutomirski wrote:

Good morning to everyone.

> On Thu, Nov 22, 2018 at 3:12 AM Dr. Greg  wrote:
> > In addition, we are not confident
> > the driver will be useful to anything other then server class hardware
> > and will be incapable of supporting virtually all of the existing SGX
> > hardware in the field.

> I forgot to mention: I have a plain old retail Intel Celeron (I
> think -- it's not in front of me right now) that has Flex LC.  I
> suspect that, going forward, all new Intel CPUs will support Flex
> LC.  I really wish that Intel would document all of the detailed
> capabilities of all their CPUs somewhere.

Interesting, that contradicts the read we had gotten on FLC.

The only specific CPU's that we know of that are acknowledged to have
FLC are the XEON E series in support of the PCE/ECDSA attestation for
data-center use of SGX.

I'm assuming this is a really new system?  If so that matches our
experience with respect to the fact that SGX2/EDMM capable systems
slipped out quietly in early generation NUC SOC's.

Your sentinments are correct with respect to getting solid guidance on
hardware, it is a significant issue, particularly with respect to
SGX.

> There has been some talk of how the driver could support old CPUs.
> It would involve a rather different LE being signed by Intel, but it
> should be more or less transparent to user code if it happens.

I will reply to the LE and driver capability issues in my response to
your earlier e-mail so the thread does not diverge.

Jarkko, when this driver lands it will set the SGX ABI in stone for
Linux.  It would be very, very helpful to the development community if
there was some official guidance from Intel on whether or not FLC will
be a universal feature on all hardware and the date that is going to
happen or has happened.

If this turns out to be an OEM selectable issue via firmware
customizations, things will be even more problematic.

As things stand now, the proposed mainline SGX driver is going to be
useless for a lot of hardware that is out in the field.  Linux has
always had the reputation for supporting legacy hardware so this
directly contravenes that principal and needlessly so.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker
IDfusion, LLC
4206 N. 19th Ave.   Implementing measured information privacy
Fargo, ND  58102and integrity architectures.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@idfusion.org
--
"Simplicity is prerequisite for reliability."
-- Edsger W. Dijkstra

Re: [RFC/RFT][PATCH v6] cpuidle: New timer events oriented governor for tickless systems

[Rafael J. Wysocki]

On Friday, November 23, 2018 11:35:38 AM CET Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The venerable menu governor does some thigns that are quite
> questionable in my view.
> 
> First, it includes timer wakeups in the pattern detection data and
> mixes them up with wakeups from other sources which in some cases
> causes it to expect what essentially would be a timer wakeup in a
> time frame in which no timer wakeups are possible (becuase it knows
> the time until the next timer event and that is later than the
> expected wakeup time).
> 
> Second, it uses the extra exit latency limit based on the predicted
> idle duration and depending on the number of tasks waiting on I/O,
> even though those tasks may run on a different CPU when they are
> woken up.  Moreover, the time ranges used by it for the sleep length
> correction factors depend on whether or not there are tasks waiting
> on I/O, which again doesn't imply anything in particular, and they
> are not correlated to the list of available idle states in any way
> whatever.
> 
> Also, the pattern detection code in menu may end up considering
> values that are too large to matter at all, in which cases running
> it is a waste of time.
> 
> A major rework of the menu governor would be required to address
> these issues and the performance of at least some workloads (tuned
> specifically to the current behavior of the menu governor) is likely
> to suffer from that.  It is thus better to introduce an entirely new
> governor without them and let everybody use the governor that works
> better with their actual workloads.
> 
> The new governor introduced here, the timer events oriented (TEO)
> governor, uses the same basic strategy as menu: it always tries to
> find the deepest idle state that can be used in the given conditions.
> However, it applies a different approach to that problem.
> 
> First, it doesn't use "correction factors" for the time till the
> closest timer, but instead it tries to correlate the measured idle
> duration values with the available idle states and use that
> information to pick up the idle state that is most likely to "match"
> the upcoming CPU idle interval.
> 
> Second, it doesn't take the number of "I/O waiters" into account at
> all and the pattern detection code in it avoids taking timer wakeups
> into account.  It also only uses idle duration values less than the
> current time till the closest timer (with the tick excluded) for that
> purpose.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> v5 -> v6:
>  * Avoid applying poll_time_limit to non-polling idle states by mistake.
>  * Use idle duration measured by the governor for everything (as it likely is
>more accurate than the one measured by the core).

This particular change is actually missing, sorry about that.  It is not
essential, however, so the v6 should be good enough as is for evaluation
and review purposes.

>  * Rename SPIKE to PULSE.
>  * Do not run pattern detection upfront.  Instead, use recent idle duration
>values to refine the state selection after finding a candidate idle state.
>  * Do not use the expected idle duration as an extra latency constraint
>(exit latency is less than the target residency for all of the idle states
>known to me anyway, so this doesn't change anything in practice).

Thanks,
Rafael

[PATCH v2 0/5] autofs updates

[Ian Kent]

- improve file system verification for ioctl case.
- fix potential inode leak in mount code.
- add "strictexpire" autofs mount option.

v2 changes:
- fix compile error.
- deffer some of the mount option re-factoring to try and
  avoid any conflicts with linux-next.

---

Ian Kent (5):
  autofs - improve ioctl sbi checks
  autofs - fix possible inode leak in autofs_fill_super()
  autofs - simplify parse_options() function call
  autofs - change catatonic setting to a bit flag
  autofs - add strictexpire mount option


 fs/autofs/autofs_i.h |   11 --
 fs/autofs/dev-ioctl.c|   29 +---
 fs/autofs/init.c |2 +
 fs/autofs/inode.c|   75 +-
 fs/autofs/root.c |   16 ++---
 fs/autofs/waitq.c|   10 +++---
 include/uapi/linux/auto_fs.h |2 +
 7 files changed, 78 insertions(+), 67 deletions(-)

--
Ian

[PATCH v2 1/5] autofs - improve ioctl sbi checks

[Ian Kent]

Al Viro made some suggestions to improve the implementation
of commit 0633da48f0 "fix autofs_sbi() does not check super
block type".

The check is unnessesary in all cases except for ioctl usage
so placing the check in the super block accessor function
adds a small overhead to the common case where it isn't
needed.

So it's sufficient to do this in the ioctl code only.

Also the check in the ioctl code is needlessly complex.

Signed-off-by: Ian Kent 
Cc: Al Viro 
---
 fs/autofs/autofs_i.h  |3 +--
 fs/autofs/dev-ioctl.c |   25 +++--
 fs/autofs/init.c  |2 +-
 3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
index 9f9cadbfbd7a..c4301e33c027 100644
--- a/fs/autofs/autofs_i.h
+++ b/fs/autofs/autofs_i.h
@@ -126,8 +126,7 @@ struct autofs_sb_info {
 
 static inline struct autofs_sb_info *autofs_sbi(struct super_block *sb)
 {
-   return sb->s_magic != AUTOFS_SUPER_MAGIC ?
-   NULL : (struct autofs_sb_info *)(sb->s_fs_info);
+   return (struct autofs_sb_info *)(sb->s_fs_info);
 }
 
 static inline struct autofs_info *autofs_dentry_ino(struct dentry *dentry)
diff --git a/fs/autofs/dev-ioctl.c b/fs/autofs/dev-ioctl.c
index 86eafda4a652..3de4f5e61caf 100644
--- a/fs/autofs/dev-ioctl.c
+++ b/fs/autofs/dev-ioctl.c
@@ -14,6 +14,8 @@
 
 #include "autofs_i.h"
 
+extern struct file_system_type autofs_fs_type;
+
 /*
  * This module implements an interface for routing autofs ioctl control
  * commands via a miscellaneous device file.
@@ -151,22 +153,6 @@ static int validate_dev_ioctl(int cmd, struct 
autofs_dev_ioctl *param)
return err;
 }
 
-/*
- * Get the autofs super block info struct from the file opened on
- * the autofs mount point.
- */
-static struct autofs_sb_info *autofs_dev_ioctl_sbi(struct file *f)
-{
-   struct autofs_sb_info *sbi = NULL;
-   struct inode *inode;
-
-   if (f) {
-   inode = file_inode(f);
-   sbi = autofs_sbi(inode->i_sb);
-   }
-   return sbi;
-}
-
 /* Return autofs dev ioctl version */
 static int autofs_dev_ioctl_version(struct file *fp,
struct autofs_sb_info *sbi,
@@ -658,6 +644,8 @@ static int _autofs_dev_ioctl(unsigned int command,
if (cmd != AUTOFS_DEV_IOCTL_VERSION_CMD &&
cmd != AUTOFS_DEV_IOCTL_OPENMOUNT_CMD &&
cmd != AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD) {
+   struct super_block *sb;
+
fp = fget(param->ioctlfd);
if (!fp) {
if (cmd == AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD)
@@ -666,12 +654,13 @@ static int _autofs_dev_ioctl(unsigned int command,
goto out;
}
 
-   sbi = autofs_dev_ioctl_sbi(fp);
-   if (!sbi || sbi->magic != AUTOFS_SBI_MAGIC) {
+   sb = file_inode(fp)->i_sb;
+   if (sb->s_type != &autofs_fs_type) {
err = -EINVAL;
fput(fp);
goto out;
}
+   sbi = autofs_sbi(sb);
 
/*
 * Admin needs to be able to set the mount catatonic in
diff --git a/fs/autofs/init.c b/fs/autofs/init.c
index 79ae07d9592f..c0c1db2cc6ea 100644
--- a/fs/autofs/init.c
+++ b/fs/autofs/init.c
@@ -16,7 +16,7 @@ static struct dentry *autofs_mount(struct file_system_type 
*fs_type,
return mount_nodev(fs_type, flags, data, autofs_fill_super);
 }
 
-static struct file_system_type autofs_fs_type = {
+struct file_system_type autofs_fs_type = {
.owner  = THIS_MODULE,
.name   = "autofs",
.mount  = autofs_mount,

[PATCH v2 3/5] autofs - simplify parse_options() function call

[Ian Kent]

The parse_options() function uses a long list of parameters, most
of which are present in the super block info structure already.

The mount parameters set in parse_options() options don't require
cleanup so using the super block info struct directly is simpler.
---
 fs/autofs/inode.c |   55 -
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c
index e5c06b5a7371..ccedd12c1ac5 100644
--- a/fs/autofs/inode.c
+++ b/fs/autofs/inode.c
@@ -124,21 +124,24 @@ static const match_table_t tokens = {
{Opt_err, NULL}
 };
 
-static int parse_options(char *options, int *pipefd, kuid_t *uid, kgid_t *gid,
-int *pgrp, bool *pgrp_set, unsigned int *type,
-int *minproto, int *maxproto)
+static int parse_options(char *options,
+struct inode *root, int *pgrp, bool *pgrp_set,
+struct autofs_sb_info *sbi)
 {
char *p;
substring_t args[MAX_OPT_ARGS];
int option;
+   int pipefd = -1;
+   kuid_t uid;
+   kgid_t gid;
 
-   *uid = current_uid();
-   *gid = current_gid();
+   root->i_uid = current_uid();
+   root->i_gid = current_gid();
 
-   *minproto = AUTOFS_MIN_PROTO_VERSION;
-   *maxproto = AUTOFS_MAX_PROTO_VERSION;
+   sbi->min_proto = AUTOFS_MIN_PROTO_VERSION;
+   sbi->max_proto = AUTOFS_MAX_PROTO_VERSION;
 
-   *pipefd = -1;
+   sbi->pipefd = -1;
 
if (!options)
return 1;
@@ -152,22 +155,25 @@ static int parse_options(char *options, int *pipefd, 
kuid_t *uid, kgid_t *gid,
token = match_token(p, tokens, args);
switch (token) {
case Opt_fd:
-   if (match_int(args, pipefd))
+   if (match_int(args, &pipefd))
return 1;
+   sbi->pipefd = pipefd;
break;
case Opt_uid:
if (match_int(args, &option))
return 1;
-   *uid = make_kuid(current_user_ns(), option);
-   if (!uid_valid(*uid))
+   uid = make_kuid(current_user_ns(), option);
+   if (!uid_valid(uid))
return 1;
+   root->i_uid = uid;
break;
case Opt_gid:
if (match_int(args, &option))
return 1;
-   *gid = make_kgid(current_user_ns(), option);
-   if (!gid_valid(*gid))
+   gid = make_kgid(current_user_ns(), option);
+   if (!gid_valid(gid))
return 1;
+   root->i_gid = gid;
break;
case Opt_pgrp:
if (match_int(args, &option))
@@ -178,27 +184,27 @@ static int parse_options(char *options, int *pipefd, 
kuid_t *uid, kgid_t *gid,
case Opt_minproto:
if (match_int(args, &option))
return 1;
-   *minproto = option;
+   sbi->min_proto = option;
break;
case Opt_maxproto:
if (match_int(args, &option))
return 1;
-   *maxproto = option;
+   sbi->max_proto = option;
break;
case Opt_indirect:
-   set_autofs_type_indirect(type);
+   set_autofs_type_indirect(&sbi->type);
break;
case Opt_direct:
-   set_autofs_type_direct(type);
+   set_autofs_type_direct(&sbi->type);
break;
case Opt_offset:
-   set_autofs_type_offset(type);
+   set_autofs_type_offset(&sbi->type);
break;
default:
return 1;
}
}
-   return (*pipefd < 0);
+   return (sbi->pipefd < 0);
 }
 
 int autofs_fill_super(struct super_block *s, void *data, int silent)
@@ -206,7 +212,6 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
struct inode *root_inode;
struct dentry *root;
struct file *pipe;
-   int pipefd;
struct autofs_sb_info *sbi;
struct autofs_info *ino;
int pgrp = 0;
@@ -266,9 +271,7 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
root->d_fsdata = ino;
 
/* Can this call block? */
-   if (parse_options(data, &pipefd, &root_inode->i_uid, &root_inode->i_gid,
- &pgrp, &pgrp_set, &

[PATCH v2 5/5] autofs - add strictexpire mount option

[Ian Kent]

Commit 092a53452b (("autofs: take more care to not update last_used
on path walk") helped to (partially) resolve a problem where automounts
were not expiring due to aggressive accesses from user space.

This patch was later reverted because, for very large environments,
it meant more mount requests from clients and when there are a lot
of clients this caused a fairly significant increase in server load.

But there is a need for both types of expire check, depending on use
case, so add a mount option to allow for strict update of last use
of autofs dentrys (which just means not updating the last use on path
walk access).

Signed-off-by: Ian Kent 
---
 fs/autofs/autofs_i.h |1 +
 fs/autofs/inode.c|8 +++-
 fs/autofs/root.c |5 -
 include/uapi/linux/auto_fs.h |2 +-
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
index 032cbb12531a..fa3733beb52e 100644
--- a/fs/autofs/autofs_i.h
+++ b/fs/autofs/autofs_i.h
@@ -102,6 +102,7 @@ struct autofs_wait_queue {
 #define AUTOFS_SBI_MAGIC 0x6d4a556d
 
 #define AUTOFS_SBI_CATATONIC   0x0001
+#define AUTOFS_SBI_STRICTEXPIRE 0x0002
 
 struct autofs_sb_info {
u32 magic;
diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c
index 8cfd3f67af57..501833cc49a8 100644
--- a/fs/autofs/inode.c
+++ b/fs/autofs/inode.c
@@ -87,6 +87,8 @@ static int autofs_show_options(struct seq_file *m, struct 
dentry *root)
seq_printf(m, ",direct");
else
seq_printf(m, ",indirect");
+   if (sbi->flags & AUTOFS_SBI_STRICTEXPIRE)
+   seq_printf(m, ",strictexpire");
 #ifdef CONFIG_CHECKPOINT_RESTORE
if (sbi->pipe)
seq_printf(m, ",pipe_ino=%ld", file_inode(sbi->pipe)->i_ino);
@@ -109,7 +111,7 @@ static const struct super_operations autofs_sops = {
 };
 
 enum {Opt_err, Opt_fd, Opt_uid, Opt_gid, Opt_pgrp, Opt_minproto, Opt_maxproto,
-   Opt_indirect, Opt_direct, Opt_offset};
+   Opt_indirect, Opt_direct, Opt_offset, Opt_strictexpire};
 
 static const match_table_t tokens = {
{Opt_fd, "fd=%u"},
@@ -121,6 +123,7 @@ static const match_table_t tokens = {
{Opt_indirect, "indirect"},
{Opt_direct, "direct"},
{Opt_offset, "offset"},
+   {Opt_strictexpire, "strictexpire"},
{Opt_err, NULL}
 };
 
@@ -200,6 +203,9 @@ static int parse_options(char *options,
case Opt_offset:
set_autofs_type_offset(&sbi->type);
break;
+   case Opt_strictexpire:
+   sbi->flags |= AUTOFS_SBI_STRICTEXPIRE;
+   break;
default:
return 1;
}
diff --git a/fs/autofs/root.c b/fs/autofs/root.c
index 164ccd3402cf..1246f396bf0e 100644
--- a/fs/autofs/root.c
+++ b/fs/autofs/root.c
@@ -275,8 +275,11 @@ static int autofs_mount_wait(const struct path *path, bool 
rcu_walk)
pr_debug("waiting for mount name=%pd\n", path->dentry);
status = autofs_wait(sbi, path, NFY_MOUNT);
pr_debug("mount wait done status=%d\n", status);
+   ino->last_used = jiffies;
+   return status;
}
-   ino->last_used = jiffies;
+   if (!(sbi->flags & AUTOFS_SBI_STRICTEXPIRE))
+   ino->last_used = jiffies;
return status;
 }
 
diff --git a/include/uapi/linux/auto_fs.h b/include/uapi/linux/auto_fs.h
index df31aa9c9a8c..082119630b49 100644
--- a/include/uapi/linux/auto_fs.h
+++ b/include/uapi/linux/auto_fs.h
@@ -23,7 +23,7 @@
 #define AUTOFS_MIN_PROTO_VERSION   3
 #define AUTOFS_MAX_PROTO_VERSION   5
 
-#define AUTOFS_PROTO_SUBVERSION3
+#define AUTOFS_PROTO_SUBVERSION4
 
 /*
  * The wait_queue_token (autofs_wqt_t) is part of a structure which is passed

[PATCH v2 4/5] autofs - change catatonic setting to a bit flag

[Ian Kent]

Change the super block info. catatonic setting to be part of a
flags bit field.

Signed-off-by: Ian Kent 
---
 fs/autofs/autofs_i.h  |7 +--
 fs/autofs/dev-ioctl.c |4 ++--
 fs/autofs/inode.c |4 ++--
 fs/autofs/root.c  |   11 ++-
 fs/autofs/waitq.c |   10 +-
 5 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h
index c4301e33c027..032cbb12531a 100644
--- a/fs/autofs/autofs_i.h
+++ b/fs/autofs/autofs_i.h
@@ -101,16 +101,18 @@ struct autofs_wait_queue {
 
 #define AUTOFS_SBI_MAGIC 0x6d4a556d
 
+#define AUTOFS_SBI_CATATONIC   0x0001
+
 struct autofs_sb_info {
u32 magic;
int pipefd;
struct file *pipe;
struct pid *oz_pgrp;
-   int catatonic;
int version;
int sub_version;
int min_proto;
int max_proto;
+   unsigned int flags;
unsigned long exp_timeout;
unsigned int type;
struct super_block *sb;
@@ -140,7 +142,8 @@ static inline struct autofs_info *autofs_dentry_ino(struct 
dentry *dentry)
  */
 static inline int autofs_oz_mode(struct autofs_sb_info *sbi)
 {
-   return sbi->catatonic || task_pgrp(current) == sbi->oz_pgrp;
+   return ((sbi->flags & AUTOFS_SBI_CATATONIC) ||
+task_pgrp(current) == sbi->oz_pgrp);
 }
 
 struct inode *autofs_get_inode(struct super_block *, umode_t);
diff --git a/fs/autofs/dev-ioctl.c b/fs/autofs/dev-ioctl.c
index 3de4f5e61caf..fc1caf449fa3 100644
--- a/fs/autofs/dev-ioctl.c
+++ b/fs/autofs/dev-ioctl.c
@@ -352,7 +352,7 @@ static int autofs_dev_ioctl_setpipefd(struct file *fp,
pipefd = param->setpipefd.pipefd;
 
mutex_lock(&sbi->wq_mutex);
-   if (!sbi->catatonic) {
+   if (!(sbi->flags & AUTOFS_SBI_CATATONIC)) {
mutex_unlock(&sbi->wq_mutex);
return -EBUSY;
} else {
@@ -379,7 +379,7 @@ static int autofs_dev_ioctl_setpipefd(struct file *fp,
swap(sbi->oz_pgrp, new_pid);
sbi->pipefd = pipefd;
sbi->pipe = pipe;
-   sbi->catatonic = 0;
+   sbi->flags &= ~AUTOFS_SBI_CATATONIC;
}
 out:
put_pid(new_pid);
diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c
index ccedd12c1ac5..8cfd3f67af57 100644
--- a/fs/autofs/inode.c
+++ b/fs/autofs/inode.c
@@ -227,12 +227,12 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
sbi->magic = AUTOFS_SBI_MAGIC;
sbi->pipefd = -1;
sbi->pipe = NULL;
-   sbi->catatonic = 1;
sbi->exp_timeout = 0;
sbi->oz_pgrp = NULL;
sbi->sb = s;
sbi->version = 0;
sbi->sub_version = 0;
+   sbi->flags = AUTOFS_SBI_CATATONIC;
set_autofs_type_indirect(&sbi->type);
sbi->min_proto = 0;
sbi->max_proto = 0;
@@ -322,7 +322,7 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
if (ret < 0)
goto fail_fput;
sbi->pipe = pipe;
-   sbi->catatonic = 0;
+   sbi->flags &= ~AUTOFS_SBI_CATATONIC;
 
/*
 * Success! Install the root dentry now to indicate completion.
diff --git a/fs/autofs/root.c b/fs/autofs/root.c
index 782e57b911ab..164ccd3402cf 100644
--- a/fs/autofs/root.c
+++ b/fs/autofs/root.c
@@ -510,7 +510,8 @@ static struct dentry *autofs_lookup(struct inode *dir,
sbi = autofs_sbi(dir->i_sb);
 
pr_debug("pid = %u, pgrp = %u, catatonic = %d, oz_mode = %d\n",
-current->pid, task_pgrp_nr(current), sbi->catatonic,
+current->pid, task_pgrp_nr(current),
+sbi->flags & AUTOFS_SBI_CATATONIC,
 autofs_oz_mode(sbi));
 
active = autofs_lookup_active(dentry);
@@ -563,7 +564,7 @@ static int autofs_dir_symlink(struct inode *dir,
 * autofs mount is catatonic but the state of an autofs
 * file system needs to be preserved over restarts.
 */
-   if (sbi->catatonic)
+   if (sbi->flags & AUTOFS_SBI_CATATONIC)
return -EACCES;
 
BUG_ON(!ino);
@@ -626,7 +627,7 @@ static int autofs_dir_unlink(struct inode *dir, struct 
dentry *dentry)
 * autofs mount is catatonic but the state of an autofs
 * file system needs to be preserved over restarts.
 */
-   if (sbi->catatonic)
+   if (sbi->flags & AUTOFS_SBI_CATATONIC)
return -EACCES;
 
if (atomic_dec_and_test(&ino->count)) {
@@ -714,7 +715,7 @@ static int autofs_dir_rmdir(struct inode *dir, struct 
dentry *dentry)
 * autofs mount is catatonic but the state of an autofs
 * file system needs to be preserved over restarts.
 */
-   if (sbi->catatonic)
+   if (sbi->flags & AUTOFS_SBI_CATATONIC)
return -EACCES;
 
spin_lock(&sbi->lookup_lock);
@@ -759,7 +760,7 @@ static int autofs_dir_mkdir(struct inode *dir,
 * autofs mount is catatonic but the state of an autofs
 * fil

[PATCH v2 2/5] autofs - fix possible inode leak in autofs_fill_super()

[Ian Kent]

There is no check at all for a failure to allocate the root inode
in autofs_fill_super(), handle it.

Signed-off-by: Ian Kent 
---
 fs/autofs/inode.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c
index 846c052569dd..e5c06b5a7371 100644
--- a/fs/autofs/inode.c
+++ b/fs/autofs/inode.c
@@ -254,9 +254,13 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
goto fail_free;
}
root_inode = autofs_get_inode(s, S_IFDIR | 0755);
+   if (!root_inode) {
+   ret = -ENOMEM;
+   goto fail_ino;
+   }
root = d_make_root(root_inode);
if (!root)
-   goto fail_ino;
+   goto fail_iput;
pipe = NULL;
 
root->d_fsdata = ino;
@@ -304,8 +308,8 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
root_inode->i_op = &autofs_dir_inode_operations;
 
pr_debug("pipe fd = %d, pgrp = %u\n", pipefd, pid_nr(sbi->oz_pgrp));
-   pipe = fget(pipefd);
 
+   pipe = fget(pipefd);
if (!pipe) {
pr_err("could not open pipe file descriptor\n");
goto fail_put_pid;
@@ -334,6 +338,8 @@ int autofs_fill_super(struct super_block *s, void *data, 
int silent)
 fail_dput:
dput(root);
goto fail_free;
+fail_iput:
+   iput(root_inode);
 fail_ino:
autofs_free_ino(ino);
 fail_free:

Re: [PATCH 1/2] mm: Remove redundant test from find_get_pages_contig

[Kirill A. Shutemov]

On Thu, Nov 22, 2018 at 01:32:23PM -0800, Matthew Wilcox wrote:
> After we establish a reference on the page, we check the pointer continues
> to be in the correct position in i_pages.  There's no need to check the
> page->mapping or page->index afterwards; if those can change after we've
> got the reference, they can change after we return the page to the caller.

Hm. IIRC, page->mapping can be set to NULL due truncation, but what about
index? When it can be changed? Truncation doesn't touch it.

-- 
 Kirill A. Shutemov

Re: Sleeping in user_access section

[Russell King - ARM Linux]

On Fri, Nov 23, 2018 at 01:57:12AM -0800, h...@zytor.com wrote:
> You should never call a sleeping function from a user_access section.
> It is intended for very limited regions.

So, what happens if the "unsafe" user access causes a page fault that
ends up sleeping?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

RE: [PATCH v4 2/5] nds32: Support FP emulation

[David Laight]

From: Vincent Chen
> Sent: 22 November 2018 03:15
> 
> The Andes FPU coprocessor does not support denormalized number handling.
> According to the specification, FPU generates a denorm input exception
> that requires the kernel to deal with this instrution operation when it
> encounters denormalized operands. Hence an nds32 FPU ISA emulator in the
> kernel is required to meet requirement.

What does the FPU generate for results near zero?
If it doesn't generate denormalised results (but does detect them)
then I assume it never generates FP values with exponent zero.
(So the gap around zero is even larger than it would be if exponent
zero values had a hidden bit.)
So is it really worth doing anything other than treating
denormalised values as zero?

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH 2/2] page cache: Store only head pages in i_pages

[Kirill A. Shutemov]

On Thu, Nov 22, 2018 at 01:32:24PM -0800, Matthew Wilcox wrote:
> Transparent Huge Pages are currently stored in i_pages as pointers to
> consecutive subpages.  This patch changes that to storing consecutive
> pointers to the head page in preparation for storing huge pages more
> efficiently in i_pages.

I probably miss something, I don't see how it wouldn't break
split_huge_page().

I don't see what would replace head pages in i_pages with
formerly-tail-pages?

Hm?

-- 
 Kirill A. Shutemov

Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs

[Charles Keepax]

On Fri, Nov 23, 2018 at 10:40:57AM +0100, Linus Walleij wrote:
> On Thu, Nov 22, 2018 at 6:30 PM Charles Keepax
>  wrote:
> 
> > Currently, a GPIO can be requested multiple times when the
> > NONEXCLUSIVE flag is set, however it must still be freed a single
> > time. This makes client code rather complex, since multiple drivers
> > may request the GPIO but only a single one can free it. Rather than
> > manually handling this in each driver add some basic reference
> > counting into the core.  Currently, this is fairly primitive but
> > so is the support for the NONEXCLUSIVE flag and the implementation
> > covers those use-cases.
> >
> > Reported-by: Marek Szyprowski 
> > Signed-off-by: Charles Keepax 
> 
> This patch is not fixing anything right now, correct?
> 

It's fixing something in the case of two regulators using the
same GPIO. The direction this patch chain takes is that the end
drivers own the GPIOs not the regulator core (except for the
legacy case). So both of the end drivers will devm_ request their
GPIOs, which means that if those drivers are unbound both of them
will attempt to free the GPIO causing the same double free
warning we saw here. Indeed there is a probably worse problem
that if one is unbound it will free the GPIO and break the second
driver.

Basically the current handling of non-exclusive GPIOs in the GPIO
core requires multiple calls to request the GPIO but only a
single call to free the GPIO. If we want to stick with that
approach, then the regulator core does need to take ownership of
the lifetime of the enable GPIOs and the end drivers can't use
devm, as per my initial patch for wm8994. But it makes getting
the error paths in regulator_register sensible really tricky, and
feels like a less "clean" solution.

> I discussed the notion of pulling reference counting for
> nonexclusive GPIOs into gpiolib with Mark but the benefit is
> a bit unclear: if the subsystem using nonexeclusive GPIOs
> (currently only regulators) would still have to keep its own
> reference count or somehow semantically know when
> the last user is gone, the point is kind of moot.
> 
> I haven't looked closely at the regulators case but I got
> the impression that it is more complex than just reference
> counting so, currently I don't know if this is such a good
> idea.
> 
> Anyway I would like to push this until we have cleaned
> up with the rest of the series I have boiling, if you don't
> mind.
> 

I don't greatly mind delaying it as I don't currently look after
any systems that share enable GPIOs on regulators, but free of
those GPIOs is currently really broken so it feels like it
shouldn't be kicked too far down the road.

Thanks,
Charles

> (Patch 1+2 should be fine anyway.)
> 
> Yours,
> Linus Walleij

Re: [PATCH v2] kmemleak: Turn kmemleak_lock to raw spinlock on RT

[Andrea Parri]

> is this an RT-only problem? Because mainline should not allow read->read
> locking or read->write locking for reader-writer locks. If this only
> happens on v4.18 and not on v4.19 then something must have fixed it.

Probably misunderstanding, but I'd say that read->read locking is "the
norm"...?

If you don't use qrwlock, readers are also "recursive", in part.,

  P0P1
  read_lock(l)
write_lock(l)
  read_lock(l)

won't block P0 on the second read_lock().  (qrwlock somehow complicate
the analysis; IIUC, they are recursive if and only if in_interrupt().).

  Andrea


>  
> 
> Sebastian

Re: [PATCH v2] kmemleak: Turn kmemleak_lock to raw spinlock on RT

[Sebastian Andrzej Siewior]

On 2018-11-23 12:02:55 [+0100], Andrea Parri wrote:
> > is this an RT-only problem? Because mainline should not allow read->read
> > locking or read->write locking for reader-writer locks. If this only
> > happens on v4.18 and not on v4.19 then something must have fixed it.
> 
> Probably misunderstanding, but I'd say that read->read locking is "the
> norm"...?
> 
> If you don't use qrwlock, readers are also "recursive", in part.,
> 
>   P0  P1
>   read_lock(l)
>   write_lock(l)
>   read_lock(l)
> 
> won't block P0 on the second read_lock().  (qrwlock somehow complicate
> the analysis; IIUC, they are recursive if and only if in_interrupt().).

ehm, peterz, is that true? My memory on that is that all readers will
block if there is a writer pending.

>   Andrea

Sebastian

Re: [PATCH 7/7] platform/chrome: cros_ec_lightbar: instantiate only if the EC has a lightbar.

[Enric Balletbo i Serra]

Hi Guenter,

On 22/11/18 20:25, Guenter Roeck wrote:
> On Thu, Nov 22, 2018 at 12:33:56PM +0100, Enric Balletbo i Serra wrote:
>> Due to the way attribute groups visibility work, the function
>> cros_ec_lightbar_attrs_are_visible is called multiple times, once per
>> attribute, and each of these calls makes an EC transaction. For what is
>> worth the EC log reports multiple errors on boot when the lightbar is
>> not available. Instead, check if the EC has a lightbar in the probe
>> function and only instantiate the device.
>>
>> Ideally we should have instantiate the driver only if the
>> EC_FEATURE_LIGHTBAR is defined, but that's not possible because that flag
>> is not in the very first Pixel Chromebook (Link), only on Samus. So, the
>> driver is instantiated by his parent always.
>>
>> This patch changes a bit the actual behaviour. Before the patch if an EC
>> doesn't have a lightbar an empty lightbar folder is created in
>> /sys/class/chromeos/, after the patch the empty folder is not
>> created, so, the folder is only created if the lightbar exists.
>>
>> Signed-off-by: Enric Balletbo i Serra 
> 
> Guess this is the answer to the suggestion I had before. Maybe the two patches
> should be merged together ? Or do  others think that they should be kept
> separate ?
> 

I did in a separate patch because it changes a bit the current behaviour (i.e
after that patch the lightbar directory will not appear if is not detected).
Having in a separate patch will allow us to revert cleanly if for some weird
reason we still want the old behaviour. So in general, first I moved the
attributes and then I did a follow up patch with the probe change. This also
happens with vbc driver.

Said that, I don't mind to merge the two patches.


> Additional comment below.
> 
> Thanks,
> Guenter
> 
>> ---
>>
>>  drivers/platform/chrome/cros_ec_lightbar.c | 29 +-
>>  1 file changed, 12 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_lightbar.c 
>> b/drivers/platform/chrome/cros_ec_lightbar.c
>> index 31d22f594fac..d255264eb082 100644
>> --- a/drivers/platform/chrome/cros_ec_lightbar.c
>> +++ b/drivers/platform/chrome/cros_ec_lightbar.c
>> @@ -567,37 +567,28 @@ static struct attribute *__lb_cmds_attrs[] = {
>>  NULL,
>>  };
>>  
>> -static bool ec_has_lightbar(struct cros_ec_dev *ec)
>> +static bool cros_ec_has_lightbar(struct cros_ec_dev *ec_dev)
>>  {
>> -return !!get_lightbar_version(ec, NULL, NULL);
>> -}
>> -
>> -static umode_t cros_ec_lightbar_attrs_are_visible(struct kobject *kobj,
>> -  struct attribute *a, int n)
>> -{
>> -struct device *dev = container_of(kobj, struct device, kobj);
>> -struct cros_ec_dev *ec = to_cros_ec_dev(dev);
>> -struct platform_device *pdev = to_platform_device(ec->dev);
>> +struct platform_device *pdev = to_platform_device(ec_dev->dev);
>>  struct cros_ec_platform *pdata = pdev->dev.platform_data;
>>  int is_cros_ec;
>>  
>>  is_cros_ec = strcmp(pdata->ec_name, CROS_EC_DEV_NAME);
>>  
> Can this now ever be false ?
> 

Yes, this happens for example on Samus, where there are two ECs, the first one
is named "cros_ec" and the second one is "cros_pd", so will fail in the second
case. Gwendal, correct me if I am wrong, but AFAIK this is a bit of hack because
some initial versions of Samus (coded Link I guess) have no support for the
EC_LIGHTBAR_FEATURE so we can't really use the features thing.

>>  if (is_cros_ec != 0)
>> -return 0;
>> +return false;
>>  
>> -/* Only instantiate this stuff if the EC has a lightbar */
>> -if (ec_has_lightbar(ec)) {
>> -ec_with_lightbar = ec;
>> -return a->mode;
>> +if (!!get_lightbar_version(ec_dev, NULL, NULL)) {
>> +ec_with_lightbar = ec_dev;
> 
> Is this variable (and the associated check in lb_manual_suspend_ctrl)
> still necessary ?
> 

Hmm, right, I will double check and remove in next version.

>> +return true;
>>  }
>> -return 0;
>> +
>> +return false;
>>  }
>>  
>>  struct attribute_group cros_ec_lightbar_attr_group = {
>>  .name = "lightbar",
>>  .attrs = __lb_cmds_attrs,
>> -.is_visible = cros_ec_lightbar_attrs_are_visible,
>>  };
>>  
>>  static int cros_ec_lightbar_probe(struct platform_device *pd)
>> @@ -611,6 +602,10 @@ static int cros_ec_lightbar_probe(struct 
>> platform_device *pd)
>>  return -EINVAL;
>>  }
>>  
>> +/* Only instantiate this stuff if the EC has a lightbar */
>> +if (!cros_ec_has_lightbar(ec_dev))
>> +return -ENODEV;
>> +
>>  /* Take control of the lightbar from the EC. */
>>  lb_manual_suspend_ctrl(ec_dev, 1);
>>  
> 

RE: [PATCH] Add /proc/pid_generation

[David Laight]

From: Kevin Easton
> Sent: 22 November 2018 11:20
> 
> On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote:
> > This change adds a per-pid-namespace 64-bit generation number,
> > incremented on PID rollover, and exposes it via a new proc file
> > /proc/pid_generation. By examining this file before and after /proc
> > enumeration, user code can detect the potential reuse of a PID and
> > restart the task enumeration process, repeating until it gets a
> > coherent snapshot.
> 
> I see downthread this patch has been withdrawn, but nonetheless I'm
> still curious - does this actually solve the problem?
> 
> It seems to me that a PID could be reused within a scan even if the
> generation number remains the same at the beginning and end of a scan:

Why not allocate a 48bit generation number to each 16bit pid?
Then you have a 64bit 'extended-pid' that can be assumed to never be reused.
Provided enough interfaces are enhanced to support 'extended-pid' values
you'll never get reused values.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH] ARM: OMAP1: ams-delta: Fix audio permanently muted

[Janusz Krzysztofik]

Since commit 1137ceee76ba ("ARM: OMAP1: ams-delta: Don't request unused
GPIOs"), on-board audio has appeared muted.  Believed to be unused GPIO
pin "hookflash1", apparently set high regardless of the corresponding
bit of "latch2" port attempted to be set low during .init_machine(),
has been identified as the reason.

According to Amstrad E3 wiki, the purpose of the pin hasn't been
clearly identified.  Original Amstrad software used to produce a high
pulse on it when the phone was taken off hook or recall was pressed.
With the current finding, we can assume the pin provides a kind of
audio mute function.

Proper resolution of the issue should be done in two steps:
- resolution of an issue with the pin state not reflecting the value
  the corresponding bit of the port was attempted to be initialized
  with,
- extension of on-board audio driver with a new control.

For now, rename the pin to "audio_mute" to reflect its function and,
as a quick fix, hogg it as output low so on-board audio can produce
audible sound again.

Fixes: 1137ceee76ba ("ARM: OMAP1: ams-delta: Don't request unused GPIOs")
Signed-off-by: Janusz Krzysztofik 
---
 arch/arm/mach-omap1/board-ams-delta.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 3d191fd52910..1d801f5e8308 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -247,8 +247,8 @@ static struct platform_device latch2_gpio_device = {
 #define LATCH2_PIN_SCARD_CMDVCC11
 #define LATCH2_PIN_MODEM_NRESET12
 #define LATCH2_PIN_MODEM_CODEC 13
-#define LATCH2_PIN_HOOKFLASH1  14
-#define LATCH2_PIN_HOOKFLASH2  15
+#define LATCH2_PIN_AUDIO_MUTE  14
+#define LATCH2_PIN_HOOKFLASH   15
 
 static struct regulator_consumer_supply modem_nreset_consumers[] = {
REGULATOR_SUPPLY("RESET#", "serial8250.1"),
@@ -588,6 +588,8 @@ static int gpiochip_match_by_label(struct gpio_chip *chip, 
void *data)
 static struct gpiod_hog ams_delta_gpio_hogs[] = {
GPIO_HOG(LATCH2_LABEL, LATCH2_PIN_KEYBRD_DATAOUT, "keybrd_dataout",
 GPIO_ACTIVE_HIGH, GPIOD_OUT_LOW),
+   GPIO_HOG(LATCH2_LABEL, LATCH2_PIN_AUDIO_MUTE, "audio_mute",
+GPIO_ACTIVE_HIGH, GPIOD_OUT_LOW),
{},
 };
 
-- 
2.18.1