[PATCH] documentation: fix broken lkml archive links in RCU requirements

[Michael Opdenacker]

Fix 4 LKML archive links that became broken (data loss
on mail-archive.com?)

Working links were found on Paul McKenney's RCU articles
on LWN.net, from which the documentation originates:
http://lwn.net/Articles/652156/
http://lwn.net/Articles/652677/
http://lwn.net/Articles/653326/

Signed-off-by: Michael Opdenacker 
---
 Documentation/RCU/Design/Requirements/Requirements.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
b/Documentation/RCU/Design/Requirements/Requirements.html
index ece410f40436..2adb3d43ce44 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -1527,7 +1527,7 @@ However, as I learned from Matt Mackall's
 http://elinux.org/Linux_Tiny-FAQ;>bloatwatch
 efforts, memory footprint is critically important on single-CPU systems with
 non-preemptible (CONFIG_PREEMPT=n) kernels, and thus
-https://lkml.kernel.org/g/20090113221724.ga15...@linux.vnet.ibm.com;>tiny 
RCU
+http://lkml.org/lkml/2009/1/14/449;>tiny RCU
 was born.
 Josh Triplett has since taken over the small-memory banner with his
 https://tiny.wiki.kernel.org/;>Linux kernel tinification
@@ -1975,7 +1975,7 @@ guard against mishaps and misuse:
and cleaned up with destroy_rcu_head().
Mathieu Desnoyers made me aware of this requirement, and also
supplied the needed
-   https://lkml.kernel.org/g/20100319013024.GA28456@Krystal;>patch.
+   https://lkml.org/lkml/2010/3/18/417;>patch.
An infinite loop in an RCU read-side critical section will
eventually trigger an RCU CPU stall warning splat, with
the duration of eventually being controlled by the
@@ -2088,7 +2088,7 @@ be hidden behind a CONFIG_RCU_EXPERT 
Kconfig option.
 
 This all should be quite obvious, but the fact remains that
 Linus Torvalds recently had to
-https://lkml.kernel.org/g/ca+55afy4wccwal4okts8wxhgz5h-ibecy_meg9c4mnqrunw...@mail.gmail.com;>remind
+https://lkml.org/lkml/2015/4/14/616;>remind
 me of this requirement.
 
 Firmware Interface
@@ -2229,7 +2229,7 @@ Thankfully, RCU update-side primitives, including
 The name notwithstanding, some Linux-kernel architectures
 can have nested NMIs, which RCU must handle correctly.
 Andy Lutomirski
-https://lkml.kernel.org/g/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com;>surprised
 me
+https://lkml.org/lkml/2014/11/21/642;>surprised me
 with this requirement;
 he also kindly surprised me with
 https://lkml.kernel.org/g/CALCETrXSY9JpW3uE6H8WYk81sg56qasA2aqmjMPsq5dOtzso=g...@mail.gmail.com;>an
 algorithm
-- 
2.7.4

--
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: fix broken lkml archive links in RCU requirements

[Richard Weinberger]

Michael,

On Fri, Sep 9, 2016 at 3:43 PM, Michael Opdenacker
 wrote:
> Fix 4 LKML archive links that became broken (data loss
> on mail-archive.com?)
>
> Working links were found on Paul McKenney's RCU articles
> on LWN.net, from which the documentation originates:
> http://lwn.net/Articles/652156/
> http://lwn.net/Articles/652677/
> http://lwn.net/Articles/653326/
>
> Signed-off-by: Michael Opdenacker 
> ---
>  Documentation/RCU/Design/Requirements/Requirements.html | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> b/Documentation/RCU/Design/Requirements/Requirements.html
> index ece410f40436..2adb3d43ce44 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.html
> +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> @@ -1527,7 +1527,7 @@ However, as I learned from Matt Mackall's
>  http://elinux.org/Linux_Tiny-FAQ;>bloatwatch
>  efforts, memory footprint is critically important on single-CPU systems with
>  non-preemptible (CONFIG_PREEMPT=n) kernels, and thus
> - href="https://lkml.kernel.org/g/20090113221724.ga15...@linux.vnet.ibm.com;>tiny
>  RCU
> +http://lkml.org/lkml/2009/1/14/449;>tiny RCU
>  was born.
>  Josh Triplett has since taken over the small-memory banner with his
>  https://tiny.wiki.kernel.org/;>Linux kernel tinification
> @@ -1975,7 +1975,7 @@ guard against mishaps and misuse:
> and cleaned up with destroy_rcu_head().
> Mathieu Desnoyers made me aware of this requirement, and also
> supplied the needed
> -href="https://lkml.kernel.org/g/20100319013024.GA28456@Krystal;>patch.
> +   https://lkml.org/lkml/2010/3/18/417;>patch.

Please don't add lkml.org. It does not use message ids for indexing.
With knowing the message id you can query any other archive.
e.g. http://marc.info/?i=20100319013024.GA28456@Krystal
By adding lkml.org you kill that information. Archives come and go,
the message id is the only common query id we have.

IMHO kernel.org admins should fix/improve their redirection service to
point to a working service.

-- 
Thanks,
//richard
--
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: fix broken lkml archive links in RCU requirements

[Paul E. McKenney]

On Fri, Sep 09, 2016 at 04:17:14PM +0200, Richard Weinberger wrote:
> Michael,
> 
> On Fri, Sep 9, 2016 at 3:43 PM, Michael Opdenacker
>  wrote:
> > Fix 4 LKML archive links that became broken (data loss
> > on mail-archive.com?)
> >
> > Working links were found on Paul McKenney's RCU articles
> > on LWN.net, from which the documentation originates:
> > http://lwn.net/Articles/652156/
> > http://lwn.net/Articles/652677/
> > http://lwn.net/Articles/653326/
> >
> > Signed-off-by: Michael Opdenacker 
> > ---
> >  Documentation/RCU/Design/Requirements/Requirements.html | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> > b/Documentation/RCU/Design/Requirements/Requirements.html
> > index ece410f40436..2adb3d43ce44 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -1527,7 +1527,7 @@ However, as I learned from Matt Mackall's
> >  http://elinux.org/Linux_Tiny-FAQ;>bloatwatch
> >  efforts, memory footprint is critically important on single-CPU systems 
> > with
> >  non-preemptible (CONFIG_PREEMPT=n) kernels, and thus
> > - > href="https://lkml.kernel.org/g/20090113221724.ga15...@linux.vnet.ibm.com;>tiny
> >  RCU
> > +http://lkml.org/lkml/2009/1/14/449;>tiny RCU
> >  was born.
> >  Josh Triplett has since taken over the small-memory banner with his
> >  https://tiny.wiki.kernel.org/;>Linux kernel tinification
> > @@ -1975,7 +1975,7 @@ guard against mishaps and misuse:
> > and cleaned up with destroy_rcu_head().
> > Mathieu Desnoyers made me aware of this requirement, and also
> > supplied the needed
> > -> href="https://lkml.kernel.org/g/20100319013024.GA28456@Krystal;>patch.
> > +   https://lkml.org/lkml/2010/3/18/417;>patch.
> 
> Please don't add lkml.org. It does not use message ids for indexing.
> With knowing the message id you can query any other archive.
> e.g. http://marc.info/?i=20100319013024.GA28456@Krystal
> By adding lkml.org you kill that information. Archives come and go,
> the message id is the only common query id we have.
> 
> IMHO kernel.org admins should fix/improve their redirection service to
> point to a working service.

There has been some instability in the kernel.org redirection.  Right
now, the /r/ services seems to work, though as noted the /g/ does not.
Please report this to the Kernel.org administrators:

https://kernel.org/category/contact-us.html

Thanx, Paul

--
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: fix broken lkml archive links in RCU requirements

[Steven Rostedt]

On Fri, 9 Sep 2016 16:17:14 +0200
Richard Weinberger  wrote:

> > Signed-off-by: Michael Opdenacker 
> > ---
> >  Documentation/RCU/Design/Requirements/Requirements.html | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> > b/Documentation/RCU/Design/Requirements/Requirements.html
> > index ece410f40436..2adb3d43ce44 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -1527,7 +1527,7 @@ However, as I learned from Matt Mackall's
> >  http://elinux.org/Linux_Tiny-FAQ;>bloatwatch
> >  efforts, memory footprint is critically important on single-CPU systems 
> > with
> >  non-preemptible (CONFIG_PREEMPT=n) kernels, and thus
> > - > href="https://lkml.kernel.org/g/20090113221724.ga15...@linux.vnet.ibm.com;>tiny
> >  RCU
> > +http://lkml.org/lkml/2009/1/14/449;>tiny RCU
> >  was born.
> >  Josh Triplett has since taken over the small-memory banner with his
> >  https://tiny.wiki.kernel.org/;>Linux kernel tinification
> > @@ -1975,7 +1975,7 @@ guard against mishaps and misuse:
> > and cleaned up with destroy_rcu_head().
> > Mathieu Desnoyers made me aware of this requirement, and also
> > supplied the needed
> > -> href="https://lkml.kernel.org/g/20100319013024.GA28456@Krystal;>patch.
> > +   https://lkml.org/lkml/2010/3/18/417;>patch.  
> 
> Please don't add lkml.org. It does not use message ids for indexing.
> With knowing the message id you can query any other archive.
> e.g. http://marc.info/?i=20100319013024.GA28456@Krystal
> By adding lkml.org you kill that information. Archives come and go,
> the message id is the only common query id we have.
> 
> IMHO kernel.org admins should fix/improve their redirection service to
> point to a working service.
> 

Correct, we avoid any links to lkml.org at all costs. Simple do a

s,/g/,/r/, and all your links should work. For example, using the above
mentioned link:

 https://lkml.kernel.org/r/20100319013024.GA28456@Krystal

Works as expected.

-- Steve
--
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 v2 0/3] doc-rst:c-domain: fix some issues in the c-domain

[Markus Heiser]

Am 09.09.2016 um 14:08 schrieb Mauro Carvalho Chehab :

> Em Wed,  7 Sep 2016 09:12:55 +0200
> Markus Heiser  escreveu:
> 
>> From: Markus Heiser 
>> 
>> Hi Jon,
>> 
>> according to your remarks I fixed the first and second patch. The third 
>> patch is
>> resend unchanged;
>> 
>>> Am 06.09.2016 um 14:28 schrieb Jonathan Corbet :
>>> 
>>> As others have pointed out, we generally want to hide the difference
>>> between functions and macros, so this is probably one change we don't
>>> want.  
>> 
>> I read "probably", so there might be a chance to persuade you ;)
>> 
>> I'm not a friend of *information hiding* and since the index is sorted
>> alphabetical it does no matter if the entry is 'FOO (C function)' or 'FOO (C
>> macro)'. The last one has the right information e.g. for someone how is 
>> looking
>> for a macro. FOO is a function-like macro and not a function, if the author
>> describes the macro he might use the word "macro FOO" but in the index it is
>> tagged as C function.
>> 
>> Macros and functions are totally different even if their notation looks
>> similarly. So where is the benefit of entries like 'FOO (C function)', which 
>> is
>> IMHO ambiguous.
>> 
>> I tagged the 'function-like macros index entry' patch with 'RFC' and resend 
>> it
>> within this series. If you and/or others have a different opinion, feel free 
>> to
>> drop it.
>> 
>> Thanks for review.
>> 
>> -- Markus --
>> 
>> 
>> Markus Heiser (3):
>>  doc-rst:c-domain: fix sphinx version incompatibility
>>  doc-rst:c-domain: function-like macros arguments
>>  doc-rst:c-domain: function-like macros index entry
>> 
>> Documentation/sphinx/cdomain.py | 79 
>> +++--
>> 1 file changed, 76 insertions(+), 3 deletions(-)
>> 
> 
> Those patches indeed fix the issues. The arguments are now
> processed properly.
> 
> Tested-by: Mauro Carvalho Chehab 
> 
> ---
> 
> Using either this approach or my kernel-doc patch, I'm now getting
> only two warnings:
> 
> 1) at media-entity.h, even without nitpick mode:
> 
> ./include/media/media-entity.h:1053: warning: No description found for 
> parameter '...'
> 
> This is caused by this kernel-doc tag and the corresponding macro:
> 
>   /**
>* media_entity_call - Calls a struct media_entity_operations operation 
> on
>*  an entity
>*
>* @entity: entity where the @operation will be called
>* @operation: type of the operation. Should be the name of a member of
>*  struct _entity_operations.
>*
>* This helper function will check if @operation is not %NULL. On such 
> case,
>* it will issue a call to @operation\(@entity, @args\).
>*/
> 
>   #define media_entity_call(entity, operation, args...)   
> \
>   (((entity)->ops && (entity)->ops->operation) ?  
> \
>(entity)->ops->operation((entity) , ##args) : -ENOIOCTLCMD)
> 
> 
> Basically, the Sphinx C domain seems to be expecting a description for
> "...". I didn't find any way to get rid of that.
> 
> 2) a nitpick warning at v4l2-mem2mem.h:
> 
> ./include/media/v4l2-mem2mem.h:339: WARNING: c:type reference target not 
> found: queue_init
> 
> 
>   /**
>* v4l2_m2m_ctx_init() - allocate and initialize a m2m context
>*
>* @m2m_dev: opaque pointer to the internal data to handle M2M context
>* @drv_priv: driver's instance private data
>* @queue_init: a callback for queue type-specific initialization 
> function
>*  to be used for initializing videobuf_queues
>*
>* Usually called from driver's ``open()`` function.
>*/
>   struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct v4l2_m2m_dev *m2m_dev,
>   void *drv_priv,
>   int (*queue_init)(void *priv, struct vb2_queue *src_vq, 
> struct vb2_queue *dst_vq));
> 
> I checked the output of kernel-doc, and it looked ok. Yet, it expects
> "queue_init" to be defined somehow. I suspect that this is an error at
> Sphinx C domain parser.
> 
> Markus,
> 
> Could you please take a look on those?

Yes, I will give it a try, but I don't know if I find the time
today.

On wich branch could I test this?

-- Markus --

> 
> Thanks,
> Mauro
> --
> 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

--
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 2/3] hwmon: xgene: Add hwmon driver

[Arnd Bergmann]

On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> > On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
> > > +   ctx->comm_base_addr = cppc_ss->base_address;
> > > +   if (ctx->comm_base_addr) {
> > > +   ctx->pcc_comm_addr =
> > > +   
> > > acpi_os_ioremap(ctx->comm_base_addr,
> > > +   cppc_ss->length);
> > > 
> > 
> > This causes the arm64 allmodconfig build to fail now, according to
> > kernelci:
> > 
> >   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> > undefined!
> > 
> > Should this perhaps call ioremap() or memremap() instead?
> > 
> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 ("arm64:
> mark reserved memblock regions explicitly in iomem") starts using a function
> in acpi_os_ioremap() which is not exported. On top of that, 
> memblock_is_memory()
> is declared as __init_memblock, which makes me really uncomfortable.
> If acpi_os_ioremap() must not be used by modules, and possibly only during
> early (?) initialization, maybe its declaration should state those 
> limitations ?

I think there is more wrong with it, the driver also accesses a shared
memory area with kernel pointers using readl_relaxed/writel_relaxed,
which are only valid on MMIO registers.

I've prepared a patch, please have a look at the follow-up email.

Arnd
--
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: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

[Borislav Petkov]

On Mon, Aug 22, 2016 at 05:37:38PM -0500, Tom Lendacky wrote:
> BOOT data (such as EFI related data) is not encyrpted when the system is
> booted and needs to be accessed as non-encrypted.  Add support to the
> early_memremap API to identify the type of data being accessed so that
> the proper encryption attribute can be applied.  Currently, two types
> of data are defined, KERNEL_DATA and BOOT_DATA.
> 
> Signed-off-by: Tom Lendacky 
> ---

...

> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 031db21..e3bdc5a 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -419,6 +419,25 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
>   iounmap((void __iomem *)((unsigned long)addr & PAGE_MASK));
>  }
>  
> +/*
> + * Architecure override of __weak function to adjust the protection 
> attributes
> + * used when remapping memory.
> + */
> +pgprot_t __init early_memremap_pgprot_adjust(resource_size_t phys_addr,
> +  unsigned long size,
> +  enum memremap_owner owner,
> +  pgprot_t prot)
> +{
> + /*
> +  * If memory encryption is enabled and BOOT_DATA is being mapped
> +  * then remove the encryption bit.
> +  */
> + if (_PAGE_ENC && (owner == BOOT_DATA))
> + prot = __pgprot(pgprot_val(prot) & ~_PAGE_ENC);
> +
> + return prot;
> +}
> +

Hmm, so AFAICT, only arch/x86/xen needs KERNEL_DATA and everything else
is BOOT_DATA.

So instead of touching so many files and changing early_memremap(),
why can't you remove _PAGE_ENC by default on x86 and define a specific
early_memremap() for arch/x86/xen/ which you call there?

That would make this patch soo much smaller and the change simpler.

...

> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 5a2631a..f9286c6 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -386,7 +386,7 @@ int __init efi_mem_desc_lookup(u64 phys_addr, 
> efi_memory_desc_t *out_md)
>* So just always get our own virtual map on the CPU.
>*
>*/
> - md = early_memremap(p, sizeof (*md));
> + md = early_memremap(p, sizeof (*md), BOOT_DATA);

WARNING: space prohibited between function name and open parenthesis '('
#432: FILE: drivers/firmware/efi/efi.c:389:
+   md = early_memremap(p, sizeof (*md), BOOT_DATA);

Please integrate checkpatch.pl into your workflow so that you can catch
small style nits like this. And don't take its output too seriously... :-)

>   if (!md) {
>   pr_err_once("early_memremap(%pa, %zu) failed.\n",
>   , sizeof (*md));
> @@ -501,7 +501,8 @@ int __init efi_config_parse_tables(void *config_tables, 
> int count, int sz,
>   if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
>   efi_properties_table_t *tbl;
>  
> - tbl = early_memremap(efi.properties_table, sizeof(*tbl));
> + tbl = early_memremap(efi.properties_table, sizeof(*tbl),
> +  BOOT_DATA);
>   if (tbl == NULL) {
>   pr_err("Could not map Properties table!\n");
>   return -ENOMEM;
-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you 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

[PATCH] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

The newly added hwmon driver fails to build in an allmodconfig
kernel:

  1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!

According to comments in the code, the mailbox is a shared memory region,
not a set of MMIO registers, so we should use memremap() for mapping it
instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
of readl/writel.

The driver already uses plain kernel pointers, so it's a bit unusual
to work with functions that operate on __iomem pointers, and this
fixes that part too.

I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
regarding the ordering of the accesses from the CPU, but note that
there are no barriers (also unchanged from before).

I'm also keeping the endianess behavior, though I'm unsure whether
the message data was supposed to be in LE32 format in the first
place, it's possible this was meant to be interpreted as a byte
stream instead.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
index bc78a5d10182..e834dfb3acca 100644
--- a/drivers/hwmon/xgene-hwmon.c
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -34,7 +34,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+
 #include 
 
 /* SLIMpro message defines */
@@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 {
u16 ret, val;
 
-   val = readw_relaxed(addr);
+   val = le16_to_cpu(READ_ONCE(*addr));
ret = val & mask;
val &= ~mask;
-   writew_relaxed(val, addr);
+   WRITE_ONCE(*addr, cpu_to_le16(val));
 
return ret;
 }
@@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
 {
struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
-   void *ptr = generic_comm_base + 1;
+   u32 *ptr = (void*)(generic_comm_base + 1);
int rc, i;
u16 val;
 
@@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
*ctx, u32 *msg)
ctx->resp_pending = true;
 
/* Write signature for subspace */
-   writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
-  _comm_base->signature);
+   WRITE_ONCE(generic_comm_base->signature,
+  cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
 
/* Write to the shared command region */
-   writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
-  _comm_base->command);
+   WRITE_ONCE(generic_comm_base->command,
+  cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
 
/* Flip CMD COMPLETE bit */
-   val = readw_relaxed(_comm_base->status);
+   val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
val &= ~PCCS_CMD_COMPLETE;
-   writew_relaxed(val, _comm_base->status);
+   WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
 
/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
-   writel_relaxed(msg[i], ptr + i * 4);
+   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
 
/* Ring the doorbell */
rc = mbox_send_message(ctx->mbox_chan, msg);
@@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
 */
ctx->comm_base_addr = cppc_ss->base_address;
if (ctx->comm_base_addr) {
-   ctx->pcc_comm_addr =
-   acpi_os_ioremap(ctx->comm_base_addr,
-   cppc_ss->length);
+   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
+   cppc_ss->length,
+   MEMREMAP_WT);
} else {
dev_err(>dev, "Failed to get PCC comm region\n");
rc = -ENODEV;

--
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] hwmon: xgene: access mailbox as RAM

[Hoan Tran]

On Fri, Sep 9, 2016 at 9:58 AM, Guenter Roeck  wrote:
> Hi Arnd,
>
> On Fri, Sep 09, 2016 at 05:38:58PM +0200, Arnd Bergmann wrote:
>> The newly added hwmon driver fails to build in an allmodconfig
>> kernel:
>>
>>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
>> undefined!
>>
>> According to comments in the code, the mailbox is a shared memory region,
>> not a set of MMIO registers, so we should use memremap() for mapping it
>> instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
>> of readl/writel.
>>
>> The driver already uses plain kernel pointers, so it's a bit unusual
>> to work with functions that operate on __iomem pointers, and this
>> fixes that part too.
>>
>> I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
>> regarding the ordering of the accesses from the CPU, but note that
>> there are no barriers (also unchanged from before).
>>
>> I'm also keeping the endianess behavior, though I'm unsure whether
>> the message data was supposed to be in LE32 format in the first
>> place, it's possible this was meant to be interpreted as a byte
>> stream instead.
>>
>> Signed-off-by: Arnd Bergmann 
>>
>
> Thanks a lot for looking into this.
>
> I'll apply this patch to address the build problem. Much better than
> my rude "depends on BROKEN". It would be great to get a Tested-by:
> from someone with access to the hardware.
>

Hi Arnd and Guenter,

Thanks for the patch. I'm testing it out.

Hoan

> Guenter
>
>> diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
>> index bc78a5d10182..e834dfb3acca 100644
>> --- a/drivers/hwmon/xgene-hwmon.c
>> +++ b/drivers/hwmon/xgene-hwmon.c
>> @@ -34,7 +34,8 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>> +
>>  #include 
>>
>>  /* SLIMpro message defines */
>> @@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>>  {
>>   u16 ret, val;
>>
>> - val = readw_relaxed(addr);
>> + val = le16_to_cpu(READ_ONCE(*addr));
>>   ret = val & mask;
>>   val &= ~mask;
>> - writew_relaxed(val, addr);
>> + WRITE_ONCE(*addr, cpu_to_le16(val));
>>
>>   return ret;
>>  }
>> @@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>>  static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
>>  {
>>   struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
>> - void *ptr = generic_comm_base + 1;
>> + u32 *ptr = (void*)(generic_comm_base + 1);
>>   int rc, i;
>>   u16 val;
>>
>> @@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
>> *ctx, u32 *msg)
>>   ctx->resp_pending = true;
>>
>>   /* Write signature for subspace */
>> - writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
>> -_comm_base->signature);
>> + WRITE_ONCE(generic_comm_base->signature,
>> +cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
>>
>>   /* Write to the shared command region */
>> - writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
>> -_comm_base->command);
>> + WRITE_ONCE(generic_comm_base->command,
>> +cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
>>
>>   /* Flip CMD COMPLETE bit */
>> - val = readw_relaxed(_comm_base->status);
>> + val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
>>   val &= ~PCCS_CMD_COMPLETE;
>> - writew_relaxed(val, _comm_base->status);
>> + WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
>>
>>   /* Copy the message to the PCC comm space */
>>   for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
>> - writel_relaxed(msg[i], ptr + i * 4);
>> + WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
>>
>>   /* Ring the doorbell */
>>   rc = mbox_send_message(ctx->mbox_chan, msg);
>> @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device 
>> *pdev)
>>*/
>>   ctx->comm_base_addr = cppc_ss->base_address;
>>   if (ctx->comm_base_addr) {
>> - ctx->pcc_comm_addr =
>> - acpi_os_ioremap(ctx->comm_base_addr,
>> - cppc_ss->length);
>> + ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
>> + cppc_ss->length,
>> + MEMREMAP_WT);
>>   } else {
>>   dev_err(>dev, "Failed to get PCC comm region\n");
>>   rc = -ENODEV;
>>
--
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] hwmon: xgene: access mailbox as RAM

[Guenter Roeck]

Hi Arnd,

On Fri, Sep 09, 2016 at 05:38:58PM +0200, Arnd Bergmann wrote:
> The newly added hwmon driver fails to build in an allmodconfig
> kernel:
> 
>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
> 
> According to comments in the code, the mailbox is a shared memory region,
> not a set of MMIO registers, so we should use memremap() for mapping it
> instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
> of readl/writel.
> 
> The driver already uses plain kernel pointers, so it's a bit unusual
> to work with functions that operate on __iomem pointers, and this
> fixes that part too.
> 
> I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
> regarding the ordering of the accesses from the CPU, but note that
> there are no barriers (also unchanged from before).
> 
> I'm also keeping the endianess behavior, though I'm unsure whether
> the message data was supposed to be in LE32 format in the first
> place, it's possible this was meant to be interpreted as a byte
> stream instead.
> 
> Signed-off-by: Arnd Bergmann 
> 

Thanks a lot for looking into this.

I'll apply this patch to address the build problem. Much better than
my rude "depends on BROKEN". It would be great to get a Tested-by:
from someone with access to the hardware.

Guenter

> diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
> index bc78a5d10182..e834dfb3acca 100644
> --- a/drivers/hwmon/xgene-hwmon.c
> +++ b/drivers/hwmon/xgene-hwmon.c
> @@ -34,7 +34,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +
>  #include 
>  
>  /* SLIMpro message defines */
> @@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>  {
>   u16 ret, val;
>  
> - val = readw_relaxed(addr);
> + val = le16_to_cpu(READ_ONCE(*addr));
>   ret = val & mask;
>   val &= ~mask;
> - writew_relaxed(val, addr);
> + WRITE_ONCE(*addr, cpu_to_le16(val));
>  
>   return ret;
>  }
> @@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>  static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
>  {
>   struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
> - void *ptr = generic_comm_base + 1;
> + u32 *ptr = (void*)(generic_comm_base + 1);
>   int rc, i;
>   u16 val;
>  
> @@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
> *ctx, u32 *msg)
>   ctx->resp_pending = true;
>  
>   /* Write signature for subspace */
> - writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
> -_comm_base->signature);
> + WRITE_ONCE(generic_comm_base->signature,
> +cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
>  
>   /* Write to the shared command region */
> - writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
> -_comm_base->command);
> + WRITE_ONCE(generic_comm_base->command,
> +cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
>  
>   /* Flip CMD COMPLETE bit */
> - val = readw_relaxed(_comm_base->status);
> + val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
>   val &= ~PCCS_CMD_COMPLETE;
> - writew_relaxed(val, _comm_base->status);
> + WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
>  
>   /* Copy the message to the PCC comm space */
>   for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
> - writel_relaxed(msg[i], ptr + i * 4);
> + WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
>  
>   /* Ring the doorbell */
>   rc = mbox_send_message(ctx->mbox_chan, msg);
> @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
>*/
>   ctx->comm_base_addr = cppc_ss->base_address;
>   if (ctx->comm_base_addr) {
> - ctx->pcc_comm_addr =
> - acpi_os_ioremap(ctx->comm_base_addr,
> - cppc_ss->length);
> + ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
> + cppc_ss->length,
> + MEMREMAP_WT);
>   } else {
>   dev_err(>dev, "Failed to get PCC comm region\n");
>   rc = -ENODEV;
> 
--
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: [RFC PATCH v2 12/20] x86: Add support for changing memory encryption attribute

[Borislav Petkov]

On Mon, Aug 22, 2016 at 05:37:49PM -0500, Tom Lendacky wrote:
> This patch adds support to be change the memory encryption attribute for
> one or more memory pages.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/cacheflush.h  |3 +
>  arch/x86/include/asm/mem_encrypt.h |   13 ++
>  arch/x86/mm/mem_encrypt.c  |   43 +
>  arch/x86/mm/pageattr.c |   75 
> 
>  4 files changed, 134 insertions(+)

...

> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 72c292d..0ba9382 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -1728,6 +1728,81 @@ int set_memory_4k(unsigned long addr, int numpages)
>   __pgprot(0), 1, 0, NULL);
>  }
>  
> +static int __set_memory_enc_dec(struct cpa_data *cpa)
> +{
> + unsigned long addr;
> + int numpages;
> + int ret;
> +
> + if (*cpa->vaddr & ~PAGE_MASK) {
> + *cpa->vaddr &= PAGE_MASK;
> +
> + /* People should not be passing in unaligned addresses */
> + WARN_ON_ONCE(1);

Let's make this more user-friendly:

if (WARN_ONCE(*cpa->vaddr & ~PAGE_MASK, "Misaligned address: 0x%lx\n", 
*cpa->vaddr))
*cpa->vaddr &= PAGE_MASK;

> + }
> +
> + addr = *cpa->vaddr;
> + numpages = cpa->numpages;
> +
> + /* Must avoid aliasing mappings in the highmem code */
> + kmap_flush_unused();
> + vm_unmap_aliases();
> +
> + ret = __change_page_attr_set_clr(cpa, 1);
> +
> + /* Check whether we really changed something */
> + if (!(cpa->flags & CPA_FLUSHTLB))
> + goto out;
> +
> + /*
> +  * On success we use CLFLUSH, when the CPU supports it to
> +  * avoid the WBINVD.
> +  */
> + if (!ret && static_cpu_has(X86_FEATURE_CLFLUSH))
> + cpa_flush_range(addr, numpages, 1);
> + else
> + cpa_flush_all(1);

So if we fail (ret != 0) we do WBINVD unconditionally even if we don't
have to?

Don't you want this instead:

ret = __change_page_attr_set_clr(cpa, 1);
if (ret)
goto out;

/* Check whether we really changed something */
if (!(cpa->flags & CPA_FLUSHTLB))
goto out;

/*
 * On success we use CLFLUSH, when the CPU supports it to
 * avoid the WBINVD.
 */
if (static_cpu_has(X86_FEATURE_CLFLUSH))
cpa_flush_range(addr, numpages, 1);
else
cpa_flush_all(1);

out:
return ret;
}

?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you 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: [RFC PATCH v2 13/20] x86: Decrypt trampoline area if memory encryption is active

[Borislav Petkov]

On Mon, Aug 22, 2016 at 05:37:57PM -0500, Tom Lendacky wrote:
> When Secure Memory Encryption is enabled, the trampoline area must not
> be encrypted. A cpu running in real mode will not be able to decrypt

s/cpu/CPU/... always :-)

> memory that has been encrypted because it will not be able to use addresses
> with the memory encryption mask.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/realmode/init.c |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
> index 5db706f1..f74925f 100644
> --- a/arch/x86/realmode/init.c
> +++ b/arch/x86/realmode/init.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct real_mode_header *real_mode_header;
>  u32 *trampoline_cr4_features;
> @@ -130,6 +131,14 @@ static void __init set_real_mode_permissions(void)
>   unsigned long text_start =
>   (unsigned long) __va(real_mode_header->text_start);
>  
> + /*
> +  * If memory encryption is active, the trampoline area will need to
> +  * be in non-encrypted memory in order to bring up other processors

Let's stick with either "unencrypted" - I'd prefer that one - or
"non-encrypted" nomenclature so that there's no distraction. I see both
versions in the patchset.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you 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] hwmon: xgene: access mailbox as RAM

[Hoan Tran]

Hi Arnd,

On Fri, Sep 9, 2016 at 8:38 AM, Arnd Bergmann  wrote:
> The newly added hwmon driver fails to build in an allmodconfig
> kernel:
>
>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
>
> According to comments in the code, the mailbox is a shared memory region,
> not a set of MMIO registers, so we should use memremap() for mapping it
> instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
> of readl/writel.
>
> The driver already uses plain kernel pointers, so it's a bit unusual
> to work with functions that operate on __iomem pointers, and this
> fixes that part too.
>
> I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
> regarding the ordering of the accesses from the CPU, but note that
> there are no barriers (also unchanged from before).
>
> I'm also keeping the endianess behavior, though I'm unsure whether
> the message data was supposed to be in LE32 format in the first
> place, it's possible this was meant to be interpreted as a byte
> stream instead.
>
> Signed-off-by: Arnd Bergmann 
>
> diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
> index bc78a5d10182..e834dfb3acca 100644
> --- a/drivers/hwmon/xgene-hwmon.c
> +++ b/drivers/hwmon/xgene-hwmon.c
> @@ -34,7 +34,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 

Alphabetical order.

> +
>  #include 
>
>  /* SLIMpro message defines */
> @@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>  {
> u16 ret, val;
>
> -   val = readw_relaxed(addr);
> +   val = le16_to_cpu(READ_ONCE(*addr));
> ret = val & mask;
> val &= ~mask;
> -   writew_relaxed(val, addr);
> +   WRITE_ONCE(*addr, cpu_to_le16(val));
>
> return ret;
>  }
> @@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>  static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
>  {
> struct acpi_pcct_shared_memory *generic_comm_base = 
> ctx->pcc_comm_addr;
> -   void *ptr = generic_comm_base + 1;
> +   u32 *ptr = (void*)(generic_comm_base + 1);

Space before "*".

> int rc, i;
> u16 val;
>
> @@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
> *ctx, u32 *msg)
> ctx->resp_pending = true;
>
> /* Write signature for subspace */
> -   writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
> -  _comm_base->signature);
> +   WRITE_ONCE(generic_comm_base->signature,
> +  cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
>
> /* Write to the shared command region */
> -   writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
> -  _comm_base->command);
> +   WRITE_ONCE(generic_comm_base->command,
> +  cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
>
> /* Flip CMD COMPLETE bit */
> -   val = readw_relaxed(_comm_base->status);
> +   val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
> val &= ~PCCS_CMD_COMPLETE;
> -   writew_relaxed(val, _comm_base->status);
> +   WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
>
> /* Copy the message to the PCC comm space */
> for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
> -   writel_relaxed(msg[i], ptr + i * 4);
> +   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
>
> /* Ring the doorbell */
> rc = mbox_send_message(ctx->mbox_chan, msg);
> @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
>  */
> ctx->comm_base_addr = cppc_ss->base_address;
> if (ctx->comm_base_addr) {
> -   ctx->pcc_comm_addr =
> -   acpi_os_ioremap(ctx->comm_base_addr,
> -   cppc_ss->length);
> +   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
> +   cppc_ss->length,
> +   MEMREMAP_WT);

It should be MEMREMAP_WB. As mailbox shared memory is on RAM and our
co-processor is also in the coherency domain.

Thanks
Hoan

> } else {
> dev_err(>dev, "Failed to get PCC comm 
> region\n");
> rc = -ENODEV;
>
--
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 v15 04/13] task_isolation: add initial support

[Chris Metcalf]

On 9/2/2016 1:28 PM, Andy Lutomirski wrote:

On Sep 2, 2016 7:04 AM, "Chris Metcalf"  wrote:

On 8/30/2016 3:50 PM, Andy Lutomirski wrote:

On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf  wrote:

On 8/30/2016 2:43 PM, Andy Lutomirski wrote:

What if we did it the other way around: set a percpu flag saying
"going quiescent; disallow new deferred work", then finish all
existing work and return to userspace.  Then, on the next entry, clear
that flag.  With the flag set, vmstat would just flush anything that
it accumulates immediately, nothing would be added to the LRU list,
etc.


This is an interesting idea!

However, there are a number of implementation ideas that make me
worry that it might be a trickier approach overall.

First, "on the next entry" hides a world of hurt in four simple words.
Some platforms (arm64 and tile, that I'm familiar with) have a common
chunk of code that always runs on every entry to the kernel.  It would
not be too hard to poke at the assembly and make those platforms
always run some task-isolation specific code on entry.  But x86 scares
me - there seem to be a whole lot of ways to get into the kernel, and
I'm not convinced there is a lot of shared macrology or whatever that
would make it straightforward to intercept all of them.

Just use the context tracking entry hook.  It's 100% reliable.  The
relevant x86 function is enter_from_user_mode(), but I would just hook
into user_exit() in the common code.  (This code is had better be
reliable, because context tracking depends on it, and, if context
tracking doesn't work on a given arch, then isolation isn't going to
work regardless.


This looks a lot cleaner than last time I looked at the x86 code. So yes, I 
think
we could do an entry-point approach plausibly now.

This is also good for when we want to look at deferring the kernel TLB flush,
since it's the same mechanism that would be required for that.



There's at least one gotcha for the latter: NMIs aren't currently
guaranteed to go through context tracking.  Instead they use their own
RCU hooks.  Deferred TLB flushes can still be made to work, but a bit
more care will be needed.  I would probably approach it with an
additional NMI hook in the same places as rcu_nmi_enter() that does,
more or less:

if (need_tlb_flush) flush();

and then make sure that the normal exit hook looks like:

if (need_tlb_flush) {
   flush();
   barrier(); /* An NMI must not see !need_tlb_flush if the TLB hasn't
been flushed */
   flush the TLB;
}


This is a good point.  For now I will continue not trying to include the TLB 
flush
in the current patch series, so I will sit on this until we're ready to do so.


So to pop up a level, what is your actual concern about the existing
"do it in a loop" model?  The macrology currently in use means there
is zero cost if you don't configure TASK_ISOLATION, and the software
maintenance cost seems low since the idioms used for task isolation
in the loop are generally familiar to people reading that code.

My concern is that it's not obvious to readers of the code that the
loop ever terminates.  It really ought to, but it's doing something
very odd.  Normally we can loop because we get scheduled out, but
actually blocking in the return-to-userspace path, especially blocking
on a condition that doesn't have a wakeup associated with it, is odd.


True, although, comments :-)

Regardless, though, this doesn't seem at all weird to me in the
context of the vmstat and lru stuff, though.  It's exactly parallel to
the fact that we loop around on checking need_resched and signal, and
in some cases you could imagine multiple loops around when we schedule
out and get a signal, so loop around again, and then another
reschedule event happens during signal processing so we go around
again, etc.  Eventually it settles down.  It's the same with the
vmstat/lru stuff.

Only kind of.

When we say, effectively, while (need_resched()) schedule();, we're
not waiting for an event or condition per se.  We're runnable (in the
sense that userspace wants to run and we're not blocked on anything)
the entire time -- we're simply yielding to some other thread that is
also runnable.  So if that loop runs forever, it either means that
we're at low priority and we genuinely shouldn't be running or that
there's a scheduler bug.

If, on the other hand, we say while (not quiesced) schedule(); (or
equivalent), we're saying that we're *not* really ready to run and
that we're waiting for some condition to change.  The condition in
question is fairly complicated and won't wake us when we are ready.  I
can also imagine the scheduler getting rather confused, since, as far
as the scheduler knows, we are runnable and we are supposed to be
running.


So, how about a code structure like this?

In the main return-to-userspace loop where we check TIF flags,
we keep the notion of our TIF_TASK_ISOLATION flag that causes
us to invoke a task_isolation_prepare() 

Re: [PATCH V5] leds: trigger: Introduce a USB port trigger

[Rafał Miłecki]

On 9 September 2016 at 13:05, Greg KH  wrote:
> On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote:
>> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote:
>> > From: Rafał Miłecki 
>> >
>> > This commit adds a new trigger responsible for turning on LED when USB
>> > device gets connected to the selected USB port. This can can useful for
>> > various home routers that have USB port(s) and a proper LED telling user
>> > a device is connected.
>> >
>> > The trigger gets its documentation file but basically it just requires
>> > enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).
>> >
>> > There was a long discussion on design of this driver. Its current state
>> > is a result of picking them most adjustable solution as others couldn't
>> > handle all cases.
>> >
>> > 1) It wasn't possible for the driver to register separated trigger for
>> >each USB port. Some physical USB ports are handled by more than one
>> >controller and so by more than one USB port. E.g. USB 2.0 physical
>> >port may be handled by OHCI's port and EHCI's port.
>> >It's also not possible to assign more than 1 trigger to a single LED
>> >and implementing such feature would be tricky due to syncing triggers
>> >and sysfs conflicts with old triggers.
>> >
>> > 2) Another idea was to register trigger per USB hub. This wouldn't allow
>> >handling devices with multiple USB LEDs and controllers (hubs)
>> >controlling more than 1 physical port. It's common for hubs to have
>> >few ports and each may have its own LED.
>> >
>> > This final trigger is highly flexible. It allows selecting any USB ports
>> > for any LED. It was also modified (compared to the initial version) to
>> > allow choosing ports rather than having user /guess/ proper names. It
>> > was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
>> > 2 physical ports and 3 controllers.
>> >
>> > Another planned feature is support for LED reacting to the USB activity.
>> > This can be implemented with another sysfs file for setting mode. The
>> > default mode wouldn't change so there won't be ABI breakage and such
>> > feature can be safely implemented later.
>> >
>>
>> It has such driver at: drivers/usb/common/led.c
>
> Ugh, I thought I had seen something like this before...
>
> Rafał, can you just use this in-kernel code instead?

I really don't think I can because of all the reasons I carefully
listed in the commit message.

Have you took a look at that simple driver? It does nothing I need.
Its design doesn't allow implementing features I clearly listed in the
commit message.

-- 
Rafał
--
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 v2 0/3] doc-rst:c-domain: fix some issues in the c-domain

[Mauro Carvalho Chehab]

Em Wed,  7 Sep 2016 09:12:55 +0200
Markus Heiser  escreveu:

> From: Markus Heiser 
> 
> Hi Jon,
> 
> according to your remarks I fixed the first and second patch. The third patch 
> is
> resend unchanged;
> 
> > Am 06.09.2016 um 14:28 schrieb Jonathan Corbet :
> >
> > As others have pointed out, we generally want to hide the difference
> > between functions and macros, so this is probably one change we don't
> > want.  
> 
> I read "probably", so there might be a chance to persuade you ;)
> 
> I'm not a friend of *information hiding* and since the index is sorted
> alphabetical it does no matter if the entry is 'FOO (C function)' or 'FOO (C
> macro)'. The last one has the right information e.g. for someone how is 
> looking
> for a macro. FOO is a function-like macro and not a function, if the author
> describes the macro he might use the word "macro FOO" but in the index it is
> tagged as C function.
> 
> Macros and functions are totally different even if their notation looks
> similarly. So where is the benefit of entries like 'FOO (C function)', which 
> is
> IMHO ambiguous.
> 
> I tagged the 'function-like macros index entry' patch with 'RFC' and resend it
> within this series. If you and/or others have a different opinion, feel free 
> to
> drop it.
> 
> Thanks for review.
> 
> -- Markus --
> 
> 
> Markus Heiser (3):
>   doc-rst:c-domain: fix sphinx version incompatibility
>   doc-rst:c-domain: function-like macros arguments
>   doc-rst:c-domain: function-like macros index entry
> 
>  Documentation/sphinx/cdomain.py | 79 
> +++--
>  1 file changed, 76 insertions(+), 3 deletions(-)
> 

Those patches indeed fix the issues. The arguments are now
processed properly.

Tested-by: Mauro Carvalho Chehab 

---

Using either this approach or my kernel-doc patch, I'm now getting
only two warnings:

1) at media-entity.h, even without nitpick mode:

./include/media/media-entity.h:1053: warning: No description found for 
parameter '...'

This is caused by this kernel-doc tag and the corresponding macro:

/**
 * media_entity_call - Calls a struct media_entity_operations operation 
on
 *  an entity
 *
 * @entity: entity where the @operation will be called
 * @operation: type of the operation. Should be the name of a member of
 *  struct _entity_operations.
 *
 * This helper function will check if @operation is not %NULL. On such 
case,
 * it will issue a call to @operation\(@entity, @args\).
 */

#define media_entity_call(entity, operation, args...)   
\
(((entity)->ops && (entity)->ops->operation) ?  
\
 (entity)->ops->operation((entity) , ##args) : -ENOIOCTLCMD)


Basically, the Sphinx C domain seems to be expecting a description for
"...". I didn't find any way to get rid of that.

2) a nitpick warning at v4l2-mem2mem.h:

./include/media/v4l2-mem2mem.h:339: WARNING: c:type reference target not found: 
queue_init


/**
 * v4l2_m2m_ctx_init() - allocate and initialize a m2m context
 *
 * @m2m_dev: opaque pointer to the internal data to handle M2M context
 * @drv_priv: driver's instance private data
 * @queue_init: a callback for queue type-specific initialization 
function
 *  to be used for initializing videobuf_queues
 *
 * Usually called from driver's ``open()`` function.
 */
struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct v4l2_m2m_dev *m2m_dev,
void *drv_priv,
int (*queue_init)(void *priv, struct vb2_queue *src_vq, 
struct vb2_queue *dst_vq));

I checked the output of kernel-doc, and it looked ok. Yet, it expects
"queue_init" to be defined somehow. I suspect that this is an error at
Sphinx C domain parser.

Markus,

Could you please take a look on those?

Thanks,
Mauro
--
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 8/9] selftests: move vDSO tests from Documentation/vDSO

[Shuah Khan]

Move vDSO tests from Documentation/vDSO to selftests/vDSO.

Signed-off-by: Shuah Khan 
---
 Documentation/vDSO/.gitignore  |   2 -
 Documentation/vDSO/Makefile|  17 --
 Documentation/vDSO/parse_vdso.c| 269 -
 Documentation/vDSO/vdso_standalone_test_x86.c  | 128 --
 Documentation/vDSO/vdso_test.c |  52 
 tools/testing/selftests/vDSO/.gitignore|   2 +
 tools/testing/selftests/vDSO/Makefile  |  17 ++
 tools/testing/selftests/vDSO/parse_vdso.c  | 269 +
 .../selftests/vDSO/vdso_standalone_test_x86.c  | 128 ++
 tools/testing/selftests/vDSO/vdso_test.c   |  52 
 10 files changed, 468 insertions(+), 468 deletions(-)
 delete mode 100644 Documentation/vDSO/.gitignore
 delete mode 100644 Documentation/vDSO/Makefile
 delete mode 100644 Documentation/vDSO/parse_vdso.c
 delete mode 100644 Documentation/vDSO/vdso_standalone_test_x86.c
 delete mode 100644 Documentation/vDSO/vdso_test.c
 create mode 100644 tools/testing/selftests/vDSO/.gitignore
 create mode 100644 tools/testing/selftests/vDSO/Makefile
 create mode 100644 tools/testing/selftests/vDSO/parse_vdso.c
 create mode 100644 tools/testing/selftests/vDSO/vdso_standalone_test_x86.c
 create mode 100644 tools/testing/selftests/vDSO/vdso_test.c

diff --git a/Documentation/vDSO/.gitignore b/Documentation/vDSO/.gitignore
deleted file mode 100644
index 133bf9e..000
--- a/Documentation/vDSO/.gitignore
+++ /dev/null
@@ -1,2 +0,0 @@
-vdso_test
-vdso_standalone_test_x86
diff --git a/Documentation/vDSO/Makefile b/Documentation/vDSO/Makefile
deleted file mode 100644
index b12e987..000
--- a/Documentation/vDSO/Makefile
+++ /dev/null
@@ -1,17 +0,0 @@
-ifndef CROSS_COMPILE
-# vdso_test won't build for glibc < 2.16, so disable it
-# hostprogs-y := vdso_test
-hostprogs-$(CONFIG_X86) := vdso_standalone_test_x86
-vdso_standalone_test_x86-objs := vdso_standalone_test_x86.o parse_vdso.o
-vdso_test-objs := parse_vdso.o vdso_test.o
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS := -I$(objtree)/usr/include -std=gnu99
-HOSTCFLAGS_vdso_standalone_test_x86.o := -fno-asynchronous-unwind-tables 
-fno-stack-protector
-HOSTLOADLIBES_vdso_standalone_test_x86 := -nostdlib
-ifeq ($(CONFIG_X86_32),y)
-HOSTLOADLIBES_vdso_standalone_test_x86 += -lgcc_s
-endif
-endif
diff --git a/Documentation/vDSO/parse_vdso.c b/Documentation/vDSO/parse_vdso.c
deleted file mode 100644
index 1dbb4b8..000
--- a/Documentation/vDSO/parse_vdso.c
+++ /dev/null
@@ -1,269 +0,0 @@
-/*
- * parse_vdso.c: Linux reference vDSO parser
- * Written by Andrew Lutomirski, 2011-2014.
- *
- * This code is meant to be linked in to various programs that run on Linux.
- * As such, it is available with as few restrictions as possible.  This file
- * is licensed under the Creative Commons Zero License, version 1.0,
- * available at http://creativecommons.org/publicdomain/zero/1.0/legalcode
- *
- * The vDSO is a regular ELF DSO that the kernel maps into user space when
- * it starts a program.  It works equally well in statically and dynamically
- * linked binaries.
- *
- * This code is tested on x86.  In principle it should work on any
- * architecture that has a vDSO.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/*
- * To use this vDSO parser, first call one of the vdso_init_* functions.
- * If you've already parsed auxv, then pass the value of AT_SYSINFO_EHDR
- * to vdso_init_from_sysinfo_ehdr.  Otherwise pass auxv to vdso_init_from_auxv.
- * Then call vdso_sym for each symbol you want.  For example, to look up
- * gettimeofday on x86_64, use:
- *
- *  = vdso_sym("LINUX_2.6", "gettimeofday");
- * or
- *  = vdso_sym("LINUX_2.6", "__vdso_gettimeofday");
- *
- * vdso_sym will return 0 if the symbol doesn't exist or if the init function
- * failed or was not called.  vdso_sym is a little slow, so its return value
- * should be cached.
- *
- * vdso_sym is threadsafe; the init functions are not.
- *
- * These are the prototypes:
- */
-extern void vdso_init_from_auxv(void *auxv);
-extern void vdso_init_from_sysinfo_ehdr(uintptr_t base);
-extern void *vdso_sym(const char *version, const char *name);
-
-
-/* And here's the code. */
-#ifndef ELF_BITS
-# if ULONG_MAX > 0xUL
-#  define ELF_BITS 64
-# else
-#  define ELF_BITS 32
-# endif
-#endif
-
-#define ELF_BITS_XFORM2(bits, x) Elf##bits##_##x
-#define ELF_BITS_XFORM(bits, x) ELF_BITS_XFORM2(bits, x)
-#define ELF(x) ELF_BITS_XFORM(ELF_BITS, x)
-
-static struct vdso_info
-{
-   bool valid;
-
-   /* Load information */
-   uintptr_t load_addr;
-   uintptr_t load_offset;  /* load_addr - recorded vaddr */
-
-   /* Symbol table */
-   ELF(Sym) *symtab;
-   const char *symstrings;
-   ELF(Word) *bucket, *chain;
-   ELF(Word) nbucket, nchain;
-
-   /* Version table 

[PATCH 9/9] selftests: Update vDSO Makefile to work under selftests

[Shuah Khan]

Update vDSO Makefile to work under selftests. vDSO will not be run as part
of selftests suite and will not included in install targets. They can be
built separately for now.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/vDSO/Makefile | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/tools/testing/selftests/vDSO/Makefile 
b/tools/testing/selftests/vDSO/Makefile
index b12e987..706b68b 100644
--- a/tools/testing/selftests/vDSO/Makefile
+++ b/tools/testing/selftests/vDSO/Makefile
@@ -1,17 +1,20 @@
 ifndef CROSS_COMPILE
-# vdso_test won't build for glibc < 2.16, so disable it
-# hostprogs-y := vdso_test
-hostprogs-$(CONFIG_X86) := vdso_standalone_test_x86
-vdso_standalone_test_x86-objs := vdso_standalone_test_x86.o parse_vdso.o
-vdso_test-objs := parse_vdso.o vdso_test.o
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS := -I$(objtree)/usr/include -std=gnu99
-HOSTCFLAGS_vdso_standalone_test_x86.o := -fno-asynchronous-unwind-tables 
-fno-stack-protector
-HOSTLOADLIBES_vdso_standalone_test_x86 := -nostdlib
+CFLAGS := -std=gnu99
+CFLAGS_vdso_standalone_test_x86 := -nostdlib -fno-asynchronous-unwind-tables 
-fno-stack-protector
 ifeq ($(CONFIG_X86_32),y)
-HOSTLOADLIBES_vdso_standalone_test_x86 += -lgcc_s
+LDLIBS += -lgcc_s
 endif
+
+TEST_PROGS := vdso_test vdso_standalone_test_x86
+
+all: $(TEST_PROGS)
+vdso_test: parse_vdso.c vdso_test.c
+vdso_standalone_test_x86: vdso_standalone_test_x86.c parse_vdso.c
+   $(CC) $(CFLAGS) $(CFLAGS_vdso_standalone_test_x86) \
+   vdso_standalone_test_x86.c parse_vdso.c \
+   -o vdso_standalone_test_x86
+
+include ../lib.mk
+clean:
+   rm -fr $(TEST_PROGS)
 endif
-- 
2.7.4

--
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 6/9] selftests: move ptp tests from Documentation/ptp

[Shuah Khan]

Move ptp tests from Documentation/ptp to selftests/ptp.

Signed-off-by: Shuah Khan 
---
 Documentation/ptp/.gitignore   |   1 -
 Documentation/ptp/Makefile |   8 -
 Documentation/ptp/testptp.c| 523 -
 Documentation/ptp/testptp.mk   |  33 ---
 tools/testing/selftests/ptp/.gitignore |   1 +
 tools/testing/selftests/ptp/Makefile   |   8 +
 tools/testing/selftests/ptp/testptp.c  | 523 +
 tools/testing/selftests/ptp/testptp.mk |  33 +++
 8 files changed, 565 insertions(+), 565 deletions(-)
 delete mode 100644 Documentation/ptp/.gitignore
 delete mode 100644 Documentation/ptp/Makefile
 delete mode 100644 Documentation/ptp/testptp.c
 delete mode 100644 Documentation/ptp/testptp.mk
 create mode 100644 tools/testing/selftests/ptp/.gitignore
 create mode 100644 tools/testing/selftests/ptp/Makefile
 create mode 100644 tools/testing/selftests/ptp/testptp.c
 create mode 100644 tools/testing/selftests/ptp/testptp.mk

diff --git a/Documentation/ptp/.gitignore b/Documentation/ptp/.gitignore
deleted file mode 100644
index f562e49..000
--- a/Documentation/ptp/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-testptp
diff --git a/Documentation/ptp/Makefile b/Documentation/ptp/Makefile
deleted file mode 100644
index 293d6c0..000
--- a/Documentation/ptp/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-# List of programs to build
-hostprogs-y := testptp
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_testptp.o += -I$(objtree)/usr/include
-HOSTLOADLIBES_testptp := -lrt
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
deleted file mode 100644
index 5d2eae1..000
--- a/Documentation/ptp/testptp.c
+++ /dev/null
@@ -1,523 +0,0 @@
-/*
- * PTP 1588 clock support - User space test program
- *
- * Copyright (C) 2010 OMICRON electronics GmbH
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-#define _GNU_SOURCE
-#define __SANE_USERSPACE_TYPES__/* For PPC64, to get LL64 types */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#define DEVICE "/dev/ptp0"
-
-#ifndef ADJ_SETOFFSET
-#define ADJ_SETOFFSET 0x0100
-#endif
-
-#ifndef CLOCK_INVALID
-#define CLOCK_INVALID -1
-#endif
-
-/* clock_adjtime is not available in GLIBC < 2.14 */
-#if !__GLIBC_PREREQ(2, 14)
-#include 
-static int clock_adjtime(clockid_t id, struct timex *tx)
-{
-   return syscall(__NR_clock_adjtime, id, tx);
-}
-#endif
-
-static clockid_t get_clockid(int fd)
-{
-#define CLOCKFD 3
-#define FD_TO_CLOCKID(fd)  ((~(clockid_t) (fd) << 3) | CLOCKFD)
-
-   return FD_TO_CLOCKID(fd);
-}
-
-static void handle_alarm(int s)
-{
-   printf("received signal %d\n", s);
-}
-
-static int install_handler(int signum, void (*handler)(int))
-{
-   struct sigaction action;
-   sigset_t mask;
-
-   /* Unblock the signal. */
-   sigemptyset();
-   sigaddset(, signum);
-   sigprocmask(SIG_UNBLOCK, , NULL);
-
-   /* Install the signal handler. */
-   action.sa_handler = handler;
-   action.sa_flags = 0;
-   sigemptyset(_mask);
-   sigaction(signum, , NULL);
-
-   return 0;
-}
-
-static long ppb_to_scaled_ppm(int ppb)
-{
-   /*
-* The 'freq' field in the 'struct timex' is in parts per
-* million, but with a 16 bit binary fractional field.
-* Instead of calculating either one of
-*
-*scaled_ppm = (ppb / 1000) << 16  [1]
-*scaled_ppm = (ppb << 16) / 1000  [2]
-*
-* we simply use double precision math, in order to avoid the
-* truncation in [1] and the possible overflow in [2].
-*/
-   return (long) (ppb * 65.536);
-}
-
-static int64_t pctns(struct ptp_clock_time *t)
-{
-   return t->sec * 10LL + t->nsec;
-}
-
-static void usage(char *progname)
-{
-   fprintf(stderr,
-   "usage: %s [options]\n"
-   " -a val request a one-shot alarm after 'val' seconds\n"
-   " -A val request a periodic alarm every 'val' seconds\n"
-   " -c query the ptp clock's capabilities\n"
-   

[PATCH 3/9] selftests: move .gitignore from Documentation/filesystems

[Shuah Khan]

Move .gitignore for dnotify_test from Documentation/filesystems to
selftests/filesystems.

Signed-off-by: Shuah Khan 
---
 Documentation/filesystems/.gitignore   | 1 -
 tools/testing/selftests/filesystems/.gitignore | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)
 delete mode 100644 Documentation/filesystems/.gitignore
 create mode 100644 tools/testing/selftests/filesystems/.gitignore

diff --git a/Documentation/filesystems/.gitignore 
b/Documentation/filesystems/.gitignore
deleted file mode 100644
index 31d6e42..000
--- a/Documentation/filesystems/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-dnotify_test
diff --git a/tools/testing/selftests/filesystems/.gitignore 
b/tools/testing/selftests/filesystems/.gitignore
new file mode 100644
index 000..31d6e42
--- /dev/null
+++ b/tools/testing/selftests/filesystems/.gitignore
@@ -0,0 +1 @@
+dnotify_test
-- 
2.7.4

--
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 5/9] selftests: Update prctl Makefile to work under selftests

[Shuah Khan]

Update prctl Makefile to work under selftests. prctl will not be run as
part of selftests suite and will not included in install targets. They
can be built separately for now.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/prctl/Makefile | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/prctl/Makefile 
b/tools/testing/selftests/prctl/Makefile
index 44de308..35aa1c8 100644
--- a/tools/testing/selftests/prctl/Makefile
+++ b/tools/testing/selftests/prctl/Makefile
@@ -1,10 +1,15 @@
 ifndef CROSS_COMPILE
-# List of programs to build
-hostprogs-$(CONFIG_X86) := disable-tsc-ctxt-sw-stress-test 
disable-tsc-on-off-stress-test disable-tsc-test
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
 
-HOSTCFLAGS_disable-tsc-ctxt-sw-stress-test.o += -I$(objtree)/usr/include
-HOSTCFLAGS_disable-tsc-on-off-stress-test.o += -I$(objtree)/usr/include
-HOSTCFLAGS_disable-tsc-test.o += -I$(objtree)/usr/include
+ifeq ($(ARCH),x86)
+TEST_PROGS := disable-tsc-ctxt-sw-stress-test disable-tsc-on-off-stress-test \
+   disable-tsc-test
+all: $(TEST_PROGS)
+
+include ../lib.mk
+
+clean:
+   rm -fr $(TEST_PROGS)
+endif
 endif
-- 
2.7.4

--
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 4/9] selftests: move prctl tests from Documentation/prctl

[Shuah Khan]

Move prctl tests from Documentation/prctl to selftests/prctl.

Signed-off-by: Shuah Khan 
---
 Documentation/prctl/.gitignore |  3 -
 Documentation/prctl/Makefile   | 10 ---
 .../prctl/disable-tsc-ctxt-sw-stress-test.c| 97 --
 .../prctl/disable-tsc-on-off-stress-test.c | 96 -
 Documentation/prctl/disable-tsc-test.c | 95 -
 tools/testing/selftests/prctl/.gitignore   |  3 +
 tools/testing/selftests/prctl/Makefile | 10 +++
 .../prctl/disable-tsc-ctxt-sw-stress-test.c| 97 ++
 .../prctl/disable-tsc-on-off-stress-test.c | 96 +
 tools/testing/selftests/prctl/disable-tsc-test.c   | 95 +
 10 files changed, 301 insertions(+), 301 deletions(-)
 delete mode 100644 Documentation/prctl/.gitignore
 delete mode 100644 Documentation/prctl/Makefile
 delete mode 100644 Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
 delete mode 100644 Documentation/prctl/disable-tsc-on-off-stress-test.c
 delete mode 100644 Documentation/prctl/disable-tsc-test.c
 create mode 100644 tools/testing/selftests/prctl/.gitignore
 create mode 100644 tools/testing/selftests/prctl/Makefile
 create mode 100644 
tools/testing/selftests/prctl/disable-tsc-ctxt-sw-stress-test.c
 create mode 100644 
tools/testing/selftests/prctl/disable-tsc-on-off-stress-test.c
 create mode 100644 tools/testing/selftests/prctl/disable-tsc-test.c

diff --git a/Documentation/prctl/.gitignore b/Documentation/prctl/.gitignore
deleted file mode 100644
index 0b5c274..000
--- a/Documentation/prctl/.gitignore
+++ /dev/null
@@ -1,3 +0,0 @@
-disable-tsc-ctxt-sw-stress-test
-disable-tsc-on-off-stress-test
-disable-tsc-test
diff --git a/Documentation/prctl/Makefile b/Documentation/prctl/Makefile
deleted file mode 100644
index 44de308..000
--- a/Documentation/prctl/Makefile
+++ /dev/null
@@ -1,10 +0,0 @@
-ifndef CROSS_COMPILE
-# List of programs to build
-hostprogs-$(CONFIG_X86) := disable-tsc-ctxt-sw-stress-test 
disable-tsc-on-off-stress-test disable-tsc-test
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_disable-tsc-ctxt-sw-stress-test.o += -I$(objtree)/usr/include
-HOSTCFLAGS_disable-tsc-on-off-stress-test.o += -I$(objtree)/usr/include
-HOSTCFLAGS_disable-tsc-test.o += -I$(objtree)/usr/include
-endif
diff --git a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c 
b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
deleted file mode 100644
index f7499d1..000
--- a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
+++ /dev/null
@@ -1,97 +0,0 @@
-/*
- * Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
- *
- * Tests if the control register is updated correctly
- * at context switches
- *
- * Warning: this test will cause a very high load for a few seconds
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-
-#include 
-#include 
-
-/* Get/set the process' ability to use the timestamp counter instruction */
-#ifndef PR_GET_TSC
-#define PR_GET_TSC 25
-#define PR_SET_TSC 26
-# define PR_TSC_ENABLE 1   /* allow the use of the timestamp counter */
-# define PR_TSC_SIGSEGV2   /* throw a SIGSEGV instead of 
reading the TSC */
-#endif
-
-static uint64_t rdtsc(void)
-{
-uint32_t lo, hi;
-/* We cannot use "=A", since this would use %rax on x86_64 */
-__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
-return (uint64_t)hi << 32 | lo;
-}
-
-static void sigsegv_expect(int sig)
-{
-   /* */
-}
-
-static void segvtask(void)
-{
-   if (prctl(PR_SET_TSC, PR_TSC_SIGSEGV) < 0)
-   {
-   perror("prctl");
-   exit(0);
-   }
-   signal(SIGSEGV, sigsegv_expect);
-   alarm(10);
-   rdtsc();
-   fprintf(stderr, "FATAL ERROR, rdtsc() succeeded while disabled\n");
-   exit(0);
-}
-
-
-static void sigsegv_fail(int sig)
-{
-   fprintf(stderr, "FATAL ERROR, rdtsc() failed while enabled\n");
-   exit(0);
-}
-
-static void rdtsctask(void)
-{
-   if (prctl(PR_SET_TSC, PR_TSC_ENABLE) < 0)
-   {
-   perror("prctl");
-   exit(0);
-   }
-   signal(SIGSEGV, sigsegv_fail);
-   alarm(10);
-   for(;;) rdtsc();
-}
-
-
-int main(void)
-{
-   int n_tasks = 100, i;
-
-   fprintf(stderr, "[No further output means we're allright]\n");
-
-   for (i=0; i

[PATCH 7/9] selftests: Update ptp Makefile to work under selftests

[Shuah Khan]

Update ptp Makefile to work under selftests. ptp will not be run as part
of selftests suite and will not included in install targets. They can be
built separately for now.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/ptp/Makefile | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/ptp/Makefile 
b/tools/testing/selftests/ptp/Makefile
index 293d6c0..f4a7238 100644
--- a/tools/testing/selftests/ptp/Makefile
+++ b/tools/testing/selftests/ptp/Makefile
@@ -1,8 +1,8 @@
-# List of programs to build
-hostprogs-y := testptp
+TEST_PROGS := testptp
+LDLIBS += -lrt
+all: $(TEST_PROGS)
 
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
+include ../lib.mk
 
-HOSTCFLAGS_testptp.o += -I$(objtree)/usr/include
-HOSTLOADLIBES_testptp := -lrt
+clean:
+   rm -fr testptp
-- 
2.7.4

--
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 2/9] selftests: update filesystems Makefile to work under selftests

[Shuah Khan]

Update to work under selftests. dnotify_test will not be run as part of
selftests suite and will not included in install targets. It can be built
separately for now.

Signed-off-by: Shuah Khan 
---
 tools/testing/selftests/filesystems/Makefile | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/filesystems/Makefile 
b/tools/testing/selftests/filesystems/Makefile
index 883010c..f1dce5c 100644
--- a/tools/testing/selftests/filesystems/Makefile
+++ b/tools/testing/selftests/filesystems/Makefile
@@ -1,5 +1,7 @@
-# List of programs to build
-hostprogs-y := dnotify_test
+TEST_PROGS := dnotify_test
+all: $(TEST_PROGS)
 
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
+include ../lib.mk
+
+clean:
+   rm -fr dnotify_test
-- 
2.7.4

--
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 1/9] selftests: move dnotify_test from Documentation/filesystems

[Shuah Khan]

Move dnotify_test from Documentation/filesystems to selftests/filesystems

Signed-off-by: Shuah Khan 
---
 Documentation/filesystems/Makefile |  5 
 Documentation/filesystems/dnotify_test.c   | 34 --
 tools/testing/selftests/filesystems/Makefile   |  5 
 tools/testing/selftests/filesystems/dnotify_test.c | 34 ++
 4 files changed, 39 insertions(+), 39 deletions(-)
 delete mode 100644 Documentation/filesystems/Makefile
 delete mode 100644 Documentation/filesystems/dnotify_test.c
 create mode 100644 tools/testing/selftests/filesystems/Makefile
 create mode 100644 tools/testing/selftests/filesystems/dnotify_test.c

diff --git a/Documentation/filesystems/Makefile 
b/Documentation/filesystems/Makefile
deleted file mode 100644
index 883010c..000
--- a/Documentation/filesystems/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-# List of programs to build
-hostprogs-y := dnotify_test
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
diff --git a/Documentation/filesystems/dnotify_test.c 
b/Documentation/filesystems/dnotify_test.c
deleted file mode 100644
index 8b37b4a..000
--- a/Documentation/filesystems/dnotify_test.c
+++ /dev/null
@@ -1,34 +0,0 @@
-#define _GNU_SOURCE/* needed to get the defines */
-#include  /* in glibc 2.2 this has the needed
-  values defined */
-#include 
-#include 
-#include 
-
-static volatile int event_fd;
-
-static void handler(int sig, siginfo_t *si, void *data)
-{
-   event_fd = si->si_fd;
-}
-
-int main(void)
-{
-   struct sigaction act;
-   int fd;
-
-   act.sa_sigaction = handler;
-   sigemptyset(_mask);
-   act.sa_flags = SA_SIGINFO;
-   sigaction(SIGRTMIN + 1, , NULL);
-
-   fd = open(".", O_RDONLY);
-   fcntl(fd, F_SETSIG, SIGRTMIN + 1);
-   fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT);
-   /* we will now be notified if any of the files
-  in "." is modified or new files are created */
-   while (1) {
-   pause();
-   printf("Got event on fd=%d\n", event_fd);
-   }
-}
diff --git a/tools/testing/selftests/filesystems/Makefile 
b/tools/testing/selftests/filesystems/Makefile
new file mode 100644
index 000..883010c
--- /dev/null
+++ b/tools/testing/selftests/filesystems/Makefile
@@ -0,0 +1,5 @@
+# List of programs to build
+hostprogs-y := dnotify_test
+
+# Tell kbuild to always build the programs
+always := $(hostprogs-y)
diff --git a/tools/testing/selftests/filesystems/dnotify_test.c 
b/tools/testing/selftests/filesystems/dnotify_test.c
new file mode 100644
index 000..8b37b4a
--- /dev/null
+++ b/tools/testing/selftests/filesystems/dnotify_test.c
@@ -0,0 +1,34 @@
+#define _GNU_SOURCE/* needed to get the defines */
+#include  /* in glibc 2.2 this has the needed
+  values defined */
+#include 
+#include 
+#include 
+
+static volatile int event_fd;
+
+static void handler(int sig, siginfo_t *si, void *data)
+{
+   event_fd = si->si_fd;
+}
+
+int main(void)
+{
+   struct sigaction act;
+   int fd;
+
+   act.sa_sigaction = handler;
+   sigemptyset(_mask);
+   act.sa_flags = SA_SIGINFO;
+   sigaction(SIGRTMIN + 1, , NULL);
+
+   fd = open(".", O_RDONLY);
+   fcntl(fd, F_SETSIG, SIGRTMIN + 1);
+   fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT);
+   /* we will now be notified if any of the files
+  in "." is modified or new files are created */
+   while (1) {
+   pause();
+   printf("Got event on fd=%d\n", event_fd);
+   }
+}
-- 
2.7.4

--
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 0/9] Move runnable code (tests) from Documentation to selftests

[Shuah Khan]

Move runnable code (tests) from Documentation to selftests and update
Makefiles to work under selftests.

Jon Corbet and I discussed this in an email thread and as per that
discussion, this patch series moves all the tests that are under the
Documentation directory to selftests. There is more runnable code in
the form of examples and utils and that is going to be another patch
series. I moved just the tests and left the documentation files as is.

Checkpatch isn't happy with a few of the patches as some of the
renamed files have existing checkpatch errors and warnings. I am
working another patch series that will address those.

Shuah Khan (9):
  selftests: move dnotify_test from Documentation/filesystems
  selftests: update filesystems Makefile to work under selftests
  selftests: move .gitignore from Documentation/filesystems
  selftests: move prctl tests from Documentation/prctl
  selftests: Update prctl Makefile to work under selftests
  selftests: move ptp tests from Documentation/ptp
  selftests: Update ptp Makefile to work under selftests
  selftests: move vDSO tests from Documentation/vDSO
  selftests: Update vDSO Makefile to work under selftests

 Documentation/filesystems/.gitignore   |   1 -
 Documentation/filesystems/Makefile |   5 -
 Documentation/filesystems/dnotify_test.c   |  34 --
 Documentation/prctl/.gitignore |   3 -
 Documentation/prctl/Makefile   |  10 -
 .../prctl/disable-tsc-ctxt-sw-stress-test.c|  97 
 .../prctl/disable-tsc-on-off-stress-test.c |  96 
 Documentation/prctl/disable-tsc-test.c |  95 
 Documentation/ptp/.gitignore   |   1 -
 Documentation/ptp/Makefile |   8 -
 Documentation/ptp/testptp.c| 523 -
 Documentation/ptp/testptp.mk   |  33 --
 Documentation/vDSO/.gitignore  |   2 -
 Documentation/vDSO/Makefile|  17 -
 Documentation/vDSO/parse_vdso.c| 269 ---
 Documentation/vDSO/vdso_standalone_test_x86.c  | 128 -
 Documentation/vDSO/vdso_test.c |  52 --
 tools/testing/selftests/filesystems/.gitignore |   1 +
 tools/testing/selftests/filesystems/Makefile   |   7 +
 tools/testing/selftests/filesystems/dnotify_test.c |  34 ++
 tools/testing/selftests/prctl/.gitignore   |   3 +
 tools/testing/selftests/prctl/Makefile |  15 +
 .../prctl/disable-tsc-ctxt-sw-stress-test.c|  97 
 .../prctl/disable-tsc-on-off-stress-test.c |  96 
 tools/testing/selftests/prctl/disable-tsc-test.c   |  95 
 tools/testing/selftests/ptp/.gitignore |   1 +
 tools/testing/selftests/ptp/Makefile   |   8 +
 tools/testing/selftests/ptp/testptp.c  | 523 +
 tools/testing/selftests/ptp/testptp.mk |  33 ++
 tools/testing/selftests/vDSO/.gitignore|   2 +
 tools/testing/selftests/vDSO/Makefile  |  20 +
 tools/testing/selftests/vDSO/parse_vdso.c  | 269 +++
 .../selftests/vDSO/vdso_standalone_test_x86.c  | 128 +
 tools/testing/selftests/vDSO/vdso_test.c   |  52 ++
 34 files changed, 1384 insertions(+), 1374 deletions(-)
 delete mode 100644 Documentation/filesystems/.gitignore
 delete mode 100644 Documentation/filesystems/Makefile
 delete mode 100644 Documentation/filesystems/dnotify_test.c
 delete mode 100644 Documentation/prctl/.gitignore
 delete mode 100644 Documentation/prctl/Makefile
 delete mode 100644 Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
 delete mode 100644 Documentation/prctl/disable-tsc-on-off-stress-test.c
 delete mode 100644 Documentation/prctl/disable-tsc-test.c
 delete mode 100644 Documentation/ptp/.gitignore
 delete mode 100644 Documentation/ptp/Makefile
 delete mode 100644 Documentation/ptp/testptp.c
 delete mode 100644 Documentation/ptp/testptp.mk
 delete mode 100644 Documentation/vDSO/.gitignore
 delete mode 100644 Documentation/vDSO/Makefile
 delete mode 100644 Documentation/vDSO/parse_vdso.c
 delete mode 100644 Documentation/vDSO/vdso_standalone_test_x86.c
 delete mode 100644 Documentation/vDSO/vdso_test.c
 create mode 100644 tools/testing/selftests/filesystems/.gitignore
 create mode 100644 tools/testing/selftests/filesystems/Makefile
 create mode 100644 tools/testing/selftests/filesystems/dnotify_test.c
 create mode 100644 tools/testing/selftests/prctl/.gitignore
 create mode 100644 tools/testing/selftests/prctl/Makefile
 create mode 100644 
tools/testing/selftests/prctl/disable-tsc-ctxt-sw-stress-test.c
 create mode 100644 
tools/testing/selftests/prctl/disable-tsc-on-off-stress-test.c
 create mode 100644 tools/testing/selftests/prctl/disable-tsc-test.c
 create mode 100644 tools/testing/selftests/ptp/.gitignore
 create mode 100644 tools/testing/selftests/ptp/Makefile
 create mode 100644 

Re: [PATCH] scsi: replace broken specification URL

[Tyrel Datwyler]

On 09/09/2016 01:16 AM, Michael Opdenacker wrote:
> Hi James,
> 
> Thank you very much for your help...
> 
> On 02/07/2016 16:49, James Bottomley wrote:
>> On Sat, 2016-07-02 at 08:56 +0200, Michael Opdenacker wrote:
>>> The t10.org website containing SCSI-2 draft specifications now
>>> requires to be from a member company to access the documents.
>>>
>>> This replaces the now broken link with another public resource
>>> where the specifications can be found.
>> Just because T10 implemented a pay wall for standards, doesn't mean
>> they're not still the definitive source.
>>
>> Adding a note about where you can get free versions is a useful
>> service, please do, but we have to keep the official links.  To be
>> honest the Duisberg site doesn't seem useful because it only has the
>> CAM standard.
> 
> Understood. I found another location where all the documents seem to be 
> available:
> http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Standarde_magistrale/SCSI/

This link is just a blank page with the CSIT background image when I
follow it. This worked for me though:

http://www.csit-sun.pub.ro/~cpop/?dir=./Documentatie_SMP/Standarde_magistrale/SCSI

-Tyrel

>>
>> The Wayback machine is more useful because it keeps a copy of the site
>> (with the attached standards) just before the paywall went up:
>>
>> https://web.archive.org/web/20080828112749/http://t10.org/drafts.htm
> 
> However, the PDF file from 
> https://web.archive.org/web/20080828112749/http://t10.org/ftp/t10/drafts/cam/cam-r12b.pdf
>  
> fails to load at a 130810 byte limit. Other people have reported a 
> similar file size issue in the past.
> 
> So, should we only that the cam-r12b document can be found from 
> http://www.t10.org/t10docs.htm (registration required)?, and tell that a 
> copy can be found on 
> http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Standarde_magistrale/SCSI/?
> 
> I'm trying to fix broken links in kernel documentation, which I publish 
> on http://free-electrons.com/kerneldoc/ . I have a broken link checker 
> for the http://free-electrons.com/ website, and it finds all the broken 
> links on http://free-electrons.com/kerneldoc/ . That's a good thing, 
> isn't need, but it means I have to get rid of the broken links :)
> 
> Thanks again for your help,
> 
> Cheers,
> 
> Michael.
> 

--
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

Updating MAINTAINERS and Documentation/video4linux F: patterns

[Joe Perches]

Hello Mauro.

After all the moving of video4linux Documentation file locations
around and converting .txt files to .rst, can you please update
the appropriate MAINTAINERS sections and F: patterns?

Thanks.

--
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 4/9] selftests: move prctl tests from Documentation/prctl

[kbuild test robot]

Hi Shuah,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc5 next-20160909]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/Move-runnable-code-tests-from-Documentation-to-selftests/20160910-063538
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   scripts/Makefile.clean:14: Documentation/prctl/Makefile: No such file or 
directory
>> make[3]: *** No rule to make target 'Documentation/prctl/Makefile'.
   make[3]: Failed to remake makefile 'Documentation/prctl/Makefile'.
   make[2]: *** [Documentation/prctl] Error 2
   scripts/Makefile.clean:14: Documentation/filesystems/Makefile: No such file 
or directory
   make[3]: *** No rule to make target 'Documentation/filesystems/Makefile'.
   make[3]: Failed to remake makefile 'Documentation/filesystems/Makefile'.
   make[2]: *** [Documentation/filesystems] Error 2
   make[2]: Target '__clean' not remade because of errors.
   make[1]: *** [_clean_Documentation] Error 2
   make[1]: Target 'distclean' not remade because of errors.
   make: *** [sub-make] Error 2

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


.config.gz
Description: Binary data

Re: [PATCH 1/9] selftests: move dnotify_test from Documentation/filesystems

[kbuild test robot]

Hi Shuah,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc5 next-20160909]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/Move-runnable-code-tests-from-Documentation-to-selftests/20160910-063538
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> scripts/Makefile.build:44: Documentation/filesystems/Makefile: No such file 
>> or directory
>> make[3]: *** No rule to make target 'Documentation/filesystems/Makefile'.
   make[3]: Failed to remake makefile 'Documentation/filesystems/Makefile'.

vim +44 scripts/Makefile.build

f77bf0142 Sam Ravnborg 2007-10-15  28  ldflags-y  :=
d72e5edbf Sam Ravnborg 2007-05-28  29  
720097d89 Sam Ravnborg 2009-04-19  30  subdir-asflags-y :=
720097d89 Sam Ravnborg 2009-04-19  31  subdir-ccflags-y :=
720097d89 Sam Ravnborg 2009-04-19  32  
3156fd052 Robert P. J. Day 2008-02-18  33  # Read auto.conf if it exists, 
otherwise ignore
c955ccafc Roman Zippel 2006-06-08  34  -include include/config/auto.conf
^1da177e4 Linus Torvalds   2005-04-16  35  
20a468b51 Sam Ravnborg 2006-01-22  36  include scripts/Kbuild.include
20a468b51 Sam Ravnborg 2006-01-22  37  
3156fd052 Robert P. J. Day 2008-02-18  38  # For backward compatibility check 
that these variables do not change
0c53c8e6e Sam Ravnborg 2007-10-14  39  save-cflags := $(CFLAGS)
0c53c8e6e Sam Ravnborg 2007-10-14  40  
2a6914703 Sam Ravnborg 2005-07-25  41  # The filename Kbuild has precedence 
over Makefile
db8c1a7b2 Sam Ravnborg 2005-07-27  42  kbuild-dir := $(if $(filter 
/%,$(src)),$(src),$(srctree)/$(src))
0c53c8e6e Sam Ravnborg 2007-10-14  43  kbuild-file := $(if $(wildcard 
$(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
0c53c8e6e Sam Ravnborg 2007-10-14 @44  include $(kbuild-file)
^1da177e4 Linus Torvalds   2005-04-16  45  
0c53c8e6e Sam Ravnborg 2007-10-14  46  # If the save-* variables changed 
error out
0c53c8e6e Sam Ravnborg 2007-10-14  47  ifeq ($(KBUILD_NOPEDANTIC),)
0c53c8e6e Sam Ravnborg 2007-10-14  48  ifneq 
("$(save-cflags)","$(CFLAGS)")
49c57d254 Arnaud Lacombe   2011-08-15  49  $(error CFLAGS was 
changed in "$(kbuild-file)". Fix it to use ccflags-y)
0c53c8e6e Sam Ravnborg 2007-10-14  50  endif
0c53c8e6e Sam Ravnborg 2007-10-14  51  endif
4a5838ad9 Borislav Petkov  2011-03-01  52  

:: The code at line 44 was first introduced by commit
:: 0c53c8e6eb456cde30f2305421c605713856abc8 kbuild: check for wrong use of 
CFLAGS

:: TO: Sam Ravnborg <sam@neptun.(none)>
:: CC: Sam Ravnborg <sam@neptun.(none)>

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


.config.gz
Description: Binary data

Re: [PATCH 4/9] selftests: move prctl tests from Documentation/prctl

[kbuild test robot]

Hi Shuah,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc5 next-20160909]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/Move-runnable-code-tests-from-Documentation-to-selftests/20160910-063538
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> scripts/Makefile.build:44: Documentation/prctl/Makefile: No such file or 
>> directory
   make[3]: *** No rule to make target 'Documentation/prctl/Makefile'.
   make[3]: Failed to remake makefile 'Documentation/prctl/Makefile'.

vim +44 scripts/Makefile.build

3156fd052 Robert P. J. Day 2008-02-18  38  # For backward compatibility check 
that these variables do not change
0c53c8e6e Sam Ravnborg 2007-10-14  39  save-cflags := $(CFLAGS)
0c53c8e6e Sam Ravnborg 2007-10-14  40  
2a6914703 Sam Ravnborg 2005-07-25  41  # The filename Kbuild has precedence 
over Makefile
db8c1a7b2 Sam Ravnborg 2005-07-27  42  kbuild-dir := $(if $(filter 
/%,$(src)),$(src),$(srctree)/$(src))
0c53c8e6e Sam Ravnborg 2007-10-14  43  kbuild-file := $(if $(wildcard 
$(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
0c53c8e6e Sam Ravnborg 2007-10-14 @44  include $(kbuild-file)
^1da177e4 Linus Torvalds   2005-04-16  45  
0c53c8e6e Sam Ravnborg 2007-10-14  46  # If the save-* variables changed 
error out
0c53c8e6e Sam Ravnborg 2007-10-14  47  ifeq ($(KBUILD_NOPEDANTIC),)

:: The code at line 44 was first introduced by commit
:: 0c53c8e6eb456cde30f2305421c605713856abc8 kbuild: check for wrong use of 
CFLAGS

:: TO: Sam Ravnborg <sam@neptun.(none)>
:: CC: Sam Ravnborg <sam@neptun.(none)>

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


.config.gz
Description: Binary data

Re: [PATCH 6/9] selftests: move ptp tests from Documentation/ptp

[kbuild test robot]

Hi Shuah,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc5 next-20160909]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/Move-runnable-code-tests-from-Documentation-to-selftests/20160910-063538
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> scripts/Makefile.build:44: Documentation/ptp/Makefile: No such file or 
>> directory
>> make[3]: *** No rule to make target 'Documentation/ptp/Makefile'.
   make[3]: Failed to remake makefile 'Documentation/ptp/Makefile'.

vim +44 scripts/Makefile.build

3156fd052 Robert P. J. Day 2008-02-18  38  # For backward compatibility check 
that these variables do not change
0c53c8e6e Sam Ravnborg 2007-10-14  39  save-cflags := $(CFLAGS)
0c53c8e6e Sam Ravnborg 2007-10-14  40  
2a6914703 Sam Ravnborg 2005-07-25  41  # The filename Kbuild has precedence 
over Makefile
db8c1a7b2 Sam Ravnborg 2005-07-27  42  kbuild-dir := $(if $(filter 
/%,$(src)),$(src),$(srctree)/$(src))
0c53c8e6e Sam Ravnborg 2007-10-14  43  kbuild-file := $(if $(wildcard 
$(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
0c53c8e6e Sam Ravnborg 2007-10-14 @44  include $(kbuild-file)
^1da177e4 Linus Torvalds   2005-04-16  45  
0c53c8e6e Sam Ravnborg 2007-10-14  46  # If the save-* variables changed 
error out
0c53c8e6e Sam Ravnborg 2007-10-14  47  ifeq ($(KBUILD_NOPEDANTIC),)

:: The code at line 44 was first introduced by commit
:: 0c53c8e6eb456cde30f2305421c605713856abc8 kbuild: check for wrong use of 
CFLAGS

:: TO: Sam Ravnborg <sam@neptun.(none)>
:: CC: Sam Ravnborg <sam@neptun.(none)>

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


.config.gz
Description: Binary data

Re: [PATCH] scsi: replace broken specification URL

[Michael Opdenacker]

Hi James,

Thank you very much for your help...

On 02/07/2016 16:49, James Bottomley wrote:

On Sat, 2016-07-02 at 08:56 +0200, Michael Opdenacker wrote:

The t10.org website containing SCSI-2 draft specifications now
requires to be from a member company to access the documents.

This replaces the now broken link with another public resource
where the specifications can be found.

Just because T10 implemented a pay wall for standards, doesn't mean
they're not still the definitive source.

Adding a note about where you can get free versions is a useful
service, please do, but we have to keep the official links.  To be
honest the Duisberg site doesn't seem useful because it only has the
CAM standard.


Understood. I found another location where all the documents seem to be 
available:

http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Standarde_magistrale/SCSI/


The Wayback machine is more useful because it keeps a copy of the site
(with the attached standards) just before the paywall went up:

https://web.archive.org/web/20080828112749/http://t10.org/drafts.htm


However, the PDF file from 
https://web.archive.org/web/20080828112749/http://t10.org/ftp/t10/drafts/cam/cam-r12b.pdf 
fails to load at a 130810 byte limit. Other people have reported a 
similar file size issue in the past.


So, should we only that the cam-r12b document can be found from 
http://www.t10.org/t10docs.htm (registration required)?, and tell that a 
copy can be found on 
http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Standarde_magistrale/SCSI/?


I'm trying to fix broken links in kernel documentation, which I publish 
on http://free-electrons.com/kerneldoc/ . I have a broken link checker 
for the http://free-electrons.com/ website, and it finds all the broken 
links on http://free-electrons.com/kerneldoc/ . That's a good thing, 
isn't need, but it means I have to get rid of the broken links :)


Thanks again for your help,

Cheers,

Michael.

--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

--
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] cpufreq-stats: Minor documentation fix

[Jean Delvare]

On Fri, 9 Sep 2016 00:38:59 +0200, Rafael J. Wysocki wrote:
> On 9/8/2016 1:20 PM, Viresh Kumar wrote:
> > On 08-09-16, 12:39, Jean Delvare wrote:
> >> The cpufreq-stats code can no longer be built as a module, so it now
> >> appears with square brackets in menuconfig.
> >>
> >> Signed-off-by: Jean Delvare 
> >> Fixes: 1aefc75b2449 ("cpufreq: stats: Make the stats code non-modular")
> >> Cc: Rafael J. Wysocki 
> >> Cc: Viresh Kumar 
> >> ---
> >>   Documentation/cpu-freq/cpufreq-stats.txt |2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- linux-4.8-rc5.orig/Documentation/cpu-freq/cpufreq-stats.txt
> >> 2016-09-04 23:31:46.0 +0200
> >> +++ linux-4.8-rc5/Documentation/cpu-freq/cpufreq-stats.txt 2016-09-08 
> >> 11:34:34.805606601 +0200
> >> @@ -103,7 +103,7 @@ Config Main Menu
> >>Power management options (ACPI, APM)  --->
> >>CPU Frequency scaling  --->
> >>[*] CPU Frequency scaling
> >> -  <*>   CPU frequency translation statistics
> >> +  [*]   CPU frequency translation statistics
> >>[*] CPU frequency translation statistics details
> > Acked-by: Viresh Kumar 
> >
> Applied, but please CC PM material to linux-pm too.  That makes it much 
> easier to handle.

OK. MAINTAINERS didn't tell me so, I'll send an update in a minute.

-- 
Jean Delvare
SUSE L3 Support
--
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] cpufreq-stats: Minor documentation fix

[Viresh Kumar]

On 09-09-16, 13:03, Jean Delvare wrote:
> On Fri, 9 Sep 2016 00:38:59 +0200, Rafael J. Wysocki wrote:
> > On 9/8/2016 1:20 PM, Viresh Kumar wrote:
> > > On 08-09-16, 12:39, Jean Delvare wrote:
> > >> The cpufreq-stats code can no longer be built as a module, so it now
> > >> appears with square brackets in menuconfig.
> > >>
> > >> Signed-off-by: Jean Delvare 
> > >> Fixes: 1aefc75b2449 ("cpufreq: stats: Make the stats code non-modular")
> > >> Cc: Rafael J. Wysocki 
> > >> Cc: Viresh Kumar 
> > >> ---
> > >>   Documentation/cpu-freq/cpufreq-stats.txt |2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> --- linux-4.8-rc5.orig/Documentation/cpu-freq/cpufreq-stats.txt  
> > >> 2016-09-04 23:31:46.0 +0200
> > >> +++ linux-4.8-rc5/Documentation/cpu-freq/cpufreq-stats.txt   
> > >> 2016-09-08 11:34:34.805606601 +0200
> > >> @@ -103,7 +103,7 @@ Config Main Menu
> > >>  Power management options (ACPI, APM)  --->
> > >>  CPU Frequency scaling  --->
> > >>  [*] CPU Frequency scaling
> > >> -<*>   CPU frequency translation statistics
> > >> +[*]   CPU frequency translation statistics
> > >>  [*] CPU frequency translation statistics 
> > >> details
> > > Acked-by: Viresh Kumar 
> > >
> > Applied, but please CC PM material to linux-pm too.  That makes it much 
> > easier to handle.
> 
> OK. MAINTAINERS didn't tell me so, I'll send an update in a minute.

You sure about it?

CPU FREQUENCY DRIVERS
M:  "Rafael J. Wysocki" 
M:  Viresh Kumar 
L:  linux...@vger.kernel.org
S:  Maintained
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
T:  git git://git.linaro.org/people/vireshk/linux.git (For ARM
Updates)
F:  drivers/cpufreq/
F:  include/linux/cpufreq.h

Also, its already applied. Don't resend it.

-- 
viresh
--
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 V5] leds: trigger: Introduce a USB port trigger

[Greg KH]

On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote:
> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote:
> > From: Rafał Miłecki 
> > 
> > This commit adds a new trigger responsible for turning on LED when USB
> > device gets connected to the selected USB port. This can can useful for
> > various home routers that have USB port(s) and a proper LED telling user
> > a device is connected.
> > 
> > The trigger gets its documentation file but basically it just requires
> > enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).
> > 
> > There was a long discussion on design of this driver. Its current state
> > is a result of picking them most adjustable solution as others couldn't
> > handle all cases.
> > 
> > 1) It wasn't possible for the driver to register separated trigger for
> >each USB port. Some physical USB ports are handled by more than one
> >controller and so by more than one USB port. E.g. USB 2.0 physical
> >port may be handled by OHCI's port and EHCI's port.
> >It's also not possible to assign more than 1 trigger to a single LED
> >and implementing such feature would be tricky due to syncing triggers
> >and sysfs conflicts with old triggers.
> > 
> > 2) Another idea was to register trigger per USB hub. This wouldn't allow
> >handling devices with multiple USB LEDs and controllers (hubs)
> >controlling more than 1 physical port. It's common for hubs to have
> >few ports and each may have its own LED.
> > 
> > This final trigger is highly flexible. It allows selecting any USB ports
> > for any LED. It was also modified (compared to the initial version) to
> > allow choosing ports rather than having user /guess/ proper names. It
> > was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
> > 2 physical ports and 3 controllers.
> > 
> > Another planned feature is support for LED reacting to the USB activity.
> > This can be implemented with another sysfs file for setting mode. The
> > default mode wouldn't change so there won't be ABI breakage and such
> > feature can be safely implemented later.
> > 
> 
> It has such driver at: drivers/usb/common/led.c

Ugh, I thought I had seen something like this before...

Rafał, can you just use this in-kernel code instead?

thanks,

greg k-h
--
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 2/3] hwmon: xgene: Add hwmon driver

[James Morse]

Hi,

On 09/09/16 04:18, AKASHI Takahiro wrote:
> On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote:
>> On 08/09/16 09:14, Arnd Bergmann wrote:
>>> On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
 On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
>> +   ctx->comm_base_addr = cppc_ss->base_address;
>> +   if (ctx->comm_base_addr) {
>> +   ctx->pcc_comm_addr =
>> +   
>> acpi_os_ioremap(ctx->comm_base_addr,
>> +   cppc_ss->length);
>>
>
> This causes the arm64 allmodconfig build to fail now, according to
> kernelci:
>
>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> undefined!
>
> Should this perhaps call ioremap() or memremap() instead?
>
 Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 
 ("arm64:
 mark reserved memblock regions explicitly in iomem") starts using a 
 function
 in acpi_os_ioremap() which is not exported. On top of that, 
 memblock_is_memory()
 is declared as __init_memblock, which makes me really uncomfortable.
 If acpi_os_ioremap() must not be used by modules, and possibly only during
 early (?) initialization, maybe its declaration should state those 
 limitations ?
>>>
>>> Ah, I didn't notice that. I guess both patches were correct individually and
>>> got added to linux-next around the same time but caused allmodconfig to 
>>> blow up
>>> when used together.
>>>
>>> Adding everyone who was involved in the memblock patch to Cc here, maybe one
>>> of them has an idea what the correct fix is. There are only two other 
>>> drivers
>>> using acpi_os_ioremap() and one of them is x86-specific, so it's still 
>>> likely
>>> that drivers are not actually supposed to use this symbol. Making
>>> acpi_os_ioremap() an exported function in arm64 would also work.
>>
>> You could use acpi_os_map_iomem()/acpi_os_unmap_iomem() from acpi/acpi_io.h.
>> If there isn't an existing mapping these end up in acpi_os_ioremap(), and are
>> already EXPORT_SYMBOL_GPL().
> 
> acpi_os_ioremap() is re-defined in arm64/include/asm/acpi.h.
> 
> The problem is that, as memblock_is_memory() is declared as __init,

__init_memblock ...

... as is memblock_is_map_memory(), which we call from pfn_valid() which is
EXPORT_SYMBOL()'d
and used from modules, (e.g. mac80211.ko). So something fishy is going on...

>From include/linux/memblock.h:
> #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
> #define __init_memblock __meminit
> #define __initdata_memblock __meminitdata
> #else
> #define __init_memblock
> #define __initdata_memblock
> #endif

arm64 doesn't define ARCH_DISCARD_MEMBLOCK, so we always keep these symbols.
If we didn't, pfn_valid() would break too.


Thanks,

James


--
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 v8 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Thanks,

Tomeu

Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   29 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_drv.c |   19 +
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/i915/i915_drv.h   |3 +-
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |7 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1014 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 17 files changed, 1656 insertions(+), 914 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

--
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 V5] leds: trigger: Introduce a USB port trigger

[Rafał Miłecki]

On 9 September 2016 at 11:34, Peter Chen  wrote:
> On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote:
>> From: Rafał Miłecki 
>>
>> This commit adds a new trigger responsible for turning on LED when USB
>> device gets connected to the selected USB port. This can can useful for
>> various home routers that have USB port(s) and a proper LED telling user
>> a device is connected.
>>
>> The trigger gets its documentation file but basically it just requires
>> enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).
>>
>> There was a long discussion on design of this driver. Its current state
>> is a result of picking them most adjustable solution as others couldn't
>> handle all cases.
>>
>> 1) It wasn't possible for the driver to register separated trigger for
>>each USB port. Some physical USB ports are handled by more than one
>>controller and so by more than one USB port. E.g. USB 2.0 physical
>>port may be handled by OHCI's port and EHCI's port.
>>It's also not possible to assign more than 1 trigger to a single LED
>>and implementing such feature would be tricky due to syncing triggers
>>and sysfs conflicts with old triggers.
>>
>> 2) Another idea was to register trigger per USB hub. This wouldn't allow
>>handling devices with multiple USB LEDs and controllers (hubs)
>>controlling more than 1 physical port. It's common for hubs to have
>>few ports and each may have its own LED.
>>
>> This final trigger is highly flexible. It allows selecting any USB ports
>> for any LED. It was also modified (compared to the initial version) to
>> allow choosing ports rather than having user /guess/ proper names. It
>> was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
>> 2 physical ports and 3 controllers.
>>
>> Another planned feature is support for LED reacting to the USB activity.
>> This can be implemented with another sysfs file for setting mode. The
>> default mode wouldn't change so there won't be ABI breakage and such
>> feature can be safely implemented later.
>>
>
> It has such driver at: drivers/usb/common/led.c

Oh, great, I had no idea about that. So if it comes to adding activity
support, we'll have to well discuss that. We may e.g. not implement
that or move existing feature into more generic usbport trigger or
partially duplicate this feature.

Anyway, I hope this note on "usb-gadget" and "usb-host" triggers won't
stop our work on "usbport". This driver implements different thing for
now (discovering device in a USB port) and I don't think "usb-gadget"
/ "usb-host" could be extended to handle such cases.

Thanks for a hint though, I'll definitely keep that in mind during
further development!

-- 
Rafał
--
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 v8 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
  capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
  isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
   in the frame field.

v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.

v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov

v7:
- Move definition of drm_debugfs_crtc_crc_add to drm_internal.h

v8:
- Call debugfs_remove_recursive when we fail to create the minor
  device

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  29 +++-
 drivers/gpu/drm/drm_debugfs.c |  34 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
 drivers/gpu/drm/drm_drv.c |  19 +++
 drivers/gpu/drm/drm_internal.h|  16 ++
 include/drm/drm_crtc.h|  41 +
 include/drm/drm_debugfs_crc.h |  73 
 9 files changed, 569 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 1ba301cebe16..de3ac9f90f8f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 439d89b25ae0..60db76bbb02a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_debugfs.o drm_encoder_slave.o \
+   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -22,6 +22,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d84a0ead8100..9363dd597d3c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -141,6 +141,25 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
}
 }
 
+static int drm_crtc_crc_init(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+   spin_lock_init(>crc.lock);
+   init_waitqueue_head(>crc.wq);
+   crtc->crc.source = kstrdup("auto", GFP_KERNEL);
+   if (!crtc->crc.source)
+   return -ENOMEM;
+#endif
+   return 0;
+}
+
+static void drm_crtc_crc_fini(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+   kfree(crtc->crc.source);
+#endif
+}
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -206,6 +225,12 @@ int 

Re: [PATCH] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

On Friday, September 9, 2016 12:24:32 PM CEST Hoan Tran wrote:
> On Fri, Sep 9, 2016 at 8:38 AM, Arnd Bergmann  wrote:
> > The newly added hwmon driver fails to build in an allmodconfig
> > index bc78a5d10182..e834dfb3acca 100644
> > --- a/drivers/hwmon/xgene-hwmon.c
> > +++ b/drivers/hwmon/xgene-hwmon.c
> > @@ -34,7 +34,8 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> 
> Alphabetical order.
> 
> > struct acpi_pcct_shared_memory *generic_comm_base = 
> > ctx->pcc_comm_addr;
> > -   void *ptr = generic_comm_base + 1;
> > +   u32 *ptr = (void*)(generic_comm_base + 1);
> 
> Space before "*".

Ok.

> > @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device 
> > *pdev)
> >  */
> > ctx->comm_base_addr = cppc_ss->base_address;
> > if (ctx->comm_base_addr) {
> > -   ctx->pcc_comm_addr =
> > -   acpi_os_ioremap(ctx->comm_base_addr,
> > -   cppc_ss->length);
> > +   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
> > +   cppc_ss->length,
> > +   MEMREMAP_WT);
> 
> It should be MEMREMAP_WB. As mailbox shared memory is on RAM and our
> co-processor is also in the coherency domain.

Right, I was wondering about this, since I could not figure out what
the other side is (hardware, service processor or firmware).
So MEMREMAP_WB makes sense here.

Two more questions:

* Any comment on the byte ordering of the data in this line:

/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
-   writel_relaxed(msg[i], ptr + i * 4);
+   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));

This assumes that the old code was correct even when running on
big-endian kernels and the message data consists of 32-bit data words.
If the message has some other format instead, we would need to treat
this as a byte stream and not do swapping here but instead do it
(if any) in the code that reads or writes the actual data here.

* Are you sure you don't need any smp_rmb()/smp_wmb() barriers
between the accesses?

Arnd
--
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] hwmon: xgene: access mailbox as RAM

[Hoan Tran]

On Fri, Sep 9, 2016 at 12:58 PM, Arnd Bergmann  wrote:
> On Friday, September 9, 2016 12:24:32 PM CEST Hoan Tran wrote:
>> On Fri, Sep 9, 2016 at 8:38 AM, Arnd Bergmann  wrote:
>> > The newly added hwmon driver fails to build in an allmodconfig
>> > index bc78a5d10182..e834dfb3acca 100644
>> > --- a/drivers/hwmon/xgene-hwmon.c
>> > +++ b/drivers/hwmon/xgene-hwmon.c
>> > @@ -34,7 +34,8 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > -#include 
>> > +#include 
>>
>> Alphabetical order.
>>
>> > struct acpi_pcct_shared_memory *generic_comm_base = 
>> > ctx->pcc_comm_addr;
>> > -   void *ptr = generic_comm_base + 1;
>> > +   u32 *ptr = (void*)(generic_comm_base + 1);
>>
>> Space before "*".
>
> Ok.
>
>> > @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device 
>> > *pdev)
>> >  */
>> > ctx->comm_base_addr = cppc_ss->base_address;
>> > if (ctx->comm_base_addr) {
>> > -   ctx->pcc_comm_addr =
>> > -   
>> > acpi_os_ioremap(ctx->comm_base_addr,
>> > -   cppc_ss->length);
>> > +   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
>> > +   cppc_ss->length,
>> > +   MEMREMAP_WT);
>>
>> It should be MEMREMAP_WB. As mailbox shared memory is on RAM and our
>> co-processor is also in the coherency domain.
>
> Right, I was wondering about this, since I could not figure out what
> the other side is (hardware, service processor or firmware).
> So MEMREMAP_WB makes sense here.
>
> Two more questions:
>
> * Any comment on the byte ordering of the data in this line:
>
> /* Copy the message to the PCC comm space */
> for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
> -   writel_relaxed(msg[i], ptr + i * 4);
> +   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
>
> This assumes that the old code was correct even when running on
> big-endian kernels and the message data consists of 32-bit data words.
> If the message has some other format instead, we would need to treat
> this as a byte stream and not do swapping here but instead do it
> (if any) in the code that reads or writes the actual data here.

This is 32-bit data words.

>
> * Are you sure you don't need any smp_rmb()/smp_wmb() barriers
> between the accesses?

No, we don't need a strict read/write during access PCC subspace. Just
make sure all access is committed before PCC send message to the
platform which done by PCC mailbox driver.

Thanks
Hoan

>
> Arnd
--
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 v2] hwmon: xgene: access mailbox as RAM

[Hoan Tran]

Hi Arnd,

On Fri, Sep 9, 2016 at 1:10 PM, Arnd Bergmann  wrote:
> The newly added hwmon driver fails to build in an allmodconfig
> kernel:
>
>   ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
>
> According to comments in the code, the mailbox is a shared memory region,
> not a set of MMIO registers, so we should use memremap() for mapping it
> instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
> of readl/writel.
>
> The driver already uses plain kernel pointers, so it's a bit unusual
> to work with functions that operate on __iomem pointers, and this
> fixes that part too.
>
> I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
> regarding the ordering of the accesses from the CPU, but note that
> there are no barriers (also unchanged from before).
>
> I'm also keeping the endianess behavior, though I'm unsure whether
> the message data was supposed to be in LE32 format in the first
> place, it's possible this was meant to be interpreted as a byte
> stream instead.
>
> Signed-off-by: Arnd Bergmann 
> ---
> v2: use write-back mapping instead of write-thru,
> minor coding style changes
>
> diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
> index bc78a5d10182..e5470bd49067 100644
> --- a/drivers/hwmon/xgene-hwmon.c
> +++ b/drivers/hwmon/xgene-hwmon.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -34,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +
>  #include 
>
>  /* SLIMpro message defines */
> @@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>  {
> u16 ret, val;
>
> -   val = readw_relaxed(addr);
> +   val = le16_to_cpu(READ_ONCE(*addr));
> ret = val & mask;
> val &= ~mask;
> -   writew_relaxed(val, addr);
> +   WRITE_ONCE(*addr, cpu_to_le16(val));
>
> return ret;
>  }
> @@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
>  static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
>  {
> struct acpi_pcct_shared_memory *generic_comm_base = 
> ctx->pcc_comm_addr;
> -   void *ptr = generic_comm_base + 1;
> +   u32 *ptr = (void *)(generic_comm_base + 1);
> int rc, i;
> u16 val;
>
> @@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
> *ctx, u32 *msg)
> ctx->resp_pending = true;
>
> /* Write signature for subspace */
> -   writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
> -  _comm_base->signature);
> +   WRITE_ONCE(generic_comm_base->signature,
> +  cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
>
> /* Write to the shared command region */
> -   writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
> -  _comm_base->command);
> +   WRITE_ONCE(generic_comm_base->command,
> +  cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
>
> /* Flip CMD COMPLETE bit */
> -   val = readw_relaxed(_comm_base->status);
> +   val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
> val &= ~PCCS_CMD_COMPLETE;
> -   writew_relaxed(val, _comm_base->status);
> +   WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
>
> /* Copy the message to the PCC comm space */
> for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
> -   writel_relaxed(msg[i], ptr + i * 4);
> +   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
>
> /* Ring the doorbell */
> rc = mbox_send_message(ctx->mbox_chan, msg);
> @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
>  */
> ctx->comm_base_addr = cppc_ss->base_address;
> if (ctx->comm_base_addr) {
> -   ctx->pcc_comm_addr =
> -   acpi_os_ioremap(ctx->comm_base_addr,
> -   cppc_ss->length);
> +   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
> +   cppc_ss->length,
> +   MEMREMAP_WB);
> } else {
> dev_err(>dev, "Failed to get PCC comm 
> region\n");
> rc = -ENODEV;
>

Acked-by: Hoan Tran 
Tested-by: Hoan Tran 

Thanks
Hoan
--
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] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

On Friday, September 9, 2016 1:43:17 PM CEST Hoan Tran wrote:
> 
> > * Are you sure you don't need any smp_rmb()/smp_wmb() barriers
> > between the accesses?
> 
> No, we don't need a strict read/write during access PCC subspace. Just
> make sure all access is committed before PCC send message to the
> platform which done by PCC mailbox driver.
> 

Ok, got it. The PCC mailbox driver presumably uses writel() to
send the message, and that implies the necessary barrier
(unlike writel_relaxed), right?

Arnd

--
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 v2] hwmon: xgene: access mailbox as RAM

[Guenter Roeck]

On Fri, Sep 09, 2016 at 10:10:45PM +0200, Arnd Bergmann wrote:
> The newly added hwmon driver fails to build in an allmodconfig
> kernel:
> 
>   ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!
> 
> According to comments in the code, the mailbox is a shared memory region,
> not a set of MMIO registers, so we should use memremap() for mapping it
> instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
> of readl/writel.
> 
> The driver already uses plain kernel pointers, so it's a bit unusual
> to work with functions that operate on __iomem pointers, and this
> fixes that part too.
> 
> I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
> regarding the ordering of the accesses from the CPU, but note that
> there are no barriers (also unchanged from before).
> 
> I'm also keeping the endianess behavior, though I'm unsure whether
> the message data was supposed to be in LE32 format in the first
> place, it's possible this was meant to be interpreted as a byte
> stream instead.
> 
> Signed-off-by: Arnd Bergmann 

Applied after 's/endianess/endianness/' to make checkpatch happy.

Thanks,
Guenter
--
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 v14 04/14] task_isolation: add initial support

[Chris Metcalf]

On 9/3/2016 11:31 AM, Frederic Weisbecker wrote:

On Tue, Aug 30, 2016 at 02:17:27PM -0400, Chris Metcalf wrote:

On 8/30/2016 1:36 PM, Chris Metcalf wrote:

See the other thread with Peter Z for the longer discussion of this.
At this point I'm leaning towards replacing the set_tsk_need_resched() with

 set_current_state(TASK_INTERRUPTIBLE);
 schedule();
 __set_current_state(TASK_RUNNING);

I don't see how that helps. What will wake the thread up except a signal?

The answer is that the scheduler will keep bringing us back to this
point (either after running another runnable task if there is one,
or else just returning to this point immediately without doing a
context switch), and we will then go around the "prepare exit to
userspace" loop and perhaps discover that enough time has gone
by that the last dyntick interrupt has triggered and the kernel has
quiesced the dynticks.  At that point we stop calling schedule()
over and over and can return normally to userspace.

Oops, you're right that if I set TASK_INTERRUPTIBLE, then if I call
schedule(), I never get control back.  So I don't want to do that.

I suppose I could do a schedule_timeout() here instead and try
to figure out how long to wait for the next dyntick.  But since we
don't expect anything else running on the core anyway, it seems
like we are probably working too hard at this point.  I don't think
it's worth it just to go into the idle task and (possibly) save some
power for a few microseconds.

The more I think about this, the more I think I am micro-optimizing
by trying to poke the scheduler prior to some external thing setting
need_resched, so I think the thing to do here is in fact, nothing.

Exactly, I fear there is nothing you can do about that.


I won't worry about rescheduling but will just continue going around
the prepare-exit-to-userspace loop until the last dyn tick fires.

You mean waiting in prepare-exit-to-userspace until the last tick fires?
I'm not sure it's a good idea either, this could take ages, it could as
well never happen.


If you don't mind, let's take this to the other thread discussing what to do
at return-to-userspace time:

https://lkml.kernel.org/r/440e20d1-441a-3228-6b37-6e71e9fce...@mellanox.com

In general, I think if your task ends up waiting forever for the dyntick to
stop, with the approach suggested in that thread you will at least be
able to tell more easily, since the core will be running the idle task and
your task will be waiting on a dyntick-specific completion.


I'd rather say that if we are in signal mode, fire such, otherwise just
return to userspace. If there is a tick, it means that the environment is
not suitable for isolation anyway.


True if there is an ongoing tick, but not if the tick is about to stop and we 
just need
to wait for the last tick to fire.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

--
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 v2] hwmon: xgene: access mailbox as RAM

[Arnd Bergmann]

The newly added hwmon driver fails to build in an allmodconfig
kernel:

  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] undefined!

According to comments in the code, the mailbox is a shared memory region,
not a set of MMIO registers, so we should use memremap() for mapping it
instead of ioremap or acpi_os_ioremap, and pointer dereferences instead
of readl/writel.

The driver already uses plain kernel pointers, so it's a bit unusual
to work with functions that operate on __iomem pointers, and this
fixes that part too.

I'm using READ_ONCE/WRITE_ONCE here to keep the existing behavior
regarding the ordering of the accesses from the CPU, but note that
there are no barriers (also unchanged from before).

I'm also keeping the endianess behavior, though I'm unsure whether
the message data was supposed to be in LE32 format in the first
place, it's possible this was meant to be interpreted as a byte
stream instead.

Signed-off-by: Arnd Bergmann 
---
v2: use write-back mapping instead of write-thru,
minor coding style changes

diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
index bc78a5d10182..e5470bd49067 100644
--- a/drivers/hwmon/xgene-hwmon.c
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+
 #include 
 
 /* SLIMpro message defines */
@@ -126,10 +127,10 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 {
u16 ret, val;
 
-   val = readw_relaxed(addr);
+   val = le16_to_cpu(READ_ONCE(*addr));
ret = val & mask;
val &= ~mask;
-   writew_relaxed(val, addr);
+   WRITE_ONCE(*addr, cpu_to_le16(val));
 
return ret;
 }
@@ -137,7 +138,7 @@ static u16 xgene_word_tst_and_clr(u16 *addr, u16 mask)
 static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev *ctx, u32 *msg)
 {
struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr;
-   void *ptr = generic_comm_base + 1;
+   u32 *ptr = (void *)(generic_comm_base + 1);
int rc, i;
u16 val;
 
@@ -146,21 +147,21 @@ static int xgene_hwmon_pcc_rd(struct xgene_hwmon_dev 
*ctx, u32 *msg)
ctx->resp_pending = true;
 
/* Write signature for subspace */
-   writel_relaxed(PCC_SIGNATURE_MASK | ctx->mbox_idx,
-  _comm_base->signature);
+   WRITE_ONCE(generic_comm_base->signature,
+  cpu_to_le32(PCC_SIGNATURE_MASK | ctx->mbox_idx));
 
/* Write to the shared command region */
-   writew_relaxed(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT,
-  _comm_base->command);
+   WRITE_ONCE(generic_comm_base->command,
+  cpu_to_le16(MSG_TYPE(msg[0]) | PCCC_GENERATE_DB_INT));
 
/* Flip CMD COMPLETE bit */
-   val = readw_relaxed(_comm_base->status);
+   val = le16_to_cpu(READ_ONCE(generic_comm_base->status));
val &= ~PCCS_CMD_COMPLETE;
-   writew_relaxed(val, _comm_base->status);
+   WRITE_ONCE(generic_comm_base->status, cpu_to_le16(val));
 
/* Copy the message to the PCC comm space */
for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++)
-   writel_relaxed(msg[i], ptr + i * 4);
+   WRITE_ONCE(ptr[i], cpu_to_le32(msg[i]));
 
/* Ring the doorbell */
rc = mbox_send_message(ctx->mbox_chan, msg);
@@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev)
 */
ctx->comm_base_addr = cppc_ss->base_address;
if (ctx->comm_base_addr) {
-   ctx->pcc_comm_addr =
-   acpi_os_ioremap(ctx->comm_base_addr,
-   cppc_ss->length);
+   ctx->pcc_comm_addr = memremap(ctx->comm_base_addr,
+   cppc_ss->length,
+   MEMREMAP_WB);
} else {
dev_err(>dev, "Failed to get PCC comm region\n");
rc = -ENODEV;

--
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] hwmon: xgene: access mailbox as RAM

[Hoan Tran]

On Fri, Sep 9, 2016 at 1:50 PM, Arnd Bergmann  wrote:
> On Friday, September 9, 2016 1:43:17 PM CEST Hoan Tran wrote:
>>
>> > * Are you sure you don't need any smp_rmb()/smp_wmb() barriers
>> > between the accesses?
>>
>> No, we don't need a strict read/write during access PCC subspace. Just
>> make sure all access is committed before PCC send message to the
>> platform which done by PCC mailbox driver.
>>
>
> Ok, got it. The PCC mailbox driver presumably uses writel() to
> send the message, and that implies the necessary barrier
> (unlike writel_relaxed), right?

Yes,

Hoan
>
> Arnd
>
--
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