Re: [PATCH v3 2/2] sched: consider missed ticks when updating global cpu load
On Fri, Oct 02, 2015 at 05:59:06PM +0200, Peter Zijlstra wrote: > On Fri, Oct 02, 2015 at 04:46:14PM +0900, byungchul.p...@lge.com wrote: > > From: Byungchul Park > > > > in hrtimer_interrupt(), the first tick_program_event() can be failed > > because the next timer could be already expired due to, > > (see the comment in hrtimer_interrupt()) > > > > - tracing > > - long lasting callbacks > > If anything keeps interrupts disabled for longer than 1 tick, you'd > better go fix that. tracing and long lasting callbacks are not my case. > > > - being scheduled away when running in a VM this is my case. > > Not sure how much I should care about that, and this patch is completely > wrong for that anyhow. do you mean, in upper case, we must assume ticks occur with 1 tick interval when update_process_times() is called even though more than 1 tick is actually passed in host? right? i am really wondering it. i would admit i was wrong if what you mean is same as what i understand. > > And this case in hrtimer_interrupt() is basically a fail case, if you > hit that, you've got bigger problems. The solution is to rework things > so you don't get there. > > > > in the case that the first tick_program_event() is failed, the second > > tick_program_event() set the expired time to more than one tick later. > > then next tick can happen after more than one tick, even though tick is > > not stopped by e.g. NOHZ. > > > > when the next tick occurs, update_process_times() -> scheduler_tick() > > -> update_cpu_load_active() is performed, assuming the distance between > > last tick and current tick is 1 tick! it's wrong in this case. thus, > > this abnormal case should be considered in update_cpu_load_active(). > > Everything in update_process_times() assumes 1 tick, just fixing up > one function inside that callchain is wrong -- I've already told you > that. anyway, it's wrong for update_process_times() to assume 1 tick because tick_irq_exit() -> tick_nohz_irq_exit() -> tick_nohz_full_update_tick() -> tick_nohz_restart_sched_tick() can happen at full NOHZ as i already said. in this full NOHZ case for tick to restart from non-idle, 1. update_process_times() -> account_process_tick() must be able to handle more than one tick, or tick_nohz_restart_sched_tick() should handle the case additionally. (i think the latter is better.) i will try to modify the code to handle it if you agree with me. 2. to handle full NOHZ, tick_nohz_restart_sched_tick() should call update_cpu_load_active() instead of update_cpu_load_nohz() with my 1/2 patch and 2/2 patch, or we should modify update_cpu_load_nohz() to know full NOHZ, which currently don't know full NOHZ. (you may agree with the latter.) in any case, 1/2 patch is necessary which current code is absolutely missing. peter, what do you think about my opinion? and about my 1/2 patch? i will modify 2/2 patch depending on your feedback. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rdma: Fix braces around if/else
On 10/3/2015 11:55 PM, Martin Kletzander wrote: Get rid of all ELSE_AFTER_BRACE type errors reported by checkpatch.pl. Hi Greg, Is there a way to signal people/tools that a certain driver parks in staging on their way **out** of the kernel and not the other way around? I guess you (nor Doug) don't want to spend time on fixing such drivers, right? Or. Signed-off-by: Martin Kletzander --- There is one warning reported in this patch though. That's because of the multiline string and it's pre-existing. Feel free to let me know if that should be fixed too, I'd also remove the pointless '#' then. On the other hand, it'll create more-than-80-columns long line. drivers/staging/rdma/ipath/ipath_driver.c| 19 --- drivers/staging/rdma/ipath/ipath_file_ops.c | 12 ++-- drivers/staging/rdma/ipath/ipath_iba6110.c | 7 +++ drivers/staging/rdma/ipath/ipath_init_chip.c | 10 +- drivers/staging/rdma/ipath/ipath_intr.c | 7 +++ drivers/staging/rdma/ipath/ipath_sysfs.c | 7 +++ drivers/staging/rdma/ipath/ipath_verbs.c | 4 ++-- 7 files changed, 30 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lockdep: drop unlikely behind DEBUG_LOCKS_WARN_ON()
DEBUG_LOCKS_WARN_ON() already contain an unlikely compiler flag. Drop it. Signed-off-by: Geliang Tang --- kernel/locking/lockdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index deae390..9d8cbb1 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -2598,7 +2598,7 @@ __visible void trace_hardirqs_on_caller(unsigned long ip) /* * See the fine text that goes along with this variable definition. */ - if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled))) + if (DEBUG_LOCKS_WARN_ON(early_boot_irqs_disabled)) return; /* -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cfg80211: drop unlikely behind WARN_ON()
WARN_ON() already contain an unlikely compiler flag. Drop it. Signed-off-by: Geliang Tang --- drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c index a511ef3..fe38fc4 100644 --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c @@ -2217,7 +2217,7 @@ static int ath6kl_wow_suspend(struct ath6kl *ar, struct cfg80211_wowlan *wow) /* enter / leave wow suspend on first vif always */ first_vif = ath6kl_vif_first(ar); - if (WARN_ON(unlikely(!first_vif)) || + if (WARN_ON(!first_vif) || !ath6kl_cfg80211_ready(first_vif)) return -EIO; @@ -2297,7 +2297,7 @@ static int ath6kl_wow_resume(struct ath6kl *ar) int ret; vif = ath6kl_vif_first(ar); - if (WARN_ON(unlikely(!vif)) || + if (WARN_ON(!vif) || !ath6kl_cfg80211_ready(vif)) return -EIO; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] staging: fsl-mc: add function to return pointer to root dprc
From: Itai Katz
To support multiple root dprcs, instead of relying on the
dev_root field of the bus type struct, instead create a
function to traverse to the root dprc and return a pointer
to the device struct
Signed-off-by: Itai Katz
---
drivers/staging/fsl-mc/bus/mc-bus.c | 38 +++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 6a6c5a6..37f51f3 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -218,11 +218,34 @@ bool fsl_mc_bus_exists(void)
EXPORT_SYMBOL_GPL(fsl_mc_bus_exists);
/**
+* fsl_mc_get_root_dprc - function to traverse to the root dprc
+*/
+static void fsl_mc_get_root_dprc(struct device *dev,
+struct device **root_dprc_dev)
+{
+ if (WARN_ON(!dev)) {
+ *root_dprc_dev = NULL;
+ } else if (WARN_ON(dev->bus != &fsl_mc_bus_type)) {
+ *root_dprc_dev = NULL;
+ } else {
+ *root_dprc_dev = dev;
+ while ((*root_dprc_dev)->parent->bus == &fsl_mc_bus_type)
+ *root_dprc_dev = (*root_dprc_dev)->parent;
+ }
+}
+
+/**
* fsl_mc_is_root_dprc - function to check if a given device is a root dprc
*/
static bool fsl_mc_is_root_dprc(struct device *dev)
{
- return dev == fsl_mc_bus_type.dev_root;
+ struct device *root_dprc_dev;
+
+ fsl_mc_get_root_dprc(dev, &root_dprc_dev);
+ if (!root_dprc_dev)
+ return false;
+ else
+ return dev == root_dprc_dev;
}
static int get_dprc_icid(struct fsl_mc_io *mc_io,
@@ -253,11 +276,18 @@ common_cleanup:
return error;
}
-static int translate_mc_addr(enum dprc_region_type mc_region_type,
+static int translate_mc_addr(struct fsl_mc_device *mc_dev,
+enum dprc_region_type mc_region_type,
u64 mc_offset, phys_addr_t *phys_addr)
{
int i;
- struct fsl_mc *mc = dev_get_drvdata(fsl_mc_bus_type.dev_root->parent);
+ struct device *root_dprc_dev;
+ struct fsl_mc *mc;
+
+ fsl_mc_get_root_dprc(&mc_dev->dev, &root_dprc_dev);
+ if (WARN_ON(!root_dprc_dev))
+ return -EINVAL;
+ mc = dev_get_drvdata(root_dprc_dev->parent);
if (mc->num_translation_ranges == 0) {
/*
@@ -328,7 +358,7 @@ static int fsl_mc_device_get_mmio_regions(struct
fsl_mc_device *mc_dev,
}
WARN_ON(region_desc.size == 0);
- error = translate_mc_addr(mc_region_type,
+ error = translate_mc_addr(mc_dev, mc_region_type,
region_desc.base_offset,
®ions[i].start);
if (error < 0) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] staging: fsl-mc: add counter to track number of root DPRCs
From: Itai Katz
Add a counter to track the number of root DPRCs.
When this counter is greater then 0 it means that at least
one root DPRC device exists.
Signed-off-by: Itai Katz
---
drivers/staging/fsl-mc/bus/mc-bus.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 37f51f3..8a2b99c 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -109,6 +109,8 @@ struct bus_type fsl_mc_bus_type = {
};
EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
+static atomic_t root_dprc_count = ATOMIC_INIT(0);
+
static int fsl_mc_driver_probe(struct device *dev)
{
struct fsl_mc_driver *mc_drv;
@@ -213,7 +215,7 @@ EXPORT_SYMBOL_GPL(fsl_mc_driver_unregister);
*/
bool fsl_mc_bus_exists(void)
{
- return fsl_mc_bus_type.dev_root;
+ return atomic_read(&root_dprc_count) > 0;
}
EXPORT_SYMBOL_GPL(fsl_mc_bus_exists);
@@ -458,6 +460,8 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
if (!fsl_mc_bus_exists())
fsl_mc_bus_type.dev_root = &mc_dev->dev;
+
+ atomic_inc(&root_dprc_count);
}
error = get_dprc_icid(mc_io2, obj_desc->id, &mc_dev->icid);
@@ -540,8 +544,13 @@ void fsl_mc_device_remove(struct fsl_mc_device *mc_dev)
mc_dev->mc_io = NULL;
}
- if (fsl_mc_is_root_dprc(&mc_dev->dev))
+ if (fsl_mc_is_root_dprc(&mc_dev->dev)) {
fsl_mc_bus_type.dev_root = NULL;
+ if (atomic_read(&root_dprc_count) > 0)
+ atomic_dec(&root_dprc_count);
+ else
+ WARN_ON(1);
+ }
}
if (mc_bus)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rdma: Fix braces around if/else
On Sun, Oct 04, 2015 at 09:47:52AM +0300, Or Gerlitz wrote: > On 10/3/2015 11:55 PM, Martin Kletzander wrote: > >Get rid of all ELSE_AFTER_BRACE type errors reported by checkpatch.pl. > > Hi Greg, > > Is there a way to signal people/tools that a certain driver parks in staging > on their way **out** of the kernel > and not the other way around? I guess you (nor Doug) don't want to spend > time on fixing such drivers, right? I'm not spending the time :) But no, there isn't a way to really show that that I know of, and it's fine, we end up getting a number of "cleanup" patches for a kernel release or two before the drivers get deleted. It gets people involved in kernel development which is the key thing here, it's not like they are actually using these drivers... So it's fine, I take the patches, the people writing the patches are happy, and the code gets a bit nicer and feels better about itself before we kick it out the door. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller.
Hi Thomas:
在 2015/10/1 5:37, Thomas Gleixner 写道:
> On Wed, 30 Sep 2015, MaJun wrote:
>
> First of all.
>
> [PATCH v5 1/3] initialize each mbigen device node as a interrupt controller
>
> is not a proper subject line, but that's the least of your problems.
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "irqchip.h"
>
> Do you really need all these includes?
Ok, I will remove usless includes.
>
>> +
>> +/* Interrupt numbers per mbigen node supported */
>> +#define IRQS_PER_MBIGEN_NODE(128)
>
[...]
>> +
>> +info = &mgn_dev->mgn_data[index].info;
>> +info->index = index;
>> +info->global_pin_offset = GET_IRQ_PIN_OFFSET(d->hwirq);
>> +info->nid = info->global_pin_offset / IRQS_PER_MBIGEN_NODE;
>> +
>> +info->local_pin_offset = (info->global_pin_offset %
>> IRQS_PER_MBIGEN_NODE)
>> +- RESERVED_IRQ_PER_MBIGEN_CHIP;
>> +
>> +info->reg_offset = get_mbigen_vec_reg_addr(info->nid,
>> info->local_pin_offset);
>
> So you fill in a structure with 5 fields and the only information
> which is ever used is local_pin_offset.
>
> What's the point of this exercise?
Besides local_pin_offset , nid, and reg_offset are also useful information
which will be used
in next patch.
For each mbigen chip, the register space of mbigen node between each other is
discontinuous.
So, I need to find the mbigen node number(nid) and pin offset within this
mbigen node
(local_pin_offset). Based on them, I can get the corresponding register address.
>
>> +
>> +return &mgn_dev->mgn_data[index];
>> +}
>> +
>> +static int mbigen_set_affinity(struct irq_data *data,
>> +const struct cpumask *mask_val,
>> +bool force)
>> +{
>> +struct mbigen_irq_data *mgn_irq_data = irq_data_get_irq_chip_data(data);
>> +struct irq_chip *chip = irq_get_chip(mgn_irq_data->msi_irq);
>
> And that msi_irq information comes from where? Nothing in that code
> initializes it.
msi_irq is is initialized in next patch.
>> +struct irq_data *parent_d = irq_get_irq_data(mgn_irq_data->msi_irq);
>
> Also WHY are you going through a full lookup of the chip and the irq
> data, if that is your parent irq? That's what the domain hierarchy is
> for. If you now tell me, that msi_irq is not the same as data->irq,
> i.e. the virq number, then you have a lot more things to explain.
Yes, they have different virq number. My explanation about this
problem is list at last.
> irq_chip_set_affinity_parent() is the callback you want for your chip,
> not some completely nonsensical hackery.
I think this is used for hierarchy structure. My interrupt controller is not
hierarchy structrue.
>
>> +
>> +if (chip && chip->irq_set_affinity)
>
> Why would chip ever be NULL? If your parent interrupt does not have a
> chip assigned then your whole setup is hosed.
>
>> +static void mbigen_eoi_irq(struct irq_data *data)
>> +{
>> +
>> +struct mbigen_irq_data *mgn_irq_data = irq_data_get_irq_chip_data(data);
>> +struct mbigen_device *mgn_dev = mgn_irq_data->dev;
>
> So the only reason for accessing yet another data structure is to get
> the base address of that mbi device. You seem to have a strong
> interest in making the cache foot print of your code as big as
> possible.
>
>> +struct irq_chip *chip = irq_get_chip(mgn_irq_data->msi_irq);
>> +struct irq_data *parent_d = irq_get_irq_data(mgn_irq_data->msi_irq);
>> +u32 pin_offset, ofst, mask;
>> +
>> +pin_offset = mgn_irq_data->info.local_pin_offset;
>> +
>> +ofst = pin_offset / 32 * 4;
>> +mask = 1 << (pin_offset % 32);
>> +
>> +writel_relaxed(mask, mgn_dev->base + ofst
>> ++ REG_MBIGEN_CLEAR_OFFSET);
>> +
>> +if (chip && chip->irq_eoi)
>> +chip->irq_eoi(parent_d);
>
> So again. Why would chip be NULL and why would chip NOT have an EOI
> callback?
>
>> +static int mbigen_domain_xlate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq,
>> + unsigned int *out_type)
>> +{
>> +
>> +if (d->of_node != controller)
>> +return -EINVAL;
>> +
>> +if (intsize < 2)
>> +return -EINVAL;
>> +
>> +/* Compose the hwirq local to mbigen domain
>> + * intspec[0]: interrut pin offset
>> + * intspec[1]: index(start from 0)
>> + */
>> +*out_hwirq = COMPOSE_MBIGEN_HWIRQ(intspec[1], intspec[0]);
>
> So here you use that convoluted MACRO. Why can't you open code it so
> we don't have to go up to the top of the file to see what you are
> composing?
>
> We use macros and inlines for things which are used over and over, but
> not for code obfuscation.
>
>> +static int
[PATCH 0/5] staging: fsl-mc: multiple root DPRCs
From: Itai Katz This patch series adds support for supporting multiple root DPRCs, which is an item on the TODO list. (This situation can is possible when assigning multiple DPRCs to KVM virtual machines.) Patch 1 abstracts the test for existence of an fsl-mc bus instance into a function. Patch 2 abstracts the test for whether a dprc is a root dprc into a function. Patch 3 replaces use of the dev_root field in the bus type struct to identify the root dprc with a more flexible pointer traversal mechanism. Patch 4 adds a counter to track the number of root dprcs. Patch 5 removes all references to the now unused dev_root Itai Katz (5): staging: fsl-mc: abstract test for existence of fsl-mc bus staging: fsl-mc: abstract test for whether a dprc is a root dprc staging: fsl-mc: add function to return pointer to root dprc staging: fsl-mc: add counter to track number of root DPRCs staging: fsl-mc: remove references to dev_root drivers/staging/fsl-mc/bus/mc-bus.c | 74 ++- drivers/staging/fsl-mc/include/mc.h |2 + 2 files changed, 66 insertions(+), 10 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] staging: fsl-mc: abstract test for whether a dprc is a root dprc
From: Itai Katz
Instead of relying on assumptions about fields in data
structures, abstract the test for whether a dprc is a root
dprc into a function.
Signed-off-by: Itai Katz
---
drivers/staging/fsl-mc/bus/mc-bus.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 2aaeb3a..6a6c5a6 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -22,6 +22,8 @@
static struct kmem_cache *mc_dev_cache;
+static bool fsl_mc_is_root_dprc(struct device *dev);
+
/**
* fsl_mc_bus_match - device to driver matching callback
* @dev: the MC object device structure to match against
@@ -50,7 +52,7 @@ static int fsl_mc_bus_match(struct device *dev, struct
device_driver *drv)
* Only exception is the root DPRC, which is a special case.
*/
if ((mc_dev->obj_desc.state & DPRC_OBJ_STATE_PLUGGED) == 0 &&
- &mc_dev->dev != fsl_mc_bus_type.dev_root)
+ !fsl_mc_is_root_dprc(&mc_dev->dev))
goto out;
/*
@@ -215,6 +217,14 @@ bool fsl_mc_bus_exists(void)
}
EXPORT_SYMBOL_GPL(fsl_mc_bus_exists);
+/**
+ * fsl_mc_is_root_dprc - function to check if a given device is a root dprc
+ */
+static bool fsl_mc_is_root_dprc(struct device *dev)
+{
+ return dev == fsl_mc_bus_type.dev_root;
+}
+
static int get_dprc_icid(struct fsl_mc_io *mc_io,
int container_id, u16 *icid)
{
@@ -500,7 +510,7 @@ void fsl_mc_device_remove(struct fsl_mc_device *mc_dev)
mc_dev->mc_io = NULL;
}
- if (&mc_dev->dev == fsl_mc_bus_type.dev_root)
+ if (fsl_mc_is_root_dprc(&mc_dev->dev))
fsl_mc_bus_type.dev_root = NULL;
}
@@ -726,7 +736,7 @@ static int fsl_mc_bus_remove(struct platform_device *pdev)
{
struct fsl_mc *mc = platform_get_drvdata(pdev);
- if (WARN_ON(&mc->root_mc_bus_dev->dev != fsl_mc_bus_type.dev_root))
+ if (WARN_ON(!fsl_mc_is_root_dprc(&mc->root_mc_bus_dev->dev)))
return -EINVAL;
fsl_mc_device_remove(mc->root_mc_bus_dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] staging: fsl-mc: abstract test for existence of fsl-mc bus
From: Itai Katz
Add function to test for existence of an fsl-mc bus instance
instead of doing this by looking directly at a field in the
bus type struct.
Signed-off-by: Itai Katz
---
drivers/staging/fsl-mc/bus/mc-bus.c | 13 +++--
drivers/staging/fsl-mc/include/mc.h |2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 92e0702..2aaeb3a 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -39,7 +39,7 @@ static int fsl_mc_bus_match(struct device *dev, struct
device_driver *drv)
bool major_version_mismatch = false;
bool minor_version_mismatch = false;
- if (WARN_ON(!fsl_mc_bus_type.dev_root))
+ if (WARN_ON(!fsl_mc_bus_exists()))
goto out;
if (!mc_drv->match_id_table)
@@ -206,6 +206,15 @@ void fsl_mc_driver_unregister(struct fsl_mc_driver
*mc_driver)
}
EXPORT_SYMBOL_GPL(fsl_mc_driver_unregister);
+/**
+ * fsl_mc_bus_exists - check if a root dprc exists
+ */
+bool fsl_mc_bus_exists(void)
+{
+ return fsl_mc_bus_type.dev_root;
+}
+EXPORT_SYMBOL_GPL(fsl_mc_bus_exists);
+
static int get_dprc_icid(struct fsl_mc_io *mc_io,
int container_id, u16 *icid)
{
@@ -407,7 +416,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
mc_io2 = mc_io;
- if (!fsl_mc_bus_type.dev_root)
+ if (!fsl_mc_bus_exists())
fsl_mc_bus_type.dev_root = &mc_dev->dev;
}
diff --git a/drivers/staging/fsl-mc/include/mc.h
b/drivers/staging/fsl-mc/include/mc.h
index 860bf26..a933291 100644
--- a/drivers/staging/fsl-mc/include/mc.h
+++ b/drivers/staging/fsl-mc/include/mc.h
@@ -182,6 +182,8 @@ int __must_check __fsl_mc_driver_register(struct
fsl_mc_driver *fsl_mc_driver,
void fsl_mc_driver_unregister(struct fsl_mc_driver *driver);
+bool fsl_mc_bus_exists(void);
+
int __must_check fsl_mc_portal_allocate(struct fsl_mc_device *mc_dev,
u16 mc_io_flags,
struct fsl_mc_io **new_mc_io);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] staging: fsl-mc: remove references to dev_root
From: Itai Katz
The dev_root field in the bus type struct has been replaced by a
new mechanism to identify the root dprc. Remove all references
to dev_root.
Signed-off-by: Itai Katz
---
drivers/staging/fsl-mc/bus/mc-bus.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/mc-bus.c
b/drivers/staging/fsl-mc/bus/mc-bus.c
index 8a2b99c..fd13053 100644
--- a/drivers/staging/fsl-mc/bus/mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/mc-bus.c
@@ -458,9 +458,6 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
mc_io2 = mc_io;
- if (!fsl_mc_bus_exists())
- fsl_mc_bus_type.dev_root = &mc_dev->dev;
-
atomic_inc(&root_dprc_count);
}
@@ -545,7 +542,6 @@ void fsl_mc_device_remove(struct fsl_mc_device *mc_dev)
}
if (fsl_mc_is_root_dprc(&mc_dev->dev)) {
- fsl_mc_bus_type.dev_root = NULL;
if (atomic_read(&root_dprc_count) > 0)
atomic_dec(&root_dprc_count);
else
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL REQUEST] md fixes for 4.3
Hi Linus, a few md bug fixes. Thanks, NeilBrown The following changes since commit bcee19f424a0d8c26ecf2607b73c690802658b29: Merge branch 'for-4.3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2015-09-21 18:26:54 -0700) are available in the git repository at: git://neil.brown.name/md tags/md/4.3-fixes for you to fetch changes up to da6fb7a9e5bd6f04f7e15070f630bdf1ea502841: md/bitmap: don't pass -1 to bitmap_storage_alloc. (2015-10-02 17:24:13 +1000) Assorted fixes for md in 4.3-rc Two tagged for -stable One is really a cleanup to match and improve kmemcache interface. Jes Sorensen (1): md/raid1: Avoid raid1 resync getting stuck Julia Lawall (1): md: drop null test before destroy functions NeilBrown (4): md: wait for pending superblock updates before switching to read-only md/raid5: don't index beyond end of array in need_this_block(). md/raid0: apply base queue limits *before* disk_stack_limits md/bitmap: don't pass -1 to bitmap_storage_alloc. Shaohua Li (2): raid5: update analysis state for failed stripe md: clear CHANGE_PENDING in readonly array drivers/md/bitmap.c| 3 ++- drivers/md/md.c| 5 + drivers/md/multipath.c | 3 +-- drivers/md/raid0.c | 12 ++-- drivers/md/raid1.c | 11 --- drivers/md/raid10.c| 9 +++-- drivers/md/raid5.c | 11 +++ 7 files changed, 28 insertions(+), 26 deletions(-) signature.asc Description: PGP signature
Re: [PATCH 01/18] mpt2sas: Use mpi headers from mpt3sas
Wasn't this originally my patch? Not that I really care for this trivial move, but the commit log just sounded familar. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] block: generic request_queue reference counting
On Wed, Sep 30, 2015 at 8:41 AM, Dan Williams wrote:
> Allow pmem, and other synchronous/bio-based block drivers, to fallback
Just a bit curious, why not extend it for all(both synchronous and
asynchrounous) bio-based drivers? As you mentioned in introductory
message, all bio based drivers may have this kind of problem.
One idea I thought of is to hold the usage counter in bio life time,
instead of request's life time like in blk-mq.
> on a per-cpu reference count managed by the core for tracking queue
> live/dead state.
>
> The existing per-cpu reference count for the blk_mq case is promoted to
> be used in all block i/o scenarios. This involves initializing it by
> default, waiting for it to drop to zero at exit, and holding a live
> reference over the invocation of q->make_request_fn() in
It isn't enough for asynchrounous bio drivers.
> generic_make_request(). The blk_mq code continues to take its own
> reference per blk_mq request and retains the ability to freeze the
> queue, but the check that the queue is frozen is moved to
> generic_make_request().
>
> This fixes crash signatures like the following:
>
> BUG: unable to handle kernel paging request at 88014000
> [..]
> Call Trace:
> [] ? copy_user_handle_tail+0x5f/0x70
> [] pmem_do_bvec.isra.11+0x70/0xf0 [nd_pmem]
> [] pmem_make_request+0xd1/0x200 [nd_pmem]
> [] ? mempool_alloc+0x72/0x1a0
> [] generic_make_request+0xd6/0x110
> [] submit_bio+0x76/0x170
> [] submit_bh_wbc+0x12f/0x160
> [] submit_bh+0x12/0x20
> [] jbd2_write_superblock+0x8d/0x170
> [] jbd2_mark_journal_empty+0x5d/0x90
> [] jbd2_journal_destroy+0x24b/0x270
> [] ? put_pwq_unlocked+0x2a/0x30
> [] ? destroy_workqueue+0x225/0x250
> [] ext4_put_super+0x64/0x360
> [] generic_shutdown_super+0x6a/0xf0
>
> Cc: Jens Axboe
> Cc: Keith Busch
> Cc: Ross Zwisler
> Suggested-by: Christoph Hellwig
> Signed-off-by: Dan Williams
> ---
> block/blk-core.c | 71 +--
> block/blk-mq-sysfs.c |6
> block/blk-mq.c | 80
> ++--
> block/blk-sysfs.c |3 +-
> block/blk.h| 14
> include/linux/blk-mq.h |1 -
> include/linux/blkdev.h |2 +
> 7 files changed, 102 insertions(+), 75 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 2eb722d48773..6062550baaef 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -554,19 +554,17 @@ void blk_cleanup_queue(struct request_queue *q)
> * Drain all requests queued before DYING marking. Set DEAD flag to
> * prevent that q->request_fn() gets invoked after draining finished.
> */
> - if (q->mq_ops) {
> - blk_mq_freeze_queue(q);
> - spin_lock_irq(lock);
> - } else {
> - spin_lock_irq(lock);
> + blk_freeze_queue(q);
> + spin_lock_irq(lock);
> + if (!q->mq_ops)
> __blk_drain_queue(q, true);
> - }
> queue_flag_set(QUEUE_FLAG_DEAD, q);
> spin_unlock_irq(lock);
>
> /* @q won't process any more request, flush async actions */
> del_timer_sync(&q->backing_dev_info.laptop_mode_wb_timer);
> blk_sync_queue(q);
> + percpu_ref_exit(&q->q_usage_counter);
>
> if (q->mq_ops)
> blk_mq_free_queue(q);
> @@ -629,6 +627,40 @@ struct request_queue *blk_alloc_queue(gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(blk_alloc_queue);
>
> +int blk_queue_enter(struct request_queue *q, gfp_t gfp)
> +{
> + while (true) {
> + int ret;
> +
> + if (percpu_ref_tryget_live(&q->q_usage_counter))
> + return 0;
> +
> + if (!(gfp & __GFP_WAIT))
> + return -EBUSY;
> +
> + ret = wait_event_interruptible(q->mq_freeze_wq,
> + !atomic_read(&q->mq_freeze_depth) ||
> + blk_queue_dying(q));
> + if (blk_queue_dying(q))
> + return -ENODEV;
> + if (ret)
> + return ret;
> + }
> +}
> +
> +void blk_queue_exit(struct request_queue *q)
> +{
> + percpu_ref_put(&q->q_usage_counter);
> +}
> +
> +static void blk_queue_usage_counter_release(struct percpu_ref *ref)
> +{
> + struct request_queue *q =
> + container_of(ref, struct request_queue, q_usage_counter);
> +
> + wake_up_all(&q->mq_freeze_wq);
> +}
> +
> struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
> {
> struct request_queue *q;
> @@ -690,11 +722,22 @@ struct request_queue *blk_alloc_queue_node(gfp_t
> gfp_mask, int node_id)
>
> init_waitqueue_head(&q->mq_freeze_wq);
>
> - if (blkcg_init_queue(q))
> + /*
> +* Init percpu_ref in atomic mode so that it's faster to shutdown.
> +* See blk_register_queue() for details.
> +*/
> +
Re: [PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver
On Sat, Oct 03, 2015 at 07:28:07PM -0400, Gabriel L. Somlo wrote:
> From: Gabriel Somlo
>
> Instead of blindly probing fw_cfg registers at known IOport and MMIO
> locations, use the ACPI subsystem to determine whether a QEMU fw_cfg
> device is present, and, if found, to initialize it.
>
> This limits portability to architectures which support ACPI (x86 and
> UEFI-enabled aarch64), but avoids touching hardware registers before
> being certain that our device is present.
>
> NOTE: The standard way to verify the presence of fw_cfg on arm VMs
> would have been to use the device tree, but that would have left out
> x86, which is the primary architecture targeted by this patch.
>
> Signed-off-by: Gabriel Somlo
IMHO it's not a good idea to probe registers provided
by CRS like this.
It seems quite reasonable that we'd want to add some
extra registers in the future, and this probing will break.
Further, accessing registers directly means that there's
no way to have ACPI code access them as that would
cause race conditions.
Maybe we should provide access methods in ACPI instead?
> ---
> .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 4 +
> drivers/firmware/Kconfig | 2 +-
> drivers/firmware/qemu_fw_cfg.c | 201
> +++--
> 3 files changed, 113 insertions(+), 94 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> index f1ef44e..e9761bf 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
> @@ -76,6 +76,10 @@ Description:
> the port number of the control register. I.e., the two ports
> are overlapping, and can not be mapped separately.
>
> + NOTE 2. QEMU publishes the register details in the device tree
> + on arm guests, and in ACPI (under _HID "QEMU0002") on x86 and
> + select arm (aarch64) VM types.
> +
> === Firmware Configuration Items of Interest ===
>
> Originally, the index key, size, and formatting of blobs in
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 0466e80..bc12d31 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -137,7 +137,7 @@ config ISCSI_IBFT
>
> config FW_CFG_SYSFS
> tristate "QEMU fw_cfg device support in sysfs"
> - depends on SYSFS
> + depends on SYSFS && ACPI
> default n
> help
> Say Y or M here to enable the exporting of the QEMU firmware
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> index 3a67a16..f935afb 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -8,6 +8,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -35,53 +36,10 @@ struct fw_cfg_file {
> char name[FW_CFG_MAX_FILE_PATH];
> };
>
> -/* fw_cfg device i/o access options type */
> -struct fw_cfg_access {
> - const char *name;
> - phys_addr_t base;
> - u8 size;
> - u8 ctrl_offset;
> - u8 data_offset;
> - bool is_mmio;
> -};
> -
> -/* table of fw_cfg device i/o access options for known architectures */
> -static struct fw_cfg_access fw_cfg_modes[] = {
> - {
> - .name = "fw_cfg IOport on i386, sun4u",
> - .base = 0x510,
> - .size = 0x02,
> - .ctrl_offset = 0x00,
> - .data_offset = 0x01,
> - .is_mmio = false,
> - }, {
> - .name = "fw_cfg MMIO on arm",
> - .base = 0x902,
> - .size = 0x0a,
> - .ctrl_offset = 0x08,
> - .data_offset = 0x00,
> - .is_mmio = true,
> - }, {
> - .name = "fw_cfg MMIO on sun4m",
> - .base = 0xd0510,
> - .size = 0x03,
> - .ctrl_offset = 0x00,
> - .data_offset = 0x02,
> - .is_mmio = true,
> - }, {
> - .name = "fw_cfg MMIO on ppc/mac",
> - .base = 0xf510,
> - .size = 0x03,
> - .ctrl_offset = 0x00,
> - .data_offset = 0x02,
> - .is_mmio = true,
> - }, { } /* END */
> -};
> -
> -/* fw_cfg device i/o currently selected option set */
> -static struct fw_cfg_access *fw_cfg_mode;
> -
> /* fw_cfg device i/o register addresses */
> +static bool fw_cfg_is_mmio;
> +static phys_addr_t fw_cfg_phys_base;
> +static u32 fw_cfg_phys_size;
> static void __iomem *fw_cfg_dev_base;
> static void __iomem *fw_cfg_reg_ctrl;
> static void __iomem *fw_cfg_reg_data;
> @@ -92,7 +50,7 @@ static DEFINE_MUTEX(fw_cfg_dev_lock);
> /* pick appropriate endianness for selector key */
> static inline u16 fw_cfg_sel_endianness(u16 key)
> {
> - return fw_cfg_mode->is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
> + return fw_cfg_is_mmio ? cpu_to_be16(key)
Re: RFC: reduce CONFIG_SCSI_CONSTANTS impact by 4k
On Sun, Oct 04, 2015 at 12:09:58AM +0200, Rasmus Villemoes wrote: > On Sat, Oct 03 2015, Christoph Hellwig wrote: > > > Hi Rasmus, > > > > I like this idea. But maybe it's also time to just move the constants > > to a plain text file and auto-generate C headers from them? That way > > the format in which they can be edited is decoupled from the > > representation in the kernel image. > > Well, I don't really have an opinion on that part. > > In the meantime, I got another idea for doubling the saving to 8k. It > requires a few more code changes and is perhaps also more hacky. 2/2 > would be something like below. Please let me know which version you'd > prefer, and I'll send both patches properly. I don't think the new version is too bad, and the saving is impressive. So I'd opt for the new one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
nfs race condition
Hello,
I'm doing some " crontab -e, exit with :x" on NFS mount point,
and there is a race condition whent removing temporary files :
7701 write(2, "No modification made\n", 21) = 21
7701 open("/tmp/crontab.vYPoHR", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
7701 getdents(4, {{d_ino=73336409, d_off=1, d_reclen=24, d_name="."}
{d_ino=73335455, d_off=2, d_reclen=24, d_name=".."} {d_ino=73340547, d_off=3,
d_reclen=32, d_name="crontab"}}, 32768) = 80
7701 unlink("/tmp/crontab.vYPoHR/crontab") = 0
7701 getdents(4, {}, 32768) = 0
7701 close(4) = 0
7701 rmdir("/tmp/crontab.vYPoHR") = -1 ENOTEMPTY (Directory not empty)
7701 write(2, "/tmp/crontab.vYPoHR: Directory n"..., 41) = 41
7701 socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
The unlink is really done after the rmdir,
nfsv4 & nfsv3 over ipv6, so the rmdir fails and the directory isn't removed.
I have same problem with mysql temporary files.
If I mount with "nocto,noac,lookupcache=none" : same problem
kernel version on server : 3.16.0-4-amd64 (debian8)
kernel version on client : 2.6.32-39-pve (proxmox), same thing with
3.13.0-63-generic (ubuntu)
Please answer me in CC, I'm not subscribed to the list.
Regards
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt-bindings: Document the STM32 HW RNG bindings
Hi Daniel, On 10/03/2015 10:35 PM, Daniel Thompson wrote: This adds documenttaion of device tree binds for the STM32 hardware s/documenttaion/documentation/ random number generator. Signed-off-by: Daniel Thompson --- .../devicetree/bindings/hwrng/stm32-rng.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwrng/stm32-rng.txt Except the typo, the patch looks good to me. When fixed, you can add my: Acked-by: Maxime Coquelin Thanks! Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/11] staging: dgnc: remove multiple blank lines
On Sat, Oct 03, 2015 at 08:52:40PM +0530, Sudip Mukherjee wrote: > checkpatch warns us about multiple blank lines which are not needed. > Remove them. > > Signed-off-by: Sudip Mukherjee > --- > drivers/staging/dgnc/dgnc_driver.c | 10 > drivers/staging/dgnc/dgnc_mgmt.c | 5 > drivers/staging/dgnc/dgnc_neo.c| 37 --- > drivers/staging/dgnc/dgnc_sysfs.c | 37 --- > drivers/staging/dgnc/dgnc_tty.c| 51 > -- > 5 files changed, 140 deletions(-) Due to other patches sent before your series, this, and some of the other patches in this series does not apply. Please rebase and resend the remaining patches. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/7] perf tools: Add 'perf-config' command
So far, it is difficult that the state of perf configs is looked through and there's no knowing what kind of other variables except variables in perfconfig.example. Also perf configs can't be changed without manually modifying $HOME/.perfconfig or $(sysconfdir)/perfconfig file. So I suggest this patchset of the perf-config command which can list, get, set, remove perf configs or list with default config values as below. Taeung Song (7): [PATCH v7 1/7] perf tools: Add 'perf-config' command [PATCH v7 2/7] perf config: Add '--system' and '--user' options to select which config file is used [PATCH v7 3/7] perf config: Add a option 'list-all' to perf-config [PATCH v7 4/7] perf config: Add 'get' functionality [PATCH v7 5/7] perf config: Add 'set' feature [PATCH v7 6/7] perf config: normalize a value depending on default type of it [PATCH v7 7/7] perf config: Add a option 'remove' to perf-config Changes in v7: - Modify explanations of syntax and options(color, gtk, tui, buildid, annotate) to be better proper descriptions as suggested by Arnaldo (PATCH v7 1/7) Changes in v6: - Split a 'set' feature patch into two patch to separate normalize_value() from it. (PATCH v6 5/7, PATCH v6 6/7) - Bug fix : 'remove' and 'set' malfunctions when without a specific file-option. (If file-option isn't used, 'remove' feature had to use both user and system config file and 'set' feature had to only handle user config file.) (PATCH v6 5/7, PATCH v6 7/7) Changes in v5: - Simplify the switch statement in cmd_config() - Set a config file path with '--system' or '--user' instead of '--global' or '--system' as suggested by Namhyung. (PATCH v5 2/6) - The patch about 'get' and 'set 'split into two patchs as suggested by Namhyung. (PATCH v5 4/6, PATCH v5 5/6) Changes in v4: - If some config value is default value, notice it is '(default)' as suggested by Jirka. (PATCH v4 3/5) - If there wasn't any perfconfig file, perf-config malfunctioned like Jirka pointed out. So add exception routine with '--global' and '--system' option which can select perf config file path. (PATCH v4 2/5) Changes in v3: - Add a config variable 'kmem.default' with a default value as suggested by Namhyung. (PATCH v3 2/5, PATCH v4 3/5) Changes in v2: - Change option name of listing all configs as '--list-all' instead of '--all' as suggested by Namhyung. (PATCH v2 3/4, PATCH v4 4/5) - Correct small infelicities or typing errors in a perf-config documention as suggested by Arnaldo. (PATCH v2 1/4, PATCH v4 1/5) - Declaration a global variable 'static struct default_configsets' has config variables with default values instead of using a 'util/PERFCONFIG-DEFAULT' file. (PATCH v2 3/4, PATCH v4 3/5) - Add a function to normalize a value and check data type of it. (PATCH v2 2/4, PATCH v4 3/5) - Simplify parsing arguments as arguments is just divided by '=' and then in front of '.' is a section, between '.' and '=' is a name, and behind '=' is a value. (PATCH v2 2/4, PATCH v4 3/5) - If run perf-config command without any option, perf-config work as '--list'. (PATCH v2 1/4, PATCH v4 1/5) tools/perf/Build | 1 + tools/perf/Documentation/perf-config.txt | 422 + tools/perf/builtin-config.c | 769 +++ tools/perf/builtin.h | 1 + tools/perf/command-list.txt | 1 + tools/perf/perf.c| 1 + tools/perf/util/cache.h | 18 + tools/perf/util/config.c | 31 +- 8 files changed, 1242 insertions(+), 2 deletions(-) create mode 100644 tools/perf/Documentation/perf-config.txt create mode 100644 tools/perf/builtin-config.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 7/7] perf config: Add a option 'remove' to perf-config
A option 'remove' is to remove specific config variables.
For the syntax examples,
# perf config [] -r | --remove [section.name ...]
Signed-off-by: Taeung Song
---
tools/perf/Documentation/perf-config.txt | 6 +
tools/perf/builtin-config.c | 38 ++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-config.txt
b/tools/perf/Documentation/perf-config.txt
index f24926e..281e759 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -13,6 +13,8 @@ or
'perf config' [] -l | --list
or
'perf config' [] -a | --list-all
+or
+'perf config' [] -r | --remove [section.name ...]
DESCRIPTION
---
@@ -37,6 +39,10 @@ OPTIONS
--list-all::
Show current and all possible config variables with default values.
+-r::
+--remove::
+ Remove specific config variables.
+
CONFIGURATION FILE
--
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 680a655..9253eae 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -22,7 +22,8 @@ static const char * const config_usage[] = {
enum actions {
ACTION_LIST = 1,
- ACTION_LIST_ALL
+ ACTION_LIST_ALL,
+ ACTION_REMOVE
} actions;
static struct option config_options[] = {
@@ -35,6 +36,8 @@ static struct option config_options[] = {
OPT_SET_UINT('a', "list-all", &actions,
"show current and all possible config variables with
default values",
ACTION_LIST_ALL),
+ OPT_SET_UINT('r', "remove", &actions,
+"remove specific variables: [section.name ...]",
ACTION_REMOVE),
OPT_END()
};
@@ -532,7 +535,14 @@ static int set_config(struct list_head *sections, const
char *config_file_name,
struct config_element *element = NULL;
find_config(sections, §ion, &element, section_name, name);
- if (value != NULL) {
+ if (!value) {
+ /* value == NULL means remove the variable */
+ if (section && element) {
+ if (!element->value)
+ free(element->value);
+ element->value = NULL;
+ }
+ } else {
value = normalize_value(section_name, name, value);
/* if there isn't existent section, add a new section */
@@ -659,6 +669,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix __maybe_unused)
set_option_flag(config_options, 'l', "list", PARSE_OPT_EXCLUSIVE);
set_option_flag(config_options, 'a', "list-all", PARSE_OPT_EXCLUSIVE);
+ set_option_flag(config_options, 'r', "remove", PARSE_OPT_EXCLUSIVE);
argc = parse_options(argc, argv, config_options, config_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
@@ -690,6 +701,29 @@ int cmd_config(int argc, const char **argv, const char
*prefix __maybe_unused)
}
switch (actions) {
+ case ACTION_REMOVE:
+ if (argc) {
+ for (i = 0; argv[i]; i++) {
+ if (!use_system_config && !use_user_config) {
+ ret =
perf_configset_with_option(set_config,
+
&system_sections,
+
system_config,
+
argv[i], NULL);
+ ret =
perf_configset_with_option(set_config,
+
&user_sections,
+
user_config,
+
argv[i], NULL);
+ } else
+ ret =
perf_configset_with_option(set_config, sections,
+
config_file_name,
+
argv[i], NULL);
+ }
+ } else {
+ pr_err("Error: Missing arguments\n");
+ parse_options_usage(config_usage, config_options, "r",
1);
+ return -1;
+ }
+ break;
case ACTION_LIST_ALL:
if (argc == 0) {
ret = show_all_config(sections);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 6/7] perf config: normalize a value depending on default type of it
Whether or not user mis-type wrong data type to set config,
normalize the value. If a config user enter isn't contained
in default configs, just pass as it is.
For the examples,
# perf config report.queue-size=1M
# perf config report.queue-size
report.queue-size=1048576
Signed-off-by: Taeung Song
---
tools/perf/builtin-config.c | 48 -
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index f034c19..680a655 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -483,6 +483,48 @@ static int show_spec_config(struct list_head *sections,
return -1;
}
+static char *normalize_value(const char *section_name, const char *name, const
char *value)
+{
+ int i, ret = 0;
+ char key[BUFSIZ];
+ char *normalized;
+
+ scnprintf(key, sizeof(key), "%s.%s", section_name, name);
+ for (i = 0; default_configsets[i].section_name != NULL; i++) {
+ struct default_configset *config = &default_configsets[i];
+
+ if (!strcmp(config->section_name, section_name)
+ && !strcmp(config->name, name)) {
+ if (!config->type)
+ ret = asprintf(&normalized, "%s", value);
+ else if (!strcmp(config->type, TYPE_BOOL))
+ ret = asprintf(&normalized, "%s",
+ perf_config_bool(key, value) ?
"true" : "false");
+ else if (!strcmp(config->type, TYPE_INT))
+ ret = asprintf(&normalized, "%d",
+ perf_config_int(key, value));
+ else if (!strcmp(config->type, TYPE_LONG))
+ ret = asprintf(&normalized, "%"PRId64,
+ perf_config_u64(key, value));
+ else if (!strcmp(config->type, TYPE_DIRNAME))
+ ret = asprintf(&normalized, "%s",
+ perf_config_dirname(key, value));
+ if (ret < 0)
+ return NULL;
+
+ return normalized;
+ }
+ }
+
+ normalized = strdup(value);
+ if (!normalized) {
+ pr_err("%s: strdup failed\n", __func__);
+ return NULL;
+ }
+
+ return normalized;
+}
+
static int set_config(struct list_head *sections, const char *config_file_name,
const char *section_name, const char *name, char *value)
{
@@ -491,11 +533,7 @@ static int set_config(struct list_head *sections, const
char *config_file_name,
find_config(sections, §ion, &element, section_name, name);
if (value != NULL) {
- value = strdup(value);
- if (!value) {
- pr_err("%s: strdup failed\n", __func__);
- return -1;
- }
+ value = normalize_value(section_name, name, value);
/* if there isn't existent section, add a new section */
if (!section) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/7] perf tools: Add 'perf-config' command
The perf configuration file contains many variables which can make the perf command's action more effective. But looking through state of configuration is difficult and there's no knowing what kind of other variables except variables in perfconfig.example exist. So This patch adds 'perf-config' command with '--list' option and a document for it. perf config [options] display current perf config variables. # perf config or # perf config -l | --list Signed-off-by: Taeung Song --- tools/perf/Build | 1 + tools/perf/Documentation/perf-config.txt | 396 +++ tools/perf/builtin-config.c | 62 + tools/perf/builtin.h | 1 + tools/perf/command-list.txt | 1 + tools/perf/perf.c| 1 + 6 files changed, 462 insertions(+) create mode 100644 tools/perf/Documentation/perf-config.txt create mode 100644 tools/perf/builtin-config.c diff --git a/tools/perf/Build b/tools/perf/Build index 7223745..2c7aaf2 100644 --- a/tools/perf/Build +++ b/tools/perf/Build @@ -1,5 +1,6 @@ perf-y += builtin-bench.o perf-y += builtin-annotate.o +perf-y += builtin-config.o perf-y += builtin-diff.o perf-y += builtin-evlist.o perf-y += builtin-help.o diff --git a/tools/perf/Documentation/perf-config.txt b/tools/perf/Documentation/perf-config.txt new file mode 100644 index 000..e8013b3 --- /dev/null +++ b/tools/perf/Documentation/perf-config.txt @@ -0,0 +1,396 @@ +perf-config(1) +== + +NAME + +perf-config - Get and set variables in a configuration file. + +SYNOPSIS + +[verse] +'perf config' -l | --list + +DESCRIPTION +--- +You can manage variables in a configuration file with this command. + +OPTIONS +--- + +-l:: +--list:: + Show current config variables, name and value, for all sections. + +CONFIGURATION FILE +-- + +The Perf configuration file contains many variables which can make +the perf command's action more effective. +The '$HOME/.perfconfig' file is used to store a per-user configuration. +The file '$(sysconfdir)/perfconfig' can be used to +store a system-wide default configuration. + +The variables are divided into sections. In each section, the variables +that are composed of a name and value. + +Syntax +~~ + +The file consist of sections. A section starts with its name +surrounded by square brackets and continues till the next section +begins. Each variable belong to a section, which means that +there must be a section header before the first variable, as below: +Each variable are in the form 'name = value'. + + [section] + name1 = value1 + name2 = value2 + +Section names are case sensitive and can contain any characters except +newline (double quote `"` and backslash have to be escaped as `\"` and `\\`, +respectively). Section headers can't span multiple lines. + +Example +~~~ + +Given a $HOME/.perfconfig like this: + +# +# This is the config file, and +# a '#' and ';' character indicates a comment +# + +[colors] + # Color variables + top = red, default + medium = green, default + normal = lightgray, default + selected = white, lightgray + code = blue, default + addr = magenta, default + root = white, blue + +[tui] + # Defaults if linked with libslang + report = on + annotate = on + top = on + +[buildid] + # Default, disable using /dev/null + dir = ~/.debug + +[annotate] + # Defaults + hide_src_code = false + use_offset = true + jump_arrows = true + show_nr_jumps = false + +[help] + # Format can be man, info, web or html + format = man + autocorrect = 0 + +[ui] + show-headers= true + +[call-graph] + # fp (framepointer), dwarf + record-mode = fp + print-type = graph + order = caller + sort-key = function + +Variables +~ + +colors.*:: + Color variables can customize colors of the output which is printed out + from ‘report’, ‘top’, ’annotate’ on tui. + Color variables are composed of foreground and background + and should have two values, comma separated as below. + + medium = green, lightgray + + If you want to keep the background or the foregroud color set for your + terminal, replace the desired value with 'default'. For instance: + + medium = default, default + + Available colors: + red, green, default, black, blue, white, magenta, lightgray + + colors.top:: + ‘top’ means a overhead percentage which is more than 5%. + And values of this variable specify colors of percentage. + Basic key values are foreground-color ’red’ and + background-color ’default’. + colors.medium:: + ‘medium’ means a overhead percentage which has more than 0.5%. +
[PATCH v7 2/7] perf config: Add '--system' and '--user' options to select which config file is used
Which config file is used is decided in only perf_config().
And a perf-config command depend on perf_config() to list
config variables with values. So add '--system' and '--user'
options to select which config file to be used without perf_config().
The file-options '--system' means $(sysconfdir)/perfconfig and
'--user' means $HOME/.perfconfig. If file-option isn't used,
both system and user config file is read
but user config have priority. The syntax examples are like below
perf config [] [options]
a specific config file.
# perf config --user | --system
or
both user and system config file.
# perf config
In addition, use List data structure which has config info.
Because perf_config() isn't used any more and directly collect
config info by perf_config_from_file() with a specific config
file path. Whichever config file or both are used, list is required
to keep and handle config variables and values.
Signed-off-by: Taeung Song
---
tools/perf/Documentation/perf-config.txt | 14 ++-
tools/perf/builtin-config.c | 163 +--
tools/perf/util/cache.h | 15 +++
tools/perf/util/config.c | 4 +-
4 files changed, 187 insertions(+), 9 deletions(-)
diff --git a/tools/perf/Documentation/perf-config.txt
b/tools/perf/Documentation/perf-config.txt
index e8013b3..a42d409 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -8,7 +8,7 @@ perf-config - Get and set variables in a configuration file.
SYNOPSIS
[verse]
-'perf config' -l | --list
+'perf config' [] -l | --list
DESCRIPTION
---
@@ -21,6 +21,14 @@ OPTIONS
--list::
Show current config variables, name and value, for all sections.
+--user::
+ For writing and reading options: write to user
+ '$HOME/.perfconfig' file or read it.
+
+--system::
+ For writing and reading options: write to system-wide
+ '$(sysconfdir)/perfconfig' or read it.
+
CONFIGURATION FILE
--
@@ -33,6 +41,10 @@ store a system-wide default configuration.
The variables are divided into sections. In each section, the variables
that are composed of a name and value.
+When reading or writing, the values are read from the system and user
+configuration files by default, and options '--system' and '--user'
+can be used to tell the command to read from or write to only that location.
+
Syntax
~~
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 30b1500..92be3eb 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -13,8 +13,10 @@
#include "util/util.h"
#include "util/debug.h"
+static bool use_system_config, use_user_config;
+
static const char * const config_usage[] = {
- "perf config [options]",
+ "perf config [] [options]",
NULL
};
@@ -23,19 +25,150 @@ enum actions {
} actions;
static struct option config_options[] = {
+ OPT_GROUP("Config file location"),
+ OPT_BOOLEAN(0, "system", &use_system_config, "use system config file"),
+ OPT_BOOLEAN(0, "user", &use_user_config, "use user config file"),
OPT_GROUP("Action"),
OPT_SET_UINT('l', "list", &actions,
"show current config variables", ACTION_LIST),
OPT_END()
};
+static int show_config(struct list_head *sections)
+{
+ struct config_section *section;
+ struct config_element *element;
+
+ list_for_each_entry(section, sections, list) {
+ list_for_each_entry(element, §ion->element_head, list) {
+ printf("%s.%s=%s\n", section->name,
+ element->name, element->value);
+ }
+ }
+
+ return 0;
+}
-static int show_config(const char *key, const char *value,
- void *cb __maybe_unused)
+static struct config_section *find_section(struct list_head *sections,
+ const char *section_name)
{
+ struct config_section *section;
+
+ list_for_each_entry(section, sections, list)
+ if (!strcmp(section->name, section_name))
+ return section;
+
+ return NULL;
+}
+
+static struct config_element *find_element(const char *name,
+ struct config_section *section)
+{
+ struct config_element *element;
+
+ list_for_each_entry(element, §ion->element_head, list)
+ if (!strcmp(element->name, name))
+ return element;
+
+ return NULL;
+}
+
+static void find_config(struct list_head *sections,
+ struct config_section **section,
+ struct config_element **element,
+ const char *section_name, const char *name)
+{
+ *section = find_section(sections, section_name);
+
+ if (*section != NULL)
+ *element = find
[PATCH v7 4/7] perf config: Add 'get' functionality
This patch consists of functions
which can get specific config variables.
For the syntax examples,
perf config [] [section.name ...]
display key-value pairs of specific config variables
# perf config report.queue-size report.children
Signed-off-by: Taeung Song
---
tools/perf/Documentation/perf-config.txt | 2 +
tools/perf/builtin-config.c | 75 ++--
tools/perf/util/cache.h | 1 +
3 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-config.txt
b/tools/perf/Documentation/perf-config.txt
index 15fbbd9..7b83406 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -8,6 +8,8 @@ perf-config - Get and set variables in a configuration file.
SYNOPSIS
[verse]
+'perf config' [] [section.name ...]
+or
'perf config' [] -l | --list
or
'perf config' [] -a | --list-all
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 8e16e18..731056c 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -16,7 +16,7 @@
static bool use_system_config, use_user_config;
static const char * const config_usage[] = {
- "perf config [] [options]",
+ "perf config [] [options] [section.name ...]",
NULL
};
@@ -452,6 +452,35 @@ static int show_all_config(struct list_head *sections)
return 0;
}
+static int show_spec_config(struct list_head *sections,
+ const char *section_name, const char *name)
+{
+ int i;
+ struct config_section *section = NULL;
+ struct config_element *element = NULL;
+
+ find_config(sections, §ion, &element, section_name, name);
+
+ if (section && element) {
+ printf("%s.%s=%s\n", section->name,
+ element->name, element->value);
+ return 0;
+ }
+
+ for (i = 0; default_configsets[i].section_name != NULL; i++) {
+ struct default_configset *config = &default_configsets[i];
+
+ if (!strcmp(config->section_name, section_name) &&
+ !strcmp(config->name, name)) {
+ printf("%s.%s=%s (default)\n", config->section_name,
+ config->name, config->value);
+ return 0;
+ }
+ }
+
+ return -1;
+}
+
static int collect_current_config(const char *var, const char *value,
void *spec_sections __maybe_unused)
{
@@ -497,9 +526,42 @@ static int collect_current_config(const char *var, const
char *value,
return 0;
}
+static int perf_configset_with_option(configset_fn_t fn, struct list_head
*sections,
+ const char *var)
+{
+ char *section_name;
+ char *name;
+ const char *last_dot;
+ char *key = strdup(var);
+
+ if (!key) {
+ pr_err("%s: strdup failed\n", __func__);
+ return -1;
+ }
+ last_dot = strchr(key, '.');
+ /*
+* Since "key" actually contains the section name and the real
+* key name separated by a dot, we have to know where the dot is.
+*/
+ if (last_dot == NULL || last_dot == key) {
+ pr_err("The config variable does not contain a section: %s\n",
key);
+ return -1;
+ }
+ if (!last_dot[1]) {
+ pr_err("The config varible does not contain variable name:
%s\n", key);
+ return -1;
+ }
+
+ section_name = strsep(&key, ".");
+ name = strsep(&key, ".");
+ free(key);
+
+ return fn(sections, section_name, name);
+}
+
int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
{
- int ret = 0;
+ int i, ret = 0;
struct list_head sections;
const char *system_config = perf_etc_perfconfig();
char *user_config = mkpath("%s/.perfconfig", getenv("HOME"));
@@ -532,7 +594,6 @@ int cmd_config(int argc, const char **argv, const char
*prefix __maybe_unused)
break;
}
case ACTION_LIST:
- default:
if (argc) {
pr_err("Error: takes no arguments\n");
if (actions == ACTION_LIST_ALL)
@@ -540,7 +601,13 @@ int cmd_config(int argc, const char **argv, const char
*prefix __maybe_unused)
else
parse_options_usage(config_usage,
config_options, "l", 1);
return -1;
- } else
+ }
+ default:
+ if (argc)
+ for (i = 0; argv[i]; i++)
+ ret =
perf_configset_with_option(show_spec_config, §ions,
+argv[i]);
+ else
ret = show_config(§ions);
[PATCH v7 5/7] perf config: Add 'set' feature
This patch consists of functions
which can set specific config variables.
For the syntax examples,
perf config [] [options] [section.name[=value] ...]
set specific config variables
# perf config report.queue-size=100M report.children=true
Signed-off-by: Taeung Song
---
tools/perf/Documentation/perf-config.txt | 2 +-
tools/perf/builtin-config.c | 122 ++-
tools/perf/util/cache.h | 4 +-
tools/perf/util/config.c | 27 +++
4 files changed, 133 insertions(+), 22 deletions(-)
diff --git a/tools/perf/Documentation/perf-config.txt
b/tools/perf/Documentation/perf-config.txt
index 7b83406..f24926e 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -8,7 +8,7 @@ perf-config - Get and set variables in a configuration file.
SYNOPSIS
[verse]
-'perf config' [] [section.name ...]
+'perf config' [] [section.name[=value] ...]
or
'perf config' [] -l | --list
or
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 731056c..f034c19 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -16,7 +16,7 @@
static bool use_system_config, use_user_config;
static const char * const config_usage[] = {
- "perf config [] [options] [section.name ...]",
+ "perf config [] [options] [section.name[=value] ...]",
NULL
};
@@ -453,7 +453,9 @@ static int show_all_config(struct list_head *sections)
}
static int show_spec_config(struct list_head *sections,
- const char *section_name, const char *name)
+ const char *config_file_name __maybe_unused,
+ const char *section_name, const char *name,
+ char *value __maybe_unused)
{
int i;
struct config_section *section = NULL;
@@ -481,6 +483,39 @@ static int show_spec_config(struct list_head *sections,
return -1;
}
+static int set_config(struct list_head *sections, const char *config_file_name,
+ const char *section_name, const char *name, char *value)
+{
+ struct config_section *section = NULL;
+ struct config_element *element = NULL;
+
+ find_config(sections, §ion, &element, section_name, name);
+ if (value != NULL) {
+ value = strdup(value);
+ if (!value) {
+ pr_err("%s: strdup failed\n", __func__);
+ return -1;
+ }
+
+ /* if there isn't existent section, add a new section */
+ if (!section) {
+ section = init_section(section_name);
+ if (!section)
+ return -1;
+ list_add_tail(§ion->list, sections);
+ }
+ /* if nothing to replace, add a new element which contains
key-value pair. */
+ if (!element) {
+ add_element(§ion->element_head, name, value);
+ } else {
+ free(element->value);
+ element->value = value;
+ }
+ }
+
+ return perf_configset_write_in_full(sections, config_file_name);
+}
+
static int collect_current_config(const char *var, const char *value,
void *spec_sections __maybe_unused)
{
@@ -526,8 +561,10 @@ static int collect_current_config(const char *var, const
char *value,
return 0;
}
-static int perf_configset_with_option(configset_fn_t fn, struct list_head
*sections,
- const char *var)
+static int perf_configset_with_option(configset_fn_t fn,
+ struct list_head *sections,
+ const char *config_file_name,
+ const char *var, char *value)
{
char *section_name;
char *name;
@@ -554,15 +591,31 @@ static int perf_configset_with_option(configset_fn_t fn,
struct list_head *secti
section_name = strsep(&key, ".");
name = strsep(&key, ".");
+ if (!value) {
+ /* do nothing */
+ } else if (!strcmp(value, "=")) {
+ pr_err("The config variable does not contain a value: %s.%s\n",
+ section_name, name);
+ return -1;
+ } else {
+ value++;
+ name = strsep(&name, "=");
+ if (name[0] == '\0') {
+ pr_err("invalid key: %s\n", var);
+ return -1;
+ }
+ }
free(key);
- return fn(sections, section_name, name);
+ return fn(sections, config_file_name, section_name, name, value);
}
int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
{
int i, ret = 0;
- struct list_head sections;
+
[PATCH v7 3/7] perf config: Add a option 'list-all' to perf-config
A option 'list-all' is to display both current config variables and
all possible config variables with default values.
The syntax examples are like below
perf config [] [options]
display all perf config with default values.
# perf config -a | --list-all
Signed-off-by: Taeung Song
---
tools/perf/Documentation/perf-config.txt | 6 +
tools/perf/builtin-config.c | 339 ++-
2 files changed, 343 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-config.txt
b/tools/perf/Documentation/perf-config.txt
index a42d409..15fbbd9 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -9,6 +9,8 @@ SYNOPSIS
[verse]
'perf config' [] -l | --list
+or
+'perf config' [] -a | --list-all
DESCRIPTION
---
@@ -29,6 +31,10 @@ OPTIONS
For writing and reading options: write to system-wide
'$(sysconfdir)/perfconfig' or read it.
+-a::
+--list-all::
+ Show current and all possible config variables with default values.
+
CONFIGURATION FILE
--
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 92be3eb..8e16e18 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -21,7 +21,8 @@ static const char * const config_usage[] = {
};
enum actions {
- ACTION_LIST = 1
+ ACTION_LIST = 1,
+ ACTION_LIST_ALL
} actions;
static struct option config_options[] = {
@@ -31,8 +32,292 @@ static struct option config_options[] = {
OPT_GROUP("Action"),
OPT_SET_UINT('l', "list", &actions,
"show current config variables", ACTION_LIST),
+ OPT_SET_UINT('a', "list-all", &actions,
+"show current and all possible config variables with
default values",
+ACTION_LIST_ALL),
OPT_END()
};
+
+/* section names */
+#define COLORS "colors"
+#define TUI "tui"
+#define BUILDID "buildid"
+#define ANNOTATE "annotate"
+#define GTK "gtk"
+#define PAGER "pager"
+#define HELP "help"
+#define HIST "hist"
+#define UI "ui"
+#define CALL_GRAPH "call-graph"
+#define REPORT "report"
+#define TOP "top"
+#define MAN "man"
+#define KMEM "kmem"
+
+/* config variable types */
+#define TYPE_INT "int"
+#define TYPE_LONG "long"
+#define TYPE_DIRNAME "dirname"
+#define TYPE_BOOL "bool"
+
+static struct default_configset {
+ const char *section_name;
+ const char *name, *value, *type;
+
+} default_configsets[] = {
+ {
+ .section_name = COLORS,
+ .name = "top",
+ .value = "red, default",
+ .type = NULL,
+ },
+ {
+ .section_name = COLORS,
+ .name = "medium",
+ .value = "green, default",
+ .type = NULL,
+ },
+ {
+ .section_name = COLORS,
+ .name = "normal",
+ .value = "lightgray, default",
+ .type = NULL,
+ },
+ {
+ .section_name = COLORS,
+ .name = "selected",
+ .value = "white, lightgray",
+ .type = NULL,
+ },
+ {
+ .section_name = COLORS,
+ .name = "code",
+ .value = "blue, default",
+ .type = NULL,
+ },
+ {
+ .section_name = COLORS,
+ .name = "addr",
+ .value = "magenta, default",
+ .type = NULL,
+ },
+ {
+ .section_name = COLORS,
+ .name = "root",
+ .value = "white, blue",
+ .type = NULL,
+ },
+ {
+ .section_name = TUI,
+ .name = "report",
+ .value = "true",
+ .type = TYPE_BOOL,
+ },
+ {
+ .section_name = TUI,
+ .name = "annotate",
+ .value = "true",
+ .type = TYPE_BOOL,
+ },
+ {
+ .section_name = TUI,
+ .name = "top",
+ .value = "true",
+ .type = TYPE_BOOL,
+ },
+ {
+ .section_name = BUILDID,
+ .name = "dir",
+ .value = "~/.debug",
+ .type = TYPE_DIRNAME,
+ },
+ {
+ .section_name = ANNOTATE,
+ .name = "hide_src_code",
+ .value = "false",
+ .type = TYPE_BOOL,
+ },
+ {
+ .section_name = ANNOTATE,
+ .name = "use_offset",
+ .value = "true",
+ .type = TYPE_BOOL,
+ },
+ {
+ .section_name = ANNOTATE,
+ .name = "jump_arrows",
+ .value = "true",
+ .type = TYPE_BOOL,
+ },
+ {
+ .section_name = ANNOTATE,
+ .name = "show_nr_jumps",
+ .value = "false",
+
Re: [PATCH 1/2] drivers: staging: wilc1000: Move spin lock to the start of critical section
On Sat, Oct 03, 2015 at 02:57:29PM +0530, Chandra S Gorentla wrote: > The spin_lock_irqsave is moved to just beginning of critical section. > This change moves a couple of return statements out of the lock. > > Signed-off-by: Chandra S Gorentla > --- > drivers/staging/wilc1000/wilc_msgqueue.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c > b/drivers/staging/wilc1000/wilc_msgqueue.c > index d5ebd6d..284a3f5 100644 > --- a/drivers/staging/wilc1000/wilc_msgqueue.c > +++ b/drivers/staging/wilc1000/wilc_msgqueue.c > @@ -72,8 +72,6 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle, > goto ERRORHANDLER; > } > > - spin_lock_irqsave(&pHandle->strCriticalSection, flags); > - > /* construct a new message */ > pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC); As you have moved the lock, can you also change this to GFP_KERNEL as well because we do not have a lock held? And how have you tested that this is ok? What is this lock trying to protect? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers: staging: wilc1000: Call kfree only for error cases
On Sat, Oct 03, 2015 at 02:57:30PM +0530, Chandra S Gorentla wrote:
> - kfree is being called for the members of the queue without
>de-queuing them; they are just inserted within this function;
>they are supposed to be de-queued and freed in a function
>for receiving the queue items
> - goto statements are removed
> - After kfree correction, there is no need for target block
>of goto statement; hence it is removed
>
> Signed-off-by: Chandra S Gorentla
> ---
> drivers/staging/wilc1000/wilc_msgqueue.c | 22 ++
> 1 file changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c
> b/drivers/staging/wilc1000/wilc_msgqueue.c
> index 284a3f5..eae90be 100644
> --- a/drivers/staging/wilc1000/wilc_msgqueue.c
> +++ b/drivers/staging/wilc1000/wilc_msgqueue.c
> @@ -56,32 +56,30 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
> int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
>const void *pvSendBuffer, u32 u32SendBufferSize)
> {
> - int result = 0;
> unsigned long flags;
> Message *pstrMessage = NULL;
>
> if ((!pHandle) || (u32SendBufferSize == 0) || (!pvSendBuffer)) {
> PRINT_ER("pHandle or pvSendBuffer is null\n");
> - result = -EFAULT;
> - goto ERRORHANDLER;
> + return -EFAULT;
> }
>
> if (pHandle->bExiting) {
> PRINT_ER("pHandle fail\n");
> - result = -EFAULT;
> - goto ERRORHANDLER;
> + return -EFAULT;
> }
>
> /* construct a new message */
> pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);
> if (!pstrMessage)
> return -ENOMEM;
> +
> pstrMessage->u32Length = u32SendBufferSize;
> pstrMessage->pstrNext = NULL;
> pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC);
> if (!pstrMessage->pvBuffer) {
> - result = -ENOMEM;
> - goto ERRORHANDLER;
> + kfree(pstrMessage);
> + return -ENOMEM;
> }
> memcpy(pstrMessage->pvBuffer, pvSendBuffer, u32SendBufferSize);
>
> @@ -102,15 +100,7 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
> spin_unlock_irqrestore(&pHandle->strCriticalSection, flags);
>
> up(&pHandle->hSem);
> -
> -ERRORHANDLER:
> - /* error occured, free any allocations */
> - if (pstrMessage) {
> - kfree(pstrMessage->pvBuffer);
> - kfree(pstrMessage);
> - }
> -
> - return result;
> + return 0;
Aren't you now leaking memory as you aren't freeing pstrMessage and the
buffer on the "normal" return path?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mwifiex: fix a comment typo
Just fix a typo in the code comment. Signed-off-by: Geliang Tang --- drivers/net/wireless/mwifiex/cfg80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c index 30cbafb..b7ac45f 100644 --- a/drivers/net/wireless/mwifiex/cfg80211.c +++ b/drivers/net/wireless/mwifiex/cfg80211.c @@ -2374,7 +2374,7 @@ mwifiex_cfg80211_leave_ibss(struct wiphy *wiphy, struct net_device *dev) * CFG802.11 operation handler for scan request. * * This function issues a scan request to the firmware based upon - * the user specified scan configuration. On successfull completion, + * the user specified scan configuration. On successful completion, * it also informs the results. */ static int -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8723au: Fix Sparse errors in rtl8723a_cmd.c
On Fri, Oct 02, 2015 at 08:36:28PM -0400, Jacob Kiefer wrote:
> From: Jacob Kiefer
>
> This patch fixes the following sparse errors:
>
>
> CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> ...
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: warning: incorrect type
> in assignment (different base types)
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25:expected unsigned int
> [unsigned] [usertype]
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25:got restricted __le32
> [usertype]
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: warning: incorrect type
> in assignment (different base types)
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14:expected unsigned int
> [unsigned] [usertype] mask
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14:got restricted __le32
> [usertype]
> CC [M] drivers/staging/rtl8723au/hal/rtl8723a_cmd.o
>
> Signed-off-by: Jacob Kiefer
> ---
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> index 9733aa6..111a24d 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> @@ -115,9 +115,11 @@ exit:
>
> int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
> {
> - *((u32 *)param) = cpu_to_le32(*((u32 *)param));
> + __le32 leparam;
Why __le32? Does this variable go across the user/kernel boundry
somehow? If not, just use le32.
>
> - FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
> + leparam = cpu_to_le32(*((u32 *)param));
> +
> + FillH2CCmd(padapter, RSSI_SETTING_EID, 3, (u8 *)&leparam);
At first glance, you aren't doing ths same logic in this function as the
original did, please look at this very closely again and verify that you
are doing this correctly.
Don't just blindly quiet tools like sparse, it is warning for a reason,
but be careful about your fix.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Staging: rtl8192u: remove ieee80211_ccmp_null()
On Sat, Oct 03, 2015 at 01:09:56PM -0800, mike dupuis wrote: > This is a patch to remove the function ieee80211_ccmp_null(). > This function does nothing and can therefore be safely removed. > > Signed-off-by: Mike Dupuis > --- > drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > index 61edd57..af22ee5 100644 > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c > @@ -175,9 +175,6 @@ struct net_device *alloc_ieee80211(int sizeof_priv) > ieee->last_packet_time[i] = 0; > } > > -/* These function were added to load crypte module autoly */ > - ieee80211_ccmp_null(); > - You didn't remove the function, only the call to it. And I think you just broke the "autoload" logic that these "call a null function" function calls were trying to solve, which isn't good at all. Have you verified that everything correctly auto-loads when the device is plugged into the system? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] hwrng: stm32 - add support for STM32 HW RNG
Hi Daniel,
On 10/03/2015 10:35 PM, Daniel Thompson wrote:
Add support for STMicroelectronics STM32 random number generator.
The config value defaults to N, reflecting the fact that STM32 is a
very low resource microcontroller platform and unlikely to be targeted
by any "grown up" defconfigs.
Signed-off-by: Daniel Thompson
---
drivers/char/hw_random/Kconfig | 12 +++
drivers/char/hw_random/Makefile| 1 +
drivers/char/hw_random/stm32-rng.c | 192 +
3 files changed, 205 insertions(+)
create mode 100644 drivers/char/hw_random/stm32-rng.c
diff --git a/drivers/char/hw_random/stm32-rng.c
b/drivers/char/hw_random/stm32-rng.c
new file mode 100644
index ..37dfa5fca105
--- /dev/null
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -0,0 +1,192 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RNG_CR 0x00
+#define RNG_CR_RNGEN BIT(2)
+
+#define RNG_SR 0x04
+#define RNG_SR_SEIS BIT(6)
+#define RNG_SR_CEIS BIT(5)
+#define RNG_SR_DRDY BIT(0)
+
+#define RNG_DR 0x08
+
+/*
+ * It takes 40 cycles @ 48MHz to generate each random number (e.g. <1us).
+ * At the time of writing STM32 parts max out at ~200MHz meaning a timeout
+ * of 500 leaves us a very comfortable margin for error. The loop to which
+ * the timeout applies takes at least 4 instructions per cycle so the
+ * timeout is enough to take us up to multi-GHz parts!
+ */
+#define RNG_TIMEOUT 500
+
+struct stm32_rng_private {
+ struct hwrng rng;
+ void __iomem *base;
+ struct clk *clk;
+};
+
+static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
+{
+ struct stm32_rng_private *priv =
+ container_of(rng, struct stm32_rng_private, rng);
+ u32 cr, sr;
+ int retval = 0;
+
+ /* enable random number generation */
+ clk_enable(priv->clk);
+ cr = readl(priv->base + RNG_CR);
+ writel(cr | RNG_CR_RNGEN, priv->base + RNG_CR);
+
+ while (max > sizeof(u32)) {
+ sr = readl(priv->base + RNG_SR);
+ if (!sr && wait) {
+ unsigned int timeout = RNG_TIMEOUT;
+
+ do {
+ cpu_relax();
+ sr = readl(priv->base + RNG_SR);
+ } while (!sr && --timeout);
+ }
+
+ /* Has h/ware error dection been triggered? */
+ if (WARN_ON(sr & (RNG_SR_SEIS | RNG_SR_CEIS)))
Maybe you should instead use WARN_ONCE?
Because from what I understand in the datasheet, CEIS bit indicates and
error with clock configuration.
If that happens, it is likely the same error will occur each time this
function will be called.
+ break;
+
+ /* No data ready... */
+ if (!sr)
+ break;
Maybe you could perform this check before the error detection, as if
!sr, the HW error condition will be always false.
+
+ *(u32 *)data = readl(priv->base + RNG_DR);
+
+ retval += sizeof(u32);
+ data += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ /* disable the generator */
+ writel(cr, priv->base + RNG_CR);
+ clk_disable(priv->clk);
+
+ return retval || !wait ? retval : -EIO;
+}
Couldn't we use "_relaxed" versions of readl/writel?
I might save some not needed barriers.
+static int stm32_rng_probe(struct platform_device *ofdev)
+{
+ struct device *dev = &ofdev->dev;
+ struct device_node *np = ofdev->dev.of_node;
+ struct stm32_rng_private *priv;
+ struct resource res;
+ int err;
+
+ priv = devm_kzalloc(dev, sizeof(struct stm32_rng_private), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ err = of_address_to_resource(np, 0, &res);
+ if (err)
+ return err;
+
+ priv->base = devm_ioremap_resource(dev, &res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->clk = devm_clk_get(&ofdev->dev, NULL);
+ if (IS_ERR(priv->clk))
+ return PTR_ERR(priv->clk);
+
+ dev_set_drvdata(dev, priv);
+
+ priv->rng.name = dev_driver_string(dev),
+ priv->rng.init = stm32_rng_init,
+ priv->rng.cleanup = stm32_rng_cleanup,
+ priv->rng.read = stm32_rng_read,
+ priv->rng.priv = (unsigned long) dev;
+
+ err = hwrng_register(&priv->rng);
+ if (err)
+ return err;
+
+ return 0;
As detected with Coccinelle by Fengguang build system, you could simplify:
return hwrng_register(&priv->rng);
Regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isci: fix two comment typos
Just fix two typos in the code comment.
Signed-off-by: Geliang Tang
---
drivers/scsi/isci/request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index cfd0084..8fe106f 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
@@ -3306,7 +3306,7 @@ sci_io_request_construct_smp(struct device *dev,
* @ireq: This parameter points to the isci_request allocated in the
*request construct function.
*
- * SCI_SUCCESS on successfull completion, or specific failure code.
+ * SCI_SUCCESS on successful completion, or specific failure code.
*/
static enum sci_status isci_smp_request_build(struct isci_request *ireq)
{
@@ -3332,7 +3332,7 @@ static enum sci_status isci_smp_request_build(struct
isci_request *ireq)
* @sci_device: This parameter is the handle for the sci core's remote device
*object that is the destination for this request.
*
- * SCI_SUCCESS on successfull completion, or specific failure code.
+ * SCI_SUCCESS on successful completion, or specific failure code.
*/
static enum sci_status isci_io_request_build(struct isci_host *ihost,
struct isci_request *request,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] IB/iser: fix a comment typo
Just fix a typo in the code comment. Signed-off-by: Geliang Tang --- drivers/infiniband/ulp/iser/iscsi_iser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c b/drivers/infiniband/ulp/iser/iscsi_iser.c index f58ff96..8f2f105 100644 --- a/drivers/infiniband/ulp/iser/iscsi_iser.c +++ b/drivers/infiniband/ulp/iser/iscsi_iser.c @@ -111,7 +111,7 @@ module_param_named(pi_guard, iser_pi_guard, int, S_IRUGO); MODULE_PARM_DESC(pi_guard, "T10-PI guard_type [deprecated]"); /* - * iscsi_iser_recv() - Process a successfull recv completion + * iscsi_iser_recv() - Process a successful recv completion * @conn: iscsi connection * @hdr: iscsi header * @rx_data: buffer containing receive data payload -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: fix a comment typo
Just fix a typo in the code comment. Signed-off-by: Geliang Tang --- fs/btrfs/free-space-cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index abe3a66..7332995 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -1215,7 +1215,7 @@ out: * @offset - the offset for the key we'll insert * * This function writes out a free space cache struct to disk for quick recovery - * on mount. This will return 0 if it was successfull in writing the cache out, + * on mount. This will return 0 if it was successful in writing the cache out, * or an errno if it was not. */ static int __btrfs_write_out_cache(struct btrfs_root *root, struct inode *inode, -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rdma: Fix braces around if/else
On Sun, Oct 04, 2015 at 08:20:09AM +0100, Greg Kroah-Hartman wrote: On Sun, Oct 04, 2015 at 09:47:52AM +0300, Or Gerlitz wrote: On 10/3/2015 11:55 PM, Martin Kletzander wrote: >Get rid of all ELSE_AFTER_BRACE type errors reported by checkpatch.pl. Hi Greg, Is there a way to signal people/tools that a certain driver parks in staging on their way **out** of the kernel and not the other way around? I guess you (nor Doug) don't want to spend time on fixing such drivers, right? I'm not spending the time :) But no, there isn't a way to really show that that I know of, and it's fine, we end up getting a number of "cleanup" patches for a kernel release or two before the drivers get deleted. It gets people involved in kernel development which is the key thing here, it's not like they are actually using these drivers... So it's fine, I take the patches, the people writing the patches are happy, and the code gets a bit nicer and feels better about itself before we kick it out the door. I didn't mean to waste anyone's time on this. I'm just trying to get more familiar with the patch submission process into the kernel. And I'm doing this in my free time despite the address used. I probably should've noted that below to commit message. Martin signature.asc Description: PGP signature
Re: [PATCH 3/3] ARM: dts: stm32f429: Adopt STM32 RNG driver
Hi Daniel, On 10/03/2015 10:35 PM, Daniel Thompson wrote: New bindings and driver have been created for STM32 series parts. This patch integrates this changes. Signed-off-by: Daniel Thompson --- arch/arm/boot/dts/stm32f429.dtsi | 7 +++ 1 file changed, 7 insertions(+) Acked-by: Maxime Coquelin I will queue it to STM32 tree as soon as the DT bindings are accepted. Thanks, Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/3] usb: xhci-platform: Configure 64-bit DMA mask if the platform is capable
On Wed, Sep 30, 2015 at 02:24:30PM -0700, Duc Dang wrote: > On Thu, Sep 17, 2015 at 11:19 AM, Duc Dang wrote: > > The xhci platform driver does not work with system that only supports > > 64-bit DMA as it requests 32-bit DMA mask during driver initialization. > > This patch set addresses this issue and also adds XHCI-compliant USB > > Controller ACPI identification into xhci-platform driver. > > Hi Greg, Mathias, > > Arnd already ack-ed the first patch, please let me know if you have > more comment on this set? I'm waiting for Mathias to forward this on to me as he's the xhci maintainer. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers: staging: wilc1000: Call kfree only for error cases
On Sun, Oct 04, 2015 at 09:44:57AM +0100, Greg KH wrote: > Aren't you now leaking memory as you aren't freeing pstrMessage and the > buffer on the "normal" return path? It's supposed to. It's a bug fix. I explained to him in the first version that his changelog sucks. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Sun, Sep 27, 2015 at 03:48:24PM +0200, Rafael J. Wysocki wrote: > On Sun, Sep 27, 2015 at 12:04 AM, Viresh Kumar > wrote: > > global_lock is defined as an unsigned long and accessing only its lower > > 32 bits from sysfs is incorrect, as we need to consider other 32 bits > > for big endian 64-bit systems. There are no such platforms yet, but the > > code needs to be robust for such a case. > > > > Fix that by changing type of 'global_lock' to u32. > > > > Signed-off-by: Viresh Kumar > > Acked-by: Rafael J. Wysocki > > Greg, please take this one along with the [2/2] if that one looks good to you. Thanks, will do. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] dma: remove external references to dma_supported
On Sat, Oct 03, 2015 at 05:19:39PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > Documentation/DMA-API.txt | 13 - > drivers/usb/host/ehci-hcd.c | 2 +- > drivers/usb/host/fotg210-hcd.c | 2 +- > drivers/usb/host/fusbh200-hcd.c | 2 +- > drivers/usb/host/oxu210hp-hcd.c | 2 +- > 5 files changed, 4 insertions(+), 17 deletions(-) Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/14] RFC: usb/host/fotg210: replace msleep by usleep_range
On Fri, Oct 2, 2015 at 7:52 PM, Alan Stern wrote: > On Fri, 2 Oct 2015, Felipe Balbi wrote: > >> On Mon, Sep 21, 2015 at 05:01:10PM +0200, Peter Senna Tschudin wrote: >> > msleep under 20ms can result in sleeping up to 20ms, which may not be >> > intended. Replace msleep(5) by usleep_range(5000, 6000). >> > >> > Signed-off-by: Peter Senna Tschudin >> >> good catch. I'd apply this straight away. Alan ? > > It really doesn't matter. As long as the delay is at least 5 ms, it > can be arbitrarily long. This won't hurt, and if it prevents automated > tools from complaining then it's worthwhile. Then is it a good idea to increase the range to reduce chances of creating an interrupt? usleep_range(5000, 1)? > > Peter, a lot of the changes you have been making will also apply to the > ehci-hcd driver. Do you want to update it as well? One caution: The > style used for continuation lines is to add two extra tab stops, not to > align things with an open paren on the original line. The drivers with more checkpatch errors and warnings are: 117 586 drivers/usb/host/fusbh200-hcd.c 38 124 drivers/usb/host/ohci-q.c 38 122 drivers/usb/host/ehci-dbg.c 37 118 drivers/usb/host/ohci-dbg.c 36 129 drivers/usb/host/ehci-sched.c 24 136 drivers/usb/host/ohci-hcd.c 23 16 drivers/usb/host/sl811-hcd.c 20 105 drivers/usb/host/ohci-hub.c 18 48 drivers/usb/host/ehci-hub.c 17 70 drivers/usb/host/ehci-hcd.c 13 4 drivers/usb/host/uhci-debug.c 12 93 drivers/usb/host/ehci-q.c 9 83 drivers/usb/host/isp116x-hcd.c 9 32 drivers/usb/host/fotg210-hcd.c 7 29 drivers/usb/host/oxu210hp-hcd.c 6 4 drivers/usb/host/sl811_cs.c I'll fix ehci-hcd. Do you want patches for the others? I'll fix the alignment using two extra tabs instead of aligning with opening parenthesis. Thank you. -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mfd: add CSR SiRFSoC on-chip power management module driver
2015-09-29 16:55 GMT+08:00 Lee Jones :
> On Tue, 29 Sep 2015, Barry Song wrote:
>
>> 2015-09-29 15:16 GMT+08:00 Lee Jones :
>> > On Tue, 29 Sep 2015, Barry Song wrote:
>> >> >> >> +static int sirfsoc_pwrc_probe(struct platform_device *pdev)
>> >> >> >> +{
>> >> >> >> + struct device_node *np = pdev->dev.of_node;
>> >> >> >> + const struct of_device_id *match;
>> >> >> >> + struct sirfsoc_pwrc_info *pwrcinfo;
>> >> >> >> + struct regmap_irq_chip *regmap_irq_chip;
>> >> >> >> + struct sirfsoc_pwrc_register *pwrc_reg;
>> >> >> >> + struct regmap *map;
>> >> >> >> + int ret;
>> >> >> >> + u32 base;
>> >> >> >> +
>> >> >> >> + if (of_property_read_u32(np, "reg", &base))
>> >> >> >> + panic("unable to find base address of pwrc node in
>> >> >> >> dtb\n");
>> >> >> >
>> >> >> > It looks like this driver should depend on OF.
>> >> >> >
>> >> >> > Why are you obtaining the base address manually? Use:
>> >> >> >
>> >> >> > res = platform_get_resource();
>> >> >> > devm_ioremap_resource(res);
>> >> >> >
>> >> >> > ... instead.
>> >> >>
>> >> >> this was explained as they are not in memory space, they are behind a
>> >> >> bus bridge.
>> >> >
>> >> > Use 'ranges' in the DT, then you can pull out the proper address
>> >> > without hand rolling your own method.
>> >>
>> >> it seems it is not a "ranges" thing, things behind rtciobrg is much
>> >> like things behind USB or sdio. we need to use a rtciobrg protocol to
>> >> do read/write.
>> >> they can not be randomly accessed by load/store, and can't be XIP.
>> >> they don't have any ranges in CPU memory space.
>> >
>> > So what's the point of 'base' then? I assumed this was the base of
>> > the IP registers which where memory mapped?
>>
>> just think we have a i2c device, and this i2c device has multi-functions.
>> each function has a base of its register offset.
>> actually, the base is the offset of 1st register.
>
> Does it every change, from device to device?
yes. Lee. e.g:
rtc-iobg@1884 {
reg = <0x1884 0x1000>;
sysrtc@2000 {
compatible = "sirf,prima2-sysrtc";
reg = <0x2000 0x100>;
interrupts = <0 52 0>;
};
pwrc@3000 {
compatible = "sirf,atlas7-pwrc";
reg = <0x3000 0x100>;
interrupts = <0 32 0>;
};
}
-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: staging: wilc1000: Move spin lock to the start of critical section
On Sun, Oct 04, 2015 at 09:43:35AM +0100, Greg KH wrote: > On Sat, Oct 03, 2015 at 02:57:29PM +0530, Chandra S Gorentla wrote: > > The spin_lock_irqsave is moved to just beginning of critical section. > > This change moves a couple of return statements out of the lock. > > > > Signed-off-by: Chandra S Gorentla > > --- > > drivers/staging/wilc1000/wilc_msgqueue.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c > > b/drivers/staging/wilc1000/wilc_msgqueue.c > > index d5ebd6d..284a3f5 100644 > > --- a/drivers/staging/wilc1000/wilc_msgqueue.c > > +++ b/drivers/staging/wilc1000/wilc_msgqueue.c > > @@ -72,8 +72,6 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle, > > goto ERRORHANDLER; > > } > > > > - spin_lock_irqsave(&pHandle->strCriticalSection, flags); > > - > > /* construct a new message */ > > pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC); > > As you have moved the lock, can you also change this to GFP_KERNEL as > well because we do not have a lock held? Can 'the change to GFP_KERNEL' be done in a separate patch? The lock is to protect linked list manipulations; in this function items are added to the list. > > And how have you tested that this is ok? What is this lock trying to > protect? I load this module on a notebook computer. I added some code to wilc_debugfs.c to invoke the functions in the file wilc_msgqueue.c > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers: staging: wilc1000: Call kfree only for error cases
On Sun, Oct 04, 2015 at 12:16:31PM +0300, Dan Carpenter wrote: > On Sun, Oct 04, 2015 at 09:44:57AM +0100, Greg KH wrote: > > Aren't you now leaking memory as you aren't freeing pstrMessage and the > > buffer on the "normal" return path? > > It's supposed to. It's a bug fix. I explained to him in the first > version that his changelog sucks. Ok, well, it still sucks :) And it's out of my queue, so I'll wait for the next spin of this series... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rdma: Fix braces around if/else
On Sun, Oct 04, 2015 at 11:05:50AM +0200, Martin Kletzander wrote: > On Sun, Oct 04, 2015 at 08:20:09AM +0100, Greg Kroah-Hartman wrote: > >On Sun, Oct 04, 2015 at 09:47:52AM +0300, Or Gerlitz wrote: > >>On 10/3/2015 11:55 PM, Martin Kletzander wrote: > >>>Get rid of all ELSE_AFTER_BRACE type errors reported by checkpatch.pl. > >> > >>Hi Greg, > >> > >>Is there a way to signal people/tools that a certain driver parks in staging > >>on their way **out** of the kernel > >>and not the other way around? I guess you (nor Doug) don't want to spend > >>time on fixing such drivers, right? > > > >I'm not spending the time :) > > > >But no, there isn't a way to really show that that I know of, and it's > >fine, we end up getting a number of "cleanup" patches for a kernel > >release or two before the drivers get deleted. It gets people involved > >in kernel development which is the key thing here, it's not like they > >are actually using these drivers... > > > >So it's fine, I take the patches, the people writing the patches are > >happy, and the code gets a bit nicer and feels better about itself > >before we kick it out the door. > > > > I didn't mean to waste anyone's time on this. I'm just trying to get > more familiar with the patch submission process into the kernel. And > I'm doing this in my free time despite the address used. I probably > should've noted that below to commit message. No need to say _why_ you are sending kernel patches, I don't care :) And this is a great way to get familiar with the process, it's why there are so many things in the drivers/staging/ tree to fix up. If we really wanted to get the code "correct", I would just take a few days and fix it all up myself, but that's not the goal here. Keep it up, you are doing just fine. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drivers: staging: wilc1000: Move spin lock to the start of critical section
On Sun, Oct 04, 2015 at 03:37:13PM +0530, Chandra Gorentla wrote: > On Sun, Oct 04, 2015 at 09:43:35AM +0100, Greg KH wrote: > > On Sat, Oct 03, 2015 at 02:57:29PM +0530, Chandra S Gorentla wrote: > > > The spin_lock_irqsave is moved to just beginning of critical section. > > > This change moves a couple of return statements out of the lock. > > > > > > Signed-off-by: Chandra S Gorentla > > > --- > > > drivers/staging/wilc1000/wilc_msgqueue.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c > > > b/drivers/staging/wilc1000/wilc_msgqueue.c > > > index d5ebd6d..284a3f5 100644 > > > --- a/drivers/staging/wilc1000/wilc_msgqueue.c > > > +++ b/drivers/staging/wilc1000/wilc_msgqueue.c > > > @@ -72,8 +72,6 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle, > > > goto ERRORHANDLER; > > > } > > > > > > - spin_lock_irqsave(&pHandle->strCriticalSection, flags); > > > - > > > /* construct a new message */ > > > pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC); > > > > As you have moved the lock, can you also change this to GFP_KERNEL as > > well because we do not have a lock held? > Can 'the change to GFP_KERNEL' be done in a separate patch? Yes. > The lock is to protect linked list manipulations; in this function items > are added to the list. Ok, please add that description to the patch so we know what is going on, and that you know what is going on as well :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers: staging: wilc1000: Call kfree only for error cases
On Sun, Oct 04, 2015 at 09:44:57AM +0100, Greg KH wrote:
> On Sat, Oct 03, 2015 at 02:57:30PM +0530, Chandra S Gorentla wrote:
> > - kfree is being called for the members of the queue without
> >de-queuing them; they are just inserted within this function;
> >they are supposed to be de-queued and freed in a function
> >for receiving the queue items
> > - goto statements are removed
> > - After kfree correction, there is no need for target block
> >of goto statement; hence it is removed
> >
> > Signed-off-by: Chandra S Gorentla
> > ---
> > drivers/staging/wilc1000/wilc_msgqueue.c | 22 ++
> > 1 file changed, 6 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c
> > b/drivers/staging/wilc1000/wilc_msgqueue.c
> > index 284a3f5..eae90be 100644
> > --- a/drivers/staging/wilc1000/wilc_msgqueue.c
> > +++ b/drivers/staging/wilc1000/wilc_msgqueue.c
> > @@ -56,32 +56,30 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
> > int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
> > const void *pvSendBuffer, u32 u32SendBufferSize)
> > {
> > - int result = 0;
> > unsigned long flags;
> > Message *pstrMessage = NULL;
> >
> > if ((!pHandle) || (u32SendBufferSize == 0) || (!pvSendBuffer)) {
> > PRINT_ER("pHandle or pvSendBuffer is null\n");
> > - result = -EFAULT;
> > - goto ERRORHANDLER;
> > + return -EFAULT;
> > }
> >
> > if (pHandle->bExiting) {
> > PRINT_ER("pHandle fail\n");
> > - result = -EFAULT;
> > - goto ERRORHANDLER;
> > + return -EFAULT;
> > }
> >
> > /* construct a new message */
> > pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);
> > if (!pstrMessage)
> > return -ENOMEM;
> > +
> > pstrMessage->u32Length = u32SendBufferSize;
> > pstrMessage->pstrNext = NULL;
> > pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC);
> > if (!pstrMessage->pvBuffer) {
> > - result = -ENOMEM;
> > - goto ERRORHANDLER;
> > + kfree(pstrMessage);
> > + return -ENOMEM;
> > }
> > memcpy(pstrMessage->pvBuffer, pvSendBuffer, u32SendBufferSize);
> >
> > @@ -102,15 +100,7 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
> > spin_unlock_irqrestore(&pHandle->strCriticalSection, flags);
> >
> > up(&pHandle->hSem);
> > -
> > -ERRORHANDLER:
> > - /* error occured, free any allocations */
> > - if (pstrMessage) {
> > - kfree(pstrMessage->pvBuffer);
> > - kfree(pstrMessage);
> > - }
> > -
> > - return result;
> > + return 0;
>
> Aren't you now leaking memory as you aren't freeing pstrMessage and the
> buffer on the "normal" return path?
In the normal path kfree is called in a separate (wilc_mq_recv) function.
The purpose of the currently modified function (wilc_mq_send) is to post
a message to a queue by allocating memory for the message. The receiver
function is supposed to remove the message from the queue and free the
memory.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] hwrng: stm32 - add support for STM32 HW RNG
On Sat, Oct 3, 2015 at 10:35 PM, Daniel Thompson
wrote:
> Add support for STMicroelectronics STM32 random number generator.
>
> The config value defaults to N, reflecting the fact that STM32 is a
> very low resource microcontroller platform and unlikely to be targeted
> by any "grown up" defconfigs.
>
> Signed-off-by: Daniel Thompson
Incidentally both you and Lee Jones submitted similar RNG drivers from
the same company (ST) recent weeks:
Lee's ST thing:
http://marc.info/?l=linux-crypto-vger&m=144249760524971&w=2
Daniel's ST thing:
http://marc.info/?l=linux-crypto-vger&m=144390463810134&w=2
And we also have from old ST:
drivers/char/hw_random/nomadik-rng.c
1. Are these similar IPs that could be unified in a driver, just different
offsets in memory?
2. Could you at least cross-review each others drivers because both
tight loops to read bytes seem to contain similar semantics.
3. I took out the datasheet for Nomadik STn8820 and it seems that
the hardware is very similar to what this driver is trying to drive.
CR, SR and DR are in the same place, can you check if you also even
have the PrimeCell magic in the words at offset 0xfe0 thru 0xffc?
In any case it seems likely that this driver should supercede and replace
drivers/char/hw_random/nomadik-rng.c
still using the PrimeCell bus, and if it doesn't have the PrimeCell
IDs in hardware, this can be specified in the device tree using
arm,primecell-periphid = <0x000805e1>; in the node if need be.
The in-tree driver is dangerously simple and assume too much IMO.
Now the rest:
> + /* enable random number generation */
> + clk_enable(priv->clk);
> + cr = readl(priv->base + RNG_CR);
> + writel(cr | RNG_CR_RNGEN, priv->base + RNG_CR);
The Nomadik datasheet says this works the inverse way: setting
bit 2 to 1 *disables* the RNG. Can you double-check this?
The Nomadik version also has a TSTCLK bit 3, that should
always be set and loop-back checked in SR bit 1 to see that the block
is properly clocked. (Read data will hang on an AHB stall if it's
unclocked) Is this missing from STM32?
> + sr = readl(priv->base + RNG_SR);
I strongly recommend that you use readl_relaxed() for this and
all other reads on the hotpath, the Nomadik uses __raw_readl()
but that is just for the same reasons that readl_relaxed() should
be used: we just wanna read, not clean buffers etc.
> + /* Has h/ware error dection been triggered? */
> + if (WARN_ON(sr & (RNG_SR_SEIS | RNG_SR_CEIS)))
> + break;
> +
> + /* No data ready... */
> + if (!sr)
> + break;
This assumes that only bits 6,5 and 0 are ever used in this hardware.
Are you sure? On Nomadik DRDY bit 0 is the same, bit 1
is the clock test bit mentioned above, bit 2 is FAULT set if an invalid
bit sequence is detected and should definately be checked if
the HW supports it. Please mask explicitly for DRDY at least.
The bit layout gives at hand that this is indeed a derived IP block,
I wonder what bits 3 & 4 may be used for in some or all
revisions?
Then this construct:
> +static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool
> wait)
> +{
(...)
> + /* enable random number generation */
> + clk_enable(priv->clk);
> + cr = readl(priv->base + RNG_CR);
> + writel(cr | RNG_CR_RNGEN, priv->base + RNG_CR);
(...)
> + /* disable the generator */
> + writel(cr, priv->base + RNG_CR);
> + clk_disable(priv->clk);
This is in the hotpath where megabytes of data may be read out
by consecutive reads. I think it's wise to move the clock enable/disable
and also the write to cr to enable/disable the block to runtime PM
hooks, so that you can e.g. set some hysteresis around the disablement
with pm_runtime_set_autosuspend_delay(&dev->dev, 50);
pm_runtime_use_autosuspend(&dev->dev);pm_runtime_put_autosuspend().
For a primecell check the usage in drivers/mmc/host/mmci.c
for a complex usecase or e.g. drivers/hwtracing/coresight/coresight-tpiu.c
for a simpler usecase.
For the performance hints I guess you can even test whether
what I'm saying makes sense or not by reading some megabytes
of random and timing it.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] video: fbdev: add Marvell PXA framebuffer binding
Add documentation for the PXA frambuffer devicetree binding.
Signed-off-by: Robert Jarzmik
---
Since v1: Philipp's review on the whole binding
---
.../devicetree/bindings/video/marvell,pxafb.txt| 80 ++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt
diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt
b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
new file mode 100644
index ..4d6bd490680d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
@@ -0,0 +1,80 @@
+PXA LCDC Framebuffer
+
+
+Required properties:
+ - compatible :
+ "marvell,pxa2xx-lcdc",
+ - reg : Should contain 1 register ranges(address and length).
+Can contain an additional register range(address and length)
+for fixed framebuffer memory. Useful for dedicated memories.
+ - interrupts : framebuffer controller interrupt
+
+Required nodes:
+ - clocks: phandle to input clocks.
+ - port: connection to the LCD panel (see video-interfaces.txt)
+This nodes must have its properties bus-width and remote-endpoint set.
+This should be in the board dts.
+
+Example:
+
+ lcd-controller@4050 {
+ compatible = "marvell,pxa2xx-lcdc";
+ reg = <0x4400 0x1>;
+ interrupts = <17>;
+ clocks = <&clks CLK_LCD>;
+ interrupts = <23>;
+ status = "okay";
+
+ port {
+ lcdc_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ bus-width = <16>;
+ };
+ };
+ };
+
+PXA LCDC Display
+
+Required properties (as per of_videomode_helper):
+ - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
+ "color-tft", "smart-panel"
+
+Optional properties (as per of_videomode_helper):
+ - power-supply: power supply regulator to the LCD to power it on or off
+(see regulator.txt)
+ - backlight: backlight control (see backlight.txt)
+
+Required nodes:
+ - port: connection to the LCD controller
+ - display-timings: panel timings (see display-timing.txt)
+
+Example:
+ panel {
+ compatible = "toshiba,ltm0305a776";
+ lcd-type = "color-tft";
+
+ power-supply = <&lcd_supply>;
+ backlight = <&lcd_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 240p {
+ /* 240x320p24 */
+ clock-frequency = <4545000>;
+ hactive = <240>;
+ vactive = <320>;
+ hfront-porch = <4>;
+ hback-porch = <6>;
+ hsync-len = <4>;
+ vback-porch = <5>;
+ vfront-porch = <3>;
+ vsync-len = <2>;
+ };
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support
Hi Maciej, On 2 October 2015 at 22:40, Maciej S. Szmigiero wrote: > Anybody here? > > I've already submitted this patch two times but received no response... > Seems that the maintainer (Thierry) isn't Cc'ed. You might want to split the DT binding and vendor prefix to separate patches. -Emil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: misc: remove "complex return code" warnings
On Fri, Oct 02, 2015 at 11:33:46PM +0200, Julia Lawall wrote:
> Do you consider that this function would be better off in two lines?
>
> static int mxt_acquire_irq(struct mxt_data *data)
> {
> int error;
>
> enable_irq(data->irq);
>
> error = mxt_process_messages_until_invalid(data);
> if (error)
> return error;
>
> return 0;
> }
Actually no, but again I'd say it's up to the author to decide.
> Would simplifying the code at the end of the following function be helpful
> or not?
>
> static int adnp_gpio_setup(struct adnp *adnp, unsigned int num_gpios)
> {
> struct gpio_chip *chip = &adnp->gpio;
> int err;
>
> adnp->reg_shift = get_count_order(num_gpios) - 3;
>
> chip->direction_input = adnp_gpio_direction_input;
> chip->direction_output = adnp_gpio_direction_output;
> chip->get = adnp_gpio_get;
> chip->set = adnp_gpio_set;
> chip->can_sleep = true;
>
> if (IS_ENABLED(CONFIG_DEBUG_FS))
> chip->dbg_show = adnp_gpio_dbg_show;
>
> chip->base = -1;
> chip->ngpio = num_gpios;
> chip->label = adnp->client->name;
> chip->dev = &adnp->client->dev;
> chip->of_node = chip->dev->of_node;
> chip->owner = THIS_MODULE;
>
> err = gpiochip_add(chip);
> if (err)
> return err;
>
> return 0;
> }
I think this is just fine as is as well.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: misc: remove "complex return code" warnings
On Sat, Oct 03, 2015 at 06:24:27PM +0200, Julia Lawall wrote: > Acked-by: Julia Lawall > > Perhaps there is a more restricted version that can be acceptable, but I'm > OK with dropping the current version. Great, thanks! Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mm/nommu: drop unlikely behind BUG_ON()
On Sun, Oct 4, 2015 at 9:18 AM, Geliang Tang wrote:
> BUG_ON() already contain an unlikely compiler flag. Drop it.
It is not the case if CONFIG_BUG and HAVE_ARCH_BUG_ON are not set.
>
> Signed-off-by: Geliang Tang
> ---
> mm/nommu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 1e0f168..92be862 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -578,16 +578,16 @@ static noinline void validate_nommu_regions(void)
> return;
>
> last = rb_entry(lastp, struct vm_region, vm_rb);
> - BUG_ON(unlikely(last->vm_end <= last->vm_start));
> - BUG_ON(unlikely(last->vm_top < last->vm_end));
> + BUG_ON(last->vm_end <= last->vm_start);
> + BUG_ON(last->vm_top < last->vm_end);
>
> while ((p = rb_next(lastp))) {
> region = rb_entry(p, struct vm_region, vm_rb);
> last = rb_entry(lastp, struct vm_region, vm_rb);
>
> - BUG_ON(unlikely(region->vm_end <= region->vm_start));
> - BUG_ON(unlikely(region->vm_top < region->vm_end));
> - BUG_ON(unlikely(region->vm_start < last->vm_top));
> + BUG_ON(region->vm_end <= region->vm_start);
> + BUG_ON(region->vm_top < region->vm_end);
> + BUG_ON(region->vm_start < last->vm_top);
>
> lastp = p;
> }
> --
> 2.5.0
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Leon Romanovsky | Independent Linux Consultant
www.leon.nu | l...@leon.nu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] nvmem: sunxi: Check for memory allocation failure
On Wed, Sep 30, 2015 at 01:36:31PM +0100, Srinivas Kandagatla wrote: > From: Maxime Ripard > > The sunxi_sid driver doesn't check for kmalloc return status before > derefencing the returned pointer, which could lead to a NULL pointer > dereference if kmalloc failed. Check for its return code to make sure it > deosn't happen. > > Reported-by: Dan Carpenter > Signed-off-by: Maxime Ripard > --- > drivers/nvmem/sunxi_sid.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) No signed-off-by: from you on this patch? :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc 1/2 4.3 V2] mei: Fix debugfs filename in error output
On Mon, Sep 21, 2015 at 10:58:15AM +0300, Tomas Winkler wrote:
> From: Alexander Kuleshov
>
> Signed-off-by: Alexander Kuleshov
> Signed-off-by: Tomas Winkler
> ---
> V2: fixed author address
>
> drivers/misc/mei/debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
> index 4b469cf9e60f..c157f0ba575c 100644
> --- a/drivers/misc/mei/debugfs.c
> +++ b/drivers/misc/mei/debugfs.c
> @@ -213,7 +213,7 @@ int mei_dbgfs_register(struct mei_device *dev, const char
> *name)
> f = debugfs_create_file("active", S_IRUSR, dir,
> dev, &mei_dbgfs_fops_active);
> if (!f) {
> - dev_err(dev->dev, "meclients: registration failed\n");
> + dev_err(dev->dev, "active: registration failed\n");
> goto err;
You should never care if a debugfs call fails or not. Also, this will
"fail" if you don't have CONFIG_DEBUGFS enabled, which means you are
using the api wrong :(
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
For Your Kind Notice
You have been selected to receive ($950,000.00 USD) as Charity Donations/Aid from (Qatar Foundation) provide the below information ASAP. 1:Full Names: 2:Complete Address: 3:Direct Telephone numbers Sincerely, Dr.Allan Faroze Mohammed. Email: poesq0...@foxmail.com Tel:+44 70457 96790 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] memory: Fix module autoload for OF platform driver
On Tue, Sep 29, 2015 at 10:40:17AM -0700, santosh shilimkar wrote: > +Greg, arm-sock folks > > On 9/17/2015 10:56 AM, santosh shilimkar wrote: > >On 9/17/2015 10:41 AM, Luis de Bethencourt wrote: > >>Hello, > >> > >>These patches add the missing MODULE_DEVICE_TABLE() for OF to export > >>the information so modules have the correct aliases built-in and > >>autoloading works correctly. > >> > >>A longer explanation by Javier Canillas can be found here: > >>https://lkml.org/lkml/2015/7/30/519 > >> > > > >> > >>Luis de Bethencourt (2): > >> memory: fsl-corenet: Fix module autoload for OF platform driver > >> memory: ti-aemif: Fix module autoload for OF platform driver > >> > >> drivers/memory/fsl-corenet-cf.c | 1 + > >> drivers/memory/ti-aemif.c | 1 + > >> 2 files changed, 2 insertions(+) > >> > >Acked-by: Santosh Shilimkar > > Will you be able to pick these two as part of your drivers/core ? > In past you have helped me to queue the drivers/memory/*emif* > via you tree but of late, I have seen other patches from > drivers/memory/ made it via arm-soc. > > I just want to make sure that some one pick these up and hence > the email. I don't have these in any queue, so someone is going to have to resend them so that I can pick them up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc: mic: use kstrdup() in mic_sysfs
On Fri, Oct 02, 2015 at 10:43:34AM +0800, Geliang Tang wrote: > Use kstrdup instead of kmalloc and strncpy. > > Signed-off-by: Geliang Tang > --- > drivers/misc/mic/host/mic_sysfs.c | 23 --- > 1 file changed, 4 insertions(+), 19 deletions(-) This file isn't even in the tree anymore :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: iio: adc: fix comment block coding style issue
On 10/03/2015 08:32 PM, Hugo Camboulive wrote: > This patch to ad7746.c makes the comment block end with a */ > on a separate line. > > Signed-off-by: Hugo Camboulive > --- > drivers/staging/iio/cdc/ad7746.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/iio/cdc/ad7746.c > b/drivers/staging/iio/cdc/ad7746.c > index 10fa372..8445ddd 100644 > --- a/drivers/staging/iio/cdc/ad7746.c > +++ b/drivers/staging/iio/cdc/ad7746.c > @@ -531,7 +531,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev, > /* CAPDAC Scale = 21pF_typ / 127 >* CIN Scale = 8.192pF / 2^24 >* Offset Scale = CAPDAC Scale / CIN Scale = 338646 > - * */ > + */ Looks good, but while you are at it please also fix the beginning of the comment. Kernel style multi-line comments look like /* * text * more text */ So the line with the /* should have any text. Bonus points if you can also fix all other occurrences of this style error in the same file. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc: mic: replace kfree with put_device
On Wed, Sep 30, 2015 at 12:58:22AM +0800, Geliang Tang wrote: > Handle a failed device_register(), replace kfree() with put_device(), > which will call mbus_release_dev() or scif_release_dev(). > > Signed-off-by: Geliang Tang > --- > drivers/misc/mic/bus/mic_bus.c | 2 +- > drivers/misc/mic/bus/scif_bus.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Due to the recent changes in this driver, this patch doesn't apply anymore. Can you please refresh it and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: iio: meter: Use devm functions
On 10/04/2015 06:34 AM, Shraddha Barke wrote:
> [...]
Hi,
Thanks for the patch.
> - st->trig = iio_trigger_alloc("%s-dev%d",
> - spi_get_device_id(st->us)->name,
> - indio_dev->id);
> + st->trig = devm_iio_trigger_alloc(&indio_dev->id, "%s-dev%d",
But I don't think this compiles. The first parameter needs to be a struct
device.
> + spi_get_device_id(st->us)->name,
> + indio_dev->id);
> if (!st->trig) {
> ret = -ENOMEM;
> goto error_ret;
> }
>
> - ret = request_irq(st->us->irq,
> - ade7758_data_rdy_trig_poll,
> - IRQF_TRIGGER_LOW,
> - spi_get_device_id(st->us)->name,
> - st->trig);
> + ret = devm_request_irq(&indio_dev->dev, st->us->irq,
And the device also needs to be the device from whose probe function this is
called. Please add a parameter to ade7758_probe_trigger that supplies this
device.
> +ade7758_data_rdy_trig_poll,
> +IRQF_TRIGGER_LOW,
> +spi_get_device_id(st->us)->name,
> +st->trig);
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] drivers/base/node.c: skip non-present sections in register_mem_sect_under_node
On Tue, Sep 22, 2015 at 04:27:01AM -0400, Jan Stancek wrote: > > > > > - Original Message - > > From: "Jan Stancek" > > To: gre...@linuxfoundation.org > > Cc: linux-kernel@vger.kernel.org, linux...@kvack.org, "Dave Young" > > > > Sent: Wednesday, 9 September, 2015 1:11:23 PM > > Subject: Re: [PATCH 2/2] drivers/base/node.c: skip non-present sections in > > register_mem_sect_under_node > > > > Greg, > > > > any thoughts about the patch? > > ping I need some -mm people to sign off on it, as this code is tricky and I think has caused problems in the past, and I know nothing about it... So please resend and get some acks from them and I'll be glad to take it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: iio: meter: Use devm functions
On 04/10/15 05:34, Shraddha Barke wrote:
> Introduce use of managed resource function devm_iio_trigger_alloc
> instead of iio_trigger_alloc and devm_request_irq instead of request_irq
> Remove corresponding calls to iio_trigger_free and free_irq in the probe
> and remove functions.
> The now unnecessary labels error_free_trig and err_free_irq are dropped.
>
> Signed-off-by: Shraddha Barke
> ---
>
> drivers/staging/iio/meter/ade7758_trigger.c | 26 ++
> 1 file changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/iio/meter/ade7758_trigger.c
> b/drivers/staging/iio/meter/ade7758_trigger.c
> index 5b35a7f..e313b37 100644
> --- a/drivers/staging/iio/meter/ade7758_trigger.c
> +++ b/drivers/staging/iio/meter/ade7758_trigger.c
> @@ -63,21 +63,21 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
> struct ade7758_state *st = iio_priv(indio_dev);
> int ret;
>
> - st->trig = iio_trigger_alloc("%s-dev%d",
> - spi_get_device_id(st->us)->name,
> - indio_dev->id);
> + st->trig = devm_iio_trigger_alloc(&indio_dev->id, "%s-dev%d",
> + spi_get_device_id(st->us)->name,
> + indio_dev->id);
> if (!st->trig) {
> ret = -ENOMEM;
> goto error_ret;
> }
>
> - ret = request_irq(st->us->irq,
> - ade7758_data_rdy_trig_poll,
> - IRQF_TRIGGER_LOW,
> - spi_get_device_id(st->us)->name,
> - st->trig);
> + ret = devm_request_irq(&indio_dev->dev, st->us->irq,
> +ade7758_data_rdy_trig_poll,
> +IRQF_TRIGGER_LOW,
> +spi_get_device_id(st->us)->name,
> +st->trig);
> if (ret)
> - goto error_free_trig;
> + goto error_ret
>
> st->trig->dev.parent = &st->us->dev;
> st->trig->ops = &ade7758_trigger_ops;
> @@ -87,14 +87,10 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
> /* select default trigger */
> indio_dev->trig = iio_trigger_get(st->trig);
> if (ret)
> - goto error_free_irq;
> + goto error_ret;
>
> return 0;
>
> -error_free_irq:
> - free_irq(st->us->irq, st->trig);
> -error_free_trig:
> - iio_trigger_free(st->trig);
> error_ret:
> return ret;
Whilst you are here, direct returns are preferred when there is no unwinding to
do
so if you could just return the error from anywhere it does the goto error_ret
that would be great!
Thanks,
Jonathan
> }
> @@ -104,6 +100,4 @@ void ade7758_remove_trigger(struct iio_dev *indio_dev)
> struct ade7758_state *st = iio_priv(indio_dev);
>
> iio_trigger_unregister(st->trig);
> - free_irq(st->us->irq, st->trig);
> - iio_trigger_free(st->trig);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/24] ver_linux: e2fsprogs.patch
On Sun, Oct 4, 2015 at 4:48 AM, Theodore Ts'o wrote: > On Sat, Oct 03, 2015 at 04:23:02PM +0300, Alexander Kapshuk wrote: >> 'tune2fs' is located in varying places depending on the distro. >> Current implementation output on distros where 'tune2fs' is found at >> a location that is not available in the PATH for the regular user, >> e.g. '/sbin', will have nothing to display. >> While running 'ver_linux' as user 'root' should be OK. > > Instead of making all of these changes, why not just add > > PATH=$PATH:/sbin:/usr/sbin:/bin:/usr/bin > > to the beginning of ver_linux? > > - Ted Thanks for your feedback. My understanding is that $PATH used to be set in ver_linux before. It had been removed by the commit given below: 2008-07-31kbuild: scripts/ver_linux: don't set PATH It would have saved both a bug submitter and me a few hours if scripts/ver_linux had picked the same gcc as the build. Since I can't see any reason why it fiddles with PATH at all this patch therefore removes the PATH setting. Signed-off-by: Adrian Bunk Signed-off-by: Sam Ravnborg -- Perhaps a better approach would be for the user to set their $PATH appropriately in their shell environment, rather than in ver_linux, as suggested in the commentary found in ver_linux, instead of ver_linux trying to guess where the binaries are. Which effectively makes my other patch, path2bin_test.patch, redundant. Apologies for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] scsi: dpt: remove i2o header in uapi
On Sun, Oct 04, 2015 at 01:22:50AM +0200, Gabriel Laskar wrote:
> The i2o subsystem was removed by
> commit 4a72a7af462d ("staging: remove i2o subsystem") but the header was
> still used by drivers/scsi/dpt_i2o.c driver.
>
> This patch moves the structures used from the header into dpti_i2o.h.
>
> CC: Arnd Bergmann
> CC: Greg Kroah-Hartman
> Signed-off-by: Gabriel Laskar
> ---
> drivers/scsi/dpt/dpti_i2o.h | 134 +-
> include/uapi/linux/Kbuild| 1 -
> include/uapi/linux/i2o-dev.h | 421
> ---
> 3 files changed, 132 insertions(+), 424 deletions(-)
> delete mode 100644 include/uapi/linux/i2o-dev.h
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] x86/process: Add proper bound checks in 64bit get_wchan()
On Sat, Oct 3, 2015 at 1:31 PM, Andrey Ryabinin wrote:
> 2015-10-03 13:54 GMT+03:00 Thomas Gleixner :
>> On Fri, 2 Oct 2015, Sasha Levin wrote:
>>> I'm seeing a different issue with this patch:
>>>
>>> [ 5228.736320] BUG: KASAN: out-of-bounds in get_wchan+0xf9/0x1b0 at addr
>>> 88049d2b7c50
>>> [ 5228.737560] Read of size 8 by task killall/22177
>>> [ 5228.738304] page:ea001274adc0 count:0 mapcount:0 mapping:
>>> (null) index:0x0
>>> [ 5228.739374] flags: 0x6f8000()
>>> [ 5228.739862] page dumped because: kasan: bad access detected
>>> [ 5228.741764] CPU: 8 PID: 22177 Comm: killall Not tainted
>>> 4.3.0-rc3-next-20151002-sasha-00076-gde7fa56-dirty #2590
>>> [ 5228.743337] 882c80967828 7a901a83 882c80967790
>>> acd2c8c8
>>> [ 5228.744409] 88049d2b7c50 882c80967818 ab74befb
>>> 882c8bd0
>>> [ 5228.745436] 0002 0282 882c8bd00cf8
>>> 0001
>>> [ 5228.746446] Call Trace:
>>> [ 5228.746881] dump_stack (lib/dump_stack.c:52)
>>> [ 5228.747720] kasan_report_error (include/linux/kasan.h:28
>>> mm/kasan/report.c:170 mm/kasan/report.c:237)
>>> [ 5228.748670] __asan_report_load8_noabort (mm/kasan/report.c:279)
>>> [ 5228.750563] get_wchan (arch/x86/kernel/process.c:561)
>>> [ 5228.751378] do_task_stat (fs/proc/array.c:458)
>>> [ 5228.755912] proc_tgid_stat (fs/proc/array.c:565)
>>> [ 5228.756770] proc_single_show (./arch/x86/include/asm/atomic.h:118
>>> include/linux/sched.h:2012 fs/proc/base.c:789)
>>> [ 5228.759066] seq_read (fs/seq_file.c:238)
>>> [ 5228.762360] __vfs_read (fs/read_write.c:432)
>>> [ 5228.767957] vfs_read (fs/read_write.c:454)
>>> [ 5228.769368] SyS_read (fs/read_write.c:570 fs/read_write.c:562)
>>> [ 5228.778344] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
>>> [ 5228.779272] Memory state around the buggy address:
>>> [ 5228.779971] 88049d2b7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00
>>> [ 5228.780992] 88049d2b7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00
>>> [ 5228.782021] >88049d2b7c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00
>>> [ 5228.783066] ^
>>> [ 5228.783936] 88049d2b7c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 00
>>> [ 5228.784994] 88049d2b7d00: 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3
>>> f3 f3
>>>
>>> fp = READ_ONCE(*(unsigned long *)sp);
>>> do {
>>> if (fp < bottom || fp > top)
>>> return 0;
>>> ip = READ_ONCE(*(unsigned long *)(fp + sizeof(unsigned
>>> long)));
>>> if (!in_sched_functions(ip))
>>> return ip;
>>> fp = READ_ONCE(*(unsigned long *)fp); <=== Here
>>
>> Weird, we accessed
>>
>> *(unsigned long *)(fp + sizeof(unsigned long))
>>
>> a few lines above, i.e. 88049d2b7c58
>>
>> But what's more weird is that the memory dump does not really look
>> like a stack at all.
>>
>> 88049d2b7c50 is stored on the stack:
>>
>>> [ 5228.744409] 88049d2b7c50 882c80967818 ab74befb
>>> 882c8bd0
>>
>> But if it is not inside the stack bounds, how do we end up
>> dereferencing it. Confused
>>
>
> I'm sure that we in stack bounds here.
> But we are not inside bounds of some stack variable
> and KASAN doesn't like it.
Agree.
> KASAN changes stack frame of each function, e.g.
> void foo() {
> int a;
> }
>
> transformed to:
> void foo() {
> char redzone1[32];
> int a;
> char redzone2[28];
> char redzone3[32];
> }
>
> So any access to redzones will be reported.
>
> I could make a patch which will tell KASAN to ignore get_wchan(),
> but if there are any real bugs left in get_wchan() they will be ignored too.
Yes, we need KASAN to ignore it. False positives are not acceptable. I
wanted to mail a fix after the fix for the real bug. I am thinking
about kasan_disable_current/kasan_enable_current around the region
that does the stack accesses; the reports are rare enough, so it
should not have any significant performance effect. I don't mind if
you send the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/24] ver_linux: path2bin_test.patch
On Sat, Oct 3, 2015 at 4:10 PM, Alexander Kapshuk
wrote:
> As suggested by Jim Davis , this patch checks for
> binaries in the user's $PATH first by calling 'which name-of-binary'. If
> the binary is not found there, an attempt is made to find it elsewhere
> on the system. 'whereis name-of-binary' is used to that end.
>
> Below is Jim's reasoning behind the suggestion made:
> Though looking back at your patch, what might work is to look first
> for depmod in the user's $PATH and then try whereis only if that fails.
> I'm not convinced that's much better than just searching $PATH, but that
> at least would go with the user's preference first.
>
> Tested on:
> Gentoo Linux
> Debian 6.0.10
> Oracle Linux Server release 7.1
>
> Signed-off-by: Alexander Kapshuk
> ---
> --- linux/scripts/ver_linux.orig2015-10-03 13:41:57.118790241 +0300
> +++ linux/scripts/ver_linux2015-10-03 13:46:25.879768460 +0300
> @@ -11,6 +11,166 @@
> uname -a
> echo ' '
>
> +gcc=`which gcc 2>/dev/null`
> +test -n "$gcc" ||
> +gcc=`whereis gcc |
> +sed '/\/gcc/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +make=`which make 2>/dev/null`
> +test -n "$make" ||
> +make=`whereis make |
> +sed '/\/make/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +ld=`which ld 2>/dev/null`
> +test -n "$ld" ||
> +ld=`whereis ld |
> +sed '/\/ld/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +mount=`which mount 2>/dev/null`
> +test -n "$mount" ||
> +mount=`whereis mount |
> +sed '/\/mount/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +depmod=`which depmod 2>/dev/null`
> +test -n "$depmod" ||
> +depmod=`whereis depmod |
> +sed '/\/depmod/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +tune2fs=`which tune2fs 2>/dev/null`
> +test -n "$tune2fs" ||
> +tune2fs=`whereis tune2fs |
> +sed '/\/tune2fs/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +fsckjfs=`which fsck.jfs 2>/dev/null`
> +test -n "$fsckjfs" ||
> +fsckjfs=`whereis fsck.jfs |
> +sed '/\/fsck.jfs/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +reiserfsck=`which reiserfsck 2>/dev/null`
> +test -n "$reiserfsck" ||
> +reiserfsck=`whereis reiserfsck |
> +sed '/\/reiserfsck/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +xfs_db=`which xfs_db 2>/dev/null`
> +test -n "$xfs_db" ||
> +xfs_db=`whereis xfs_db |
> +sed '/\/xfs_db/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +pccardctl=`which pccardctl 2>/dev/null`
> +test -n "$pccardctl" ||
> +pccardctl=`whereis pccardctl |
> +sed '/\/pccardctl/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +quota=`which quota 2>/dev/null`
> +test -n "$quota" ||
> +quota=`whereis quota |
> +sed '/\/quota/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +pppd=`which pppd 2>/dev/null`
> +test -n "$pppd" ||
> +pppd=`whereis pppd |
> +sed '/\/pppd/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +ldd=`which ldd 2>/dev/null`
> +test -n "$ldd" ||
> +ldd=`whereis ldd |
> +sed '/\/ldd/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +ldconfig=`which ldconfig 2>/dev/null`
> +test -n "$ldconfig" ||
> +ldconfig=`whereis ldconfig |
> +sed '/\/ldconfig/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +ps=`which ps 2>/dev/null`
> +test -n "$ps" ||
> +ps=`whereis ps |
> +sed '/\/ps/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +ifconfig=`which ifconfig 2>/dev/null`
> +test -n "$ifconfig" ||
> +ifconfig=`whereis ifconfig |
> +sed '/\/ifconfig/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +loadkeys=`which loadkeys 2>/dev/null`
> +test -n "$loadkeys" ||
> +loadkeys=`whereis loadkeys |
> +sed '/\/loadkeys/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +expr=`which expr 2>/dev/null`
> +test -n "$expr" ||
> +expr=`whereis expr |
> +sed '/\/expr/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +udev=`which udevadm 2>/dev/null`
> +test -n "$udev" ||
> +udev=`whereis udevadm |
> +sed '/\/udevadm/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> +iwconfig=`which iwconfig 2>/dev/null`
> +test -n "$iwconfig" ||
> +iwconfig=`whereis iwconfig |
> +sed '/\/iwconfig/!d
> +s/.*:[ \t]//
> +s/[ \t].*//'
> +`
> +
> gcc -dumpversion 2>&1| awk \
> 'NR==1{print "Gnu C ", $1}'
About this patch...
It is probably better to have the user set their $PATH appropriately
in their shell environment as suggested in the commentary found in
ver_linux, rather than have ver_linux guess where the binaries are.
So, please do not apply this patch, unless you think otherwise. Thanks.
As far as the other ver_linux patches I have sent in is concerned, if
you consider any, or all of them to be over-engineered, please do not
apply them.
Apologies for the confusion, o
Re: Problems with printk logs and my driver
On 30 September 2015 at 13:07, Austin S Hemmelgarn wrote: > On 2015-09-29 18:11, Eric Curtin wrote: >> >> On 25 September 2015 at 16:45, Austin S Hemmelgarn >> wrote: >>> >>> On 2015-09-25 08:02, Jiri Kosina wrote: On Fri, 25 Sep 2015, Felipe Tonello wrote: > Maybe a better description on Kconfig and/or comments on source code > it's enough. I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless. >>> For some reason there seem to be a lot of people who go to configure >>> there >>> own kernel and don't read the help text (I understand if you've been >>> building your own Linux kernel's for years and actually understand what a >>> Kconfig option is really asking, but most people who I've heard of doing >>> this have never built a kernel before in their life). >>> >>> On the other hand, can anyone think of any real reason to use this >>> outside >>> of embedded systems? I know there are a lot of distros that build this >>> and >>> the USB HIDBP mouse support as modules, but I have yet to hear/find any >>> reports of hardware that _only_ works with this driver and not the >>> generic >>> HID driver. If this is the case, it might make sense to make this depend >>> on >>> EXPERT or at least remove the bit about 'simple keyboards'. >>> >> >> As regards renaming usbkbd.c, @Austin there are some reasons why you would >> not read the Kconfig. As a beginner, I didn't even configure this part or >> read the help text as I used the configuration that comes with Fedora, I >> don't know if that's a valid excuse or not though. I'll leave you guys >> decide, you're the experts! >> >> As regards the issue with my capslock led I'm still looking into it. >> > Personally, I would not ever advocate not reading the help text for an > option (although in some cases it's pretty un-helpful, especially for some > staging drivers). > > Your case is one of the common ones, and it's not a bad place to start, but > you have to keep in mind that most distro's turn on a huge amount of stuff > that more than 90% of people aren't ever going to need (for example, I'm > pretty sure Ubuntu still builds a module for SLIP, which has been an > essentially dead technology for more than a decade now). For anyone starting > from a distro's kconfig, I'd suggest at least: > a. Turn off CONFIG_EXPERT unless you intend to actually try and understand > the options it enables (most distro's turn this on for some of the fine > tuning features it enables, most regular people don't actually need it). > b. Go through using menuconfig, and turn off stuff under the drivers menu > that you know you will never need (and take the time to use stuff like lspci > and lsusb to figure out what actually need). > c. Read the help text before trying to change anything, and if you don't > understand it after that, look it up online, and even then be careful > changing it. > d. If you intend on actually using it with a particular distro, don't turn > off too much outside of the drivers menu, other stuff can cause things to > fail in unusual ways, and you often won't get a great amount of help from > the distro maintainers when using a custom kernel. > > The real problem is when people just read the option name and think they > understand it when they don't really (or just don't think about the > implications), and then wonder why something stops working suddenly (like > one guy I know who was building a kernel for a server, and thought he could > just disable everything under the 'Graphics' menu, then wondered why he > didn't get console output on his monitor). > Ok so for the fun of it, I changed the VENDOR_ID and DEVICE_ID of my keyboard to use the driver for this samsung Wireless keyboard and mouse, crazy I know since I have a different piece of hardware, but I wanted to see what happens or at least does it change driver. When I reboot to this kernel, my keyboard still uses the usbhid driver. Why does this happen? diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index f769208..350a6f8 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @
Re: [PATCH] Staging: iio: meter: Use devm functions
On Sun, 4 Oct 2015, Jonathan Cameron wrote:
On 04/10/15 05:34, Shraddha Barke wrote:
Introduce use of managed resource function devm_iio_trigger_alloc
instead of iio_trigger_alloc and devm_request_irq instead of request_irq
Remove corresponding calls to iio_trigger_free and free_irq in the probe
and remove functions.
The now unnecessary labels error_free_trig and err_free_irq are dropped.
Signed-off-by: Shraddha Barke
---
drivers/staging/iio/meter/ade7758_trigger.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/iio/meter/ade7758_trigger.c
b/drivers/staging/iio/meter/ade7758_trigger.c
index 5b35a7f..e313b37 100644
--- a/drivers/staging/iio/meter/ade7758_trigger.c
+++ b/drivers/staging/iio/meter/ade7758_trigger.c
@@ -63,21 +63,21 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
struct ade7758_state *st = iio_priv(indio_dev);
int ret;
- st->trig = iio_trigger_alloc("%s-dev%d",
- spi_get_device_id(st->us)->name,
- indio_dev->id);
+ st->trig = devm_iio_trigger_alloc(&indio_dev->id, "%s-dev%d",
+ spi_get_device_id(st->us)->name,
+ indio_dev->id);
if (!st->trig) {
ret = -ENOMEM;
goto error_ret;
}
- ret = request_irq(st->us->irq,
- ade7758_data_rdy_trig_poll,
- IRQF_TRIGGER_LOW,
- spi_get_device_id(st->us)->name,
- st->trig);
+ ret = devm_request_irq(&indio_dev->dev, st->us->irq,
+ ade7758_data_rdy_trig_poll,
+ IRQF_TRIGGER_LOW,
+ spi_get_device_id(st->us)->name,
+ st->trig);
if (ret)
- goto error_free_trig;
+ goto error_ret
st->trig->dev.parent = &st->us->dev;
st->trig->ops = &ade7758_trigger_ops;
@@ -87,14 +87,10 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
/* select default trigger */
indio_dev->trig = iio_trigger_get(st->trig);
if (ret)
- goto error_free_irq;
+ goto error_ret;
return 0;
-error_free_irq:
- free_irq(st->us->irq, st->trig);
-error_free_trig:
- iio_trigger_free(st->trig);
error_ret:
return ret;
Whilst you are here, direct returns are preferred when there is no unwinding to
do
so if you could just return the error from anywhere it does the goto error_ret
that would be great!
I was a little skeptical about the change from request_irq to
devm_request_irq because I'm not sure whether the things that are
freed by the function are needed by the interrupt handler. Do you
think it's correct?
Shraddha
Thanks,
Jonathan
}
@@ -104,6 +100,4 @@ void ade7758_remove_trigger(struct iio_dev *indio_dev)
struct ade7758_state *st = iio_priv(indio_dev);
iio_trigger_unregister(st->trig);
- free_irq(st->us->irq, st->trig);
- iio_trigger_free(st->trig);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/7] squashfs: xattr simplifications
2015-10-04 8:29 GMT+02:00 Christoph Hellwig : > IS it just me or is this handler broke before and after this patch? It > only copies out the prefix, but not the actual xattr name. Well, squashfs appends the rest of the name in squashfs_listxattr, so it's not broken, just different. I have tried cleaning that up by converting the list operation into something like this instead: bool (*may_list)(struct dentry *dentry); The xattr name would always be copied into the buffer in iop->listxattr. But security_inode_listsecurity which is called from vfs_getxattr as well as nfs4_xattr_list_nfs4_label was getting in the way, and it's unclear to me how to best clean that up first. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: Modify the id and name of external connector
On Sun, Oct 04, 2015 at 12:45:36PM +0900, Chanwoo Choi wrote:
> This patch modifies the id and name of external connector with the additional
> prefix to clarify both attribute and meaning of external connector as
> following:
> - EXTCON_CHG_* mean the charger connector.
> - EXTCON_JACK_* mean the jack connector.
> - EXTCON_DISP_* mean the display port connector.
>
> Following table show the new name of external connector with old name:
> -
> Old extcon name | New extcon name |
> -
> EXTCON_TA | EXTCON_CHG_USB_DCP|
> EXTCON_FAST_CHARGER | EXTCON_CHG_USB_FAST |
> EXTCON_SLOW_CHARGER | EXTCON_CHG_USB_SLOW |
> EXTCON_CHARGE_DOWNSTREAM| EXTCON_CHG_USB_CDP|
> -
> EXTCON_MICROPHONE | EXTCON_JACK_MICROPHONE|
> EXTCON_HEADPHONE| EXTCON_JACK_HEADPHONE |
> EXTCON_LINE_IN | EXTCON_JACK_LINE_IN |
> EXTCON_LINE_OUT | EXTCON_JACK_LINE_OUT |
> EXTCON_VIDEO_IN | EXTCON_JACK_VIDEO_IN |
> EXTCON_VIDEO_OUT| EXTCON_JACK_VIDEO_OUT |
> EXTCON_SPDIF_IN | EXTCON_JACK_SPDIF_IN |
> EXTCON_SPDIF_OUT| EXTCON_JACK_SPDIF_OUT |
> -
> EXTCON_HMDI | EXTCON_DISP_HDMI |
> EXTCON_MHL | EXTCON_DISP_MHL |
> EXTCON_DVI | EXTCON_DISP_DVI |
> EXTCON_VGA | EXTCON_DISP_VGA |
> -
>
> And, when altering the name of USB charger connector, EXTCON refers to the
> "USB battery charging specification"[1] to use the standard name of USB
> charging port as following. Following name of USB charging port are already
> used
> in power_supply subsystem. We chan check it on patch[2].
> - EXTCON_CHG_USB /* Standard Downstream Port */
> - EXTCON_CHG_USB_DCP /* Dedicated Charging Port */
> - EXTCON_CHG_USB_CDP /* Charging Downstream Port */
> - EXTCON_CHG_USB_ACA /* Accessory Charging Adapter */
>
> [1]
> http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf
> [2] commit 85efc8a18ce ("[PATCH] power_supply: Add types for USB chargers")
>
> Signed-off-by: Chanwoo Choi
> ---
For the Arizona changes:
Acked-by: Charles Keepax
Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] fs: have flush_delayed_fput flush the workqueue job
On Thu, 17 Sep 2015 08:39:44 -0400
Jeff Layton wrote:
> I think there's a potential race in flush_delayed_fput. A kthread does
> an fput() and that file gets added to the list and the delayed work is
> scheduled. More than 1 jiffy passes, and the workqueue thread picks up
> the work and starts running it. Then the kthread calls
> flush_delayed_work. It sees that the list is empty and returns
> immediately, even though the __fput for its file may not have run yet.
>
> Close this by making flush_delayed_fput use flush_delayed_work instead,
> which should immediately schedule the work to run if it's not already,
> and block until the workqueue job completes.
>
> Signed-off-by: Jeff Layton
> ---
> fs/file_table.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
It should be noted that the only current user of flush_delayed_fput()
can call it before the workqueue threads are ever started.
Looking at the code, I *think* this will still do the right thing --
block until those threads are started and then flush the work as usual,
but do let me know if I've misread it.
> diff --git a/fs/file_table.c b/fs/file_table.c
> index ad17e05ebf95..52cc6803c07a 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -244,6 +244,8 @@ static void fput(struct callback_head *work)
> __fput(container_of(work, struct file, f_u.fu_rcuhead));
> }
>
> +static DECLARE_DELAYED_WORK(delayed_fput_work, delayed_fput);
> +
> /*
> * If kernel thread really needs to have the final fput() it has done
> * to complete, call this. The only user right now is the boot - we
> @@ -256,11 +258,9 @@ static void fput(struct callback_head *work)
> */
> void flush_delayed_fput(void)
> {
> - delayed_fput(NULL);
> + flush_delayed_work(&delayed_fput_work);
> }
>
> -static DECLARE_DELAYED_WORK(delayed_fput_work, delayed_fput);
> -
> void fput(struct file *file)
> {
> if (atomic_long_dec_and_test(&file->f_count)) {
--
Jeff Layton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: sun4i-codec: Rework and fix headphone routing
Most of the boards have their headphone jack directly connected to the
matching pins of the SoCs. Since most of the time we will have the same
routing path, it makes sense to put that in the driver, and only have a
property describing whether that route is enabled or not.
It also fixes the following warning messages that were seen so far:
sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack
sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct ->
Headphone Jack
sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack
sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct ->
Headphone Jack
Reported-by: Priit Laes
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/sound/sun4i-codec.txt | 9
sound/soc/sunxi/sun4i-codec.c | 25 +-
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index 680144b74ae9..470823845698 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -13,10 +13,10 @@ Required properties:
- clock-names: should contain followings:
- "apb": the parent APB clock for this controller
- "codec": the parent module clock
-- routing : A list of the connections between audio components. Each
- entry is a pair of strings, the first being the connection's sink,
- the second being the connection's source.
+Optional Properties:
+- allwinner,hp-jack-attached: Indicates that the headphone jack on the
+ board is directly routed to the SoC pins
Example:
codec: codec@01c22c00 {
@@ -28,6 +28,5 @@ codec: codec@01c22c00 {
clock-names = "apb", "codec";
dmas = <&dma 0 19>, <&dma 0 19>;
dma-names = "rx", "tx";
- routing = "Headphone Jack", "HP Right",
- "Headphone Jack", "HP Left";
+ allwinner,hp-jack-attached;
};
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 47780552dcd0..e86b8fcede5a 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -568,10 +568,18 @@ static struct snd_soc_dai_link
*sun4i_codec_create_link(struct device *dev,
return link;
};
+static const struct snd_soc_dapm_widget sun4i_codec_sink_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+};
+
+static const struct snd_soc_dapm_route sun4i_codec_sink_routes[] = {
+ { "Headphone Jack", NULL, "HP Right" },
+ { "Headphone Jack", NULL, "HP Left" },
+};
+
static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
{
struct snd_soc_card *card;
- int ret;
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -584,10 +592,17 @@ static struct snd_soc_card
*sun4i_codec_create_card(struct device *dev)
card->dev = dev;
card->name = "sun4i-codec";
- ret = snd_soc_of_parse_audio_routing(card, "routing");
- if (ret) {
- dev_err(dev, "Failed to create our audio routing\n");
- return NULL;
+ /*
+* FIXME: This will probably require more logic once we will
+*support other sinks (for capture for example), or
+*encounter more complicated setups where the
+*headphone jack is not directly connected to the SoC.
+*/
+ if (of_property_read_bool(dev->of_node, "allwinner,hp-jack-attached")) {
+ card->dapm_widgets = sun4i_codec_sink_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun4i_codec_sink_widgets);
+ card->dapm_routes = sun4i_codec_sink_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun4i_codec_sink_routes);
}
return card;
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] kbuild: document recursive dependency limitation / resolution
Hi Luis, I finally found some time to read your patch. Thanks for doing this work in such great detail. What I miss in the text is a general discussion of the widespread use of selects. In my opinion, selects should be (like gotos) considered harmful: First, selects ignore the user selection and all feature constraints: a symbol can be selected regardless if this breaks the constraints induced by dependencies. Second, in my experience, selects are oftentimes used to make manual configuration of the kernel easier, since a given symbol is visible to the user even when the symbol's dependency is not yet selected. In contrast to a select, a symbol using a dependency is only visible to the user when its dependency are satisfied. I see it as a decision between being semantically correct (depends) and being easy to configure/user friendly (select). The danger of using selects is already mentioned in the description of selects, but I believe that it's good to raise awareness on top of what you already wrote down. On Sep 23 '15 09:41, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Recursive dependency issues with kconfig are unavoidable due to > some limitations with kconfig, since these issues are recurring > provide a hint to the user how they can resolve these dependency > issues and also document why such limitation exists. > > While at it also document a bit of future prospects of ways to > enhance Kconfig, including providing formal semantics and evaluation > of use of a SAT solver. > > Cc: Geert Uytterhoeven > Cc: James Bottomley > Cc: Josh Triplett > Cc: Paul Bolle > Cc: Herbert Xu > Cc: Takashi Iwai > Cc: "Yann E. MORIN" > Cc: Michal Marek > Cc: Jonathan Corbet > Cc: Mate Soos > Cc: linux-kbu...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Luis R. Rodriguez > --- > > This v3 builds up on requests on the v2 patch [0] by Josh first to clarify use > of a SAT solver remains purely theoretical to address the known recursive > dependency issues, and lastly then feedback by Paul to clarify why we > have the recursive dependency issues. Since I still think the practical > implications I was trying to clarify are important for developers to be > aware of I've separated that into a different subsection. Lastly, I've added > two subsections so that folks interested in advancing Kconfig can dig into > to try to help address the feasibility of using a SAT solver with Kconfig. > > I should also note that prospect use of SAT solvers on Linux is not only > limited to Kconfig, however some areas may obviously require smaller time > resolution constraints. For instance another theoretical area is in the use of > kernel call site use of select_idle_sibling() where the schedular checks if > the > overall compute and NUMA accesses of the system would be improved if the > source > tasks were migrated to another target CPU. Such use would require a resolution > in the thousands of CPU cycles time frame, and the size of the problems will > vary depending on the number of CPUs, topology, and workloads. In addition > workload parameters in particular can vary extremely fast, its not even > certain > yet if these problems can be represented as a SAT problem at the moment. > Another optimization consideration would be the requirement for scheduling > decisions to have all data locally avaiable, offloading such problems would > very likely not be viable solution, for instance, so fully hardware assisted > SAT solvers may be required. Hardware assisted SAT solutions are known to > exist > but R&D for it is still in early stages [1] [2] [3]. > > [0] > http://lkml.kernel.org/r/1438200556-13842-1-git-send-email-mcg...@do-not-panic.com > [1] https://dl.acm.org/citation.cfm?id=1025035 > [2] http://sweet.ua.pt/iouliia/Papers/2004/SSPA_FPL.pdf > [3] http://link.springer.com/chapter/10.1007/978-3-540-71431-6_32 > > Documentation/kbuild/Kconfig.recursion-issue-01 | 13 ++ > Documentation/kbuild/Kconfig.recursion-issue-02 | 17 ++ > Documentation/kbuild/kconfig-language.txt | 233 > > scripts/kconfig/symbol.c| 2 + > 4 files changed, 265 insertions(+) > create mode 100644 Documentation/kbuild/Kconfig.recursion-issue-01 > create mode 100644 Documentation/kbuild/Kconfig.recursion-issue-02 > > diff --git a/Documentation/kbuild/Kconfig.recursion-issue-01 > b/Documentation/kbuild/Kconfig.recursion-issue-01 > new file mode 100644 > index ..a097973025e7 > --- /dev/null > +++ b/Documentation/kbuild/Kconfig.recursion-issue-01 > @@ -0,0 +1,13 @@ > +mainmenu "Simple example to demo kconfig recursive dependency issue" > + > +config CORE > + tristate > + > +config CORE_BELL_A > + tristate > + depends on CORE > + > +config CORE_BELL_A_ADVANCED > + tristate > + depends on CORE_BELL_A > + select CORE > diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02
Re: [PATCH 2/2] iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs
On 02/10/15 13:45, Paul Cercueil wrote:
> This patch adds support for the AD5592R (spi) and AD5593R (i2c)
> ADC/DAC devices.
>
> Signed-off-by: Paul Cercueil
SMBUS makes the assumption that the wire order is little endian. As such
all the i2c drivers should be doing an necessary endian conversions
for word write / read internally. Hence if the wire order is be16 you'll
want unconditional swaps. Note we have i2c_smbus_read_word_swapped
and i2c_smbus_write_word_swapped for this.
I've mentioned this in a few places inline but there are probably others.
See Documentation/i2c/smbus-protocol.txt for more details.
Various other bits inline.
I would in particular like you to use a common module to handle the base
part rather than linking this object file into two separate modules..
Jonathan
> ---
> drivers/iio/dac/Kconfig | 22 +++
> drivers/iio/dac/Makefile | 2 +
> drivers/iio/dac/ad5592r-base.c| 290
> ++
> drivers/iio/dac/ad5592r-base.h| 59 +++
> drivers/iio/dac/ad5592r.c | 121 ++
> drivers/iio/dac/ad5593r.c | 121 ++
> include/dt-bindings/iio/adi,ad5592r.h | 13 ++
> 7 files changed, 628 insertions(+)
> create mode 100644 drivers/iio/dac/ad5592r-base.c
> create mode 100644 drivers/iio/dac/ad5592r-base.h
> create mode 100644 drivers/iio/dac/ad5592r.c
> create mode 100644 drivers/iio/dac/ad5593r.c
> create mode 100644 include/dt-bindings/iio/adi,ad5592r.h
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index e701e28..e520059 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -72,6 +72,28 @@ config AD5449
> To compile this driver as a module, choose M here: the
> module will be called ad5449.
>
> +config AD5592R
> + tristate "Analog Devices AD5592R ADC/DAC driver"
> + depends on SPI_MASTER
> + depends on OF
> + help
> + Say yes here to build support for Analog Devices AD5592R
> + Digital to Analog / Analog to Digital Converter.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad5592r.
> +
> +config AD5593R
> + tristate "Analog Devices AD5593R ADC/DAC driver"
> + depends on I2C
> + depends on OF
> + help
> + Say yes here to build support for Analog Devices AD5593R
> + Digital to Analog / Analog to Digital Converter.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad5593r.
> +
> config AD5504
> tristate "Analog Devices AD5504/AD5501 DAC SPI driver"
> depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 63ae056..181fc28 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -11,6 +11,8 @@ obj-$(CONFIG_AD5064) += ad5064.o
> obj-$(CONFIG_AD5504) += ad5504.o
> obj-$(CONFIG_AD5446) += ad5446.o
> obj-$(CONFIG_AD5449) += ad5449.o
> +obj-$(CONFIG_AD5592R) += ad5592r.o ad5592r-base.o
> +obj-$(CONFIG_AD5593R) += ad5593r.o ad5592r-base.o
Note the majority of distros will just enable anything and everything. Hence
most of the time they'll both be built. As such I'd prefer you to make
the minor mods needed to have a common base module rather than dublicating
the *-base.o object in both modules.
> obj-$(CONFIG_AD5755) += ad5755.o
> obj-$(CONFIG_AD5764) += ad5764.o
> obj-$(CONFIG_AD5791) += ad5791.o
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
> new file mode 100644
> index 000..347f209
> --- /dev/null
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -0,0 +1,290 @@
> +/*
> + * AD5592R Digital <-> Analog converters driver
> + *
> + * Copyright 2014 Analog Devices Inc.
> + * Author: Paul Cercueil
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +/*
> + * TODO:
> + * - Add support for using channels as GPIOs
> + */
> +
> +#include "ad5592r-base.h"
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int ad5592r_set_channel_modes(struct ad5592r_state *st)
> +{
> + const struct ad5592r_rw_ops *ops = st->ops;
> + int ret;
> + unsigned i;
> + struct iio_dev *iio_dev = iio_priv_to_dev(st);
> + u8 pulldown = 0, open_drain = 0, tristate = 0,
> +dac = 0, adc = 0, gpio_in = 0, gpio_out = 0;
> + u16 read_back;
> +
> + for (i = 0; i < st->chip_info->num_channels; i++) {
> + switch (st->channel_modes[i]) {
> + case CH_MODE_DAC:
> + dac |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_ADC:
> + adc |= BIT(i);
> + break;
> +
> + case CH_MODE_GPIO_OUT:
> + gpio_out |= BIT(i);
> +
> + /* fall-through */
> + case CH_MODE_GPIO_IN:
> + gpio_in |= BIT(i);
> + break
Re: [PATCH 3/3] iio: ad5064: Always use external vref if there is no internal vref
On 02/10/15 13:41, Paul Cercueil wrote:
> If the device does not have an internal reference, there is no
> other choice but to use the external reference. In that case,
> it does not make much sense to have to specify it.
>
> This patch ensures that the external reference is used if the
> device does not feature an internal reference.
>
> Signed-off-by: Paul Cercueil
Other than the issue the autobuilder found I'm happy enough
with the series.
Given it is Lars' driver I'd like him to take a look as well
before I apply it.
Thanks,
Jonathan
> ---
> drivers/iio/dac/ad5064.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5064.c b/drivers/iio/dac/ad5064.c
> index 7146f42..daee39e 100644
> --- a/drivers/iio/dac/ad5064.c
> +++ b/drivers/iio/dac/ad5064.c
> @@ -464,7 +464,9 @@ static int ad5064_probe(struct device *dev, enum
> ad5064_type type,
> for (i = 0; i < ad5064_num_vref(st); ++i)
> st->vref_reg[i].supply = ad5064_vref_name(st, i);
>
> - if (dev->of_node) {
> + if (!st->chip_info->internal_vref) {
> + ext_vref = true;
> + } else if (dev->of_node) {
> for (i = 0; ext_vref && i < ad5064_num_vref(st); ++i)
> ext_vref = of_property_read_bool(dev->of_node,
> ad5064_vref_name(st, i));
> @@ -483,11 +485,6 @@ static int ad5064_probe(struct device *dev, enum
> ad5064_type type,
> if (ret)
> return ret;
> } else {
> - if (!st->chip_info->internal_vref) {
> - dev_err(dev, "No vref available\n");
> - return -ENXIO;
> - }
> -
> st->use_internal_vref = true;
> ret = ad5064_write(st, AD5064_CMD_CONFIG, 0,
> AD5064_CONFIG_INT_VREF_ENABLE, 0);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: Fix build errors with mipsel-linux-uclibc compiler
Hello Stephane, Armaldo, On Tue, 2015-09-22 at 00:06 +0300, Aaro Koskinen wrote: > Hi, > > On Mon, Sep 21, 2015 at 04:29:39PM +, Alexey Brodkin wrote: > > > Em Fri, Sep 04, 2015 at 04:01:54PM -0700, Petri Gynther escreveu: > > > > On Fri, Sep 4, 2015 at 3:48 PM, Arnaldo Carvalho de Melo > > > > wrote: > > > > > Em Fri, Sep 04, 2015 at 03:45:03PM -0700, Petri Gynther escreveu: > > > > > > This commit breaks the perf tool MIPS build because MIPS doesn't > > > > > > have > > > > > > CONFIG_PERF_REGS=y in .config-detected: > > > > > > > > > > > > commit bcc84ec65ad1bd9f777a1fade6f8e5e0c5808fa5 > > > > > > Author: Stephane Eranian > > > > > > Date: Mon Aug 31 18:41:12 2015 +0200 > > > > > > > > > > > > perf record: Add ability to name registers to record > > > > > > > > > > There was a fix for another arch that came after this one.. here it > > > > > is, already > > > > > upstream, can you take a look? > > > > > > > > > > commit af4aeadd8c04303c0aa2d112145c3627e2ebd026 > > > > > Author: Stephane Eranian > > > > > Date: Tue Sep 1 11:30:14 2015 +0200 > > > > > > > > > > perf tools: Fix link time error with sample_reg_masks on non x86 > > > > > > > > > > This patch makes perf compile on non x86 platforms by defining a > > > > > weak > > > > > symbol for sample_reg_masks[] in util/perf_regs.c. > > > > > > > > > > The patch also moves the REG() and REG_END() macros into the > > > > > util/per_regs.h header file. The macros are renamed to > > > > > SMPL_REG/SMPL_REG_END to avoid clashes with other header files. > > > > > > > > > > > > > > > > > > I have the above commit in my tree (as I have the latest Linus' tree > > > > as of right now). > > > > The MIPS build is still broken as I reported. > > > > > > Stephane, can you please take a look? > > > > The same problem happens when building perf on ARC. > > I'm on 4.3-rc2 and that's what I see: > > --->8- > > LINK .../linux-4.3-rc2/tools/perf/perf > > .../linux-4.3-rc2/tools/perf/libperf.a(libperf-in.o): In function > > `parse_regs': > > .../linux-4.3-rc2/tools/perf/util/parse-regs-options.c:28: undefined > > reference to `sample_reg_masks' > > .../linux-4.3-rc2/tools/perf/util/parse-regs-options.c:45: undefined > > reference to `sample_reg_masks' > > .../linux-4.3-rc2/tools/perf/util/parse-regs-options.c:38: undefined > > reference to `sample_reg_masks' > > collect2: error: ld returned 1 exit status > > --->8- > > > > Any chance for this to be discussed any further? > > Also (with 4.3-rc2) on PA-RISC, PowerPC and SPARC the same errors are > seen. 4.2 builds fine. Any chance to take a look at this issue? It's already 4.3-rc3 so it would be nice to get some fix to try so there will be time to make sure that new fix doesn't break stuff for other arches. Regards, Alexey
Re: [PATCH v5 2/5] soc: sunxi: Add driver for Allwinner Reduced Serial Bus
Hi, On Thu, Oct 01, 2015 at 07:57:48PM +0800, Chen-Yu Tsai wrote: > Reduced Serial Bus (RSB) is an Allwinner proprietery interface > used to communicate with PMICs and other peripheral ICs. > > RSB is a two-wire push-pull serial bus that supports 1 master > device and up to 15 active slave devices. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH RESEND 0/6] staging: dgnc: checkpatch cleanups
Resending after rebasing on current staging-testing tree. Few patches of the original series are already applied only these checkpatch related patches did not apply due to other changes. regards sudip Sudip Mukherjee (6): staging: dgnc: remove multiple blank lines staging: dgnc: remove blankline before brace staging: dgnc: remove blankline after brace staging: dgnc: remove space after cast staging: dgnc: alignment style staging: dgnc: remove parenthesis drivers/staging/dgnc/dgnc_cls.c| 31 -- drivers/staging/dgnc/dgnc_driver.c | 23 ++-- drivers/staging/dgnc/dgnc_mgmt.c | 13 +--- drivers/staging/dgnc/dgnc_neo.c| 65 +++- drivers/staging/dgnc/dgnc_sysfs.c | 86 --- drivers/staging/dgnc/dgnc_tty.c| 118 - 6 files changed, 75 insertions(+), 261 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 1/6] staging: dgnc: remove multiple blank lines
checkpatch warns us about multiple blank lines which are not needed.
Remove them.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/dgnc/dgnc_driver.c | 10
drivers/staging/dgnc/dgnc_mgmt.c | 5
drivers/staging/dgnc/dgnc_neo.c| 37 ---
drivers/staging/dgnc/dgnc_sysfs.c | 37 ---
drivers/staging/dgnc/dgnc_tty.c| 51 --
5 files changed, 140 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index ce2d1c7..926808b 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -13,7 +13,6 @@
* PURPOSE. See the GNU General Public License for more details.
*/
-
#include
#include
#include
@@ -56,7 +55,6 @@ static const struct file_operations dgnc_BoardFops = {
.release= dgnc_mgmt_close
};
-
/*
* Globals
*/
@@ -79,7 +77,6 @@ static ulong dgnc_poll_time; /* Time of next poll */
static uintdgnc_poll_stop; /* Used to tell poller to stop */
static struct timer_list dgnc_poll_timer;
-
static const struct pci_device_id dgnc_pci_tbl[] = {
{PCI_DEVICE(DIGI_VID, PCI_DEVICE_CLASSIC_4_DID), .driver_data = 0},
{PCI_DEVICE(DIGI_VID, PCI_DEVICE_CLASSIC_4_422_DID), .driver_data = 1},
@@ -354,13 +351,11 @@ static void dgnc_cleanup_board(struct dgnc_board *brd)
}
}
-
dgnc_Board[brd->boardnum] = NULL;
kfree(brd);
}
-
/*
* dgnc_found_board()
*
@@ -421,7 +416,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
pci_irq = pdev->irq;
brd->irq = pci_irq;
-
switch (brd->device) {
case PCI_DEVICE_CLASSIC_4_DID:
@@ -441,7 +435,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
* 4Memory Mapped UARTs and Status
*/
-
/* get the PCI Base Address Registers */
brd->membase = pci_resource_start(pdev, 4);
@@ -482,7 +475,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
break;
-
case PCI_DEVICE_NEO_4_DID:
case PCI_DEVICE_NEO_8_DID:
case PCI_DEVICE_NEO_2DB9_DID:
@@ -592,7 +584,6 @@ failed:
}
-
static int dgnc_finalize_board_init(struct dgnc_board *brd)
{
int rc = 0;
@@ -627,7 +618,6 @@ static void dgnc_do_remap(struct dgnc_board *brd)
brd->re_map_membase = ioremap(brd->membase, 0x1000);
}
-
/*
*
* Function:
diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index 81c793a..81f0da2 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -32,11 +32,9 @@
#include "dgnc_pci.h"
#include "dgnc_mgmt.h"
-
/* Our "in use" variables, to enforce 1 open only */
static int dgnc_mgmt_in_use[MAXMGMTDEVICES];
-
/*
* dgnc_mgmt_open()
*
@@ -67,7 +65,6 @@ int dgnc_mgmt_open(struct inode *inode, struct file *file)
return 0;
}
-
/*
* dgnc_mgmt_close()
*
@@ -90,7 +87,6 @@ int dgnc_mgmt_close(struct inode *inode, struct file *file)
return 0;
}
-
/*
* dgnc_mgmt_ioctl()
*
@@ -256,7 +252,6 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
break;
}
-
}
return 0;
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 900e3ae..09d3de7 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -13,7 +13,6 @@
* PURPOSE. See the GNU General Public License for more details.
*/
-
#include
#include/* For jiffies, task states */
#include /* For tasklet and interrupt structs/defines */
@@ -57,7 +56,6 @@ static uint neo_get_uart_bytes_left(struct channel_t *ch);
static void neo_send_immediate_char(struct channel_t *ch, unsigned char c);
static irqreturn_t neo_intr(int irq, void *voidbrd);
-
struct board_ops dgnc_neo_ops = {
.tasklet = neo_tasklet,
.intr = neo_intr,
@@ -81,7 +79,6 @@ struct board_ops dgnc_neo_ops = {
static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40,
0x80 };
-
/*
* This function allows calls to ensure that all outstanding
* PCI writes have been completed, by doing a PCI read against
@@ -100,7 +97,6 @@ static inline void neo_set_cts_flow_control(struct channel_t
*ch)
unsigned char ier = readb(&ch->ch_neo_uart->ier);
unsigned char efr = readb(&ch->ch_neo_uart->efr);
-
/* Turn on auto CTS flow control */
#if 1
ier |= UART_17158_IER_CTSDSR;
@@ -131,7 +127,6 @@ static inline void neo_set_cts_flow_control(struct
channel_t *ch)
neo_pci_posting_flush(ch->ch_bd);
}
-
static inline void neo_set_rts_flow_control(struct channel_t *ch)
{
unsigned char
[PATCH RESEND 4/6] staging: dgnc: remove space after cast
Space is not necessary after typecast.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/dgnc/dgnc_cls.c| 6 +++---
drivers/staging/dgnc/dgnc_driver.c | 6 +++---
drivers/staging/dgnc/dgnc_mgmt.c | 6 +++---
drivers/staging/dgnc/dgnc_neo.c| 12 ++--
drivers/staging/dgnc/dgnc_tty.c| 24
5 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index 5a35808..50fe22b 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -438,7 +438,7 @@ static void cls_param(struct tty_struct *tty)
if (!tty || tty->magic != TTY_MAGIC)
return;
- un = (struct un_t *) tty->driver_data;
+ un = (struct un_t *)tty->driver_data;
if (!un || un->magic != DGNC_UNIT_MAGIC)
return;
@@ -676,7 +676,7 @@ static void cls_param(struct tty_struct *tty)
*/
static void cls_tasklet(unsigned long data)
{
- struct dgnc_board *bd = (struct dgnc_board *) data;
+ struct dgnc_board *bd = (struct dgnc_board *)data;
struct channel_t *ch;
unsigned long flags;
int i;
@@ -904,7 +904,7 @@ static int cls_drain(struct tty_struct *tty, uint seconds)
if (!tty || tty->magic != TTY_MAGIC)
return -ENXIO;
- un = (struct un_t *) tty->driver_data;
+ un = (struct un_t *)tty->driver_data;
if (!un || un->magic != DGNC_UNIT_MAGIC)
return -ENXIO;
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index fc3eff9..033 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -452,7 +452,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->iobase = pci_resource_start(pdev, 1);
brd->iobase_end = pci_resource_end(pdev, 1);
- brd->iobase = ((unsigned int) (brd->iobase)) & 0xFFFE;
+ brd->iobase = ((unsigned int)(brd->iobase)) & 0xFFFE;
/* Assign the board_ops struct */
brd->bd_ops = &dgnc_cls_ops;
@@ -559,7 +559,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
/* init our poll helper tasklet */
tasklet_init(&brd->helper_tasklet,
brd->bd_ops->tasklet,
-(unsigned long) brd);
+(unsigned long)brd);
spin_lock_irqsave(&dgnc_global_lock, flags);
brd->msgbuf = NULL;
@@ -672,7 +672,7 @@ static void dgnc_poll_handler(ulong dummy)
new_time = dgnc_poll_time - jiffies;
- if ((ulong) new_time >= 2 * dgnc_poll_tick)
+ if ((ulong)new_time >= 2 * dgnc_poll_tick)
dgnc_poll_time = jiffies + dgnc_jiffies_from_ms(dgnc_poll_tick);
setup_timer(&dgnc_poll_timer, dgnc_poll_handler, 0);
diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index 5f46e69..9ec3efe 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -96,7 +96,7 @@ int dgnc_mgmt_close(struct inode *inode, struct file *file)
long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
unsigned long flags;
- void __user *uarg = (void __user *) arg;
+ void __user *uarg = (void __user *)arg;
switch (cmd) {
case DIGI_GETDD:
@@ -142,8 +142,8 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
di.info_bdtype = dgnc_Board[brd]->dpatype;
di.info_bdstate = dgnc_Board[brd]->dpastatus;
di.info_ioport = 0;
- di.info_physaddr = (ulong) dgnc_Board[brd]->membase;
- di.info_physsize = (ulong) dgnc_Board[brd]->membase
+ di.info_physaddr = (ulong)dgnc_Board[brd]->membase;
+ di.info_physsize = (ulong)dgnc_Board[brd]->membase
- dgnc_Board[brd]->membase_end;
if (dgnc_Board[brd]->state != BOARD_FAILED)
di.info_nports = dgnc_Board[brd]->nasync;
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 3dd7342..0d7ba53 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -590,7 +590,7 @@ static void neo_param(struct tty_struct *tty)
if (!tty || tty->magic != TTY_MAGIC)
return;
- un = (struct un_t *) tty->driver_data;
+ un = (struct un_t *)tty->driver_data;
if (!un || un->magic != DGNC_UNIT_MAGIC)
return;
@@ -828,7 +828,7 @@ static void neo_param(struct tty_struct *tty)
*/
static void neo_tasklet(unsigned long data)
{
- struct dgnc_board *bd = (struct dgnc_board *) data;
+ struct dgnc_board *bd = (struct dgnc_board *)data;
struct channel_t *ch;
unsigned long flags;
int i;
@@ -1151,7 +1151,7 @@ static void neo_copy_data_from_ua
[PATCH RESEND 3/6] staging: dgnc: remove blankline after brace
Blank lines are not needed after opening braces. checkpatch was giving
us warnings about this.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/dgnc/dgnc_cls.c| 4
drivers/staging/dgnc/dgnc_driver.c | 3 ---
drivers/staging/dgnc/dgnc_mgmt.c | 1 -
drivers/staging/dgnc/dgnc_neo.c| 11 ---
drivers/staging/dgnc/dgnc_tty.c| 11 ---
5 files changed, 30 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index e7c946e..5a35808 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -378,7 +378,6 @@ static inline void cls_parse_isr(struct dgnc_board *brd,
uint port)
/* Here we try to figure out what caused the interrupt to happen */
while (1) {
-
isr = readb(&ch->ch_cls_uart->isr_fcr);
/* Bail if no pending interrupt on port */
@@ -472,7 +471,6 @@ static void cls_param(struct tty_struct *tty)
ch->ch_old_baud = 0;
return;
} else if (ch->ch_custom_speed) {
-
baud = ch->ch_custom_speed;
/* Handle transition from B0 */
if (ch->ch_flags & CH_BAUD0) {
@@ -704,7 +702,6 @@ static void cls_tasklet(unsigned long data)
* If board is ready, parse deeper to see if there is anything to do.
*/
if ((state == BOARD_READY) && (ports > 0)) {
-
/* Loop on each port */
for (i = 0; i < ports; i++) {
ch = bd->channels[i];
@@ -999,7 +996,6 @@ static void cls_copy_data_from_queue_to_uart(struct
channel_t *ch)
n = min(n, qlen);
while (n > 0) {
-
/*
* If RTS Toggle mode is on, turn on RTS now if not already set,
* and make sure we get an event when the data transfer has
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 4bb3e6f..fc3eff9 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -417,7 +417,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->irq = pci_irq;
switch (brd->device) {
-
case PCI_DEVICE_CLASSIC_4_DID:
case PCI_DEVICE_CLASSIC_8_DID:
case PCI_DEVICE_CLASSIC_4_422_DID:
@@ -516,7 +515,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
dgnc_do_remap(brd);
if (brd->re_map_membase) {
-
/* Read and store the dvid after remapping */
brd->dvid = readb(brd->re_map_membase + 0x8D);
@@ -609,7 +607,6 @@ static int dgnc_finalize_board_init(struct dgnc_board *brd)
*/
static void dgnc_do_remap(struct dgnc_board *brd)
{
-
if (!brd || brd->magic != DGNC_BOARD_MAGIC)
return;
diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index e8aaf35..5f46e69 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -99,7 +99,6 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
void __user *uarg = (void __user *) arg;
switch (cmd) {
-
case DIGI_GETDD:
{
/*
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index fb95282..3dd7342 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -320,7 +320,6 @@ static inline void neo_set_no_output_flow_control(struct
channel_t *ch)
/* change UARTs start/stop chars */
static inline void neo_set_new_start_stop_chars(struct channel_t *ch)
{
-
/* if hardware flow control is set, then skip this whole thing */
if (ch->ch_digi.digi_flags & (CTSPACE | RTSPACE) || ch->ch_c_cflag &
CRTSCTS)
return;
@@ -387,7 +386,6 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
/* Here we try to figure out what caused the interrupt to happen */
while (1) {
-
isr = readb(&ch->ch_neo_uart->isr_fcr);
/* Bail if no pending interrupt */
@@ -626,7 +624,6 @@ static void neo_param(struct tty_struct *tty)
return;
} else if (ch->ch_custom_speed) {
-
baud = ch->ch_custom_speed;
/* Handle transition from B0 */
if (ch->ch_flags & CH_BAUD0) {
@@ -954,7 +951,6 @@ static irqreturn_t neo_intr(int irq, void *voidbrd)
/* Loop on each port */
while ((uart_poll & 0xff) != 0) {
-
tmp = uart_poll;
/* Check current port to see if it has interrupt pending */
@@ -977,7 +973,6 @@ static irqreturn_t neo_intr(int irq, void *voidbrd)
/* Switch on type of interrupt we have */
switch (type) {
-
case UART_17158_RXRDY_TIMEOUT:
/*
* RXRDY Time-out is cleared by reading data in the
@@ -1141
[PATCH RESEND 5/6] staging: dgnc: alignment style
checkpatch was warning us that the alignment should match the open
parenthesis.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/dgnc/dgnc_cls.c| 14 +++---
drivers/staging/dgnc/dgnc_driver.c | 2 +-
drivers/staging/dgnc/dgnc_neo.c| 2 +-
drivers/staging/dgnc/dgnc_tty.c| 26 +-
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index 50fe22b..75040da 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -518,7 +518,7 @@ static void cls_param(struct tty_struct *tty)
* unit is NOT open
*/
if (!(ch->ch_tun.un_flags & UN_ISOPEN) &&
-(un->un_type == DGNC_PRINT))
+ (un->un_type == DGNC_PRINT))
baud = C_BAUD(ch->ch_pun.un_tty) & 0xff;
else
baud = C_BAUD(ch->ch_tun.un_tty) & 0xff;
@@ -532,7 +532,7 @@ static void cls_param(struct tty_struct *tty)
jindex = baud;
if ((iindex >= 0) && (iindex < 4) && (jindex >= 0) &&
- (jindex < 16)) {
+ (jindex < 16)) {
baud = bauds[iindex][jindex];
} else {
baud = 0;
@@ -641,7 +641,7 @@ static void cls_param(struct tty_struct *tty)
* disable flow control
*/
if ((ch->ch_startc == _POSIX_VDISABLE) ||
-(ch->ch_stopc == _POSIX_VDISABLE))
+ (ch->ch_stopc == _POSIX_VDISABLE))
cls_set_no_output_flow_control(ch);
else
cls_set_ixon_flow_control(ch);
@@ -657,7 +657,7 @@ static void cls_param(struct tty_struct *tty)
* flow control
*/
if ((ch->ch_startc == _POSIX_VDISABLE) ||
- (ch->ch_stopc == _POSIX_VDISABLE))
+ (ch->ch_stopc == _POSIX_VDISABLE))
cls_set_no_input_flow_control(ch);
else
cls_set_ixoff_flow_control(ch);
@@ -933,7 +933,7 @@ static void cls_flush_uart_write(struct channel_t *ch)
return;
writeb((UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_XMIT),
- &ch->ch_cls_uart->isr_fcr);
+ &ch->ch_cls_uart->isr_fcr);
udelay(10);
ch->ch_flags |= (CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
@@ -979,7 +979,7 @@ static void cls_copy_data_from_queue_to_uart(struct
channel_t *ch)
/* If port is "stopped", don't send any data to the UART */
if ((ch->ch_flags & CH_FORCED_STOP) ||
-(ch->ch_flags & CH_BREAK_SENDING))
+ (ch->ch_flags & CH_BREAK_SENDING))
goto exit_unlock;
if (!(ch->ch_flags & (CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM)))
@@ -1169,7 +1169,7 @@ static void cls_uart_init(struct channel_t *ch)
readb(&ch->ch_cls_uart->txrx);
writeb((UART_FCR_ENABLE_FIFO|UART_FCR_CLEAR_RCVR|UART_FCR_CLEAR_XMIT),
-&ch->ch_cls_uart->isr_fcr);
+ &ch->ch_cls_uart->isr_fcr);
udelay(10);
ch->ch_flags |= (CH_FIFO_ENABLED | CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 033..619baa9 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -237,7 +237,7 @@ static int dgnc_start(void)
}
dev = device_create(dgnc_class, NULL,
- MKDEV(dgnc_Major, 0),
+ MKDEV(dgnc_Major, 0),
NULL, "dgnc_mgmt");
if (IS_ERR(dev)) {
rc = PTR_ERR(dev);
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 0d7ba53..99287bb 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1390,7 +1390,7 @@ static void neo_copy_data_from_queue_to_uart(struct
channel_t *ch)
/* If port is "stopped", don't send any data to the UART */
if ((ch->ch_flags & CH_FORCED_STOP) ||
-(ch->ch_flags & CH_BREAK_SENDING))
+ (ch->ch_flags & CH_BREAK_SENDING))
goto exit_unlock;
/*
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 6c71a2f..18f0dae 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -365,12 +365,12 @@ int dgnc_tty_init(struct dgnc_board *brd)
struct device *classp;
classp = tty_register_device(&brd->SerialDriver, i,
- &(ch->ch_bd->pdev->dev));
+
[PATCH RESEND 6/6] staging: dgnc: remove parenthesis
checkpatch was warning us about extra unneeded parenthesis.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/dgnc/dgnc_neo.c | 2 +-
drivers/staging/dgnc/dgnc_sysfs.c | 48 +++
drivers/staging/dgnc/dgnc_tty.c | 14 ++--
3 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 99287bb..8106f52 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1792,6 +1792,6 @@ static void neo_vpd(struct dgnc_board *brd)
/* Search for the serial number */
for (i = 0; i < NEO_VPD_IMAGEBYTES - 3; i++)
if (brd->vpd[i] == 'S' && brd->vpd[i + 1] == 'N')
- strncpy(brd->serial_num, &(brd->vpd[i + 3]), 9);
+ strncpy(brd->serial_num, &brd->vpd[i + 3], 9);
}
}
diff --git a/drivers/staging/dgnc/dgnc_sysfs.c
b/drivers/staging/dgnc/dgnc_sysfs.c
index dffb4af..74a0725 100644
--- a/drivers/staging/dgnc/dgnc_sysfs.c
+++ b/drivers/staging/dgnc/dgnc_sysfs.c
@@ -343,18 +343,18 @@ void dgnc_create_ports_sysfiles(struct dgnc_board *bd)
int rc = 0;
dev_set_drvdata(&bd->pdev->dev, bd);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_state);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_baud);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_msignals);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_iflag);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_cflag);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_oflag);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_lflag);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_digi_flag);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_rxcount);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_ports_txcount);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_vpd);
- rc |= device_create_file(&(bd->pdev->dev), &dev_attr_serial_number);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_state);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_baud);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_msignals);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_iflag);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_cflag);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_oflag);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_lflag);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_digi_flag);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_rxcount);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_ports_txcount);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_vpd);
+ rc |= device_create_file(&bd->pdev->dev, &dev_attr_serial_number);
if (rc)
dev_err(&bd->pdev->dev, "dgnc: sysfs device_create_file
failed!\n");
}
@@ -362,18 +362,18 @@ void dgnc_create_ports_sysfiles(struct dgnc_board *bd)
/* removes all the sys files created for that port */
void dgnc_remove_ports_sysfiles(struct dgnc_board *bd)
{
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_state);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_baud);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_msignals);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_iflag);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_cflag);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_oflag);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_lflag);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_digi_flag);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_rxcount);
- device_remove_file(&(bd->pdev->dev), &dev_attr_ports_txcount);
- device_remove_file(&(bd->pdev->dev), &dev_attr_vpd);
- device_remove_file(&(bd->pdev->dev), &dev_attr_serial_number);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_state);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_baud);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_msignals);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_iflag);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_cflag);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_oflag);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_lflag);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_digi_flag);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_rxcount);
+ device_remove_file(&bd->pdev->dev, &dev_attr_ports_txcount);
+ device_remove_file(&bd->pdev->dev, &dev_attr_vpd);
+ device_remove_file(&bd->pdev->dev, &dev_attr_serial_number);
}
[PATCH RESEND 2/6] staging: dgnc: remove blankline before brace
Blank lines are not needed before closing braces. checkpatch was giving warning about this. Signed-off-by: Sudip Mukherjee --- drivers/staging/dgnc/dgnc_cls.c| 7 --- drivers/staging/dgnc/dgnc_driver.c | 2 -- drivers/staging/dgnc/dgnc_mgmt.c | 1 - drivers/staging/dgnc/dgnc_neo.c| 1 - drivers/staging/dgnc/dgnc_sysfs.c | 1 - drivers/staging/dgnc/dgnc_tty.c| 4 6 files changed, 16 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c index 944982a..e7c946e 100644 --- a/drivers/staging/dgnc/dgnc_cls.c +++ b/drivers/staging/dgnc/dgnc_cls.c @@ -115,7 +115,6 @@ static inline void cls_set_cts_flow_control(struct channel_t *ch) &ch->ch_cls_uart->isr_fcr); ch->ch_t_tlevel = 16; - } static inline void cls_set_ixon_flow_control(struct channel_t *ch) @@ -161,7 +160,6 @@ static inline void cls_set_ixon_flow_control(struct channel_t *ch) writeb((UART_FCR_ENABLE_FIFO | UART_16654_FCR_RXTRIGGER_16 | UART_16654_FCR_TXTRIGGER_16 | UART_FCR_CLEAR_RCVR), &ch->ch_cls_uart->isr_fcr); - } static inline void cls_set_no_output_flow_control(struct channel_t *ch) @@ -205,7 +203,6 @@ static inline void cls_set_no_output_flow_control(struct channel_t *ch) ch->ch_r_watermark = 0; ch->ch_t_tlevel = 16; ch->ch_r_tlevel = 16; - } static inline void cls_set_rts_flow_control(struct channel_t *ch) @@ -244,7 +241,6 @@ static inline void cls_set_rts_flow_control(struct channel_t *ch) ch->ch_r_watermark = 4; ch->ch_r_tlevel = 8; - } static inline void cls_set_ixoff_flow_control(struct channel_t *ch) @@ -286,7 +282,6 @@ static inline void cls_set_ixoff_flow_control(struct channel_t *ch) writeb((UART_FCR_ENABLE_FIFO | UART_16654_FCR_RXTRIGGER_16 | UART_16654_FCR_TXTRIGGER_16 | UART_FCR_CLEAR_RCVR), &ch->ch_cls_uart->isr_fcr); - } static inline void cls_set_no_input_flow_control(struct channel_t *ch) @@ -325,7 +320,6 @@ static inline void cls_set_no_input_flow_control(struct channel_t *ch) ch->ch_t_tlevel = 16; ch->ch_r_tlevel = 16; - } /* @@ -746,7 +740,6 @@ static void cls_tasklet(unsigned long data) } spin_unlock_irqrestore(&bd->bd_intr_lock, flags); - } /* diff --git a/drivers/staging/dgnc/dgnc_driver.c b/drivers/staging/dgnc/dgnc_driver.c index 926808b..4bb3e6f 100644 --- a/drivers/staging/dgnc/dgnc_driver.c +++ b/drivers/staging/dgnc/dgnc_driver.c @@ -529,7 +529,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id) dev_err(&brd->pdev->dev, "Didn't find any compatible Neo/Classic PCI boards.\n"); return -ENXIO; - } /* @@ -581,7 +580,6 @@ failed: brd->dpastatus = BD_NOFEP; return -ENXIO; - } static int dgnc_finalize_board_init(struct dgnc_board *brd) diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c index 81f0da2..e8aaf35 100644 --- a/drivers/staging/dgnc/dgnc_mgmt.c +++ b/drivers/staging/dgnc/dgnc_mgmt.c @@ -251,7 +251,6 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, unsigned long arg) break; } - } return 0; diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c index 09d3de7..fb95282 100644 --- a/drivers/staging/dgnc/dgnc_neo.c +++ b/drivers/staging/dgnc/dgnc_neo.c @@ -901,7 +901,6 @@ static void neo_tasklet(unsigned long data) /* Allow interrupt routine to access the interrupt register again */ spin_unlock_irqrestore(&bd->bd_intr_lock, flags); - } /* diff --git a/drivers/staging/dgnc/dgnc_sysfs.c b/drivers/staging/dgnc/dgnc_sysfs.c index c8a6c28..dffb4af 100644 --- a/drivers/staging/dgnc/dgnc_sysfs.c +++ b/drivers/staging/dgnc/dgnc_sysfs.c @@ -695,7 +695,6 @@ void dgnc_create_tty_sysfs(struct un_t *un, struct device *c) } dev_set_drvdata(c, un); - } void dgnc_remove_tty_sysfs(struct device *c) diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c index 497e1f4..ddf0e41 100644 --- a/drivers/staging/dgnc/dgnc_tty.c +++ b/drivers/staging/dgnc/dgnc_tty.c @@ -374,7 +374,6 @@ int dgnc_tty_init(struct dgnc_board *brd) ch->ch_pun.un_sysfs = classp; dgnc_create_tty_sysfs(&ch->ch_pun, classp); } - } return 0; @@ -1368,7 +1367,6 @@ static void dgnc_tty_hangup(struct tty_struct *tty) /* flush the transmit queues */ dgnc_tty_flush_buffer(tty); - } /* @@ -1981,7 +1979,6 @@ static int dgnc_tty_send_break(struct tty_struct *tty, int msec) spin_unlock_irqrestore(&ch->ch_lock, flags); return 0; - } /* @@ -2744,7 +2741,6 @@ static int dgnc_tty_ioctl(struct tty_struct *tty, unsigned int cmd, ~(UN_LOW|UN_EMPTY);
[PATCH v2] staging: iio: adc: fix comment block coding style issue
This patch to ad7746.c makes the comment blocks end with a */
on a separate line, and start with a /* on an empty line.
Signed-off-by: Hugo Camboulive
---
drivers/staging/iio/cdc/ad7746.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 10fa372..e8eab25 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -528,10 +528,11 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
goto out;
}
- /* CAPDAC Scale = 21pF_typ / 127
+ /*
+* CAPDAC Scale = 21pF_typ / 127
* CIN Scale = 8.192pF / 2^24
* Offset Scale = CAPDAC Scale / CIN Scale = 338646
-* */
+*/
val /= 338646;
@@ -600,7 +601,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
switch (chan->type) {
case IIO_TEMP:
- /* temperature in milli degrees Celsius
+ /*
+* temperature in milli degrees Celsius
* T = ((*val / 2048) - 4096) * 1000
*/
*val = (*val * 125) / 256;
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm64: Introduce IRQ stack
On Oct 3, 2015, at 1:23 AM, James Morse wrote: > Hi, Hi James, > > On 22/09/15 13:11, Jungseok Lee wrote: >> Currently, kernel context and interrupts are handled using a single >> kernel stack navigated by sp_el1. This forces a system to use 16KB >> stack, not 8KB one. This restriction makes low memory platforms suffer >> from memory pressure accompanied by performance degradation. >> >> This patch addresses the issue as introducing a separate percpu IRQ >> stack to handle both hard and soft interrupts with two ground rules: >> >> - Utilize sp_el0 in EL1 context, which is not used currently >> - Do not complicate current_thread_info calculation >> >> It is a core concept to directly retrieve struct thread_info from >> sp_el0. This approach helps to prevent text section size from being >> increased largely as removing masking operation using THREAD_SIZE >> in tons of places. > > One observed change in behaviour: > Any stack-unwinding now stops at el1_irq(), which is the bottom of the irq > stack. This shows up with perf (using incantation [0]), and with any calls > to dump_stack() (which actually stops the frame before el1_irq()). > > I don't know if this will break something, (perf still seems to work) - but > it makes the panic() output less useful, as all the 'other' cpus print: Agreed. A process stack should be walked to deliver useful information. There are two approaches I've tried as experimental. 1) Link IRQ stack to a process one via frame pointer As saving x29 and elr_el1 into IRQ stack and then updating x29, IRQ stack could be linked to a process one. It is similar to your patch except some points. However, it might complicate "stack tracer on ftrace" issue. 2) Walk a process stack followed by IRQ one This idea, which is straightforward, comes from x86 implementation [1]. The approach might be orthogonal to "stack tracer on ftrace" issue. In this case, unfortunately, a top bit comparison of stack pointer cannot be adopted due to a necessity of a final snapshot of a process stack pointer, which is struct irq_stack::thread_sp in v2 patch. Which one is your favorite? or any ideas? BTW, I have another question. Is it reasonable to introduce THREAD_SIZE as a kernel configuration option like page size for the sake of convenience because a combination of ARM64 and a small ram is not unusual in real practice? Needless to say, a patch, reducing the size, can be managed as out of mainline tree one. [1] arch/x86/kernel/dumpstack_64.c Best Regards Jungseok Lee-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] scsi: drop unlikely behind BUG_ON()
On 10/03/15 23:18, Geliang Tang wrote: BUG_ON() already contain an unlikely compiler flag. Drop it. Signed-off-by: Geliang Tang Reviewed-by: Bart Van Assche -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: iio: meter: Use devm functions
On 04/10/15 13:43, Shraddha Barke wrote:
>
>
> On Sun, 4 Oct 2015, Jonathan Cameron wrote:
>
>> On 04/10/15 05:34, Shraddha Barke wrote:
>>> Introduce use of managed resource function devm_iio_trigger_alloc
>>> instead of iio_trigger_alloc and devm_request_irq instead of request_irq
>>> Remove corresponding calls to iio_trigger_free and free_irq in the probe
>>> and remove functions.
>>> The now unnecessary labels error_free_trig and err_free_irq are dropped.
>>>
>>> Signed-off-by: Shraddha Barke
>>> ---
>>>
>>> drivers/staging/iio/meter/ade7758_trigger.c | 26 ++
>>> 1 file changed, 10 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/meter/ade7758_trigger.c
>>> b/drivers/staging/iio/meter/ade7758_trigger.c
>>> index 5b35a7f..e313b37 100644
>>> --- a/drivers/staging/iio/meter/ade7758_trigger.c
>>> +++ b/drivers/staging/iio/meter/ade7758_trigger.c
>>> @@ -63,21 +63,21 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
>>> struct ade7758_state *st = iio_priv(indio_dev);
>>> int ret;
>>>
>>> -st->trig = iio_trigger_alloc("%s-dev%d",
>>> -spi_get_device_id(st->us)->name,
>>> -indio_dev->id);
>>> +st->trig = devm_iio_trigger_alloc(&indio_dev->id, "%s-dev%d",
>>> + spi_get_device_id(st->us)->name,
>>> + indio_dev->id);
>>> if (!st->trig) {
>>> ret = -ENOMEM;
>>> goto error_ret;
>>> }
>>>
>>> -ret = request_irq(st->us->irq,
>>> - ade7758_data_rdy_trig_poll,
>>> - IRQF_TRIGGER_LOW,
>>> - spi_get_device_id(st->us)->name,
>>> - st->trig);
>>> +ret = devm_request_irq(&indio_dev->dev, st->us->irq,
>>> + ade7758_data_rdy_trig_poll,
>>> + IRQF_TRIGGER_LOW,
>>> + spi_get_device_id(st->us)->name,
>>> + st->trig);
>>> if (ret)
>>> -goto error_free_trig;
>>> +goto error_ret
>>>
>>> st->trig->dev.parent = &st->us->dev;
>>> st->trig->ops = &ade7758_trigger_ops;
>>> @@ -87,14 +87,10 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
>>> /* select default trigger */
>>> indio_dev->trig = iio_trigger_get(st->trig);
>>> if (ret)
>>> -goto error_free_irq;
>>> +goto error_ret;
>>>
>>> return 0;
>>>
>>> -error_free_irq:
>>> -free_irq(st->us->irq, st->trig);
>>> -error_free_trig:
>>> -iio_trigger_free(st->trig);
>>> error_ret:
>>> return ret;
>> Whilst you are here, direct returns are preferred when there is no unwinding
>> to do
>> so if you could just return the error from anywhere it does the goto
>> error_ret
>> that would be great!
>
> I was a little skeptical about the change from request_irq to
> devm_request_irq because I'm not sure whether the things that are
> freed by the function are needed by the interrupt handler. Do you think it's
> correct?
Good point. It's a dangerous corner as there is a whole load of stuff in the
_core.c file
remove which will move from after to before this call. I'd actually be a bit
dubious about
using any devm stuff in here without working on that file a touch first.
The st->tx, st->rx allocations could be trivially made devm as well.
(be careful here as there are two lots of rx and tx buffers so that
the other lot can be left intact to do the ring reads nice and quickly
whatever other reads and writes occur).
The unconfigure_ring does a bit more and is the sticky issue.
I'd leave the whole lot as non devm functions as it meets the 'obviously
correct'
requirement and the devm equivalent does not...
Still worth cleaning up those goto error_ret bits though!
Jonathan
>
> Shraddha
>>
>> Thanks,
>>
>> Jonathan
>>> }
>>> @@ -104,6 +100,4 @@ void ade7758_remove_trigger(struct iio_dev *indio_dev)
>>> struct ade7758_state *st = iio_priv(indio_dev);
>>>
>>> iio_trigger_unregister(st->trig);
>>> -free_irq(st->us->irq, st->trig);
>>> -iio_trigger_free(st->trig);
>>> }
>>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] staging: iio: adc: fix comment block coding style issue
On 04/10/15 17:30, Hugo Camboulive wrote:
> This patch to ad7746.c makes the comment blocks end with a */
> on a separate line, and start with a /* on an empty line.
>
> Signed-off-by: Hugo Camboulive
Thanks.
Applied to the togreg branch of iio.git - initially pushed out
as staging for the automated build testing to check it.
(obviously not really going to do much with this patch!)
Probably a good few more of these in the staging drivers if
you want to clear out a few more!
If not, take a look at the review I did of this driver the other
day for other bits that could do with cleaning up.
http://marc.info/?l=linux-iio&m=144277958123939&w=2
> ---
> drivers/staging/iio/cdc/ad7746.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/iio/cdc/ad7746.c
> b/drivers/staging/iio/cdc/ad7746.c
> index 10fa372..e8eab25 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -528,10 +528,11 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
> goto out;
> }
>
> - /* CAPDAC Scale = 21pF_typ / 127
> + /*
> + * CAPDAC Scale = 21pF_typ / 127
>* CIN Scale = 8.192pF / 2^24
>* Offset Scale = CAPDAC Scale / CIN Scale = 338646
> - * */
> + */
>
> val /= 338646;
>
> @@ -600,7 +601,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
>
> switch (chan->type) {
> case IIO_TEMP:
> - /* temperature in milli degrees Celsius
> + /*
> + * temperature in milli degrees Celsius
>* T = ((*val / 2048) - 4096) * 1000
>*/
> *val = (*val * 125) / 256;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] nvmem: sunxi: Check for memory allocation failure
On 04/10/15 12:04, Greg KH wrote: On Wed, Sep 30, 2015 at 01:36:31PM +0100, Srinivas Kandagatla wrote: From: Maxime Ripard The sunxi_sid driver doesn't check for kmalloc return status before derefencing the returned pointer, which could lead to a NULL pointer dereference if kmalloc failed. Check for its return code to make sure it deosn't happen. Reported-by: Dan Carpenter Signed-off-by: Maxime Ripard --- drivers/nvmem/sunxi_sid.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) No signed-off-by: from you on this patch? Oops!! My bad I missed the sign-off. Thanks for taking this patch, I will make sure I will recheck this before sending. --srini :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] gpio: Add GPIO support for the ACCES 104-IDIO-16
The ACCES 104-IDIO-16 family of PC/104 utility boards feature 16
optically isolated inputs and 16 optically isolated FET solid state
outputs. This driver provides GPIO support for these 32 channels of
digital I/O. Change-of-State detection interrupts are not supported.
GPIO 0-15 correspond to digital outputs 0-15, while GPIO 16-31
correspond to digital inputs 0-15.
Signed-off-by: William Breathitt Gray
---
Changes in v2:
- Add X86 dependency for CONFIG_GPIO_104_IDIO_16
- Encapsulate container_of macro within static function
drivers/gpio/Kconfig| 15
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-104-idio-16.c | 157
3 files changed, 173 insertions(+)
create mode 100644 drivers/gpio/gpio-104-idio-16.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8949b3f..70b63f1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -684,6 +684,21 @@ config GPIO_SX150X
endmenu
+menu "ISA GPIO expanders"
+
+menuconfig GPIO_104_IDIO_16
+ tristate "ACCES 104-IDIO-16 GPIO support"
+ depends on X86
+ help
+ Enables GPIO support for the ACCES 104-IDIO-16 family.
+
+config 104_IDIO_16_BASE
+ hex "ACCES 104-IDIO-16 base address"
+ depends on GPIO_104_IDIO_16
+ default 0x000
+
+endmenu
+
menu "MFD GPIO expanders"
config GPIO_ADP5520
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..6f2fea5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_ACPI) += gpiolib-acpi.o
# Device drivers. Generally keep list sorted alphabetically
obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
+obj-$(CONFIG_GPIO_104_IDIO_16) += gpio-104-idio-16.o
obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
obj-$(CONFIG_GPIO_74XX_MMIO) += gpio-74xx-mmio.o
obj-$(CONFIG_GPIO_ADNP)+= gpio-adnp.o
diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
new file mode 100644
index 000..be7179f
--- /dev/null
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -0,0 +1,157 @@
+/*
+ * GPIO driver for the ACCES 104-IDIO-16 family
+ * Copyright (C) 2015 William Breathitt Gray
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct a_104_idio_16_gpio {
+ struct gpio_chip chip;
+ spinlock_t lock;
+ unsigned base;
+ unsigned data;
+};
+
+static void __exit a_104_idio_16_exit(void);
+static int a_104_idio_16_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset);
+static int a_104_idio_16_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value);
+static int a_104_idio_16_gpio_get(struct gpio_chip *chip, unsigned offset);
+static void a_104_idio_16_gpio_set(struct gpio_chip *chip, unsigned offset,
+ int value);
+static int __init a_104_idio_16_init(void);
+static struct a_104_idio_16_gpio *to_a104i16gp(struct gpio_chip *gc);
+
+static const unsigned A_104_IDIO_16_EXTENT = 8;
+
+static struct a_104_idio_16_gpio gp = {
+ .chip = {
+ .label = "104-IDIO-16 GPIO",
+ .owner = THIS_MODULE,
+ .base = -1,
+ .ngpio = 32,
+ .direction_input = a_104_idio_16_gpio_direction_input,
+ .direction_output = a_104_idio_16_gpio_direction_output,
+ .get = a_104_idio_16_gpio_get,
+ .set = a_104_idio_16_gpio_set
+ },
+ .base = CONFIG_104_IDIO_16_BASE
+};
+
+static void __exit a_104_idio_16_exit(void)
+{
+ pr_info("104-idio-16: Exiting 104-idio-16 module\n");
+
+ gpiochip_remove(&gp.chip);
+ release_region(CONFIG_104_IDIO_16_BASE, A_104_IDIO_16_EXTENT);
+}
+
+static int a_104_idio_16_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset)
+{
+ return 0;
+}
+
+static int a_104_idio_16_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ chip->set(chip, offset, value);
+ return 0;
+}
+
+static int a_104_idio_16_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct a_104_idio_16_gpio *a104i16gp = to_a104i16gp(chip);
+ const unsigned BIT_MASK = 1U << (offset-16);
+
+ if (offset < 16)
+ return 0;
+
+ if (offset < 24)
+ return !!(inb(a104i16gp->base + 1) & BIT_MASK);
+
+ return !!(inb(a104i16gp->base + 5) & (BIT_MASK>>8));
+}
+
+static void a_104_idio_16_gpio_set(struct gpio_chip *chip, unsigned offset,
+ int
Re: [PATCH] power: print function name of callbacks
On Tue 2015-09-22 10:26:37, Douglas Anderson wrote:
> The printouts writen to the logs by suspend can be a bit opaque: it can
> be hard to track them down to the actual function called. You might
> see:
It seems simple enough.
Acked-by: Pavel Machek
> +static ktime_t initcall_debug_start(struct device *dev, void *cb)
> {
> ktime_t calltime = ktime_set(0, 0);
>
> if (pm_print_times_enabled) {
> - pr_info("calling %s+ @ %i, parent: %s\n",
> + pr_info("calling %s+ @ %i, parent: %s, cb: %pf\n",
> dev_name(dev), task_pid_nr(current),
> - dev->parent ? dev_name(dev->parent) : "none");
> + dev->parent ? dev_name(dev->parent) : "none", cb);
> calltime = ktime_get();
> }
>
> @@ -382,7 +382,7 @@ static int dpm_run_callback(pm_callback_t cb, struct
> device *dev,
> if (!cb)
> return 0;
>
> - calltime = initcall_debug_start(dev);
> + calltime = initcall_debug_start(dev, cb);
>
> pm_dev_dbg(dev, state, info);
> trace_device_pm_callback_start(dev, info, state.event);
> @@ -1324,7 +1324,7 @@ static int legacy_suspend(struct device *dev,
> pm_message_t state,
> int error;
> ktime_t calltime;
>
> - calltime = initcall_debug_start(dev);
> + calltime = initcall_debug_start(dev, cb);
>
> trace_device_pm_callback_start(dev, info, state.event);
> error = cb(dev, state);
> --
> 2.6.0.rc0.131.gf624c3d
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.3-rc0: snd_hda_intel 0000:00:1b.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
On Tue 2015-09-08 23:05:35, Takashi Iwai wrote: > On Tue, 08 Sep 2015 22:52:02 +0200, > Pavel Machek wrote: > > > > Hi! > > > > On something like 4c12ab7e5e2e892fa94df500f96001837918a281 ... I got > > > > [ 6078.393375] snd_hda_intel :00:1b.0: IRQ timing workaround is > > activated for card #0. Suggest a bigger bdl_pos_adj. > > > > ...and now sound does not play any more. Never seen the message before > > (but I did not search for it too actively), and sound usually worked > > before... > > > > Any ideas? > > The message itself is mostly harmless, as the symptom is found on > pretty many devices. I have no idea for now. Could you try > bisection? It did not happen again... so hopefully newer -rcs solved that. Pavel (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [v4] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map
Hi! > > > > 3) I'm not sure I understand the changelog correctly. What happens > > > > when BIOS reports less memory on hibernation? Will you magically > > > > remove memory from kernel at runtime? Will /proc/meminfo be invalid > > after resume? > > > > Will all the memory management tuning need fixing? > > > > > > > Oh, I did not notice it before. So deleting the logic of ' > > > info->num_physpages != get_num_physpages()' is not suitable. > > > The subset relationship should not be considered in this patch. > > > > Ok. So... if you really want, you can add some messages like "hey, this is > > bios > > bug, maybe updating bios is a good idea".. but please lets keep the original > > logic. > > > OK. I see, I'll not change its original code. > So can I add a function here that checks if current BIOS e820 map is > strictly the same as it was before S4? If it is not the same, we will print > some warnnings > , and if we panic later, we will print that , the panic reason might be due > to broken BIOS. > I think I can archive this by putting the e820_saved array into struct > swsusp_info, > and pass it to second kernel: > struct swsusp_info will always occupy one page size, and has a lot of extra > space left, > meanwhile the total size of e820 map will not exceed the PAGE_SIZE currently, > it's safe > to put it in struct swsusp_info. > > And this does not need much changing of current code. What do you think? > Thanks. Can we simply add explanation printk() before the panic(), without any other changes? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM/hibernate: fix a comment typo
On Tue 2015-09-29 20:36:58, Geliang Tang wrote: > Just fix a typo in a function name in kerneldoc comments. > > Signed-off-by: Geliang Tang Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
Hi! > > > > > >> > This suggests we forget about power/wakeup == "off" and introduce an > > >> > "inhibit" attribute instead. > > >> > > >> If we do that, can it still be regarded as a PM attribute? > > > > > > Why not? Consider this: Is there any reason to support inhibit when > > > CONFIG_PM is disabled? I can't come up with any. > > > > Well, the "I don't want any input from you now, because the phone is > > going into a pocket" case? > > But who would make a phone without CONFIG_PM? If you're sufficiently > unconcerned about power usage that you turn off CONFIG_PM, then you > probably don't care about getting excess input events either. Well.. .excess input events means that your phone now sends (meaningful, thanks to advanced predictions) messages to your friends... Better not do that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
