[PATCH] Documentation: make Makefile.sphinx no-ops quieter

[Jim Davis]

Silence the "make[1]: Nothing to be done for ..." messages for the
no-op targets in Makefile.sphinx.

Signed-off-by: Jim Davis 
---
 Documentation/Makefile.sphinx | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 707c65337ebf..b83d1160aaba 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -92,9 +92,13 @@ xmldocs:
 
 # no-ops for the Sphinx toolchain
 sgmldocs:
+   @:
 psdocs:
+   @:
 mandocs:
+   @:
 installmandocs:
+   @:
 
 cleandocs:
$(Q)rm -rf $(BUILDDIR)
-- 
2.9.3

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

Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver

[Logan Gunthorpe]

On 10/02/17 10:09 AM, Greg Kroah-Hartman wrote:
> Sure, or just wait for these to be applied to the PCI tree and then send
> a follow-on patch.  It's up to Bjorn really, as to what he wants.

Ok, I sent a working follow-on patch to this thread.

@Bjorn: I'm happy to send the patches however you like. Just let me
know. If at all possible, we'd really like to see this in for the 4.11
merge window.

Thanks,

Logan
--
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] switchtec: cleanup cdev init

[Logan Gunthorpe]

Per a suggestion from Greg Kroah-Hartman [1], don't set the cdev's
kobject parent. This allows us to use device_register instead of init
and add.

[1] https://lkml.org/lkml/2017/2/10/370
---
 drivers/pci/switch/switchtec.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 82bfd18..014eaec 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1222,24 +1222,23 @@ static struct switchtec_dev *stdev_create(struct 
pci_dev *pdev)
return ERR_PTR(minor);
 
dev = >dev;
-   device_initialize(dev);
dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
-   dev->class = switchtec_class;
-   dev->parent = >dev;
-   dev->groups = switchtec_device_groups;
-   dev->release = stdev_release;
-   dev_set_name(dev, "switchtec%d", minor);
 
cdev = >cdev;
cdev_init(cdev, _fops);
cdev->owner = THIS_MODULE;
-   cdev->kobj.parent = >kobj;
 
rc = cdev_add(>cdev, dev->devt, 1);
if (rc)
goto err_cdev;
 
-   rc = device_add(dev);
+   dev->class = switchtec_class;
+   dev->parent = >dev;
+   dev->groups = switchtec_device_groups;
+   dev->release = stdev_release;
+   dev_set_name(dev, "switchtec%d", minor);
+
+   rc = device_register(dev);
if (rc) {
cdev_del(>cdev);
put_device(dev);
-- 
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: [PATCH v2 1/4] MicroSemi Switchtec management interface driver

[Logan Gunthorpe]

On 10/02/17 09:55 AM, Greg Kroah-Hartman wrote:
> Yes, but try it yourself to verify it really is correct :)

Yes, of course... turns out it wasn't. I accidentally refereed to dev
before I assigned it. I had mainly just wanted your feedback to ensure
that switching to device_register made sense.

> And it can just be an add-on patch, no need to respin a whole new
> version for just that simple change, it doesn't hurt anything as-is,
> it's just "not needed".

Ok... How should I do that exactly? Attempt to reply to the thread with
another patch?

Thanks,

Logan
--
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/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 10:03:10AM -0700, Logan Gunthorpe wrote:
> 
> 
> On 10/02/17 09:55 AM, Greg Kroah-Hartman wrote:
> > Yes, but try it yourself to verify it really is correct :)
> 
> Yes, of course... turns out it wasn't. I accidentally refereed to dev
> before I assigned it. I had mainly just wanted your feedback to ensure
> that switching to device_register made sense.
> 
> > And it can just be an add-on patch, no need to respin a whole new
> > version for just that simple change, it doesn't hurt anything as-is,
> > it's just "not needed".
> 
> Ok... How should I do that exactly? Attempt to reply to the thread with
> another patch?

Sure, or just wait for these to be applied to the PCI tree and then send
a follow-on patch.  It's up to Bjorn really, as to what he wants.

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 v2 1/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 09:48:37AM -0700, Logan Gunthorpe wrote:
> Hey Greg,
> 
> Thanks so much for the review.
> 
> On 10/02/17 07:51 AM, Greg Kroah-Hartman wrote:
> > On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
> >> +  cdev = >cdev;
> >> +  cdev_init(cdev, _fops);
> >> +  cdev->owner = THIS_MODULE;
> >> +  cdev->kobj.parent = >kobj;
> > 
> > Minor nit, the kobject in a cdev is unlike any other kobject you have
> > ever seen, don't mess with it, it's not doing anything like you think it
> > is doing.  So no need to set the parent field.
> 
> Ok, that makes sense. I'll do a v3 shortly.
> 
> I copied this from drivers/dax/dax.c so when I have a spare moment I'll
> submit a patch to remove it from there as well.
> 
> Just to make sure I get this right without extra churn: does this look
> correct?
> 
> 
> cdev = >cdev;
> cdev_init(cdev, _fops);
> cdev->owner = THIS_MODULE;
> 
> rc = cdev_add(>cdev, dev->devt, 1);
> if (rc)
> goto err_cdev;
> 
> dev = >dev;
> dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
> dev->class = switchtec_class;
> dev->parent = >dev;
> dev->groups = switchtec_device_groups;
> dev->release = stdev_release;
> dev_set_name(dev, "switchtec%d", minor);
> 
> rc = device_register(dev);
> if (rc) {
> cdev_del(>cdev);
> put_device(dev);
> return ERR_PTR(rc);
> }
> 

Yes, but try it yourself to verify it really is correct :)

And it can just be an add-on patch, no need to respin a whole new
version for just that simple change, it doesn't hurt anything as-is,
it's just "not needed".

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 v2 1/4] MicroSemi Switchtec management interface driver

[Logan Gunthorpe]

Hey Greg,

Thanks so much for the review.

On 10/02/17 07:51 AM, Greg Kroah-Hartman wrote:
> On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
>> +cdev = >cdev;
>> +cdev_init(cdev, _fops);
>> +cdev->owner = THIS_MODULE;
>> +cdev->kobj.parent = >kobj;
> 
> Minor nit, the kobject in a cdev is unlike any other kobject you have
> ever seen, don't mess with it, it's not doing anything like you think it
> is doing.  So no need to set the parent field.

Ok, that makes sense. I'll do a v3 shortly.

I copied this from drivers/dax/dax.c so when I have a spare moment I'll
submit a patch to remove it from there as well.

Just to make sure I get this right without extra churn: does this look
correct?


cdev = >cdev;
cdev_init(cdev, _fops);
cdev->owner = THIS_MODULE;

rc = cdev_add(>cdev, dev->devt, 1);
if (rc)
goto err_cdev;

dev = >dev;
dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
dev->class = switchtec_class;
dev->parent = >dev;
dev->groups = switchtec_device_groups;
dev->release = stdev_release;
dev_set_name(dev, "switchtec%d", minor);

rc = device_register(dev);
if (rc) {
cdev_del(>cdev);
put_device(dev);
return ERR_PTR(rc);
}


Thanks,

Logan
--
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/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already well
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint with a separate
> PCI function address and class code. This endpoint enables some additional
> functionality which includes:
> 
>  * Packet and Byte Counters
>  * Switch Firmware Upgrades
>  * Event and Error logs
>  * Querying port link status
>  * Custom user firmware commands
> 
> This patch introduces the switchtec kernel module which provides
> PCI driver that exposes a char device. The char device provides
> userspace access to this interface through read, write and (optionally)
> poll calls.
> 
> A userspace tool and library which utilizes this interface is available
> at [1]. This tool takes inspiration (and borrows some code) from
> nvme-cli [2]. The tool is largely complete at this time but additional
> features may be added in the future.
> 
> [1] https://github.com/sbates130272/switchtec-user
> [2] https://github.com/linux-nvme/nvme-cli
> 
> Signed-off-by: Logan Gunthorpe 
> Signed-off-by: Stephen Bates 

Reviewed-by: Greg Kroah-Hartman 
--
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/4] MicroSemi Switchtec management interface driver

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
> + cdev = >cdev;
> + cdev_init(cdev, _fops);
> + cdev->owner = THIS_MODULE;
> + cdev->kobj.parent = >kobj;

Minor nit, the kobject in a cdev is unlike any other kobject you have
ever seen, don't mess with it, it's not doing anything like you think it
is doing.  So no need to set the parent field.

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

[PATCH v2] irqdesc: add a resource managed version of irq_alloc_descs()

[Bartosz Golaszewski]

Add a devres flavor of __devm_irq_alloc_descs() and corresponding
helper macros.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- added kernel docs for the new function
- made the from and cnt fields of struct irq_desc_devres unsigned
  integers as this is what irq_free_descs() expects
- commit message tweaks

 Documentation/driver-model/devres.txt |  5 
 include/linux/irq.h   | 19 +
 kernel/irq/devres.c   | 53 +++
 3 files changed, 77 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index ca9d1eb..bf34d5b 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -306,6 +306,11 @@ IRQ
   devm_request_any_context_irq()
   devm_request_irq()
   devm_request_threaded_irq()
+  devm_irq_alloc_descs()
+  devm_irq_alloc_desc()
+  devm_irq_alloc_desc_at()
+  devm_irq_alloc_desc_from()
+  devm_irq_alloc_descs_from()
 
 LED
   devm_led_classdev_register()
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 39e3254..f887351 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -732,6 +732,10 @@ unsigned int arch_dynirq_lower_bound(unsigned int from);
 int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
  struct module *owner, const struct cpumask *affinity);
 
+int __devm_irq_alloc_descs(struct device *dev, int irq, unsigned int from,
+  unsigned int cnt, int node, struct module *owner,
+  const struct cpumask *affinity);
+
 /* use macros to avoid needing export.h for THIS_MODULE */
 #define irq_alloc_descs(irq, from, cnt, node)  \
__irq_alloc_descs(irq, from, cnt, node, THIS_MODULE, NULL)
@@ -748,6 +752,21 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned 
int cnt, int node,
 #define irq_alloc_descs_from(from, cnt, node)  \
irq_alloc_descs(-1, from, cnt, node)
 
+#define devm_irq_alloc_descs(dev, irq, from, cnt, node)\
+   __devm_irq_alloc_descs(dev, irq, from, cnt, node, THIS_MODULE, NULL)
+
+#define devm_irq_alloc_desc(dev, node) \
+   devm_irq_alloc_descs(dev, -1, 0, 1, node)
+
+#define devm_irq_alloc_desc_at(dev, at, node)  \
+   devm_irq_alloc_descs(dev, at, at, 1, node)
+
+#define devm_irq_alloc_desc_from(dev, from, node)  \
+   devm_irq_alloc_descs(dev, -1, from, 1, node)
+
+#define devm_irq_alloc_descs_from(dev, from, cnt, node)\
+   devm_irq_alloc_descs(dev, -1, from, cnt, node)
+
 void irq_free_descs(unsigned int irq, unsigned int cnt);
 static inline void irq_free_desc(unsigned int irq)
 {
diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 74d90a7..fd0285bc 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Device resource management aware IRQ request/free implementation.
@@ -137,3 +138,55 @@ void devm_free_irq(struct device *dev, unsigned int irq, 
void *dev_id)
free_irq(irq, dev_id);
 }
 EXPORT_SYMBOL(devm_free_irq);
+
+struct irq_desc_devres {
+   unsigned int from;
+   unsigned int cnt;
+};
+
+static void devm_irq_desc_release(struct device *dev, void *res)
+{
+   struct irq_desc_devres *this = res;
+
+   irq_free_descs(this->from, this->cnt);
+}
+
+/**
+ * devm_irq_alloc_descs - allocate and initialize a range of irq
+ * descriptors for a managed device
+ * @dev: device to allocate the descriptors for
+ * @irq: allocate for specific irq number if irq >= 0
+ * @from: start the search from this irq number
+ * @cnt: number of consecutive irqs to allocate
+ * @node: preferred node on which the irq descriptor should be allocated
+ * @owner: owning module (can be NULL)
+ * @affinity: optional pointer to an affinity mask array of size @cnt
+ *which hints where the irq descriptors should be allocated
+ *and which default affinities to use
+ *
+ * Returns the first irq number or error code.
+ */
+int __devm_irq_alloc_descs(struct device *dev, int irq, unsigned int from,
+  unsigned int cnt, int node, struct module *owner,
+  const struct cpumask *affinity)
+{
+   struct irq_desc_devres *dr;
+   int base;
+
+   dr = devres_alloc(devm_irq_desc_release, sizeof(*dr), GFP_KERNEL);
+   if (!dr)
+   return -ENOMEM;
+
+   base = __irq_alloc_descs(irq, from, cnt, node, owner, affinity);
+   if (base < 0) {
+   devres_free(dr);
+   return base;
+   }
+
+   dr->from = base;
+   dr->cnt = cnt;
+   devres_add(dev, dr);
+
+   return base;
+}
+EXPORT_SYMBOL_GPL(__devm_irq_alloc_descs);
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the 

Re: [PATCH] irqdesc: add memory managed version of irq_alloc_descs()

[Thomas Gleixner]

On Tue, 7 Feb 2017, Bartosz Golaszewski wrote:
> +
> +int __devm_irq_alloc_descs(struct device *dev, int irq, unsigned int from,
> +unsigned int cnt, int node, struct module *owner,
> +const struct cpumask *affinity)

This lacks the kernel doc comment explaining the interface. Other than that
it's fine. See the other public functions in that file.

Thanks,

tglx
--
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 v7] arm64: Work around Falkor erratum 1003

[Catalin Marinas]

On Wed, Feb 08, 2017 at 03:08:37PM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
> 
> Consider the following pseudo code.
> 
>   write new BADDR and ASID values to TTBRx_EL1
> 
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
> 
>   write reserved value to TTBRx_EL1[ASID]
>   ISB
>   write new value to TTBRx_EL1[BADDR]
>   ISB
>   write new value to TTBRx_EL1[ASID]
>   ISB
> 
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.
> 
> Based on work by Shanker Donthineni 
> 
> Signed-off-by: Christopher Covington 

Reviewed-by: Catalin Marinas 
--
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