Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Joe Perches]

On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
> On Tue, 10 Jan 2017 14:09:51 -0800
> Joe Perches  wrote:
> 
> > Make these files symlinks to the .rst equivalents
> 
> So I am not necessarily opposed to doing this, but the changelog lacks
> one important thing: why do we need to make that change?  Have the
> existing one-liner files been a problem somehow?

The files tell people to open other files.

Giving the old link to people just tells them to
use the new filename instead.

symlinks open the new file automatically.

$ head Documentation/CodingStyle
This file has moved to process/coding-style.rst

vs a symlink

$ head Documentation/CodingStyle
.. _codingstyle:

Linux kernel coding style
=

This is a short document describing the preferred coding style for the
linux kernel.  Coding style is very personal, and I won't **force** my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too.  Please
at least consider the points made here.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Jonathan Corbet]

On Tue, 10 Jan 2017 14:09:51 -0800
Joe Perches  wrote:

> Make these files symlinks to the .rst equivalents

So I am not necessarily opposed to doing this, but the changelog lacks
one important thing: why do we need to make that change?  Have the
existing one-liner files been a problem somehow?

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions

[Christoph Hellwig]

Hi Kishon,

a couple comments on the configfs layout based on my experiments with
your previous drop to implement a NVMe device using it.

I don't think most of these configfs files should be present here, as
they are properties of the implemented PCIe devices.  E.g. for my
NVMe device they will be sort of hardcoded most of the time, as they
would be for other devices that would always have a fixed vendor/device/
class ID, cacheline size, etc.

In the end what we'll to be able to do here is to be able to create
a directory for each function driver, which then can create it's own
attributes inside it.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Doc: clarify that GPL is GPL v2, not v2+

[Jonathan Corbet]

On Wed, 11 Jan 2017 02:28:40 +0800
Sanjeev  wrote:

> ... and a minor missing priod at EOL
> 
> Signed-off-by: Sanjeev Gupta 

Applied to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kernel-doc: properly document array arguments of function

[Jonathan Corbet]

On Mon,  9 Jan 2017 18:11:57 -0200
Gabriel Krisman Bertazi  wrote:

> Documentation for array parameters passed in a function, like the first
> argument in the function below, weren't getting exported in the rst
> format, although they work fine for html and pdf formats:
> 
>   void drm_clflush_pages(struct page * pages[], unsigned long num_pages)
> 
> That's because the string key to store the description in the
> parameterdescs dictionary doesn't have the [] suffix.  This cleans up
> the suffix from the key before accessing the dictionary.
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  scripts/kernel-doc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 030fc633acd4..0cd3b8461860 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1883,7 +1883,7 @@ sub output_function_rst(%) {
>  $lineprefix = "  ";
>  foreach $parameter (@{$args{'parameterlist'}}) {
>   my $parameter_name = $parameter;
> - #$parameter_name =~ s/\[.*//;
> + $parameter_name =~ s/\[.*//;
>   $type = $args{'parametertypes'}{$parameter};

So surely I had some good reason for commenting that line way back when,
but I certainly don't remember it now.  Applied to the docs tree, thanks.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/37] PCI: dwc: Create a new config symbol to enable pci dwc host

[Joao Pinto]

Hi Kishon,

Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Now that pci designware host has a separate file, create a new
> config symbol to select the host only driver. This is in preparation
> to enable endpoint support to designware driver.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/Kconfig   |   26 +++---
>  drivers/pci/dwc/Makefile  |3 ++-
>  drivers/pci/dwc/pcie-designware.h |   29 +
>  3 files changed, 42 insertions(+), 16 deletions(-)
> 

You are already working in a base where dwc/ already exists. I know you made a
rename / re-structure patch for pci, but I think it was not yet accepted, right?
I don't see it in any of Bjorn' dev branches.

Thanks.

> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 8b08519..d0bdfb5 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -3,13 +3,17 @@ menu "DesignWare PCI Core Support"
>  
>  config PCIE_DW
>   bool
> +
> +config PCIE_DW_HOST
> +bool
>   depends on PCI_MSI_IRQ_DOMAIN
> +select PCIE_DW
>  
>  config PCI_DRA7XX
>   bool "TI DRA7xx PCIe controller"
>   depends on OF && HAS_IOMEM && TI_PIPE3
>   depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
>Enables support for the PCIe controller in the DRA7xx SoC.  There
>are two instances of PCIe controller in DRA7xx.  This controller can
> @@ -18,7 +22,7 @@ config PCI_DRA7XX
>  config PCIE_DW_PLAT
>   bool "Platform bus based DesignWare PCIe Controller"
>   depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
>   ---help---
>This selects the DesignWare PCIe controller support. Select this if
>you have a PCIe controller on Platform bus.
> @@ -32,21 +36,21 @@ config PCI_EXYNOS
>   depends on SOC_EXYNOS5440 || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>  
>  config PCI_IMX6
>   bool "Freescale i.MX6 PCIe controller"
>   depends on SOC_IMX6Q || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>  
>  config PCIE_SPEAR13XX
>   bool "STMicroelectronics SPEAr PCIe controller"
>   depends on ARCH_SPEAR13XX || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want PCIe support on SPEAr13XX SoCs.
>  
> @@ -55,7 +59,7 @@ config PCI_KEYSTONE
>   depends on ARCH_KEYSTONE || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want to enable PCI controller support on Keystone
> SoCs. The PCI controller on Keystone is based on Designware hardware
> @@ -67,7 +71,7 @@ config PCI_LAYERSCAPE
>   depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
>   depends on PCI_MSI_IRQ_DOMAIN
>   select MFD_SYSCON
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want PCIe controller support on Layerscape SoCs.
>  
> @@ -76,7 +80,7 @@ config PCI_HISI
>   bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want PCIe controller support on HiSilicon
> Hip05 and Hip06 SoCs
> @@ -86,7 +90,7 @@ config PCIE_QCOM
>   depends on (ARCH_QCOM || COMPILE_TEST) && OF
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here to enable PCIe controller support on Qualcomm SoCs. The
> PCIe controller uses the Designware core plus Qualcomm-specific
> @@ -97,7 +101,7 @@ config PCIE_ARMADA_8K
>   depends on ARCH_MVEBU || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here if you want to enable PCIe controller support on
> Armada-8K SoCs. The PCIe controller on Armada-8K is based on
> @@ -109,7 +113,7 @@ config PCIE_ARTPEC6
>   depends on MACH_ARTPEC6 || COMPILE_TEST
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>   help
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs.  This PCIe controller uses the DesignWare core.
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 3b57e55..a2df13c 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,5 @@
> -obj-$(CONFIG_PCIE_DW) += pcie-designware.o 

Re: [PATCH] Documentation: cpuset: Fix 'cpuset.tasks' -> 'tasks'

[W. Trevor King]

On Fri, Jan 13, 2017 at 10:27:42AM -0700, Jonathan Corbet wrote:
> > -if a task's pid is written to another cpusets 'cpuset.tasks' file, then its
> > +if a task's pid is written to another cpuset's 'tasks' file, then its
> 
> So I'll confess that I don't understand this change.  All of the
> control files are referred to as cpuset.whatever in this document;
> why should this one, in particular, be different?

'tasks' is part of the generic cgroup tooling, so it doesn't get the
cpuset prefix:

  $ ls /sys/fs/cgroup/cpuset/*tasks*
  /sys/fs/cgroup/cpuset/tasks

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Rob Gardner]

On 01/13/2017 09:08 AM, Dave Hansen wrote:

On 01/13/2017 07:29 AM, Rob Gardner wrote:

so perhaps ADI should simply be disallowed for memory mapped to
files, and this particular complication can be avoided. Thoughts?

What's a "file" from your perspective?

In Linux, shared memory is a file.  hugetlbfs is done with files.  Many
databases mmap() their data into their address space.


Of course I meant a traditional file is the DOS sense, ie, data stored 
on something magnetic. ;) But it doesn't really matter because I am just 
trying to envision a use case for any of the mmap scenarios.


For instance a very persuasive use case for ADI is to 'color' malloc 
memory, freed malloc memory, and malloc's metadata with different ADI 
version tags so as to catch buffer overflows, underflows, use-after-free 
and use-after-realloc type scenarios. What is an equally compelling or 
even mildly interesting use case for ADI in shared memory and file mmap 
situations? Maybe you could mmap a file and immediately tag the entire 
thing with some version, thus disallowing all access to it, and then 
hand out access a chunk at a time. And then?


Rob



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/cgroup-v1: convert pids.txt to pids.rst

[Jonathan Corbet]

On Sat, 24 Dec 2016 11:48:49 +0300
Adygzhy Ondar  wrote:

> Convert pids.txt document to reStructuredText file.

Sorry to have sat on this for so long.

While I am all in favor of converting existing documentation to RST, I
don't think it makes a whole lot of sense if the result isn't included
with the rest of the structured documentation.  If it's not built with
the rest, it might as well stay in the current format.

If you decide to do this again, it's worth thinking about how all of the
control-group documentation will fit into what we're building.  Also
please CC the control-group maintainer on any patches.

Thanks,

jon


Jonathan Corbet / LWN.net / cor...@lwn.net
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: Update CPU hotplug and move it to core-api

[Jonathan Corbet]

On Thu, 22 Dec 2016 17:19:34 +0100
Sebastian Andrzej Siewior  wrote:

> The current CPU hotplug is outdated. During the update to what we
> currently have I rewrote it partly and moved to sphinx format.

OK, I've applied this (finally) to the docs tree, even though I do kind
of agree with Jani about keeping the author information in Git.

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc

[Joao Pinto]

Hi,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> *num-lanes* dt property is parsed in dw_pcie_host_init. However
> *num-lanes* property is applicable to both root complex mode and
> endpoint mode. As a first step, move the parsing of this property
> outside dw_pcie_host_init. This is in preparation for splitting
> pcie-designware.c to pcie-designware.c and pcie-designware-host.c
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |   18 +++---
>  drivers/pci/dwc/pcie-designware.h |1 -
>  2 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 00a0fdc..89cdb6b 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -551,10 +551,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   }
>   }
>  
> - ret = of_property_read_u32(np, "num-lanes", >lanes);
> - if (ret)
> - pci->lanes = 0;
> -
>   ret = of_property_read_u32(np, "num-viewport", >num_viewport);
>   if (ret)
>   pci->num_viewport = 2;
> @@ -751,18 +747,26 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 
> devfn,
>  
>  void dw_pcie_setup_rc(struct pcie_port *pp)
>  {
> + int ret;
> + u32 lanes;
>   u32 val;
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct device *dev = pci->dev;
> + struct device_node *np = dev->of_node;
>  
>   /* get iATU unroll support */
>   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
>   dev_dbg(pci->dev, "iATU unroll: %s\n",
>   pci->iatu_unroll_enabled ? "enabled" : "disabled");
>  
> + ret = of_property_read_u32(np, "num-lanes", );
> + if (ret)
> + lanes = 0;

You moved from host_init to root complex setup function, which in my opinion did
not improve (in this scope).

I suggest that instead of making so much intermediary patches, which is nice to
understand your development sequence, but hard to review. Wouldn't be better to
condense some of the patches? We would have a cloear vision of the final 
product :)

Joao

> +
>   /* set the number of lanes */
>   val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
>   val &= ~PORT_LINK_MODE_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
>   case 1:
>   val |= PORT_LINK_MODE_1_LANES;
>   break;
> @@ -776,7 +780,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>   val |= PORT_LINK_MODE_8_LANES;
>   break;
>   default:
> - dev_err(pci->dev, "num-lanes %u: invalid value\n", pci->lanes);
> + dev_err(pci->dev, "num-lanes %u: invalid value\n", lanes);
>   return;
>   }
>   dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
> @@ -784,7 +788,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>   /* set link width speed control register */
>   val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
>   val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
>   case 1:
>   val |= PORT_LOGIC_LINK_WIDTH_1_LANES;
>   break;
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index d4b3d43..491fbe3 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -148,7 +148,6 @@ struct dw_pcie_ops {
>  struct dw_pcie {
>   struct device   *dev;
>   void __iomem*dbi_base;
> - u32 lanes;
>   u32 num_viewport;
>   u8  iatu_unroll_enabled;
>   struct pcie_portpp;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/37] PCI: dwc: designware: Get device pointer at the start of dw_pcie_host_init

[Joao Pinto]

Hi!

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Get device pointer at the beginning of
> dw_pcie_host_init instead of getting it all over dw_pcie_host_init.
> This is in preparation for splitting struct pcie_port into host and
> core structures (Once split pcie_port will not have device pointer).
> 

I think change should be condense with another patch to reduce the patch-set
number and to give it real meaning. I understand why you are breaking so much
the patch, it is has a lot of changes, but in my opinion is too much fragmented.

Thanks
Joao
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/37] PCI: dwc: Add platform_set_drvdata

[Joao Pinto]

Hi,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Add platform_set_drvdata in all designware based drivers to store the
> private data structure of the driver so that dev_set_drvdata can be
> used to get back private data pointer in add_pcie_port/host_init.
> This is in preparation for splitting struct pcie_port into core and
> host only structures. After the split pcie_port will not be part of
> the driver's private data structure and *container_of* used now
> to get the private data pointer cannot be used.
> 
> Cc: Jingoo Han 
> Cc: Richard Zhu 
> Cc: Lucas Stach 
> Cc: Murali Karicheri 
> Cc: Minghuan Lian 
> Cc: Mingkai Hu 
> Cc: Roy Zang 
> Cc: Thomas Petazzoni 
> Cc: Niklas Cassel 
> Cc: Jesper Nilsson 
> Cc: Joao Pinto 
> Cc: Zhou Wang 
> Cc: Gabriele Paoloni 
> Cc: Stanimir Varbanov 
> Cc: Pratyush Anand 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pci-dra7xx.c   |3 ++-
>  drivers/pci/dwc/pci-exynos.c   |3 ++-
>  drivers/pci/dwc/pci-imx6.c |3 ++-
>  drivers/pci/dwc/pci-keystone.c |2 ++
>  drivers/pci/dwc/pci-layerscape.c   |2 ++
>  drivers/pci/dwc/pcie-armada8k.c|2 ++
>  drivers/pci/dwc/pcie-artpec6.c |2 ++
>  drivers/pci/dwc/pcie-designware-plat.c |2 ++
>  drivers/pci/dwc/pcie-hisi.c|2 ++
>  drivers/pci/dwc/pcie-qcom.c|2 ++
>  drivers/pci/dwc/pcie-spear13xx.c   |3 ++-
>  11 files changed, 22 insertions(+), 4 deletions(-)
> 

This is an example of a change that could be merged with another patch that
gives it more meaning, like I wrote in the review of patch 9/37.

Thanks,
Joao

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 36/37] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP

[Tony Lindgren]

* Kishon Vijay Abraham I  [170112 02:35]:
> The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
> be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
> in RC mode. However in EP mode, the host system is not able to access the
> MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.

I guess ideally in the long run we would set this dynamically based on
the selected mode, right?

Regards,

Tony

> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/mach-omap2/clockdomains7xx_data.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c 
> b/arch/arm/mach-omap2/clockdomains7xx_data.c
> index 6c67965..67ebff8 100644
> --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> @@ -524,7 +524,7 @@
>   .dep_bit  = DRA7XX_PCIE_STATDEP_SHIFT,
>   .wkdep_srcs   = pcie_wkup_sleep_deps,
>   .sleepdep_srcs= pcie_wkup_sleep_deps,
> - .flags= CLKDM_CAN_HWSUP_SWSUP,
> + .flags= CLKDM_CAN_SWSUP,
>  };
>  
>  static struct clockdomain atl_7xx_clkdm = {
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

I'm taking this patch, but with the following commit log:

  Due to the way kbuild works, this header was unintentionally exported
  back in 2013 when it was created, despite it not being in a uapi/
  directory.  This is very non-intuitive behaviour by Kbuild.

  However, we've had this include exported to userland for almost four
  years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
  no hint that anyone has complained about it.  So, let's make it
  officially exported in this state.

If anyone has any objections, they better shout sooner rather than
later.

> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  arch/arm/include/asm/types.h  | 40 
> ---
>  arch/arm/include/uapi/asm/types.h | 40 
> +++
>  2 files changed, 40 insertions(+), 40 deletions(-)
>  delete mode 100644 arch/arm/include/asm/types.h
>  create mode 100644 arch/arm/include/uapi/asm/types.h
> 
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> deleted file mode 100644
> index a53cdb8f068c..
> --- a/arch/arm/include/asm/types.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -#ifndef _ASM_TYPES_H
> -#define _ASM_TYPES_H
> -
> -#include 
> -
> -/*
> - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> - * unambiguous on ARM as you would expect. For the types below, there is a
> - * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> - * and the kernel itself, which results in build errors if you try to build 
> with
> - * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> - * source file (provided that -ffreestanding is used).
> - *
> - *int32_t uint32_t   uintptr_t
> - * bare metal GCC longunsigned long  unsigned int
> - * glibc GCC  int unsigned int   unsigned int
> - * kernel int unsigned int   unsigned long
> - */
> -
> -#ifdef __INT32_TYPE__
> -#undef __INT32_TYPE__
> -#define __INT32_TYPE__   int
> -#endif
> -
> -#ifdef __UINT32_TYPE__
> -#undef __UINT32_TYPE__
> -#define __UINT32_TYPE__  unsigned int
> -#endif
> -
> -#ifdef __UINTPTR_TYPE__
> -#undef __UINTPTR_TYPE__
> -#define __UINTPTR_TYPE__ unsigned long
> -#endif
> -
> -#endif /* _ASM_TYPES_H */
> diff --git a/arch/arm/include/uapi/asm/types.h 
> b/arch/arm/include/uapi/asm/types.h
> new file mode 100644
> index ..9435a42f575e
> --- /dev/null
> +++ b/arch/arm/include/uapi/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _UAPI_ASM_TYPES_H
> +#define _UAPI_ASM_TYPES_H
> +
> +#include 
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> + * and the kernel itself, which results in build errors if you try to build 
> with
> + * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> + * source file (provided that -ffreestanding is used).
> + *
> + *int32_t uint32_t   uintptr_t
> + * bare metal GCC longunsigned long  unsigned int
> + * glibc GCC  int unsigned int   unsigned int
> + * kernel int unsigned int   unsigned long
> + */
> +
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
> +
> +#endif /* _UAPI_ASM_TYPES_H */
> -- 
> 2.8.1
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files

[Joao Pinto]

Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Split pcie-designware.c into pcie-designware-host.c that contains
> the host specific parts of the driver and pcie-designware.c that
> contains the parts used by both host driver and endpoint driver.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/Makefile   |2 +-
>  drivers/pci/dwc/pcie-designware-host.c |  619 
> 
>  drivers/pci/dwc/pcie-designware.c  |  613 +--
>  drivers/pci/dwc/pcie-designware.h  |8 +
>  4 files changed, 634 insertions(+), 608 deletions(-)
>  create mode 100644 drivers/pci/dwc/pcie-designware-host.c
> 
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 7d27c14..3b57e55 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,4 @@

(snip...)

> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> -   int type, u64 cpu_addr, u64 pci_addr,
> -   u32 size)
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> +u64 cpu_addr, u64 pci_addr, u32 size)
>  {
>   u32 retries, val;
>  
> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie 
> *pci, int index,
>   dev_err(pci->dev, "iATU is not being enabled\n");
>  }

Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.

>  
> -static struct irq_chip dw_msi_irq_chip = {
> - .name = "PCI-MSI",
> - .irq_enable = pci_msi_unmask_irq,
> - .irq_disable = pci_msi_mask_irq,
> - .irq_mask = pci_msi_mask_irq,
> - .irq_unmask = pci_msi_unmask_irq,
> -};
> -

(snip...)

> -
> -static const struct irq_domain_ops msi_domain_ops = {
> - .map = dw_pcie_msi_map,
> -};
> -
>  static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
>  {
>   u32 val;
> @@ -454,303 +192,11 @@ static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie 
> *pci)
>   return 0;
>  }

Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.

(snip...)

> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index 491fbe3..808d17b 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -14,6 +14,10 @@
>  #ifndef _PCIE_DESIGNWARE_H
>  #define _PCIE_DESIGNWARE_H
>  
> +#include 
> +#include 
> +#include 
> +
>  /* Parameters for the waiting for link up routine */
>  #define LINK_WAIT_MAX_RETRIES10
>  #define LINK_WAIT_USLEEP_MIN 9
> @@ -167,4 +171,8 @@ struct dw_pcie {
>  void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
>  int dw_pcie_link_up(struct dw_pcie *pci);
>  int dw_pcie_wait_for_link(struct dw_pcie *pci);
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> +int type, u64 cpu_addr, u64 pci_addr,
> +u32 size);
> +void dw_pcie_setup(struct dw_pcie *pci);


Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host as static.

>  #endif /* _PCIE_DESIGNWARE_H */
> 

Thanks,
Joao
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/37] PCI: dwc: designware: Fix style errors in pcie-designware.c

[Joao Pinto]

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Fix all checkpatch warnings and check errors
> in pcie-designware.c
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |   42 
> ++---
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 89cdb6b..ff04074 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -40,13 +40,13 @@ int dw_pcie_read(void __iomem *addr, int size, u32 *val)
>   return PCIBIOS_BAD_REGISTER_NUMBER;
>   }
>  
> - if (size == 4)
> + if (size == 4) {
>   *val = readl(addr);
> - else if (size == 2)
> + } else if (size == 2) {
>   *val = readw(addr);
> - else if (size == 1)
> + } else if (size == 1) {
>   *val = readb(addr);
> - else {
> + } else {
>   *val = 0;
>   return PCIBIOS_BAD_REGISTER_NUMBER;
>   }
> @@ -203,16 +203,15 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>  
>   for (i = 0; i < MAX_MSI_CTRLS; i++) {
>   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
> - (u32 *));
> + (u32 *));
>   if (val) {
>   ret = IRQ_HANDLED;
>   pos = 0;
>   while ((pos = find_next_bit(, 32, pos)) != 32) {
>   irq = irq_find_mapping(pp->irq_domain,
> - i * 32 + pos);
> - dw_pcie_wr_own_conf(pp,
> - PCIE_MSI_INTR0_STATUS + i * 12,
> - 4, 1 << pos);
> +i * 32 + pos);
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
> + i * 12, 4, 1 << pos);
>   generic_handle_irq(irq);
>   pos++;
>   }
> @@ -278,8 +277,9 @@ static void dw_pcie_msi_set_irq(struct pcie_port *pp, int 
> irq)
>  static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)
>  {
>   int irq, pos0, i;
> - struct pcie_port *pp = (struct pcie_port *) 
> msi_desc_to_pci_sysdata(desc);
> + struct pcie_port *pp;
>  
> + pp  = (struct pcie_port *)msi_desc_to_pci_sysdata(desc);
>   pos0 = bitmap_find_free_region(pp->msi_irq_in_use, MAX_MSI_IRQS,
>  order_base_2(no_irqs));
>   if (pos0 < 0)
> @@ -341,7 +341,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp, 
> unsigned int irq, u32 pos)
>  }
>  
>  static int dw_msi_setup_irq(struct msi_controller *chip, struct pci_dev 
> *pdev,
> - struct msi_desc *desc)
> + struct msi_desc *desc)
>  {
>   int irq, pos;
>   struct pcie_port *pp = pdev->bus->sysdata;
> @@ -389,7 +389,7 @@ static void dw_msi_teardown_irq(struct msi_controller 
> *chip, unsigned int irq)
>  {
>   struct irq_data *data = irq_get_irq_data(irq);
>   struct msi_desc *msi = irq_data_get_msi_desc(data);
> - struct pcie_port *pp = (struct pcie_port *) 
> msi_desc_to_pci_sysdata(msi);
> + struct pcie_port *pp = (struct pcie_port *)msi_desc_to_pci_sysdata(msi);
>  
>   clear_irq_range(pp, irq, 1, data->hwirq);
>  }
> @@ -431,7 +431,7 @@ int dw_pcie_link_up(struct dw_pcie *pci)
>  }
>  
>  static int dw_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> - irq_hw_number_t hwirq)
> +irq_hw_number_t hwirq)
>  {
>   irq_set_chip_and_handler(irq, _msi_irq_chip, handle_simple_irq);
>   irq_set_chip_data(irq, domain->host_data);
> @@ -468,8 +468,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  
>   cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>   if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res)/2;
> - pp->cfg1_size = resource_size(cfg_res)/2;
> + pp->cfg0_size = resource_size(cfg_res) / 2;
> + pp->cfg1_size = resource_size(cfg_res) / 2;
>   pp->cfg0_base = cfg_res->start;
>   pp->cfg1_base = cfg_res->start + pp->cfg0_size;
>   } else if (!pp->va_cfg0_base) {
> @@ -508,8 +508,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   break;
>   case 0:
>   pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg)/2;
> - pp->cfg1_size = resource_size(pp->cfg)/2;
> + pp->cfg0_size = resource_size(pp->cfg) / 2;
> + pp->cfg1_size = resource_size(pp->cfg) / 2;
>   

Re: [PATCH 06/37] PCI: dwc: Rename cfg_read/cfg_write to read/write

[Joao Pinto]

Hi,

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. dw_pcie_cfg_read/dw_pcie_cfg_write doesn't do
> anything specific to access configuration space. It can be just renamed
> to dw_pcie_read/dw_pcie_write and used to read/write data to dbi space.
> This is in preparation for added endpoint support to linux kernel.
> 
> Cc: Jingoo Han 
> Cc: Murali Karicheri 
> Cc: Joao Pinto 
> Cc: Stanimir Varbanov 
> Cc: Pratyush Anand 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pci-dra7xx.c  |   16 
>  drivers/pci/dwc/pci-exynos.c  |4 ++--
>  drivers/pci/dwc/pci-keystone-dw.c |4 ++--
>  drivers/pci/dwc/pcie-designware.c |   12 ++--
>  drivers/pci/dwc/pcie-designware.h |4 ++--
>  drivers/pci/dwc/pcie-qcom.c   |2 +-
>  drivers/pci/dwc/pcie-spear13xx.c  |   24 
>  7 files changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index aeeab74..38b0c9a 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -114,22 +114,22 @@ static int dra7xx_pcie_establish_link(struct 
> dra7xx_pcie *dra7xx)
>   }
>  
>   if (dra7xx->link_gen == 1) {
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> -  4, );
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCAP,
> +  4, );
>   if ((reg & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
>   reg &= ~((u32)PCI_EXP_LNKCAP_SLS);
>   reg |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> -   PCI_EXP_LNKCAP, 4, reg);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> +   PCI_EXP_LNKCAP, 4, reg);
>   }
>  
> - dw_pcie_cfg_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> -  2, );
> + dw_pcie_read(pp->dbi_base + exp_cap_off + PCI_EXP_LNKCTL2,
> +  2, );
>   if ((reg & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB) {
>   reg &= ~((u32)PCI_EXP_LNKCAP_SLS);
>   reg |= PCI_EXP_LNKCAP_SLS_2_5GB;
> - dw_pcie_cfg_write(pp->dbi_base + exp_cap_off +
> -   PCI_EXP_LNKCTL2, 2, reg);
> + dw_pcie_write(pp->dbi_base + exp_cap_off +
> +   PCI_EXP_LNKCTL2, 2, reg);
>   }
>   }
>  
> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
> index c179e7a..e3fbff4 100644
> --- a/drivers/pci/dwc/pci-exynos.c
> +++ b/drivers/pci/dwc/pci-exynos.c
> @@ -429,7 +429,7 @@ static int exynos_pcie_rd_own_conf(struct pcie_port *pp, 
> int where, int size,
>   int ret;
>  
>   exynos_pcie_sideband_dbi_r_mode(exynos_pcie, true);
> - ret = dw_pcie_cfg_read(pp->dbi_base + where, size, val);
> + ret = dw_pcie_read(pp->dbi_base + where, size, val);
>   exynos_pcie_sideband_dbi_r_mode(exynos_pcie, false);
>   return ret;
>  }
> @@ -441,7 +441,7 @@ static int exynos_pcie_wr_own_conf(struct pcie_port *pp, 
> int where, int size,
>   int ret;
>  
>   exynos_pcie_sideband_dbi_w_mode(exynos_pcie, true);
> - ret = dw_pcie_cfg_write(pp->dbi_base + where, size, val);
> + ret = dw_pcie_write(pp->dbi_base + where, size, val);
>   exynos_pcie_sideband_dbi_w_mode(exynos_pcie, false);
>   return ret;
>  }
> diff --git a/drivers/pci/dwc/pci-keystone-dw.c 
> b/drivers/pci/dwc/pci-keystone-dw.c
> index 9397c46..4875334 100644
> --- a/drivers/pci/dwc/pci-keystone-dw.c
> +++ b/drivers/pci/dwc/pci-keystone-dw.c
> @@ -444,7 +444,7 @@ int ks_dw_pcie_rd_other_conf(struct pcie_port *pp, struct 
> pci_bus *bus,
>  
>   addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>  
> - return dw_pcie_cfg_read(addr + where, size, val);
> + return dw_pcie_read(addr + where, size, val);
>  }
>  
>  int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
> @@ -456,7 +456,7 @@ int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct 
> pci_bus *bus,
>  
>   addr = ks_pcie_cfg_setup(ks_pcie, bus_num, devfn);
>  
> - return dw_pcie_cfg_write(addr + where, size, val);
> + return dw_pcie_write(addr + where, size, val);
>  }
>  
>  /**
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0b928dc..d0ea310 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -33,7 +33,7 @@
>  
>  static struct pci_ops dw_pcie_ops;
>  
> -int dw_pcie_cfg_read(void __iomem *addr, int size, u32 

Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Borislav Petkov]

On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote:
> Le 13/01/2017 à 16:43, David Howells a écrit :
> >> -header-y += msr-index.h
> > 
> > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there 
> > at
> > least four years - and as such it's part of the UAPI.  I don't think you can
> > remove it unless you can guarantee there are no userspace users.
> I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks 
> me
> to un-export it.
> 
> I will follow the maintainer decision.

I'm not the maintainer. I simply think that exporting that file was
wrong because it if we change something in it, we will break userspace.
And that should not happen - if userspace needs MSRs, it should do its
own defines.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/37] PCI: dwc: designware: Move the register defines to designware header file

[Joao Pinto]

Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Move the register defines and other macros from
> pcie-designware.c to pcie-designware.h. This is in preparation to
> split the pcie-designware.c file into designware core file and host
> specific file.
> 
> While at that also fix a checkpatch warning.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/dwc/pcie-designware.c |   70 
>  drivers/pci/dwc/pcie-designware.h |   71 
> +
>  2 files changed, 71 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index d68bc7b..0b928dc 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -25,76 +25,6 @@
>  
>  #include "pcie-designware.h"

Make sense.

Reviewed-By: Joao Pinto 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v1 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 pwm and fan tach controller device driver

[Rob Herring]

On Mon, Jan 09, 2017 at 01:59:34PM -0800, Jaghathiswari Rankappagounder 
Natarajan wrote:
> This binding provides interface for adding values related to ASPEED
> AST2400/2500 PWM and Fan tach controller support.
> The PWM controller can support upto 8 PWM output ports.
> The Fan tach controller can support upto 16 tachometer inputs.
> PWM clock types M, N and 0 are three types just to have three independent
> PWM sources.
> 
> Signed-off-by: Jaghathiswari Rankappagounder Natarajan 
> ---
>  .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 153 
> +

Perhaps bindings/pwm/... even though this is more than just PWM.

>  1 file changed, 153 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt 
> b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> new file mode 100644
> index ..8f346409ee8c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> @@ -0,0 +1,153 @@
> +ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
> +
> +The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan 
> Tacho
> +controller can support upto 16 tachometer inputs. The PWM controller supports
> +3 types of frequency mode PWM for fan speed control. PWM clock types M, N 
> and 0
> +are 3 types of frequency mode PWM just to have 3 independent PWM sources.
> +
> +Required properties for pwm_tacho node:
> +- #address-cells : should be 1.
> +
> +- #size-cells : should be 1.
> +
> +- reg : address and length of the register set for the device.
> +
> +- pinctrl-names : a pinctrl state named "default" must be defined.
> +
> +- pinctrl-0 : phandle referencing pin configuration of the AST2400/AST2500 
> PWM
> +   ports.
> +
> +- compatible : should be "aspeed,aspeed2400-pwm-tacho" for AST2400 or
> +"aspeed,aspeed2500-pwm-tacho" for AST2500.
> +
> +- clocks : a fixed clock providing input clock frequency(PWM
> +and Fan Tach clock)
> +
> +type_values subnode format:

Don't use '_' in node or property names.

> +===
> +Under type_values subnode there can be upto 3 child nodes indicating type 
> M/N/O
> +values. Atleast one child node is required.
> +
> +Required properties for the child node(type M/N/O):
> +- pwm_period : indicates type M/N/O PWM period, as per the AST2400/AST2500
> +datasheet. integer value in the range 0 to 255.


> +
> +- pwm_clock_division_l : indicates type M/N/O PWM clock division L value,
> +  as per the AST2400/AST2500 datasheet.
> +  integer value in the range 0 to 15.
> +  0 here indicates divide 1, 1 indicates divide 2,
> +  2 indicates divide 4, 3 indicates divide 6, and so on
> +  till 15 indicates divide 30.
> +
> +- pwm_clock_division_h : indicates type M/N/O PWM clock division H value,
> +  as per the AST2400/AST2500 datasheet.
> +  integer value in the range 0 to 15.
> +  0 here indicates divide 1, 1 indicates divide 2,
> +  2 indicates divide 4, 3 indicates divide 8, and so on
> +  till 15 indicates divide 32768.

Can't you have a single divider value and driver convert to register 
values? Really, you should specify the PWM period in ns/us and calculate 
the divider based on the input clock freq. (i.e. use the clock binding). 
There's already PWM binding to specify the period.

I think you should have a node for the fan using the PWM binding and 
perhaps moving some of these properties to the fan node.

> +
> +- fan_tach_enable : indicates fan tach enable of type M/N/O as per the
> + AST2400/AST2500 datasheet. boolean value.
> +
> +- fan_tach_clock_division : indicates fan tach clock division as per the
> + AST2400/AST2500 datasheet.
> + integer value in the range 0 to 7.
> + 0 indicates divide 4, 1 indicates divide 16,
> + 2 indicates divide 64, 3 indicates divide 256
> + and so on till 7 indicates divide 65536.
> +
> +- fan_tach_mode_selection : indicates fan tach mode mode selection as per the
> + AST2400/AST2500 datasheet. integer value in the
> + range 0 to 2. 0 indicates falling edge, 1 indicates
> + rising edge and 2 indicates both edges.
> +
> +- fan_tach_period : indicates fan tach period as per the AST2400/AST2500
> + datasheet. integer value (can be upto 16 bits long).
> +
> +pwm_port subnode format:
> +
> +Under pwm_port subnode there can upto 8 child nodes each indicating values
> +for one of the 8 PWM output ports.
> +
> +Required properties for 

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote:
> Please, do not remove the email subject when you reply. I restore it to
> ease the thread follow-up.

I mentioned it to David, and he says it's because the long list of
recipients is breaking his mailer.  I've already posed the question
about whether that's exploitable!

> Le 13/01/2017 à 16:36, David Howells a écrit :
> > Nicolas Dichtel  wrote:
> > 
> >> This header file is exported, thus move it to uapi.
> > 
> > Exported how?
> 
> It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
> arch/arm/include/uapi/asm/Kbuild.

We really should not be installing non-uapi header files to userland
under _any_ circumstance - this to me sounds like a bug in kbuild.

The assumption is that headers outside of uapi directories are not
part of the user visible API, and so can be freely modified - which
in the presence of this bug is untrue.

However, as it's happening, and this header has been there since 2013
(commit 09096f6a0ee2 - "ARM: 7822/1: add workaround for ambiguous C99
stdint.h types") it's now well and truely part of the user API whether
we intended it to be or not, so your patch looks to me like the correct
thing to do.

I think it needs further evaluation to make sure kbuild isn't going to
do something else silly, like subsitute include/asm-generic/types.h for
the now missing arch/arm/include/asm/types.h

I wonder how many more headers are unintentionally exported.

... what a mess. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Dave Hansen]

On 01/13/2017 07:29 AM, Rob Gardner wrote:
> so perhaps ADI should simply be disallowed for memory mapped to
> files, and this particular complication can be avoided. Thoughts?

What's a "file" from your perspective?

In Linux, shared memory is a file.  hugetlbfs is done with files.  Many
databases mmap() their data into their address space.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Nicolas Dichtel]

Le 13/01/2017 à 16:43, David Howells a écrit :
>> -header-y += msr-index.h
> 
> I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
> least four years - and as such it's part of the UAPI.  I don't think you can
> remove it unless you can guarantee there are no userspace users.
I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks me
to un-export it.

I will follow the maintainer decision.


Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/8] arm: put types.h in uapi

[Nicolas Dichtel]

Please, do not remove the email subject when you reply. I restore it to ease the
thread follow-up.

Le 13/01/2017 à 16:36, David Howells a écrit :
> Nicolas Dichtel  wrote:
> 
>> This header file is exported, thus move it to uapi.
> 
> Exported how?
It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
arch/arm/include/uapi/asm/Kbuild.

You can also have a look at patch #5 to see why it was exported even if it was
not in an uapi directory.

Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Khalid Aziz]

On 01/13/2017 08:29 AM, Rob Gardner wrote:

On 01/13/2017 07:48 AM, Khalid Aziz wrote:

On 01/12/2017 06:31 PM, Rob Gardner wrote:

On 01/12/2017 05:22 PM, Khalid Aziz wrote:

On 01/12/2017 10:53 AM, Dave Hansen wrote:

On 01/12/2017 08:50 AM, Khalid Aziz wrote:

2. Any shared page that has ADI protection enabled on it, must
stay ADI
protected across all processes sharing it.


Is that true?

What happens if a page with ADI tags set is accessed via a PTE without
the ADI enablement bit set?


ADI protection applies across all processes in terms of all of them
must use the same tag to access the shared memory, but if a process
accesses a shared page with TTE.mcde bit cleared, access will be
granted.




COW creates an intersection of the two. It creates a new copy of the
shared data. It is a new data page and hence the process creating it
must be the one responsible for enabling ADI protection on it.


Do you mean that the application must be responsible?  Or the kernel
running in the context of the new process must be responsible?


It is also a copy of what was ADI protected data, so should it
inherit the protection instead?


I think the COW'd copy must inherit the VMA bit, the PTE bits, and the
tags on the cachelines.


I misspoke earlier. I had misinterpreted the results of test I ran.
Changing the tag on shared memory is allowed by memory controller.
The
requirement is every one sharing the page must switch to the new
tag or
else they get SIGSEGV.


I asked this in the last mail, but I guess I'll ask it again. Please
answer this directly.

If we require that everyone coordinate their tags on the backing
physical memory, and we allow a lower-privileged program to access the
same data as a more-privileged one, then the lower-privilege app can
cause arbitrary crashes in the privileged application.

For instance, say sudo mmap()'s /etc/passwd and uses ADI tags to
protect
the mapping.  Couldn't any other app in the system prevent sudo from
working?

How can we *EVER* allow tags to be set on non-writable mappings?


I don't think you can write a tag to memory if you don't have write
access in the TTE. Writing a tag requires a store instruction, and if
the machine is at all sane, this will fault if you don't have write
access.



But could you have mmap'd the file writable, set the tags and then
changed the protection on memory to read-only? That would be the
logical way to ADI protect a memory being used to mmap a file. Right?



Sure, if you have write access to begin with, you can set memory
versions, then remove write access to the page. But I think the point is
that if a process doesn't have write access, and cannot get it, then it
will not ever be able to change memory versions. So in the example of a
non-root process opening /etc/passwd (read only), and mmaping it, the
mapping would be read-only as well. Personally I don't really see a use
case for ADI on memory mapped to a file. In an abstract sense, the
"backing store" for a memory mapped file is the file itself on disk, not
physical memory. And there is already a way to restrict access to files,
so perhaps ADI should simply be disallowed for memory mapped to files,
and this particular complication can be avoided. Thoughts?


Hi Rob,

That is a good way to look at it. Memory mapped files already have a 
protection mechanism in place.




Incidentally, I see ADI as primarily a way to protect memory from
improper access within a process or group of cooperating processes.
There is already a way to protect memory from unrelated processes, and
if that is circumvented somehow, then ADI won't help at all. Perhaps we
should stop talking about ADI as a "security" feature; It does add a
layer of protection against buffer overflow attacks, but this attack
only exists when there is a bug in the underlying application. If an
attacker gains access to the virtual memory for a process, then nothing
can help you.



That does make sense. Looking at ADI as a mechanism to prevent 
unintended improper access to memory through buffer overflow or other 
mechanism, would it still make sense to support ADI tags on mmap'd files 
within the group of cooperating processes? Say we have a process that 
mmap's a large file and then forks off a bunch of children that process 
smaller segments of that file. We would want to make sure these children 
do not step over each other's segments of the file due to programming 
flaw or compromise. Parent process could tag each segment with a 
different tag and give one tag to each child process.


I want to be sure we are not shutting down potential useful applications 
of ADI before we choose to not support ADI with memory mapped files.


I appreciate your input.

Thanks,
Khalid



Rob




--
Khalid


Rob





I understand your quetion better now. That is a very valid concern.
Using ADI tags to prevent an unauthorized process from just reading
data in memory, say an in-memory copy of database, is one of the use
cases for ADI. This means 

[no subject]

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[no subject]

[David Howells]

Nicolas Dichtel  wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7

[Khalid Aziz]

On 01/12/2017 06:31 PM, Rob Gardner wrote:

On 01/12/2017 05:22 PM, Khalid Aziz wrote:

On 01/12/2017 10:53 AM, Dave Hansen wrote:

On 01/12/2017 08:50 AM, Khalid Aziz wrote:

2. Any shared page that has ADI protection enabled on it, must stay ADI
protected across all processes sharing it.


Is that true?

What happens if a page with ADI tags set is accessed via a PTE without
the ADI enablement bit set?


ADI protection applies across all processes in terms of all of them
must use the same tag to access the shared memory, but if a process
accesses a shared page with TTE.mcde bit cleared, access will be granted.




COW creates an intersection of the two. It creates a new copy of the
shared data. It is a new data page and hence the process creating it
must be the one responsible for enabling ADI protection on it.


Do you mean that the application must be responsible?  Or the kernel
running in the context of the new process must be responsible?


It is also a copy of what was ADI protected data, so should it
inherit the protection instead?


I think the COW'd copy must inherit the VMA bit, the PTE bits, and the
tags on the cachelines.


I misspoke earlier. I had misinterpreted the results of test I ran.
Changing the tag on shared memory is allowed by memory controller. The
requirement is every one sharing the page must switch to the new tag or
else they get SIGSEGV.


I asked this in the last mail, but I guess I'll ask it again. Please
answer this directly.

If we require that everyone coordinate their tags on the backing
physical memory, and we allow a lower-privileged program to access the
same data as a more-privileged one, then the lower-privilege app can
cause arbitrary crashes in the privileged application.

For instance, say sudo mmap()'s /etc/passwd and uses ADI tags to protect
the mapping.  Couldn't any other app in the system prevent sudo from
working?

How can we *EVER* allow tags to be set on non-writable mappings?


I don't think you can write a tag to memory if you don't have write
access in the TTE. Writing a tag requires a store instruction, and if
the machine is at all sane, this will fault if you don't have write access.



But could you have mmap'd the file writable, set the tags and then 
changed the protection on memory to read-only? That would be the logical 
way to ADI protect a memory being used to mmap a file. Right?


--
Khalid


Rob





I understand your quetion better now. That is a very valid concern.
Using ADI tags to prevent an unauthorized process from just reading
data in memory, say an in-memory copy of database, is one of the use
cases for ADI. This means there is a reasonable case to allow enabling
ADI and setting tags even on non-writable mappings. On the other hand,
if an unauthorized process manages to map the right memory pages in
its address space, it can read them any way by not setting TTE.mcd.

Userspace app can set tag on any memory it has mapped in without
requiring assistance from kernel. Can this problem be solved by not
allowing setting TTE.mcd on non-writable mappings? Doesn't the same
problem occur on writable mappings? If a privileged process mmap()'s a
writable file with MAP_SHARED, enables ADI and sets tag on the mmap'd
memory region, then another lower privilege process mmap's the same
file writable (assuming file permissions allow it to), enables ADI and
sets a different tag on it, the privileged process would get SIGSEGV
when it tries to access the mmap'd file. Right?




--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix documentation warnings

[Johannes Berg]

On Fri, 2017-01-13 at 13:43 +0100, Markus Heiser wrote:

> does it make live easier when we use in-line member comments:
> 
>  https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#in-
> line-member-documentation-comments
> 
> and place the entire list in a literalblock? 

Ah yes, I forgot about that. I should convert everything to that, but
that's probably better done separately.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/8] nios2: put setup.h in uapi

[Tobias Klauser]

On 2017-01-13 at 11:46:41 +0100, Nicolas Dichtel  
wrote:
> This header file is exported, but from a userland pov, it's just a wrapper
> to asm-generic/setup.h.
> 
> Signed-off-by: Nicolas Dichtel 

Reviewed-by: Tobias Klauser 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/8] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Here is the v3 of this series. The first 5 patches are just cleanup: some
exported headers were still under a non-uapi directory or (x86 case) were
wrongly exported.
The patch 6 was spotted by code review: there is no in-tree user of this
functionality.
Patches 7 and 8 remove the need to list explicitly headers. Now all files
under an uapi directory are exported.

This series has been tested with a 'make headers_install' on x86 and a
'make headers_install_all'. I've checked the result of both commands.

This patch is built against linus tree. If I must rebase it against the kbuild
tree, just tell me ;-)

v2 -> v3:
 - patch #1: remove arch/arm/include/asm/types.h
 - patch #2: remove arch/h8300/include/asm/bitsperlong.h
 - patch #3: remove arch/nios2/include/uapi/asm/setup.h
 - patch #4: don't export msr-index.h
 - patch #5: fix a typo: s/unput-files3-name/input-files3-name
 - patch #6: no change
 - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y
 - add patch #8

v1 -> v2:
 - add patch #1 to #6
 - patch #7: remove use of header-y

Comments are welcomed,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 6/8] Makefile.headersinst: remove destination-y option

[Nicolas Dichtel]

This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y
for exported headers") but never used in-tree.

Signed-off-by: Nicolas Dichtel 
---
 Documentation/kbuild/makefiles.txt | 23 ---
 scripts/Makefile.headersinst   |  2 +-
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 9b9c4797fc55..37b525d329ae 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -46,9 +46,8 @@ This document describes the Linux kernel Makefiles.
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 genhdr-y
-   --- 7.3 destination-y
-   --- 7.4 generic-y
-   --- 7.5 generated-y
+   --- 7.3 generic-y
+   --- 7.4 generated-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1295,21 +1294,7 @@ See subsequent chapter for the syntax of the Kbuild file.
#include/linux/Kbuild
genhdr-y += version.h
 
-   --- 7.3 destination-y
-
-   When an architecture has a set of exported headers that needs to be
-   exported to a different directory destination-y is used.
-   destination-y specifies the destination directory for all exported
-   headers in the file where it is present.
-
-   Example:
-   #arch/xtensa/platforms/s6105/include/platform/Kbuild
-   destination-y := include/linux
-
-   In the example above all exported headers in the Kbuild file
-   will be located in the directory "include/linux" when exported.
-
-   --- 7.4 generic-y
+   --- 7.3 generic-y
 
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
@@ -1336,7 +1321,7 @@ See subsequent chapter for the syntax of the Kbuild file.
Example: termios.h
#include 
 
-   --- 7.5 generated-y
+   --- 7.4 generated-y
 
If an architecture generates other header files alongside generic-y
wrappers, and not included in genhdr-y, then generated-y specifies
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 3e20d03432d2..876b42cfede4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -14,7 +14,7 @@ kbuild-file := $(srctree)/$(obj)/Kbuild
 include $(kbuild-file)
 
 # called may set destination dir (when installing to asm/)
-_dst := $(if $(destination-y),$(destination-y),$(if $(dst),$(dst),$(obj)))
+_dst := $(if $(dst),$(dst),$(obj))
 
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/8] h8300: put bitsperlong.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel 
---
 arch/h8300/include/asm/bitsperlong.h  | 14 --
 arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++
 2 files changed, 14 insertions(+), 14 deletions(-)
 delete mode 100644 arch/h8300/include/asm/bitsperlong.h
 create mode 100644 arch/h8300/include/uapi/asm/bitsperlong.h

diff --git a/arch/h8300/include/asm/bitsperlong.h 
b/arch/h8300/include/asm/bitsperlong.h
deleted file mode 100644
index e140e46729ac..
--- a/arch/h8300/include/asm/bitsperlong.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __ASM_H8300_BITS_PER_LONG
-#define __ASM_H8300_BITS_PER_LONG
-
-#include 
-
-#if !defined(__ASSEMBLY__)
-/* h8300-unknown-linux required long */
-#define __kernel_size_t __kernel_size_t
-typedef unsigned long  __kernel_size_t;
-typedef long   __kernel_ssize_t;
-typedef long   __kernel_ptrdiff_t;
-#endif
-
-#endif /* __ASM_H8300_BITS_PER_LONG */
diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
b/arch/h8300/include/uapi/asm/bitsperlong.h
new file mode 100644
index ..e56cf72369b6
--- /dev/null
+++ b/arch/h8300/include/uapi/asm/bitsperlong.h
@@ -0,0 +1,14 @@
+#ifndef _UAPI_ASM_H8300_BITS_PER_LONG
+#define _UAPI_ASM_H8300_BITS_PER_LONG
+
+#include 
+
+#if !defined(__ASSEMBLY__)
+/* h8300-unknown-linux required long */
+#define __kernel_size_t __kernel_size_t
+typedef unsigned long  __kernel_size_t;
+typedef long   __kernel_ssize_t;
+typedef long   __kernel_ptrdiff_t;
+#endif
+
+#endif /* _UAPI_ASM_H8300_BITS_PER_LONG */
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 8/8] uapi: export all arch specifics directories

[Nicolas Dichtel]

This patch removes the need of subdir-y. Now all files/directories under
arch//include/uapi/ are exported.

The only change for userland is the layout of the command 'make
headers_install_all': directories asm- are replaced by arch-/.
Those new directories contains all files/directories of the specified arch.

Note that only cris and tile have more directories than only asm:
 - arch-v[10|32] for cris;
 - arch for tile.

Signed-off-by: Nicolas Dichtel 
---
 Documentation/kbuild/makefiles.txt | 15 +--
 Makefile   |  4 ++--
 arch/cris/include/uapi/asm/Kbuild  |  3 ---
 arch/tile/include/uapi/asm/Kbuild  |  2 --
 scripts/Makefile.headersinst   |  3 +--
 5 files changed, 4 insertions(+), 23 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt 
b/Documentation/kbuild/makefiles.txt
index 51c072049e45..87a3d7d86776 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -48,7 +48,6 @@ This document describes the Linux kernel Makefiles.
--- 7.2 genhdr-y
--- 7.3 generic-y
--- 7.4 generated-y
-   --- 7.5 subdir-y
 
=== 8 Kbuild Variables
=== 9 Makefile language
@@ -1264,7 +1263,7 @@ The pre-processing does:
 - drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
 
 All headers under include/uapi/, include/generated/uapi/,
-arch//include/uapi/asm/ and arch//include/generated/uapi/asm/
+arch//include/uapi/ and arch//include/generated/uapi/
 are exported.
 
 A Kbuild file may be defined under arch//include/uapi/asm/ and
@@ -1331,18 +1330,6 @@ See subsequent chapter for the syntax of the Kbuild file.
#arch/x86/include/asm/Kbuild
generated-y += syscalls_32.h
 
-   --- 7.5 subdir-y
-
-   subdir-y may be used to specify a subdirectory to be exported.
-
-   Example:
-   #arch/cris/include/uapi/asm/Kbuild
-   subdir-y += ../arch-v10/arch/
-   subdir-y += ../arch-v32/arch/
-
-   The convention is to list one subdir per line and
-   preferably in alphabetic order.
-
 === 8 Kbuild Variables
 
 The top Makefile exports the following variables:
diff --git a/Makefile b/Makefile
index 5f1a84735ff6..a35098157b69 100644
--- a/Makefile
+++ b/Makefile
@@ -1126,7 +1126,7 @@ firmware_install:
 export INSTALL_HDR_PATH = $(objtree)/usr
 
 # If we do an all arch process set dst to asm-$(hdr-arch)
-hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
+hdr-dst = $(if $(KBUILD_HEADERS), dst=include/arch-$(hdr-arch), dst=include)
 
 PHONY += archheaders
 archheaders:
@@ -1147,7 +1147,7 @@ headers_install: __headers
$(if $(wildcard $(srctree)/arch/$(hdr-arch)/include/uapi/asm/Kbuild),, \
  $(error Headers not exportable for the $(SRCARCH) architecture))
$(Q)$(MAKE) $(hdr-inst)=include/uapi
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst)
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi $(hdr-dst)
 
 PHONY += headers_check_all
 headers_check_all: headers_install_all
diff --git a/arch/cris/include/uapi/asm/Kbuild 
b/arch/cris/include/uapi/asm/Kbuild
index d0c5471856e0..b15bf6bc0e94 100644
--- a/arch/cris/include/uapi/asm/Kbuild
+++ b/arch/cris/include/uapi/asm/Kbuild
@@ -1,5 +1,2 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
-
-subdir-y += ../arch-v10/arch/
-subdir-y += ../arch-v32/arch/
diff --git a/arch/tile/include/uapi/asm/Kbuild 
b/arch/tile/include/uapi/asm/Kbuild
index e0a50111e07f..0c74c3c5ebfa 100644
--- a/arch/tile/include/uapi/asm/Kbuild
+++ b/arch/tile/include/uapi/asm/Kbuild
@@ -2,5 +2,3 @@
 include include/uapi/asm-generic/Kbuild.asm
 
 generic-y += ucontext.h
-
-subdir-y += ../arch
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 16ac3e71050e..cafaca2d9a23 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -2,7 +2,7 @@
 # Installing headers
 #
 # All headers under include/uapi, include/generated/uapi,
-# arch//include/uapi/asm and arch//include/generated/uapi/asm are
+# arch//include/uapi and arch//include/generated/uapi are
 # exported.
 # They are preprocessed to remove __KERNEL__ section of the file.
 #
@@ -28,7 +28,6 @@ include scripts/Kbuild.include
 installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 
 subdirs   := $(patsubst $(srctree)/$(obj)/%/.,%,$(wildcard 
$(srctree)/$(obj)/*/.))
-subdirs   += $(subdir-y)
 header-files  := $(notdir $(wildcard $(srctree)/$(obj)/*.h))
 header-files  += $(notdir $(wildcard $(srctree)/$(obj)/*.agh))
 genhdr-files  := $(notdir $(wildcard $(srctree)/$(gen)/*.h))
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/8] nios2: put setup.h in uapi

[Nicolas Dichtel]

This header file is exported, but from a userland pov, it's just a wrapper
to asm-generic/setup.h.

Signed-off-by: Nicolas Dichtel 
---
 arch/nios2/include/uapi/asm/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nios2/include/uapi/asm/Kbuild 
b/arch/nios2/include/uapi/asm/Kbuild
index e0bb972a50d7..69c965304146 100644
--- a/arch/nios2/include/uapi/asm/Kbuild
+++ b/arch/nios2/include/uapi/asm/Kbuild
@@ -2,4 +2,5 @@ include include/uapi/asm-generic/Kbuild.asm
 
 header-y += elf.h
 
+generic-y += setup.h
 generic-y += ucontext.h
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 7/8] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Regularly, when a new header is created in include/uapi/, the developer
forgets to add it in the corresponding Kbuild file. This error is usually
detected after the release is out.

In fact, all headers under uapi directories should be exported, thus it's
useless to have an exhaustive list.

After this patch, the following files, which were not exported, are now
exported (with make headers_install_all):
asm-unicore32/shmparam.h
asm-unicore32/ucontext.h
asm-hexagon/shmparam.h
asm-mips/ucontext.h
asm-mips/hwcap.h
asm-mips/reg.h
drm/vgem_drm.h
drm/armada_drm.h
drm/omap_drm.h
drm/etnaviv_drm.h
asm-tile/shmparam.h
asm-blackfin/shmparam.h
asm-blackfin/ucontext.h
asm-powerpc/perf_regs.h
rdma/qedr-abi.h
asm-parisc/kvm_para.h
asm-openrisc/shmparam.h
.install
asm-nios2/kvm_para.h
asm-nios2/ucontext.h
asm-sh/kvm_para.h
asm-sh/ucontext.h
asm-xtensa/kvm_para.h
asm-avr32/kvm_para.h
asm-m32r/kvm_para.h
asm-h8300/shmparam.h
asm-h8300/ucontext.h
asm-metag/kvm_para.h
asm-metag/shmparam.h
asm-metag/ucontext.h
asm-m68k/kvm_para.h
asm-m68k/shmparam.h
linux/bcache.h
linux/kvm.h
linux/kvm_para.h
linux/kfd_ioctl.h
linux/cryptouser.h
linux/kcm.h
linux/kcov.h
linux/seg6_iptunnel.h
linux/stm.h
linux/genwqe
linux/genwqe/.install
linux/genwqe/genwqe_card.h
linux/genwqe/..install.cmd
linux/seg6.h
linux/cifs
linux/cifs/.install
linux/cifs/cifs_mount.h
linux/cifs/..install.cmd
linux/auto_dev-ioctl.h
linux/userio.h
linux/pr.h
linux/wil6210_uapi.h
linux/a.out.h
linux/nilfs2_ondisk.h
linux/hash_info.h
linux/seg6_genl.h
linux/seg6_hmac.h
linux/batman_adv.h
linux/nsfs.h
linux/qrtr.h
linux/btrfs_tree.h
linux/coresight-stm.h
linux/dma-buf.h
linux/module.h
linux/lightnvm.h
linux/nilfs2_api.h
asm-cris/kvm_para.h
asm-arc/kvm_para.h
asm-arc/ucontext.h
..install.cmd
asm-c6x/shmparam.h
asm-c6x/ucontext.h

Thanks to Julien Floret  for the tip to get all
subdirs with a pure makefile command.

For the record, note that exported files for asm directories are a mix of
files listed by:
 - include/uapi/asm-generic/Kbuild.asm;
 - arch//include/uapi/asm/Kbuild;
 - arch//include/asm/Kbuild.

Signed-off-by: Nicolas Dichtel 
Acked-by: Daniel Vetter 
Acked-by: Russell King 
Acked-by: Mark Salter 
---
 Documentation/kbuild/makefiles.txt  |  55 ++--
 arch/alpha/include/uapi/asm/Kbuild  |  41 ---
 arch/arc/include/uapi/asm/Kbuild|   3 -
 arch/arm/include/uapi/asm/Kbuild|  17 -
 arch/arm64/include/uapi/asm/Kbuild  |  18 --
 arch/avr32/include/uapi/asm/Kbuild  |  20 --
 arch/blackfin/include/uapi/asm/Kbuild   |  17 -
 arch/c6x/include/uapi/asm/Kbuild|   8 -
 arch/cris/include/uapi/arch-v10/arch/Kbuild |   5 -
 arch/cris/include/uapi/arch-v32/arch/Kbuild |   3 -
 arch/cris/include/uapi/asm/Kbuild   |  43 +--
 arch/frv/include/uapi/asm/Kbuild|  33 --
 arch/h8300/include/uapi/asm/Kbuild  |  28 --
 arch/hexagon/include/asm/Kbuild |   3 -
 arch/hexagon/include/uapi/asm/Kbuild|  13 -
 arch/ia64/include/uapi/asm/Kbuild   |  45 ---
 arch/m32r/include/uapi/asm/Kbuild   |  31 --
 arch/m68k/include/uapi/asm/Kbuild   |  24 --
 arch/metag/include/uapi/asm/Kbuild  |   8 -
 arch/microblaze/include/uapi/asm/Kbuild |  32 --
 arch/mips/include/uapi/asm/Kbuild   |  37 ---
 arch/mn10300/include/uapi/asm/Kbuild|  32 --
 arch/nios2/include/uapi/asm/Kbuild  |   3 +-
 arch/openrisc/include/asm/Kbuild|   3 -
 arch/openrisc/include/uapi/asm/Kbuild   |   8 -
 arch/parisc/include/uapi/asm/Kbuild |  28 --
 arch/powerpc/include/uapi/asm/Kbuild|  45 ---
 arch/s390/include/uapi/asm/Kbuild   |  52 ---
 arch/score/include/asm/Kbuild   |   4 -
 arch/score/include/uapi/asm/Kbuild  |  32 --
 arch/sh/include/uapi/asm/Kbuild |  23 --
 arch/sparc/include/uapi/asm/Kbuild  |  48 ---
 arch/tile/include/asm/Kbuild|   3 -
 arch/tile/include/uapi/arch/Kbuild  |  17 -
 arch/tile/include/uapi/asm/Kbuild   |  19 +-
 arch/unicore32/include/uapi/asm/Kbuild  |   6 -
 arch/x86/include/uapi/asm/Kbuild|  58 
 arch/xtensa/include/uapi/asm/Kbuild |  23 --
 include/Kbuild  |   2 -
 include/asm-generic/Kbuild.asm  |   1 -
 include/scsi/fc/Kbuild  |   0
 include/uapi/Kbuild |  15 -
 include/uapi/asm-generic/Kbuild |  36 ---
 include/uapi/asm-generic/Kbuild.asm |  62 ++--
 include/uapi/drm/Kbuild |  22 --
 include/uapi/linux/Kbuild   | 483 
 include/uapi/linux/android/Kbuild   |   2 -
 include/uapi/linux/byteorder/Kbuild |   3 -
 include/uapi/linux/caif/Kbuild  |   3 -
 include/uapi/linux/can/Kbuild 

[PATCH v3 5/8] Makefile.headersinst: cleanup input files

[Nicolas Dichtel]

After the last four patches, all exported headers are under uapi/, thus
input-files2 are not needed anymore.
The side effect is that input-files1-name is exactly header-y.

Note also that input-files3-name is genhdr-y.

Signed-off-by: Nicolas Dichtel 
---
 scripts/Makefile.headersinst | 34 +++---
 1 file changed, 11 insertions(+), 23 deletions(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 1106d6ca3a38..3e20d03432d2 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -40,31 +40,20 @@ wrapper-files := $(filter $(header-y), $(generic-y))
 srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
 
-oldsrcdir := $(srctree)/$(subst /uapi,,$(obj))
-
 # all headers files for this dir
 header-y  := $(filter-out $(generic-y), $(header-y))
 all-files := $(header-y) $(genhdr-y) $(wrapper-files)
 output-files  := $(addprefix $(installdir)/, $(all-files))
 
-input-files1  := $(foreach hdr, $(header-y), \
-  $(if $(wildcard $(srcdir)/$(hdr)), \
-   $(wildcard $(srcdir)/$(hdr))) \
-  )
-input-files1-name := $(notdir $(input-files1))
-input-files2  := $(foreach hdr, $(header-y), \
-  $(if  $(wildcard $(srcdir)/$(hdr)),, \
-   $(if $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(wildcard $(oldsrcdir)/$(hdr)), \
-   $(error Missing UAPI file $(srcdir)/$(hdr))) \
-  ))
-input-files2-name := $(notdir $(input-files2))
-input-files3  := $(foreach hdr, $(genhdr-y), \
-  $(if $(wildcard $(gendir)/$(hdr)), \
-   $(wildcard $(gendir)/$(hdr)), \
-   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
-  ))
-input-files3-name := $(notdir $(input-files3))
+# Check that all expected files exist
+$(foreach hdr, $(header-y), \
+  $(if $(wildcard $(srcdir)/$(hdr)),, \
+   $(error Missing UAPI file $(srcdir)/$(hdr)) \
+   ))
+$(foreach hdr, $(genhdr-y), \
+  $(if $(wildcard $(gendir)/$(hdr)),, \
+   $(error Missing generated UAPI file $(gendir)/$(hdr)) \
+  ))
 
 # Work out what needs to be removed
 oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h))
@@ -78,9 +67,8 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@))
 quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
 file$(if $(word 2, $(all-files)),s))
   cmd_install = \
-$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(input-files1-name); \
-$(CONFIG_SHELL) $< $(installdir) $(oldsrcdir) $(input-files2-name); \
-$(CONFIG_SHELL) $< $(installdir) $(gendir) $(input-files3-name); \
+$(CONFIG_SHELL) $< $(installdir) $(srcdir) $(header-y); \
+$(CONFIG_SHELL) $< $(installdir) $(gendir) $(genhdr-y); \
 for F in $(wrapper-files); do   \
 echo "\#include " > $(installdir)/$$F;\
 done;   \
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Nicolas Dichtel]

Suggested-by: Borislav Petkov 
Signed-off-by: Nicolas Dichtel 
---
 arch/x86/include/uapi/asm/Kbuild | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/Kbuild b/arch/x86/include/uapi/asm/Kbuild
index 3dec769cadf7..1c532b3f18ea 100644
--- a/arch/x86/include/uapi/asm/Kbuild
+++ b/arch/x86/include/uapi/asm/Kbuild
@@ -27,7 +27,6 @@ header-y += ldt.h
 header-y += mce.h
 header-y += mman.h
 header-y += msgbuf.h
-header-y += msr-index.h
 header-y += msr.h
 header-y += mtrr.h
 header-y += param.h
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: fix documentation warnings

[Johannes Berg]

From: Johannes Berg 

For a few restructured text warnings in mac80211, making the
documentation warning-free (for now). Again, this required
adding trailing whitespace to keep multiple paragraphs in a
parameter description together.

Signed-off-by: Johannes Berg 
---
 include/net/mac80211.h | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 86967b85dfd0..228c72617916 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1771,10 +1771,12 @@ struct ieee80211_sta_rates {
  * @max_amsdu_len: indicates the maximal length of an A-MSDU in bytes. This
  * field is always valid for packets with a VHT preamble. For packets
  * with a HT preamble, additional limits apply:
- * + If the skb is transmitted as part of a BA agreement, the
- *   A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
- * + If the skb is not part of a BA aggreement, the A-MSDU maximal
- *   size is min(max_amsdu_len, 7935) bytes.
+ * 
+ * * If the skb is transmitted as part of a BA agreement, the
+ *   A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
+ * * If the skb is not part of a BA aggreement, the A-MSDU maximal
+ *   size is min(max_amsdu_len, 7935) bytes.
+ * 
  * Both additional HT limits must be enforced by the low level driver.
  * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
  * @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
@@ -3212,14 +3214,20 @@ enum ieee80211_reconfig_type {
  * nor send aggregates in a way that lost frames would exceed the
  * buffer size. If just limiting the aggregate size, this would be
  * possible with a buf_size of 8:
- *  - TX: 1.7
- *  - RX:  27 (lost frame #1)
- *  - TX:8..1...
+ * 
+ * - ``TX: 1.7``
+ * - ``RX:  27`` (lost frame #1)
+ * - ``TX:8..1...``
+ * 
  * which is invalid since #1 was now re-transmitted well past the
  * buffer size of 8. Correct ways to retransmit #1 would be:
- *  - TX:   1 or 18 or 81
- * Even "189" would be wrong since 1 could be lost again.
- *
+ * 
+ * - ``TX:1   or``
+ * - ``TX:18  or``
+ * - ``TX:81``
+ * 
+ * Even ``189`` would be wrong since 1 could be lost again.
+ * 
  * Returns a negative error code on failure.
  * The callback can sleep.
  *
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] watchdog: introduce watchdog.open_timeout commandline parameter

[Rasmus Villemoes]

On 2017-01-11 12:02, Guenter Roeck wrote:
> On 01/11/2017 12:11 AM, Rasmus Villemoes wrote:
>> On 2017-01-10 19:08, Guenter Roeck wrote:
>>> On Mon, Jan 09, 2017 at 04:02:32PM +0100, Rasmus Villemoes wrote:

 +static unsigned open_timeout;
 +module_param(open_timeout, uint, 0644);
 +
 +static bool watchdog_past_open_deadline(struct watchdog_core_data
 *data)
 +{
 +if (!open_timeout)
 +return false;
 +return time_is_before_jiffies(data->open_deadline);
>>>
>>> Doesn't this return true if the time is _before_ the open deadline ?
>>> Should it be time_is_after_jiffies() ?
>>
>> Yes, time_is_before_jiffies(foo) means foo < jiffies, and that is what
>> we want when we're querying whether we've passed the deadline.
>>
> So you want the function to return true if the timeout has _not_ expired ?

No, I want it to return true if the timeout has expired, just as its
name hopefully suggests ("are we now past the deadline for opening").

time_is_before_jiffies(foo) expands to time_after(jiffies, foo), which
in turn expands to (aside from some type checking)

(long)((foo) - (jiffies)) < 0

which is true precisely when jiffies > foo, i.e., when the current time
is later than foo. [Yes, just as every other user of the time_* helpers
this only works if the times being compared are within LONG_MAX jiffies
of each other.]

> 
> [ Can you try to work with line wraps ? ]

Sorry about that, I hope I've now managed to make Thunderbird not mess
it up.

> Uuh, no. I didn't realize that you apply that case to the "userspace app
> gracefully
> closes the watchdog device" case as well. This is clearly a separate use
> case.
> 
> Looks like there are now three use cases for 'open timeout'.
> - time after boot
> - timer after loading the watchdog device
> - time after closing watchdog device and before reopening it
> 
> I would have thought the first use case is the important one, and the
> other ones are,
> at best, secondary. Given that, we are clearly not there yet. This will
> require input
> from others on the semantics.

I agree, it would be nice to have others chime in on whether they'd even
find this useful, and what semantics they'd like.

But for the record, for us, both the "time after boot" and "time after
closing" are important use cases. In practice, approximating boot time
with time of first registration effectively just pushes the deadline a
little further out, which I think is acceptable (boot time anyway means
"when timekeeping began", and even when the deadline is passed, it takes
up to whatever the hardware is configured to before the board actually
resets, so there's already some slack involved). If one really wants to
measure with respect to boot time, I think one can just make
set_open_deadline take an additional "from" parameter, passing
INITIAL_JIFFIES from watchdog_cdev_register and jiffies from
watchdog_release.

(That won't work for the hotplug case, but please ignore that; it was a
bad example, and certainly not a use case we actually have in mind).


Thanks,
Rasmus


-- 
Rasmus Villemoes
Software Developer
Prevas A/S
Hedeager 1
DK-8200 Aarhus N
+45 51210274
rasmus.villem...@prevas.dk
www.prevas.dk
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html