[PATCH] Documentation: make Makefile.sphinx no-ops quieter
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 linux v7 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
On 02/09/2017 11:31 PM, Joel Stanley wrote:
On Wed, Feb 8, 2017 at 9:40 AM, wrote:
From: "Edward A. James"
Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use SCOM
operations in order to access the OCC register space.
This doesn't need to be separate from the p8_occ_i2c.c file. You can
remove a layer of function calls by merging this in and having these
be your getscom putscom bus_ops callbacks.
The purpose of having this separate was so that we could do the scom
address shift for p8 separately.
Signed-off-by: Edward A. James
Signed-off-by: Andrew Jeffery
---
drivers/hwmon/occ/occ_scom_i2c.c | 77
drivers/hwmon/occ/occ_scom_i2c.h | 26 ++
2 files changed, 103 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 000..74bd6ff
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,77 @@
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ ssize_t rc;
+ u64 buf;
If you add endianness annotations sparse can check your types are
consistent. The warning looks like this:
make C=2 drivers/hwmon/occ/occ_scom_i2c.o
drivers/hwmon/occ/occ_scom_i2c.c:48:17: warning: cast to restricted __be64
Which tells you it expects the type you pass to be64_to_cpu to be __be64.
+ struct i2c_client *client = bus;
+ struct i2c_msg msgs[2];
+
+ msgs[0].addr = client->addr;
+ msgs[0].flags = client->flags & I2C_M_TEN;
+ msgs[0].len = sizeof(u32);
+ msgs[0].buf = (char *)&address;
+
+ msgs[1].addr = client->addr;
+ msgs[1].flags = client->flags & I2C_M_TEN;
+ msgs[1].flags |= I2C_M_RD;
I first thought you had made a mistake here. Instead you could do:
msgs[1].flags = client->flags & I2C_M_TEN | I2C_M_RD;
Sure. Was just copying i2c_master_recv.
+ msgs[1].len = sizeof(u64);
+ msgs[1].buf = (char *)&buf;
+
+ rc = i2c_transfer(client->adapter, msgs, 2);
+ if (rc < 0)
+ return rc;
+
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux v7 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
On 02/09/2017 11:31 PM, Joel Stanley wrote:
On Wed, Feb 8, 2017 at 9:40 AM, wrote:
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
The kernel is using reStructuredText these days. You should consider
following suit:
https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html#writing-documentation
@@ -0,0 +1,40 @@
+Kernel driver occ
+=
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
Not really - this will run on any chip that's connected to a P8 or P9.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f10c28..193a13b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9128,6 +9128,13 @@ T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/i2c/ov7670.c
+ON-CHIP CONTROLLER HWMON DRIVER
Mention P8 and P9?
+M: Eddie James
+L: linux-hw...@vger.kernel.org
Have you subscribed to this list? Would you prefer the mail to come to
the openbmc list?
+S: Maintained
+F: Documentation/hwmon/occ
+F: drivers/hwmon/occ/
+
ONENAND FLASH DRIVER
M: Kyungmin Park
L: linux-...@lists.infradead.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 190d270..e80ca81 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1240,6 +1240,8 @@ config SENSORS_NSA320
This driver can also be built as a module. If so, the module
will be called nsa320-hwmon.
+source drivers/hwmon/occ/Kconfig
+
config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2cb7e8..c7ec5d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o
obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o
obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ/
obj-$(CONFIG_PMBUS)+= pmbus/
ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c
new file mode 100644
index 000..af077f2
--- /dev/null
+++ b/drivers/hwmon/occ/occ.c
+ sensors = &resp->data.blocks[b].sensors;
+ if (!sensors) {
+ /* first poll response */
+ sensors = driver->ops.alloc_sensor(dev, sensor_type,
+ block->num_sensors);
+ if (!sensors)
+ return -ENOMEM;
+
+ resp->data.blocks[b].sensors = sensors;
+ resp->data.sensor_block_id[sensor_type] = b;
+ resp->data.blocks[b].header = *block;
+ } else if (block->sensor_length !=
+resp->data.blocks[b].header.sensor_length) {
+ dev_warn(dev,
+"different sensor length than first poll\n");
The driver has changed behaviour from your previous version; now it
discards data if the sensors change.
Under what circumstances does the sensor data change?
Yes. The sensor data shouldn't change, as far as I know. I think
something would be wrong if it did.
+ continue;
+ }
+
+ for (s = 0; s < block->num_sensors &&
+s < resp->data.blocks[b].header.num_sensors; s++) {
+ if (offset + block->sensor_length > num_bytes) {
+ dev_warn(dev, "exceeded data length\n");
+ return 0;
+ }
+
+ driver->ops.parse_sensor(data, sensors, sensor_type,
+offset, s);
+ offset += block->sensor_length;
+ }
+ }
+
+ return 0;
+}
+
+static u8 occ_send_cmd(struct occ *driver, u8 seq, u8 type, u16 length,
+ const u8 *data, u8 *resp)
+{
+ u32 cmd1, cmd2 = 0;
+ u16 checksum = 0;
+ bool retry = false;
+ int i, rc, tries = 0;
+
+ cmd1 = (seq << 24) | (type << 16) | length;
+ memcpy(&cmd2, data, length);
+ cmd2 <<= ((4 - length) * 8);
+
+ /* checksum: sum of every bytes of cmd1, cmd2 */
+ for (i = 0; i < 4; i++) {
+ checksum += (cmd1 >> (i * 8)) & 0xFF;
+ checksum += (cmd2 >> (i * 8)) & 0xFF;
+ }
+
+ cmd2 |= checksum << ((2 - length) * 8);
+
+ /* Init OCB */
You should mention what OCB means in your documentation.
+ rc = driver->bus_ops.putscom(driver->bus, OCB_STATUS_CONTROL_OR,
+OCB_OR_INIT0, OCB_OR_INIT1);
+ if (rc)
+ goto err;
+
+int occ_set_user_powercap(struct occ *occ, u16 cap)
+{
+ u8 resp[8];
+
+ cap = cpu_to_be16(cap);
+
+ retu
Re: [PATCH v2 1/4] MicroSemi Switchtec management interface driver
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
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 = &stdev->dev;
- device_initialize(dev);
dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
- dev->class = switchtec_class;
- dev->parent = &pdev->dev;
- dev->groups = switchtec_device_groups;
- dev->release = stdev_release;
- dev_set_name(dev, "switchtec%d", minor);
cdev = &stdev->cdev;
cdev_init(cdev, &switchtec_fops);
cdev->owner = THIS_MODULE;
- cdev->kobj.parent = &dev->kobj;
rc = cdev_add(&stdev->cdev, dev->devt, 1);
if (rc)
goto err_cdev;
- rc = device_add(dev);
+ dev->class = switchtec_class;
+ dev->parent = &pdev->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(&stdev->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
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
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
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 = &stdev->cdev;
> >> + cdev_init(cdev, &switchtec_fops);
> >> + cdev->owner = THIS_MODULE;
> >> + cdev->kobj.parent = &dev->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 = &stdev->cdev;
> cdev_init(cdev, &switchtec_fops);
> cdev->owner = THIS_MODULE;
>
> rc = cdev_add(&stdev->cdev, dev->devt, 1);
> if (rc)
> goto err_cdev;
>
> dev = &stdev->dev;
> dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
> dev->class = switchtec_class;
> dev->parent = &pdev->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(&stdev->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
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 = &stdev->cdev;
>> +cdev_init(cdev, &switchtec_fops);
>> +cdev->owner = THIS_MODULE;
>> +cdev->kobj.parent = &dev->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 = &stdev->cdev;
cdev_init(cdev, &switchtec_fops);
cdev->owner = THIS_MODULE;
rc = cdev_add(&stdev->cdev, dev->devt, 1);
if (rc)
goto err_cdev;
dev = &stdev->dev;
dev->devt = MKDEV(MAJOR(switchtec_devt), minor);
dev->class = switchtec_class;
dev->parent = &pdev->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(&stdev->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 0/4] New Microsemi PCI Switch Management Driver
On Thu, Feb 2, 2017 at 11:05 AM, Logan Gunthorpe wrote: > Changes since v1: > > * Rebased onto 4.10-rc6 (cleanly) > * Split the patch into a few more easily digestible patches (as > suggested by Greg Kroah-Hartman) > * Folded switchtec.c into switchtec.h (per Greg) > * Fixed a bunch of 32bit build warnings caught by the kbuild test robot > * Fixed some issues in the documentation so it has a proper > reStructredText format (as noted by Jonathan Corbet) > * Fixed padding and sizes in the IOCTL structures as noticed by Emil > Velikov and used pahole to verify their consistency across 32 and 64 > bit builds > * Reworked one of the IOCTL interfaces to be more future proof (per > Emil). > > Changes since RFC: > > * Fixed incorrect use of the drive model as pointed out by Greg > Kroah-Hartman > * Used devm functions as suggested by Keith Busch > * Added a handful of sysfs attributes to the switchtec class > * Added a handful of IOCTLs to the switchtec device > * A number of miscellaneous bug fixes > > -- > > Hi, > > This is a continuation of the RFC we posted lasted month [1] which > proposes a management driver for Microsemi's Switchtec line of PCI > switches. This hardware is still looking to be used in the Open > Compute Platform > > To make this entirely clear: the Switchtec products are compliant > with the PCI specifications and are supported today with the standard > in-kernel driver. However, these devices also expose a management endpoint > on a separate PCI function address which can be used to perform some > advanced operations. This is a driver for that function. See the patch > for more information. > > Since the RFC, we've made the changes requested by Greg Kroah-Hartman > and Keith Busch, and we've also fleshed out a number of features. We've > added a couple of IOCTLs and sysfs attributes which are documented in > the patch. Significant work has also been done on the userspace tool > which is available under a GPL license at [2]. We've also had testing > done by some of the interested parties. > > We hope to see this work included in either 4.11 or 4.12 assuming a > smooth review process. > > The patch is based off of the v4.10-rc6 release. > > Thanks for your review, Looks good to me, you can add my: Reviewed-by: Jens Axboe -- 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 3/4] switchtec: Add sysfs attributes to the Switchtec driver
On Thu, Feb 02, 2017 at 11:06:02AM -0700, Logan Gunthorpe wrote: > This patch adds a few read-only sysfs attributes which provide > some device information that is exposed from the devices. Primarily > component and device names and versions. These are documented in > Documentation/ABI/testing/sysfs-class-switchtec. > > 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
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 0/4] New Microsemi PCI Switch Management Driver
On Thu, Feb 02, 2017 at 11:05:59AM -0700, Logan Gunthorpe wrote: > Changes since v1: > > * Rebased onto 4.10-rc6 (cleanly) > * Split the patch into a few more easily digestible patches (as > suggested by Greg Kroah-Hartman) > * Folded switchtec.c into switchtec.h (per Greg) > * Fixed a bunch of 32bit build warnings caught by the kbuild test robot > * Fixed some issues in the documentation so it has a proper > reStructredText format (as noted by Jonathan Corbet) > * Fixed padding and sizes in the IOCTL structures as noticed by Emil > Velikov and used pahole to verify their consistency across 32 and 64 > bit builds > * Reworked one of the IOCTL interfaces to be more future proof (per > Emil). > > Changes since RFC: > > * Fixed incorrect use of the drive model as pointed out by Greg > Kroah-Hartman > * Used devm functions as suggested by Keith Busch > * Added a handful of sysfs attributes to the switchtec class > * Added a handful of IOCTLs to the switchtec device > * A number of miscellaneous bug fixes I didn't audit the ioctl code, but the driver model and sysfs stuff looks sane to me, nice job cleaning it up. 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
On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote: > + cdev = &stdev->cdev; > + cdev_init(cdev, &switchtec_fops); > + cdev->owner = THIS_MODULE; > + cdev->kobj.parent = &dev->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()
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 body of a message to majord
Re: [PATCH] irqdesc: add memory managed version of irq_alloc_descs()
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
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
