Re: [PATCH 2/2] mmc: sunxi: Also set SDXC_LOW_POWER_ON
Hi, On 24-05-15 20:04, Michal Suchanek wrote: The function sunxi_mmc_oclk_onoff filters out the SDXC_LOW_POWER_ON flag but never sets it. Set SDXC_LOW_POWER_ON when oclk is disabled. Nack, looking at the datasheet I do not thing this patch actually does anything, according to the datasheet setting this bit to 1 results in: "Turn off card clock when FSM in IDLE state", iow this does mmc clock gating on idle automatically in hardware, since we completely disable the clock on clock-off by clearing SDXC_CARD_CLOCK_ON setting this bit on clock-off is a nop. We could consider actually setting this to safe power when setting the clock on, for doing that it would be good to look at the android code and see if it ever sets this bit and if so when. WRT CONFIG_MMC_CLKGATE we are probably better off using SDXC_LOW_POWER_ON then that when it is enabled. So maybe we should set SDXC_LOW_POWER_ON based on #ifdef WRT CONFIG_MMC_CLKGATE, and have some way to tell the mmc core to not do clock gating on this host ? Regards, Hans Signed-off-by: Michal Suchanek --- drivers/mmc/host/sunxi-mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c index 7cdeecd..e957888 100644 --- a/drivers/mmc/host/sunxi-mmc.c +++ b/drivers/mmc/host/sunxi-mmc.c @@ -603,6 +603,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en) if (oclk_en) rval |= SDXC_CARD_CLOCK_ON; + else + rval |= SDXC_LOW_POWER_ON; start = jiffies; end = start + msecs_to_jiffies(750); -- 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 20/21] nfit-test: manufactured NFITs for interface development
> -Original Message- > From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On Behalf > Of Dan Williams > Sent: Wednesday, May 20, 2015 3:58 PM > To: ax...@kernel.dk > Subject: [PATCH v3 20/21] nfit-test: manufactured NFITs for interface > development ... Attached is some experimental code to try pmem with different cache types (UC, WB, WC, and WT) and memcpy functions using x86 AVX non-temporal load and store instructions. It depends on Toshi's WT patch series: https://lkml.org/lkml/2015/5/13/866 If you don't have that, you can just comment out the lines related to ioremap_wt. --- Rob Elliott, HP Server Storage 0001-pmem-cache-type Description: 0001-pmem-cache-type
Re: [PATCH v4 06/11] md/raid5: get rid of bio_fits_rdev()
On Sun, May 24, 2015 at 10:48 PM, NeilBrown wrote:
> On Fri, 22 May 2015 11:18:38 -0700 Ming Lin wrote:
>
>> From: Kent Overstreet
>>
>> Remove bio_fits_rdev() completely, because ->merge_bvec_fn() has now
>> gone. There's no point in calling bio_fits_rdev() only for ensuring
>> aligned read from rdev.
>
> Surely this patch should come *before*
> [PATCH v4 07/11] md/raid5: split bio for chunk_aligned_read
PATCH 6, then PATCH 7, isn't it already *before*?
>
> and the comment says ->merge_bvec_fn() has gone, but that isn't until
> [PATCH v4 08/11] block: kill merge_bvec_fn() completely
>
>
> If those issues are resolved, then
How about this?
PATCH 6: md/raid5: split bio for chunk_aligned_read
PATCH 7: block: kill merge_bvec_fn() completely
PATCH 8: md/raid5: get rid of bio_fits_rdev()
Thanks.
>
> Acked-by: NeilBrown
>
> Thanks,
> NeilBrown
>
>
>>
>> Cc: Neil Brown
>> Cc: linux-r...@vger.kernel.org
>> Signed-off-by: Kent Overstreet
>> [dpark: add more description in commit message]
>> Signed-off-by: Dongsu Park
>> Signed-off-by: Ming Lin
>> ---
>> drivers/md/raid5.c | 23 +--
>> 1 file changed, 1 insertion(+), 22 deletions(-)
>>
>> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
>> index 1ba97fd..b303ded 100644
>> --- a/drivers/md/raid5.c
>> +++ b/drivers/md/raid5.c
>> @@ -4743,25 +4743,6 @@ static void raid5_align_endio(struct bio *bi, int
>> error)
>> add_bio_to_retry(raid_bi, conf);
>> }
>>
>> -static int bio_fits_rdev(struct bio *bi)
>> -{
>> - struct request_queue *q = bdev_get_queue(bi->bi_bdev);
>> -
>> - if (bio_sectors(bi) > queue_max_sectors(q))
>> - return 0;
>> - blk_recount_segments(q, bi);
>> - if (bi->bi_phys_segments > queue_max_segments(q))
>> - return 0;
>> -
>> - if (q->merge_bvec_fn)
>> - /* it's too hard to apply the merge_bvec_fn at this stage,
>> - * just just give up
>> - */
>> - return 0;
>> -
>> - return 1;
>> -}
>> -
>> static int chunk_aligned_read(struct mddev *mddev, struct bio * raid_bio)
>> {
>> struct r5conf *conf = mddev->private;
>> @@ -4815,11 +4796,9 @@ static int chunk_aligned_read(struct mddev *mddev,
>> struct bio * raid_bio)
>> align_bi->bi_bdev = rdev->bdev;
>> __clear_bit(BIO_SEG_VALID, &align_bi->bi_flags);
>>
>> - if (!bio_fits_rdev(align_bi) ||
>> - is_badblock(rdev, align_bi->bi_iter.bi_sector,
>> + if (is_badblock(rdev, align_bi->bi_iter.bi_sector,
>> bio_sectors(align_bi),
>> &first_bad, &bad_sectors)) {
>> - /* too big in some way, or has a known bad block */
>> bio_put(align_bi);
>> rdev_dec_pending(rdev, mddev);
>> return 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 3/4] drm/tegra: Add VIC support
On 05/22/2015 01:25 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Thu, May 21, 2015 at 05:40:31PM +0300, Mikko Perttunen wrote:
On 05/21/2015 04:20 PM, Arto Merilainen wrote:
[...]
+static int vic_is_addr_reg(struct device *dev, u32 class, u32 offset, u32 val)
+{
+ struct vic *vic = dev_get_drvdata(dev);
+
+ /* handle host class */
+ if (class == HOST1X_CLASS_HOST1X) {
+ if (offset == 0x2b)
+ return true;
+ return false;
"return (offset == 0x2b);" perhaps?
I think this should really be extracted into a separate helper. If we
ever need to take into account additional offsets we would otherwise
have to extend every driver rather than just the helper.
I agree, that would be better.
Also I think the 0x2b should be replaced by some symbolic name.
According to the TRM 0x2b is the host1x class method named
NV_CLASS_HOST_INDCTRL_0. Oddly enough that doesn't seem to be an address
register. Instead the address seems to be in the INDOFF2 and INDOFF
methods (0x2c and 0x2d). I also can't tell from the TRM what exactly
these are supposed to do.
Arto, can you clarify?
This looks like an unfortunate mistake that got reproduced from gr2d and
gr3d.
The INDCTRL method is used for indirect register accessing and it allows
Host1x to read registers of an engine - or write data directly to
memory. It allow implementing context switch for the clients whose state
should be not change between jobs from the same application.
+ if (IS_ERR(vic->rst)) {
+ dev_err(&pdev->dev, "cannot get reset\n");
+ return PTR_ERR(vic->rst);
+ }
+
+ platform_set_drvdata(pdev, vic);
+
+ INIT_LIST_HEAD(&vic->client.base.list);
+ vic->client.base.ops = &vic_client_ops;
+ vic->client.base.dev = dev;
+ vic->client.base.class = vic_config->class_id;
+ vic->client.base.syncpts = syncpts;
+ vic->client.base.num_syncpts = 1;
+ vic->dev = dev;
+ vic->config = vic_config;
+
+ INIT_LIST_HEAD(&vic->client.list);
+ vic->client.ops = &vic_ops;
+
+ err = tegra_powergate_sequence_power_up(vic->config->powergate_id,
+ vic->clk, vic->rst);
+ if (err) {
+ dev_err(dev, "cannot turn on the device\n");
+ return err;
+ }
+
+ err = host1x_client_register(&vic->client.base);
+ if (err < 0) {
You used 'if (err) {' previously, so maybe also here.
For consistency with other Tegra DRM code these checks should use (at
least where possible) the (err < 0) notation.
Will fix.
- Arto
--
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] proc/schedstat: Expose /proc//schedstat if delay accounting is enabled
/proc//schedstat is currently only available if CONFIG_SCHEDSTATS is
enabled. But, all the fields that this exposes are available and valid
if CONFIG_TASK_DELAY_ACCT is enabled as well.
Signed-off-by: Naveen N. Rao
---
fs/proc/base.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 093ca14..3ece303 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -304,14 +304,17 @@ static int proc_pid_stack(struct seq_file *m, struct
pid_namespace *ns,
}
#endif
-#ifdef CONFIG_SCHEDSTATS
+#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
/*
* Provides /proc/PID/schedstat
*/
static int proc_pid_schedstat(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
- seq_printf(m, "%llu %llu %lu\n",
+ if (unlikely(!sched_info_on()))
+ seq_printf(m, "0 0 0\n");
+ else
+ seq_printf(m, "%llu %llu %lu\n",
(unsigned long long)task->se.sum_exec_runtime,
(unsigned long long)task->sched_info.run_delay,
task->sched_info.pcount);
@@ -2600,7 +2603,7 @@ static const struct pid_entry tgid_base_stuff[] = {
#ifdef CONFIG_STACKTRACE
ONE("stack", S_IRUSR, proc_pid_stack),
#endif
-#ifdef CONFIG_SCHEDSTATS
+#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
ONE("schedstat", S_IRUGO, proc_pid_schedstat),
#endif
#ifdef CONFIG_LATENCYTOP
@@ -2948,7 +2951,7 @@ static const struct pid_entry tid_base_stuff[] = {
#ifdef CONFIG_STACKTRACE
ONE("stack", S_IRUSR, proc_pid_stack),
#endif
-#ifdef CONFIG_SCHEDSTATS
+#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
ONE("schedstat", S_IRUGO, proc_pid_schedstat),
#endif
#ifdef CONFIG_LATENCYTOP
--
2.4.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: Device Tree Blob (DTB) licence
On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud wrote: > I've added licens...@fsf.ogrg in Cc: in my previous message to have an > advice on this subject, but I failed to notice licens...@fsf.org > is not a mailing list: I was assigned request ID [gnu.org #1017262]. > > Regards. They're also not an unbiased source. Their job is to reply "you should license it under GPLv3" without actually looking at your message. (This is a slight oversimplification, they may instead recomend the GFDL. They will never _not_ recommend one of their licenses.) Personally, I'm sad we're starting to get ACPI for arm but if device tree data files are only available under GPL, people will hold their nose and deploy ACPI. Rob -- 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] zram: check compressor name before setting it
Hi Sergey,
On 25/05/15 08:18, Sergey Senozhatsky wrote:
On (05/22/15 15:26), Marcin Jabrzyk wrote:
From the other hand, the only valid values that can be written are
in 'comp_algorithm'.
So when writing other one, returning -EINVAL seems to be reasonable.
The user would get immediately information that he can't do that,
now the information can be very deferred in time.
it's not.
the error message appears in syslog right before we return -EINVAL
back to user.
Yes I've read up the code more detailed and I saw that error message
just before returning to user with error value.
But this happens when 'disksize' is wirtten, not when 'comp_algorithm'.
I understood, the error message in dmesg is clear there is no such
algorithm.
But this is not an immediate error, when setting the 'comp_algorithm',
where we already know that it's wrong, not existing etc.
Anything after that moment would be wrong and would not work at all.
From what I saw 'comp_algorithm_store' is the only *_store in zram that
believes user that he writes proper value and just makes strlcpy.
So what I've ing mind is to provide direct feedback, you have
written wrong name of compressor, you got -EINVAL, please write
correct value. This would be very useful when scripting.
I can't see how printing error 0.0012 seconds earlier helps. really.
if one sets a compression algorithm the very next thing to do is to
set device's disksize. even if he/she usually watch a baseball game in
between, then the error message appears right when it's needed anyway:
during `setup my device and make it usable' stage.
I'm not for exposing more internals, but getting -EINVAL would be nice I
you are.
find_backend() returns back to its caller a raw and completely initialized
zcomp_backend pointer. this is very dangerous zcomp internals, which should
never be exposed. from zcomp layer we return either ERR_PTR() or a usable
zcomp_backend pointer. that's the rule.
if you guys still insist that this is critical and very important change,
then there should be a small helper function instead with a clear name
(starting with zcomp_ to indicate its place) which will simply return bool
TRUE for `algorithm is known' case and FALSE otherwise (aka `algorithm is
unknown').
This is exactly the idea I've in my mind, when thinking about much
proper solution.
Simple function that will return bool and just check if name is correct
or not. Without presenting find_backend or anything from zcomp.
something like below:
# echo LZ5 > /sys/block/zram0/comp_algorithm
-bash: echo: write error: Invalid argument
dmesg
[ 7440.544852] Error: unknown compression algorithm: LZ5
p.s. but, I still see a very little value.
p.p.s notice a necessary and inevitable `dmesg'. (back to 'no one reads
syslog' argument).
---
drivers/block/zram/zcomp.c| 10 ++
drivers/block/zram/zcomp.h| 1 +
drivers/block/zram/zram_drv.c | 3 +++
3 files changed, 14 insertions(+)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index a1a8b8e..b68b16f 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -54,11 +54,16 @@ static struct zcomp_backend *backends[] = {
static struct zcomp_backend *find_backend(const char *compress)
{
int i = 0;
+
while (backends[i]) {
if (sysfs_streq(compress, backends[i]->name))
break;
i++;
}
+
+ if (!backends[i])
+ pr_err("Error: unknown compression algorithm: %s\n",
+ compress);
return backends[i];
}
@@ -320,6 +325,11 @@ void zcomp_destroy(struct zcomp *comp)
kfree(comp);
}
+bool zcomp_known_algorithm(const char *comp)
+{
+ return find_backend(comp) != NULL;
+}
+
/*
* search available compressors for requested algorithm.
* allocate new zcomp and initialize it. return compressing
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index c59d1fc..773bdf1 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -51,6 +51,7 @@ struct zcomp {
};
ssize_t zcomp_available_show(const char *comp, char *buf);
+bool zcomp_known_algorithm(const char *comp);
struct zcomp *zcomp_create(const char *comp, int max_strm);
void zcomp_destroy(struct zcomp *comp);
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f750e34..2197a81 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -378,6 +378,9 @@ static ssize_t comp_algorithm_store(struct device *dev,
if (sz > 0 && zram->compressor[sz - 1] == '\n')
zram->compressor[sz - 1] = 0x00;
+ if (!zcomp_known_algorithm(zram->compressor))
+ len = -EINVAL;
+
up_write(&zram->init_lock);
return len;
}
I'm perfectly fine with this solution. It just does what
I'd expect.
Best regards,
Marcin Jabrzyk
--
To unsubscribe from this list: send th
Re: [PATCH] cpufreq:cpufreq-nforce2 - Fix typo in comment to function nforce2_init().
On 23-05-15, 10:36, Shailendra Verma wrote: Always mention something here on why this is required. Even if the subject is good enough :) > Signed-off-by: Shailendra Verma > --- > drivers/cpufreq/cpufreq-nforce2.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/cpufreq-nforce2.c > b/drivers/cpufreq/cpufreq-nforce2.c > index a225809..db69eeb 100644 > --- a/drivers/cpufreq/cpufreq-nforce2.c > +++ b/drivers/cpufreq/cpufreq-nforce2.c > @@ -414,7 +414,7 @@ static int nforce2_detect_chipset(void) > * nforce2_init - initializes the nForce2 CPUFreq driver > * > * Initializes the nForce2 FSB support. Returns -ENODEV on unsupported > - * devices, -EINVAL on problems during initiatization, and zero on > + * devices, -EINVAL on problems during initialization, and zero on > * success. > */ > static int __init nforce2_init(void) Acked-by: Viresh Kumar -- viresh -- 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] cpufreq:gx-suspmod - Fix two typos in two comments.
On 23-05-15, 10:36, Shailendra Verma wrote: > > Signed-off-by: Shailendra Verma > --- > drivers/cpufreq/gx-suspmod.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/cpufreq/gx-suspmod.c b/drivers/cpufreq/gx-suspmod.c > index 1d723dc..3488c9c 100644 > --- a/drivers/cpufreq/gx-suspmod.c > +++ b/drivers/cpufreq/gx-suspmod.c > @@ -144,7 +144,7 @@ module_param(max_duration, int, 0444); > > > /** > - * we can detect a core multipiler from dir0_lsb > + * we can detect a core multiplier from dir0_lsb > * from GX1 datasheet p.56, > * MULT[3:0]: > * = SYSCLK multiplied by 4 (test only) > @@ -346,7 +346,7 @@ static int cpufreq_gx_verify(struct cpufreq_policy > *policy) > > /* it needs to be assured that at least one supported frequency is >* within policy->min and policy->max. If it is not, policy->max > - * needs to be increased until one freuqency is supported. > + * needs to be increased until one frequency is supported. >* policy->min may not be decreased, though. This way we guarantee a >* specific processing capacity. >*/ Acked-by: Viresh Kumar -- viresh -- 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/
linux-next: manual merge of the kvm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kvm/x86.c between commit c447e76b4cab ("kvm/fpu: Enable eager
restore kvm FPU for MPX") from the tree and commit 653f52c316a4
("kvm,x86: load guest FPU context more eagerly") from the kvm tree.
I fixed it up (I used the version from the kvm tree) and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp5pMeHahNTn.pgp
Description: OpenPGP digital signature
[GIT PULL] GPIO fixes for the v4.1 series
Hi Linus, here are two GPIO fixes targeted for stable. Nothing special, a blurb in the signed tag. Please pull this in! Yours, Linus Walleij The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736: Linux 4.1-rc3 (2015-05-10 15:12:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v4.1-3 for you to fetch changes up to f230e8ffc03f17bd9d6b90ea890b8252a8cc1821: gpio: gpio-kempld: Fix get_direction return value (2015-05-12 13:49:13 +0200) GPIO fixes for the v4.1 series: - A leak in gpiochip_add path destined for stable. - A kempld driver bug destined for stable. Johan Hovold (1): gpio: fix gpio leak in gpiochip_add error path Michael Brunner (1): gpio: gpio-kempld: Fix get_direction return value drivers/gpio/gpio-kempld.c | 2 +- drivers/gpio/gpiolib.c | 10 ++ 2 files changed, 7 insertions(+), 5 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/
Re: [PATCH] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.
On 25-05-15, 07:39, Shailendra Verma wrote:
> During probe free the memory allocated to "exynos_info" in case of
> unknown SOC type.
>
> Signed-off-by: Shailendra Verma
> ---
> drivers/cpufreq/exynos-cpufreq.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 82d2fbb..8682378 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -182,7 +182,7 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
> ret = exynos5250_cpufreq_init(exynos_info);
> } else {
> pr_err("%s: Unknown SoC type\n", __func__);
> - return -ENODEV;
> + ret = -ENODEV;
> }
>
> if (ret)
> @@ -190,12 +190,14 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
>
> if (exynos_info->set_freq == NULL) {
> dev_err(&pdev->dev, "No set_freq function (ERR)\n");
> + ret = -EINVAL;
> goto err_vdd_arm;
> }
>
> arm_regulator = regulator_get(NULL, "vdd_arm");
> if (IS_ERR(arm_regulator)) {
> dev_err(&pdev->dev, "failed to get resource vdd_arm\n");
> + ret = -EINVAL;
> goto err_vdd_arm;
> }
>
> @@ -227,7 +229,7 @@ err_cpufreq_reg:
> regulator_put(arm_regulator);
> err_vdd_arm:
> kfree(exynos_info);
> - return -EINVAL;
> + return ret;
> }
>
> static struct platform_driver exynos_cpufreq_platdrv = {
Acked-by: Viresh Kumar
--
viresh
--
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] pin control fixes for the v4.1 kernel cycle
Hi Linus, here are some three pin control fixes for the v4.1 cycle, all driver-specific. Business as usual and calm as it should be in this portion of the merge window. Please pull them in! Yours, Linus Walleij The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736: Linux 4.1-rc3 (2015-05-10 15:12:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v4.1-4 for you to fetch changes up to 984cffdeaeb7ea5a21f49a89f638d84d62d08992: pinctrl: Fix gpio/pin mapping for Meson8b (2015-05-19 11:40:52 +0200) Pin control fixes for the v4.1 kernel cycle: - IRQ trigger fix for the Intel Cherryview. - GPIO-to-pin mapping fix for the Cygnus driver. - GPIO-to-pin mapping fix for the Meson8b driver. Carlo Caione (1): pinctrl: Fix gpio/pin mapping for Meson8b Mika Westerberg (1): pinctrl: cherryview: Read triggering type from HW if not set when requested Ray Jui (1): pinctrl: cygnus: fixed incorrect GPIO-pin mapping drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 4 ++- drivers/pinctrl/intel/pinctrl-cherryview.c | 44 ++ drivers/pinctrl/meson/pinctrl-meson.c | 2 +- drivers/pinctrl/meson/pinctrl-meson8b.c| 4 +-- 4 files changed, 50 insertions(+), 4 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/
Re: [PATCH] zram: check compressor name before setting it
On (05/25/15 09:15), Marcin Jabrzyk wrote: [..] > > > I'm perfectly fine with this solution. It just does what > I'd expect. cool, let's hear from Minchan. btw, if we decide to move on, how do you guys want to route it? do you want Marcin (I don't mind) or me (of course, with the appropriate credit to Marcin) to submit it? -ss -- 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 v3 18/37] bpf tools: Record map accessing instructions for each program
On 2015/5/19 2:34, Alexei Starovoitov wrote:
On 5/17/15 3:56 AM, Wang Nan wrote:
This patch records the indics of instructions which are needed to be
relocated. Those information are saved in 'reloc_desc' field in
'struct bpf_program'. In loading phase (this patch takes effect in
opening phase), the collected instructions will be replaced by
map loading instructions.
Since we are going to close the ELF file and clear all data at the end
of 'opening' phase, ELF information will no longer be valid in
'loading' phase. We have to locate the instructions before maps are
loaded, instead of directly modifying the instruction.
'struct bpf_map_def' is introduce in this patch to let us know how many
maps defined in the object.
Signed-off-by: Wang Nan
...
+/*
+ * packed attribute is unnecessary for 'bpf_map_def'.
+ */
+struct bpf_map_def {
+unsigned int type;
+unsigned int key_size;
+unsigned int value_size;
+unsigned int max_entries;
+};
the comment looks out of place. 'packed' is necessary somewhere else?
What were you concerned about here?
I see a warning message:
make: Entering directory `/home/w00229757/kernel-hydrogen/tools/lib/bpf'
CC libbpf.o
In file included from libbpf.c:23:0:
libbpf.h:31:1: error: packed attribute is unnecessary for
‘bpf_map_def’ [-Werror=packed]
} __attribute__((packed));
^
cc1: all warnings being treated as errors
if I append __attribute__((packed)) here. This is because
Makefile.include in tools/script
as '-Wpacked' warning message and it is inherited by perf. When
compiling with perf this
problem breaks compiling. Therefore I don't use 'packed' here. However I
think there should
be one. This comment is 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: [RFC PATCH v2 03/15] perf bpf: Save pt_regs info from debuginfo
On 2015/5/24 21:31, Masami Hiramatsu wrote:
> On 2015/05/24 17:27, He Kuang wrote:
>> Save reg number in function convert_variable_location() instead of the
>> register string name, so we can fetch the target register from bpf
>> context register later.
>
> This is not needed because you can also get reg number from reg string
> afterwards.
>
> Thank you,
Ok, thanks
>
>>
>> Signed-off-by: He Kuang
>> ---
>> tools/perf/util/include/dwarf-regs.h | 13 +
>> tools/perf/util/probe-event.h| 1 +
>> tools/perf/util/probe-finder.c | 11 +++
>> 3 files changed, 25 insertions(+)
>>
>> diff --git a/tools/perf/util/include/dwarf-regs.h
>> b/tools/perf/util/include/dwarf-regs.h
>> index 8f14965..566ff6d 100644
>> --- a/tools/perf/util/include/dwarf-regs.h
>> +++ b/tools/perf/util/include/dwarf-regs.h
>> @@ -2,7 +2,20 @@
>> #define _PERF_DWARF_REGS_H_
>>
>> #ifdef HAVE_DWARF_SUPPORT
>> +struct arch_regs_info {
>> +const char *name; /* Architecture dependent register string */
>> +int offset; /* Reg offset in struct pt_regs */
>> +int size; /* Reg size */
>> +};
>> +
>> +#define ARCH_REGS_INFO(r, pt_reg_name)
>> \
>> +{.name = r,\
>> +.offset = offsetof(struct pt_regs, pt_reg_name),\
>> +.size = sizeof(((struct pt_regs *)0)->pt_reg_name)} \
>> +
>> const char *get_arch_regstr(unsigned int n);
>> +int get_arch_reg_offset(unsigned int n);
>> +int get_arch_reg_size(unsigned int n);
>> #endif
>>
>> #endif
>> diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
>> index d6b7834..6c19395 100644
>> --- a/tools/perf/util/probe-event.h
>> +++ b/tools/perf/util/probe-event.h
>> @@ -29,6 +29,7 @@ struct probe_trace_arg {
>> char*value; /* Base value */
>> char*type; /* Type name */
>> struct probe_trace_arg_ref *ref; /* Referencing offset */
>> +unsigned intregn; /* Regn from dwarf */
>> };
>>
>> /* kprobe-tracer and uprobe-tracer tracing event (point + arg) */
>> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
>> index ee27b74..681af00 100644
>> --- a/tools/perf/util/probe-finder.c
>> +++ b/tools/perf/util/probe-finder.c
>> @@ -159,6 +159,16 @@ static struct probe_trace_arg_ref
>> *alloc_trace_arg_ref(long offs)
>> return ref;
>> }
>>
>> +int __attribute__ ((weak))
>> +get_arch_reg_offset(unsigned int n __maybe_unused) {
>> +return -1;
>> +}
>> +
>> +int __attribute__ ((weak))
>> +get_arch_reg_size(unsigned int n __maybe_unused) {
>> +return -1;
>> +}
>> +
>> /*
>>* Convert a location into trace_arg.
>>* If tvar == NULL, this just checks variable can be converted.
>> @@ -260,6 +270,7 @@ static_var:
>> return -ERANGE;
>> }
>>
>> +tvar->regn = regn;
>> tvar->value = strdup(regs);
>> if (tvar->value == NULL)
>> return -ENOMEM;
>>
>
>
--
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] Add --show-total-period for perf annotate
On 05/23/2015 06:08 AM, Andi Kleen wrote: Martin Liška writes: I've been working on a new feature for perf annotate, which should be able to annotate instructions with total spent time (compared to percentage usage). Let's consider following use-case. You want to compare two different compilers on the same code base and let's assume 90% of wall-time is spent in a single function. Moreover, let's say that these compilers produce assembly of a totally different size. In such case, it's very useful to get an approximation of spent time on a bunch of instructions, which can be compared among other compilers. Otherwise, one has to somehow sum percentages and compare it to size of a function. perf diff does not handle this? Especially with the differential profiling options it should. It does not work if you, in my case, compare ICC and GCC, where ICC uses a different mangling scheme for fortran modules. Moreover, situation can be more complicated if a compiler performs a bit different inlining decisions. @@ -623,6 +624,8 @@ static int __cmd_record(struct record *rec, int argc, const char **argv) if (!target__none(&opts->target) && !opts->initial_delay) perf_evlist__enable(rec->evlist); + t0 = rdclock(); + /* * Let the child rip */ @@ -692,6 +695,9 @@ static int __cmd_record(struct record *rec, int argc, const char **argv) goto out_child; } + t1 = rdclock(); + walltime_nsecs = t1 - t0; The walltime can be later computed by the difference of the first and the last time stamp after sorting the events. So you don't need the new header. -Andi Good point. Can you please help me how to compute a function percentage usage in perf annotate ;) ? Thanks, Martin -- 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 06/11] md/raid5: get rid of bio_fits_rdev()
On Mon, 25 May 2015 00:03:20 -0700 Ming Lin wrote:
> On Sun, May 24, 2015 at 10:48 PM, NeilBrown wrote:
> > On Fri, 22 May 2015 11:18:38 -0700 Ming Lin wrote:
> >
> >> From: Kent Overstreet
> >>
> >> Remove bio_fits_rdev() completely, because ->merge_bvec_fn() has now
> >> gone. There's no point in calling bio_fits_rdev() only for ensuring
> >> aligned read from rdev.
> >
> > Surely this patch should come *before*
> > [PATCH v4 07/11] md/raid5: split bio for chunk_aligned_read
>
> PATCH 6, then PATCH 7, isn't it already *before*?
Did I write that? I guess I did :-(
I meant *after*. Don't get rid of bio_fits_rdev until split_bio is in
chunk_aligned_read().
Sorry.
>
> >
> > and the comment says ->merge_bvec_fn() has gone, but that isn't until
> > [PATCH v4 08/11] block: kill merge_bvec_fn() completely
> >
> >
> > If those issues are resolved, then
>
> How about this?
>
> PATCH 6: md/raid5: split bio for chunk_aligned_read
> PATCH 7: block: kill merge_bvec_fn() completely
> PATCH 8: md/raid5: get rid of bio_fits_rdev()
Yes for "get rid of bio_fits_rdev()" after "split bio for chunk_aligned_read".
For the other issue, you could do was you suggest, or you could just change
the comment.
Remove bio_fits_rdev() as sufficient merge_bvec_fn() handling is now
performed by blk_queue_split() in md_make_request().
Up to you.
Thanks,
NeilBrown
>
> Thanks.
>
> >
> > Acked-by: NeilBrown
> >
> > Thanks,
> > NeilBrown
> >
> >
> >>
> >> Cc: Neil Brown
> >> Cc: linux-r...@vger.kernel.org
> >> Signed-off-by: Kent Overstreet
> >> [dpark: add more description in commit message]
> >> Signed-off-by: Dongsu Park
> >> Signed-off-by: Ming Lin
> >> ---
> >> drivers/md/raid5.c | 23 +--
> >> 1 file changed, 1 insertion(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> >> index 1ba97fd..b303ded 100644
> >> --- a/drivers/md/raid5.c
> >> +++ b/drivers/md/raid5.c
> >> @@ -4743,25 +4743,6 @@ static void raid5_align_endio(struct bio *bi, int
> >> error)
> >> add_bio_to_retry(raid_bi, conf);
> >> }
> >>
> >> -static int bio_fits_rdev(struct bio *bi)
> >> -{
> >> - struct request_queue *q = bdev_get_queue(bi->bi_bdev);
> >> -
> >> - if (bio_sectors(bi) > queue_max_sectors(q))
> >> - return 0;
> >> - blk_recount_segments(q, bi);
> >> - if (bi->bi_phys_segments > queue_max_segments(q))
> >> - return 0;
> >> -
> >> - if (q->merge_bvec_fn)
> >> - /* it's too hard to apply the merge_bvec_fn at this stage,
> >> - * just just give up
> >> - */
> >> - return 0;
> >> -
> >> - return 1;
> >> -}
> >> -
> >> static int chunk_aligned_read(struct mddev *mddev, struct bio * raid_bio)
> >> {
> >> struct r5conf *conf = mddev->private;
> >> @@ -4815,11 +4796,9 @@ static int chunk_aligned_read(struct mddev *mddev,
> >> struct bio * raid_bio)
> >> align_bi->bi_bdev = rdev->bdev;
> >> __clear_bit(BIO_SEG_VALID, &align_bi->bi_flags);
> >>
> >> - if (!bio_fits_rdev(align_bi) ||
> >> - is_badblock(rdev, align_bi->bi_iter.bi_sector,
> >> + if (is_badblock(rdev, align_bi->bi_iter.bi_sector,
> >> bio_sectors(align_bi),
> >> &first_bad, &bad_sectors)) {
> >> - /* too big in some way, or has a known bad block */
> >> bio_put(align_bi);
> >> rdev_dec_pending(rdev, mddev);
> >> return 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/
pgpVaNZXhm1Q_.pgp
Description: OpenPGP digital signature
Re: [PATCH 00/15] MIPS Malta DT Conversion
On Fri, May 22, 2015 at 10:50 AM, Paul Burton wrote: > This series begins converting the MIPS Malta board to use device tree, > which is done with a few goals in mind: > > - To modernise the Malta board support, providing a cleaner example to > people referencing it when bringing up new boards and reducing the > amount of code they need to write. > > - To make the code at the board level more generic with the eventual > aim of sharing it between multiple boards & allowing for > multi-platform kernel binaries. Although this series doesn't result > in the kernel reaching those goals, it is a step in that direction. > > - To result in a more maintainable kernel through a combination of the > above. How would I go about testing this under qemu? (Especially the "more than 256 megs ram" part. :) Rob -- 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: fix wrong DEBUG configuration
On 05/22/2015 09:02 AM, Ingo Molnar wrote:
* Arnaldo Carvalho de Melo wrote:
Em Wed, May 20, 2015 at 06:16:51PM +0200, Martin Liška escreveu:
On 05/20/2015 04:55 PM, Ingo Molnar wrote:
* Arnaldo Carvalho de Melo wrote:
So the rule has been: What are the kernel requirements for the
toolchain? tools/perf/ should build with that.
So we could use -Og if it works, like Kbuild does it:
KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387)
the 'cc-option' Make function does some magic of silently calling GCC
with that option and observing the result.
See:
scripts/Kbuild.include:cc-option = $(call try-run,\
I am sorry, I did mistake in understanding of DEBUG variable.
Following patch should be fixed, except missing auto-detection
of -Og option.
Unfortunately, following hunk does not work, no -Ox is added to CFLAGS?
-- CFLAGS += -Og
++ CFLAGS += $(call cc-option,-Og,-O0)
I don't know if we have this cc-option, perhaps Ingo is suggesting
we get it in tools/build/? Or include scripts/Kbuild.include and
then use it?
I.e. we have checks to see if we can use, for instance
-fstack-protector-all, see tools/build/feature/Makefile, using this
cc-option thing, importing it from Kbuild would solve the issue at
hand in a definitive way and in line with what we have been
pursuing: to make the tools/ build system be based on Kbuild.
So I'd suggest copying any necessary functions instead of outright
including all of Kbuild in the tooling build system which creates
non-trivial dependencies that is not necessarily tested as thoroughly
on the kbuild side as on the tooling side.
Thanks,
Ingo
Hi.
Thanks for advice, I copied necessary functions to include/utilities.mak.
Following patch works for, tested both with a compiler capable of -Og and
a not capable one.
Thanks,
Martin
Currently, GCC optimizes -O6 same as -O3 level, thus change the value
to -O6.
Right optimize debugging experience is given by passing -Og to compiler.
Assign default value for pointers that are identified by compiler as
non-initialized.
Signed-off-by: Martin Liska
---
tools/perf/arch/common.c| 2 +-
tools/perf/config/Makefile | 4 +++-
tools/perf/config/utilities.mak | 19 +++
tools/perf/util/symbol.c| 2 +-
tools/perf/util/trace-event-parse.c | 2 +-
5 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index 49776f1..b7bb42c 100644
--- a/tools/perf/arch/common.c
+++ b/tools/perf/arch/common.c
@@ -61,7 +61,7 @@ const char *const mips_triplets[] = {
static bool lookup_path(char *name)
{
bool found = false;
- char *path, *tmp;
+ char *path, *tmp = NULL;
char buf[PATH_MAX];
char *env = getenv("PATH");
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index e3b3724..47e4ae1 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -129,7 +129,9 @@ ifndef DEBUG
endif
ifeq ($(DEBUG),0)
- CFLAGS += -O6
+ CFLAGS += -O3
+else
+ CFLAGS += $(call cc-option,-Og,-O0)
endif
ifdef PARSER_DEBUG
diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak
index c16ce83..0ebef09 100644
--- a/tools/perf/config/utilities.mak
+++ b/tools/perf/config/utilities.mak
@@ -177,3 +177,22 @@ $(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
endef
_ge_attempt = $(if $(get-executable),$(get-executable),$(call _gea_err,$(2)))
_gea_err = $(if $(1),$(error Please set '$(1)' appropriately))
+
+# try-run
+# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
+# Exit code chooses option. "$$TMP" is can be used as temporary file and
+# is automatically cleaned up.
+try-run = $(shell set -e; \
+ TMP="$(TMPOUT)..tmp"; \
+ TMPO="$(TMPOUT)..o"; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi;\
+ rm -f "$$TMP" "$$TMPO")
+
+# cc-option
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+
+cc-option = $(call try-run,\
+ $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 82a31fd..a19fbd4 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -400,7 +400,7 @@ static struct symbol *symbols__find_by_name(struct rb_root *symbols,
const char *name)
{
struct rb_node *n;
- struct symbol_name_rb_node *s;
+ struct symbol_name_rb_node *s = NULL;
if (symbols == NULL)
return NULL;
diff --git a/tools/perf/util/trace-event-parse.c b/tools/perf/util/trace-event-parse.c
index 25d6c73..d495741 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -173,7 +173,7 @@ void parse_ftrace_printk(struct pevent *pevent,
char *line;
char *next = NULL;
char *addr_str;
- char *fmt;
+ char *fmt = NULL;
line = strtok_r(file, "\n", &next);
while (line) {
--
2.1.4
Re: [PATCH] zram: check compressor name before setting it
On 25/05/15 09:34, Sergey Senozhatsky wrote: On (05/25/15 09:15), Marcin Jabrzyk wrote: [..] I'm perfectly fine with this solution. It just does what I'd expect. cool, let's hear from Minchan. btw, if we decide to move on, how do you guys want to route it? do you want Marcin (I don't mind) or me (of course, with the appropriate credit to Marcin) to submit it? It this get accepted, then I'm fine with you to submit it. Best regards, Marcin Jabrzyk -ss -- 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/1] x86_64: fix KASan shadow region page tables
On 05/22/2015 07:03 PM, Alexander Popov wrote: > Physical addresses in KASan shadow region page tables need fixup: > kernel halts without it if phys_base is not zero. > Indeed. Since we have to patch page tables anyway, compile-time created kasan page tables become pointless. So, I'd suggest to create them in runtime. This could be done in plain C in kasan_map_early_shadow(). -- 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] coresight-etm3x: Add Qualcomm PTM v1.1 peripheral ID
Add Qualcomm's PTM v1.1 peripheral ID to supported devices.
This device could be found at least in MSM8974 and APQ8064
chipsets.
Signed-off-by: Ivan T. Ivanov
---
Changes since v1:
- s/PFT/PTM/ to describe device and not protocol implementation
drivers/hwtracing/coresight/coresight-etm3x.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c
b/drivers/hwtracing/coresight/coresight-etm3x.c
index 018a00f..cca98a8 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -1912,6 +1912,11 @@ static struct amba_id etm_ids[] = {
.mask = 0x0003,
.data = "PTM 1.1",
},
+ { /* PTM 1.1 Qualcomm */
+ .id = 0x0003006f,
+ .mask = 0x0003,
+ .data = "PTM 1.1",
+ },
{ 0, 0},
};
--
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/
linux-next: manual merge of the tty tree with the tty.current tree
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in
drivers/tty/serial/amba-pl011.c between commit 43dd1f9a5b05
("serial/amba-pl011: Unconditionally poll for FIFO space before each TX
char") from the tty.current tree and commit 1e84d22322ce
("serial/amba-pl011: Refactor and simplify TX FIFO handling") from the
tty tree.
I fixed it up (I just used the version from the tty tree) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpVuiNmxouEI.pgp
Description: OpenPGP digital signature
RE: [PATCH v5 19/21] clk: tegra: Add Super Gen5 Logic
> -Original Message- > From: ble...@google.com [mailto:ble...@google.com] On Behalf Of Benson > Leung > Sent: Friday, May 15, 2015 3:37 AM > To: Rhyland Klein > Cc: Peter De Schrijver; Mike Turquette; Stephen Warren; Stephen Boyd; Thierry > Reding; Alexandre Courbot; Bill Huang; Paul Walmsley; Jim Lin; linux- > c...@vger.kernel.org; linux-te...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH v5 19/21] clk: tegra: Add Super Gen5 Logic > > On Tue, May 12, 2015 at 10:24 AM, Rhyland Klein wrote: > > From: Bill Huang > > > > Super clock divider control and clock source mux of Tegra210 has > > changed a little against prior SoCs, this patch adds Gen5 logic to > > address those differences. > > > > Signed-off-by: Bill Huang > > --- > > v2: > > - Fixed sclk divider address (0x370 -> 0x2c) > > > > drivers/clk/tegra/Makefile |1 + > > drivers/clk/tegra/clk-tegra-super-gen5.c | 150 > ++ > > drivers/clk/tegra/clk.h |3 + > > 3 files changed, 154 insertions(+) > > create mode 100644 drivers/clk/tegra/clk-tegra-super-gen5.c > > I've diffed clk-tegra-super-gen5.c and the existing clk-tegra-super-gen4.c, > and > there's a lot of code duplication here. > They're the same pair of functions, with several small changes. Since the idea > behind pulling out the super clock initialization into a common file was to > reuse > the same init, could we extend the super-gen4 file (rename if you have to) to > support both gens instead? > Thanks, we'll integrate gen5 into gen4 file in v6. > -- > Benson Leung > Software Engineer, Chrom* OS > ble...@chromium.org
Re: [RESEND PATCH v1 2/2] drm: bridge/dw_hdmi-i2s-audio: add audio driver
Just a nit: a license mismatch.
On Fri, 2015-05-22 at 10:14 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
> + * 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 states the license is GPL v2.
> +MODULE_LICENSE("GPL");
And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think that either the comment at the top of this file
or the ident used in the MODULE_LICENSE() macro should change.
Paul Bolle
--
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/4] drm/tegra: Add VIC support
Hi Thierry,
Thank you for your thorough analysis - and sorry for a bunch of very
silly mistakes.
I am skipping most trivial parts and focus on the trickier comments and
questions.
On 05/22/2015 02:47 PM, Thierry Reding wrote:
+
+ struct tegra_bo *ucode_bo;
+ bool ucode_valid;
+ void *ucode_vaddr;
+
+ bool booted;
There are a bunch of other drivers that use a Falcon and they will all
need to use similar data to this to deal with the firmware and all. I
would like to see that code to be made into a Falcon library so that it
can be reused in a meaningful way.
Roughly this would look like this:
struct falcon {
struct device *dev;
...
};
int falcon_init(struct falcon *falcon, struct device *dev,
void __iomem *regs);
int falcon_load_firmware(struct falcon *falcon, const char *filename);
int falcon_exit(struct falcon *falcon);
int falcon_boot(struct falcon *falcon);
There are two issues in above scheme..:
- Memory allocation. Despite I have explicitly mentioned that the series
has been tested only with iommu disabled, I would prefer trying to keep
an option to use it later. Depending how well we want to isolate the
falcon library from other parts of tegradrm, the library may not have
ability to map anything to the tegradrm iommu domain.
- The firmware images may not hold only Falcon firmware. Already in VIC
case we have two firmwares: One for Falcon, another for FCE.
To overcome the above issues, I would prefer dropping
falcon_load_firmware() and keeping firmware image specifics inside the
client driver and giving data related to Falcon as a parameter for
falcon_boot(). Would this be ok?
+
+ /* for firewall - this determines if method 1 should be regarded
+* as an address register */
+ bool method_data_is_addr_reg;
+};
I think it'd be best to incorporate that functionality into the firewall
so that we can deal with it more centrally rather that duplicate this in
all drivers.
Do you have a concrete suggestion how this should be done? Firewall has
no access to the driver specifics and in VIC case the VIC methods
themselves define whether the METHOD1 includes address or not.
+static int vic_dma_pa_to_internal_256b(struct vic *vic, phys_addr_t pa,
+ u32 internal_offset, bool imem)
The name is confusing. Without looking at the code I'd expect this to
perform some kind of conversion from a physical address to some internal
address, but if I understand correctly this actually copies code into
the Falcon instruction or data memories. A better name I think would be:
static int falcon_load_chunk(struct falcon *falcon, phys_addr_t phys,
unsigned long offset, enum falcon_memory
target);
Note that this is now part of the Falcon library because I've seen
identical code used in several other drivers. Also the bool argument is
now an enumeration, which makes it much easier to read. Compare:
err = vic_dma_pa_to_internal_256b(vic, phys, offset, true);
and
err = falcon_load_chunk(&vic->falcon, phys, offset, FALCON_MEMORY_IMEM);
Sounds ok.
Is there a specific term in Falcon-speak for these 256 byte blocks?
"chunk" is a little awkward.
Unfortunately I am not aware that there would be - maybe "block"?
+ if (ucode.bin_header->bin_ver != 1) {
+ dev_err(vic->dev, "unsupported firmware version");
+ return -ENOENT;
Why not -EINVAL here, too?
We can interpret the issue two ways..: The given firmware is invalid
(-EINVAL) or that there was no supported firmware entry available (-ENOENT).
I do not have strong opinions and will change this to -EINVAL.
+ vic->ucode_bo = tegra_bo_create(dev, ucode_fw->size, 0);
+ if (IS_ERR(vic->ucode_bo)) {
+ dev_err(vic->dev, "dma memory allocation failed");
+ err = PTR_ERR(vic->ucode_bo);
+ goto err_alloc_iova;
+ }
Erm... no. Please don't use tegra_bo_create() to allocate these buffers.
tegra_bo_create() creates GEM objects and firmware doesn't qualify as a
GEM object.
Can't you use the DMA API here?
The firmware must be mapped to the IOMMU domain into which VIC is
attached - and I would prefer keeping the door open for enabling iommu
on VIC. This was the simplest way to get a buffer that is allocated to
the tegradrm iommu domain.
Should I add a function for allocating memory without making a gem
object or should I keep memory allocation here and simply add functions
for mapping it into tegradrm domain?
+static int vic_boot(struct device *dev)
+{
+ struct vic *vic = dev_get_drvdata(dev);
+ u32 offset;
+ int err = 0;
+
+ if (vic->booted)
+ return 0;
+
+ if (!vic->ucode_valid) {
+ err = vic_read_ucode(vic);
+ if (err)
+
[PATCH] [media] lmedm04: Neaten logging
Use a more current logging style.
o Use pr_fmt
o Add missing newlines to formats
o Remove used-once lme_debug macro incorporating it into dbg_info
o Remove unnecessary allocation error messages
o Remove unnecessary semicolons from #defines
o Remove info macro and convert uses to pr_info
o Fix spelling of snippet
o Use %phN extension
Signed-off-by: Joe Perches
---
drivers/media/usb/dvb-usb-v2/lmedm04.c | 105 +++--
1 file changed, 49 insertions(+), 56 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 5de6f7c..7e8e58b 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -67,6 +67,8 @@
* M88RS2000 suffers from loss of lock.
*/
#define DVB_USB_LOG_PREFIX "LME2510(C)"
+#define pr_fmt(fmt) DVB_USB_LOG_PREFIX ": " fmt
+
#include
#include
#include
@@ -84,25 +86,22 @@
#include "ts2020.h"
-#define LME2510_C_S7395"dvb-usb-lme2510c-s7395.fw";
-#define LME2510_C_LG "dvb-usb-lme2510c-lg.fw";
-#define LME2510_C_S0194"dvb-usb-lme2510c-s0194.fw";
-#define LME2510_C_RS2000 "dvb-usb-lme2510c-rs2000.fw";
-#define LME2510_LG "dvb-usb-lme2510-lg.fw";
-#define LME2510_S0194 "dvb-usb-lme2510-s0194.fw";
+#define LME2510_C_S7395"dvb-usb-lme2510c-s7395.fw"
+#define LME2510_C_LG "dvb-usb-lme2510c-lg.fw"
+#define LME2510_C_S0194"dvb-usb-lme2510c-s0194.fw"
+#define LME2510_C_RS2000 "dvb-usb-lme2510c-rs2000.fw"
+#define LME2510_LG "dvb-usb-lme2510-lg.fw"
+#define LME2510_S0194 "dvb-usb-lme2510-s0194.fw"
/* debug */
static int dvb_usb_lme2510_debug;
-#define lme_debug(var, level, args...) do { \
- if ((var >= level)) \
- pr_debug(DVB_USB_LOG_PREFIX": " args); \
+#define deb_info(level, fmt, ...) \
+do { \
+ if (dvb_usb_lme2510_debug >= level) \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
-#define deb_info(level, args...) lme_debug(dvb_usb_lme2510_debug, level, args)
-#define debug_data_snipet(level, name, p) \
-deb_info(level, name" (%02x%02x%02x%02x%02x%02x%02x%02x)", \
- *p, *(p+1), *(p+2), *(p+3), *(p+4), \
- *(p+5), *(p+6), *(p+7));
-#define info(args...) pr_info(DVB_USB_LOG_PREFIX": "args)
+#define debug_data_snippet(level, name, p) \
+ deb_info(level, name " (%*phN)\n", 8, p)
module_param_named(debug, dvb_usb_lme2510_debug, int, 0644);
MODULE_PARM_DESC(debug, "set debugging level (1=info (or-able)).");
@@ -182,10 +181,8 @@ static int lme2510_usb_talk(struct dvb_usb_device *d,
if (st->usb_buffer == NULL) {
st->usb_buffer = kmalloc(64, GFP_KERNEL);
- if (st->usb_buffer == NULL) {
- info("MEM Error no memory");
+ if (st->usb_buffer == NULL)
return -ENOMEM;
- }
}
buff = st->usb_buffer;
@@ -234,7 +231,7 @@ static int lme2510_enable_pid(struct dvb_usb_device *d, u8
index, u16 pid_out)
u8 pid_no = index * 2;
u8 pid_len = pid_no + 2;
int ret = 0;
- deb_info(1, "PID Setting Pid %04x", pid_out);
+ deb_info(1, "PID Setting Pid %04x\n", pid_out);
if (st->pid_size == 0)
ret |= lme2510_stream_restart(d);
@@ -275,7 +272,7 @@ static void lme2510_int_response(struct urb *lme_urb)
case -ESHUTDOWN:
return;
default:
- info("Error %x", lme_urb->status);
+ pr_info("Error %x\n", lme_urb->status);
break;
}
@@ -286,17 +283,17 @@ static void lme2510_int_response(struct urb *lme_urb)
for (i = 0; i < offset; ++i) {
ibuf = (u8 *)&rbuf[i*8];
- deb_info(5, "INT O/S C =%02x C/O=%02x Type =%02x%02x",
- offset, i, ibuf[0], ibuf[1]);
+ deb_info(5, "INT O/S C =%02x C/O=%02x Type =%02x%02x\n",
+offset, i, ibuf[0], ibuf[1]);
switch (ibuf[0]) {
case 0xaa:
- debug_data_snipet(1, "INT Remote data snipet", ibuf);
+ debug_data_snippet(1, "INT Remote data snippet", ibuf);
if ((ibuf[4] + ibuf[5]) == 0xff) {
key = RC_SCANCODE_NECX((ibuf[2] ^ 0xff) << 8 |
(ibuf[3] > 0) ? (ibuf[3]
^ 0xff) : 0,
ibuf[5]);
- deb_info(1, "INT Key =%08x", key);
+ deb_info(1, "INT Key =%08x\n", key);
if (adap_to_d(adap)->rc_dev != NULL)
rc_keydown(adap_to_d(adap)->rc_dev,
Re: [PATCH v2 5/6] iommu/mediatek: Add mt8173 IOMMU driver
Hi,
Please see my comments inline.
On Fri, May 15, 2015 at 6:43 PM, Yong Wu wrote:
[snip]
> +
> +struct mtk_iommu_info {
> + void __iomem*base;
> + int irq;
> + struct device *dev;
> + struct device *larbdev[MTK_IOMMU_LARB_MAX_NR];
> + struct clk *bclk;
> + dma_addr_t protect_base; /* protect memory base */
> + unsigned intlarb_nr; /* local arbiter number */
> + unsigned intlarb_portid_base[MTK_IOMMU_LARB_MAX_NR];
> + /* the port id base for each local arbiter */
It might not be a bad idea to convert this kind of comments into a
proper kerneldoc comment for the whole struct. Similarly for other
structs in the driver.
[snip]
> +static void mtk_iommu_clear_intr(void __iomem *m4u_base)
nit: Instead of pasing m4u_base here, could you pass a pointer to the
mtk_iommu_info here and use its base field? This would be more strict,
because currently a void pointer permits passing anything to this
function.
> +{
> + u32 val;
> +
> + val = readl(m4u_base + REG_MMU_INT_CONTROL0);
> + val |= F_INT_L2_CLR_BIT;
> + writel(val, m4u_base + REG_MMU_INT_CONTROL0);
> +}
> +
> +static void mtk_iommu_tlb_flush_all(void *cookie)
> +{
> + struct mtk_iommu_domain *domain = cookie;
> + u32 val;
> +
> + val = F_INVLD_EN1 | F_INVLD_EN0;
> + writel(val, domain->imuinfo->base + REG_MMU_INV_SEL);
nit: Do you need this val variable?
> + writel(F_ALL_INVLD, domain->imuinfo->base + REG_MMU_INVALIDATE);
> +}
> +
> +static void mtk_iommu_tlb_add_flush(unsigned long iova, size_t size,
> + bool leaf, void *cookie)
> +{
> + struct mtk_iommu_domain *domain = cookie;
> + void __iomem *m4u_base = domain->imuinfo->base;
> + unsigned int iova_start = iova, iova_end = iova + size - 1;
> + int ret;
> + u32 val;
> +
> + val = F_INVLD_EN1 | F_INVLD_EN0;
> + writel(val, m4u_base + REG_MMU_INV_SEL);
nit: Does this write need to go through this val variable?
> +
> + writel(iova_start, m4u_base + REG_MMU_INVLD_START_A);
> + writel(iova_end, m4u_base + REG_MMU_INVLD_END_A);
> + writel(F_MMU_INV_RANGE, m4u_base + REG_MMU_INVALIDATE);
> +
> + ret = readl_poll_timeout_atomic(m4u_base + REG_MMU_CPE_DONE, val,
> + val != 0, 10, 100);
> + if (ret) {
> + dev_warn(domain->imuinfo->dev, "Invalid tlb don't done\n");
Maybe "Partial TLB flush timed out, falling back to full flush\n"?
> + mtk_iommu_tlb_flush_all(cookie);
> + }
> + writel(0, m4u_base + REG_MMU_CPE_DONE);
> +}
> +
> +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> +{
> + /*
> +* After delete arch_setup_dma_ops,
> +* This will be replaced with dma_map_page
> +*/
> +__dma_flush_range(ptr, ptr + size);
> +}
> +
> +static struct iommu_gather_ops mtk_iommu_gather_ops = {
> + .tlb_flush_all = mtk_iommu_tlb_flush_all,
> + .tlb_add_flush = mtk_iommu_tlb_add_flush,
> + .tlb_sync = mtk_iommu_tlb_flush_all,
> + .flush_pgtable = mtk_iommu_flush_pgtable,
> +};
> +
> +static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> +{
> + struct mtk_iommu_domain *mtkdomain = dev_id;
> + struct mtk_iommu_info *piommu = mtkdomain->imuinfo;
> + struct device *dev = piommu->dev;
> + void __iomem *m4u_base = piommu->base;
> + u32 int_state, regval, fault_iova, fault_pa;
> + unsigned int fault_larb, fault_port;
> + bool layer, write;
> +
> + int_state = readl(m4u_base + REG_MMU_FAULT_ST1);
> +
> + /* read error info from registers */
> + fault_iova = readl(m4u_base + REG_MMU_FAULT_VA);
> + layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
> + write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
> + fault_iova &= F_MMU_FAULT_VA_MSK;
> + fault_pa = readl(m4u_base + REG_MMU_INVLD_PA);
> + regval = readl(m4u_base + REG_MMU_INT_ID);
> + fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
> + fault_port = F_MMU0_INT_ID_PORT_ID(regval);
> +
> + report_iommu_fault(&mtkdomain->domain, dev, fault_iova,
> + write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
> +
> + if (int_state & F_INT_TRANSLATION_FAULT) {
> + dev_err_ratelimited(
> + dev,
> + "fault:iova=0x%x pa=0x%x larb=%d port=%d layer=%d
> %s\n",
> + fault_iova, fault_pa, fault_larb, fault_port,
> + layer, write ? "write" : "read");
> + }
> +
> + if (int_state & F_INT_MAIN_MULTI_HIT_FAULT)
> + dev_err_ratelimited(dev,
> + "multi-hit!iova=0x%x larb=%d port=%d\n",
> +
Re: [git pull] vfs part 2
On 04/23/2015 01:16 PM, Andrey Ryabinin wrote: > On 04/15/2015 09:14 PM, Al Viro wrote: >> 9p: switch p9_client_write() to passing it struct iov_iter * > > Hi Al, > > This change caused following: > > [ 91.637917] > == > [ 91.639252] BUG: KASan: out of bounds on stack in > iov_iter_advance+0x3e4/0x4b0 at addr 8800ba1efd20 > [ 91.640979] Read of size 8 by task trinity-c15/4746 > [ 91.641493] page:ea0002e87bc0 count:0 mapcount:0 mapping: > (null) index:0x0 > [ 91.641787] flags: 0x100() > [ 91.641787] page dumped because: kasan: bad access detected > [ 91.641787] CPU: 1 PID: 4746 Comm: trinity-c15 Not tainted 4.0.0+ #319 > [ 91.641787] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014 > [ 91.641787] 8800ba1efd08 8800ba1ef918 81ab94ed > 1d40005d0f7f > [ 91.641787] 8800ba1ef9b0 8800ba1ef998 812bc0f4 > 814901f0 > [ 91.641787] 8800ba1efa40 0296 8801f4993490 > 81228fe0 > [ 91.641787] Call Trace: > [ 91.641787] dump_stack (lib/dump_stack.c:52) > [ 91.641787] kasan_report_error (mm/kasan/report.c:132 > mm/kasan/report.c:193) > [ 91.641787] ? idr_mark_full (lib/idr.c:551) > [ 91.641787] ? clear_exceptional_entry (mm/truncate.c:561) > [ 91.641787] __asan_report_load8_noabort (mm/kasan/report.c:251) > [ 91.641787] ? iov_iter_advance (lib/iov_iter.c:511) > [ 91.641787] iov_iter_advance (lib/iov_iter.c:511) > [ 91.641787] p9_client_write (net/9p/client.c:1656) > [ 91.641787] ? p9_client_readdir (net/9p/client.c:1614) > [ 91.641787] ? kasan_kmalloc (mm/kasan/kasan.c:355) > [ 91.641787] ? __kmalloc (mm/slub.c:3325) > [ 91.641787] ? p9_client_readdir (net/9p/client.c:1614) > [ 91.641787] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:405) > [ 91.641787] v9fs_file_write_iter (fs/9p/vfs_file.c:421) > [ 91.641787] ? __sb_end_write (fs/super.c:1192) > [ 91.641787] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:405) > [ 91.641787] ? do_readv_writev (fs/read_write.c:776) > [ 91.641787] ? recalc_sigpending (kernel/signal.c:160) > [ 91.641787] ? __set_task_blocked (kernel/signal.c:2514) > [ 91.641787] __vfs_write (fs/read_write.c:479 fs/read_write.c:490) > [ 91.641787] ? recalc_sigpending (kernel/signal.c:160) > [ 91.641787] ? __vfs_read (fs/read_write.c:486) > [ 91.641787] ? __sb_end_write (fs/super.c:1192) > [ 91.641787] ? signal_setup_done (kernel/signal.c:2556) > [ 91.641787] ? hrtimer_start (kernel/time/hrtimer.c:1043) > [ 91.641787] ? do_setitimer (kernel/time/itimer.c:222) > [ 91.641787] vfs_write (include/linux/fs.h:1984 include/linux/fs.h:2416 > fs/read_write.c:543) > [ 91.641787] SyS_write (fs/read_write.c:585 fs/read_write.c:576) > [ 91.641787] ? SyS_read (fs/read_write.c:576) > [ 91.641787] ? init_fpu (arch/x86/kernel/i387.c:231 > arch/x86/kernel/i387.c:266) > [ 91.641787] ? math_state_restore (arch/x86/kernel/traps.c:869) > [ 91.641787] system_call_fastpath (arch/x86/kernel/entry_64.S:261) > [ 91.641787] Memory state around the buggy address: > [ 91.641787] 8800ba1efc00: f2 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f3 > f3 f3 > [ 91.641787] 8800ba1efc80: f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 > f1 f1 > [ 91.641787] >8800ba1efd00: f1 00 00 f4 f4 f2 f2 f2 f2 00 00 00 00 00 > f4 f4 > [ 91.641787]^ > [ 91.641787] 8800ba1efd80: f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 > f3 f3 > [ 91.641787] 8800ba1efe00: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > [ 91.641787] > == > > > > This could happen when p9pdu_readf() changes 'count' to some value > > iov_iter_count(from): > > p9_client_write(): > <...> > int count = iov_iter_count(from); > <...> > *err = p9pdu_readf(req->rc, clnt->proto_version, "d", &count); > <...> > iov_iter_advance(from, count); > > > Ping. -- 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] regulator: da9062: Fix modalias
Remove extra space between platform prefix and driver name in MODULE_ALIAS.
Signed-off-by: Axel Lin
---
drivers/regulator/da9062-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/da9062-regulator.c
b/drivers/regulator/da9062-regulator.c
index 9805b6b..e572a65 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -840,4 +840,4 @@ module_exit(da9062_regulator_cleanup);
MODULE_AUTHOR("S Twiss ");
MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform: da9062-regulators");
+MODULE_ALIAS("platform:da9062-regulators");
--
2.1.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: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo
hi,
On 2015/5/24 16:49, Masami Hiramatsu wrote:
> On 2015/05/24 17:28, He Kuang wrote:
>> When probing at function entry, fallback $params to calling regs if no
>> debuginfo is provided.
>>
>> Before this path:
>>$ perf probe -v --add='generic_perform_write $params'
>>...
>>Added new event:
>>Writing event: p:probe/generic_perform_write _stext+1246632 $params
>>[86152.161204] Parse error at argument[0]. (-22)
>>Failed to write event: Invalid argument
>> Error: Failed to add events. Reason: Invalid argument (Code: -22)
>>
>> After this patch:
>>$ perf probe -v --add='generic_perform_write $params'
>>...
>>Could not open debuginfo. Try to use symbols.
>>...
>>Added new event:
>>Writing event: p:probe/generic_perform_write _stext+1246632 %di %si %dx
>> %cx %r8 %r9
>> probe:generic_perform_write (on generic_perform_write with $params)
>>
>>You can now use it in all perf tools, such as:
>>
>> perf record -e probe:generic_perform_write -aR sleep 1
>>
>>$ perf record -e probe:generic_perform_write dd if=/dev/zero
>> of=/mnt/data/test bs=4k count=3
>
> NAK, this should not work on x86-32 and we don't know how many registers are
> used.
> I think $params special handler should be used only with debuginfo, since
> $params
> ensures user to save function parameters with its name. If we can't do that,
> we
> should accept that.
>
> If you need to handle register arguments, you should introduce new $regparams
> instead
Yes, $regparam is more appropriate.
> of $params. (however, that still not work correctly on x86-32)
>
> Hmm, we also need $regs to record all registers.
Right, I learnt regparm(3) is mandatory in x86_32, according to rules,
the first three args will go to regparm(ax, dx, cx). But we should not
refer arg1~3 to ax, dx, cx because of 64bit parameters (other reasons?).
Consider this keyword is used for generating bpf prologue which fetches
formal parameters when no debuginfo is provided, for this purpose, we can:
1) We just help fetch the $regs or $regparms(If the keyword is
$regparms, ax/dx/cx is fetched, nothing related to args) to bpf arglists
and leave the rest things to bpf prog writer.
2) Keep that on platforms like x86_64 and skip this feature on
platforms like x86_32.
or any other suggestions?
Thanks
>
> Thank you,
>
>
>>
>>$ perf script
>>dd 1149 [000] 18574.762652: probe:generic_perform_write:
>> (81130770) arg1=0x88007c37f600 arg2=0x88007ca87e70 arg3=0x0
>> arg4=0x0 arg5=0x556062e3 arg6=0x12a8010
>>dd 1149 [000] 18574.762652: probe:generic_perform_write:
>> (81130770) arg1=0x88007c37f600 arg2=0x88007ca87e70
>> arg3=0x1000 arg4=0x0 arg5=0x556062e3 arg6=0x12a8010
>>dd 1149 [000] 18574.762652: probe:generic_perform_write:
>> (81130770) arg1=0x88007c37f600 arg2=0x88007ca87e70
>> arg3=0x2000 arg4=0x0 arg5=0x556062e3 arg6=0x12a8010
>>
>> Signed-off-by: He Kuang
>> ---
>> tools/perf/util/probe-event.c | 42
>> ++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index d05b77c..7f9f431 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -46,6 +46,7 @@
>> #include "probe-event.h"
>> #include "probe-finder.h"
>> #include "session.h"
>> +#include
>>
>> #define MAX_CMDLEN 256
>> #define PERFPROBE_GROUP "probe"
>> @@ -286,6 +287,14 @@ static void clear_probe_trace_events(struct
>> probe_trace_event *tevs, int ntevs)
>> clear_probe_trace_event(tevs + i);
>> }
>>
>> +static bool perf_probe_is_function_entry(struct perf_probe_event *pev)
>> +{
>> +if (pev->point.file || pev->point.line || pev->point.lazy_line)
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> #ifdef HAVE_DWARF_SUPPORT
>> /*
>>* Some binaries like glibc have special symbols which are on the symbol
>> @@ -1225,6 +1234,33 @@ static int parse_perf_probe_point(char *arg, struct
>> perf_probe_event *pev)
>> return 0;
>> }
>>
>> +static char *parse_perf_probe_param(void)
>> +{
>> +int i = 0;
>> +struct strbuf sb;
>> +bool first = true;
>> +const char *reg_str;
>> +
>> +strbuf_init(&sb, 16);
>> +
>> +while (1) {
>> +reg_str = get_arch_calling_reg_str(i++);
>> +if (!reg_str)
>> +break;
>> +
>> +if (first) {
>> +strbuf_addf(&sb, "%s", reg_str);
>> +first = false;
>> +} else
>> +strbuf_addf(&sb, " %s", reg_str);
>> +}
>> +
>> +if (first)
>> +strbuf_add(&sb, "", 1);
>> +
>> +return strbuf_detach(&sb, NULL);
>> +}
>> +
>> /* Parse perf-probe event argument */
>> static int parse_perf_probe_arg(char *str, struct perf_probe_arg *arg)
>> {
>> @@ -2543,6 +2579,12 @@ static int fin
Re: [v7 4/8] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts
On Mon, 25 May 2015, Feng Wu wrote: > We don't need to migrate the irqs for VT-d Posted-Interrupts here. > When 'pst' is set in IRTE, the associated irq will be posted to > guests instead of interrupt remapping. The destination of the > interrupt is set in Posted-Interrupts Descriptor, and the migration > happens during vCPU scheduling. > > However, we still update the cached irte here, which can be used > when changing back to remapping mode. > > Signed-off-by: Feng Wu > Reviewed-by: Jiang Liu > Acked-by: David Woodhouse > --- > drivers/iommu/intel_irq_remapping.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel_irq_remapping.c > b/drivers/iommu/intel_irq_remapping.c > index 1955b09..646f4cf 100644 > --- a/drivers/iommu/intel_irq_remapping.c > +++ b/drivers/iommu/intel_irq_remapping.c > @@ -994,7 +994,10 @@ intel_ir_set_affinity(struct irq_data *data, const > struct cpumask *mask, >*/ > irte->vector = cfg->vector; > irte->dest_id = IRTE_DEST(cfg->dest_apicid); > - modify_irte(&ir_data->irq_2_iommu, irte); > + > + /* We don't need to modify irte if the interrupt is for posting. */ > + if (irte->pst != 1) > + modify_irte(&ir_data->irq_2_iommu, irte); I don't think this is correct. ir_data->irte_entry contains the non posted version, which has pst == 0. You need some other way to store whether you are in posted mode or not. Thanks, tglx -- 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 00/13] POWER DSCR fixes, improvements, docs and tests
On 05/21/2015 12:13 PM, Anshuman Khandual wrote: > This patch series has patches for POWER DSCR fixes, improvements, > in code documentaion, kernel support user documentation and selftest based > test cases. It has got five test cases which are derived from Anton's DSCR > test bucket which can be listed as follows. > > (1) http://ozlabs.org/~anton/junkcode/dscr_default_test.c > (2) http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c > (3) http://ozlabs.org/~anton/junkcode/dscr_inherit_exec_test.c > (4) http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c > (5) http://ozlabs.org/~anton/junkcode/user_dscr_test.c > > NOTE1: Anton's original inherit exec test expected the child to have > system default DSCR value instead of the inherited DSCR value from > it's parent. But looks like thats not the case when we execute the > test, it always inherits it's parent's DSCR value over the exec call > as well. So I have changed the test program assuming its correct to > have the inherited DSCR value in the fork/execed child program. > Please let me know if thats not correct and I am missing something > there. > > Changes in V5: > - > - Fixed build problem with get_default_dscr/set_default_dscr functions > by checking on the return values of read & write system calls. These patches are available for pull from this location mentioned below. https://github.com/akhandual/linux.git dscr_v5 -- 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 5/5] mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
On 14 May 2015 at 01:36, Tony Lindgren wrote:
> We can now use generic wakeirq handling and remove the custom handling
> for the wake-up interrupts.
>
> Signed-off-by: Tony Lindgren
Rafael, if you are fine with it, please take this one through your
linux-pm tree.
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/mmc/host/omap_hsmmc.c | 51
> +++
> 1 file changed, 8 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 9df2b68..5fbf4d8 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /* OMAP HSMMC Host Controller Registers */
> @@ -218,7 +219,6 @@ struct omap_hsmmc_host {
> unsigned intflags;
> #define AUTO_CMD23 (1 << 0)/* Auto CMD23 support */
> #define HSMMC_SDIO_IRQ_ENABLED (1 << 1)/* SDIO irq enabled */
> -#define HSMMC_WAKE_IRQ_ENABLED (1 << 2)
> struct omap_hsmmc_next next_data;
> struct omap_hsmmc_platform_data*pdata;
>
> @@ -1117,22 +1117,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> -static irqreturn_t omap_hsmmc_wake_irq(int irq, void *dev_id)
> -{
> - struct omap_hsmmc_host *host = dev_id;
> -
> - /* cirq is level triggered, disable to avoid infinite loop */
> - spin_lock(&host->irq_lock);
> - if (host->flags & HSMMC_WAKE_IRQ_ENABLED) {
> - disable_irq_nosync(host->wake_irq);
> - host->flags &= ~HSMMC_WAKE_IRQ_ENABLED;
> - }
> - spin_unlock(&host->irq_lock);
> - pm_request_resume(host->dev); /* no use counter */
> -
> - return IRQ_HANDLED;
> -}
> -
> static void set_sd_bus_power(struct omap_hsmmc_host *host)
> {
> unsigned long i;
> @@ -1665,7 +1649,6 @@ static void omap_hsmmc_enable_sdio_irq(struct mmc_host
> *mmc, int enable)
>
> static int omap_hsmmc_configure_wake_irq(struct omap_hsmmc_host *host)
> {
> - struct mmc_host *mmc = host->mmc;
> int ret;
>
> /*
> @@ -1677,11 +1660,7 @@ static int omap_hsmmc_configure_wake_irq(struct
> omap_hsmmc_host *host)
> if (!host->dev->of_node || !host->wake_irq)
> return -ENODEV;
>
> - /* Prevent auto-enabling of IRQ */
> - irq_set_status_flags(host->wake_irq, IRQ_NOAUTOEN);
> - ret = devm_request_irq(host->dev, host->wake_irq, omap_hsmmc_wake_irq,
> - IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> - mmc_hostname(mmc), host);
> + ret = dev_pm_request_wake_irq(host->dev, host->wake_irq, NULL, 0,
> NULL);
> if (ret) {
> dev_err(mmc_dev(host->mmc), "Unable to request wake IRQ\n");
> goto err;
> @@ -1718,7 +1697,7 @@ static int omap_hsmmc_configure_wake_irq(struct
> omap_hsmmc_host *host)
> return 0;
>
> err_free_irq:
> - devm_free_irq(host->dev, host->wake_irq, host);
> + dev_pm_free_wake_irq(host->dev);
> err:
> dev_warn(host->dev, "no SDIO IRQ support, falling back to polling\n");
> host->wake_irq = 0;
> @@ -2007,6 +1986,7 @@ static int omap_hsmmc_probe(struct platform_device
> *pdev)
> omap_hsmmc_ops.multi_io_quirk = omap_hsmmc_multi_io_quirk;
> }
>
> + device_init_wakeup(&pdev->dev, true);
> pm_runtime_enable(host->dev);
> pm_runtime_get_sync(host->dev);
> pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> @@ -2147,6 +2127,7 @@ err_slot_name:
> if (host->use_reg)
> omap_hsmmc_reg_put(host);
> err_irq:
> + device_init_wakeup(&pdev->dev, false);
> if (host->tx_chan)
> dma_release_channel(host->tx_chan);
> if (host->rx_chan)
> @@ -2178,6 +2159,7 @@ static int omap_hsmmc_remove(struct platform_device
> *pdev)
>
> pm_runtime_put_sync(host->dev);
> pm_runtime_disable(host->dev);
> + device_init_wakeup(&pdev->dev, false);
> if (host->dbclk)
> clk_disable_unprepare(host->dbclk);
>
> @@ -2204,11 +2186,6 @@ static int omap_hsmmc_suspend(struct device *dev)
> OMAP_HSMMC_READ(host->base, HCTL) & ~SDBP);
> }
>
> - /* do not wake up due to sdio irq */
> - if ((host->mmc->caps & MMC_CAP_SDIO_IRQ) &&
> - !(host->mmc->pm_flags & MMC_PM_WAKE_SDIO_IRQ))
> - disable_irq(host->wake_irq);
> -
> if (host->dbclk)
> clk_disable_unprepare(host->dbclk);
>
> @@ -2233,11 +2210,6 @@ static int omap_hsmmc_resume(struct device *dev)
> omap_hsmmc_conf_bus_power(host);
>
> omap_hsmmc_protect_card(host);
> -
> - if ((host->mmc->caps & MMC_CAP_SDIO_IRQ) &&
> - !(host->mmc->pm_flags & MMC_PM_WAKE_SDIO_IRQ))
> -
Re: [PATCH V8 00/28] Add new powerpc specific ELF core notes
On 05/19/2015 08:37 PM, Anshuman Khandual wrote: > From: Anshuman Khandual > > This patch series adds twelve new ELF core note sections which can > be used with existing ptrace request PTRACE_GETREGSET-SETREGSET for accessing > various transactional memory and other miscellaneous debug register sets on > powerpc platform. > > Previous versions: > == > RFC: https://lkml.org/lkml/2014/4/1/292 > V1: https://lkml.org/lkml/2014/4/2/43 > V2: https://lkml.org/lkml/2014/5/5/88 > V3: https://lkml.org/lkml/2014/5/23/486 > V4: https://lkml.org/lkml/2014/11/11/6 > V5: https://lkml.org/lkml/2014/11/25/134 > V6: https://lkml.org/lkml/2014/12/2/98 > V7: https://lkml.org/lkml/2015/1/14/19 > > Changes in V8: > -- > - Split the misc register set into individual ELF core notes > - Implemented support for VSX register set (on and off TM) > - Implemented support for EBB register set > - Implemented review comments on previous versions > - Some code re-arrangements, re-writes and documentation > - Added comprehensive list of test cases into selftests These patches are available for pull from this location mentioned below. https://github.com/akhandual/linux.git ptrace_powerpc_v8 -- 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/
linux-next: manual merge of the extcon tree with the battery tree
Hi Chanwoo,
Today's linux-next merge of the extcon tree got a conflict in
include/linux/mfd/axp20x.h between commit 843735b788a4 ("power:
axp288_charger: axp288 charger driver") from the battery tree and
commit f03123783d4e ("extcon: axp288: Add axp288 extcon driver
support") from the extcon tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/mfd/axp20x.h
index 02f97dc568ac,4ed8071d062e..
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@@ -361,11 -275,9 +361,16 @@@ struct axp20x_fg_pdata
int thermistor_curve[MAX_THERM_CURVE_SIZE][2];
};
+struct axp20x_chrg_pdata {
+ int max_cc;
+ int max_cv;
+ int def_cc;
+ int def_cv;
+};
+
+ struct axp288_extcon_pdata {
+ /* GPIO pin control to switch D+/D- lines b/w PMIC and SOC */
+ struct gpio_desc *gpio_mux_cntl;
+ };
+
#endif /* __LINUX_MFD_AXP20X_H */
pgpdWBelC2XAE.pgp
Description: OpenPGP digital signature
Re: [PATCH] ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask
On Sat, May 23, 2015 at 06:32:29PM +0200, Maciej S. Szmigiero wrote: > snd_soc_pcm_stream.formats is a bitmask of SNDRV_PCM_FMTBIT_*, > not of SNDRV_PCM_FORMAT_* (which are sequential integers), > however some of ASoC CODEC drivers use these values instead. > > Found out by sparse on 0-day kernel tester. > > Signed-off-by: Maciej Szmigiero > 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: [RFC] signal:remove duplicate code
Am 25.05.2015 um 07:49 schrieb yalin wang:
> __dequeue_signal() is only called by dequeue_signal(), after that,
> dequeue_signal() will call recalc_sigpending(), this function will
> set or unset TIF_SIGPENDING bit, so we don't need do this in
> __dequeue_signal()
>
> Signed-off-by: yalin wang
> ---
> kernel/signal.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 836df8d..de33281 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -583,10 +583,9 @@ static int __dequeue_signal(struct sigpending *pending,
> sigset_t *mask,
> if (sig) {
> if (current->notifier) {
> if (sigismember(current->notifier_mask, sig)) {
> -if (!(current->notifier)(current->notifier_data)) {
> -clear_thread_flag(TIF_SIGPENDING);
Here be dragons.
In __dequeue_signal() we clear TIF_SIGPENDING depending
on the result of ->notifier().
Did you double check that clearing that flag goes hand in hand
with recalc_sigpending()?
Thanks,
//richard
--
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] ARM: berlin: add SPI nodes for BG2Q
Sebastian,
On Wed, May 20, 2015 at 06:58:35PM +0200, Sebastian Hesselbarth wrote:
> On 20.05.2015 14:53, Antoine Tenart wrote:
> >The BG2Q SoC has two SPI controllers. Add the corresponding nodes.
> >
> >Signed-off-by: Antoine Tenart
> >---
> >
> >Based on top of the Berlin clock rework series.
> >
> > arch/arm/boot/dts/berlin2q.dtsi | 38 ++
> > 1 file changed, 38 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/berlin2q.dtsi
> >b/arch/arm/boot/dts/berlin2q.dtsi
> >index 187d056f7ad2..c25ee86b2bfa 100644
> >--- a/arch/arm/boot/dts/berlin2q.dtsi
> >+++ b/arch/arm/boot/dts/berlin2q.dtsi
> >@@ -286,6 +286,20 @@
> > status = "disabled";
> > };
> >
> >+spi0: spi@1c00 {
> >+compatible = "snps,dw-apb-ssi";
> >+reg = <0x1c00 0x100>;
> >+interrupt-parrent = <&aic>;
>
> the same question as for the ADC node patch: IIRC you don't have
> to repeat the interrupt-parent property as long as any node upstream
> will have it already.
You're right, I'll remove this. And we have other nodes doing the same
thing, I'll cook up a patch to remove non mandatory interrupt-parent
properties.
>
> >+interrupts = <7>;
> >+clocks = <&chip_clk CLKID_CFG>;
> >+pinctrl-0 = <&spi0_pmux>;
> >+pinctrl-names = "default";
> >+#address-cells = <1>;
> >+#size-cells = <0>;
> >+num-cs = <4>;
> >+status = "disabled";
> >+};
> >+
> > timer0: timer@2c00 {
> > compatible = "snps,dw-apb-timer";
> > reg = <0x2c00 0x14>;
> >@@ -383,6 +397,11 @@
> > groups = "G7";
> > function = "twsi1";
> > };
> >+
> >+spi0_pmux: spi0-pmux {
> >+groups = "G8", "G9", "G10", "G11";
> >+function = "spi1";
>
> Hmm, "spi0_pmux" but "spi1" function?
Yep. See below.
> >+};
> > };
> >
> > chip_rst: reset {
> >@@ -473,6 +492,20 @@
> > };
> > };
> >
> >+spi1: spi@5000 {
> >+compatible = "snps,dw-apb-ssi";
> >+reg = <0x6000 0x100>;
> >+interrupt-parent = <&sic>;
> >+interrupts = <5>;
> >+clocks = <&refclk>;
> >+pinctrl-0 = <&spi1_pmux>;
> >+pinctrl-names = "default";
> >+#address-cells = <1>;
> >+#size-cells = <0>;
> >+num-cs = <4>;
> >+status = "disabled";
> >+};
> >+
> > i2c2: i2c@7000 {
> > compatible = "snps,designware-i2c";
> > #address-cells = <1>;
> >@@ -564,6 +597,11 @@
> > groups = "GSM14";
> > function = "twsi3";
> > };
> >+
> >+spi1_pmux: spi1-pmux {
> >+groups = "GSM0", "GSM1",
> >"GSM2", "GSM3";
> >+function = "spi2";
>
> ditto.
>
> I know the internal numbering scheme on BG-SoCs is weird, but it looks like
> that either you are missing the third SPI or there is only 2 and
> numbering starts with 1 *sigh* ;)
There are 2 SPI, starting at 1... :)
> Anyway, the numbering should be consistent with pinctrl function names
> although I would have preferred to start counting with 0.
OK, so we'll have spi1_pmux in the spi0 node. I'll update.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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] ARM: berlin: add SPI nodes for BG2Q
On Thu, May 21, 2015 at 01:21:42AM +0200, Sebastian Hesselbarth wrote:
> On 20.05.2015 14:53, Antoine Tenart wrote:
> >+
> >+spi0_pmux: spi0-pmux {
> >+groups = "G8", "G9", "G10", "G11";
> >+function = "spi1";
> >+};
>
> ... can you check which of G8-G11 are actually clock/data and which
> are CSn lines?
>
> CSn lines should all be optional and per-board pinmux - same for the
> other spi pinmux.
G8 and GSM3 are for clock/data, the other groups (G9-11 and GSM0-2)
control the CSn lines. I'll update.
> > };
> >
> > chip_rst: reset {
> >@@ -473,6 +492,20 @@
> > };
> > };
> >
> >+spi1: spi@5000 {
> >+compatible = "snps,dw-apb-ssi";
> >+reg = <0x6000 0x100>;
>
> s/spi@5000/spi@6000/
Oops.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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 v6] serial: 8250_uniphier: add UniPhier serial driver
On Mon, 2015-05-25 at 12:44 +0900, Masahiro Yamada wrote:
> Add the driver for on-chip UART used on UniPhier SoCs.
>
> This hardware is similar to 8250, but the register mapping is
> slightly different:
> - The offset to FCR, MCR is different.
> - The divisor latch access bit does not exist. Instead, the
> divisor latch register is available at offset 9.
>
> This driver overrides serial_{in,out}, dl_{read,write} callbacks,
> but wants to borrow most of code from 8250_core.c.
Do not send series too often, let people to review what you did.
More comments below.
>
> Signed-off-by: Masahiro Yamada
> Reviewed-by: Matthias Brugger
> ---
>
> Changes in v6:
> - Drop unnecessary #include
> (it is covered by #include "8250.h")
>
> Changes in v5:
> - Set up.port.mapsize
> - Pass NULL rahter than 0 to the second argument of devm_clk_get()
>
> Changes in v4:
> - Use spin_lock for read-modify-write register access
> - Add /* fall through */ comments where I intentionally
> did not add "break";
> - Drop unnecessary #include
> - Drop unnecessary #include
> - Add an empty line between #include <> and ""
> - Use platform_get_irq() instead of platform_get_resource()
>
> Changes in v3:
> - Just add *_SHIFT macro for the special case
>
> Changes in v2:
> - Drop unnecessary #include
> - Sort includes in alphabetical order
> - Use devm_clk_get() rather than of_clk_get()
> - Delete unneeded clk_put() from uniphier_uart_remove callback
> - Delete unneeded IS_ERR_OR_NULL check from uniphier_uart_remove callback
> - Use UNIPHIER_UART_*_SHIFT instead of hard-coded shift values
> - Change the first argument type of uniphier_of_serial_setup()
> from (struct platform_device *) to (struct device *) for code-cleanup.
>
> drivers/tty/serial/8250/8250_uniphier.c | 257
>
> drivers/tty/serial/8250/Kconfig | 7 +
> drivers/tty/serial/8250/Makefile| 1 +
> 3 files changed, 265 insertions(+)
> create mode 100644 drivers/tty/serial/8250/8250_uniphier.c
>
> diff --git a/drivers/tty/serial/8250/8250_uniphier.c
> b/drivers/tty/serial/8250/8250_uniphier.c
> new file mode 100644
> index 000..6f1e997
> --- /dev/null
> +++ b/drivers/tty/serial/8250/8250_uniphier.c
> @@ -0,0 +1,257 @@
> +/*
> + * Copyright (C) 2015 Masahiro Yamada
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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 "8250.h"
> +
> +/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
> +#define UNIPHIER_UART_DEFAULT_FIFO_SIZE 64
> +
> +#define UNIPHIER_UART_CHAR_FCR 3 /* Character / FIFO Control
> Register */
> +#define UNIPHIER_UART_LCR_MCR4 /* Line/Modem Control Register
> */
> +#define UNIPHIER_UART_LCR_SHIFT8
Indentation problem, needs to be fixed.
> +#define UNIPHIER_UART_DLR9 /* Divisor Latch Register */
> +
> +struct uniphier8250_priv {
> + int line;
> + struct clk *clk;
> + spinlock_t atomic_write_lock;
> +};
> +
> +/*
> + * The register map is slightly different from that of 8250.
> + * IO callbacks must be overridden for correct access to FCR, LCR, and MCR.
> + */
> +static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
> +{
> + int valshift = 0;
Perhaps unsigned int?
> +
> + switch (offset) {
> + case UART_LCR:
> + valshift = UNIPHIER_UART_LCR_SHIFT;
> + /* fall through */
> + case UART_MCR:
> + offset = UNIPHIER_UART_LCR_MCR;
> + break;
> + default:
> + break;
> + }
> +
> + offset <<= p->regshift;
> +
> + /*
> + * The return value must be masked with 0xff because LCR and MCR reside
> + * in the same register that must be accessed by 32-bit write/read.
> + * 8 or 16 bit access to this hardware result in unexpected behavior.
> + */
> + return (readl(p->membase + offset) >> valshift) & 0xff;
> +}
> +
> +static void uniphier_serial_out(struct uart_port *p, int offset, int value)
> +{
> + int valshift = 0;
Ditto.
> + bool normal = false;
> +
> + switch (offset) {
> + case UART_FCR:
> + offset = UNIPHIER_UART_CHAR_FCR;
> + break;
> + case UART_LCR:
> + valshift = UNIPHIER_UART_LCR_SHIFT;
> + /* Divisor latch access bit does not exist. */
> + value &= ~(UART_LCR_DLAB << valshift);
> +
Re: [RFC PATCH v3 21/37] bpf tools: Create eBPF maps defined in an object file
On 2015/5/19 2:48, Alexei Starovoitov wrote:
On 5/17/15 3:56 AM, Wang Nan wrote:
This patch creates maps based on 'map' section in object file using
bpf_create_map(), and store the fds into an array in
'struct bpf_object'. Since the byte order of the object may differ
from the host, swap map definition before processing.
This is the first patch in 'loading' phase. Previous patches parse ELF
object file and create needed data structure, but doesnnt play with
kernel. They belong to 'opening' phase.
Signed-off-by: Wang Nan
...
+for (j = 0; j < i; j++) {
+close(obj->maps_fds[j]);
+obj->maps_fds[j] = -1;
this line is unnecessary, since you're freeing the whole array
at the line below:
+}
+free(obj->maps_fds);
+obj->maps_fds = NULL;
...
void bpf_close_object(struct bpf_object *obj)
{
if (!obj)
return;
bpf_obj_clear_elf(obj);
+bpf_unload_object(obj);
just realized that this API keeps elf file open for the whole
life time. I think that should be split up.
bpf_open_object() can do elf parsing, creation of maps and
bpf loading.
bpf_close_object() can unload programs, maps. That's fine,
but closing of elf file and freeing memory associated
with parsing sections should be a separate call.
Looks like I didn't describe the API of libbpf very clearly in patch 0/37.
There are two phases of the API: opening and loading. Opening phase
does ELF parsing, and records all related information info 'struct
bpf_object'.
After that, ELF file itself is closed by bpf_obj_elf_finish(). See patch
19/37.
After that, caller will have a chance to adjust programs and maps
(currently not
implemented). Caller should call bpf_load_object() to do real useful
things with
kernel. bpf_unload_object() remove map and programs in the object from
kernel. It
also calls bpf_obj_elf_finish(). However, if it has been called once,
the 2nd call
doesn't take effect at all. Just in case.
Thank you.
--
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] backlight: pwm: handle EPROBE_DEFER while requesting the PWM
Hi Lee, On Thu, 12 Mar 2015 09:02:24 + Lee Jones wrote: > On Thu, 19 Feb 2015, Nicolas Ferre wrote: > > > When trying to request the PWM device with devm_pwm_get(), the EPROBE_DEFER > > flag is not handled properly. It can lead to the PWM not being found. > > > > Signed-off-by: Boris Brezillon > > Signed-off-by: Nicolas Ferre > > --- > > drivers/video/backlight/pwm_bl.c | 4 > > 1 file changed, 4 insertions(+) > > Applied, thanks. I don't see this patch in Linus' tree (actually, it's not even in linux-next). I don't know where it's stuck, but could you make sure it reaches mainline for 4.2 (or 4.1 if it's not to late) ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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: RaspberryPi "is this a real kernel?"
On Sun, May 24, 2015 at 09:11:56PM -0400, valdis.kletni...@vt.edu wrote: > On Sun, 24 May 2015 11:32:36 +0100, John Whitmore said: > > > $ ./mkknlimg ../../linux/arch/arm/boot/zImage 3.18.0-can+.img > > tail: +: invalid number of bytes > > * Is this a valid kernel? In pass-through mode. > > Looks like they try to use 'tail' to skip over something, but the + sign > in your uname -r gives it indigestion. Try building with a version name > that doesn't include a + sign, and complain to the maintainers of mkknlimg > that they've probably got a parameter quoting problem (most likely, there's > someplace a > > tail -this -that $foo > > needs to be > > tail -this -that "$foo" Thanks a million for that help. I'll do a bit of looking into the scripts. -- 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 v1] tree-wide: remove "select FW_LOADER" uses
On Fri, 2015-05-22 at 22:12 +0200, Geert Uytterhoeven wrote: > On Fri, May 22, 2015 at 9:30 PM, Austin S Hemmelgarn > wrote: > >>> Either way SUSE kernels also have EXPERT=y as well. Would not be > >>> surprised if > >>> other major distributions also have EXPERT=y. > >> > >> Right, I believe Fedora has it set as well. > >> > > I'm pretty certain that Fedora does, and that Arch does as well. Fedora doesn't set EXPERT, and as far as I can see, never has. Same goes for EMBEDDED, which is the predecessor of EXPERT. If EXPERT really turns out to be set on most distributions it will have gone the way of EXPERIMENTAL: a warning sign that lost its impact through overuse. Perhaps that's the way these things go. But I don't think that has happened with EXPERT, not yet. Paul Bolle -- 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] drivers:usb:fsl: Introduce FSL_USB2_PHY_UTMI_DUAL macro
Introduce FSL_USB2_PHY_UTMI_DUAL macro for setting phy mode
in SOCs such has T4240, T1040, T2080 which have utmi dual-phy
Signed-off-by: Ramneek Mehresh
Signed-off-by: Nikhil Badola
---
drivers/usb/host/ehci-fsl.c | 1 +
drivers/usb/host/fsl-mph-dr-of.c | 2 ++
include/linux/fsl_devices.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index ab4eee3..1f0e4e0 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -226,6 +226,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
portsc |= PORT_PTS_PTW;
/* fall through */
case FSL_USB2_PHY_UTMI:
+ case FSL_USB2_PHY_UTMI_DUAL:
if (pdata->have_sysif_regs && pdata->controller_ver) {
/* controller version 1.6 or above */
setbits32(non_ehci + FSL_SOC_USB_CTRL, UTMI_PHY_EN);
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 7e325e9..ed39081 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -69,6 +69,8 @@ static enum fsl_usb2_phy_modes determine_usb_phy(const char
*phy_type)
return FSL_USB2_PHY_UTMI;
if (!strcasecmp(phy_type, "utmi_wide"))
return FSL_USB2_PHY_UTMI_WIDE;
+ if (!strcasecmp(phy_type, "utmi_dual"))
+ return FSL_USB2_PHY_UTMI_DUAL;
if (!strcasecmp(phy_type, "serial"))
return FSL_USB2_PHY_SERIAL;
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index a82296a..dd73fad 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -64,6 +64,7 @@ enum fsl_usb2_phy_modes {
FSL_USB2_PHY_UTMI,
FSL_USB2_PHY_UTMI_WIDE,
FSL_USB2_PHY_SERIAL,
+ FSL_USB2_PHY_UTMI_DUAL,
};
struct clk;
--
2.1.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 5/6] staging:lustre: style cleanups for lib-socket.c
On Fri, May 22, 2015 at 02:32:31PM -0400, James Simmons wrote:
> @@ -167,13 +164,14 @@ lnet_ipif_enumerate (char ***namesp)
> if (nalloc * sizeof(*ifr) > PAGE_CACHE_SIZE) {
> toobig = 1;
> nalloc = PAGE_CACHE_SIZE/sizeof(*ifr);
> - CWARN("Too many interfaces: only enumerating first
> %d\n",
> - nalloc);
> + CWARN("Too many interfaces: only enumerating "
> + "first %d\n", nalloc);
> }
Don't split string literals, it makes them hard to grep for.
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/
[PATCH 1/2] mfd: arizona: Add convience defines for micd_rate/micd_bias_starttime
Signed-off-by: Charles Keepax --- include/dt-bindings/mfd/arizona.h | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/include/dt-bindings/mfd/arizona.h b/include/dt-bindings/mfd/arizona.h index c7af7c7..5556099 100644 --- a/include/dt-bindings/mfd/arizona.h +++ b/include/dt-bindings/mfd/arizona.h @@ -90,4 +90,18 @@ #define ARIZONA_INMODE_SE 1 #define ARIZONA_INMODE_DMIC 2 +#define ARIZONA_MICD_TIME_CONTINUOUS 0 +#define ARIZONA_MICD_TIME_250US 1 +#define ARIZONA_MICD_TIME_500US 2 +#define ARIZONA_MICD_TIME_1MS3 +#define ARIZONA_MICD_TIME_2MS4 +#define ARIZONA_MICD_TIME_4MS5 +#define ARIZONA_MICD_TIME_8MS6 +#define ARIZONA_MICD_TIME_16MS 7 +#define ARIZONA_MICD_TIME_32MS 8 +#define ARIZONA_MICD_TIME_64MS 9 +#define ARIZONA_MICD_TIME_128MS 10 +#define ARIZONA_MICD_TIME_256MS 11 +#define ARIZONA_MICD_TIME_512MS 12 + #endif -- 1.7.2.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: [RESEND PATCH v1 2/2] drm: bridge/dw_hdmi-i2s-audio: add audio driver
Hi Paul,
在 2015/5/25 16:24, Paul Bolle 写道:
Just a nit: a license mismatch.
On Fri, 2015-05-22 at 10:14 -0500, Yakir Yang wrote:
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
+ * 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 states the license is GPL v2.
+MODULE_LICENSE("GPL");
And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think that either the comment at the top of this file
or the ident used in the MODULE_LICENSE() macro should change.
Thanks for your catch, got it :-)
Yakir Yang
Paul Bolle
--
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/2] mfd: arizona: Add DT/ACPI u32 helper functions
Add helpers to read u32's and arrays of u32's from device tree or ACPI
using the new device properties API.
Signed-off-by: Charles Keepax
---
drivers/mfd/arizona-core.c | 39 ++
include/linux/mfd/arizona/core.h |5
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index bebf58a..fb55769 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -746,6 +747,44 @@ int arizona_of_get_named_gpio(struct arizona *arizona,
const char *prop,
}
EXPORT_SYMBOL_GPL(arizona_of_get_named_gpio);
+int arizona_device_read_u32_array(struct arizona *arizona,
+ const char *prop, bool mandatory,
+ u32 *data, size_t num)
+{
+ int ret;
+
+ ret = device_property_read_u32_array(arizona->dev, prop, data, num);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ if (!mandatory)
+ break;
+
+ dev_err(arizona->dev, "Mandatory property %s is missing\n",
+ prop);
+ break;
+ default:
+ dev_err(arizona->dev, "Property %s is malformed: %d\n",
+ prop, ret);
+ break;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(arizona_device_read_u32_array);
+
+unsigned int arizona_device_read_u32(struct arizona *arizona,
+const char *prop, bool mandatory)
+{
+ u32 data = 0;
+
+ arizona_device_read_u32_array(arizona, prop, mandatory, &data, 1);
+
+ return data;
+}
+EXPORT_SYMBOL_GPL(arizona_device_read_u32);
+
static int arizona_of_get_core_pdata(struct arizona *arizona)
{
struct arizona_pdata *pdata = &arizona->pdata;
diff --git a/include/linux/mfd/arizona/core.h b/include/linux/mfd/arizona/core.h
index 847bdaf..1c3d39d 100644
--- a/include/linux/mfd/arizona/core.h
+++ b/include/linux/mfd/arizona/core.h
@@ -160,5 +160,10 @@ int wm8997_patch(struct arizona *arizona);
extern int arizona_of_get_named_gpio(struct arizona *arizona, const char *prop,
bool mandatory);
+extern int arizona_device_read_u32_array(struct arizona *arizona,
+const char *prop, bool mandatory,
+u32 *data, size_t num);
+extern unsigned int arizona_device_read_u32(struct arizona *arizona,
+ const char *prop, bool mandatory);
#endif
--
1.7.2.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 4/7 V2] workqueue: reuse the current per-node pwq when its attrs unchanged
Hi, TJ The patch 4/5/6 does reduce cpu and temporary-memory usage sometimes. But it is in slow path where small optimization is commonly unwelcome at. Do I need to refactor the patches? I'm in doubt for the necessary. Thanks, Lai -- 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/
linux-next: manual merge of the userns tree with the vfs tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in
fs/libfs.c between commit 61ba64fc0768 ("libfs: simple_follow_link()")
from the vfs tree and commit d5044ae07353 ("fs: Add helper functions
for permanently empty directories.") from the userns tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/libfs.c
index 65e1feca8b98,02813592e121..
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@@ -1097,14 -1094,98 +1097,109 @@@ simple_nosetlease(struct file *filp, lo
}
EXPORT_SYMBOL(simple_nosetlease);
+const char *simple_follow_link(struct dentry *dentry, void **cookie)
+{
+ return d_inode(dentry)->i_link;
+}
+EXPORT_SYMBOL(simple_follow_link);
+
+const struct inode_operations simple_symlink_inode_operations = {
+ .follow_link = simple_follow_link,
+ .readlink = generic_readlink
+};
+EXPORT_SYMBOL(simple_symlink_inode_operations);
+
+ /*
+ * Operations for a permanently empty directory.
+ */
+ static struct dentry *empty_dir_lookup(struct inode *dir, struct dentry
*dentry, unsigned int flags)
+ {
+ return ERR_PTR(-ENOENT);
+ }
+
+ static int empty_dir_getattr(struct vfsmount *mnt, struct dentry *dentry,
+struct kstat *stat)
+ {
+ struct inode *inode = d_inode(dentry);
+ generic_fillattr(inode, stat);
+ return 0;
+ }
+
+ static int empty_dir_setattr(struct dentry *dentry, struct iattr *attr)
+ {
+ return -EPERM;
+ }
+
+ static int empty_dir_setxattr(struct dentry *dentry, const char *name,
+ const void *value, size_t size, int flags)
+ {
+ return -EOPNOTSUPP;
+ }
+
+ static ssize_t empty_dir_getxattr(struct dentry *dentry, const char *name,
+ void *value, size_t size)
+ {
+ return -EOPNOTSUPP;
+ }
+
+ static int empty_dir_removexattr(struct dentry *dentry, const char *name)
+ {
+ return -EOPNOTSUPP;
+ }
+
+ static ssize_t empty_dir_listxattr(struct dentry *dentry, char *list, size_t
size)
+ {
+ return -EOPNOTSUPP;
+ }
+
+ static const struct inode_operations empty_dir_inode_operations = {
+ .lookup = empty_dir_lookup,
+ .permission = generic_permission,
+ .setattr= empty_dir_setattr,
+ .getattr= empty_dir_getattr,
+ .setxattr = empty_dir_setxattr,
+ .getxattr = empty_dir_getxattr,
+ .removexattr= empty_dir_removexattr,
+ .listxattr = empty_dir_listxattr,
+ };
+
+ static loff_t empty_dir_llseek(struct file *file, loff_t offset, int whence)
+ {
+ /* An empty directory has two entries . and .. at offsets 0 and 1 */
+ return generic_file_llseek_size(file, offset, whence, 2, 2);
+ }
+
+ static int empty_dir_readdir(struct file *file, struct dir_context *ctx)
+ {
+ dir_emit_dots(file, ctx);
+ return 0;
+ }
+
+ static const struct file_operations empty_dir_operations = {
+ .llseek = empty_dir_llseek,
+ .read = generic_read_dir,
+ .iterate= empty_dir_readdir,
+ .fsync = noop_fsync,
+ };
+
+
+ void make_empty_dir_inode(struct inode *inode)
+ {
+ set_nlink(inode, 2);
+ inode->i_mode = S_IFDIR | S_IRUGO | S_IXUGO;
+ inode->i_uid = GLOBAL_ROOT_UID;
+ inode->i_gid = GLOBAL_ROOT_GID;
+ inode->i_rdev = 0;
+ inode->i_size = 2;
+ inode->i_blkbits = PAGE_SHIFT;
+ inode->i_blocks = 0;
+
+ inode->i_op = &empty_dir_inode_operations;
+ inode->i_fop = &empty_dir_operations;
+ }
+
+ bool is_empty_dir_inode(struct inode *inode)
+ {
+ return (inode->i_fop == &empty_dir_operations) &&
+ (inode->i_op == &empty_dir_inode_operations);
+ }
pgpevH4YBtprn.pgp
Description: OpenPGP digital signature
[PATCH] rtc: pcf8563 fix: return -EINVAL if we read an invalid time.
Return -EINVAL if the voltage low bit is set or the time looks invalid
to avoid getting a bogus time at boot.
There was a comment stating that util-linux hwclock refuses to set a
new time if we return an error code on read, but at least the current
version do set the time as expected. Anyway most rtc drivers do return
an error if the read time is invalid.
Signed-off-by: Jan Kardell
---
drivers/rtc/rtc-pcf8563.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0ba7e59..1af0c48 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -22,7 +22,7 @@
#include
#include
-#define DRV_VERSION "0.4.3"
+#define DRV_VERSION "0.4.4"
#define PCF8563_REG_ST10x00 /* status */
#define PCF8563_REG_ST20x01
@@ -202,8 +202,9 @@ static int pcf8563_get_datetime(struct i2c_client *client,
struct rtc_time *tm)
if (buf[PCF8563_REG_SC] & PCF8563_SC_LV) {
pcf8563->voltage_low = 1;
- dev_info(&client->dev,
+ dev_err(&client->dev,
"low voltage detected, date/time is not reliable.\n");
+ return -EINVAL;
}
dev_dbg(&client->dev,
@@ -234,11 +235,11 @@ static int pcf8563_get_datetime(struct i2c_client
*client, struct rtc_time *tm)
tm->tm_sec, tm->tm_min, tm->tm_hour,
tm->tm_mday, tm->tm_mon, tm->tm_year, tm->tm_wday);
- /* the clock can give out invalid datetime, but we cannot return
-* -EINVAL otherwise hwclock will refuse to set the time on bootup.
-*/
- if (rtc_valid_tm(tm) < 0)
+ err = rtc_valid_tm(tm);
+ if (err < 0) {
dev_err(&client->dev, "retrieved date/time is not valid.\n");
+ return err;
+ }
return 0;
}
--
1.8.4.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: [f2fs-dev] [PATCH 2/3] f2fs crypto: use bounce pages from mempool first
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, May 22, 2015 8:40 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 2/3] f2fs crypto: use bounce pages from mempool
> first
>
> If a lot of write streams are triggered, alloc_page and __free_page are
> costly called, resulting in high memory pressure.
>
> In order to avoid that, let's reuse mempool pages for writeback pages.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/crypto.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/fs/f2fs/crypto.c b/fs/f2fs/crypto.c
> index 2c7819a..2ceee68 100644
> --- a/fs/f2fs/crypto.c
> +++ b/fs/f2fs/crypto.c
> @@ -408,20 +408,12 @@ struct page *f2fs_encrypt(struct inode *inode,
> return (struct page *)ctx;
>
> /* The encryption operation will require a bounce page. */
> - ciphertext_page = alloc_page(GFP_NOFS);
> + ciphertext_page = mempool_alloc(f2fs_bounce_page_pool, GFP_NOFS);
> if (!ciphertext_page) {
> - /*
> - * This is a potential bottleneck, but at least we'll have
> - * forward progress.
> - */
> - ciphertext_page = mempool_alloc(f2fs_bounce_page_pool,
> - GFP_NOFS);
> - if (WARN_ON_ONCE(!ciphertext_page))
> - ciphertext_page = mempool_alloc(f2fs_bounce_page_pool,
> - GFP_NOFS | __GFP_WAIT);
> - ctx->flags &= ~F2FS_BOUNCE_PAGE_REQUIRES_FREE_ENCRYPT_FL;
> - } else {
> + ciphertext_page = alloc_page(GFP_NOFS);
Using alloc_page(GFP_NOFS | __GFP_WAIT) to avoid failure?
Thanks,
> ctx->flags |= F2FS_BOUNCE_PAGE_REQUIRES_FREE_ENCRYPT_FL;
> + } else {
> + ctx->flags &= ~F2FS_BOUNCE_PAGE_REQUIRES_FREE_ENCRYPT_FL;
> }
> ctx->flags |= F2FS_WRITE_PATH_FL;
> ctx->w.bounce_page = ciphertext_page;
> --
> 2.1.1
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
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 2/2] arm64: Implement vmalloc based thread_info allocator
On May 25, 2015, at 2:49 AM, Arnd Bergmann wrote: > On Monday 25 May 2015 01:02:20 Jungseok Lee wrote: >> Fork-routine sometimes fails to get a physically contiguous region for >> thread_info on 4KB page system although free memory is enough. That is, >> a physically contiguous region, which is currently 16KB, is not available >> since system memory is fragmented. >> >> This patch tries to solve the problem as allocating thread_info memory >> from vmalloc space, not 1:1 mapping one. The downside is one additional >> page allocation in case of vmalloc. However, vmalloc space is large enough, >> around 240GB, under a combination of 39-bit VA and 4KB page. Thus, it is >> not a big tradeoff for fork-routine service. > > vmalloc has a rather large runtime cost. I'd argue that failing to allocate > thread_info structures means something has gone very wrong. That is why the feature is marked "N" by default. I focused on fork-routine stability rather than performance. Could you give me an idea how to evaluate performance degradation? Running some benchmarks would be helpful, but I would like to try to gather data based on meaningful methodology. > Can you describe the scenario that leads to fragmentation this bad? Android, but I could not describe an exact reproduction procedure step by step since it's behaved and reproduced randomly. As reading the following thread from mm mailing list, a similar symptom is observed on other systems. https://lkml.org/lkml/2015/4/28/59 Although I do not know the details of a system mentioned in the thread, even order-2 page allocation is not smoothly operated due to fragmentation on low memory system. I think the point is *low memory system*. 64-bit kernel is usually a feasible option when system memory is enough, but 64-bit kernel and low memory system combo is not unusual in case of ARM64. > Could the stack size be reduced to 8KB perhaps? I guess probably not. A commit, 845ad05e, says that 8KB is not enough to cover SpecWeb benchmark. The stack size is 16KB on x86_64. I am not sure whether all applications, which work fine on x86_64 machine, run very well on ARM64 with 8KB stack size. 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/2] f2fs: avoid duplicated code by reusing f2fs_read_end_io
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, May 20, 2015 1:49 AM
> To: Chao Yu
> Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] f2fs: avoid duplicated code by reusing
> f2fs_read_end_io
>
> Hi Chao,
>
> On Tue, May 19, 2015 at 05:38:56PM +0800, Chao Yu wrote:
> > This patch tries to clean up code as part code of f2fs_read_end_io
> > and mpage_end_io are the same, so it's better to merge and reuse them.
> >
> > Signed-off-by: Chao Yu
> > ---
> > fs/f2fs/data.c | 35 +--
> > 1 file changed, 5 insertions(+), 30 deletions(-)
> >
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 8d04e24..5173d0f 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -34,40 +34,16 @@ static void f2fs_read_end_io(struct bio *bio, int err)
> > struct bio_vec *bvec;
> > int i;
> >
> > - bio_for_each_segment_all(bvec, bio, i) {
> > - struct page *page = bvec->bv_page;
> > -
> > - if (!err) {
> > - SetPageUptodate(page);
> > - } else {
> > - ClearPageUptodate(page);
> > - SetPageError(page);
> > - }
> > - unlock_page(page);
> > - }
> > - bio_put(bio);
> > -}
> > -
> > -/*
> > - * I/O completion handler for multipage BIOs.
> > - * copied from fs/mpage.c
> > - */
> > -static void mpage_end_io(struct bio *bio, int err)
> > -{
> > - struct bio_vec *bv;
> > - int i;
> > -
> > if (f2fs_bio_encrypted(bio)) {
> > if (err) {
> > f2fs_release_crypto_ctx(bio->bi_private);
> > } else {
> > - f2fs_end_io_crypto_work(bio->bi_private, bio);
> > - return;
> > + return f2fs_end_io_crypto_work(bio->bi_private, bio);
>
> IMO, it'd better remain the previous one to make clear that
> f2fs_en_io_crypto_work defines a void return.
> How about that?
OK, will do.
Thanks,
--
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 1/2] f2fs: avoid duplicated code by reusing f2fs_read_end_io
This patch tries to clean up code because part code of f2fs_read_end_io
and mpage_end_io are the same, so it's better to merge and reuse them.
Signed-off-by: Chao Yu
---
v2:
* do not merge 'f2fs_end_io_crypto_work' and 'return' to indicate
f2fs_end_io_crypto_work is defined to be a void returned function.
fs/f2fs/data.c | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 8d04e24..9bedfa8 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -34,29 +34,6 @@ static void f2fs_read_end_io(struct bio *bio, int err)
struct bio_vec *bvec;
int i;
- bio_for_each_segment_all(bvec, bio, i) {
- struct page *page = bvec->bv_page;
-
- if (!err) {
- SetPageUptodate(page);
- } else {
- ClearPageUptodate(page);
- SetPageError(page);
- }
- unlock_page(page);
- }
- bio_put(bio);
-}
-
-/*
- * I/O completion handler for multipage BIOs.
- * copied from fs/mpage.c
- */
-static void mpage_end_io(struct bio *bio, int err)
-{
- struct bio_vec *bv;
- int i;
-
if (f2fs_bio_encrypted(bio)) {
if (err) {
f2fs_release_crypto_ctx(bio->bi_private);
@@ -66,8 +43,8 @@ static void mpage_end_io(struct bio *bio, int err)
}
}
- bio_for_each_segment_all(bv, bio, i) {
- struct page *page = bv->bv_page;
+ bio_for_each_segment_all(bvec, bio, i) {
+ struct page *page = bvec->bv_page;
if (!err) {
SetPageUptodate(page);
@@ -77,7 +54,6 @@ static void mpage_end_io(struct bio *bio, int err)
}
unlock_page(page);
}
-
bio_put(bio);
}
@@ -122,7 +98,7 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi,
block_t blk_addr,
bio->bi_bdev = sbi->sb->s_bdev;
bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(blk_addr);
bio->bi_end_io = is_read ? f2fs_read_end_io : f2fs_write_end_io;
- bio->bi_private = sbi;
+ bio->bi_private = is_read ? NULL : sbi;
return bio;
}
@@ -1584,7 +1560,7 @@ submit_and_realloc:
}
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(block_nr);
- bio->bi_end_io = mpage_end_io;
+ bio->bi_end_io = f2fs_read_end_io;
bio->bi_private = ctx;
}
--
2.3.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 v3 0/6] Watchdog: introduce ARM SBSA watchdog driver
From: Fu Wei This patchset: (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt for FDT info of SBSA Generic Watchdog, and give two examples of adding SBSA Generic Watchdog device node into the dts files: foundation-v8.dts and amd-seattle-soc.dtsi. (2)Introduce "pretimeout" into the watchdog framework, and update Documentation/watchdog/watchdog-kernel-api.txt to introduce: (1)the new elements in the watchdog_device and watchdog_ops struct; (2)the new API "watchdog_init_timeouts". (3)Introduce ARM SBSA watchdog driver: a.Use linux kernel watchdog framework; b.Work with FDT on ARM64; c.Use "pretimeout" in watchdog framework; d.In first timeout, do panic to save system context; e.Support getting timeout and pretimeout from parameter and FDT at the driver init stage. (4)Parse SBSA Generic Watchdog Structure in GTDT table of ACPI, and create a platform device with that information. This platform device can be used by This Watchdog driver. This patchset has been tested with watchdog daemon (ACPI/FDT, module/build-in) on the following platforms: (1)ARM Foundation v8 model (2)AMD Seattle B0 Changelog: v3: Delete "export arch_timer_get_rate" patch. Driver back to use arch_timer_get_cntfrq. Improve watchdog_init_timeouts function and update relevant documentation. Improve watchdog_timeout_invalid and watchdog_pretimeout_invalid. Improve foundation-v8.dts: delete the unnecessary tag of device node. Remove "ARM64 || COMPILE_TEST" from Kconfig. Add comments in arch/arm64/kernel/acpi.c Fix typoes and incorrect comments. v2: Improve watchdog-kernel-api.txt documentation for pretimeout support. Export "arch_timer_get_rate" in arm_arch_timer.c. Add watchdog_init_timeouts API for pretimeout support in framework. Improve suspend and resume foundation in driver Improve timeout/pretimeout values init code in driver. Delete unnecessary items of the sbsa_gwdt struct and #define. Delete all unnecessary debug info in driver. Fix 64bit division bug. Use the arch_timer interface to get watchdog clock rate. Add MODULE_DEVICE_TABLE for platform device id. Fix typoes. v1: The first version upstream patchset to linux mailing list. Fu Wei (6): Documentation: add sbsa-gwdt.txt documentation ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi Watchdog: introdouce "pretimeout" into framework Watchdog: introduce ARM SBSA watchdog driver ACPI: import watchdog info of GTDT into platform device .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 36 ++ Documentation/watchdog/watchdog-kernel-api.txt | 47 +- arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 11 + arch/arm64/boot/dts/arm/foundation-v8.dts | 10 + arch/arm64/kernel/acpi.c | 145 +++ drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/sbsa_gwdt.c | 474 + drivers/watchdog/watchdog_core.c | 95 +++-- drivers/watchdog/watchdog_dev.c| 50 +++ include/linux/watchdog.h | 33 +- 11 files changed, 880 insertions(+), 33 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt create mode 100644 drivers/watchdog/sbsa_gwdt.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 v3 3/6] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
From: Fu Wei
This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.
Acked-by: Arnd Bergmann
Acked-by: Suravee Suthikulpanit
Tested-by: Suravee Suthikulpanit
Signed-off-by: Fu Wei
---
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..95994eb 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,17 @@
clock-names = "uartclk", "apb_pclk";
};
+ watchdog0: watchdog@e0bb {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0xe0bb 0 0x1>,
+ <0x0 0xe0bc 0 0x1>;
+ reg-names = "refresh",
+ "control";
+ interrupts = <0 337 4>;
+ interrupt-names = "ws0";
+ timeout-sec = <10 5>;
+ };
+
spi0: ssp@e102 {
status = "disabled";
compatible = "arm,pl022", "arm,primecell";
--
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 v3 4/6] Watchdog: introdouce "pretimeout" into framework
From: Fu Wei
Also update Documentation/watchdog/watchdog-kernel-api.txt to
introduce:
(1)the new elements in the watchdog_device and watchdog_ops struct;
(2)the new API "watchdog_init_timeouts"
Reasons:
(1)kernel already has two watchdog drivers are using "pretimeout":
drivers/char/ipmi/ipmi_watchdog.c
drivers/watchdog/kempld_wdt.c(but the definition is different)
(2)some other drivers are going to use this: ARM SBSA Generic Watchdog
Acked-by: Arnd Bergmann
Tested-by: Suravee Suthikulpanit
Signed-off-by: Fu Wei
---
Documentation/watchdog/watchdog-kernel-api.txt | 47 +++--
drivers/watchdog/watchdog_core.c | 95 +++---
drivers/watchdog/watchdog_dev.c| 50 ++
include/linux/watchdog.h | 33 -
4 files changed, 192 insertions(+), 33 deletions(-)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index a0438f3..95b355d 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -49,6 +49,9 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int pretimeout;
+ unsigned int min_pretimeout;
+ unsigned int max_pretimeout;
void *driver_data;
struct mutex lock;
unsigned long status;
@@ -70,6 +73,9 @@ It contains following fields:
* timeout: the watchdog timer's timeout value (in seconds).
* min_timeout: the watchdog timer's minimum timeout value (in seconds).
* max_timeout: the watchdog timer's maximum timeout value (in seconds).
+* pretimeout: the watchdog timer's pretimeout value (in seconds).
+* min_pretimeout: the watchdog timer's minimum pretimeout value (in seconds).
+* max_pretimeout: the watchdog timer's maximum pretimeout value (in seconds).
* bootstatus: status of the device after booting (reported with watchdog
WDIOF_* status bits).
* driver_data: a pointer to the drivers private data of a watchdog device.
@@ -92,6 +98,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -153,9 +160,19 @@ they are supported. These optional routines/operations are:
and -EIO for "could not write value to the watchdog". On success this
routine should set the timeout value of the watchdog_device to the
achieved timeout value (which may be different from the requested one
- because the watchdog does not necessarily has a 1 second resolution).
+ because the watchdog does not necessarily has a 1 second resolution;
+ If the driver supports pretimeout, then the timeout value must be greater
+ than that).
(Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
watchdog's info structure).
+* set_pretimeout: this routine checks and changes the pretimeout of the
+ watchdog timer device. It returns 0 on success, -EINVAL for "parameter out of
+ range" and -EIO for "could not write value to the watchdog". On success this
+ routine should set the pretimeout value of the watchdog_device to the
+ achieved pretimeout value (which may be different from the requested one
+ because the watchdog does not necessarily has a 1 second resolution).
+ (Note: the WDIOF_PRETIMEOUT needs to be set in the options field of the
+ watchdog's info structure).
* get_timeleft: this routines returns the time that's left before a reset.
* ref: the operation that calls kref_get on the kref of a dynamically
allocated watchdog_device struct.
@@ -219,8 +236,28 @@ extern int watchdog_init_timeout(struct watchdog_device
*wdd,
unsigned int timeout_parm, struct device
*dev);
The watchdog_init_timeout function allows you to initialize the timeout field
-using the module timeout parameter or by retrieving the timeout-sec property
from
-the device tree (if the module timeout parameter is invalid). Best practice is
-to set the default timeout value as timeout value in the watchdog_device and
-then use this function to set the user "preferred" timeout value.
+using the module timeout parameter or by retrieving the first element of
+the timeout-sec property from the device tree (if the module timeout parameter
+is invalid). Best practice is to set the default timeout value as timeout value
+in the watchdog_device and then use this function to set the user "preferred"
+timeout value.
+This routine returns zero on success and a negative errno code for failure.
+
+Some watchdog timers have two stage of timeouts(timeout and pretimeout),
+to initialize the
[PATCH v3 1/6] Documentation: add sbsa-gwdt.txt documentation
From: Fu Wei
The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.
Acked-by: Arnd Bergmann
Signed-off-by: Fu Wei
---
.../devicetree/bindings/watchdog/sbsa-gwdt.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 000..010e5c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,36 @@
+* SBSA(Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used for resetting the system after
+two stages of timeout.
+More details: ARM-DEN-0029 - Server Base System Architecture (SBSA)
+
+Required properties:
+- compatible : Should at least contain "arm,sbsa-gwdt".
+
+- reg : base physical address of the frames and length of memory mapped region.
+
+- reg-names : Should contain the resource reg names to show the order of
+ the values in "reg".
+ Must include the following entries : "refresh", "control".
+
+- interrupts : Should at least contain WS0 interrupt,
+ the WS1 Signal is optional.
+
+- interrupt-names : Should contain the resource interrupt names.
+ Must include the following entries : "ws0". "ws1" is optional.
+
+Optional properties
+- timeout-sec : Watchdog pre-timeout and timeout values (in seconds).
+ The first is timeout values, then pre-timeout.
+
+Example for FVP Foundation Model v8:
+
+watchdog@2a44 {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x2a44 0 0x1>,
+ <0x0 0x2a45 0 0x1>;
+ reg-names = "control", "refresh";
+ interrupts = <0 27 4>;
+ interrupt-names = "ws0";
+ timeout-sec = <10 5>;
+};
--
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 1/3] f2fs crypto: check context consistent for rename2
For exchange rename, we should check context consistent of encryption
between new_dir and old_inode or old_dir and new_inode. Otherwise
inheritance of parent's encryption context will be broken.
Signed-off-by: Chao Yu
---
fs/f2fs/namei.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index daed09c..3188464 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -754,6 +754,15 @@ static int f2fs_cross_rename(struct inode *old_dir, struct
dentry *old_dentry,
int old_nlink = 0, new_nlink = 0;
int err = -ENOENT;
+ if ((old_dir != new_dir) &&
+ (!f2fs_is_child_context_consistent_with_parent(new_dir,
+ old_inode) ||
+ !f2fs_is_child_context_consistent_with_parent(old_dir,
+ new_inode))) {
+ err = -EPERM;
+ goto out;
+ }
+
f2fs_balance_fs(sbi);
old_entry = f2fs_find_entry(old_dir, &old_dentry->d_name, &old_page);
--
2.3.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 v3 6/6] ACPI: import watchdog info of GTDT into platform device
From: Fu Wei
Parse SBSA Generic Watchdog Structure in GTDT table of ACPI,
and create a platform device with that information.
This platform device can be used by the ARM SBSA Generic
Watchdog driver.
Tested-by: Suravee Suthikulpanit
Tested-by: Timur Tabi
Signed-off-by: Fu Wei
---
arch/arm64/kernel/acpi.c | 145 +++
1 file changed, 145 insertions(+)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 8b83955..c95deec 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -343,3 +344,147 @@ void __init acpi_gic_init(void)
early_acpi_os_unmap_memory((char *)table, tbl_size);
}
+
+static int __init acpi_gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
+int index)
+{
+ struct platform_device *pdev;
+ struct resource *res;
+ u32 gsi, flags;
+ int irq, trigger, polarity;
+ resource_size_t rf_base_phy, cf_base_phy;
+ int err = -ENOMEM;
+
+ /*
+* Get SBSA Generic Watchdog info
+* from a Watchdog GT type structure in GTDT
+*/
+ rf_base_phy = (resource_size_t)wd->refresh_frame_address;
+ cf_base_phy = (resource_size_t)wd->control_frame_address;
+ gsi = wd->timer_interrupt;
+ flags = wd->timer_flags;
+
+ pr_debug("GTDT: a Watchdog GT structure(0x%llx/0x%llx gsi:%u
flags:0x%x)\n",
+rf_base_phy, cf_base_phy, gsi, flags);
+
+ if (!(rf_base_phy && cf_base_phy && gsi)) {
+ pr_err("GTDT: failed geting the device info.\n");
+ return -EINVAL;
+ }
+
+ trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
+ : ACPI_LEVEL_SENSITIVE;
+ polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+ irq = acpi_register_gsi(NULL, gsi, trigger, polarity);
+ if (irq < 0) {
+ pr_err("GTDT: failed to register GSI of the Watchdog GT.\n");
+ return -EINVAL;
+ }
+
+ /*
+* Add a platform device named "sbsa-gwdt" to match the platform driver.
+* "sbsa-gwdt": SBSA(Server Base System Architecture) Generic Watchdog
+* The platform driver can get device info below by matching this name.
+*/
+ pdev = platform_device_alloc("sbsa-gwdt", index);
+ if (!pdev)
+ goto err_unregister_gsi;
+
+ res = kcalloc(3, sizeof(*res), GFP_KERNEL);
+ if (!res)
+ goto err_device_put;
+
+ /*
+* According to SBSA specification the size of refresh and control
+* frames of SBSA Generic Watchdog is SZ_4K(Offset 0x000 – 0xFFF).
+*/
+ res[0].start = rf_base_phy;
+ res[0].end = rf_base_phy + SZ_4K - 1;
+ res[0].name = "refresh";
+ res[0].flags = IORESOURCE_MEM;
+
+ res[1].start = cf_base_phy;
+ res[1].end = cf_base_phy + SZ_4K - 1;
+ res[1].name = "control";
+ res[1].flags = IORESOURCE_MEM;
+
+ res[2].start = irq;
+ res[2].end = res[2].start;
+ res[2].name = "ws0";
+ res[2].flags = IORESOURCE_IRQ;
+
+ err = platform_device_add_resources(pdev, res, 3);
+ if (err)
+ goto err_free_res;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_free_res;
+
+ return 0;
+
+err_free_res:
+ kfree(res);
+err_device_put:
+ platform_device_put(pdev);
+err_unregister_gsi:
+ acpi_unregister_gsi(gsi);
+
+ return err;
+}
+
+/* Initialize SBSA generic Watchdog platform device info from GTDT */
+static int __init acpi_gtdt_sbsa_gwdt_init(struct acpi_table_header *table)
+{
+ struct acpi_table_gtdt *gtdt;
+ struct acpi_gtdt_header *header;
+ void *gtdt_subtable;
+ int i, gwdt_index;
+ int ret = 0;
+
+ if (table->revision < 2) {
+ pr_warn("GTDT: Revision:%d doesn't support Platform Timers.\n",
+ table->revision);
+ return 0;
+ }
+
+ gtdt = container_of(table, struct acpi_table_gtdt, header);
+ if (!gtdt->platform_timer_count) {
+ pr_info("GTDT: No Platform Timer structures.\n");
+ return 0;
+ }
+
+ gtdt_subtable = (void *)gtdt + gtdt->platform_timer_offset;
+
+ for (i = 0, gwdt_index = 0; i < gtdt->platform_timer_count; i++) {
+ if (gtdt_subtable > (void *)table + table->length) {
+ pr_err("GTDT: subtable pointer overflows, bad table\n");
+ return -EINVAL;
+ }
+ header = (struct acpi_gtdt_header *)gtdt_subtable;
+ if (header->type == ACPI_GTDT_TYPE_WATCHDOG) {
+ ret = acpi_gtdt_import_sbsa_gwdt(gtdt_subtable,
+
[PATCH v3 2/6] ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts
From: Fu Wei
This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.
Acked-by: Arnd Bergmann
Signed-off-by: Fu Wei
---
arch/arm64/boot/dts/arm/foundation-v8.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts
b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..962a07e 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,14 @@
};
};
};
+ watchdog@2a44 {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x2a44 0 0x1>,
+ <0x0 0x2a45 0 0x1>;
+ reg-names = "control",
+ "refresh";
+ interrupts = <0 27 4>;
+ interrupt-names = "ws0";
+ timeout-sec = <10 5>;
+ };
};
--
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 v3 5/6] Watchdog: introduce ARM SBSA watchdog driver
From: Fu Wei
This driver bases on linux kernel watchdog framework, and
use "pretimeout" in the framework. It supports getting timeout and
pretimeout from parameter and FDT at the driver init stage.
In first timeout, the interrupt routine run panic to save
system context.
Acked-by: Arnd Bergmann
Tested-by: Suravee Suthikulpanit
Signed-off-by: Fu Wei
---
drivers/watchdog/Kconfig | 11 +
drivers/watchdog/Makefile| 1 +
drivers/watchdog/sbsa_gwdt.c | 474 +++
3 files changed, 486 insertions(+)
create mode 100644 drivers/watchdog/sbsa_gwdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e5e7c55..554f18a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -152,6 +152,17 @@ config ARM_SP805_WATCHDOG
ARM Primecell SP805 Watchdog timer. This will reboot your system when
the timeout is reached.
+config ARM_SBSA_WATCHDOG
+ tristate "ARM SBSA Generic Watchdog"
+ depends on ARM64
+ depends on ARM_ARCH_TIMER
+ select WATCHDOG_CORE
+ help
+ ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts.
+ The first timeout will trigger a panic; the second timeout will
+ trigger a system reset.
+ More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
config AT91RM9200_WATCHDOG
tristate "AT91RM9200 watchdog"
depends on SOC_AT91RM9200 && MFD_SYSCON
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c19294..471f1b7c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
# ARM Architecture
obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 000..0d1aff1
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,474 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei
+ * Suravee Suthikulpanit
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * Note: This SBSA Generic watchdog driver is compatible with
+ * the pretimeout concept of Linux kernel.
+ * The timeout and pretimeout are set by the different REGs.
+ * The first watch period is set by writing WCV directly,
+ * that can support more than 10s timeout at the maximum
+ * system counter frequency.
+ * The second watch period is set by WOR(32bit) which will be loaded
+ * automatically by hardware, when WS0 is triggered.
+ * This gives a maximum watch period of around 10s at the maximum
+ * system counter frequency.
+ * The System Counter shall run at maximum of 400MHz.
+ * More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * Kernel/API: P-| pretimeout
+ * |---T timeout
+ * SBSA GWDT: P--WOR---WS1 pretimeout
+ * |---WCV--WS0T timeout
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR 0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS 0x000
+#define SBSA_GWDT_WOR 0x008
+#define SBSA_GWDT_WCV_LO 0x010
+#define SBSA_GWDT_WCV_HI 0x014
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR 0xfcc
+#define SBSA_GWDT_IDR 0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN BIT(0)
+#define SBSA_GWDT_WCS_WS0 BIT(1)
+#define SBSA_GWDT_WCS_WS1 BIT(2)
+
+/**
+ * struct sbsa_gwdt - Internal representation of the SBSA GWDT
+ * @wdd: kernel watchdog_device structure
+ * @clk: store the System Counter clock frequency, in Hz.
+ * @refresh_base: Virtual address of the watchdog refresh frame
+ * @control_base: Virtual address of the watchdog control frame
+ */
+struct sbsa_gwdt {
+ struct watchdog_device wdd;
+ u32
[PATCH 3/3] f2fs crypto: allow setting encryption policy once
This patch add XATTR_CREATE flag in setxattr when setting encryption context for inode. Without this flag the context could be set more than once, this should never happen. So, fix it. Signed-off-by: Chao Yu --- fs/f2fs/crypto_policy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/crypto_policy.c b/fs/f2fs/crypto_policy.c index 56b2ac0..71b3a5a 100644 --- a/fs/f2fs/crypto_policy.c +++ b/fs/f2fs/crypto_policy.c @@ -83,7 +83,7 @@ static int f2fs_create_encryption_context_from_policy( return f2fs_setxattr(inode, F2FS_XATTR_INDEX_ENCRYPTION, F2FS_XATTR_NAME_ENCRYPTION_CONTEXT, &ctx, - sizeof(ctx), NULL, 0); + sizeof(ctx), NULL, XATTR_CREATE); } int f2fs_process_policy(const struct f2fs_encryption_policy *policy, @@ -202,5 +202,5 @@ int f2fs_inherit_context(struct inode *parent, struct inode *child, get_random_bytes(ctx.nonce, F2FS_KEY_DERIVATION_NONCE_SIZE); return f2fs_setxattr(child, F2FS_XATTR_INDEX_ENCRYPTION, F2FS_XATTR_NAME_ENCRYPTION_CONTEXT, &ctx, - sizeof(ctx), ipage, 0); + sizeof(ctx), ipage, XATTR_CREATE); } -- 2.3.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: [BUG] Read-Only THP causes stalls (commit 10359213d)
On Sun, May 24, 2015 at 09:34:04PM +0200, Christoffer Dall wrote: > Hi all, > > I noticed a regression on my arm64 APM X-Gene system a couple > of weeks back. I would occassionally see the system lock up and see RCU > stalls during the caching phase of kernbench. I then wrote a small > script that does nothing but cache the files > (http://paste.ubuntu.com/11324767/) and ran that in a loop. On a known > bad commit (v4.1-rc2), out of 25 boots, I never saw it get past 21 > iterations of the loop. I have since tried to run a bisect from v3.19 to > v4.0 using 100 iterations as my criteria for a good commit. > > This resulted in the following first bad commit: > > 10359213d05acf804558bda7cc9b8422a828d1cd > (mm: incorporate read-only pages into transparent huge pages, 2015-02-11) > > Indeed, running the workload on v4.1-rc4 still produced the behavior, > but reverting the above commit gets me through 100 iterations of the > loop. > > I have not tried to reproduce on an x86 system. Turning on a bunch > of kernel debugging features *seems* to hide the problem. My config for > the XGene system is defconfig + CONFIG_BRIDGE and > CONFIG_POWER_RESET_XGENE. > > Please let me know if I can help test patches or other things I can > do to help. I'm afraid that by simply reading the patch I didn't see > anything obviously wrong with it which would cause this behavior. I don't see the problem on x86. Some backtraces could help to track it down. -- Kirill A. Shutemov -- 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/3] f2fs crypto: check dir entry just for directory
This patch fixes to add a judgement condition to verify type of the
target inode before empty directory verification.
So wrong verification could be avoided for non-directory inode.
Signed-off-by: Chao Yu
---
fs/f2fs/crypto_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/crypto_policy.c b/fs/f2fs/crypto_policy.c
index bef254b..56b2ac0 100644
--- a/fs/f2fs/crypto_policy.c
+++ b/fs/f2fs/crypto_policy.c
@@ -93,7 +93,7 @@ int f2fs_process_policy(const struct f2fs_encryption_policy
*policy,
return -EINVAL;
if (!f2fs_inode_has_encryption_context(inode)) {
- if (!f2fs_empty_dir(inode))
+ if (S_ISDIR(inode->i_mode) && !f2fs_empty_dir(inode))
return -ENOTEMPTY;
return f2fs_create_encryption_context_from_policy(inode,
policy);
--
2.3.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 v6] serial: 8250_uniphier: add UniPhier serial driver
Hi Andy,
2015-05-25 18:14 GMT+09:00 Shevchenko, Andriy :
> On Mon, 2015-05-25 at 12:44 +0900, Masahiro Yamada wrote:
>> Add the driver for on-chip UART used on UniPhier SoCs.
>>
>> This hardware is similar to 8250, but the register mapping is
>> slightly different:
>> - The offset to FCR, MCR is different.
>> - The divisor latch access bit does not exist. Instead, the
>> divisor latch register is available at offset 9.
>>
>> This driver overrides serial_{in,out}, dl_{read,write} callbacks,
>> but wants to borrow most of code from 8250_core.c.
>
> Do not send series too often, let people to review what you did.
>
> More comments below.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "8250.h"
>> +
>> +/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
>> +#define UNIPHIER_UART_DEFAULT_FIFO_SIZE 64
>> +
>> +#define UNIPHIER_UART_CHAR_FCR 3 /* Character / FIFO Control
>> Register */
>> +#define UNIPHIER_UART_LCR_MCR4 /* Line/Modem Control Register
>> */
>> +#define UNIPHIER_UART_LCR_SHIFT8
>
> Indentation problem, needs to be fixed.
How should it be fixed?
Could you explain it more detailed, please?
>> +#define UNIPHIER_UART_DLR9 /* Divisor Latch Register */
>> +
>> +struct uniphier8250_priv {
>> + int line;
>> + struct clk *clk;
>> + spinlock_t atomic_write_lock;
>> +};
>> +
>> +/*
>> + * The register map is slightly different from that of 8250.
>> + * IO callbacks must be overridden for correct access to FCR, LCR, and MCR.
>> + */
>> +static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
>> +{
>> + int valshift = 0;
>
> Perhaps unsigned int?
OK, I will fix it (after waiting for some more comments).
>
>> + bool normal = false;
>> +
>> + switch (offset) {
>> + case UART_FCR:
>> + offset = UNIPHIER_UART_CHAR_FCR;
>> + break;
>> + case UART_LCR:
>> + valshift = UNIPHIER_UART_LCR_SHIFT;
>> + /* Divisor latch access bit does not exist. */
>> + value &= ~(UART_LCR_DLAB << valshift);
>> + /* fall through */
>> + case UART_MCR:
>> + offset = UNIPHIER_UART_LCR_MCR;
>> + break;
>> + default:
>> + normal = true;
>> + break;
>> + }
>> +
>> + offset <<= p->regshift;
>> +
>> + if (normal) {
>> + writel(value, p->membase + offset);
>
> Perhaps put this in place where normal == true and use return instead of
> break?
In that case, I do not know where I should put
offset <<= p->regshift
, which I want to run for all the cases.
--
Best Regards
Masahiro Yamada
--
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: [BUG] Read-Only THP causes stalls (commit 10359213d)
On Mon, May 25, 2015 at 01:05:15PM +0300, Kirill A. Shutemov wrote:
> On Sun, May 24, 2015 at 09:34:04PM +0200, Christoffer Dall wrote:
> > Hi all,
> >
> > I noticed a regression on my arm64 APM X-Gene system a couple
> > of weeks back. I would occassionally see the system lock up and see RCU
> > stalls during the caching phase of kernbench. I then wrote a small
> > script that does nothing but cache the files
> > (http://paste.ubuntu.com/11324767/) and ran that in a loop. On a known
> > bad commit (v4.1-rc2), out of 25 boots, I never saw it get past 21
> > iterations of the loop. I have since tried to run a bisect from v3.19 to
> > v4.0 using 100 iterations as my criteria for a good commit.
> >
> > This resulted in the following first bad commit:
> >
> > 10359213d05acf804558bda7cc9b8422a828d1cd
> > (mm: incorporate read-only pages into transparent huge pages, 2015-02-11)
> >
> > Indeed, running the workload on v4.1-rc4 still produced the behavior,
> > but reverting the above commit gets me through 100 iterations of the
> > loop.
> >
> > I have not tried to reproduce on an x86 system. Turning on a bunch
> > of kernel debugging features *seems* to hide the problem. My config for
> > the XGene system is defconfig + CONFIG_BRIDGE and
> > CONFIG_POWER_RESET_XGENE.
> >
> > Please let me know if I can help test patches or other things I can
> > do to help. I'm afraid that by simply reading the patch I didn't see
> > anything obviously wrong with it which would cause this behavior.
>
> I don't see the problem on x86.
I'm wondering if we could have some weird combination of how the
specific architecture works along with these patches...
>
> Some backtraces could help to track it down.
>
I don't really get backtraces as the sytem just locks up. But here are
some of the RCU stalls as I've observed them on the console:
http://paste.ubuntu.com/11014701/
http://paste.ubuntu.com/11023143/
http://paste.ubuntu.com/11023261/
Occasionally, I also get this error from the SATA system at the moment
when I power off the device, but not sure if it is related:
ata1: exception Emask 0x10 SAct 0x0 SErr 0x18 action 0xe frozen
ata1: irq_stat 0x0040, PHY RDY changed
ata1: SError: { 10B8B Dispar }
Thanks,
-Christoffer
--
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 0/3] Add support for Richtek RT9455 battery charger
Hello, The next 3 patches do the following: - first patch adds Richtek Technology Corporation in the vendor-prefixes list - second patch adds device tree binding example for Richtek RT9455 battery charger - third patch adds the driver for Richtek RT9455 battery charger Thanks, Anda Anda-Maria Nicolae (3): of: Add vendor prefix for Richtek Technology Corporation Documentation: devicetree: Add Richtek RT9455 bindings power_supply: Add support for Richtek RT9455 battery charger .../devicetree/bindings/power/rt9455_charger.txt | 46 + .../devicetree/bindings/vendor-prefixes.txt|1 + drivers/power/Kconfig |7 + drivers/power/Makefile |1 + drivers/power/rt9455_charger.c | 1821 5 files changed, 1876 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/rt9455_charger.txt create mode 100644 drivers/power/rt9455_charger.c -- 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 3/3] power_supply: Add support for Richtek RT9455 battery charger
Based on the datasheet found here:
http://www.richtek.com/download_ds.jsp?p=RT9455
Signed-off-by: Anda-Maria Nicolae
---
drivers/power/Kconfig |7 +
drivers/power/Makefile |1 +
drivers/power/rt9455_charger.c | 1821
3 files changed, 1829 insertions(+)
create mode 100644 drivers/power/rt9455_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index a848b1a..9bb906a 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -460,6 +460,13 @@ config BATTERY_RT5033
The fuelgauge calculates and determines the battery state of charge
according to battery open circuit voltage.
+config CHARGER_RT9455
+ tristate "Richtek RT9455 battery charger driver"
+ depends on I2C && GPIOLIB
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the Richtek RT9455 battery charger.
+
source "drivers/power/reset/Kconfig"
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 3572a72..5752ce8 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_BATTERY_MAX17040)+= max17040_battery.o
obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
obj-$(CONFIG_BATTERY_Z2) += z2_battery.o
obj-$(CONFIG_BATTERY_RT5033) += rt5033_battery.o
+obj-$(CONFIG_CHARGER_RT9455) += rt9455_charger.o
obj-$(CONFIG_BATTERY_S3C_ADC) += s3c_adc_battery.o
obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
obj-$(CONFIG_CHARGER_88PM860X) += 88pm860x_charger.o
diff --git a/drivers/power/rt9455_charger.c b/drivers/power/rt9455_charger.c
new file mode 100644
index 000..4f6db92
--- /dev/null
+++ b/drivers/power/rt9455_charger.c
@@ -0,0 +1,1821 @@
+/*
+ * Driver for Richtek RT9455WSC battery charger.
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RT9455_MANUFACTURER"Richtek"
+#define RT9455_MODEL_NAME "RT9455"
+#define RT9455_DRIVER_NAME "rt9455-charger"
+
+#define RT9455_IRQ_NAME"interrupt"
+
+#define RT9455_PWR_RDY_DELAY 1 /* 1 second */
+#define RT9455_MAX_CHARGING_TIME 21600 /* 6 hrs */
+#define RT9455_BATT_PRESENCE_DELAY 60 /* 60 seconds */
+
+#define RT9455_CHARGE_MODE 0x00
+#define RT9455_BOOST_MODE 0x01
+
+#define RT9455_FAULT 0x03
+
+#define RT9455_IAICR_100MA 0x00
+#define RT9455_IAICR_500MA 0x01
+#define RT9455_IAICR_NO_LIMIT 0x03
+
+#define RT9455_CHARGE_DISABLE 0x00
+#define RT9455_CHARGE_ENABLE 0x01
+
+#define RT9455_PWR_FAULT 0x00
+#define RT9455_PWR_GOOD0x01
+
+#define RT9455_REG_CTRL1 0x00 /* CTRL1 reg address */
+#define RT9455_REG_CTRL2 0x01 /* CTRL2 reg address */
+#define RT9455_REG_CTRL3 0x02 /* CTRL3 reg address */
+#define RT9455_REG_DEV_ID 0x03 /* DEV_ID reg address */
+#define RT9455_REG_CTRL4 0x04 /* CTRL4 reg address */
+#define RT9455_REG_CTRL5 0x05 /* CTRL5 reg address */
+#define RT9455_REG_CTRL6 0x06 /* CTRL6 reg address */
+#define RT9455_REG_CTRL7 0x07 /* CTRL7 reg address */
+#define RT9455_REG_IRQ10x08 /* IRQ1 reg
address */
+#define RT9455_REG_IRQ20x09 /* IRQ2 reg
address */
+#define RT9455_REG_IRQ30x0A /* IRQ3 reg
address */
+#define RT9455_REG_MASK1 0x0B /* MASK1 reg address */
+#define RT9455_REG_MASK2 0x0C /* MASK2 reg address */
+#define RT9455_REG_MASK3 0x0D /* MASK3 reg address */
+
+enum rt9455_fields {
+ F_STAT, F_BOOST, F_PWR_RDY, F_OTG_PIN_POLARITY, /* CTRL1 reg fields */
+
+ F_IAICR, F_TE_SHDN_EN, F_HIGHER_OCP, F_TE, F_IAICR_INT, F_HIZ,
+ F_OPA_MODE, /* CTRL2 reg fields */
+
+ F_VOREG, F_OTG_PL, F_OTG_EN, /* CTRL3 reg fields */
+
+ F_VENDOR_ID, F_CHIP_REV, /* DEV_ID reg fields */
+
+
[PATCH 1/3] of: Add vendor prefix for Richtek Technology Corporation
Signed-off-by: Anda-Maria Nicolae --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8033919..7b8c129 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -161,6 +161,7 @@ ralink Mediatek/Ralink Technology Corp. ramtronRamtron International realtek Realtek Semiconductor Corp. renesasRenesas Electronics Corporation +richtekRichtek Technology Corporation ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsungSamsung Semiconductor -- 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/3] Documentation: devicetree: Add Richtek RT9455 bindings
Signed-off-by: Anda-Maria Nicolae
---
.../devicetree/bindings/power/rt9455_charger.txt | 46
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/rt9455_charger.txt
diff --git a/Documentation/devicetree/bindings/power/rt9455_charger.txt
b/Documentation/devicetree/bindings/power/rt9455_charger.txt
new file mode 100644
index 000..bb46842
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/rt9455_charger.txt
@@ -0,0 +1,46 @@
+Binding for Richtek rt9455 battery charger
+
+Required properties:
+- compatible: Should contain one of the following:
+ * "richtek,rt9455"
+
+- reg: integer, i2c address of the device.
+- richtek,output-charge-current: integer, output current in uA, from the
+ charger to the battery.
+- richtek,end-of-charge-percentage:integer, percent of the output charge
current.
+ When the current in constant-voltage
phase drops
+ below output_charge_current x
end-of-charge-percentage,
+ charge is terminated.
+- richtek,battery-regulation-voltage: integer, maximum battery voltage in uV.
+- richtek,boost-output-voltage:integer, maximum voltage in uV,
provided to consumer
+ devices, when the charger is in boost
mode.
+
+Optional properties:
+- richtek,min-input-voltage-regulation: integer, input voltage threshold in
uA, used to
+ determine when to decrease voltage
level when
+ the over current of the input power
source occurs.
+ This prevents input voltage drop due to
insufficient
+ current provided by the power source.
+- richtek,avg-input-current-regulation: integer, input current in uA, the
charger should
+ drain from the power source.
+
+Example:
+
+rt9455@22 {
+ compatible = "richtek,rt9455";
+ reg = <0x22>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <0 1>;
+
+ interrupt-gpio = <&gpio1 0 1>;
+ reset-gpio = <&gpio1 1 1>;
+
+ richtek,output-charge-current = <50>;
+ richtek,end-of-charge-percentage= <10>;
+ richtek,battery-regulation-voltage = <420>;
+ richtek,boost-output-voltage= <505>;
+
+ richtek,min-input-voltage-regulation = <450>;
+ richtek,avg-input-current-regulation = <50>;
+};
--
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 v3 2/2] soc: Add driver for Freescale Vybrid Platform
Hello Arnd, On 15-05-22 15:20:00, Arnd Bergmann wrote: > On Friday 22 May 2015 14:02:52 Stefan Agner wrote: > > > Can you use syscon_regmap_lookup_by_phandle instead, and put the > > > phandles in the fsl,vf610-mscm-cpucfg node? > > > > Hm, with that we would wire up hardware modules which does nothing has > > to do with each other. We just happen to need a driver which collects > > information accross the SoC. I'm not sure we should put the modules > > required into the device tree. > > > > I don't think its nice to have the compatible strings in the source > > code, however it feels more appropriate than in the device tree, IMHO... > > I see. Another option would be to point directly to the registers > you need: > > ocotp-cfg0 = <&ocotp 0x10>; > ocotp-cfg1 = <&ocotp 0x20>; > rom-revision = <&rom 0x80>; > > We don't yet have an abstraction to access a register from a syscon > reference like this, but you could either roll your own here, or > add a generic abstraction. Can you tell me a little about how can I start implementing it? I am not clear on how to approach this. > > > > Also, I'd argue that the mscm should not be a syscon device at all, > > > but instead I'd use platform_get_resource()/devm_ioremap_resource() > > > to get an __iomem pointer. > > > > We need to have mscm-cpucfg to be syscon because we need to get the CPU > > personality in the MSCM interrupt router driver (irq-vf610-mscm-ir.c). > > It can be both at the same time now. > > Arnd Regards, Sanchayan. -- 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] drm/atomic: fix out of bounds read in for_each_*_in_state helpers
for_each_*_in_state validate array index after
access to array elements, thus perform out of bounds read.
Fix this by validating index in the first place and read
array element iff validation was successful.
Fixes: df63b9994eaf ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state
helper macros")
Signed-off-by: Andrey Ryabinin
---
include/drm/drm_atomic.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index c1571034..3f13b91 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -77,26 +77,26 @@ int __must_check drm_atomic_async_commit(struct
drm_atomic_state *state);
#define for_each_connector_in_state(state, connector, connector_state, __i) \
for ((__i) = 0; \
-(connector) = (state)->connectors[__i],\
-(connector_state) = (state)->connector_states[__i],\
-(__i) < (state)->num_connector;\
+(__i) < (state)->num_connector && \
+((connector) = (state)->connectors[__i], \
+(connector_state) = (state)->connector_states[__i], 1);\
(__i)++) \
if (connector)
#define for_each_crtc_in_state(state, crtc, crtc_state, __i) \
for ((__i) = 0; \
-(crtc) = (state)->crtcs[__i], \
-(crtc_state) = (state)->crtc_states[__i], \
-(__i) < (state)->dev->mode_config.num_crtc;\
+(__i) < (state)->dev->mode_config.num_crtc && \
+((crtc) = (state)->crtcs[__i], \
+(crtc_state) = (state)->crtc_states[__i], 1); \
(__i)++) \
if (crtc_state)
-#define for_each_plane_in_state(state, plane, plane_state, __i)\
- for ((__i) = 0; \
-(plane) = (state)->planes[__i],\
-(plane_state) = (state)->plane_states[__i],\
-(__i) < (state)->dev->mode_config.num_total_plane; \
-(__i)++) \
+#define for_each_plane_in_state(state, plane, plane_state, __i)
\
+ for ((__i) = 0; \
+(__i) < (state)->dev->mode_config.num_total_plane && \
+((plane) = (state)->planes[__i], \
+(plane_state) = (state)->plane_states[__i], 1);\
+(__i)++) \
if (plane_state)
#endif /* DRM_ATOMIC_H_ */
--
2.4.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/
Re: [PATCH 1/4] arm64: gicv3: its: Encode domain number in PCI stream id
On Fri, 22 May 2015 23:57:40 +0100 "Chalamarla, Tirumalesh" wrote: Hi Tirumalesh, > > > On May 22, 2015, at 1:26 AM, Marc Zyngier wrote: > > > > On 20/05/15 13:48, Robert Richter wrote: > >> Mark, > >> > >> thanks for review, also of the other patches of this series. > >> > >> See below > >> > >> On 20.05.15 13:11:38, Marc Zyngier wrote: > -dev_alias->dev_id = alias; > +dev_alias->dev_id = (pci_domain_nr(pdev->bus) << 16) | alias; > >> > >>> This feels very scary. We're now assuming that the domain number will > >>> always be presented to the doorbell. What guarantee do we have that > >>> this is always the case, irrespective of the platform? > >>> > >>> Also, domains have no PCI reality, they are a Linux thing. And they can > >>> be "randomly" assigned, unless you force the domain in DT with a > >>> linux,pci-domain property. This looks even more wrong, specially > >>> considering ACPI. > >> > >> The main problem here is that device ids (32 bits) are system > >> specific. Since we have more than one PCI root complex we need the > >> upper 16 bits in the devid for mapping. Using pci_domain_nr for this > >> fits our needs for now and shouldn't affect systems with a single RC > >> only as the domain nr is zero then. > >> > >> The domain number is incremented during initialization beginnig with > >> zero and the order of it is fixed since it is taken from DT or ACPI > >> tables. So we have full controll of it. I don't see issues here. > > > > This may match what you have on ThunderX (as long as the kernel doesn't > > adopt another behaviour when allocating the domain number). But other > > platforms may have a completely different numbering, which will mess > > them up entirely. > > > >>> It really feels like we need a way to describe how the BDF numbering is > >>> augmented. We also need to guarantee that we get the actual bridge > >>> number, as opposed to the domain number. > >> > >> But true, the obove is just intermediate. In the end we need some sort > >> of handler that is setup during cpu initialization that registers a > >> callback for the gic to determine the device id of that paricular > >> system. > > > > I don't really like the idea of a callback from the GIC - I'd prefer it > > to be standalone, and rely on the topology information to build the > > DeviceID. Mark Rutland had some ideas for DT (he posted an RFC a while > > ago), maybe it would be good to get back to that and find out what we > > can do. ACPI should also have similar information (IORT?). > > > > How can some one pass this from DT, especially in GIC entry. i still > think it is bus owner responsibility and call back is better idea. > but if some one has a better idea for DT and ACPI, we are fine as > long as it works on ThunderX. A callback would have to be bus-specific, and depends from the observer of the access. There is strictly no guarantee that a single write from the device is performed using the same ID to the IOMMU and to the MSI doorbell. Actually, they are very likely to be different. A generic callback would have to know about the point where this access is observed, and expressing this is a nightmare. Also, I'm really opposed to having platform-specific code that has for sole purpose to describe the hardware. This is why we have DT (and to a lesser extent ACPI). We've been there on 32bit, and learned our lesson. It doesn't scale, it leads to a bunch of hacks in all corners, and I don't feel like being on the receiving end of something like this. I really suggest you look at Mark's suggestion: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333199.html http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/341584.html because so far, this is the only proposal that makes any sense to me in the long run. Feel free to comment on it and help us making something that also work for your favorite SoC. Thanks, M. -- Without deviation from the norm, progress is not possible. -- 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/
linux-next: build failure after merge of the userns tree
Hi Eric,
After merging the userns tree, today's linux-next build (powerpc allnoconfig)
failed like this:
In file included from include/linux/kobject.h:21:0,
from include/linux/device.h:17,
from arch/powerpc/include/asm/io.h:27,
from arch/powerpc/include/asm/pgtable-ppc32.h:9,
from arch/powerpc/include/asm/pgtable.h:19,
from include/linux/mm.h:53,
from include/linux/pid_namespace.h:6,
from include/linux/ptrace.h:8,
from arch/powerpc/mm/fault.c:24:
include/linux/sysfs.h: In function 'sysfs_remove_mount_point':
include/linux/sysfs.h:314:2: error: 'return' with a value, in function
returning void [-Werror]
return 0;
^
and many more :-(
Caused by commit f7e299595408 ("sysfs: Add support for permanently
empty directories to serve as mount points.").
I have added the following fix patch for today:
From: Stephen Rothwell
Date: Mon, 25 May 2015 20:20:44 +1000
Subject: [PATCH] sysfs: void functions do not return values
Signed-off-by: Stephen Rothwell
---
include/linux/sysfs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 3e7e41acc451..9f65758311a4 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -311,7 +311,6 @@ static inline int sysfs_create_mount_point(struct kobject
*parent_kobj,
static inline void sysfs_remove_mount_point(struct kobject *parent_kobj,
const char *name)
{
- return 0;
}
static inline int sysfs_create_file_ns(struct kobject *kobj,
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpNesT00X3O_.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer
* Huang Rui wrote: > No, the timeout value doesn't decide how 'deep' the power state > enters. Basically, the same power consumption with any timeout. > > I summarized the comparison of mwait and mwaitx > > MWAIT MWAITX > opcode 0f 01 c9 |0f 01 fb > ECX[0] value of RFLAGS.IF seen by instruction > ECX[1] unused/#GP if set |enable timer if set > ECX[31:2] unused/#GP if set > EAX unused > EBX[31:0] unused |max wait time (loops) > > > MONITOR MONITORX > opcode 0f 01 c8 |0f 01 fa > EAX (logical) address to monitor > ECX #GP if not zero Ok, thanks for the clarification! Thanks, Ingo -- 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: fix wrong DEBUG configuration
* Martin Liška wrote: > Currently, GCC optimizes -O6 same as -O3 level, thus change the value > to -O6. s/to -O6 to -O3 > Right optimize debugging experience is given by passing -Og to > compiler. Assign default value for pointers that are identified by > compiler as non-initialized. s/Right optimize debugging experience is given/ Correct debugging experience is given/ s/identified by compiler identified by the compiler > ifeq ($(DEBUG),0) > - CFLAGS += -O6 > + CFLAGS += -O3 > +else > + CFLAGS += $(call cc-option,-Og,-O0) > endif > +# try-run > +# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise) > +# Exit code chooses option. "$$TMP" is can be used as temporary file and > +# is automatically cleaned up. > +try-run = $(shell set -e;\ > + TMP="$(TMPOUT)..tmp"; \ > + TMPO="$(TMPOUT)..o";\ > + if ($(1)) >/dev/null 2>&1; \ > + then echo "$(2)"; \ > + else echo "$(3)"; \ > + fi; \ > + rm -f "$$TMP" "$$TMPO") > + > +# cc-option > +# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586) > + > +cc-option = $(call try-run,\ > + $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o > "$$TMP",$(1),$(2)) Looks good to me! Acked-by: Ingo Molnar Thanks, Ingo -- 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 v1] tree-wide: remove "select FW_LOADER" uses
On Fri, 2015-05-22 at 14:43 -0700, j...@joshtriplett.org wrote: > Ideally, someone should teach Kconfig to handle recursive dependencies, I'm probably reading too much in this remark, but how should it handle that other than returning an error because the configuration it's fed makes it run in circles? Paul Bolle -- 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] ARM: module: Add ".ref.text" to arm unwind tables
Forgot to add Maintainers. Adding them now.
> On 05/13/2015 08:20 AM, Vignesh Radhakrishnan wrote:
>> Functions inside kernel modules that use __ref
>> will end up being placed in .ARM.exidx.ref.text
>> section by gcc.
>>
>> Currently we don't consider adding these functions
>> to arm unwind tables.
>>
>> Hence, if we turn slub debug on by default we end up
>> with the messages of this sort:
>>
>> unwind: Index not found bf0011e0
>>
>> This is because slub debug saves stack trace of
>> allocation's and free's. Therefore, we end up seeing
>> a flood of these messages in dmesg since its not
>> able to locate these functions.
>>
>> Fix this by adding .ref.text section to arm unwind tables.
>>
>
> With this patch, I go from
>
> [ cut here ]
> WARNING: CPU: 0 PID: 63 at drivers/misc/test.c:12 that_function+0x10/0x2c
> [test]()
> Modules linked in: test(P+)
> CPU: 0 PID: 63 Comm: insmod Tainted: P4.1.0-rc2+ #28
> Hardware name: ARM-Versatile PB
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from []
> (warn_slowpath_common+0x78/0xb0)
> [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x1c/0x24)
> [] (warn_slowpath_null) from []
> (that_function+0x10/0x2c [test])
> unwind: Index not found bf48
> ---[ end trace 3e24f8edd90f3b27 ]---
>
> to
>
> [ cut here ]
> WARNING: CPU: 0 PID: 63 at drivers/misc/test.c:12 that_function+0x10/0x2c
> [test]()
> Modules linked in: test(P+)
> CPU: 0 PID: 63 Comm: insmod Tainted: P4.1.0-rc2+ #30
> Hardware name: ARM-Versatile PB
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from []
> (warn_slowpath_common+0x78/0xb0)
> [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x1c/0x24)
> [] (warn_slowpath_null) from []
> (that_function+0x10/0x2c [test])
> [] (that_function [test]) from []
> (awesome_module+0x10/0x1c [test])
> [] (awesome_module [test]) from []
> (do_one_initcall+0x80/0x1dc)
> [] (do_one_initcall) from []
> (do_init_module+0x58/0x1a8)
> [] (do_init_module) from []
> (load_module+0x170c/0x1c38)
> [] (load_module) from [] (SyS_init_module+0xcc/0x124)
> [] (SyS_init_module) from []
> (ret_fast_syscall+0x0/0x30)
> ---[ end trace 554c9ff461eb2505 ]---
>
> Tested-by: Laura Abbott
>
>> Signed-off-by: Vignesh Radhakrishnan
>> ---
>> arch/arm/include/asm/module.h | 1 +
>> arch/arm/kernel/module.c | 4
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/module.h
>> b/arch/arm/include/asm/module.h
>> index ed690c4..17640c9 100644
>> --- a/arch/arm/include/asm/module.h
>> +++ b/arch/arm/include/asm/module.h
>> @@ -14,6 +14,7 @@ enum {
>> ARM_SEC_DEVEXIT,
>> ARM_SEC_HOT,
>> ARM_SEC_UNLIKELY,
>> +ARM_SEC_REF,
>> ARM_SEC_MAX,
>> };
>>
>> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
>> index 2e11961..846b888 100644
>> --- a/arch/arm/kernel/module.c
>> +++ b/arch/arm/kernel/module.c
>> @@ -308,6 +308,8 @@ int module_finalize(const Elf32_Ehdr *hdr, const
>> Elf_Shdr *sechdrs,
>> maps[ARM_SEC_UNLIKELY].unw_sec = s;
>> else if (strcmp(".ARM.exidx.text.hot", secname) == 0)
>> maps[ARM_SEC_HOT].unw_sec = s;
>> +else if (strcmp(".ARM.exidx.ref.text", secname) == 0)
>> +maps[ARM_SEC_REF].unw_sec = s;
>> else if (strcmp(".init.text", secname) == 0)
>> maps[ARM_SEC_INIT].txt_sec = s;
>> else if (strcmp(".text", secname) == 0)
>> @@ -318,6 +320,8 @@ int module_finalize(const Elf32_Ehdr *hdr, const
>> Elf_Shdr *sechdrs,
>> maps[ARM_SEC_UNLIKELY].txt_sec = s;
>> else if (strcmp(".text.hot", secname) == 0)
>> maps[ARM_SEC_HOT].txt_sec = s;
>> +else if (strcmp(".ref.text", secname) == 0)
>> +maps[ARM_SEC_REF].txt_sec = s;
>> }
>>
>> for (i = 0; i < ARM_SEC_MAX; i++)
>>
>
>
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of the Code Aurora Forum, hosted by The Linux Foundation.
again
--
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 v1] tree-wide: remove "select FW_LOADER" uses
On Fri, 2015-05-22 at 21:28 +0200, Luis R. Rodriguez wrote: > > So I see your GYM and LOCKER example, or better, the original FW & > > CRYPTO warning and I wonder why do we actually go and check dependencies > > of selected symbols when resolving given symbol. > > I'm no kconfig expert and I wondered the same. > > Perhaps Paul can elaborate. Because both the dependencies of a symbol and the select statements on that symbol influence the set of values that is possible for that symbol. Paul Bolle -- 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 1/6] Documentation: dmaengine: pxa-dma design
Robert Jarzmik writes: > Robert Jarzmik writes: > >> Robert Jarzmik writes: >> >> Hi Vinod, >> >> ... removed most of the people as this is a non-technical mail ... >> >> I hope to land this in the upcoming merge window. We're at -rc3, so time is >> short. Apart from patch 6/6 where I still have Maxime's review to apply, are >> you >> satisfied with the v3 of this serie which I hope addresses all your comments >> so >> far ? > > Vinod, we're at -rc4 now, ping ? Hello Vinod, I still didn't receive any answer. I feeling I'm gonna miss the merge window again if nothing moves. If I miss again this merge window, I'll take that through the pxa tree. Arnd might not be pleased, but this serie was submitted more than 2 monthes ago [1], and missing a merge window is really getting to be tiring, especially when nothing can be broken in an existing support platform. I hope you'll be able to include it in the upcoming window. Thanks. -- Robert [1] https://lwn.net/Articles/637500/ -- 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: fix wrong DEBUG configuration
On 05/25/2015 12:47 PM, Ingo Molnar wrote:
* Martin Liška wrote:
Currently, GCC optimizes -O6 same as -O3 level, thus change the value
to -O6.
s/to -O6
to -O3
Right optimize debugging experience is given by passing -Og to
compiler. Assign default value for pointers that are identified by
compiler as non-initialized.
s/Right optimize debugging experience is given/
Correct debugging experience is given/
s/identified by compiler
identified by the compiler
ifeq ($(DEBUG),0)
- CFLAGS += -O6
+ CFLAGS += -O3
+else
+ CFLAGS += $(call cc-option,-Og,-O0)
endif
+# try-run
+# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
+# Exit code chooses option. "$$TMP" is can be used as temporary file and
+# is automatically cleaned up.
+try-run = $(shell set -e; \
+ TMP="$(TMPOUT)..tmp"; \
+ TMPO="$(TMPOUT)..o"; \
+ if ($(1)) >/dev/null 2>&1;\
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi; \
+ rm -f "$$TMP" "$$TMPO")
+
+# cc-option
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+
+cc-option = $(call try-run,\
+ $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o
"$$TMP",$(1),$(2))
Looks good to me!
Acked-by: Ingo Molnar
Thanks,
Ingo
Thank you for review.
This is final version of the patch, where I appended your acknowledgment.
Martin
Currently, GCC optimizes -O6 same as -O3 level, thus change the value
to -O3.
Right debugging experience is given by passing -Og to compiler.
Assign default value for pointers that are identified by the compiler as
non-initialized.
Signed-off-by: Martin Liska
Acked-by: Ingo Molnar
---
tools/perf/arch/common.c| 2 +-
tools/perf/config/Makefile | 4 +++-
tools/perf/config/utilities.mak | 19 +++
tools/perf/util/symbol.c| 2 +-
tools/perf/util/trace-event-parse.c | 2 +-
5 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index 49776f1..b7bb42c 100644
--- a/tools/perf/arch/common.c
+++ b/tools/perf/arch/common.c
@@ -61,7 +61,7 @@ const char *const mips_triplets[] = {
static bool lookup_path(char *name)
{
bool found = false;
- char *path, *tmp;
+ char *path, *tmp = NULL;
char buf[PATH_MAX];
char *env = getenv("PATH");
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index e3b3724..47e4ae1 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -129,7 +129,9 @@ ifndef DEBUG
endif
ifeq ($(DEBUG),0)
- CFLAGS += -O6
+ CFLAGS += -O3
+else
+ CFLAGS += $(call cc-option,-Og,-O0)
endif
ifdef PARSER_DEBUG
diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak
index c16ce83..0ebef09 100644
--- a/tools/perf/config/utilities.mak
+++ b/tools/perf/config/utilities.mak
@@ -177,3 +177,22 @@ $(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
endef
_ge_attempt = $(if $(get-executable),$(get-executable),$(call _gea_err,$(2)))
_gea_err = $(if $(1),$(error Please set '$(1)' appropriately))
+
+# try-run
+# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
+# Exit code chooses option. "$$TMP" is can be used as temporary file and
+# is automatically cleaned up.
+try-run = $(shell set -e; \
+ TMP="$(TMPOUT)..tmp"; \
+ TMPO="$(TMPOUT)..o"; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi;\
+ rm -f "$$TMP" "$$TMPO")
+
+# cc-option
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+
+cc-option = $(call try-run,\
+ $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 82a31fd..a19fbd4 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -400,7 +400,7 @@ static struct symbol *symbols__find_by_name(struct rb_root *symbols,
const char *name)
{
struct rb_node *n;
- struct symbol_name_rb_node *s;
+ struct symbol_name_rb_node *s = NULL;
if (symbols == NULL)
return NULL;
diff --git a/tools/perf/util/trace-event-parse.c b/tools/perf/util/trace-event-parse.c
index 25d6c73..d495741 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -173,7 +173,7 @@ void parse_ftrace_printk(struct pevent *pevent,
char *line;
char *next = NULL;
char *addr_str;
- char *fmt;
+ char *fmt = NULL;
line = strtok_r(file, "\n", &next);
while (line) {
--
2.1.4
linux-next: build failure after merge of the extcon tree
Hi all,
After merging the extcon tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/power/axp288_charger.c: In function 'axp288_charger_probe':
drivers/power/axp288_charger.c:851:8: error: incompatible type for argument 2
of 'extcon_register_notifier'
ret = extcon_register_notifier(info->cable.edev, &info->cable.nb);
^
In file included from drivers/power/axp288_charger.c:29:0:
include/linux/extcon.h:240:12: note: expected 'enum extcon' but argument is of
type 'struct notifier_block *'
extern int extcon_register_notifier(struct extcon_dev *edev, enum extcon id,
^
drivers/power/axp288_charger.c:851:8: error: too few arguments to function
'extcon_register_notifier'
ret = extcon_register_notifier(info->cable.edev, &info->cable.nb);
^
In file included from drivers/power/axp288_charger.c:29:0:
include/linux/extcon.h:240:12: note: declared here
extern int extcon_register_notifier(struct extcon_dev *edev, enum extcon id,
^
drivers/power/axp288_charger.c:912:2: error: incompatible type for argument 2
of 'extcon_unregister_notifier'
extcon_unregister_notifier(info->cable.edev, &info->cable.nb);
^
In file included from drivers/power/axp288_charger.c:29:0:
include/linux/extcon.h:242:12: note: expected 'enum extcon' but argument is of
type 'struct notifier_block *'
extern int extcon_unregister_notifier(struct extcon_dev *edev, enum extcon id,
^
drivers/power/axp288_charger.c:912:2: error: too few arguments to function
'extcon_unregister_notifier'
extcon_unregister_notifier(info->cable.edev, &info->cable.nb);
^
In file included from drivers/power/axp288_charger.c:29:0:
include/linux/extcon.h:242:12: note: declared here
extern int extcon_unregister_notifier(struct extcon_dev *edev, enum extcon id,
^
drivers/power/axp288_charger.c: In function 'axp288_charger_remove':
drivers/power/axp288_charger.c:923:2: error: incompatible type for argument 2
of 'extcon_unregister_notifier'
extcon_unregister_notifier(info->cable.edev, &info->cable.nb);
^
In file included from drivers/power/axp288_charger.c:29:0:
include/linux/extcon.h:242:12: note: expected 'enum extcon' but argument is of
type 'struct notifier_block *'
extern int extcon_unregister_notifier(struct extcon_dev *edev, enum extcon id,
^
drivers/power/axp288_charger.c:923:2: error: too few arguments to function
'extcon_unregister_notifier'
extcon_unregister_notifier(info->cable.edev, &info->cable.nb);
^
In file included from drivers/power/axp288_charger.c:29:0:
include/linux/extcon.h:242:12: note: declared here
extern int extcon_unregister_notifier(struct extcon_dev *edev, enum extcon id,
^
Caused by commit 843735b788a4 ("power: axp288_charger: axp288 charger
driver") from the battery tree interacting with commit 046050f6e623
("extcon: Update the prototype of extcon_register_notifier() with enum
extcon") from the extcon tree.
I applied this merge fix patch for tday and can carry it as necessary
(it is clearly not correct, but it will make it build):
From: Stephen Rothwell
Date: Mon, 25 May 2015 21:00:24 +1000
Subject: [PATCH] power: axp288_charger: fix for AIP change
Signed-off-by: Stephen Rothwell
---
drivers/power/axp288_charger.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/axp288_charger.c b/drivers/power/axp288_charger.c
index 5680317f4823..e4d569f57acc 100644
--- a/drivers/power/axp288_charger.c
+++ b/drivers/power/axp288_charger.c
@@ -848,7 +848,7 @@ static int axp288_charger_probe(struct platform_device
*pdev)
/* Register for extcon notification */
INIT_WORK(&info->cable.work, axp288_charger_extcon_evt_worker);
info->cable.nb.notifier_call = axp288_charger_handle_cable_evt;
- ret = extcon_register_notifier(info->cable.edev, &info->cable.nb);
+ ret = extcon_register_notifier(info->cable.edev, EXTCON_NONE,
&info->cable.nb);
if (ret) {
dev_err(&info->pdev->dev,
"failed to register extcon notifier %d\n", ret);
@@ -909,7 +909,7 @@ intr_reg_failed:
extcon_unregister_interest(&info->otg.cable);
power_supply_unregister(info->psy_usb);
psy_reg_failed:
- extcon_unregister_notifier(info->cable.edev, &info->cable.nb);
+ extcon_unregister_notifier(info->cable.edev, EXTCON_NONE,
&info->cable.nb);
return ret;
}
@@ -920,7 +920,7 @@ static int axp288_charger_remove(struct platform_device
*pdev)
if (info->otg.cable.edev)
extcon_unregister_interest(&info->otg.cable);
- extcon_unregister_notifier(info->cable.edev, &info->cable.nb);
+ extcon_unregister_notifier(info->cable.edev, EXTCON_NONE,
&info->cable.nb);
power_supply_unregister(info->psy_usb);
return 0;
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7A6q3e7f6s.pgp
Description: OpenPGP digital signature
Re: [PATCH] perf: fix wrong DEBUG configuration
* Martin Liška wrote: > >>Right optimize debugging experience is given by passing -Og to > >>compiler. Assign default value for pointers that are identified by > >>compiler as non-initialized. > > > >s/Right optimize debugging experience is given/ > > Correct debugging experience is given/ > Right debugging experience is given by passing -Og to compiler. So I fixed the spelling here once already :-/ If you want to use 'right' in this context then use it like this: The right debugging experience is given by ... Or you can use what I suggested first: Correct debugging experience is given by ... Thanks, Ingo -- 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 v1] tree-wide: remove "select FW_LOADER" uses
On Fri, 2015-05-22 at 11:52 -0700, Dmitry Torokhov wrote: > selects still don't cascade down - right? select statements trigger the select statements of the selected symbol, if that's what you mean. Paul Bolle -- 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: fix wrong DEBUG configuration
On 05/25/2015 01:09 PM, Ingo Molnar wrote:
* Martin Liška wrote:
Right optimize debugging experience is given by passing -Og to
compiler. Assign default value for pointers that are identified by
compiler as non-initialized.
s/Right optimize debugging experience is given/
Correct debugging experience is given/
Right debugging experience is given by passing -Og to compiler.
So I fixed the spelling here once already :-/ If you want to use
'right' in this context then use it like this:
The right debugging experience is given by ...
Or you can use what I suggested first:
Correct debugging experience is given by ...
Thanks,
Ingo
Sorry Ingo for that, I overlooked that correction :)
Attached version should reflect that.
Thanks,
Martin
Currently, GCC optimizes -O6 same as -O3 level, thus change the value
to -O3.
Correct debugging experience is given by passing -Og to compiler.
Assign default value for pointers that are identified by the compiler as
non-initialized.
Signed-off-by: Martin Liska
Acked-by: Ingo Molnar
---
tools/perf/arch/common.c| 2 +-
tools/perf/config/Makefile | 4 +++-
tools/perf/config/utilities.mak | 19 +++
tools/perf/util/symbol.c| 2 +-
tools/perf/util/trace-event-parse.c | 2 +-
5 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/tools/perf/arch/common.c b/tools/perf/arch/common.c
index 49776f1..b7bb42c 100644
--- a/tools/perf/arch/common.c
+++ b/tools/perf/arch/common.c
@@ -61,7 +61,7 @@ const char *const mips_triplets[] = {
static bool lookup_path(char *name)
{
bool found = false;
- char *path, *tmp;
+ char *path, *tmp = NULL;
char buf[PATH_MAX];
char *env = getenv("PATH");
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index e3b3724..47e4ae1 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -129,7 +129,9 @@ ifndef DEBUG
endif
ifeq ($(DEBUG),0)
- CFLAGS += -O6
+ CFLAGS += -O3
+else
+ CFLAGS += $(call cc-option,-Og,-O0)
endif
ifdef PARSER_DEBUG
diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak
index c16ce83..0ebef09 100644
--- a/tools/perf/config/utilities.mak
+++ b/tools/perf/config/utilities.mak
@@ -177,3 +177,22 @@ $(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
endef
_ge_attempt = $(if $(get-executable),$(get-executable),$(call _gea_err,$(2)))
_gea_err = $(if $(1),$(error Please set '$(1)' appropriately))
+
+# try-run
+# Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise)
+# Exit code chooses option. "$$TMP" is can be used as temporary file and
+# is automatically cleaned up.
+try-run = $(shell set -e; \
+ TMP="$(TMPOUT)..tmp"; \
+ TMPO="$(TMPOUT)..o"; \
+ if ($(1)) >/dev/null 2>&1; \
+ then echo "$(2)"; \
+ else echo "$(3)"; \
+ fi;\
+ rm -f "$$TMP" "$$TMPO")
+
+# cc-option
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+
+cc-option = $(call try-run,\
+ $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 82a31fd..a19fbd4 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -400,7 +400,7 @@ static struct symbol *symbols__find_by_name(struct rb_root *symbols,
const char *name)
{
struct rb_node *n;
- struct symbol_name_rb_node *s;
+ struct symbol_name_rb_node *s = NULL;
if (symbols == NULL)
return NULL;
diff --git a/tools/perf/util/trace-event-parse.c b/tools/perf/util/trace-event-parse.c
index 25d6c73..d495741 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -173,7 +173,7 @@ void parse_ftrace_printk(struct pevent *pevent,
char *line;
char *next = NULL;
char *addr_str;
- char *fmt;
+ char *fmt = NULL;
line = strtok_r(file, "\n", &next);
while (line) {
--
2.1.4
Re: [PATCH v5 36/37] MIPS: ingenic: initial JZ4780 support
On 05/24/2015 05:11 PM, Paul Burton wrote:
> Support the Ingenic JZ4780 SoC using the existing code under
> arch/mips/jz4740 now that it has been generalised sufficiently.
>
> Signed-off-by: Paul Burton
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Lars-Peter Clausen
> Cc: Mark Rutland
> Cc: Pawel Moll
> Cc: Ralf Baechle
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> ---
>
> Changes in v5:
> - Disable the UARTs by default, so that devices can enable only the ones
> they actually expose.
>
> Changes in v4: None
> Changes in v3:
> - Rebase, dropping serial.h & relocating behind CONFIG_MACH_INGENIC.
>
> Changes in v2: None
>
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 111
> +
> arch/mips/include/asm/cpu-type.h | 2 +-
> .../asm/mach-jz4740/cpu-feature-overrides.h| 3 -
> arch/mips/include/asm/mach-jz4740/irq.h| 4 +
> arch/mips/jz4740/Kconfig | 6 ++
> arch/mips/jz4740/Makefile | 4 +-
> arch/mips/jz4740/setup.c | 3 +
> arch/mips/jz4740/time.c| 7 +-
> 8 files changed, 134 insertions(+), 6 deletions(-)
> create mode 100644 arch/mips/boot/dts/ingenic/jz4780.dtsi
>
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> new file mode 100644
> index 000..65389f6
> --- /dev/null
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -0,0 +1,111 @@
> +#include
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ingenic,jz4780";
> +
> + cpuintc: interrupt-controller {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "mti,cpu-interrupt-controller";
> + };
> +
> + intc: interrupt-controller@10001000 {
> + compatible = "ingenic,jz4780-intc";
> + reg = <0x10001000 0x50>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&cpuintc>;
> + interrupts = <2>;
> + };
> +
> + ext: ext {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + };
> +
> + rtc: rtc {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + };
> +
> + cgu: jz4780-cgu@1000 {
> + compatible = "ingenic,jz4780-cgu";
> + reg = <0x1000 0x100>;
> +
> + clocks = <&ext>, <&rtc>;
> + clock-names = "ext", "rtc";
> +
> + #clock-cells = <1>;
> + };
> +
> + uart0: serial@1003 {
> + compatible = "ingenic,jz4780-uart";
> + reg = <0x1003 0x100>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <51>;
> +
> + clocks = <&ext>, <&cgu JZ4780_CLK_UART0>;
> + clock-names = "baud", "module";
> +
> + status = "disabled";
> + };
> +
> + uart1: serial@10031000 {
> + compatible = "ingenic,jz4780-uart";
> + reg = <0x10031000 0x100>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <50>;
> +
> + clocks = <&ext>, <&cgu JZ4780_CLK_UART1>;
> + clock-names = "baud", "module";
> +
> + status = "disabled";
> + };
> +
> + uart2: serial@10032000 {
> + compatible = "ingenic,jz4780-uart";
> + reg = <0x10032000 0x100>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <49>;
> +
> + clocks = <&ext>, <&cgu JZ4780_CLK_UART2>;
> + clock-names = "baud", "module";
> +
> + status = "disabled";
> + };
> +
> + uart3: serial@10033000 {
> + compatible = "ingenic,jz4780-uart";
> + reg = <0x10033000 0x100>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <48>;
> +
> + clocks = <&ext>, <&cgu JZ4780_CLK_UART3>;
> + clock-names = "baud", "module";
> +
> + status = "disabled";
> + };
> +
> + uart4: serial@10034000 {
> + compatible = "ingenic,jz4780-uart";
> + reg = <0x10034000 0x100>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <34>;
> +
> + clocks = <&ext>, <&cgu JZ4780_CLK_UART4>;
> + clock-names = "baud", "module";
> +
> + status = "disabled";
> + };
> +};
> diff --git a/arch/mips/include/asm/cpu-type.h
> b/arch/mips/include/asm/cpu-type.h
> index 33f3cab..d41e8e2 100644
> --- a/arch/mips/include/asm/cpu-type.h
> +++ b/arch/mips/include/asm/cpu-type.h
> @@ -32,12 +32,12 @@ static inline int __pure __get_cpu_type(const int
> cpu_type)
> case CPU_4KC:
> case CPU_ALCHEMY:
> case CP
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
__NR_syscalls (364) is not one more than the last syscall (364)
Caused by commit d7766613717b ("userfaultfd: activate syscall"). (BTW,
I notice that this patch was not cc'd to any ppc maintainers :-()
I have added this fix patch for today:
From: Stephen Rothwell
Date: Mon, 25 May 2015 21:13:40 +1000
Subject: [PATCH] userfaultfd: activate syscall fix
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/unistd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
index f4f8b667d75b..4a055b6c2a64 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
#include
-#define __NR_syscalls 364
+#define __NR_syscalls 365
#define __NR__exit __NR_exit
#define NR_syscalls__NR_syscalls
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpBVE7OY4CFa.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 1/1] ARM: mvebu: dts: Add dts file for DLink DNS-327L
Hi Andrew,
On 20/05/2015 13:00, Sebastian Hesselbarth wrote:
> On 20.05.2015 12:20, Andrew wrote:
>> Sebastian Hesselbarth писал 20.05.2015 12:05:
>>> On 19.05.2015 23:10, Andrew Andrianov wrote:
DNS-327L is a 2-bay NAS with the following specs:
>>> [...]
Signed-off-by: Andrew Andrianov
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 356
+
2 files changed, 357 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-370-dlink-dns327l.dts
>>> [...]
diff --git a/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
new file mode 100644
index 000..0f4555c4
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
@@ -0,0 +1,356 @@
>>> [...]
+regulators {
+compatible = "simple-bus";
+#address-cells = <1>;
+#size-cells = <0>;
+pinctrl-0 = <&xhci_pwr_pin
+&sata_l_pwr_pin
+&sata_r_pwr_pin>;
+
+pinctrl-names = "default";
>>>
>>> I doubt pinctrl will not work as you expected. For regulators, unlike
>>> gpio-keys/leds above, this node just describes the "bus" of regulators.
>>
>> Are you sure about this moment? FYI: I've taken
>> armada-370-synology-ds213j.dts
>> as the reference which happens to list regulator pinctrl (As of 4.1-rc1)
>> just the same way:
>>
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> pinctrl-0 = <&sata1_pwr_pin &sata2_pwr_pin>;
>> pinctrl-names = "default";
>> ...
>
> Well, even if it works the pinctrl should be claimed by the device that
> actually depends on it, i.e. the regulator itself.
>
>> If that's erroneous we should fix armada-370-synology-ds213j.dts as well.
>
> Most likely nobody ever noticed if that didn't work because (a) usually
> gpio functions are setup by the bootloader or (b) gpio is default reset
> value of the pinctrl registers anyway.
>
> I'd say move the pinctrl properties to regulator nodes for dns-327l now
> and we move the properties for ds213j in a separate patch.
Usually the merge windows for arm-soc is closed when the rc6 is released which
should
happen at the end of this week. If you manged to send a new version this week,
then I
will apply it on mvebu/dt and it should be part of our next pull request.
Thanks,
Gregory
>
> Sebastian
>
+
+usb_power: regulator@1 {
+compatible = "regulator-fixed";
+reg = <1>;
+regulator-name = "USB3.0 Port Power";
+regulator-min-microvolt = <500>;
+regulator-max-microvolt = <500>;
+enable-active-high;
+regulator-boot-on;
+regulator-always-on;
+gpio = <&gpio0 13 GPIO_ACTIVE_HIGH>;
>>>
>>> Instead you'll have to put the corresponding pinctrl-0/names properties
>>> in each of the regulator nodes, i.e.
>>>
>>> pinctrl-0 = <&xhci_pwr_pin>
>>> pinctrl-names = "default";
>>>
>>> here and similar for the other regulator nodes.
>>>
+};
+
+sata_r_power: regulator@2 {
+compatible = "regulator-fixed";
+reg = <2>;
+regulator-name = "SATA-R Power";
+regulator-min-microvolt = <500>;
+regulator-max-microvolt = <500>;
+startup-delay-us = <200>;
+enable-active-high;
+regulator-always-on;
+regulator-boot-on;
+gpio = <&gpio1 22 GPIO_ACTIVE_HIGH>;
+};
+
+sata_l_power: regulator@3 {
+compatible = "regulator-fixed";
+reg = <3>;
+regulator-name = "SATA-L Power";
+regulator-min-microvolt = <500>;
+regulator-max-microvolt = <500>;
+startup-delay-us = <400>;
+enable-active-high;
+regulator-always-on;
+regulator-boot-on;
+gpio = <&gpio1 24 GPIO_ACTIVE_HIGH>;
+};
+};
+};
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/8] kernel/exit.c: make sure current's nsproxy != NULL while checking caps
On sob, 2015-05-23 at 12:49 -0500, Eric W. Biederman wrote: > Lukasz Pawelczyk writes: > > > There is a rare case where current's nsproxy might be NULL but we are > > required to check for credentials and capabilities. It sometimes happens > > during an exit_group() syscall while destroying user's session (logging > > out). > > > > My understanding is that while we have to lock the task to get task's > > nsproxy and check whether it's NULL, for the 'current' we don't have to > > and it's expected not to be NULL. There is a code in the kernel > > currently that does current->nsproxy->user_ns without any checks. > > And include/linux/nsproxy.h confirms that: > > > > 2. when accessing (i.e. reading) current task's namespaces - no > >precautions should be taken - just dereference the pointers > > > > There seem to be no crash currently because of this, but with accessing > > nsproxy from LSM hooks there is. This is the backtrace: > > > > 0 smk_tskacc (task=0x88003b0b92e0, obj_known=0x2 , > > mode=2, a=0x88003be53dd8) at security/smack/smack_access.c:261 > > 1 0x8130e2aa in smk_curacc (obj_known=, > > mode=, a=) at > > security/smack/smack_access.c:318 > > 2 0x8130a50d in smack_task_kill (p=0x88003b0b92e0, > > info=, sig=, secid=) at > > security/smack/smack_lsm.c:2071 > > 3 0x812ea4f6 in security_task_kill (p=, > > info=, sig=, secid=) at > > security/security.c:952 > > 4 0x8109ac80 in check_kill_permission (sig=15, info=0x0 > > , t=0x88003b0b8000) at kernel/signal.c:796 > > 5 0x8109d3ab in group_send_sig_info (sig=15, info=0x0 > > , p=0x88003b0b8000) at kernel/signal.c:1296 > > 6 0x8108e527 in forget_original_parent (father=) at > > kernel/exit.c:575 > > 7 exit_notify (group_dead=, tsk=) at > > kernel/exit.c:606 > > 8 do_exit (code=) at kernel/exit.c:775 > > 9 0x8108ec0f in do_group_exit (exit_code=0) at kernel/exit.c:891 > > 10 0x8108ec84 in SYSC_exit_group (error_code=) at > > kernel/exit.c:902 > > 11 SyS_exit_group (error_code=) at kernel/exit.c:900 > > > > This backtrace clearly shows that there is an LSM hook task_kill() that > > happens during an exit_group() syscall and that this happens after > > exit_task_namespaces(). LSM hooks with namespaces might need nsproxy to > > be able to check for capabilities. At this point this is impossible. The > > current's nsproxy is already NULL/destroyed. > > > > This is the case because exit_task_namespaces() is called before the > > exit_notify() where all of the above happens. This patch changes their > > order. > > Nacked-by: "Eric W. Biederman" > > current->nsproxy->user_ns does not exist, > and changing where exit_task_namespaces is fragile and I am really not > interested in messing with it right now, to solve a problem that does > not exist. I must have missed the moment where current->nsproxy->user_ns was removed. I obviously even don't use it in my patches anymore (replaced with cred->user_ns). Back when I started to write my patches and wanted to use current->nsproxy->user_ns in LSM hooks the problem was real. Fortunately current->cred->user_ns does not exhibit the same issue. I'll drop this patch. Sorry for the confusion. > > > > > Signed-off-by: Lukasz Pawelczyk > > --- > > kernel/exit.c | 8 +++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/exit.c b/kernel/exit.c > > index 22fcc05..da1bb18 100644 > > --- a/kernel/exit.c > > +++ b/kernel/exit.c > > @@ -742,7 +742,6 @@ void do_exit(long code) > > exit_fs(tsk); > > if (group_dead) > > disassociate_ctty(1); > > - exit_task_namespaces(tsk); > > exit_task_work(tsk); > > exit_thread(); > > > > @@ -763,6 +762,13 @@ void do_exit(long code) > > > > TASKS_RCU(tasks_rcu_i = __srcu_read_lock(&tasks_rcu_exit_srcu)); > > exit_notify(tsk, group_dead); > > + > > + /* > > +* This should be after all things that potentially require > > +* process's namespaces (e.g. capability checks). > > +*/ > > + exit_task_namespaces(tsk); > > + > > proc_exit_connector(tsk); > > #ifdef CONFIG_NUMA > > task_lock(tsk); > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Lukasz Pawelczyk Samsung R&D Institute Poland Samsung Electronics -- 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] cgroup: add explicit cast and comment for return type conversion
Hello, Nicholas. On Mon, May 25, 2015 at 07:57:42AM +0200, Nicholas Mc Guire wrote: > nop not downward but signed/unsigned if it were down it would not be > a problem but signed/unsigned can be - for those cases where it can't > be fixed up by changing the declarations or return variable types > explicit cast might make sense - as noted in the patch Im not sure either > if this form of cleanups is helpful. > > In the kernel core there are about 400 signed/unsigned implicit > conversions (about 3k in the entire kernel) which is what Im trying to > remove or if that is not possible in a resonable way mark as false positive. I still don't get it. What does this buy us actually? If we continue to do this, people would just learn to add explicit cast when doing sign conversions. We just converge to a different behavior without actually gaining any protection. What's the benefit of doing this? Thanks. -- tejun -- 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] usb: ulpi: don't register drivers if bus doesn't exist
Hi, > Why do we even need that? If you take patch that makes ulpi_init a > subsys_initcall you won't have this problem, and no additional weird > hacks and errors will be needed Using subsys_initcall will work around the problem for now, but I would not make the assumption that there will never be ulpi phy drivers and ulpi interface drivers that don't use subsys_initcall themselves. By checking the old phy drivers at drivers/usb/phy/, at least so far it hasn't been uncommon for them to use subsys_initcall. I would much prefer to have a proper fix for this issue instead of just working around it, but we need to use subsys_initcall in any case. > >> > + /* Was the bus registered successfully? */ > >> > + if (!ulpi_bus.p) > >> > + return -ENODEV; > >> > >> Ick, no, don't go mucking around in the bus internals like this, that's > >> not ok. You should either "know" the bus is registered, or something is > >> really wrong with the design here. > > can't we use a variable which can be initialized to 1 in ulpi_init() if > > the bus registers successfully and later check that? Just a note. We should also be aware if the bus registration failed or if it just hasn't been loaded yet. If we used a variable like that, I guess it could initially have the value -EAGAIN. If bus_register returns error, we store -ENODEV to it. If bus_register succeeds we store 0 to it. I don't know if we can just store the return value from bus_register to it. In ulpi_register_driver and ulpi_register_interface we can then just return it if it has a value other then 0. But couldn't we add a helper function to drivers/base/bus.c that the bus drivers can use to at least check was the bus already loaded or not? It looks like there are a couple of bus drivers that use the struct bus member "p" to check that. Greg, what do you think? Thanks, -- heikki -- 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] ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC
The IRQB of S2MPS11 PMIC is wired to XEINT4 (GPX0-4) through pull-up
resistor.
Add interrupt properties and pinctrl configuration to enable RTC wake
alarm of rtc-s5m driver. This also removes a warning:
sec_pmic 4-0066: No interrupt specified, no interrupts
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c16987950aa1..27014bb0c586 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include
+#include
#include
#include
#include "exynos5800.dtsi"
@@ -153,6 +154,11 @@
s2mps11,buck3-ramp-enable = <1>;
s2mps11,buck4-ramp-enable = <1>;
+ interrupt-parent = <&gpx0>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&s2mps11_irq>;
+
s2mps11_osc: clocks {
#clock-cells = <1>;
clock-output-names = "s2mps11_ap",
@@ -473,6 +479,13 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ s2mps11_irq: s2mps11-irq {
+ samsung,pins = "gpx0-4";
+ samsung,pin-function = <0xf>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
&pwm {
--
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: [RFC PATCH v3 30/37] perf bpf: Add bpf-loader and open ELF object files
On 2015/5/23 1:24, Jiri Olsa wrote:
On Sun, May 17, 2015 at 10:56:55AM +, Wang Nan wrote:
SNIP
+#define DEFINE_PRINT_FN(name, level) \
+static int libbpf_##name(const char *fmt, ...) \
+{ \
+ va_list args; \
+ int ret;\
+ \
+ va_start(args, fmt);\
+ ret = veprintf(level, verbose, pr_fmt(fmt), args);\
+ va_end(args); \
+ return ret; \
+}
+
+DEFINE_PRINT_FN(warning, 0)
+DEFINE_PRINT_FN(info, 0)
+DEFINE_PRINT_FN(debug, 1)
+
+static bool libbpf_inited = false;
+
+#define MAX_OBJECTS128
+
+struct {
+ struct bpf_object *objects[MAX_OBJECTS];
+ size_t nr_objects;
+} params;
apart from that we dont like this kind of static stuff, this seems like
nice case for having simple handler like 'struct bpf_objects' carrying
the above data.. what do I miss?
I want to avoid fragmented memory allocation for storing bpf_object
pointers.
Storing them together into an array can make code simpler. I think I can
made
something like 'struct bpf_object *bpf_next_object(obj)' in libbpf so we can
iterate over each loaded bpf objects, then this array and nr_objects can be
hidden.
also params should actually be static right?
jirka
--
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] cgroup: add explicit cast and comment for return type conversion
On Mon, 25 May 2015, Tejun Heo wrote: > Hello, Nicholas. > > On Mon, May 25, 2015 at 07:57:42AM +0200, Nicholas Mc Guire wrote: > > nop not downward but signed/unsigned if it were down it would not be > > a problem but signed/unsigned can be - for those cases where it can't > > be fixed up by changing the declarations or return variable types > > explicit cast might make sense - as noted in the patch Im not sure either > > if this form of cleanups is helpful. > > > > In the kernel core there are about 400 signed/unsigned implicit > > conversions (about 3k in the entire kernel) which is what Im trying to > > remove or if that is not possible in a resonable way mark as false positive. > > I still don't get it. What does this buy us actually? If we continue > to do this, people would just learn to add explicit cast when doing > sign conversions. We just converge to a different behavior without > actually gaining any protection. What's the benefit of doing this? > that would be no benefit of course - the goal is not to simply put casts in but to use casts as last resort if type cleanups are not doable or if the type missmatch is intended - the cast then should document that it is intentional and comments explain why it is justified. If that were the result of type cleanup I think it would benefit the kernel code as I suspect that quite a few of the type missmatches simply happened. thx! hofrat -- 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] HID: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLL
On Thu, 21 May 2015, Herton R. Krzesinski wrote: > I received a report from an user of following mouse which needs this quirk: > > usb 1-1.6: USB disconnect, device number 58 > usb 1-1.6: new low speed USB device number 59 using ehci_hcd > usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053 > usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-1.6: Product: USB Optical Mouse > usb 1-1.6: Manufacturer: PixArt > usb 1-1.6: configuration #1 chosen from 1 choice > input: PixArt USB Optical Mouse as > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887 > generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt > USB Optical Mouse] on usb-:00:1a.0-1.6/input0 > > The quirk was tested by the reporter and it fixed the frequent disconnections > etc. > > Signed-off-by: Herton R. Krzesinski Applied (with Benjamin's nit taken into account). Thanks, -- Jiri Kosina SUSE Labs -- 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/
