* [PATCH v7 15/16] drivers: acpi: iort: add single mapping function
From: Lorenzo Pieralisi @ 2016-11-09 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
The current IORT id mapping API requires components to provide
an input requester ID (a Bus-Device-Function (BDF) identifier for
PCI devices) to translate an input identifier to an output
identifier through an IORT range mapping.
Named components do not have an identifiable source ID therefore
their respective input/output mapping can only be defined in
IORT tables through single mappings, that provide a translation
that does not require any input identifier.
Current IORT interface for requester id mappings (iort_node_map_rid())
is not suitable for components that do not provide a requester id,
so it cannot be used for IORT named components.
Add an interface to the IORT API to enable retrieval of id
by allowing an indexed walk of the single mappings array for
a given component, therefore completing the IORT mapping API.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 62057c6..7d30605 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -318,6 +318,45 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
return 0;
}
+static
+struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
+ u32 *id_out, u8 type_mask,
+ int index)
+{
+ struct acpi_iort_node *parent;
+ struct acpi_iort_id_mapping *map;
+
+ if (!node->mapping_offset || !node->mapping_count ||
+ index >= node->mapping_count)
+ return NULL;
+
+ map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
+ node->mapping_offset);
+
+ /* Firmware bug! */
+ if (!map->output_reference) {
+ pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
+ node, node->type);
+ return NULL;
+ }
+
+ parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
+ map->output_reference);
+
+ if (!(IORT_TYPE_MASK(parent->type) & type_mask))
+ return NULL;
+
+ if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
+ if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
+ node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
+ *id_out = map[index].output_base;
+ return parent;
+ }
+ }
+
+ return NULL;
+}
+
static struct acpi_iort_node *iort_node_map_rid(struct acpi_iort_node *node,
u32 rid_in, u32 *rid_out,
u8 type_mask)
--
2.10.0
^ permalink raw reply related
* [PATCH v7 16/16] drivers: acpi: iort: introduce iort_iommu_configure
From: Lorenzo Pieralisi @ 2016-11-09 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-1-lorenzo.pieralisi@arm.com>
DT based systems have a generic kernel API to configure IOMMUs
for devices (ie of_iommu_configure()).
On ARM based ACPI systems, the of_iommu_configure() equivalent can
be implemented atop ACPI IORT kernel API, with the corresponding
functions to map device identifiers to IOMMUs and retrieve the
corresponding IOMMU operations necessary for DMA operations set-up.
By relying on the iommu_fwspec generic kernel infrastructure,
implement the IORT based IOMMU configuration for ARM ACPI systems
and hook it up in the ACPI kernel layer that implements DMA
configuration for a device.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/acpi/scan.c | 7 +++-
include/linux/acpi_iort.h | 6 +++
3 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 7d30605..c129c60 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -28,6 +28,8 @@
#define IORT_TYPE_MASK(type) (1 << (type))
#define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
+#define IORT_IOMMU_TYPE ((1 << ACPI_IORT_NODE_SMMU) | \
+ (1 << ACPI_IORT_NODE_SMMU_V3))
struct iort_its_msi_chip {
struct list_head list;
@@ -501,6 +503,103 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
}
+static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
+{
+ u32 *rid = data;
+
+ *rid = alias;
+ return 0;
+}
+
+static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
+ struct fwnode_handle *fwnode,
+ const struct iommu_ops *ops)
+{
+ int ret = iommu_fwspec_init(dev, fwnode, ops);
+
+ if (!ret)
+ ret = iommu_fwspec_add_ids(dev, &streamid, 1);
+
+ return ret;
+}
+
+static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
+ struct acpi_iort_node *node,
+ u32 streamid)
+{
+ struct fwnode_handle *iort_fwnode = NULL;
+ const struct iommu_ops *ops = NULL;
+ int ret = -ENODEV;
+
+ if (node) {
+ iort_fwnode = iort_get_fwnode(node);
+ if (!iort_fwnode)
+ return NULL;
+
+ ops = fwnode_iommu_get_ops(iort_fwnode);
+ if (!ops)
+ return NULL;
+
+ ret = arm_smmu_iort_xlate(dev, streamid,
+ iort_fwnode, ops);
+ }
+
+ return ret ? NULL : ops;
+}
+
+/**
+ * iort_iommu_configure - Set-up IOMMU configuration for a device.
+ *
+ * @dev: device to configure
+ *
+ * Returns: iommu_ops pointer on configuration success
+ * NULL on configuration failure
+ */
+const struct iommu_ops *iort_iommu_configure(struct device *dev)
+{
+ struct acpi_iort_node *node, *parent;
+ const struct iommu_ops *ops = NULL;
+ u32 streamid = 0;
+
+ if (dev_is_pci(dev)) {
+ struct pci_bus *bus = to_pci_dev(dev)->bus;
+ u32 rid;
+
+ pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid,
+ &rid);
+
+ node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
+ iort_match_node_callback, &bus->dev);
+ if (!node)
+ return NULL;
+
+ parent = iort_node_map_rid(node, rid, &streamid,
+ IORT_IOMMU_TYPE);
+
+ ops = iort_iommu_xlate(dev, parent, streamid);
+
+ } else {
+ int i = 0;
+
+ node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
+ iort_match_node_callback, dev);
+ if (!node)
+ return NULL;
+
+ parent = iort_node_get_id(node, &streamid,
+ IORT_IOMMU_TYPE, i++);
+
+ while (parent) {
+ ops = iort_iommu_xlate(dev, parent, streamid);
+
+ parent = iort_node_get_id(node, &streamid,
+ IORT_IOMMU_TYPE, i++);
+ }
+ }
+
+ return ops;
+}
+
static void __init acpi_iort_register_irq(int hwirq, const char *name,
int trigger,
struct resource *res)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 694e0b6..e5f7004 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -7,6 +7,7 @@
#include <linux/slab.h>
#include <linux/kernel.h>
#include <linux/acpi.h>
+#include <linux/acpi_iort.h>
#include <linux/signal.h>
#include <linux/kthread.h>
#include <linux/dmi.h>
@@ -1377,6 +1378,8 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
*/
void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
{
+ const struct iommu_ops *iommu;
+
/*
* Set default coherent_dma_mask to 32 bit. Drivers are expected to
* setup the correct supported mask.
@@ -1391,11 +1394,13 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
if (!dev->dma_mask)
dev->dma_mask = &dev->coherent_dma_mask;
+ iommu = iort_iommu_configure(dev);
+
/*
* Assume dma valid range starts at 0 and covers the whole
* coherent_dma_mask.
*/
- arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
+ arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
attr == DEV_DMA_COHERENT);
}
EXPORT_SYMBOL_GPL(acpi_dma_configure);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 79ba1bb..dcb2b60 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -34,6 +34,8 @@ void acpi_iort_init(void);
bool iort_node_match(u8 type);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
+/* IOMMU interface */
+const struct iommu_ops *iort_iommu_configure(struct device *dev);
#else
static inline void acpi_iort_init(void) { }
static inline bool iort_node_match(u8 type) { return false; }
@@ -42,6 +44,10 @@ static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
{ return NULL; }
+/* IOMMU interface */
+static inline
+const struct iommu_ops *iort_iommu_configure(struct device *dev)
+{ return NULL; }
#endif
#define IORT_ACPI_DECLARE(name, table_id, fn) \
--
2.10.0
^ permalink raw reply related
* [PATCH] fpga zynq: Check the bitstream for validity
From: Mike Looijmans @ 2016-11-09 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108000538.GA13959@obsidianresearch.com>
?On 08-11-16 01:05, Jason Gunthorpe wrote:
> On Tue, Nov 01, 2016 at 06:48:42PM +0100, Michal Simek wrote:
>> On 1.11.2016 16:33, Jason Gunthorpe wrote:
>>> On Tue, Nov 01, 2016 at 07:39:22AM +0100, Michal Simek wrote:
>>>
>>>> Regarding BIT and BIN format. This support is in vivado for a long time
>>>> and it is up2you what you want to support. We have removed that BIT
>>>> support and not doing any swap by saying only BIN format is supported.
>>>
>>> BIN is not supported, it needs a swap as well.
>>>
>>> Moritz has it right, you have to use vivado to create a PROM image to be
>>> compatible with the driver.
>>
>> hm than that's bad.
>
> IMHO, Xilinx made an error with Zynq DevC, the DMA does not accept a
> memory image that is output by the usual Xilinx tools. It should have
> accepted a byte swapped input.
>
> I think Moritz is right, the fpgamgr *should not* alter the bitstream
> in any way. This is important for future work to make the DMA do
> gather and avoid the really bad high-order allocation.
>
> So users will have to provide byte swapped .bin files - the vivado
> write_cfgmem command will produce them - this all needs to be
> documented.
>
> Also, I think Punnaiah (?) was telling me that bitstream encryption
> does not work - DevC must be told the bitstream is encrypted.
> That seems like something that needs work at the fpgamgr level - and
> maybe this driver should auto-detect encryption by looking at the
> bitfile (as is typical for Xilinx programming)
>
I think the basic idea behind the commit is flawed to begin with and the patch
should be discarded completely. The same discussion was done for the Xilinx
FPGA manager driver, which resulted in the decision that the tooling should
create a proper file. This driver should either become obsolete or at least
move into the same direction as the FPGA manager rather than away from that.
Besides political arguments, there's a more pressing technical argument
against this theck as well: The whole check is pointless since the hardware
itself already verifies the validity of the stream. Sending bitstreams
intended for other devices has no effect at all. Even sending random data
doesn't have any effect, the hardware will discard it. There's no reason to
waste CPU cycles duplicating this check in software.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* [PATCH 2/3] ipmi/bt-bmc: maintain a request expiry list
From: Cédric Le Goater @ 2016-11-09 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7aea2a7-6cb4-655e-3c69-1a156945e27b@acm.org>
On 11/07/2016 08:04 PM, Corey Minyard wrote:
> On 11/02/2016 02:57 AM, C?dric Le Goater wrote:
>> Regarding the response expiration handling, the IPMI spec says :
>>
>> The BMC must not return a given response once the corresponding
>> Request-to-Response interval has passed. The BMC can ensure this
>> by maintaining its own internal list of outstanding requests through
>> the interface. The BMC could age and expire the entries in the list
>> by expiring the entries at an interval that is somewhat shorter than
>> the specified Request-to-Response interval....
>>
>> To handle such case, we maintain list of received requests using the
>> seq number of the BT message to identify them. The list is updated
>> each time a request is received and a response is sent. The expiration
>> of the reponses is handled at each updates but also with a timer.
>
> This looks correct, but it seems awfully complicated.
>
> Why can't you get the current time before the wait_event_interruptible()
> and then compare the time before you do the write? That would seem to
> accomplish the same thing without any lists or extra locks.
Well, the expiry list needs a request identifier and it is currently using
the Seq byte for this purpose. So the BT message needs to be read to grab
that byte. The request is added to a list and that involves some locking.
When the response is written, the first matching request is removed from
the list and a garbage collector loop is also run. Then, as we might not
get any responses to run that loop, we use a timer to empty the list from
any expired requests.
The read/write ops of the driver are protected with a mutex, the list and
the timer add their share of locking. That could have been done with RCU
surely but we don't really need performance in this driver.
Caveats :
bt_bmc_remove_request() should not be done in the writing loop though.
It needs a fix.
The request identifier is currently Seq but the spec say we should use
Seq, NetFn, and Command or an internal Seq value as a request identifier.
Google is also working on an OEM/Group extension (Brendan in CC: )
which has a different message format. I need to look closer at what
should be done in this case.
> Also, if you are going to have multiple writers on this interface, I don't
> think the interface will work correctly. I think you need to claim the
> mutex first. Otherwise you might get into a situation where two writers
> will wake up at the same time, the first writes and releases the mutex,
> then the second will find that the interface is busy and fail.
yes. that is a current problem in the driver and it is not really an
elegant way to handle concurrency. We are fine for the moment as we
only have one single threaded process using the device.
> If I am correct, the mutex will need to become interruptible and come
> first, I think. (And the timing would have to start before the mutex,
> of course.) This applies to both the read and write interface.
OK. I will look into fixing this problem first.
> Another thing is that this is request-to-release time. If a request takes
> a long time to process (say, a write to a flash device) the timeout would
> need to be decreased by the processing time.
Hmm, how would that fit with the "BT Interface Capabilities" which
defines :
BMC Request-to-Response time, in seconds, 1 based. 30 seconds, maximum.
This is a fixed value. And the spec only say :
The BMC could age and expire the entries in the list by expiring
the entries at an interval that is somewhat shorter than the
specified Request-to-Response interval.
May be I am misunderstanding.
> It's probably ok to not do that for the moment, but you may want to add
> a note. Fixing that would require adding a timeout for each message.
Thanks,
C.
> -corey
>
>
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 132 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 132 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index fc9e8891eae3..e751e4a754b7 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -17,6 +17,7 @@
>> #include <linux/platform_device.h>
>> #include <linux/poll.h>
>> #include <linux/sched.h>
>> +#include <linux/slab.h>
>> #include <linux/timer.h>
>> /*
>> @@ -57,6 +58,15 @@
>> #define BT_BMC_BUFFER_SIZE 256
>> +#define BT_BMC_RESPONSE_TIME 5 /* seconds */
>> +
>> +struct ipmi_request {
>> + struct list_head list;
>> +
>> + u8 seq;
>> + unsigned long expires;
>> +};
>> +
>> struct bt_bmc {
>> struct device dev;
>> struct miscdevice miscdev;
>> @@ -65,6 +75,11 @@ struct bt_bmc {
>> wait_queue_head_t queue;
>> struct timer_list poll_timer;
>> struct mutex mutex;
>> +
>> + unsigned int response_time;
>> + struct timer_list requests_timer;
>> + spinlock_t requests_lock;
>> + struct list_head requests;
>> };
>> static atomic_t open_count = ATOMIC_INIT(0);
>> @@ -163,6 +178,94 @@ static int bt_bmc_open(struct inode *inode, struct file *file)
>> }
>> /*
>> + * lock should be held
>> + */
>> +static void drop_expired_requests(struct bt_bmc *bt_bmc)
>> +{
>> + unsigned long flags = 0;
>> + struct ipmi_request *req, *next;
>> + unsigned long next_expires = 0;
>> + int start_timer = 0;
>> +
>> + spin_lock_irqsave(&bt_bmc->requests_lock, flags);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + if (time_after_eq(jiffies, req->expires)) {
>> + pr_warn("BT: request seq:%d has expired. dropping\n",
>> + req->seq);
>> + list_del(&req->list);
>> + kfree(req);
>> + continue;
>> + }
>> + if (!start_timer) {
>> + start_timer = 1;
>> + next_expires = req->expires;
>> + } else {
>> + next_expires = min(next_expires, req->expires);
>> + }
>> + }
>> + spin_unlock_irqrestore(&bt_bmc->requests_lock, flags);
>> +
>> + /* and possibly restart */
>> + if (start_timer)
>> + mod_timer(&bt_bmc->requests_timer, next_expires);
>> +}
>> +
>> +static void requests_timer(unsigned long data)
>> +{
>> + struct bt_bmc *bt_bmc = (void *)data;
>> +
>> + drop_expired_requests(bt_bmc);
>> +}
>> +
>> +static int bt_bmc_add_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req;
>> +
>> + req = kmalloc(sizeof(*req), GFP_KERNEL);
>> + if (!req)
>> + return -ENOMEM;
>> +
>> + req->seq = seq;
>> + req->expires = jiffies +
>> + msecs_to_jiffies(bt_bmc->response_time * 1000);
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_add(&req->list, &bt_bmc->requests);
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_remove_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req, *next;
>> + int ret = -EBADRQC; /* Invalid request code */
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + /*
>> + * The sequence number should be unique, so remove the
>> + * first matching request found. If there are others,
>> + * they should expire
>> + */
>> + if (req->seq == seq) {
>> + list_del(&req->list);
>> + kfree(req);
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + if (ret)
>> + pr_warn("BT: request seq:%d is invalid\n", seq);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return ret;
>> +}
>> +
>> +/*
>> * The BT (Block Transfer) interface means that entire messages are
>> * buffered by the host before a notification is sent to the BMC that
>> * there is data to be read. The first byte is the length and the
>> @@ -231,6 +334,13 @@ static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>> len_byte = 0;
>> }
>> + if (ret > 0) {
>> + int ret2 = bt_bmc_add_request(bt_bmc, kbuffer[2]);
>> +
>> + if (ret2)
>> + ret = ret2;
>> + }
>> +
>> clr_b_busy(bt_bmc);
>> out_unlock:
>> @@ -283,12 +393,20 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>> clr_wr_ptr(bt_bmc);
>> while (count) {
>> + int ret2;
>> +
>> nwritten = min_t(ssize_t, count, sizeof(kbuffer));
>> if (copy_from_user(&kbuffer, buf, nwritten)) {
>> ret = -EFAULT;
>> break;
>> }
>> + ret2 = bt_bmc_remove_request(bt_bmc, kbuffer[2]);
>> + if (ret2) {
>> + ret = ret2;
>> + break;
>> + }
>> +
>> bt_writen(bt_bmc, kbuffer, nwritten);
>> count -= nwritten;
>> @@ -438,6 +556,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> mutex_init(&bt_bmc->mutex);
>> init_waitqueue_head(&bt_bmc->queue);
>> + INIT_LIST_HEAD(&bt_bmc->requests);
>> + spin_lock_init(&bt_bmc->requests_lock);
>> bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> bt_bmc->miscdev.name = DEVICE_NAME,
>> @@ -451,6 +571,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> + bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> +
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> } else {
>> @@ -468,6 +590,9 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> BT_CR0_ENABLE_IBT,
>> bt_bmc->base + BT_CR0);
>> + setup_timer(&bt_bmc->requests_timer, requests_timer,
>> + (unsigned long)bt_bmc);
>> +
>> clr_b_busy(bt_bmc);
>> return 0;
>> @@ -476,10 +601,17 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> static int bt_bmc_remove(struct platform_device *pdev)
>> {
>> struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
>> + struct ipmi_request *req, *next;
>> misc_deregister(&bt_bmc->miscdev);
>> if (!bt_bmc->irq)
>> del_timer_sync(&bt_bmc->poll_timer);
>> +
>> + del_timer_sync(&bt_bmc->requests_timer);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + list_del(&req->list);
>> + kfree(req);
>> + }
>> return 0;
>> }
>>
>
>
^ permalink raw reply
* [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC
From: Andrew Lunn @ 2016-11-09 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478683994-12008-2-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for mdio mux available in Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
> new file mode 100644
> index 0000000..b749a2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
> @@ -0,0 +1,57 @@
> +Properties for an MDIO bus multiplexer available in Broadcom NSP SoC.
> +
> +This MDIO bus multiplexer defines buses that could access the internal
> +phys as well as external to SoCs. When child bus is selected, one needs
Hi Yendapally
Since we are in the networking subsystem, when we see phy, we think
Ethernet PHY. But broadcom mdio mux is generic and can have any sort
of PHY or device connected to it. To avoid confusion and
missunderstanding, please could you try to prefix each 'PHY' in the
with an indication of what type it is, 'Ethernet PHY', 'USB phy',
'SERDES PHY', or 'generic PHY/mdio device'.
And i mean this in general, not just this patch.
Thanks
Andrew
^ permalink raw reply
* [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-13-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:34 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-freqeuncy" property.
> It should be same behavior, So Use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
applied to my dts64 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-09 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-5-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a device tree node, therefore
> the interface requires generalization.
>
> The struct device fwnode member represents the fwnode token
> associated with the device and the struct it points at is firmware
> specific; regardless, it is initialized on both ACPI and DT systems
> and makes an ideal candidate to use it to associate a set of IOMMU
> operations to a given device, through its struct device.fwnode member
> pointer.
>
> Convert the DT specific of_iommu_{set/get}_ops() interface to
> use struct device.fwnode as a look-up token, making the interface
> usable on ACPI systems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/iommu/iommu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/of_iommu.c | 39 ---------------------------------------
> include/linux/iommu.h | 14 ++++++++++++++
> include/linux/of_iommu.h | 12 ++++++++++--
> 4 files changed, 66 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..5c97c01 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1615,6 +1615,48 @@ int iommu_request_dm_for_dev(struct device *dev)
> return ret;
> }
>
> +struct iommu_fwentry {
:)
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
> +static LIST_HEAD(iommu_fwentry_list);
> +static DEFINE_SPINLOCK(iommu_fwentry_lock);
> +
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> +
> + if (WARN_ON(!iommu))
> + return;
> +
> + if (is_of_node(fwnode))
Nit: this check is actually redundant, since to_of_node() already does
the right thing and of_node_get() is NULL-safe - iommu_fwspec_init()
already works that way. On the other hand, though, it is perhaps more
intuitive to see it explicitly, and since to_of_node() is inline it
ought to result in the same object code (I've not checked, though).
Either way:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> + of_node_get(to_of_node(fwnode));
> +
> + INIT_LIST_HEAD(&iommu->list);
> + iommu->fwnode = fwnode;
> + iommu->ops = ops;
> + spin_lock(&iommu_fwentry_lock);
> + list_add_tail(&iommu->list, &iommu_fwentry_list);
> + spin_unlock(&iommu_fwentry_lock);
> +}
> +
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + struct iommu_fwentry *node;
> + const struct iommu_ops *ops = NULL;
> +
> + spin_lock(&iommu_fwentry_lock);
> + list_for_each_entry(node, &iommu_fwentry_list, list)
> + if (node->fwnode == fwnode) {
> + ops = node->ops;
> + break;
> + }
> + spin_unlock(&iommu_fwentry_lock);
> + return ops;
> +}
> +
> int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops)
> {
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5b82862..0f57ddc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -struct of_iommu_node {
> - struct list_head list;
> - struct device_node *np;
> - const struct iommu_ops *ops;
> -};
> -static LIST_HEAD(of_iommu_list);
> -static DEFINE_SPINLOCK(of_iommu_lock);
> -
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> -{
> - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> -
> - if (WARN_ON(!iommu))
> - return;
> -
> - of_node_get(np);
> - INIT_LIST_HEAD(&iommu->list);
> - iommu->np = np;
> - iommu->ops = ops;
> - spin_lock(&of_iommu_lock);
> - list_add_tail(&iommu->list, &of_iommu_list);
> - spin_unlock(&of_iommu_lock);
> -}
> -
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - struct of_iommu_node *node;
> - const struct iommu_ops *ops = NULL;
> -
> - spin_lock(&of_iommu_lock);
> - list_for_each_entry(node, &of_iommu_list, list)
> - if (node->np == np) {
> - ops = node->ops;
> - break;
> - }
> - spin_unlock(&of_iommu_lock);
> - return ops;
> -}
> -
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> struct of_phandle_args *iommu_spec = data;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 436dc21..15d5478 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops);
> void iommu_fwspec_free(struct device *dev);
> int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops);
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode);
>
> #else /* CONFIG_IOMMU_API */
>
> @@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> return -ENODEV;
> }
>
> +static inline void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> +}
> +
> +static inline
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + return NULL;
> +}
> +
> #endif /* CONFIG_IOMMU_API */
>
> #endif /* __LINUX_IOMMU_H */
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index e80b9c7..7681007 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> +static inline void of_iommu_set_ops(struct device_node *np,
> + const struct iommu_ops *ops)
> +{
> + fwnode_iommu_set_ops(&np->fwnode, ops);
> +}
> +
> +static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> +{
> + return fwnode_iommu_get_ops(&np->fwnode);
> +}
>
> extern struct of_device_id __iommu_of_table;
>
>
^ permalink raw reply
* [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Cédric Le Goater @ 2016-11-09 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a1f8e6d-c935-3404-ffa0-81b19d170731@acm.org>
On 11/07/2016 07:37 PM, Corey Minyard wrote:
> Sorry, I was at Plumbers and extra busy with other stuff. Just getting around to reviewing this.
>
> On 11/02/2016 02:57 AM, C?dric Le Goater wrote:
>> We could also use an ioctl for that purpose. sysfs seems a better
>> approach.
>>
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index e751e4a754b7..d7146f0e900e 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -84,6 +84,33 @@ struct bt_bmc {
>> static atomic_t open_count = ATOMIC_INIT(0);
>> +static ssize_t bt_bmc_show_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> +
>> + return snprintf(buf, PAGE_SIZE - 1, "%d\n", bt_bmc->response_time);
>> +}
>> +
>> +static ssize_t bt_bmc_set_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> + unsigned long val;
>> + int err;
>> +
>> + err = kstrtoul(buf, 0, &val);
>> + if (err)
>> + return err;
>> + bt_bmc->response_time = val;
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(response_time, 0644,
>> + bt_bmc_show_response_time, bt_bmc_set_response_time);
>> +
>> static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
>> {
>> return ioread8(bt_bmc->base + reg);
>> @@ -572,6 +599,10 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> + rc = device_create_file(&pdev->dev, &dev_attr_response_time);
>> + if (rc)
>> + dev_warn(&pdev->dev, "can't create response_time file\n");
>> +
>
> You added an extra space here.
yes. I will remove it in the next version.
The patch raises a few questions on the "BT Interface Capabilities" :
- should we use sysfs or a specific ioctl to configure the driver ?
- should the driver handle directly the response to the "Get BT
Interface Capabilities" command ?
What is your opinion ?
Thanks,
C.
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>
>
^ permalink raw reply
* [PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-6-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f72814..8a3c2a4 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1379,13 +1379,14 @@ static bool arm_smmu_capable(enum iommu_cap cap)
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1403,7 +1404,7 @@ static int arm_smmu_add_device(struct device *dev)
> if (ret)
> goto out_free;
> } else if (fwspec && fwspec->ops == &arm_smmu_ops) {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> } else {
> return -ENODEV;
> }
> @@ -2007,7 +2008,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> }
>
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
>
>
^ permalink raw reply
* [PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-7-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU v3 driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index e6f9b2d..fef9f60 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1723,13 +1723,14 @@ static struct platform_driver arm_smmu_driver;
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1765,7 +1766,7 @@ static int arm_smmu_add_device(struct device *dev)
> master = fwspec->iommu_priv;
> smmu = master->smmu;
> } else {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> if (!smmu)
> return -ENODEV;
> master = kzalloc(sizeof(*master), GFP_KERNEL);
> @@ -2634,7 +2635,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> return ret;
>
> /* And we're up. Go go go! */
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> +
> #ifdef CONFIG_PCI
> if (pci_bus_type.iommu_ops != &arm_smmu_ops) {
> pci_request_acs();
>
^ permalink raw reply
* [PATCH 3/6] net: mdio-mux: Add MDIO mux driver for NSP SoC
From: Andrew Lunn @ 2016-11-09 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478683994-12008-4-git-send-email-yendapally.reddy@broadcom.com>
> +#define NSP_MDIO_EXT_BUS_START_ADDR 16
> +#define NSP_MDIO_EXT_SELECT_BIT BIT(9)
> +
> +static int mdio_mux_nsp_switch_fn(int current_child, int desired_child,
> + void *priv)
> +{
> + struct nsp_mdiomux_desc *md = priv;
> + u32 data, bus_id;
> +
> + /* select internal or external bus */
> + data = readl(md->mgmt_ctrl);
> + if (desired_child == NSP_MDIO_EXT_BUS_START_ADDR)
> + data |= NSP_MDIO_EXT_SELECT_BIT;
> + else
> + data &= ~NSP_MDIO_EXT_SELECT_BIT;
> + writel(data, md->mgmt_ctrl);
> +
> + /* select bus number */
> + if (md->bus_ctrl) {
> + bus_id = desired_child & (NSP_MDIO_EXT_BUS_START_ADDR - 1);
> + writel(bus_id, md->bus_ctrl);
> + }
> +
> + return 0;
So address 16 is external. What happens which you try to access
address 16 internally? Does the chip raise an abort? Reads just give
0xffff?
I'm wondering if it would be better to implement this as two nested
muxes. One mux doing internal/external, and the other doing the bus.
If you do that, you can use the existing mdio-mux-mmioreg.c and don't
need any new code at all.
Andrew
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-09 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109135453.2e5402bd@lxorguk.ukuu.org.uk>
> -----Original Message-----
> From: One Thousand Gnomes [mailto:gnomes at lxorguk.ukuu.org.uk]
> Sent: 09 November 2016 13:55
> To: Arnd Bergmann
> Cc: Mark Rutland; Yuanzhichang; catalin.marinas at arm.com;
> will.deacon at arm.com; robh+dt at kernel.org; bhelgaas at google.com;
> olof at lixom.net; linux-arm-kernel at lists.infradead.org;
> lorenzo.pieralisi at arm.com; linux-kernel at vger.kernel.org; Linuxarm;
> devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-
> serial at vger.kernel.org; minyard at acm.org; benh at kernel.crashing.org;
> liviu.dudau at arm.com; zourongrong at gmail.com; John Garry; Gabriele
> Paoloni; zhichang.yuan02 at gmail.com; kantyzc at 163.com; xuwei (O);
> marc.zyngier at arm.com
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
>
> > I think it is a relatively safe assumption that there is only one
> > ISA bridge. A lot of old drivers hardcode PIO or memory addresses
>
> It's not a safe assumption for x86 at least. There are a few systems
> with
> multiple ISA busses particularly older laptops with a docking station.
Mmmm right...now the point is that this kind of special devices appearing
as a special ISA bus will probably never appear on x86 platforms (I guess).
So maybe it is a safe assumption because of this...?
Thanks
Gab
>
> > when talking to an ISA device, so having multiple instances is
> > already problematic.
>
> PCMCIA devices handle it themselves so are ok. I'm not clear how the
> dual
> PIIX4 configuration used in the older IBM laptop docks actually worked
> so
> I assume the transaction went out of both bridges and providing one of
> them responded the other kept silent as you simply stuffed the card
> into
> the dock and it worked.
>
> Alan
^ permalink raw reply
* [PATCH v2 0/2] pinctrl: single: fixes for davinci
From: Axel Haslam @ 2016-11-09 14:53 UTC (permalink / raw)
To: linux-arm-kernel
After recent pinctl patches we see a warning when booting davinci
due to a bad memory allocation:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:3511 __alloc_pages_nodemask+0x16c/0xb18
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc2-00023-g22d5127-dirty #1019
Hardware name: Generic DA850/OMAP-L138/AM18x
Backtrace:
[<c000d670>] (dump_backtrace) from [<c000d794>] (show_stack+0x18/0x1c)
[<c000d77c>] (show_stack) from [<c021a0d0>] (dump_stack+0x20/0x28)
[<c021a0b0>] (dump_stack) from [<c001bb10>] (__warn+0xe8/0x100)
[<c001ba28>] (__warn) from [<c001bb50>] (warn_slowpath_null+0x28/0x30)
[<c001bb28>] (warn_slowpath_null) from [<c0097e7c>] (__alloc_pages_nodemask+0x16c/0xb18)
[<c0097d10>] (__alloc_pages_nodemask) from [<c00afef4>] (kmalloc_order+0x20/0x58)
[<c00afed4>] (kmalloc_order) from [<c00ce7ac>] (__kmalloc_track_caller+0x188/0x190)
[<c00ce624>] (__kmalloc_track_caller) from [<c02a762c>] (devm_kmalloc+0x24/0x70)
[<c02a7608>] (devm_kmalloc) from [<c0247d10>] (pcs_dt_node_to_map+0x1d0/0xa40)
[<c0245ec8>] (pinctrl_dt_to_map) from [<c0242fd0>] (pinctrl_get+0xe8/0x484)
[snip]
This series fixes this error.
Changes form v1 -> v2
* Add an error message, and correct also other places where the
issue is seen
* Add patch to parse for bits instead of pins
Axel Haslam (2):
pinctrl: single: check for any error when getting rows
pinctrl: single: search for the bits property when parsing bits
drivers/pinctrl/pinctrl-single.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v2 1/2] pinctrl: single: check for any error when getting rows
From: Axel Haslam @ 2016-11-09 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>
pinctrl_count_index_with_args returns -ENOENT not
-EINVAL. The return check would pass, and we would
try to kzalloc with a negative error size throwing
a warning.
Instead of checking for -EINVAL specifically, lets
check for any error and avoid negative size allocations.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
drivers/pinctrl/pinctrl-single.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 539f31c..f36a9f1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1133,8 +1133,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
struct pcs_function *function;
rows = pinctrl_count_index_with_args(np, name);
- if (rows == -EINVAL)
- return rows;
+ if (rows <= 0) {
+ dev_err(pcs->dev, "Ivalid number of rows: %d\n", rows);
+ return -EINVAL;
+ }
vals = devm_kzalloc(pcs->dev, sizeof(*vals) * rows, GFP_KERNEL);
if (!vals)
@@ -1228,8 +1230,10 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
struct pcs_function *function;
rows = pinctrl_count_index_with_args(np, name);
- if (rows == -EINVAL)
- return rows;
+ if (rows <= 0) {
+ dev_err(pcs->dev, "Invalid number of rows: %d\n", rows);
+ return -EINVAL;
+ }
npins_in_row = pcs->width / pcs->bits_per_pin;
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/2] pinctrl: single: search for the bits property when parsing bits
From: Axel Haslam @ 2016-11-09 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>
The pcs_parse_bits_in_pinctrl_entry function should search
for the "pinctrl-single,bits" and not "pinctrl-single,pins"
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
drivers/pinctrl/pinctrl-single.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f36a9f1..2b196e5 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1223,7 +1223,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
unsigned *num_maps,
const char **pgnames)
{
- const char *name = "pinctrl-single,pins";
+ const char *name = "pinctrl-single,bits";
struct pcs_func_vals *vals;
int rows, *pins, found = 0, res = -ENOMEM, i;
int npins_in_row;
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for optional reset control to quirks" to the asoc tree
From: Mark Brown @ 2016-11-09 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-6-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for optional reset control to quirks
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9aead156c0665a362c8b007b51fe3396fea4d346 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Mon, 7 Nov 2016 18:06:58 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for optional reset control to
quirks
The later Allwinner SoCs have a dedicated reset controller, and
peripherals have dedicated reset controls which need to be deasserted
before the associated peripheral can be used.
Add support for this to the quirks structure and probe/remove functions.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 735115244b17..6379efd21f00 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -30,6 +30,7 @@
#include <linux/of_platform.h>
#include <linux/clk.h>
#include <linux/regmap.h>
+#include <linux/reset.h>
#include <linux/gpio/consumer.h>
#include <sound/core.h>
@@ -217,6 +218,7 @@ struct sun4i_codec {
struct regmap *regmap;
struct clk *clk_apb;
struct clk *clk_module;
+ struct reset_control *rst;
struct gpio_desc *gpio_pa;
/* ADC_FIFOC register is at different offset on different SoCs */
@@ -1232,6 +1234,7 @@ struct sun4i_codec_quirks {
struct reg_field reg_adc_fifoc; /* used for regmap_field */
unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
unsigned int reg_adc_rxdata; /* RX FIFO offset for DMA config */
+ bool has_reset;
};
static const struct sun4i_codec_quirks sun4i_codec_quirks = {
@@ -1327,6 +1330,14 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(scodec->clk_module);
}
+ if (quirks->has_reset) {
+ scodec->rst = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(scodec->rst)) {
+ dev_err(&pdev->dev, "Failed to get reset control\n");
+ return PTR_ERR(scodec->rst);
+ }
+ };
+
scodec->gpio_pa = devm_gpiod_get_optional(&pdev->dev, "allwinner,pa",
GPIOD_OUT_LOW);
if (IS_ERR(scodec->gpio_pa)) {
@@ -1353,6 +1364,16 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return -EINVAL;
}
+ /* Deassert the reset control */
+ if (scodec->rst) {
+ ret = reset_control_deassert(scodec->rst);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to deassert the reset control\n");
+ goto err_clk_disable;
+ }
+ }
+
/* DMA configuration for TX FIFO */
scodec->playback_dma_data.addr = res->start + quirks->reg_dac_txdata;
scodec->playback_dma_data.maxburst = 8;
@@ -1367,7 +1388,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
&sun4i_codec_dai, 1);
if (ret) {
dev_err(&pdev->dev, "Failed to register our codec\n");
- goto err_clk_disable;
+ goto err_assert_reset;
}
ret = devm_snd_soc_register_component(&pdev->dev,
@@ -1404,6 +1425,9 @@ static int sun4i_codec_probe(struct platform_device *pdev)
err_unregister_codec:
snd_soc_unregister_codec(&pdev->dev);
+err_assert_reset:
+ if (scodec->rst)
+ reset_control_assert(scodec->rst);
err_clk_disable:
clk_disable_unprepare(scodec->clk_apb);
return ret;
@@ -1416,6 +1440,8 @@ static int sun4i_codec_remove(struct platform_device *pdev)
snd_soc_unregister_card(card);
snd_soc_unregister_codec(&pdev->dev);
+ if (scodec->rst)
+ reset_control_assert(scodec->rst);
clk_disable_unprepare(scodec->clk_apb);
return 0;
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 ADC capture path" to the asoc tree
From: Mark Brown @ 2016-11-09 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003110804.28235-10-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 ADC capture path
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 24c99f843208df70ec7d1e04aa405f7e4c36f228 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Mon, 7 Nov 2016 18:06:59 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 ADC capture path
The A31's internal codec capture path has a mixer in front of the ADC
for each channel, capable of selecting various inputs, including
microphones, line in, phone in, and the main output mixer.
This patch adds the various controls, widgets and routes needed for
audio capture from the already supported inputs on the A31.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 65 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 1934db29b2b5..735115244b17 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -786,6 +786,30 @@ static const struct snd_kcontrol_new sun6i_codec_mixer_controls[] = {
SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2, 1, 0),
};
+/* ADC mixer controls */
+static const struct snd_kcontrol_new sun6i_codec_adc_mixer_controls[] = {
+ SOC_DAPM_DOUBLE("Mixer Capture Switch",
+ SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_LADCMIX_OMIXL,
+ SUN6I_CODEC_ADC_ACTL_RADCMIX_OMIXR, 1, 0),
+ SOC_DAPM_DOUBLE("Mixer Reversed Capture Switch",
+ SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_LADCMIX_OMIXR,
+ SUN6I_CODEC_ADC_ACTL_RADCMIX_OMIXL, 1, 0),
+ SOC_DAPM_DOUBLE("Line In Capture Switch",
+ SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_LADCMIX_LINEINL,
+ SUN6I_CODEC_ADC_ACTL_RADCMIX_LINEINR, 1, 0),
+ SOC_DAPM_DOUBLE("Mic1 Capture Switch",
+ SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_LADCMIX_MIC1,
+ SUN6I_CODEC_ADC_ACTL_RADCMIX_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE("Mic2 Capture Switch",
+ SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_LADCMIX_MIC2,
+ SUN6I_CODEC_ADC_ACTL_RADCMIX_MIC2, 1, 0),
+};
+
/* headphone controls */
static const char * const sun6i_codec_hp_src_enum_text[] = {
"DAC", "Mixer",
@@ -885,6 +909,10 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("Mic2 Boost Volume", SUN6I_CODEC_MIC_CTRL,
SUN6I_CODEC_MIC_CTRL_MIC2BOOST, 0x7, 0,
sun6i_codec_mic_gain_scale),
+ SOC_DOUBLE_TLV("ADC Capture Volume",
+ SUN6I_CODEC_ADC_ACTL, SUN6I_CODEC_ADC_ACTL_ADCLG,
+ SUN6I_CODEC_ADC_ACTL_ADCRG, 0x7, 0,
+ sun6i_codec_out_mixer_pregain_scale),
};
static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
@@ -910,6 +938,23 @@ static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
/* Line In */
SND_SOC_DAPM_INPUT("LINEIN"),
+ /* Digital parts of the ADCs */
+ SND_SOC_DAPM_SUPPLY("ADC Enable", SUN6I_CODEC_ADC_FIFOC,
+ SUN6I_CODEC_ADC_FIFOC_EN_AD, 0,
+ NULL, 0),
+
+ /* Analog parts of the ADCs */
+ SND_SOC_DAPM_ADC("Left ADC", "Codec Capture", SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_ADCLEN, 0),
+ SND_SOC_DAPM_ADC("Right ADC", "Codec Capture", SUN6I_CODEC_ADC_ACTL,
+ SUN6I_CODEC_ADC_ACTL_ADCREN, 0),
+
+ /* ADC Mixers */
+ SOC_MIXER_ARRAY("Left ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun6i_codec_adc_mixer_controls),
+ SOC_MIXER_ARRAY("Right ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun6i_codec_adc_mixer_controls),
+
/* Digital parts of the DACs */
SND_SOC_DAPM_SUPPLY("DAC Enable", SUN4I_CODEC_DAC_DPC,
SUN4I_CODEC_DAC_DPC_EN_DA, 0,
@@ -973,6 +1018,20 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Right Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
{ "Right Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
+ /* Left ADC Mixer Routes */
+ { "Left ADC Mixer", "Mixer Capture Switch", "Left Mixer" },
+ { "Left ADC Mixer", "Mixer Reversed Capture Switch", "Right Mixer" },
+ { "Left ADC Mixer", "Line In Capture Switch", "LINEIN" },
+ { "Left ADC Mixer", "Mic1 Capture Switch", "Mic1 Amplifier" },
+ { "Left ADC Mixer", "Mic2 Capture Switch", "Mic2 Amplifier" },
+
+ /* Right ADC Mixer Routes */
+ { "Right ADC Mixer", "Mixer Capture Switch", "Right Mixer" },
+ { "Right ADC Mixer", "Mixer Reversed Capture Switch", "Left Mixer" },
+ { "Right ADC Mixer", "Line In Capture Switch", "LINEIN" },
+ { "Right ADC Mixer", "Mic1 Capture Switch", "Mic1 Amplifier" },
+ { "Right ADC Mixer", "Mic2 Capture Switch", "Mic2 Amplifier" },
+
/* Headphone Routes */
{ "Headphone Source Playback Route", "DAC", "Left DAC" },
{ "Headphone Source Playback Route", "DAC", "Right DAC" },
@@ -987,6 +1046,12 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Line Out Source Playback Route", "Stereo", "Right Mixer" },
{ "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
{ "LINEOUT", NULL, "Line Out Source Playback Route" },
+
+ /* ADC Routes */
+ { "Left ADC", NULL, "ADC Enable" },
+ { "Right ADC", NULL, "ADC Enable" },
+ { "Left ADC", NULL, "Left ADC Mixer" },
+ { "Right ADC", NULL, "Right ADC Mixer" },
};
static struct snd_soc_codec_driver sun6i_codec_codec = {
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: wm8978: Adjust clock indices so that simple card works" to the asoc tree
From: Mark Brown @ 2016-11-09 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d9c794b19e99745f0a98412c4cf8dcf26d728d4.1478524066.git-series.maxime.ripard@free-electrons.com>
The patch
ASoC: wm8978: Adjust clock indices so that simple card works
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From fbd972d7f4a60677f6fbe558dc23e4029dc2d45d Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Date: Mon, 7 Nov 2016 14:08:20 +0100
Subject: [PATCH] ASoC: wm8978: Adjust clock indices so that simple card works
Using simple-card with the wm8978 doesn't work because simple card calls
set_sysclk on the clock index 0, which is not the MCLK in the WM8978.
Adjust the clock definition so that the clock 0 is the MCLK.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/wm8978.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8978.h b/sound/soc/codecs/wm8978.h
index 6ae43495b7cf..0dcf6868dff6 100644
--- a/sound/soc/codecs/wm8978.h
+++ b/sound/soc/codecs/wm8978.h
@@ -78,8 +78,8 @@ enum wm8978_clk_id {
};
enum wm8978_sysclk_src {
+ WM8978_MCLK = 0,
WM8978_PLL,
- WM8978_MCLK
};
#endif /* __WM8978_H__ */
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: sunxi: i2s: Implement set_sysclk" to the asoc tree
From: Mark Brown @ 2016-11-09 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e86d676f28ff62bc0a56741f76afb2cbdfedbdd8.1478524066.git-series.maxime.ripard@free-electrons.com>
The patch
ASoC: sunxi: i2s: Implement set_sysclk
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From b2b7b56f713ab833413548b119c53bbe2a9a9f8f Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Date: Mon, 7 Nov 2016 14:08:19 +0100
Subject: [PATCH] ASoC: sunxi: i2s: Implement set_sysclk
In our i2s driver, we were previously trying to guess which oversample the
user wanted to use by looking at the rate and trying to max it.
However, the cards, and especially simple-card with its mclk-fs property
will already provide the expected oversample ratio by using the set_sysclk
callback.
We can thus implement it and remove the logic to deal with the runtime
guess.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 53 ++++++++++++++++++++++++++++++++-------------
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index a7653114e895..f24d19526603 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -93,6 +93,8 @@ struct sun4i_i2s {
struct clk *mod_clk;
struct regmap *regmap;
+ unsigned int mclk_freq;
+
struct snd_dmaengine_dai_dma_data capture_dma_data;
struct snd_dmaengine_dai_dma_data playback_dma_data;
};
@@ -158,14 +160,24 @@ static int sun4i_i2s_get_mclk_div(struct sun4i_i2s *i2s,
}
static int sun4i_i2s_oversample_rates[] = { 128, 192, 256, 384, 512, 768 };
+static bool sun4i_i2s_oversample_is_valid(unsigned int oversample)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(sun4i_i2s_oversample_rates); i++)
+ if (sun4i_i2s_oversample_rates[i] == oversample)
+ return true;
+
+ return false;
+}
static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
unsigned int rate,
unsigned int word_size)
{
- unsigned int clk_rate;
+ unsigned int oversample_rate, clk_rate;
int bclk_div, mclk_div;
- int ret, i;
+ int ret;
switch (rate) {
case 176400:
@@ -197,21 +209,18 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
if (ret)
return ret;
- /* Always favor the highest oversampling rate */
- for (i = (ARRAY_SIZE(sun4i_i2s_oversample_rates) - 1); i >= 0; i--) {
- unsigned int oversample_rate = sun4i_i2s_oversample_rates[i];
-
- bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
- word_size);
- mclk_div = sun4i_i2s_get_mclk_div(i2s, oversample_rate,
- clk_rate,
- rate);
+ oversample_rate = i2s->mclk_freq / rate;
+ if (!sun4i_i2s_oversample_is_valid(oversample_rate))
+ return -EINVAL;
- if ((bclk_div >= 0) && (mclk_div >= 0))
- break;
- }
+ bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
+ word_size);
+ if (bclk_div < 0)
+ return -EINVAL;
- if ((bclk_div < 0) || (mclk_div < 0))
+ mclk_div = sun4i_i2s_get_mclk_div(i2s, oversample_rate,
+ clk_rate, rate);
+ if (mclk_div < 0)
return -EINVAL;
regmap_write(i2s->regmap, SUN4I_I2S_CLK_DIV_REG,
@@ -481,9 +490,23 @@ static void sun4i_i2s_shutdown(struct snd_pcm_substream *substream,
regmap_write(i2s->regmap, SUN4I_I2S_CTRL_REG, 0);
}
+static int sun4i_i2s_set_sysclk(struct snd_soc_dai *dai, int clk_id,
+ unsigned int freq, int dir)
+{
+ struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+
+ if (clk_id != 0)
+ return -EINVAL;
+
+ i2s->mclk_freq = freq;
+
+ return 0;
+}
+
static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.hw_params = sun4i_i2s_hw_params,
.set_fmt = sun4i_i2s_set_fmt,
+ .set_sysclk = sun4i_i2s_set_sysclk,
.shutdown = sun4i_i2s_shutdown,
.startup = sun4i_i2s_startup,
.trigger = sun4i_i2s_trigger,
--
2.10.2
^ permalink raw reply related
* Applied "spi: atmel: use managed resource for gpio chip select" to the spi tree
From: Mark Brown @ 2016-11-09 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108174852.14311-1-nicolas.ferre@atmel.com>
The patch
spi: atmel: use managed resource for gpio chip select
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9610620078a3900e7fad82de620ce809fd29ba60 Mon Sep 17 00:00:00 2001
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Tue, 8 Nov 2016 18:48:52 +0100
Subject: [PATCH] spi: atmel: use managed resource for gpio chip select
Use the managed gpio CS pin request so that we avoid having trouble
in the cleanup code.
In fact, if module was configured with DT, cleanup code released
invalid pin. Since resource wasn't freed, module cannot be reinserted.
This require to extract the gpio request call from the "setup" function
and call it in the appropriate probe function.
Reported-by: Alexander Morozov <linux@meltdown.ru>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-atmel.c | 50 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8feac599e9ab..d3affa6afe7e 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -24,6 +24,7 @@
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <linux/pinctrl/consumer.h>
#include <linux/pm_runtime.h>
@@ -1204,7 +1205,6 @@ static int atmel_spi_setup(struct spi_device *spi)
u32 csr;
unsigned int bits = spi->bits_per_word;
unsigned int npcs_pin;
- int ret;
as = spi_master_get_devdata(spi->master);
@@ -1247,16 +1247,9 @@ static int atmel_spi_setup(struct spi_device *spi)
if (!asd)
return -ENOMEM;
- if (as->use_cs_gpios) {
- ret = gpio_request(npcs_pin, dev_name(&spi->dev));
- if (ret) {
- kfree(asd);
- return ret;
- }
-
+ if (as->use_cs_gpios)
gpio_direction_output(npcs_pin,
!(spi->mode & SPI_CS_HIGH));
- }
asd->npcs_pin = npcs_pin;
spi->controller_state = asd;
@@ -1471,13 +1464,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
static void atmel_spi_cleanup(struct spi_device *spi)
{
struct atmel_spi_device *asd = spi->controller_state;
- unsigned gpio = (unsigned long) spi->controller_data;
if (!asd)
return;
spi->controller_state = NULL;
- gpio_free(gpio);
kfree(asd);
}
@@ -1499,6 +1490,39 @@ static void atmel_get_caps(struct atmel_spi *as)
}
/*-------------------------------------------------------------------------*/
+static int atmel_spi_gpio_cs(struct platform_device *pdev)
+{
+ struct spi_master *master = platform_get_drvdata(pdev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+ struct device_node *np = master->dev.of_node;
+ int i;
+ int ret = 0;
+ int nb = 0;
+
+ if (!as->use_cs_gpios)
+ return 0;
+
+ if (!np)
+ return 0;
+
+ nb = of_gpio_named_count(np, "cs-gpios");
+ for (i = 0; i < nb; i++) {
+ int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
+ "cs-gpios", i);
+
+ if (cs_gpio == -EPROBE_DEFER)
+ return cs_gpio;
+
+ if (gpio_is_valid(cs_gpio)) {
+ ret = devm_gpio_request(&pdev->dev, cs_gpio,
+ dev_name(&pdev->dev));
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
static int atmel_spi_probe(struct platform_device *pdev)
{
@@ -1577,6 +1601,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
master->num_chipselect = 4;
}
+ ret = atmel_spi_gpio_cs(pdev);
+ if (ret)
+ goto out_unmap_regs;
+
as->use_dma = false;
as->use_pdc = false;
if (as->caps.has_dma_support) {
--
2.10.2
^ permalink raw reply related
* [PATCH] fpga zynq: Check the bitstream for validity
From: Matthias Brugger @ 2016-11-09 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <609bc971-bb6d-8cd2-8e64-23c0082a6216@topic.nl>
On 11/09/2016 03:21 PM, Mike Looijmans wrote:
> On 08-11-16 01:05, Jason Gunthorpe wrote:
>> On Tue, Nov 01, 2016 at 06:48:42PM +0100, Michal Simek wrote:
>>> On 1.11.2016 16:33, Jason Gunthorpe wrote:
>>>> On Tue, Nov 01, 2016 at 07:39:22AM +0100, Michal Simek wrote:
>>>>
>>>>> Regarding BIT and BIN format. This support is in vivado for a long
>>>>> time
>>>>> and it is up2you what you want to support. We have removed that BIT
>>>>> support and not doing any swap by saying only BIN format is supported.
>>>>
>>>> BIN is not supported, it needs a swap as well.
>>>>
>>>> Moritz has it right, you have to use vivado to create a PROM image
>>>> to be
>>>> compatible with the driver.
>>>
>>> hm than that's bad.
>>
>> IMHO, Xilinx made an error with Zynq DevC, the DMA does not accept a
>> memory image that is output by the usual Xilinx tools. It should have
>> accepted a byte swapped input.
>>
>> I think Moritz is right, the fpgamgr *should not* alter the bitstream
>> in any way. This is important for future work to make the DMA do
>> gather and avoid the really bad high-order allocation.
>>
>> So users will have to provide byte swapped .bin files - the vivado
>> write_cfgmem command will produce them - this all needs to be
>> documented.
>>
>> Also, I think Punnaiah (?) was telling me that bitstream encryption
>> does not work - DevC must be told the bitstream is encrypted.
>> That seems like something that needs work at the fpgamgr level - and
>> maybe this driver should auto-detect encryption by looking at the
>> bitfile (as is typical for Xilinx programming)
>>
>
> I think the basic idea behind the commit is flawed to begin with and the
> patch should be discarded completely. The same discussion was done for
> the Xilinx FPGA manager driver, which resulted in the decision that the
> tooling should create a proper file. This driver should either become
> obsolete or at least move into the same direction as the FPGA manager
> rather than away from that.
>
> Besides political arguments, there's a more pressing technical argument
> against this theck as well: The whole check is pointless since the hardware
> itself already verifies the validity of the stream. Sending bitstreams
> intended for other devices has no effect at all. Even sending random
> data doesn't have any effect, the hardware will discard it. There's no
> reason to waste CPU cycles duplicating this check in software.
>
I get your point. Especially looping to the whole file to find the sync
header can take a while, especially if the file is big and the sync
header is not present.
So I think the whole idea behind this patch is to provide feedback to
the user about what went wrong when trying to update the FPGA. Is there
a way to get this information from the hardware which discards the update?
Regards,
Matthias
^ permalink raw reply
* [PATCH] pinctrl: single: check for any error when getting rows
From: Tony Lindgren @ 2016-11-09 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141706.12624-1-ahaslam@baylibre.com>
* Axel Haslam <ahaslam@baylibre.com> [161109 07:19]:
> pinctrl_count_index_with_args returns -ENOENT not
> -EINVAL. The return check would pass, and we would
> try to kzalloc with a negative error size throwing
> a warning.
>
> Instead of checking for -EINVAL specifically, lets
> check for any error and avoid negative size allocations.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Thanks for fixing that:
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/pinctrl/pinctrl-single.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index 539f31c..56e22be 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -1228,7 +1228,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct pcs_device *pcs,
> struct pcs_function *function;
>
> rows = pinctrl_count_index_with_args(np, name);
> - if (rows == -EINVAL)
> + if (rows < 0)
> return rows;
>
> npins_in_row = pcs->width / pcs->bits_per_pin;
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH v2 0/2] pinctrl: single: fixes for davinci
From: Tony Lindgren @ 2016-11-09 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109145401.25327-1-ahaslam@baylibre.com>
* Axel Haslam <ahaslam@baylibre.com> [161109 07:54]:
> After recent pinctl patches we see a warning when booting davinci
> due to a bad memory allocation:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:3511 __alloc_pages_nodemask+0x16c/0xb18
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc2-00023-g22d5127-dirty #1019
> Hardware name: Generic DA850/OMAP-L138/AM18x
> Backtrace:
> [<c000d670>] (dump_backtrace) from [<c000d794>] (show_stack+0x18/0x1c)
> [<c000d77c>] (show_stack) from [<c021a0d0>] (dump_stack+0x20/0x28)
> [<c021a0b0>] (dump_stack) from [<c001bb10>] (__warn+0xe8/0x100)
> [<c001ba28>] (__warn) from [<c001bb50>] (warn_slowpath_null+0x28/0x30)
> [<c001bb28>] (warn_slowpath_null) from [<c0097e7c>] (__alloc_pages_nodemask+0x16c/0xb18)
> [<c0097d10>] (__alloc_pages_nodemask) from [<c00afef4>] (kmalloc_order+0x20/0x58)
> [<c00afed4>] (kmalloc_order) from [<c00ce7ac>] (__kmalloc_track_caller+0x188/0x190)
> [<c00ce624>] (__kmalloc_track_caller) from [<c02a762c>] (devm_kmalloc+0x24/0x70)
> [<c02a7608>] (devm_kmalloc) from [<c0247d10>] (pcs_dt_node_to_map+0x1d0/0xa40)
> [<c0245ec8>] (pinctrl_dt_to_map) from [<c0242fd0>] (pinctrl_get+0xe8/0x484)
> [snip]
>
> This series fixes this error.
Thanks for fixing these and sorry about breaking pinctrl-bits:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure
From: Robin Murphy @ 2016-11-09 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-8-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> Since acpi_dma_configure() is used to configure DMA operations, the
> function initializes the dma/coherent_dma masks to sane default values
> if the current masks are uninitialized (also to keep the default values
> consistent with DT systems) to make sure the device has a complete
> default DMA set-up.
>
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> drivers/pci/probe.c | 3 +--
> include/acpi/acpi_bus.h | 2 ++
> include/linux/acpi.h | 5 +++++
> 5 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 5ea5dc2..f8d6564 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -227,8 +227,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>
> attr = acpi_get_dma_attr(acpi_dev);
> if (attr != DEV_DMA_NOT_SUPPORTED)
> - arch_setup_dma_ops(dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(dev, attr);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> @@ -251,6 +250,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> return 0;
>
> err:
> + acpi_dma_deconfigure(dev);
> ACPI_COMPANION_SET(dev, NULL);
> put_device(dev);
> put_device(&acpi_dev->dev);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 035ac64..694e0b6 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,6 +1370,46 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NON_COHERENT;
> }
>
> +/**
> + * acpi_dma_configure - Set-up DMA configuration for the device.
> + * @dev: The pointer to the device
> + * @attr: device dma attributes
> + */
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +{
> + /*
> + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> + * setup the correct supported mask.
> + */
> + if (!dev->coherent_dma_mask)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> + * Set it to coherent_dma_mask by default if the architecture
> + * code has not set it.
> + */
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + /*
> + * Assume dma valid range starts at 0 and covers the whole
> + * coherent_dma_mask.
> + */
> + arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> + attr == DEV_DMA_COHERENT);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_configure);
> +
> +/**
> + * acpi_dma_deconfigure - Tear-down DMA configuration for the device.
> + * @dev: The pointer to the device
> + */
> +void acpi_dma_deconfigure(struct device *dev)
> +{
> + arch_teardown_dma_ops(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_deconfigure);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ab00267..c29e07a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1738,8 +1738,7 @@ static void pci_dma_configure(struct pci_dev *dev)
> if (attr == DEV_DMA_NOT_SUPPORTED)
> dev_warn(&dev->dev, "DMA not supported.\n");
If we're going to check attr for DMA support before each call like this,
it seems like we may as well put the check at the top of
acpi_dma_configure() instead. I think it should be viable to predicate
the warning on dev_is_pci() at this point, if that's the appropriate
behaviour.
Still, we're likely to be touching this again soon with the
IOMMU-probe-ordering work, so there's plenty of room for further
cleanups then:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> else
> - arch_setup_dma_ops(&dev->dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(&dev->dev, attr);
> }
>
> pci_put_host_bridge_device(bridge);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index c1a524d..4242c31 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,6 +573,8 @@ struct acpi_pci_root {
>
> bool acpi_dma_supported(struct acpi_device *adev);
> enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +void acpi_dma_deconfigure(struct device *dev);
>
> struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> u64 address, bool check_children);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 6efb13c..df961f4 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -764,6 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NOT_SUPPORTED;
> }
>
> +static inline void acpi_dma_configure(struct device *dev,
> + enum dev_dma_attr attr) { }
> +
> +static inline void acpi_dma_deconfigure(struct device *dev) { }
> +
> #define ACPI_PTR(_ptr) (NULL)
>
> static inline void acpi_device_set_enumerated(struct acpi_device *adev)
>
^ permalink raw reply
* [PATCH] mfd: qcom-pm8xxx: Clean up PM8XXX namespace
From: Lee Jones @ 2016-11-09 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477487453-15801-1-git-send-email-linus.walleij@linaro.org>
On Wed, 26 Oct 2016, Linus Walleij wrote:
> The Kconfig and file naming for the PM8xxx driver is totally
> confusing:
>
> - Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel
> users depending on or selecting either at random.
> - A driver file named pm8921-core.c even if it is indeed
> used by the whole PM8xxx family of chips.
> - An irqchip named pm8xxx since it was (I guess) realized that
> the driver was generic for all pm8xxx PMICs.
>
> As I may want to add support for PM8901 this is starting to get
> really messy. Fix this situation by:
>
> - Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX
> and convert all users, including LEDs Kconfig and ARM defconfigs
> for qcom and multi_v7 to use that single symbol.
> - Renaming the driver to qcom-pm8xxx.c to fit along the two
> other qcom* prefixed drivers.
> - Rename functions withing the driver from 8921 to 8xxx to
> indicate it is generic.
> - Just drop the =m config from the pxa_defconfig, I have no clue
> why it is even there, it is not a Qualcomm platform. (Possibly
> older Kconfig noise from saveconfig.)
>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I do NOT think it is a good idea to try to split this commit up,
> I rather prefer that Lee simply merge it into MFD.
>
> The reason is that files like qcom_defconfig already contain both
> the right symbols, but the MFD_PM8921_CORE symbol cannot be removed
> until this rename has happened, whereas multi_v7_defconfig needs
> it added etc, and this is just a clean nice cut.
>
> Jacek, ARM SoC person: please ACK this patch to get merged into
> MFD.
> ---
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/pxa_defconfig | 1 -
> arch/arm/configs/qcom_defconfig | 1 -
> drivers/leds/Kconfig | 2 +-
> drivers/mfd/Kconfig | 14 ++++------
> drivers/mfd/Makefile | 2 +-
> drivers/mfd/{pm8921-core.c => qcom-pm8xxx.c} | 42 ++++++++++++++--------------
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> 7 files changed, 29 insertions(+), 35 deletions(-)
> rename drivers/mfd/{pm8921-core.c => qcom-pm8xxx.c} (92%)
How many more Acks do we need?
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox