Re: [PATCH] scsi: replace broken specification URL

[Laurence Oberman]

- Original Message -
> From: "Martin K. Petersen" 
> To: "Michael Opdenacker" 
> Cc: cor...@lwn.net, j...@linux.vnet.ibm.com, "martin petersen" 
> ,
> linux-doc@vger.kernel.org, linux-ker...@vger.kernel.org, 
> linux-s...@vger.kernel.org
> Sent: Thursday, September 15, 2016 10:06:19 AM
> Subject: Re: [PATCH] scsi: replace broken specification URL
> 
> > "Michael" == Michael Opdenacker 
> > writes:
> 
> Michael> + * 'cam-r12b.pdf' document on http://www.t10.org/t10docs.htm
> Michael> + * (registration required)
> 
> That link really should be http://www.t10.org/drafts.htm. You can't look
> up draft specifications using the proposal document search form.
> 
> --
> Martin K. PetersenOracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
I looked up the original URL when reviewing, and missed the Proposal Heading.
Checked the one Martin referred to and agree with Martin's change as well.



--
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] scsi: replace broken specification URL

[Laurence Oberman]

- Original Message -
> From: "Michael Opdenacker" 
> To: cor...@lwn.net, j...@linux.vnet.ibm.com, "martin petersen" 
> 
> Cc: linux-doc@vger.kernel.org, linux-ker...@vger.kernel.org, 
> linux-s...@vger.kernel.org, "Michael Opdenacker"
> 
> Sent: Thursday, September 15, 2016 9:03:05 AM
> Subject: [PATCH] scsi: replace broken specification URL
> 
> The t10.org website containing SCSI-2 draft specifications now requires
> to be from a member company to access the documents.
> 
> Signed-off-by: Michael Opdenacker 
> ---
>  Documentation/DocBook/scsi.tmpl | 6 +++---
>  drivers/scsi/scsicam.c  | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/DocBook/scsi.tmpl
> b/Documentation/DocBook/scsi.tmpl
> index 4b9b9b286cea..b8b646426321 100644
> --- a/Documentation/DocBook/scsi.tmpl
> +++ b/Documentation/DocBook/scsi.tmpl
> @@ -160,9 +160,9 @@
>
>  drivers/scsi/scsicam.c
>  
> -   url='http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf'>SCSI
> -  Common Access Method support functions, for use with
> -  HDIO_GETGEO, etc.
> +  SCSI Common Access
> +   Method support functions ('cam-r12b.pdf' document,
> +   registration required), for use with HDIO_GETGEO, etc.
>  
>  !Edrivers/scsi/scsicam.c
>
> diff --git a/drivers/scsi/scsicam.c b/drivers/scsi/scsicam.c
> index 910f4a7a3924..5c446d9ef468 100644
> --- a/drivers/scsi/scsicam.c
> +++ b/drivers/scsi/scsicam.c
> @@ -207,7 +207,8 @@ EXPORT_SYMBOL(scsi_partsize);
>   *
>   * WORKINGX3T9.2
>   * DRAFT792D
> - * see http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf
> + * 'cam-r12b.pdf' document on http://www.t10.org/t10docs.htm
> + * (registration required)
>   *
>   *Revision 6
>   * 10-MAR-94
> --
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Looks right matching what James wanted as well.
Reviewed-by: Laurence Oberman 
--
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] docs/driver-model: fix typo

[Laurent Navet]

No need to be be, just be should be sufficient.

Signed-off-by: Laurent Navet 
---
 Documentation/driver-model/device.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/driver-model/device.txt 
b/Documentation/driver-model/device.txt
index 1e70220..2403eb8 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -50,7 +50,7 @@ Attributes of devices can be exported by a device driver 
through sysfs.
 Please see Documentation/filesystems/sysfs.txt for more information
 on how sysfs works.
 
-As explained in Documentation/kobject.txt, device attributes must be be
+As explained in Documentation/kobject.txt, device attributes must be
 created before the KOBJ_ADD uevent is generated. The only way to realize
 that is by defining an attribute group.
 
-- 
2.1.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: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Leon Romanovsky]

On Wed, Sep 14, 2016 at 12:36:19PM +0530, Parav Pandit wrote:
> Hi Dennis,
>
> Do you know how would HFI1 driver would work along with rdma cgroup?
>
> Hi Matan, Leon, Jason,
> Apart from HFI1, is there any other concern?
> Or Patch is good to go?

I didn't review it yet :(.
Sorry

>
> 4.8 dates are close by (2 weeks) and there are two git trees involved
> (that might cause merge error to Linus) so if there are no issues, I
> would like to make request to Doug to consider it for 4.8 early on.
>
> Parav
>
> On Mon, Sep 12, 2016 at 10:37 AM, Leon Romanovsky  wrote:
> > On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> >> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> >> > > > > I've posted some initial work toward a) a while ago, and once we
> >> > >
> >> > > Did it get merged? Do you have a pointer?
> >> >
> >> > http://www.spinics.net/lists/linux-rdma/msg31958.html
> >>
> >> Right, I remember that. Certainly the right direction
> >>
> >> > > However, everything under verbs is not straightforward. The files in
> >> > > userspace are not copies...
> >> > >
> >> > > user:
> >> > >
> >> > > struct ibv_query_device {
> >> > >__u32 command;
> >> > >__u16 in_words;
> >> > >__u16 out_words;
> >> > >__u64 response;
> >> > >__u64 driver_data[0];
> >> > > };
> >> > >
> >> > > kernel:
> >> > >
> >> > > struct ib_uverbs_query_device {
> >> > > __u64 response;
> >> > > __u64 driver_data[0];
> >> > > };
> >> >
> >> > We'll obviously need different strutures for the libibvers API
> >> > and the kernel interface in this case, and we'll need to figure out
> >> > how to properly translate them.  I think a cast, plus compile time
> >> > type checking ala BUILD_BUG_ON is the way to go.
> >>
> >> I'm not sure I follow, which would I cast?
> >>
> >> BUILD_BUG_ON(sizeof(ibv_query_device) == sizeof(ib_uverbs_cmd_hdr) +
> >>  sizeof(ib_uverbs_query_device))
> >>
> >> ?
> >>
> >> > > I'm thinking the best way forward might be to use a script and
> >> > > transform userspace into:
> >> > >
> >> > > struct ibv_query_device {
> >> > >   struct ib_uverbs_cmd_hdr hdr;
> >> > >   struct ib_uverbs_query_device cmd;
> >> > > };
> >> >
> >> > That would break the users of the interface.
> >>
> >> Sorry, I mean doing this inside rdma-plumbing. Since the change is ABI
> >> identical the modified libibverbs would still be binary compatible
> >> with all providers but not source compatible. Since all kernel
> >> supported providers are in rdma-plumbing we can add the '.cmd.' at the
> >> same time.
> >>
> >> The kernel uapi header would stay the same.
> >>
> >> > However automatically generating the user ABI from the kernel one
> >> > might still be a good idea in the long run.
> >>
> >> My preference would be to try and use the kernel headers directly.
> >
> > I thought the same, especially after realizing that they are almost
> > copy/paste from the vendor *-abi.h files.
> >
> >>
> >> Jason


signature.asc
Description: PGP signature

Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

[Tom Lendacky]

On 09/14/2016 09:51 AM, Borislav Petkov wrote:
> On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote:
>> This is still required because just using the __va() would still cause
>> the mapping created to have the encryption bit set. The ioremap call
>> will result in the mapping not having the encryption bit set.
> 
> I meant this: https://lkml.kernel.org/r/20160902181447.ga25...@nazgul.tnic
> 
> Wouldn't simply clearing the SME mask work?
> 
> #define __va(x)   ((void *)(((unsigned 
> long)(x)+PAGE_OFFSET) & ~sme_me_mask))
> 
> Or are you saying, one needs the whole noodling through ioremap_cache()
> because the data is already encrypted and accessing it with sme_me_mask
> cleared would simply give you the encrypted garbage?

The problem is that this physical address does not contain the
encryption bit, and even if it did, it wouldn't matter.  The __va()
define creates a virtual address that will be mapped as encrypted given
the current approach (which is how I found this).  It's only ioremap()
that would create a mapping without the encryption attribute and since
this is unencrypted data it needs to be access accordingly.

Thanks,
Tom

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

[Tom Lendacky]

On 09/15/2016 04:57 AM, Matt Fleming wrote:
> On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote:
>> On 09/12/2016 11:55 AM, Andy Lutomirski wrote:
>>> On Aug 22, 2016 6:53 PM, "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.
>>>
>>> What happens when you memremap boot services data outside of early
>>> boot?  Matt just added code that does this.
>>>
>>> IMO this API is not so great.  It scatters a specialized consideration
>>> all over the place.  Could early_memremap not look up the PA to figure
>>> out what to do?
>>
>> Yes, I could see if the PA falls outside of the kernel usable area and,
>> if so, remove the memory encryption attribute from the mapping (for both
>> early_memremap and memremap).
>>
>> Let me look into that, I would prefer something along that line over
>> this change.
> 
> So, the last time we talked about using the address to figure out
> whether to encrypt/decrypt you said,
> 
>  "I looked into this and this would be a large change also to parse
>   tables and build lists."
> 
> Has something changed that makes this approach easier?

The original idea of parsing the tables and building a list was
a large change.  This approach would be simpler by just checking if
the PA is outside the kernel usable area, and if so, removing the
encryption bit.

> 
> And again, you need to be careful with the EFI kexec code paths, since
> you've got a mixture of boot and kernel data being passed. In
> particular the EFI memory map is allocated by the firmware on first
> boot (BOOT_DATA) but by the kernel on kexec (KERNEL_DATA).
> 
> That's one of the reasons I suggested requiring the caller to decide
> on BOOT_DATA vs KERNEL_DATA - when you start looking at kexec the
> distinction isn't easily made.

Yeah, for kexec I think I'll need to make sure that everything looks
like it came from the BIOS/UEFI/bootloader.  If all of the kexec
pieces are allocated with un-encrypted memory, then the boot path
should remain the same.  That's the piece I need to investigate
further.

Thanks,
Tom

> 
--
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 15/20] iommu/amd: AMD IOMMU support for memory encryption

[Tom Lendacky]

On 09/14/2016 09:41 AM, Borislav Petkov wrote:
> On Wed, Sep 14, 2016 at 08:45:44AM -0500, Tom Lendacky wrote:
>> Currently, mem_encrypt.h only lives in the arch/x86 directory so it
>> wouldn't be able to be included here without breaking other archs.
> 
> I'm wondering if it would be simpler to move only sme_me_mask to an
> arch-agnostic header just so that we save us all the code duplication.
> 
> Hmmm.

If I do that, then I could put an #ifdef in the header to include the
asm/mem_encrypt.h if the memory encryption is configured, else set the
value to zero.  I'll look into this.  One immediate question becomes do
we keep the name very specific vs. making it more generic, sme_me_mask
vs me_mask, etc.

Thanks,
Tom

> 
--
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] selftests: Move networking/timestamping from Documentation

[Shuah Khan]

Remove networking from Documentation Makefile to move the test to
selftests. Update networking/timestamping Makefile to work under
selftests. These tests will not be run as part of selftests suite
and will not be included in install targets. They can be built and
run separately for now.

This is part of the effort to move runnable code from Documentation.

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile |   3 +-
 Documentation/networking/Makefile  |   1 -
 Documentation/networking/timestamping/.gitignore   |   3 -
 Documentation/networking/timestamping/Makefile |  14 -
 .../networking/timestamping/hwtstamp_config.c  | 134 -
 .../networking/timestamping/timestamping.c | 528 
 .../networking/timestamping/txtimestamp.c  | 549 -
 .../selftests/networking/timestamping/.gitignore   |   3 +
 .../selftests/networking/timestamping/Makefile |   8 +
 .../networking/timestamping/hwtstamp_config.c  | 134 +
 .../networking/timestamping/timestamping.c | 528 
 .../networking/timestamping/txtimestamp.c  | 549 +
 12 files changed, 1223 insertions(+), 1231 deletions(-)
 delete mode 100644 Documentation/networking/Makefile
 delete mode 100644 Documentation/networking/timestamping/.gitignore
 delete mode 100644 Documentation/networking/timestamping/Makefile
 delete mode 100644 Documentation/networking/timestamping/hwtstamp_config.c
 delete mode 100644 Documentation/networking/timestamping/timestamping.c
 delete mode 100644 Documentation/networking/timestamping/txtimestamp.c
 create mode 100644 tools/testing/selftests/networking/timestamping/.gitignore
 create mode 100644 tools/testing/selftests/networking/timestamping/Makefile
 create mode 100644 
tools/testing/selftests/networking/timestamping/hwtstamp_config.c
 create mode 100644 
tools/testing/selftests/networking/timestamping/timestamping.c
 create mode 100644 
tools/testing/selftests/networking/timestamping/txtimestamp.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 572e9b7..f530c29 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,3 +1,2 @@
 subdir-y := accounting auxdisplay blackfin \
-   laptops mic misc-devices \
-   networking pcmcia timers watchdog
+   laptops mic misc-devices pcmcia timers watchdog
diff --git a/Documentation/networking/Makefile 
b/Documentation/networking/Makefile
deleted file mode 100644
index 4c5d7c4..000
--- a/Documentation/networking/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-subdir-y := timestamping
diff --git a/Documentation/networking/timestamping/.gitignore 
b/Documentation/networking/timestamping/.gitignore
deleted file mode 100644
index 9e69e98..000
--- a/Documentation/networking/timestamping/.gitignore
+++ /dev/null
@@ -1,3 +0,0 @@
-timestamping
-txtimestamp
-hwtstamp_config
diff --git a/Documentation/networking/timestamping/Makefile 
b/Documentation/networking/timestamping/Makefile
deleted file mode 100644
index 8c20dfa..000
--- a/Documentation/networking/timestamping/Makefile
+++ /dev/null
@@ -1,14 +0,0 @@
-# To compile, from the source root
-#
-#make headers_install
-#make M=documentation
-
-# List of programs to build
-hostprogs-y := hwtstamp_config timestamping txtimestamp
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_timestamping.o += -I$(objtree)/usr/include
-HOSTCFLAGS_txtimestamp.o += -I$(objtree)/usr/include
-HOSTCFLAGS_hwtstamp_config.o += -I$(objtree)/usr/include
diff --git a/Documentation/networking/timestamping/hwtstamp_config.c 
b/Documentation/networking/timestamping/hwtstamp_config.c
deleted file mode 100644
index e8b685a..000
--- a/Documentation/networking/timestamping/hwtstamp_config.c
+++ /dev/null
@@ -1,134 +0,0 @@
-/* Test program for SIOC{G,S}HWTSTAMP
- * Copyright 2013 Solarflare Communications
- * Author: Ben Hutchings
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-static int
-lookup_value(const char **names, int size, const char *name)
-{
-   int value;
-
-   for (value = 0; value < size; value++)
-   if (names[value] && strcasecmp(names[value], name) == 0)
-   return value;
-
-   return -1;
-}
-
-static const char *
-lookup_name(const char **names, int size, int value)
-{
-   return (value >= 0 && value < size) ? names[value] : NULL;
-}
-
-static void list_names(FILE *f, const char **names, int size)
-{
-   int value;
-
-   for (value = 0; value < size; value++)
-   if (names[value])
-   fprintf(f, "%s\n", names[value]);
-}
-
-static const char *tx_types[] = {
-#define TX_TYPE(name) [HWTSTAMP_TX_ ## name] = #name
-   TX_TYPE(OFF),
-   TX_TYPE(ON),
-   TX_TYPE(ONESTEP_SYNC)
-#undef TX_TYPE
-};
-#define N_TX_TYPES 

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

[Jacek Anaszewski]

On 09/15/2016 03:33 PM, Rafał Miłecki wrote:

On 15 September 2016 at 14:56, Pavel Machek  wrote:

On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote:

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.


In any case, the new driver should probably go near the old one, at
the very least.


I can do that. Anyone objects?



It's OK with me.

--
Best regards,
Jacek Anaszewski
--
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 Thu, Sep 15, 2016 at 09:18:28AM -0400, Steven Rostedt wrote:
> On Thu, 15 Sep 2016 14:17:06 +0200
> Michael Opdenacker  wrote:
> 
> > Fix 4 LKML archive links that became broken
> > (issue with https://lkml.kernel.org/g/ redirection links)
> > 
> > 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..1c39a2362911 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
> > + > href="https://lkml.kernel.org/r/20090113221724.ga15...@linux.vnet.ibm.com;>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.
> > +> href="https://lkml.kernel.org/r/20100319013024.GA28456@Krystal;>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
> > - > href="https://lkml.kernel.org/g/ca+55afy4wccwal4okts8wxhgz5h-ibecy_meg9c4mnqrunw...@mail.gmail.com;>remind
> > + > href="https://lkml.kernel.org/r/ca+55afy4wccwal4okts8wxhgz5h-ibecy_meg9c4mnqrunw...@mail.gmail.com;>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
> > - > href="https://lkml.kernel.org/g/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com;>surprised
> >  me
> > + > href="https://lkml.kernel.org/r/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com;>surprised
> >  me
> >  with this requirement;
> >  he also kindly surprised me with
> >   > href="https://lkml.kernel.org/g/CALCETrXSY9JpW3uE6H8WYk81sg56qasA2aqmjMPsq5dOtzso=g...@mail.gmail.com;>an
> >  algorithm
> 
> Strange that this one still works. Anyway...
> 
> 
> Acked-by: Steven Rostedt 

So we are confident that these links won't be fixed by the next merge
window?

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 v2 1/3] drivers/of: recognize status property of dt memory nodes

[Reza Arbab]

On Thu, Sep 15, 2016 at 08:43:08AM -0500, Rob Herring wrote:

On Wed, Sep 14, 2016 at 3:06 PM, Reza Arbab  wrote:

+   status = of_get_flat_dt_prop(node, "status", NULL);
+   add_memory = !status || !strcmp(status, "okay");


Move this into it's own function to mirror the unflattened version
(of_device_is_available). Also, make sure the logic is the same. IIRC,
"ok" is also allowed.


Will do. 


@@ -1057,6 +1062,9 @@ int __init early_init_dt_scan_memory(unsigned long node, 
const char *uname,
pr_debug(" - %llx ,  %llx\n", (unsigned long long)base,
(unsigned long long)size);

+   if (!add_memory)
+   continue;


There's no point in checking this in the loop. status applies to the
whole node. Just return up above.


I was trying to preserve that pr_debug output for these nodes, but I'm 
also fine with skipping it.


Thanks for your feedback! I'll spin a v3 of this patchset soon.

--
Reza Arbab

--
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] scsi: replace broken specification URL

[Martin K. Petersen]

> "Michael" == Michael Opdenacker  
> writes:

Michael> + * 'cam-r12b.pdf' document on http://www.t10.org/t10docs.htm
Michael> + * (registration required)

That link really should be http://www.t10.org/drafts.htm. You can't look
up draft specifications using the proposal document search form.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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 1/3] drivers/of: recognize status property of dt memory nodes

[Rob Herring]

On Wed, Sep 14, 2016 at 3:06 PM, Reza Arbab  wrote:
> Respect the standard dt "status" property when scanning memory nodes in
> early_init_dt_scan_memory(), so that if the property is present and not
> "okay", no memory will be added.
>
> The use case at hand is accelerator or device memory, which may be
> unusable until post-boot initialization of the memory link. Such a node
> can be described in the dt as any other, given its status is "disabled".
> Per the device tree specification,
>
> "disabled"
> Indicates that the device is not presently operational, but it
> might become operational in the future (for example, something
> is not plugged in, or switched off).
>
> Once such memory is made operational, it can then be hotplugged.
>
> Signed-off-by: Reza Arbab 
> ---
>  drivers/of/fdt.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 085c638..fc19590 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1022,8 +1022,10 @@ int __init early_init_dt_scan_memory(unsigned long 
> node, const char *uname,
>  int depth, void *data)
>  {
> const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> +   const char *status;
> const __be32 *reg, *endp;
> int l;
> +   bool add_memory;
>
> /* We are scanning "memory" nodes only */
> if (type == NULL) {
> @@ -1044,6 +1046,9 @@ int __init early_init_dt_scan_memory(unsigned long 
> node, const char *uname,
>
> endp = reg + (l / sizeof(__be32));
>
> +   status = of_get_flat_dt_prop(node, "status", NULL);
> +   add_memory = !status || !strcmp(status, "okay");

Move this into it's own function to mirror the unflattened version
(of_device_is_available). Also, make sure the logic is the same. IIRC,
"ok" is also allowed.

> +
> pr_debug("memory scan node %s, reg size %d,\n", uname, l);
>
> while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
> @@ -1057,6 +1062,9 @@ int __init early_init_dt_scan_memory(unsigned long 
> node, const char *uname,
> pr_debug(" - %llx ,  %llx\n", (unsigned long long)base,
> (unsigned long long)size);
>
> +   if (!add_memory)
> +   continue;

There's no point in checking this in the loop. status applies to the
whole node. Just return up above.

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

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

[Steven Rostedt]

On Thu, 15 Sep 2016 14:17:06 +0200
Michael Opdenacker  wrote:

> Fix 4 LKML archive links that became broken
> (issue with https://lkml.kernel.org/g/ redirection links)
> 
> 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..1c39a2362911 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
> + href="https://lkml.kernel.org/r/20090113221724.ga15...@linux.vnet.ibm.com;>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.
> +  href="https://lkml.kernel.org/r/20100319013024.GA28456@Krystal;>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
> - href="https://lkml.kernel.org/g/ca+55afy4wccwal4okts8wxhgz5h-ibecy_meg9c4mnqrunw...@mail.gmail.com;>remind
> + href="https://lkml.kernel.org/r/ca+55afy4wccwal4okts8wxhgz5h-ibecy_meg9c4mnqrunw...@mail.gmail.com;>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
> - href="https://lkml.kernel.org/g/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com;>surprised
>  me
> + href="https://lkml.kernel.org/r/CALCETrXLq1y7e_dKFPgou-FKHB6Pu-r8+t-6Ds+8=va7anb...@mail.gmail.com;>surprised
>  me
>  with this requirement;
>  he also kindly surprised me with
>   href="https://lkml.kernel.org/g/CALCETrXSY9JpW3uE6H8WYk81sg56qasA2aqmjMPsq5dOtzso=g...@mail.gmail.com;>an
>  algorithm

Strange that this one still works. Anyway...


Acked-by: Steven Rostedt 

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

[PATCH] scsi: replace broken specification URL

[Michael Opdenacker]

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

Signed-off-by: Michael Opdenacker 
---
 Documentation/DocBook/scsi.tmpl | 6 +++---
 drivers/scsi/scsicam.c  | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/DocBook/scsi.tmpl b/Documentation/DocBook/scsi.tmpl
index 4b9b9b286cea..b8b646426321 100644
--- a/Documentation/DocBook/scsi.tmpl
+++ b/Documentation/DocBook/scsi.tmpl
@@ -160,9 +160,9 @@
   
 drivers/scsi/scsicam.c
 
-  SCSI
-  Common Access Method support functions, for use with
-  HDIO_GETGEO, etc.
+  SCSI Common Access
+ Method support functions ('cam-r12b.pdf' document,
+ registration required), for use with HDIO_GETGEO, etc.
 
 !Edrivers/scsi/scsicam.c
   
diff --git a/drivers/scsi/scsicam.c b/drivers/scsi/scsicam.c
index 910f4a7a3924..5c446d9ef468 100644
--- a/drivers/scsi/scsicam.c
+++ b/drivers/scsi/scsicam.c
@@ -207,7 +207,8 @@ EXPORT_SYMBOL(scsi_partsize);
  *
  * WORKINGX3T9.2
  * DRAFT792D
- * see http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf
+ * 'cam-r12b.pdf' document on http://www.t10.org/t10docs.htm
+ * (registration required)
  *
  *Revision 6
  * 10-MAR-94
-- 
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] scsi: replace broken specification URL

[Michael Opdenacker]

Hi Martin,

On 14/09/2016 19:00, Martin K. Petersen wrote:


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

As inconvenient as the T10/ANSI restrictions are, we should not be
linking to illegitimate spec repositories.


I agree with you. The documents do not allow copy without permission, so 
the copies we found are illegitimate indeed.


Now I know what patch to send, to get rid of the broken link :)

Thanks,

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

[Michael Opdenacker]

Hi Steve,

On 09/09/2016 16:34, Steven Rostedt wrote:

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.


I confirm that all the links work indeed. I'm sending a patch update 
right away.


Thanks!

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

[Michael Opdenacker]

Richard, Paul,

Thank you for your replies!

On 09/09/2016 16:33, Paul E. McKenney wrote:

On Fri, Sep 09, 2016 at 04:17:14PM +0200, Richard Weinberger wrote:
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


Done. I reported this issue to them and will keep an eye on it. I 
definitely agree that we shouldn't use the message ids. Otherwise, 
that's really a lot of detective work to find out which message was 
referred to. That's very good advise.


Thanks,

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

[Matt Fleming]

On Wed, 14 Sep, at 09:20:44AM, Tom Lendacky wrote:
> On 09/12/2016 11:55 AM, Andy Lutomirski wrote:
> > On Aug 22, 2016 6:53 PM, "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.
> > 
> > What happens when you memremap boot services data outside of early
> > boot?  Matt just added code that does this.
> > 
> > IMO this API is not so great.  It scatters a specialized consideration
> > all over the place.  Could early_memremap not look up the PA to figure
> > out what to do?
> 
> Yes, I could see if the PA falls outside of the kernel usable area and,
> if so, remove the memory encryption attribute from the mapping (for both
> early_memremap and memremap).
> 
> Let me look into that, I would prefer something along that line over
> this change.

So, the last time we talked about using the address to figure out
whether to encrypt/decrypt you said,

 "I looked into this and this would be a large change also to parse
  tables and build lists."

Has something changed that makes this approach easier?

And again, you need to be careful with the EFI kexec code paths, since
you've got a mixture of boot and kernel data being passed. In
particular the EFI memory map is allocated by the firmware on first
boot (BOOT_DATA) but by the kernel on kexec (KERNEL_DATA).

That's one of the reasons I suggested requiring the caller to decide
on BOOT_DATA vs KERNEL_DATA - when you start looking at kexec the
distinction isn't easily made.
--
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 00/11] pci: support for configurable PCI endpoint

[Kishon Vijay Abraham I]

Hi Arnd,

On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I 
> wrote:
>> This patch series
>>  *) adds PCI endpoint core layer
>>  *) modifies designware/dra7xx driver to be configured in EP mode
>>  *) adds a PCI endpoint *test* function driver
> 
> Hi Kishon,
> 
> I think this is a great start, thanks for posting early with a clear
> list of limitations and TODO items.

Thank you :-)
> 
> I've added the drivers/ntb maintainers to Cc, given that there is
> a certain degree of overlap between your work and the existing
> code, I think they should be part of the discussion.
>  
>> Known Limitation:
>>  *) Does not support multi-function devices
> 
> If I understand it right, this was a problem for USB and adding
> it later made it somewhat inconsistent. Maybe we can at least
> try to come up with an idea of how multi-function devices
> could be handled even if we don't implement it until someone
> actually needs it.

Actually IMO multi-function device in PCI should be much simpler than it is for
USB. In the case of USB, all the functions in a multi-function device will
share the same *usb configuration* . (USB device can have multiple
configuration but only one can be enabled at a time). A multi-function USB
device will still have a single vendor-id/product-id/class... So I think a
separate library (composite.c) in USB makes sense.

But in the case of PCI, every function can be treated independently since all
the functions have it's own 4KB configuration space. Each function can be
configured independently. Each can have it's own vendor-id/product-id/class..
I'm not sure if we'll need a separate library for PCI like we have for USB.

Now the restriction for not allowing multi-function device is because of the
following structure definition.

struct pci_epc {
..
struct pci_epf *epf;
..
};

EPC has a single reference to EPF and it is used *only* to notify the function
driver when the link is up. (If this can be changed to use notification
mechanism, multi-function devices can be supported here)

One more place where this restriction arises is in designware driver

struct dw_pcie_ep {
..
u8 bar_to_atu[6];
..
};

We use single ATU window to configure a BAR (in BAR). If there are multiple
functions, then this should also be modified since each function has 6 BARs.

This can be fixed without much effort unless some other issue props up.

> 
> Is your hardware able to make the PCIe endpoint look like
> a device with multiple PCI functions, or would one have to
> do this in software inside of a single PCI function if we
> ever need it?

The hardware I have doesn't support multiple PCI functions (like having a
separate configuration space for each function). It has a dedicated space for
configuration space supporting only one function. [Section 24.9.7.3.2
PCIe_SS_EP_CFG_DBICS Register Description in  [1]].

yeah, it has to be done in software (but that won't be multi-function device in
PCI terms).

[1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
> 
>> TODO:
>>  *) access buffers in RC
>>  *) raise MSI interrupts
>>  *) Enable user space control for the RC side PCI driver
> 
> The user space control would end up just being one of several
> gadget drivers, right? E.g. gadget drivers for standard hardware
> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
> drivers while a user space driver can be used for things that
> are more unusual and that don't need to interface to another
> part of the kernel?

Actually I didn't mean that. It was more with respect to the host side PCI test
driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
itself. I wanted to change this so that the user controls which tests to run.
(Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
tests). Similarly I want to have a userspace program invoke pci_endpoint_test
to perform various PCI tests.
> 
>>  *) Adapt all other users of designware to use the new design (only
>> dra7xx has been adapted)
> 
> I don't fully understand this part. Does every designware based
> driver need modifications, or are the changes to the
> generic parts of the designware driver enough to make it
> work for the simpler platforms?

I have changed the core designware driver structures (like previously the
platform drivers will only use pcie_port, but now I introduced struct dw_pcie
to support both host and endpoint). This will break (compilation failure) all
the designware based drivers (except dra7xx). All these drivers should be
adapted to the new change (even if they work only in host mode these has to be
adapted).
> 
>> HOW TO:
>>
>> ON THE EP SIDE:
>> ***
>>
>> /* EP function is configured using configfs */
>> # mount -t configfs none /sys/kernel/config
>>
>> /* PCI EP core layer creates "pci_ep" entry in configfs */