Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios
On Sat, 2015-08-01 at 12:33 -0400, Mike Snitzer wrote:
> On Sat, Aug 01 2015 at 2:58am -0400,
> Ming Lin wrote:
>
> > On Fri, 2015-07-31 at 17:38 -0400, Mike Snitzer wrote:
> > >
> > > OK, once setup, to run the 2 tests in question directly you'd do
> > > something like:
> > >
> > > dmtest run --suite thin-provisioning -n discard_a_fragmented_device
> > >
> > > dmtest run --suite thin-provisioning -n
> > > discard_fully_provisioned_device_benchmark
> > >
> > > Again, these tests pass without this patchset.
> >
> > It's caused by patch 4.
Typo. I mean patch 5.
> > When discard size >=4G, the bio->bi_iter.bi_size overflows.
>
> Thanks for tracking this down!
blkdev_issue_write_same() has same problem.
>
> > Below is the new patch.
> >
> > Christoph,
> > Could you also help to review it?
> >
> > Now we still do "misaligned" check in blkdev_issue_discard().
> > So the same code in blk_bio_discard_split() was removed.
>
> But I don't agree with this approach. One of the most meaningful
> benefits of late bio splitting is the upper layers shouldn't _need_ to
> depend on the intermediate devices' queue_limits being stacked properly.
> Your solution to mix discard granularity/alignment checks at the upper
> layer(s) but then split based on max_discard_sectors at the lower layer
> defeats that benefit for discards.
>
> This will translate to all intermediate layers that might split
> discards needing to worry about granularity/alignment
> too (e.g. how dm-thinp will have to care because it must generate
> discard mappings with associated bios based on how blocks were mapped to
> thinp).
I think the important thing is the late splitting for regular bio.
For discard/write_same bio, how about just don't do late splitting?
That is:
1. remove "PATCH 5: block: remove split code in blkdev_issue_discard"
2. Add below changes to PATCH 1
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 1f5dfa0..90b085e 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -9,59 +9,6 @@
#include "blk.h"
-static struct bio *blk_bio_discard_split(struct request_queue *q,
-struct bio *bio,
-struct bio_set *bs)
-{
- unsigned int max_discard_sectors, granularity;
- int alignment;
- sector_t tmp;
- unsigned split_sectors;
-
- /* Zero-sector (unknown) and one-sector granularities are the same. */
- granularity = max(q->limits.discard_granularity >> 9, 1U);
-
- max_discard_sectors = min(q->limits.max_discard_sectors, UINT_MAX >> 9);
- max_discard_sectors -= max_discard_sectors % granularity;
-
- if (unlikely(!max_discard_sectors)) {
- /* XXX: warn */
- return NULL;
- }
-
- if (bio_sectors(bio) <= max_discard_sectors)
- return NULL;
-
- split_sectors = max_discard_sectors;
-
- /*
-* If the next starting sector would be misaligned, stop the discard at
-* the previous aligned sector.
-*/
- alignment = (q->limits.discard_alignment >> 9) % granularity;
-
- tmp = bio->bi_iter.bi_sector + split_sectors - alignment;
- tmp = sector_div(tmp, granularity);
-
- if (split_sectors > tmp)
- split_sectors -= tmp;
-
- return bio_split(bio, split_sectors, GFP_NOIO, bs);
-}
-
-static struct bio *blk_bio_write_same_split(struct request_queue *q,
- struct bio *bio,
- struct bio_set *bs)
-{
- if (!q->limits.max_write_same_sectors)
- return NULL;
-
- if (bio_sectors(bio) <= q->limits.max_write_same_sectors)
- return NULL;
-
- return bio_split(bio, q->limits.max_write_same_sectors, GFP_NOIO, bs);
-}
-
static struct bio *blk_bio_segment_split(struct request_queue *q,
struct bio *bio,
struct bio_set *bs)
@@ -129,10 +76,8 @@ void blk_queue_split(struct request_queue *q, struct bio
**bio,
{
struct bio *split;
- if ((*bio)->bi_rw & REQ_DISCARD)
- split = blk_bio_discard_split(q, *bio, bs);
- else if ((*bio)->bi_rw & REQ_WRITE_SAME)
- split = blk_bio_write_same_split(q, *bio, bs);
+ if ((*bio)->bi_rw & REQ_DISCARD || (*bio)->bi_rw & REQ_WRITE_SAME)
+ split = NULL;
else
split = blk_bio_segment_split(q, *bio, q->bio_split);
>
> Also, it is unfortunate that IO that doesn't have a payload is being
> artificially split simply because bio->bi_iter.bi_size is 32bits.
Indeed.
Will it be possible to make it 64bits? I guess no.
>
> Mike
--
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
[PATCH v3] HID: hid-input: Fix accessing freed memory during device disconnect
During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().
Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supply_unregister() this
memory is freed and the driver cannot access these members.
Fix this by storing the pointer to internal description of battery in a
local variable before calling power_supply_unregister(), so the pointer
remains valid.
Signed-off-by: Krzysztof Kozlowski
Reported-by: H.J. Lu
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Cc:
---
Changes since v2:
1. Add missing 'const'.
Changes since v1:
1. Re-work idea, use local variable instead of devm-like functions
(pointed out by Dmitry Torokhov).
2. Adjusted subject and commit message.
---
drivers/hid/hid-input.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 14aebe483219..53aeaf6252c7 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -462,12 +462,15 @@ out:
static void hidinput_cleanup_battery(struct hid_device *dev)
{
+ const struct power_supply_desc *psy_desc;
+
if (!dev->battery)
return;
+ psy_desc = dev->battery->desc;
power_supply_unregister(dev->battery);
- kfree(dev->battery->desc->name);
- kfree(dev->battery->desc);
+ kfree(psy_desc->name);
+ kfree(psy_desc);
dev->battery = NULL;
}
#else /* !CONFIG_HID_BATTERY_STRENGTH */
--
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/
Re: Re: [PATCH 03/15] drivers: devfreq: Drop unlikely before IS_ERR(_OR_NULL)
On 03-08-15, 05:50, MyungJoo Ham wrote: > Acked-by: MyungJoo Ham > > > please let me know when the series is ready to go. It wouldn't harm even if you apply it without 1/15. So, just go on and apply :) -- 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/
[PATCH V2] staging: android: lowmemorykiller: imporve lmk to avoid deadlock issue
Consider the following case:
Task A trigger lmk with a lock held, while task B try to
get this lock, but unfortunately B is the very culprit task lmk select to
kill. Then B will never be killed, and A will forever select B to kill.
Such dead lock will trigger softlock up issue.
This patch try to pick the next task to break this loop.
Signed-off-by: Wang Biao
Reviewed-by: Zhang Di
Reviewed-by: Dan Carpenter
Reviewed-by: Joe Perches
---
drivers/staging/android/lowmemorykiller.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index feafa17..23d9832 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -127,9 +127,10 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
if (!p)
continue;
- if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
- time_before_eq(jiffies, lowmem_deathpending_timeout)) {
+ if (test_tsk_thread_flag(p, TIF_MEMDIE)) {
task_unlock(p);
+ if (time_after(jiffies, lowmem_deathpending_timeout))
+ continue;
rcu_read_unlock();
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH 03/15] drivers: devfreq: Drop unlikely before IS_ERR(_OR_NULL)
> On 03-08-15, 05:10, MyungJoo Ham wrote:
> > > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> > > is no need to do that again from its callers. Drop it.
> > >
> > > Signed-off-by: Viresh Kumar
> >
> > @ from include/linux/err.h
> > #define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> > ...
> > static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
> > {
> > return !ptr || IS_ERR_VALUE((unsigned long)ptr);
> > }
> >
> > "!ptr" appears not covered with IS_ERR_OR_NULL.
> > (only the IS_ERR part seems covered)
>
> Right, the first patch of the series has fixed that.
>
> http://permalink.gmane.org/gmane.linux.kernel/2009151
Ah.. ok, then,
Acked-by: MyungJoo Ham
please let me know when the series is ready to go.
Cheers,
MyungJoo
>
> --
> viresh
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] Avoid compiler warning by storing the result of rq_data_dir() in an int variable
With gcc 5.1 I get:
warning: switch condition has boolean value [-Wswitch-bool]
Signed-off-by: Tomer Barletz
---
drivers/mtd/mtd_blkdevs.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 41acc50..8830475 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -97,14 +97,13 @@ static int do_blktrans_request(struct mtd_blktrans_ops *tr,
if (req->cmd_flags & REQ_DISCARD)
return tr->discard(dev, block, nsect);
- switch(rq_data_dir(req)) {
- case READ:
+ if (rq_data_dir(req) == READ) {
for (; nsect > 0; nsect--, block++, buf += tr->blksize)
if (tr->readsect(dev, block, buf))
return -EIO;
rq_flush_dcache_pages(req);
return 0;
- case WRITE:
+ } else {
if (!tr->writesect)
return -EIO;
@@ -113,9 +112,6 @@ static int do_blktrans_request(struct mtd_blktrans_ops *tr,
if (tr->writesect(dev, block, buf))
return -EIO;
return 0;
- default:
- printk(KERN_NOTICE "Unknown request %u\n", rq_data_dir(req));
- return -EIO;
}
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/15] drivers: devfreq: Drop unlikely before IS_ERR(_OR_NULL)
On 03-08-15, 05:10, MyungJoo Ham wrote:
> > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> > is no need to do that again from its callers. Drop it.
> >
> > Signed-off-by: Viresh Kumar
>
> @ from include/linux/err.h
> #define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> ...
> static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
> {
> return !ptr || IS_ERR_VALUE((unsigned long)ptr);
> }
>
> "!ptr" appears not covered with IS_ERR_OR_NULL.
> (only the IS_ERR part seems covered)
Right, the first patch of the series has fixed that.
http://permalink.gmane.org/gmane.linux.kernel/2009151
--
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/
[PATCH] Staging : lustre: Struct file_operations should be const
Declare the file_operations structure ll_file_operations as const, as done
elsewhere in the kernel, as there are no modifications to its fields.
Problem found using checkpatch:
WARNING: struct file_operations should normally be const
Signed-off-by: Shraddha Barke
---
drivers/staging/lustre/lustre/llite/file.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index dcd0c6d..2c467bf 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -3116,7 +3116,7 @@ int ll_inode_permission(struct inode *inode, int mask)
}
/* -o localflock - only provides locally consistent flock locks */
-struct file_operations ll_file_operations = {
+const struct file_operations ll_file_operations = {
.read_iter = ll_file_read_iter,
.write_iter = ll_file_write_iter,
.unlocked_ioctl = ll_file_ioctl,
@@ -3129,7 +3129,7 @@ struct file_operations ll_file_operations = {
.flush= ll_flush
};
-struct file_operations ll_file_operations_flock = {
+const struct file_operations ll_file_operations_flock = {
.read_iter= ll_file_read_iter,
.write_iter = ll_file_write_iter,
.unlocked_ioctl = ll_file_ioctl,
@@ -3145,7 +3145,7 @@ struct file_operations ll_file_operations_flock = {
};
/* These are for -o noflock - to return ENOSYS on flock calls */
-struct file_operations ll_file_operations_noflock = {
+const struct file_operations ll_file_operations_noflock = {
.read_iter= ll_file_read_iter,
.write_iter = ll_file_write_iter,
.unlocked_ioctl = ll_file_ioctl,
--
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 11/15] drivers: target: Drop unlikely before IS_ERR(_OR_NULL)
On Fri, 2015-07-31 at 14:08 +0530, Viresh Kumar wrote:
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> is no need to do that again from its callers. Drop it.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/target/tcm_fc/tfc_cmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/target/tcm_fc/tfc_cmd.c b/drivers/target/tcm_fc/tfc_cmd.c
> index 68031723e5be..aa3caca8bace 100644
> --- a/drivers/target/tcm_fc/tfc_cmd.c
> +++ b/drivers/target/tcm_fc/tfc_cmd.c
> @@ -255,7 +255,7 @@ static void ft_recv_seq(struct fc_seq *sp, struct
> fc_frame *fp, void *arg)
> struct ft_cmd *cmd = arg;
> struct fc_frame_header *fh;
>
> - if (unlikely(IS_ERR(fp))) {
> + if (IS_ERR(fp)) {
> /* XXX need to find cmd if queued */
> cmd->seq = NULL;
> cmd->aborted = true;
Looks fine. Applied to target-pending/for-next.
Thanks 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 v2] Revert "Staging : lustre: Struct file_operations should be const"
On Sun, Aug 02, 2015 at 11:04:22PM +0530, Shraddha Barke wrote:
Your subject says 'Revert "Staging : lustre: Struct file_operations
should be const"'. This patch reverts which commit?
> Declare the file_operations structure ll_file_operations as const, as done
> elsewhere in the kernel, as there are no modifications to its fields.
>
> Problem found using checkpatch.
>
> Signed-off-by: Shraddha Barke
> ---
> Changes in v2:
> - Make the commit message more clearer.
>
> drivers/staging/lustre/lustre/llite/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/llite/file.c
> b/drivers/staging/lustre/lustre/llite/file.c
> index 369a722..dcd0c6d 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -3116,7 +3116,7 @@ int ll_inode_permission(struct inode *inode, int mask)
> }
>
> /* -o localflock - only provides locally consistent flock locks */
> -const struct file_operations ll_file_operations = {
> +struct file_operations ll_file_operations = {
Your commit message says "Declare the file_operations structure
ll_file_operations as const" but your patch is removing the const.
regards
sudip
--
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] ecryptfs: Allow only one instance per lower path
On 2015-08-02 09:51:16, Richard Weinberger wrote: > Am 02.08.2015 um 03:03 schrieb Tyler Hicks: > > Thanks for the report and for the patch, Richard! > > > > On 2015-07-31 12:23:10, Richard Weinberger wrote: > >> Mounting the same lower path multiple times should not result > >> into multiple ecryptfs instances, otherwise ecryptfs gets confused. > >> > >> A command sequence of: > > > > An important detail that took me a while to realize is that /tmp should > > be tmpfs in order to trigger the warnings below. I was unable to > > reproduce the warnings with ext4 as the lower filesystem. > > Hmm, I saw it with UBIFS found that it triggers with tmpfs too. > I gave ext4 a quick try and yes, it behaves differently, I get > a EIO upon the second unlink(). > > >> $ mount -t ecryptfs /tmp/.secret /mnt_a/secret/ > >> $ mount -t ecryptfs /tmp/.secret /mnt_b/secret/ > >> $ mkdir -p /mnt_a/secret/xxx > >> $ mkdir -p /mnt_b/secret/xxx > > > > Note that the -p option is covering up the fact that /mnt_b/secret/xxx > > already exists. Remove that option and you should see this error: > > > > mkdir: cannot create directory ‘/mnt_b/secret/xxx’: File exists > > > > This really isn't important other than understanding that the second > > mkdir it isn't needed. > > > >> $ echo foo > /mnt_a/secret/xxx/test.txt > >> $ echo foo > /mnt_b/secret/xxx/test.txt > > > > /mnt_b/secret/xxx/test.txt should already exist (it does for me, at > > least) so the same file is being written to twice in a row. Again, not > > really important other than to know that it isn't needed. > > > >> $ rm -rf /mnt_a/secret/xxx > >> $ rm -rf /mnt_b/secret/xxx > > > > The /mnt_b/secret/xxx dcache entry is stale here because the underlying > > file was removed by the first rm command in the /mnt_a/secret mount. The > > lower inode's nlink is 0 at this point and what should be happening > > here, I think, is that the eCryptfs dentry should be invalidated and the > > eCryptfs inode should be destroyed. > > > > I think that the proper fix is to catch this condition in > > ecryptfs_d_revalidate(). I've started working on coming up with a patch > > for that but I'll need some more time to finish and test it. > > So ecryptfs definitely supports mounting the same lower path multiple times? > What is the benefit of that behavior? No, it doesn't support that in a way that provides consistency among all of the eCryptfs mounts. However, multiple mounts on the same lower path is not the cause of this bug. The real issue is a stale dcache entry when the lower filesystem has been modified without eCryptfs' knowing. I can trigger the same warnings with only a single eCryptfs mount. Tyler > > Thanks, > //richard signature.asc Description: Digital signature
Re: [PATCH] Adding YAMA hooks also when YAMA is not stacked.
On Fri, 31 Jul 2015, Salvatore Mesoraca wrote:
> Without this patch YAMA will not work at all if it is chosen
> as the primary LSM instead of being "stacked".
>
> Signed-off-by: Salvatore Mesoraca
> ---
> security/yama/yama_lsm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index 9ed3250..5ebb896 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -406,6 +406,7 @@ static __init int yama_init(void)
> */
> if (!security_module_enable("yama"))
> return 0;
> +yama_add_hooks();
> #endif
> pr_info("Yama: becoming mindful.\n");
It looks like your mailer is converting tabs to spaces, please fix and
resend.
--
James Morris
--
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 03/15] drivers: devfreq: Drop unlikely before IS_ERR(_OR_NULL)
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> is no need to do that again from its callers. Drop it.
>
> Signed-off-by: Viresh Kumar
@ from include/linux/err.h
#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
...
static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
{
return !ptr || IS_ERR_VALUE((unsigned long)ptr);
}
"!ptr" appears not covered with IS_ERR_OR_NULL.
(only the IS_ERR part seems covered)
Cheers,
MyungJoo
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [RFC PATCH 4/5] ARM: dts: DRA7: Add memory map region entries for qspi
On 07/31/2015 07:18 PM, Sekhar Nori wrote: > On Tuesday 28 July 2015 02:11 PM, Vignesh R wrote: >> Add qspi memory mapped region entries for DRA7xx based SoCs. >> >> Signed-off-by: Vignesh R >> --- >> arch/arm/boot/dts/am4372.dtsi | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi >> index ade28c790f4b..5317a0f24ab9 100644 >> --- a/arch/arm/boot/dts/am4372.dtsi >> +++ b/arch/arm/boot/dts/am4372.dtsi > > The patch talks about DRA7x in subject and description but you modify > AM437x here. You have got commit text mixed up between 4/5 and 5/5. > > Probably not the kind of feedback you are looking for an RFC, but since > I noticed it.. Oh, my bad.. I will correct $subject when I submit actual patch series. -- Regards Vignesh -- 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/5] arm: qcom: dts: Add NAND controller node for ipq806x
The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.
Cc: devicet...@vger.kernel.org
Reviewed-by: Andy Gross
Signed-off-by: Archit Taneja
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 1e1b3f0..a7f0ee5 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -350,5 +350,20 @@
status = "disabled";
};
+ nand@1ac0 {
+ compatible = "qcom,ebi2-nandc";
+ reg = <0x1ac0 0x800>;
+
+ clocks = < EBI2_CLK>,
+< EBI2_AON_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
+
+ status = "disabled";
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform
Enable the NAND controller node on the AP148 platform. Provide pinmux
information.
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..2e88eff 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,28 @@
bias-none;
};
};
+ nand_pins: nand_pins {
+ mux {
+ pins = "gpio34", "gpio35", "gpio36",
+ "gpio37", "gpio38", "gpio39",
+ "gpio40", "gpio41", "gpio42",
+ "gpio43", "gpio44", "gpio45",
+ "gpio46", "gpio47";
+ function = "nand";
+ drive-strength = <10>;
+ bias-disable;
+ };
+ pullups {
+ pins = "gpio39";
+ bias-pull-up;
+ };
+ hold {
+ pins = "gpio40", "gpio41", "gpio42",
+ "gpio43", "gpio44", "gpio45",
+ "gpio46", "gpio47";
+ bias-bus-hold;
+ };
+ };
};
gsbi@1630 {
@@ -93,5 +115,19 @@
sata@2900 {
status = "ok";
};
+
+ nand@1ac0 {
+ status = "ok";
+
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ nand-ecc-strength = <4>;
+ nand-bus-width = <8>;
+ };
};
};
+
+_dma {
+ status = "ok";
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/5] dt/bindings: qcom_nandc: Add DT bindings
Add DT bindings document for the Qualcomm NAND controller driver.
Cc: devicet...@vger.kernel.org
v3:
- Don't use '0x' when specifying nand controller address space
- Add optional property for on-flash bbt usage
Acked-by: Andy Gross
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/mtd/qcom_nandc.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..1de4643
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,49 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible: should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks: must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+ always on clock
+- dmas:DMA specifier, consisting of a phandle to the
ADM DMA
+ controller node and the channel number to be used for
+ NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names: must be "rxtx"
+- qcom,cmd-crci: must contain the ADM command type CRCI block instance
+ number specified for the NAND controller on the given
+ platform
+- qcom,data-crci: must contain the ADM data type CRCI block instance
+ number specified for the NAND controller on the given
+ platform
+
+Optional properties:
+- nand-bus-width: bus width. Must be 8 or 16. If not present, 8 is chosen
+ as default
+
+- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
+ bits. If not present, 4 is chosen as default
+- nand-on-flash-bbt: Create/use on-flash bad block table
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@1ac0 {
+ compatible = "qcom,ebi2-nandc";
+ reg = <0x1ac0 0x800>;
+
+ clocks = < EBI2_CLK>,
+< EBI2_AON_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
+
+ partition@0 {
+ ...
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/5] mtd: nand: Qualcomm NAND controller driver
The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx, MDM9x15 series. It exists as a sub block inside the IPs EBI2 (External Bus Interface 2) and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a broader interface for external slow peripheral devices such as LCD and NAND/NOR flash memory or SRAM like interfaces. We add support for the NAND controller found within EBI2. For the SoCs of our interest, we only use the NAND controller within EBI2. Therefore, it's safe for us to assume that the NAND controller is a standalone block within the SoC. The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and 16 bit correction/step) and RS ECC(4 bit correction/step) that covers main and spare data. The controller contains an internal 512 byte page buffer to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA for register read/write and data transfers. The controller performs page reads and writes at a codeword/step level of 512 bytes. It can support up to 2 external chips of different configurations. The driver prepares register read and write configuration descriptors for each codeword, followed by data descriptors to read or write data from the controller's internal buffer. It uses a single ADM DMA channel that we get via dmaengine API. The controller requires 2 ADM CRCIs for command and data flow control. These are passed via DT. The ecc layout used by the controller is syndrome like, but we can't use the standard syndrome ecc ops because of several reasons. First, the amount of data bytes covered by ecc isn't same in each step. Second, writing to free oob space requires us writing to the entire step in which the oob lies. This forces us to create our own ecc ops. One more difference is how the controller accesses the bad block marker. The controller ignores reading the marker when ECC is enabled. ECC needs to be explicity disabled to read or write to the bad block marker. For this reason, we use the newly created flag NAND_BBT_ACCESS_BBM_RAW to read the factory provided bad block markers. v3: - Refactor dma functions for maximum reuse - Use dma_slave_confing on stack - optimize and clean upempty_page_fixup using memchr_inv - ensure portability with dma register reads using le32_* funcs - use NAND_USE_BOUNCE_BUFFER instead of doing it ourselves - fix handling of return values of dmaengine funcs - constify wherever possible - Remove dependency on ADM DMA in Kconfig - Misc fixes and clean ups v2: - Use new BBT flag that allows us to read BBM in raw mode - reduce memcpy-s in the driver - some refactor and clean ups because of above changes Reviewed-by: Andy Gross Signed-off-by: Archit Taneja --- drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/qcom_nandc.c | 1913 + 3 files changed, 1921 insertions(+) create mode 100644 drivers/mtd/nand/qcom_nandc.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5b2806a..6085b8a 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -538,4 +538,11 @@ config MTD_NAND_HISI504 help Enables support for NAND controller on Hisilicon SoC Hip04. +config MTD_NAND_QCOM + tristate "Support for NAND on QCOM SoCs" + depends on ARCH_QCOM + help + Enables support for NAND flash chips on SoCs containing the EBI2 NAND + controller. This controller is found on IPQ806x SoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 1f897ec..87b6a1d 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -53,5 +53,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ +obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c new file mode 100644 index 000..e1f1576 --- /dev/null +++ b/drivers/mtd/nand/qcom_nandc.c @@ -0,0 +1,1913 @@ +/* + * Copyright (c) 2015, The Linux Foundation. All rights reserved. + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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 + +/* NANDc reg
[PATCH v3 1/5] mtd: nand: Create a BBT flag to access bad block markers in raw mode
Some controllers can access the factory bad block marker from OOB only
when they read it in raw mode. When ECC is enabled, these controllers
discard reading/writing bad block markers, preventing access to them
altogether.
The bbt driver assumes MTD_OPS_PLACE_OOB when scanning for bad blocks.
This results in the nand driver's ecc->read_oob() op to be called, which
works with ECC enabled.
Create a new BBT option flag that tells nand_bbt to force the mode to
MTD_OPS_RAW. This would result in the correct op being called for the
underlying nand controller driver.
Reviewed-by: Andy Gross
Signed-off-by: Archit Taneja
---
drivers/mtd/nand/nand_base.c | 6 +-
drivers/mtd/nand/nand_bbt.c | 6 +-
include/linux/mtd/bbm.h | 7 +++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ceb68ca..0a0c524 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -394,7 +394,11 @@ static int nand_default_block_markbad(struct mtd_info
*mtd, loff_t ofs)
} else {
ops.len = ops.ooblen = 1;
}
- ops.mode = MTD_OPS_PLACE_OOB;
+
+ if (unlikely(chip->bbt_options & NAND_BBT_ACCESS_BBM_RAW))
+ ops.mode = MTD_OPS_RAW;
+ else
+ ops.mode = MTD_OPS_PLACE_OOB;
/* Write to first/last page(s) if necessary */
if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 63a1a36..f2d89c9 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -420,7 +420,11 @@ static int scan_block_fast(struct mtd_info *mtd, struct
nand_bbt_descr *bd,
ops.oobbuf = buf;
ops.ooboffs = 0;
ops.datbuf = NULL;
- ops.mode = MTD_OPS_PLACE_OOB;
+
+ if (unlikely(bd->options & NAND_BBT_ACCESS_BBM_RAW))
+ ops.mode = MTD_OPS_RAW;
+ else
+ ops.mode = MTD_OPS_PLACE_OOB;
for (j = 0; j < numpages; j++) {
/*
diff --git a/include/linux/mtd/bbm.h b/include/linux/mtd/bbm.h
index 36bb6a5..f67f84a 100644
--- a/include/linux/mtd/bbm.h
+++ b/include/linux/mtd/bbm.h
@@ -116,6 +116,13 @@ struct nand_bbt_descr {
#define NAND_BBT_NO_OOB_BBM0x0008
/*
+ * Force MTD_OPS_RAW mode when trying to access bad block markes from OOB. To
+ * be used by controllers which can access BBM only when ECC is disabled, i.e,
+ * when in RAW access mode
+ */
+#define NAND_BBT_ACCESS_BBM_RAW0x0010
+
+/*
* Flag set by nand_create_default_bbt_descr(), marking that the nand_bbt_descr
* was allocated dynamicaly and must be freed in nand_release(). Has no meaning
* in nand_chip.bbt_options.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/5] mtd: Qualcomm NAND controller driver
Add support for the NAND controller driver for SoC's that contain EBI2. For now, the only SoC upstream that has EBI2 is IPQ806x. The original version was posted a while back. The main comments were about the driver not being able to use nand_bbt. This was because the controller could read factory bad block markers only in RAW mode. This forced us to implement our own versions of chip->block_bad and chip->blobk_markbad, and also we had to skip creating a BBT. Discussions with Kevin Cernekee concluded that having a new BBT flag that incorporates this controller's special requirement is a possible option. The new version makes use of this flag and now uses nand_bbt, at the cost of implement read_oob_raw and write_oob_raw ops. The patchset requires the v6 ADM dmaengine patches posted by Andy: https://lkml.org/lkml/2015/3/17/19 v3: - Various fixes and clean ups suggested by Stephen Boyd. v2: - Added a new BBT flag that allows us to read BBM in raw mode - reduce memcpy-s in the driver - some refactor and clean ups because of above changes v1: - original series: https://lkml.org/lkml/2015/1/16/317 Archit Taneja (5): mtd: nand: Create a BBT flag to access bad block markers in raw mode mtd: nand: Qualcomm NAND controller driver dt/bindings: qcom_nandc: Add DT bindings arm: qcom: dts: Add NAND controller node for ipq806x arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform .../devicetree/bindings/mtd/qcom_nandc.txt | 49 + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 + arch/arm/boot/dts/qcom-ipq8064.dtsi| 15 + drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/nand_base.c |6 +- drivers/mtd/nand/nand_bbt.c|6 +- drivers/mtd/nand/qcom_nandc.c | 1913 include/linux/mtd/bbm.h|7 + 9 files changed, 2038 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt create mode 100644 drivers/mtd/nand/qcom_nandc.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 4/5] ARM: dts: DRA7: Add memory map region entries for qspi
On 08/01/2015 02:58 AM, Brian Norris wrote:
> On Tue, Jul 28, 2015 at 02:11:15PM +0530, Vignesh R wrote:
>> Add qspi memory mapped region entries for DRA7xx based SoCs.
>>
>> Signed-off-by: Vignesh R
>> ---
>> arch/arm/boot/dts/am4372.dtsi | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index ade28c790f4b..5317a0f24ab9 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -902,7 +902,9 @@
>>
>> qspi: qspi@4790 {
>> compatible = "ti,am4372-qspi";
>> -reg = <0x4790 0x100>;
>> +reg = <0x4790 0x100>,
>> + <0x3000 0x3ff>;
>
> Are you sure this region is 1 byte shy of 64MB in length? Same question
> for patch 5.
>
Oops, my bad... Its 64MB in length, I entered offset of last byte
instead of length. Will correct this in the actual patch.
>> +reg-names = "qspi_base", "qspi_mmap";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> ti,hwmods = "qspi";
>> --
>> 2.4.6
>>
--
Regards
Vignesh
--
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 4/5] ARM: dts: DRA7: Add memory map region entries for qspi
On 07/31/2015 11:49 PM, Mark Brown wrote:
> On Tue, Jul 28, 2015 at 02:11:15PM +0530, Vignesh R wrote:
>> Add qspi memory mapped region entries for DRA7xx based SoCs.
>>
>> Signed-off-by: Vignesh R
>
>> qspi: qspi@4790 {
>> compatible = "ti,am4372-qspi";
>> -reg = <0x4790 0x100>;
>> +reg = <0x4790 0x100>,
>> + <0x3000 0x3ff>;
>> +reg-names = "qspi_base", "qspi_mmap";
>
> The DT binding document for the controller needs to be extended to
> document this change in the binding.
>
DT bindings are already documented at
Documentation/devicetree/bindings/spi/ti_qspi.txt. Did you mean to add
this node as an example in that file?
--
Regards
Vignesh
--
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 1/5] spi: introduce flag for memory mapped read
Hi, On 7/31/2015 11:47 PM, Mark Brown wrote: > On Tue, Jul 28, 2015 at 02:11:12PM +0530, Vignesh R wrote: > >> Introduce use_mmap_read field in spi_message struct. This can be set by >> mtd devices (m25p80) to indicate to spi-master (ti-qspi) to perform >> memory mapped read. This helps to distinguish whether the spi-message is >> from mtd layer(hence mmap read is possible) or by other spi devices. > > Based on this description and... > >> + * @use_mmap_mode: Indicate to spi master to perform memory mapped >> + * read if possible. > > ...the internal documentation I unable to tell what is meant by "perform > a memory mapped read", at least to the extent where it is visible > outside of the driver. This means we can't really use this as a generic > API since other people won't be able to tell what it does. > Will the following documentation provide better idea regarding the flag: @use_mmap_mode: Some SPI controller chips are optimized for interacting with serial flash memories. These chips have memory mapped interface, through which entire serial flash memory slave can be read/written as if though they are physical memories (like RAM). Using this interface, flash can be accessed using memcpy() function and the spi controller hardware will take care of communicating with serial flash over SPI. Setting this flag will indicate the SPI controller driver that the spi_message is from mtd layer to read from/write to flash. The SPI master driver can then appropriately switch the controller to memory mapped interface to read from/write to flash, based on this flag (See drivers/spi/spi-ti-qspi.c for example). NOTE: If the SPI controller chip lacks memory mapped interface, then the driver will ignore this flag and use normal SPI protocol to read from/write to flash. Communication with non-flash SPI devices is not possible using the memory mapped interface. I can update the patch commit message and documentation accordingly? Regards Vignesh -- 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: Re: [PATCH] PM / devfreq: event: Remove incorrect property in exynos-ppmu DT binding
> Hello Myungjoo,
>
> On 07/23/2015 10:30 AM, Javier Martinez Canillas wrote:
> > Hello Chanwoo,
> >
> > On 07/23/2015 10:19 AM, Chanwoo Choi wrote:
> >> Hi Javier,
> >>
> >> On 07/13/2015 03:58 PM, Javier Martinez Canillas wrote:
> >>> The exynos-ppmu driver is only a clock consumer and not a clock
> >>> provider but its Device Tree binding listed #clock-cells as an
> >>> optional property.
> >>>
> >>> Signed-off-by: Javier Martinez Canillas
> >>>
[]
> >>>
> >>> Example1 : PPMU nodes in exynos3250.dtsi are listed below.
> >>>
> >>>
> >>
> >> Reviewed-by: Chanwoo Choi
> >>
> >> + Devfreq maintainer (Myungjoo Ham)
> >
> > Thanks for the review and for cc'ing Myungjoo. The get_maintainer.pl script
> > didn't tell me that so I think Documentation/devicetree/bindings/devfreq/
> > sub-dir should be added to the DEVICE FREQUENCY (DEVFREQ) entry in the
> > MAINTAINERS file.
> >
> >> I think that this patch will be more appropriate on devfreq git tree
> >> than linux-samsung git tree.
> >>
> >
> > Agreed.
> >
>
> Any comments about this patch?
Nope. It's applied.
Thanks.
MyungJoo
>
>
>
> Best regards,
> --
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: samples/kdbus/kdbus-workers.c and cross compiling MIPS
On Fri, 2015-07-31 at 09:29 -0700, Greg Kroah-Hartman wrote: > On Fri, Jul 31, 2015 at 05:01:01PM +1000, Michael Ellerman wrote: > > It's obviously possible that some samples build with that configuration, but > > building against another arch'es kernel headers just seems like it's asking > > for > > trouble. Even if we can build the samples, they will never run correctly. > > > > So I suggest we should just disable SAMPLES if we're cross compiling, full > > stop. > > Yes, that seems like a much better solution overall. Can you send a > patch for this? Yep, will do. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] HID: hid-input: Fix accessing freed memory during device disconnect
On 03.08.2015 09:01, Krzysztof Kozlowski wrote:
> During unbinding the driver was dereferencing a pointer to memory
> already freed by power_supply_unregister().
>
> Driver was freeing its internal description of battery through pointers
> stored in power_supply structure. However, because the core owns the
> power supply instance, after calling power_supply_unregister() this
> memory is freed and the driver cannot access these members.
>
> Fix this by storing the pointer to internal description of battery in a
> local variable before calling power_supply_unregister(), so the pointer
> remains valid.
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: H.J. Lu
> Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
> Cc:
>
> ---
> Changes since v1:
> 1. Re-work idea, use local variable instead of devm-like functions
>(pointed out by Dmitry Torokhov).
> 2. Adjusted subject and commit message.
I missed the warning:
drivers/hid/hid-input.c:470:11: warning: assignment discards ‘const’
qualifier from pointer target type
I'll fix this and send v3.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup
Ezequiel Garcia writes:
> Just tested linux-next (hence *without* the patchset) and I see
> the same "Wait time out". In other words, pxa3xx-nand is broken
> on PXA :/
>
> Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself.
> Reverting the recent commits on pxa3xx-nand doesn't help.
>
> ce914e6 mtd: nand: pxa3xx: fix build on ARM64
> afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout
> e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling
> 7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0
> ed446cc Merge MTD updates into -next
> e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0
> 2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt
> 8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining
> b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems
> 5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding
> eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling
> 17754ad mtd: nand: pxa3xx: Make of_device_id array const
> e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message
>
> Yet v3.18 succeeds to pass a few NAND blocks on nandtest.
>
> Robert: any ideas?
Actually yes, I worked on that this weekend.
Would you try the following patch [1] to see if it works for you ?
The issue I see is that :
- there is a bug in the clk driver for pxa3xx I introduced (CKEN_AB)
- and shutting down the GCU clock prevents the NAND from working (I can't
explain that one yet)
Cheers.
--
Robert
[1] Clocks patch
---8>---
diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
index c677b9ab5367..a47a0c40f937 100644
--- a/drivers/clk/pxa/clk-pxa3xx.c
+++ b/drivers/clk/pxa/clk-pxa3xx.c
@@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { "ring_osc_60mhz", "ac97" };
PARENTS(pxa3xx_sbus) = { "ring_osc_60mhz", "system_bus" };
PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
-#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ? : )
+#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ? : )
#define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp, \
div_hp, bit, is_lp, flags) \
PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp, \
@@ -136,6 +136,10 @@ PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
mult_hp, div_hp, delay)\
PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp, \
div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced, 0)
+#define PXA3XX_PBUS_CKENF(dev_id, con_id, bit, mult_lp, div_lp,
\
+ mult_hp, div_hp, delay, flag) \
+ PXA3XX_CKEN(dev_id, con_id, pxa3xx_pbus_parents, mult_lp, \
+ div_lp, mult_hp, div_hp, bit, pxa3xx_is_ring_osc_forced,
flag)
#define PXA3XX_CKEN_1RATE(dev_id, con_id, bit, parents)
\
PXA_CKEN_1RATE(dev_id, con_id, bit, parents,\
CKEN_AB(bit), (CKEN_ ## bit % 32), 0)
@@ -173,13 +177,13 @@ static struct desc_clk_cken pxa3xx_clocks[] __initdata = {
static struct desc_clk_cken pxa300_310_clocks[] __initdata = {
- PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0),
- PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0),
+ PXA3XX_PBUS_CKENF("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0,
CLK_IGNORE_UNUSED),
+ PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0,
CLK_IGNORE_UNUSED),
PXA3XX_CKEN_1RATE("pxa3xx-gpio", NULL, GPIO, pxa3xx_13MHz_bus_parents),
};
static struct desc_clk_cken pxa320_clocks[] __initdata = {
- PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 6, 0),
+ PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0,
CLK_IGNORE_UNUSED),
PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA320_GCU, 1, 1, 1, 1, 0),
PXA3XX_CKEN_1RATE("pxa3xx-gpio", NULL, GPIO, pxa3xx_13MHz_bus_parents),
};
@@ -187,7 +191,7 @@ static struct desc_clk_cken pxa320_clocks[] __initdata = {
static struct desc_clk_cken pxa93x_clocks[] __initdata = {
PXA3XX_PBUS_CKEN("pxa3xx-gcu", NULL, PXA300_GCU, 1, 1, 1, 1, 0),
- PXA3XX_PBUS_CKEN("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0),
+ PXA3XX_PBUS_CKENF("pxa3xx-nand", NULL, NAND, 1, 2, 1, 4, 0,
CLK_IGNORE_UNUSED),
PXA3XX_CKEN_1RATE("pxa93x-gpio", NULL, GPIO, pxa3xx_13MHz_bus_parents),
};
--
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 9/15 V2] drivers: rtc: Drop (un)likely before IS_ERR(_OR_NULL)
Hi
On Fri, 31 Jul 2015, Viresh Kumar wrote:
> IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> is no need to do that again from its callers. Drop it.
>
> gemini driver was using likely() for a failure case while the rtc driver
> is getting registered. That looks wrong and it should really be
> unlikely. But because we are killing all the unlikely() flags, lets kill
> that too.
>
> Signed-off-by: Viresh Kumar
> ---
> V1->V2:
> - Removed the likely() part from gemini driver and the changelog wasn't
> updated to match that. Fixed the changelog now.
>
> drivers/rtc/interface.c | 2 +-
> drivers/rtc/rtc-bfin.c | 2 +-
> drivers/rtc/rtc-gemini.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index 11b639067312..5836751b8203 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -564,7 +564,7 @@ enum hrtimer_restart rtc_pie_update_irq(struct hrtimer
> *timer)
> void rtc_update_irq(struct rtc_device *rtc,
> unsigned long num, unsigned long events)
> {
> - if (unlikely(IS_ERR_OR_NULL(rtc)))
> + if (IS_ERR_OR_NULL(rtc))
> return;
>
> pm_stay_awake(rtc->dev.parent);
> diff --git a/drivers/rtc/rtc-bfin.c b/drivers/rtc/rtc-bfin.c
> index 3d44b11721ea..535a5f9338d0 100644
> --- a/drivers/rtc/rtc-bfin.c
> +++ b/drivers/rtc/rtc-bfin.c
> @@ -361,7 +361,7 @@ static int bfin_rtc_probe(struct platform_device *pdev)
> /* Register our RTC with the RTC framework */
> rtc->rtc_dev = devm_rtc_device_register(dev, pdev->name, _rtc_ops,
> THIS_MODULE);
> - if (unlikely(IS_ERR(rtc->rtc_dev)))
> + if (IS_ERR(rtc->rtc_dev))
> return PTR_ERR(rtc->rtc_dev);
>
> /* Grab the IRQ and init the hardware */
> diff --git a/drivers/rtc/rtc-gemini.c b/drivers/rtc/rtc-gemini.c
> index 35f4486738fc..2fed93e1114a 100644
> --- a/drivers/rtc/rtc-gemini.c
> +++ b/drivers/rtc/rtc-gemini.c
> @@ -148,7 +148,7 @@ static int gemini_rtc_probe(struct platform_device *pdev)
>
> rtc->rtc_dev = rtc_device_register(pdev->name, dev,
> _rtc_ops, THIS_MODULE);
> - if (likely(IS_ERR(rtc->rtc_dev)))
> + if (IS_ERR(rtc->rtc_dev))
> return PTR_ERR(rtc->rtc_dev);
>
> return 0;
> --
> 2.4.0
>
>
For the mach-gemini part
Acked-by: Hans Ulli Kroll
--
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: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
On Mon, Aug 3, 2015 at 12:22 PM, Julian Calaby wrote: > Hi Chen-Yu, > > On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai wrote: >> Hi, >> >> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby >> wrote: >>> Hi Timo, >>> >>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson >>> wrote: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. >>> >>> Surely it wouldn't be added here if some could supply 0.9v. >> >> On the side, the original OPPs in the FEX files are actually >> frequency/voltage ranges, and not just points. Mainlines OPPv2 >> will support these, along with turbo frequencies. > > Ah, that makes sense. > >> Furthermore, the FEX files also have fields that limit the >> minimum and maximum frequencies. > > Is this going to be supported by OPPv2 too? IIRC yes, OPPv2 moves to a range profile. OPPv2 is not merged yet. >>> Is the code that uses this smart enough to sensibly switch between two >>> operating points with the same frequency and different voltages? If >>> so, maybe just add a 144MHz @ 1.0v operating point? >> >> You could try. Though I really don't see much to gain here. > > From what I recall, lower frequency = less power usage, though my > experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing > a lot of details. This is the sort of thing that requires thorough > testing on a dev board. I agree, though my limited experiences tell me that the major savings come from lowering the core voltage. >>> (Alternatively, would it make sense to modify the code that uses this >>> to use frequencies with voltages specified that are lower than can be >>> supplied with the lowest voltage it can?) >> >> I think that's a bit harder to get accepted. > > Oh, definitely. It kinda makes sense, but at the same time it'll > require some seriously thorough testing on a lot of different boards. > > My only real objection here is are there boards that can go down to > 0.9v and if so, won't this change make them less power efficient in > the almost-idle case? And are those power savings enough to justify > not accepting this patch? This will require most testing as well. (sigh) Alas, my boards aren't stable enough at 0.9V, so I can't say much about it. ChenYu -- 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.2 000/164] 3.2.70-rc1 review
On 08/02/2015 02:49 PM, Ben Hutchings wrote: On Sat, 2015-08-01 at 19:23 -0700, Guenter Roeck wrote: On 08/01/2015 05:02 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.70 release. There are 164 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Aug 05 23:00:00 UTC 2015. Anything received after that time might be too late. Build results: > total: 96 pass: 96 fail: 0 Qemu test results: > total: 22 pass: 22 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Thanks. I was checking there as I went along, which is why I added patches 158-160. (It looks like you turned on some new config options for those architectures recently, as the bugs those fix don't seem to be triggered by earlier patches.) Hi Ben, I added several 'allnoconfig' and 'allmodconfig' builds. At the same time, I changed the approach on how known failures are handled; those are now added to an exception list which won't be built in the first place. The current exception list for builds in 3.2 is: alpha:allnoconfig arm:allnoconfig arm:allmodconfig avr32:allnoconfig m68k:allnoconfig microblaze:allnoconfig mips:allmodconfig openrisc:allnoconfig parisc:allnoconfig sparc32:allmodconfig xtensa:defconfig xtensa:allmodconfig xtensa:allnoconfig and for qemu tests: powerpc:qemu_virtex440_defconfig arm:qemu_arm_vexpress_defconfig:vexpress-a15 arm:multi_v7_defconfig:vexpress-a9 arm:multi_v7_defconfig:vexpress-a15 There may be more as I am adding more builds. I didn't expect you to fix any of those. If you are, let me know, and I'll drop the build/qemu exceptions. Thanks, Guenter -- 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: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Chen-Yu, On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai wrote: > Hi, > > On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby wrote: >> Hi Timo, >> >> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson >> wrote: >>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 >>> boards >>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise >>> the >>> voltage for the lowest operating point to 1.0V so all boards can actually >>> use >>> it. >> >> Surely it wouldn't be added here if some could supply 0.9v. > > On the side, the original OPPs in the FEX files are actually > frequency/voltage ranges, and not just points. Mainlines OPPv2 > will support these, along with turbo frequencies. Ah, that makes sense. > Furthermore, the FEX files also have fields that limit the > minimum and maximum frequencies. Is this going to be supported by OPPv2 too? >> Is the code that uses this smart enough to sensibly switch between two >> operating points with the same frequency and different voltages? If >> so, maybe just add a 144MHz @ 1.0v operating point? > > You could try. Though I really don't see much to gain here. >From what I recall, lower frequency = less power usage, though my experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing a lot of details. This is the sort of thing that requires thorough testing on a dev board. >> (Alternatively, would it make sense to modify the code that uses this >> to use frequencies with voltages specified that are lower than can be >> supplied with the lowest voltage it can?) > > I think that's a bit harder to get accepted. Oh, definitely. It kinda makes sense, but at the same time it'll require some seriously thorough testing on a lot of different boards. My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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] pci/pciehp: bail on bogus pcie reads from removed devices
On Tue, Jul 21, 2015 at 12:25:30PM -0400, Jarod Wilson wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=99841
>
> Seems like a read of all 1's from a register of a device that has gone
> away should be taken as a sign that the device has gone away.
> Section 6.2.10 of the PCIE spec (v4.0, rev 0.3, Feb 19, 2014) suggests as
> much with this snippet:
>
> |IMPLEMENTATION NOTE
> |Data Value of All 1’s
> |Many platforms, including those supporting RP Extensions for DPC, can
> |return a data value of all 1’s to software when an error is associated
> |with a PCI Express Configuration, I/O, or Memory Read Request. During DPC,
> |the Downstream Port discards Requests destined for the Link and completes
> |them with an error (i.e., either with an Unsupported Request (UR) or
> |Completer Abort (CA) Completion Status). By ending a series of MMIO or
> |configuration space operations with a read to an address with a known
> |data value not equal to all 1’s, software may determine if a Completer
> |has been removed or DPC has been triggered.
>
> I'm not sure the above is directly relevant to this case, but the same
> principle (reading all 1's means the device is probably gone) seems to
> hold.
>
> This is based on part of a debugging patch Bjorn posted in the referenced
> bugzilla, and its required to make the HP ZBook G2 I've got here not barf
> when disconnecting a thunderbolt ethernet adapter and corrupt memory.
>
> Suggested-by: Bjorn Helgaas
> CC: Bjorn Helgaas
> CC: Rafael J. Wysocki
> CC: linux-...@vger.kernel.org
> Signed-off-by: Jarod Wilson
Hi Jarod,
I think there are two issues here:
1) pciehp doesn't handle all 1's correctly
2) use-after-free of hotplug_slot
This patch is for the first issue. I think it's correct, but I still
have a question or two. I attached an updated version of the patch
and changelog.
Here's the path I think we're taking: 03:03.0 receives pciehp
interrupt for removal (link down and card not present), and we call
pciehp_unconfigure_device() for 05:00.0 and everything downstream from
it. Part of this is removing 06:00.0. I expected this would use this
path:
pcie_port_remove_service# .remove method for 06:00.0
dev_printk("unloading service driver ...")
pciehp_remove # hpdriver_portdrv.remove
pciehp_release_ctrl
pcie_shutdown_notification
pcie_disable_notification
pcie_write_cmd
pcie_do_write_cmd(..., true)# wait
pcie_wait_cmd
pcie_poll_cmd
read PCI_EXP_SLTSTA# would get 0x
read PCI_EXPT_SLTCTL# would get 0x
so I added checks for ~0 data in pcie_poll_cmd() and
pcie_do_write_cmd().
But the dmesg log shows that we were in pcie_isr(), and I don't
understand yet how we got there. Can you help figure that out? Maybe
put a dump_stack() in pcie_isr() or something?
OK, now for the second issue. I think we have a lifetime issue with
the hotplug_slot structure.
pcie_port_remove_service# .remove method
"unloading service driver ..."
pciehp_remove # hpdriver_portdrv.remove
cleanup_slot
pci_hp_deregister(ctrl->slot->hotplug_slot)
hotplug->release
release_slot # hotplug->release
ctrl_dbg("release_slot: physical_slot = 9")
kfree(hotplug_slot->ops)
kfree(hotplug_slot->info)
kfree(hotplug_slot) # <--- FREE
pci_slot->hotplug = NULL
pci_destroy_slot
kobject_put(pci_slot->kobj)
pciehp_release_ctrl
pcie_shutdown_notification
pcie_disable_notification
pcie_write_cmd
...
pcie_isr# not sure how we got here
ctrl_info("Latch open on Slot(%s)", slot_name(slot)) # <--- USE
I haven't chased this down completely either, but I'm pretty sure
we're looking at ctrl->slot->hotplug_slot to get the name after we've
already freed it, and this accounts for the garbage slot names we
print.
This seems like a pretty serious problem as well, but I don't
understand it well enough to propose a fix.
I suspect both of these issues affect all the hotplug drivers, not
just pciehp.
Bjorn
commit b24e231a9e846f0420746a56cea7a48b41f3798b
Author: Jarod Wilson
Date: Tue Jul 21 12:25:30 2015 -0400
PCI: pciehp: Handle invalid data when reading from non-existent devices
It's platform-dependent, but an MMIO read to a non-existent PCI device
generally returns data with all bits set. This happens when the host
bridge or Root Complex times out waiting for a response from the device and
fabricates return data to complete the CPU's read.
One example, reported in the bugzilla below, involved this hierarchy:
pci :00:1c.0: PCI bridge to [bus 02-3a] Root Port
pci :02:00.0: PCI bridge to [bus
Re: [PATCH] mm: add the block to the tail of the list in expand()
On 08/02/2015 07:05 PM, Xishi Qiu wrote: >> > Also, this might not do very much good in practice. If you are >> > splitting a high-order page, you are doing the split because the >> > lower-order lists are empty. So won't that list_add() be to an empty > > I made a mistake, you are right, all the lower-order lists are empty, > so it is no sense to add to the tail. I actually tested this experimentally and the lists are not always empty. It's probably __rmqueue_smallest() vs. __rmqueue_fallback() logic. In any case, you might want to double-check. -- 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] fs: orangefs: remove execute priviliges from module params
This makes no sense and causes warnings on boot.
Signed-off-by: Sasha Levin
---
fs/orangefs/pvfs2-mod.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/orangefs/pvfs2-mod.c b/fs/orangefs/pvfs2-mod.c
index 69289c5..d80537d 100644
--- a/fs/orangefs/pvfs2-mod.c
+++ b/fs/orangefs/pvfs2-mod.c
@@ -65,7 +65,7 @@ static struct file_system_type pvfs2_fs_type = {
};
module_param(hash_table_size, int, 0);
-module_param(module_parm_debug_mask, ulong, 0755);
+module_param(module_parm_debug_mask, ulong, 0644);
module_param(op_timeout_secs, int, 0);
module_param(slot_timeout_secs, int, 0);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: dw_mmc: Fix coding style issues
Hi, Shawn.
On 07/28/2015 12:06 PM, Shawn Lin wrote:
> This patch fixes the following issues reported by checkpatch.pl:
> - use -EINVAL instead of -ENOSYS, to fix warning message:
> "ENOSYS means 'invalid syscall nr' and nothing else"
> - split lines whose length is greater than 80 characters
> - avoid quoted string split across lines
> - use min_t instead of min, to fix warning message:
> "min() should probably be min_t(int, cnt, host->part_buf_count)"
Thanks for fixing coding style.
But i will apply this patch(https://patchwork.kernel.org/patch/6672581/).
So if you can fix with this patch, then it's helpful to me.
If you can't, i will modify your patch before applying.
How about?
>
> Signed-off-by: Shawn Lin
> ---
>
> drivers/mmc/host/dw_mmc.c | 85
> ++-
> 1 file changed, 54 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 40e9d8e..6aede38 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -235,8 +235,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
> struct mmc_command *cmd)
> struct dw_mci *host = slot->host;
> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
> u32 cmdr;
> - cmd->error = -EINPROGRESS;
>
> + cmd->error = -EINPROGRESS;
> cmdr = cmd->opcode;
>
> if (cmd->opcode == MMC_STOP_TRANSMISSION ||
> @@ -371,6 +371,7 @@ static void dw_mci_start_command(struct dw_mci *host,
>cmd->arg, cmd_flags);
>
> mci_writel(host, CMDARG, cmd->arg);
> + /* Make sure CMDARG is configured before CMD */
> wmb();
> dw_mci_wait_while_busy(host, cmd_flags);
>
> @@ -380,6 +381,7 @@ static void dw_mci_start_command(struct dw_mci *host,
> static inline void send_stop_abort(struct dw_mci *host, struct mmc_data
> *data)
> {
> struct mmc_command *stop = data->stop ? data->stop : >stop_abort;
> +
> dw_mci_start_command(host, stop, host->stop_cmdr);
> }
>
> @@ -463,6 +465,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
> struct mmc_data *data,
> unsigned int sg_len)
> {
> int i;
> +
> if (host->dma_64bit_address == 1) {
> struct idmac_desc_64addr *desc = host->sg_cpu;
>
> @@ -524,7 +527,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
> struct mmc_data *data,
> desc->des0 |= cpu_to_le32(IDMAC_DES0_LD);
> }
>
> - wmb();
> + wmb(); /* drain writebuffer */
> }
>
> static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
> @@ -542,7 +545,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
> unsigned int sg_len)
> temp |= SDMMC_CTRL_USE_IDMAC;
> mci_writel(host, CTRL, temp);
>
> - wmb();
> + wmb(); /* drain writebuffer */
>
> /* Enable the IDMAC */
> temp = mci_readl(host, BMOD);
> @@ -589,7 +592,9 @@ static int dw_mci_idmac_init(struct dw_mci *host)
> host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>
> /* Forward link the descriptor list */
> - for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++,
> p++) {
> + for (i = 0, p = host->sg_cpu;
> + i < host->ring_size - 1;
> + i++, p++) {
> p->des3 = cpu_to_le32(host->sg_dma +
> (sizeof(struct idmac_desc) * (i + 1)));
> p->des1 = 0;
> @@ -718,7 +723,7 @@ static void dw_mci_adjust_fifoth(struct dw_mci *host,
> struct mmc_data *data)
> u32 fifo_width = 1 << host->data_shift;
> u32 blksz_depth = blksz / fifo_width, fifoth_val;
> u32 msize = 0, rx_wmark = 1, tx_wmark, tx_wmark_invers;
> - int idx = (sizeof(mszs) / sizeof(mszs[0])) - 1;
> + int idx = ARRAY_SIZE(mszs) - 1;
>
> tx_wmark = (host->fifo_depth) / 2;
> tx_wmark_invers = host->fifo_depth - tx_wmark;
> @@ -843,6 +848,7 @@ static int dw_mci_submit_data_dma(struct dw_mci *host,
> struct mmc_data *data)
> static void dw_mci_submit_data(struct dw_mci *host, struct mmc_data *data)
> {
> unsigned long irqflags;
> + int flags = SG_MITER_ATOMIC;
> u32 temp;
>
> data->error = -EINPROGRESS;
> @@ -859,7 +865,6 @@ static void dw_mci_submit_data(struct dw_mci *host,
> struct mmc_data *data)
> }
>
> if (dw_mci_submit_data_dma(host, data)) {
> - int flags = SG_MITER_ATOMIC;
> if (host->data->flags & MMC_DATA_READ)
> flags |= SG_MITER_TO_SG;
> else
> @@ -906,6 +911,7 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
> cmd, u32 arg)
> unsigned int cmd_status = 0;
>
> mci_writel(host, CMDARG, arg);
> + /* Make sure CMDARG is configured before CMD */
> wmb();
> dw_mci_wait_while_busy(host, cmd);
> mci_writel(host, CMD,
[PATCH v1 2/2] pinctrl: rockchip: only enable gpio clock when it setting
gpio can keep state even the clock disable, for save power
consumption, only enable gpio clock when it setting
Signed-off-by: Heiko Stuebner
Signed-off-by: huang lin
Signed-off-by: huang lin
---
drivers/pinctrl/pinctrl-rockchip.c | 60 ++
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index cc2843a..445829f 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -945,17 +945,20 @@ static int _rockchip_pmx_gpio_set_direction(struct
gpio_chip *chip,
if (ret < 0)
return ret;
+ clk_enable(bank->clk);
spin_lock_irqsave(>slock, flags);
- data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
+ data = readl(bank->reg_base + GPIO_SWPORT_DDR);
/* set bit to 1 for output, 0 for input */
if (!input)
data |= BIT(pin);
else
data &= ~BIT(pin);
+
writel_relaxed(data, bank->reg_base + GPIO_SWPORT_DDR);
spin_unlock_irqrestore(>slock, flags);
+ clk_disable(bank->clk);
return 0;
}
@@ -1389,6 +1392,7 @@ static void rockchip_gpio_set(struct gpio_chip *gc,
unsigned offset, int value)
unsigned long flags;
u32 data;
+ clk_enable(bank->clk);
spin_lock_irqsave(>slock, flags);
data = readl(reg);
@@ -1398,6 +1402,7 @@ static void rockchip_gpio_set(struct gpio_chip *gc,
unsigned offset, int value)
writel(data, reg);
spin_unlock_irqrestore(>slock, flags);
+ clk_disable(bank->clk);
}
/*
@@ -1409,7 +1414,9 @@ static int rockchip_gpio_get(struct gpio_chip *gc,
unsigned offset)
struct rockchip_pin_bank *bank = gc_to_pin_bank(gc);
u32 data;
+ clk_enable(bank->clk);
data = readl(bank->reg_base + GPIO_EXT_PORT);
+ clk_disable(bank->clk);
data >>= offset;
data &= 1;
return data;
@@ -1546,9 +1553,10 @@ static int rockchip_irq_set_type(struct irq_data *d,
unsigned int type)
if (ret < 0)
return ret;
+ clk_enable(bank->clk);
spin_lock_irqsave(>slock, flags);
- data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
+ data = readl(bank->reg_base + GPIO_SWPORT_DDR);
data &= ~mask;
writel_relaxed(data, bank->reg_base + GPIO_SWPORT_DDR);
@@ -1603,6 +1611,7 @@ static int rockchip_irq_set_type(struct irq_data *d,
unsigned int type)
default:
irq_gc_unlock(gc);
spin_unlock_irqrestore(>slock, flags);
+ clk_disable(bank->clk);
return -EINVAL;
}
@@ -1611,6 +1620,7 @@ static int rockchip_irq_set_type(struct irq_data *d,
unsigned int type)
irq_gc_unlock(gc);
spin_unlock_irqrestore(>slock, flags);
+ clk_disable(bank->clk);
return 0;
}
@@ -1620,8 +1630,10 @@ static void rockchip_irq_suspend(struct irq_data *d)
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct rockchip_pin_bank *bank = gc->private;
+ clk_enable(bank->clk);
bank->saved_masks = irq_reg_readl(gc, GPIO_INTMASK);
irq_reg_writel(gc, ~gc->wake_active, GPIO_INTMASK);
+ clk_disable(bank->clk);
}
static void rockchip_irq_resume(struct irq_data *d)
@@ -1629,7 +1641,27 @@ static void rockchip_irq_resume(struct irq_data *d)
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct rockchip_pin_bank *bank = gc->private;
+ clk_enable(bank->clk);
irq_reg_writel(gc, bank->saved_masks, GPIO_INTMASK);
+ clk_disable(bank->clk);
+}
+
+static void rockchip_irq_gc_mask_clr_bit(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct rockchip_pin_bank *bank = gc->private;
+
+ clk_enable(bank->clk);
+ irq_gc_mask_clr_bit(d);
+}
+
+void rockchip_irq_gc_mask_set_bit(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct rockchip_pin_bank *bank = gc->private;
+
+ irq_gc_mask_set_bit(d);
+ clk_disable(bank->clk);
}
static int rockchip_interrupts_register(struct platform_device *pdev,
@@ -1640,7 +1672,7 @@ static int rockchip_interrupts_register(struct
platform_device *pdev,
unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
struct irq_chip_generic *gc;
int ret;
- int i;
+ int i, j;
for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {
if (!bank->valid) {
@@ -1649,11 +1681,19 @@ static int rockchip_interrupts_register(struct
platform_device *pdev,
continue;
}
+ ret = clk_enable(bank->clk);
+ if (ret) {
+ dev_err(>dev, "failed to enable clock for bank
%s\n",
+
[PATCH v1 1/2] clk: rockchip: add pclk_pd_pmu to the list of rk3288 critical clocks
pclk_pd_pmu needs to keep running and with the upcoming gpio clock
handling this is not always the case anymore. So add it to the list
of critical clocks for now.
Signed-off-by: Heiko Stuebner
Signed-off-by: huang lin
---
drivers/clk/rockchip/clk-rk3288.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 0df5bae..9040878 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -780,6 +780,7 @@ static const char *const rk3288_critical_clocks[]
__initconst = {
"aclk_cpu",
"aclk_peri",
"hclk_peri",
+ "pclk_pd_pmu",
};
#ifdef CONFIG_PM_SLEEP
--
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/
Re: [PATCH 2/2] media: atmel-isi: move configure_geometry() to start_streaming()
HI, Laurent
On 7/31/2015 10:37 PM, Laurent Pinchart wrote:
Hi Josh,
Thank you for the patch.
On Wednesday 17 June 2015 18:39:39 Josh Wu wrote:
As in set_fmt() function we only need to know which format is been set,
we don't need to access the ISI hardware in this moment.
So move the configure_geometry(), which access the ISI hardware, to
start_streaming() will make code more consistent and simpler.
Signed-off-by: Josh Wu
---
drivers/media/platform/soc_camera/atmel-isi.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c index 8bc40ca..b01086d
100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -390,6 +390,11 @@ static int start_streaming(struct vb2_queue *vq,
unsigned int count) /* Disable all interrupts */
isi_writel(isi, ISI_INTDIS, (u32)~0UL);
+ ret = configure_geometry(isi, icd->user_width, icd->user_height,
+ icd->current_fmt->code);
I would also make configure_geometry a void function, as the only failure case
really can't occur.
I think this case can be reached if user require a RGB565 format to
capture and sensor also support RGB565 format.
As atmel-isi driver will provide RGB565 support via the pass-through
mode (maybe we need re-consider this part).
So that will cause the configure_geometry() returns an error since it
found the bus format is not Y8 or YUV422.
In my opinion, we should not change configure_geometry()'s return type,
until we add a insanity format check before we call configure_geometry()
in future.
Apart from that,
Reviewed-by: Laurent Pinchart
Thanks for the review.
Best Regards,
Josh Wu
+ if (ret < 0)
+ return ret;
+
spin_lock_irq(>lock);
/* Clear any pending interrupt */
isi_readl(isi, ISI_STATUS);
@@ -477,8 +482,6 @@ static int isi_camera_init_videobuf(struct vb2_queue *q,
static int isi_camera_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
{
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
- struct atmel_isi *isi = ici->priv;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = >fmt.pix;
@@ -511,16 +514,6 @@ static int isi_camera_set_fmt(struct soc_camera_device
*icd, if (mf->code != xlate->code)
return -EINVAL;
- /* Enable PM and peripheral clock before operate isi registers */
- pm_runtime_get_sync(ici->v4l2_dev.dev);
-
- ret = configure_geometry(isi, pix->width, pix->height, xlate->code);
-
- pm_runtime_put(ici->v4l2_dev.dev);
-
- if (ret < 0)
- return ret;
-
pix->width = mf->width;
pix->height = mf->height;
pix->field = mf->field;
--
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 2/2] dt: power: st: Provide bindings for ST's OPPs
On 31-07-15, 09:37, Stephen Boyd wrote: > For qcom platforms, the frequency is almost always constant. > There may be some tables where we have a couple higher > frequencies than others because the speed bin is different. > Otherwise the voltage/current is changing based on the silicon > characteristics. So the biggest duplication is the frequency > property. > > As far as I know there isn't any algorithm to generate the > voltage values. It's all hand tuned tables based on the silicon > characterization, so we're left to store these tables in DT and > pick the right one at runtime. With regards to the table > explosion, on qcom platforms we haven't worried that we have ~40 > tables, but I'm not opposed to expressing it in a smaller set of > nodes, tables, etc. if that's what's desired. > > Do we need vendor specific properties for that though? Or do we > need some sort of extended frequency/voltage properties that are > arrays of values that we can index into based on some silicon > characteristics? I like the name based approach because it's > simple. Use this OPP table because it's called > x-y-z-characteristics and be done. Cramming the tables into less > lines may save us some typing and dtb space, but I'm not sure > what else it does. What about something like this: diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 0cb44dc21f97..bad7a8299b9c 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -74,6 +74,8 @@ This describes the OPPs belonging to a device. This node can have following reference an OPP. Optional properties: +- opp-cuts: One or more strings, describing the versions of hardware the OPPs + can support. - opp-shared: Indicates that device nodes using this OPP Table Node's phandle switch their DVFS state together, i.e. they share clock/voltage/current lines. Missing property means devices have independent clock/voltage/current lines, @@ -100,6 +102,9 @@ properties. Entries for multiple regulators must be present in the same order as regulators are specified in device's DT node. + If used with 'opp-cuts', then the number of entries present here must match + the number of strings present in 'opp-cuts'. + - opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process, aging, maximum operating temperature range etc.) as necessary. This may be used to -- 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/
[PATCH 1/1] add-ZTE-pid
Signed-off-by: Liu.Zhao
---
drivers/usb/serial/option.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index f0c0c53..6996308 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -285,6 +285,10 @@ static void option_instat_callback(struct urb *urb);
#define ZTE_PRODUCT_MC2718 0xffe8
#define ZTE_PRODUCT_AD3812 0xffeb
#define ZTE_PRODUCT_MC2716 0xffed
+#define ZTE_PRODUCT_ZM8620_X 0x0396
+#define ZTE_PRODUCT_ME3620_X 0x1432
+#define ZTE_PRODUCT_ME3620_L 0x1433
+#define ZTE_PRODUCT_ME3620_MBIM0x0426
#define BENQ_VENDOR_ID 0x04a5
#define BENQ_PRODUCT_H10 0x4068
@@ -544,6 +548,23 @@ static const struct option_blacklist_info
zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
};
+static const struct option_blacklist_info zte_zm8620_x_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_x_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_l_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+ .reserved = BIT(2) | BIT(3) | BIT(4),
+};
+
+
static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
};
@@ -1592,6 +1613,14 @@ static const struct usb_device_id option_ids[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+ .driver_info = (kernel_ulong_t)_zm8620_x_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+ .driver_info = (kernel_ulong_t)_me3620_x_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+ .driver_info = (kernel_ulong_t)_me3620_l_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+ .driver_info = (kernel_ulong_t)_me3620_mbim_blacklist },
{ USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_H10) },
{ USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },
--
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] igb: Fix a deadlock in igb_sriov_reinit
When igb_init_interrupt_scheme in igb_sriov_reinit is failed, the lock
acquired by rtnl_lock() is not released, which causes a deadlock.
This patch adds rtnl_unlock() in error handling to fix it.
Signed-off-by: Jia-Ju Bai
---
drivers/net/ethernet/intel/igb/igb_main.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 2f70a9b..311d1ca 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -7539,6 +7539,7 @@ static int igb_sriov_reinit(struct pci_dev *dev)
if (igb_init_interrupt_scheme(adapter, true)) {
dev_err(>dev, "Unable to allocate memory for queues\n");
+ rtnl_unlock();
return -ENOMEM;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] add-ZTE-pid
Signed-off-by: Liu.Zhao
---
drivers/usb/serial/option.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index f0c0c53..6996308 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -285,6 +285,10 @@ static void option_instat_callback(struct urb *urb);
#define ZTE_PRODUCT_MC2718 0xffe8
#define ZTE_PRODUCT_AD3812 0xffeb
#define ZTE_PRODUCT_MC2716 0xffed
+#define ZTE_PRODUCT_ZM8620_X 0x0396
+#define ZTE_PRODUCT_ME3620_X 0x1432
+#define ZTE_PRODUCT_ME3620_L 0x1433
+#define ZTE_PRODUCT_ME3620_MBIM0x0426
#define BENQ_VENDOR_ID 0x04a5
#define BENQ_PRODUCT_H10 0x4068
@@ -544,6 +548,23 @@ static const struct option_blacklist_info
zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
};
+static const struct option_blacklist_info zte_zm8620_x_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_x_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_l_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+ .reserved = BIT(2) | BIT(3) | BIT(4),
+};
+
+
static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
};
@@ -1592,6 +1613,14 @@ static const struct usb_device_id option_ids[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+ .driver_info = (kernel_ulong_t)_zm8620_x_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+ .driver_info = (kernel_ulong_t)_me3620_x_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+ .driver_info = (kernel_ulong_t)_me3620_l_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+ .driver_info = (kernel_ulong_t)_me3620_mbim_blacklist },
{ USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_H10) },
{ USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },
--
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 v2] mmc: dw_mmc: Add external dma interface support
DesignWare MMC Controller can support two types of DMA
mode: external dma and internal dma. We get a RK312x platform
integrated dw_mmc and ARM pl330 dma controller. This patch add
edmac ops to suuport these platforms. I've tested it on RK312x
platform with edmac mode and RK3288 platform with idmac mode.
Patch is based on next of git://git.linaro.org/people/ulf.hansson/mmc
Signed-off-by: Shawn Lin
---
Changes in v2:
- Fix typo of dev_info msg
- remove unused dmach from declaration of dw_mci_dma_slave
drivers/mmc/host/Kconfig| 24 +-
drivers/mmc/host/dw_mmc-pltfm.c | 4 +
drivers/mmc/host/dw_mmc.c | 169 ++--
include/linux/mmc/dw_mmc.h | 18 -
4 files changed, 205 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 6a0f9c7..2a66b08 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -607,16 +607,36 @@ config MMC_DW
help
This selects support for the Synopsys DesignWare Mobile Storage IP
block, this provides host support for SD and MMC interfaces, in both
- PIO and external DMA modes.
+ PIO, internal DMA mode and external DMA modes.
+
+choice
+ prompt "DesignWare MMC transfer mode"
+ depends on MMC_DW
+
+config MMC_DW_PIO
+ bool "Use PIO transfers only"
+ help
+ Use PIO to transfer data between memory and the hardware.
+ PIO is slower than DMA as it requires CPU instructions to
+ move the data. This has been the traditional default for
+ the DW MCI driver.
config MMC_DW_IDMAC
bool "Internal DMAC interface"
- depends on MMC_DW
help
This selects support for the internal DMAC block within the Synopsys
Designware Mobile Storage IP block. This disables the external DMA
interface.
+config MMC_DW_EDMAC
+ bool "External DMAC interface"
+ help
+ This selects support for the external DMAC block outside the Synopsys
+ Designware Mobile Storage IP block. This disables the internal DMA
+ interface.
+
+endchoice
+
config MMC_DW_PLTFM
tristate "Synopsys Designware MCI Support as platform device"
depends on MMC_DW
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index ec6dbcd..9475b9f 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,6 +59,10 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
host->pdata = pdev->dev.platform_data;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+#ifdef CONFIG_MMC_DW_EDMAC
+ /* Get registers' physical base address */
+ host->phy_regs = (void *)(regs->start);
+#endif
host->regs = devm_ioremap_resource(>dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 40e9d8e..88a8501 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -441,8 +441,9 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host)
mci_writel(host, BMOD, temp);
}
-static void dw_mci_idmac_complete_dma(struct dw_mci *host)
+static void dw_mci_idmac_complete_dma(void *arg)
{
+ struct dw_mci *host = arg;
struct mmc_data *data = host->data;
dev_vdbg(host->dev, "DMA complete\n");
@@ -527,7 +528,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
struct mmc_data *data,
wmb();
}
-static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
+static int dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
{
u32 temp;
@@ -551,6 +552,8 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
unsigned int sg_len)
/* Start it running */
mci_writel(host, PLDMND, 1);
+
+ return 0;
}
static int dw_mci_idmac_init(struct dw_mci *host)
@@ -634,6 +637,144 @@ static const struct dw_mci_dma_ops dw_mci_idmac_ops = {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+#ifdef CONFIG_MMC_DW_EDMAC
+static void dw_mci_edmac_cleanup(struct dw_mci *host)
+{
+ struct mmc_data *data = host->data;
+
+ if (data && (!data->host_cookie))
+ dma_unmap_sg(host->dev, data->sg,
+data->sg_len, dw_mci_get_dma_dir(data));
+}
+
+static void dw_mci_edmac_stop_dma(struct dw_mci *host)
+{
+ dmaengine_terminate_all(host->dms->ch);
+}
+
+static void dw_mci_edmac_complete_dma(void *arg)
+{
+ struct dw_mci *host = arg;
+ struct mmc_data *data = host->data;
+
+ dev_vdbg(host->dev, "DMA complete\n");
+
+ if (data && data->flags & MMC_DATA_READ)
+ /* Invalidate cache after read */
+ dma_sync_sg_for_cpu(mmc_dev(host->cur_slot->mmc), data->sg,
+ data->sg_len, DMA_FROM_DEVICE);
+
+ host->dma_ops->cleanup(host);
+
+ /*
+
[PATCH] usb_gadget: fix spin_lock in pch_udc
When remove module g_serial on quark platform, the following Warning on:
Modules linked in: usb_f_acm u_serial g_serial(-) pch_udc libcomposite configfs
udc_core
ad7298 industrialio_triggered_buffer kfifo_buf tpm_i2c_infineon indus
CPU: 0 PID: 369 Comm: modprobe Not tainted 3.14.29ltsi-WR7.0.0.0_standard #6
Hardware name: Intel Corp. QUARK/CrossHill, BIOS 0x010100F5 01/01/2014
f641df0c f641df0c f641dec8 c15ac7fa f641defc c103084f c16c2356 f641df28
0171 c16b855c 09dd c15b2d6f 09dd c15b2d6f f6bd2000 faae5480
f641df14 c10308a3 0009 f641df0c c16c2356 f641df28 f641df2c
Call Trace:
[] dump_stack+0x16/0x18
[] warn_slowpath_common+0x7f/0xa0
[] ? preempt_count_sub+0x6f/0xc0
[] ? preempt_count_sub+0x6f/0xc0
[] warn_slowpath_fmt+0x33/0x40
[] preempt_count_sub+0x6f/0xc0
[] pch_udc_pcd_pullup+0x32/0xa0 [pch_udc]
[] usb_gadget_remove_driver+0x29/0x60 [udc_core]
[] usb_gadget_unregister_driver+0x59/0x80 [udc_core]
[] usb_composite_unregister+0x10/0x20 [libcomposite]
[] cleanup+0xd/0xf [g_serial]
[] SyS_delete_module+0xf7/0x150
[] ? fput+0xd/0x10
[] ? task_work_run+0x6e/0xa0
[] syscall_call+0x7/0x7
g_serial module on quark is depended on pch_udc module, ttyGSX cann't recieve
data and warning on when remove g_serial.
It was unlocked before the modification of the structure it was protecting,
fix it as "lock -> unlock" to resolve this.
Signed-off-by: Pengyu Ma
---
drivers/usb/gadget/udc/pch_udc.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..2a35dd4 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -620,9 +620,9 @@ static inline void pch_udc_vbus_session(struct pch_udc_dev
*dev,
dev->vbus_session = 1;
} else {
if (dev->driver && dev->driver->disconnect) {
- spin_unlock(>lock);
- dev->driver->disconnect(>gadget);
spin_lock(>lock);
+ dev->driver->disconnect(>gadget);
+ spin_unlock(>lock);
}
pch_udc_set_disconnect(dev);
dev->vbus_session = 0;
@@ -1191,9 +1191,9 @@ static int pch_udc_pcd_pullup(struct usb_gadget *gadget,
int is_on)
pch_udc_reconnect(dev);
} else {
if (dev->driver && dev->driver->disconnect) {
- spin_unlock(>lock);
- dev->driver->disconnect(>gadget);
spin_lock(>lock);
+ dev->driver->disconnect(>gadget);
+ spin_unlock(>lock);
}
pch_udc_set_disconnect(dev);
}
@@ -1488,11 +1488,11 @@ static void complete_req(struct pch_udc_ep *ep, struct
pch_udc_request *req,
req->dma_mapped = 0;
}
ep->halted = 1;
- spin_unlock(>lock);
+ spin_lock(>lock);
if (!ep->in)
pch_udc_ep_clear_rrdy(ep);
usb_gadget_giveback_request(>ep, >req);
- spin_lock(>lock);
+ spin_unlock(>lock);
ep->halted = halted;
}
@@ -2414,7 +2414,7 @@ static void pch_udc_svc_control_out(struct pch_udc_dev
*dev)
dev->gadget.ep0 = >ep[UDC_EP0IN_IDX].ep;
else /* OUT */
dev->gadget.ep0 = >ep;
- spin_unlock(>lock);
+ spin_lock(>lock);
/* If Mass storage Reset */
if ((dev->setup_data.bRequestType == 0x21) &&
(dev->setup_data.bRequest == 0xFF))
@@ -2422,7 +2422,7 @@ static void pch_udc_svc_control_out(struct pch_udc_dev
*dev)
/* call gadget with setup data received */
setup_supported = dev->driver->setup(>gadget,
>setup_data);
- spin_lock(>lock);
+ spin_unlock(>lock);
if (dev->setup_data.bRequestType & USB_DIR_IN) {
ep->td_data->status = (ep->td_data->status &
@@ -2594,9 +2594,9 @@ static void pch_udc_svc_ur_interrupt(struct pch_udc_dev
*dev)
empty_req_queue(ep);
}
if (dev->driver) {
- spin_unlock(>lock);
- usb_gadget_udc_reset(>gadget, dev->driver);
spin_lock(>lock);
+ usb_gadget_udc_reset(>gadget, dev->driver);
+ spin_unlock(>lock);
}
}
@@ -2675,9 +2675,9 @@ static void pch_udc_svc_intf_interrupt(struct pch_udc_dev
*dev)
dev->ep[i].halted = 0;
}
dev->stall = 0;
- spin_unlock(>lock);
- ret = dev->driver->setup(>gadget, >setup_data);
spin_lock(>lock);
+ ret = dev->driver->setup(>gadget, >setup_data);
+ spin_unlock(>lock);
}
/**
@@ -2712,9 +2712,9 @@ static void
[PATCH] 3c59x: Fix resource leaks in vortex_open
When vortex_up is failed, the skb buffers allocated by __netdev_alloc_skb
in vortex_open are not released, which may cause resource leaks.
This bug has been submitted before.
This patch modifies the error handling code to fix it.
Signed-off-by: Jia-Ju Bai
---
drivers/net/ethernet/3com/3c59x.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c
b/drivers/net/ethernet/3com/3c59x.c
index 2d1ce3c..753887d 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -1763,16 +1763,9 @@ vortex_open(struct net_device *dev)
vp->rx_ring[i].addr =
cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data, PKT_BUF_SZ,
PCI_DMA_FROMDEVICE));
}
if (i != RX_RING_SIZE) {
- int j;
pr_emerg("%s: no memory for rx ring\n", dev->name);
- for (j = 0; j < i; j++) {
- if (vp->rx_skbuff[j]) {
- dev_kfree_skb(vp->rx_skbuff[j]);
- vp->rx_skbuff[j] = NULL;
- }
- }
retval = -ENOMEM;
- goto err_free_irq;
+ goto err_free_skb;
}
/* Wrap the ring. */
vp->rx_ring[i-1].next = cpu_to_le32(vp->rx_ring_dma);
@@ -1782,7 +1775,13 @@ vortex_open(struct net_device *dev)
if (!retval)
goto out;
-err_free_irq:
+err_free_skb:
+ for (i = 0; i < RX_RING_SIZE; i++) {
+ if (vp->rx_skbuff[i]) {
+ dev_kfree_skb(vp->rx_skbuff[i]);
+ vp->rx_skbuff[i] = NULL;
+ }
+ }
free_irq(dev->irq, dev);
err:
if (vortex_debug > 1)
--
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 RFC 1/3] x86: Add Intel PT common files
On 2015/08/02 19:02, Thomas Gleixner wrote:
> On Wed, 29 Jul 2015, Takao Indoh wrote:
>> +/*
>> + * Table of Physical Addresses bits
>> + */
>> +enum topa_sz {
>> +TOPA_4K = 0,
>> +TOPA_8K,
>> +TOPA_16K,
>> +TOPA_32K,
>> +TOPA_64K,
>> +TOPA_128K,
>> +TOPA_256K,
>> +TOPA_512K,
>> +TOPA_1MB,
>> +TOPA_2MB,
>> +TOPA_4MB,
>> +TOPA_8MB,
>> +TOPA_16MB,
>> +TOPA_32MB,
>> +TOPA_64MB,
>> +TOPA_128MB,
>> +TOPA_SZ_END,
>> +};
>
> While moving this around, can we pretty please clean that up? That
> enum just pointless. None of the values is ever used and they hardly
> have any value as they are just computable.
Ok, I'll update my patches based on Alex's comments, but before that
I'll clean up intel_pt.h and perf_event_intel_pt.c.
Thanks,
Takao Indoh
>
>> +static inline unsigned int sizes(enum topa_sz tsz)
>> +{
>> +return 1 << (tsz + 12);
>
> 12?? PAGE_SHIFT perhaps?
>
>> +#define TOPA_SHIFT 12
>
> Sigh.
>
>> diff --git a/arch/x86/kernel/cpu/intel_pt_cap.c
>> b/arch/x86/kernel/cpu/intel_pt_cap.c
>> new file mode 100644
>> index 000..a2cfbfc
>> --- /dev/null
>> +++ b/arch/x86/kernel/cpu/intel_pt_cap.c
>> @@ -0,0 +1,69 @@
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>> +#include
>> +#include
>> +
>> +enum cpuid_regs {
>> +CR_EAX = 0,
>> +CR_ECX,
>> +CR_EDX,
>> +CR_EBX
>> +};
>> +
>> +static u32 cpuid_cache[4 * PT_CPUID_LEAVES];
>
> 4 ? Magic constant pulled from thin air?
>
>> +static int pt_cap_initialized;
>> +
>> +#define PT_CAP(_n, _l, _r, _m)
>> \
>> +[PT_CAP_ ## _n] = { .name = __stringify(_n), .leaf = _l,\
>> +.reg = _r, .mask = _m }
>> +
>> +static struct pt_cap_desc {
>> +const char *name;
>> +u32 leaf;
>> +u8 reg;
>> +u32 mask;
>> +} pt_caps[] = {
>> +PT_CAP(max_subleaf, 0, CR_EAX, 0x),
>> +PT_CAP(cr3_filtering, 0, CR_EBX, BIT(0)),
>> +PT_CAP(topa_output, 0, CR_ECX, BIT(0)),
>> +PT_CAP(topa_multiple_entries, 0, CR_ECX, BIT(1)),
>> +PT_CAP(payloads_lip,0, CR_ECX, BIT(31)),
>> +};
>> +
>> +u32 pt_cap_get(enum pt_capabilities cap)
>> +{
>> +struct pt_cap_desc *cd = _caps[cap];
>> +u32 c = cpuid_cache[cd->leaf * 4 + cd->reg];
>
> Ditto
>
>> +unsigned int shift = __ffs(cd->mask);
>> +
>> +return (c & cd->mask) >> shift;
>> +}
>> +
>> +const char *pt_cap_name(enum pt_capabilities cap)
>> +{
>> +return pt_caps[cap].name;
>> +}
>> +
>> +int pt_cap_num(void)
>> +{
>> +return ARRAY_SIZE(pt_caps);
>> +}
>> +
>> +void __init pt_cap_init(void)
>> +{
>> +int i;
>> +
>> +if (pt_cap_initialized)
>> +return;
>> +
>> +for (i = 0; i < PT_CPUID_LEAVES; i++) {
>> +cpuid_count(20, i,
>> +_cache[CR_EAX + i*4],
>
> Once more.
>
> 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] thermal/cpu_cooling: remove local cooling state variable
On 01-08-15, 17:04, Viresh Kumar wrote: > On 31-07-15, 08:30, Radivoje Jovanovic wrote: > > I agree with you that this patch is trivial for the current > > implementation since the notifier, as it is currently, will enforce > > cpu_cooling policy change at every CPUFREQ_ADJUST which would cause > > problems in our current implementation. In our implementation there is > > a cpufreq driver that will also change policies during CPUFREQ_ADJUST, > > once the request comes from the underlying FW so there would be a fight > > who gets there first since cpu_cooling will change the policy in > > CPUFREQ_ADJUST notifier_chain and the driver would do the same thing. Okay, I had a detailed look this morning. cpufreq-notifier is designed this way that policy->max can be updated by drivers.. So, that's fine. Now coming to your problem. So, there are two users: fw and thermal, which can affect policy->max. Now, both of them need to respect the limits set by others and only decrease policy->max from the notifier if it doesn't suit them. I think it should work pretty well, unless you know you have triggered a corner case somewhere, that I am not able to imagine. Please let me know in case I am wrong. -- 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/
[PATCH] fallback to hostname in scripts/package/builddeb
Hi, I happened to build a kernel with "make deb-pkg" on a machine with no network connectivity, but this failed with: [...] INSTALL debian/headertmp/usr/include/asm/ (65 files) hostname: Name or service not known ../scripts/package/Makefile:90: recipe for target 'deb-pkg' failed make[2]: *** [deb-pkg] Error 1 In scripts/package/builddeb it tries to construct an email address (that can be queried in /proc/version later on) but with no network, the "hostname -f" fails. The following patch falls back to just use the shortname if we cannot determine our FQDN. Signed-off-by: Christian Kujau diff --git a/scripts/package/builddeb b/scripts/package/builddeb index 88dbf23..7de1d1c 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -206,7 +206,7 @@ if [ -n "$DEBEMAIL" ]; then elif [ -n "$EMAIL" ]; then email=$EMAIL else - email=$(id -nu)@$(hostname -f) + email=$(id -nu)@$(hostname -f 2>/dev/null || hostname) fi if [ -n "$DEBFULLNAME" ]; then name=$DEBFULLNAME -- BOFH excuse #334: 50% of the manual is in .pdf readme files -- 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 6/7] cpufreq: rename cpufreq_real_policy as cpufreq_user_policy
Its all about caching min/max freq requested by userspace, and
the name 'cpufreq_real_policy' doesn't fit that well. Rename it to
cpufreq_user_policy.
Signed-off-by: Viresh Kumar
---
include/linux/cpufreq.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 54dbbff0a55e..6ff6a4d95eea 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -51,7 +51,7 @@ struct cpufreq_cpuinfo {
unsigned inttransition_latency;
};
-struct cpufreq_real_policy {
+struct cpufreq_user_policy {
unsigned intmin;/* in kHz */
unsigned intmax;/* in kHz */
};
@@ -86,7 +86,7 @@ struct cpufreq_policy {
struct work_struct update; /* if update_policy() needs to be
* called, but you're in IRQ context */
- struct cpufreq_real_policy user_policy;
+ struct cpufreq_user_policy user_policy;
struct cpufreq_frequency_table *freq_table;
struct list_headpolicy_list;
--
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/
[PATCH 4/7] cpufreq: remove redundant 'governor' field from user_policy
Its always same as policy->governor, and there is no need to keep
another copy of it. Remove it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 7 ++-
include/linux/cpufreq.h | 1 -
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 8e71d8e08439..3033952391fe 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -675,7 +675,6 @@ static ssize_t store_scaling_governor(struct cpufreq_policy
*policy,
return ret;
policy->user_policy.policy = policy->policy;
- policy->user_policy.governor = policy->governor;
return count;
}
@@ -1323,10 +1322,9 @@ static int cpufreq_online(unsigned int cpu)
goto out_exit_policy;
}
- if (new_policy) {
+ if (new_policy)
policy->user_policy.policy = policy->policy;
- policy->user_policy.governor = policy->governor;
- }
+
up_write(>rwsem);
kobject_uevent(>kobj, KOBJ_ADD);
@@ -2305,7 +2303,6 @@ int cpufreq_update_policy(unsigned int cpu)
new_policy.min = policy->user_policy.min;
new_policy.max = policy->user_policy.max;
new_policy.policy = policy->user_policy.policy;
- new_policy.governor = policy->user_policy.governor;
/*
* BIOS might change freq behind our back
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index bedcc90c0757..752bf8a5c314 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -55,7 +55,6 @@ struct cpufreq_real_policy {
unsigned intmin;/* in kHz */
unsigned intmax;/* in kHz */
unsigned intpolicy; /* see above */
- struct cpufreq_governor *governor; /* see below */
};
struct cpufreq_policy {
--
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/
[PATCH 5/7] cpufreq: remove redundant 'policy' field from user_policy
Its always same as policy->policy, and there is no need to keep another
copy of it. Remove it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 10 +-
include/linux/cpufreq.h | 1 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3033952391fe..a80bd68bbd74 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -671,11 +671,7 @@ static ssize_t store_scaling_governor(struct
cpufreq_policy *policy,
return -EINVAL;
ret = cpufreq_set_policy(policy, _policy);
- if (ret)
- return ret;
-
- policy->user_policy.policy = policy->policy;
- return count;
+ return ret ? ret : count;
}
/**
@@ -1322,9 +1318,6 @@ static int cpufreq_online(unsigned int cpu)
goto out_exit_policy;
}
- if (new_policy)
- policy->user_policy.policy = policy->policy;
-
up_write(>rwsem);
kobject_uevent(>kobj, KOBJ_ADD);
@@ -2302,7 +2295,6 @@ int cpufreq_update_policy(unsigned int cpu)
memcpy(_policy, policy, sizeof(*policy));
new_policy.min = policy->user_policy.min;
new_policy.max = policy->user_policy.max;
- new_policy.policy = policy->user_policy.policy;
/*
* BIOS might change freq behind our back
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 752bf8a5c314..54dbbff0a55e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -54,7 +54,6 @@ struct cpufreq_cpuinfo {
struct cpufreq_real_policy {
unsigned intmin;/* in kHz */
unsigned intmax;/* in kHz */
- unsigned intpolicy; /* see above */
};
struct cpufreq_policy {
--
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/
[PATCH 7/7] cpufreq: drop !cpufreq_driver check from cpufreq_parse_governor()
Driver is guaranteed to be present on a call to cpufreq_parse_governor()
and there is no need to check for !cpufreq_driver. Drop it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a80bd68bbd74..a05cc75cc45d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -520,9 +520,6 @@ static int cpufreq_parse_governor(char *str_governor,
unsigned int *policy,
{
int err = -EINVAL;
- if (!cpufreq_driver)
- goto out;
-
if (cpufreq_driver->setpolicy) {
if (!strncasecmp(str_governor, "performance",
CPUFREQ_NAME_LEN)) {
*policy = CPUFREQ_POLICY_PERFORMANCE;
@@ -557,7 +554,6 @@ static int cpufreq_parse_governor(char *str_governor,
unsigned int *policy,
mutex_unlock(_governor_mutex);
}
-out:
return err;
}
--
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/
[PATCH 2/7] cpufreq: use memcpy() to copy policy
cpufreq_get_policy() is useful if the pointer to policy isn't available in advance. But if it is available, then there is no need to call cpufreq_get_policy(). Directly use memcpy() to copy the policy. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 293f47b814bf..86d69416821b 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -606,9 +606,7 @@ static ssize_t store_##file_name \ int ret, temp; \ struct cpufreq_policy new_policy; \ \ - ret = cpufreq_get_policy(_policy, policy->cpu); \ - if (ret)\ - return -EINVAL; \ + memcpy(_policy, policy, sizeof(*policy)); \ \ ret = sscanf(buf, "%u", _policy.object);\ if (ret != 1) \ @@ -662,9 +660,7 @@ static ssize_t store_scaling_governor(struct cpufreq_policy *policy, charstr_governor[16]; struct cpufreq_policy new_policy; - ret = cpufreq_get_policy(_policy, policy->cpu); - if (ret) - return ret; + memcpy(_policy, policy, sizeof(*policy)); ret = sscanf(buf, "%15s", str_governor); if (ret != 1) -- 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/
[PATCH 3/7] cpufreq: update user_policy.* on success
'user_policy' caches properties of a policy that are set by userspace. And these must be updated only if cpufreq core was successful in updating them based on request from user space. In store_scaling_governor(), we are updating user_policy.policy and user_policy.governor even if cpufreq_set_policy() failed. That's incorrect. Fix this by updating user_policy.* only if we were successful in updating the properties. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 86d69416821b..8e71d8e08439 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -671,14 +671,12 @@ static ssize_t store_scaling_governor(struct cpufreq_policy *policy, return -EINVAL; ret = cpufreq_set_policy(policy, _policy); + if (ret) + return ret; policy->user_policy.policy = policy->policy; policy->user_policy.governor = policy->governor; - - if (ret) - return ret; - else - return count; + return count; } /** -- 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/
[PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event
What's being done from CPUFREQ_INCOMPATIBLE, can also be done with
CPUFREQ_ADJUST. There is nothing special with CPUFREQ_INCOMPATIBLE
notifier.
Kill CPUFREQ_INCOMPATIBLE and fix its usage sites.
This also updates the numbering of notifier events to remove holes.
Signed-off-by: Viresh Kumar
---
Documentation/cpu-freq/core.txt | 7 ++-
drivers/acpi/processor_perflib.c | 2 +-
drivers/cpufreq/cpufreq.c | 4
drivers/cpufreq/ppc_cbe_cpufreq_pmi.c | 4 ++--
drivers/video/fbdev/pxafb.c | 1 -
drivers/video/fbdev/sa1100fb.c| 1 -
include/linux/cpufreq.h | 9 -
7 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index 70933eadc308..ba78e7c2a069 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -55,16 +55,13 @@ transition notifiers.
These are notified when a new policy is intended to be set. Each
-CPUFreq policy notifier is called three times for a policy transition:
+CPUFreq policy notifier is called twice for a policy transition:
1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
they see a need for this - may it be thermal considerations or
hardware limitations.
-2.) During CPUFREQ_INCOMPATIBLE only changes may be done in order to avoid
-hardware failure.
-
-3.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
+2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
- if two hardware drivers failed to agree on a new policy before this
stage, the incompatible hardware shall be shut down, and the user
informed of this.
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 47af702bb6a2..bb01dea39fdc 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -83,7 +83,7 @@ static int acpi_processor_ppc_notifier(struct notifier_block
*nb,
if (ignore_ppc)
return 0;
- if (event != CPUFREQ_INCOMPATIBLE)
+ if (event != CPUFREQ_ADJUST)
return 0;
mutex_lock(_mutex);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 76a26609d96b..293f47b814bf 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2206,10 +2206,6 @@ static int cpufreq_set_policy(struct cpufreq_policy
*policy,
blocking_notifier_call_chain(_policy_notifier_list,
CPUFREQ_ADJUST, new_policy);
- /* adjust if necessary - hardware incompatibility*/
- blocking_notifier_call_chain(_policy_notifier_list,
- CPUFREQ_INCOMPATIBLE, new_policy);
-
/*
* verify the cpu speed can be set within this limit, which might be
* different to the first one
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
index d29e8da396a0..7969f7690498 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq_pmi.c
@@ -97,8 +97,8 @@ static int pmi_notifier(struct notifier_block *nb,
struct cpufreq_frequency_table *cbe_freqs;
u8 node;
- /* Should this really be called for CPUFREQ_ADJUST, CPUFREQ_INCOMPATIBLE
-* and CPUFREQ_NOTIFY policy events?)
+ /* Should this really be called for CPUFREQ_ADJUST and CPUFREQ_NOTIFY
+* policy events?)
*/
if (event == CPUFREQ_START)
return 0;
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 7245611ec963..94813af97f09 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -1668,7 +1668,6 @@ pxafb_freq_policy(struct notifier_block *nb, unsigned
long val, void *data)
switch (val) {
case CPUFREQ_ADJUST:
- case CPUFREQ_INCOMPATIBLE:
pr_debug("min dma period: %d ps, "
"new clock %d kHz\n", pxafb_display_dma_period(var),
policy->max);
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index 89dd7e02197f..dcf774c15889 100644
--- a/drivers/video/fbdev/sa1100fb.c
+++ b/drivers/video/fbdev/sa1100fb.c
@@ -1042,7 +1042,6 @@ sa1100fb_freq_policy(struct notifier_block *nb, unsigned
long val,
switch (val) {
case CPUFREQ_ADJUST:
- case CPUFREQ_INCOMPATIBLE:
dev_dbg(fbi->dev, "min dma period: %d ps, "
"new clock %d kHz\n", sa1100fb_min_dma_period(fbi),
policy->max);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index bde1e567b3a9..bedcc90c0757 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -369,11 +369,10 @@ static inline void cpufreq_resume(void) {}
/* Policy Notifiers */
#define CPUFREQ_ADJUST (0)
-#define CPUFREQ_INCOMPATIBLE (1)
-#define
Re: linux: sata_nv: adma support
On Sun, Aug 2, 2015 at 3:08 AM, Pali Rohár wrote:
> On Sunday 02 August 2015 03:45:32 Robert Hancock wrote:
>> On Sat, Aug 1, 2015 at 2:09 PM, Pali Rohár
>> wrote:
>> > On Thursday 25 December 2014 07:22:13 Robert Hancock wrote:
>> >> On Tue, Dec 23, 2014 at 1:51 PM, Pali Rohár
>> >>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I have nvidia nforce4 motherboard with nvidia sata controller:
>> >> >
>> >> > 00:07.0 IDE interface [0101]: NVIDIA Corporation CK804 Serial
>> >> > ATA Controller [10de:0054] (rev f3)
>> >> > 00:08.0 IDE interface [0101]: NVIDIA Corporation CK804 Serial
>> >> > ATA Controller [10de:0055] (rev f3)
>> >> >
>> >> > I manually enabled adma mode (which is disabled by default) by
>> >> > adding sata_nv.adma=1 to grub cmdline. In git history I found
>> >> > that enabling adma mode includes NCQ support and reduced CPU
>> >> > overhead. It looks like adma mode is working, but at every boot
>> >> > I see one same error message in dmesg:
>> >> >
>> >> > [ 16.823514] ata1.00: exception Emask 0x1 SAct 0x0 SErr 0x0
>> >> > action 0x0
>> >> > [ 16.823520] ata1.00: CPB resp_flags 0x11: , CMD error
>> >> > [ 16.823524] ata1.00: failed command: SET FEATURES
>> >> > [ 16.823530] ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40
>> >> > tag 16
>> >> > [ 16.823530] res 51/04:fe:00:00:00/00:00:00:00:00/40
>> >> > Emask 0x1 (device error)
>> >> > [ 16.823533] ata1.00: status: { DRDY ERR }
>> >> > [ 16.823535] ata1.00: error: { ABRT }
>> >> >
>> >> > When adma is disabled then this error message is not generated.
>> >>
>> >> It looks like something is trying to issue a command to disable
>> >> APM power management on the drive, and the command fails (likely
>> >> because it doesn't support that command). I'm not sure where that
>> >> would be coming from - I'm pretty sure the kernel doesn't issue
>> >> that command itself. Something that's part of your distro
>> >> perhaps?
>> >>
>> >> I don't know why it would only be failing in ADMA mode either,
>> >> though depending on where the command is coming from, maybe it's
>> >> not being issued otherwise for some reason?
>> >>
>> >> > What does that error message means? It is critical? What is that
>> >> > command SET FEATURES doing? Are there any problems with adma
>> >> > mode on nforce4 motherboards? Because I did not see any
>> >> > problems (except that one error message).
>> >> >
>> >> > --
>> >> > Pali Rohár
>> >> > pali.ro...@gmail.com
>> >
>> > Hello,
>> >
>> > now after long time I did more investigation and that error is
>> > reported for every connected HDD. I identified that it comes from
>> > udev script
>> >
>> > /lib/udev/rules.d/85-hdparm.rules
>> >
>> > which just call script /lib/udev/hdparm for every one connected
>> > HDD.
>> >
>> > Script /lib/udev/hdparm just call:
>> > /sbin/hdparm -B254 $DRIVE
>> >
>> > And that -B254 cause above error message in dmesg log. Output from
>> >
>> > hdparm is:
>> > /dev/sda:
>> > setting Advanced Power Management level to 0xfe (254)
>> > APM_level = not supported
>> >
>> > Any idea why in ADMA mode it cause above error (APM unsupported)
>> > and in non ADMA mode it is working fine? Maybe APM ATA commands
>> > should not be sent via ADMA?
>> >
>> > Here is another output:
>> > $ sudo hdparm -I /dev/sda | grep -i power
>> >
>> > *Power Management feature set
>> >
>> > Power-Up In Standby feature set
>> >
>> > *SET_FEATURES required to spinup after power up
>> > *Host-initiated interface power management
>>
>> The "set features" command is a non-data command so based on our
>> current knowledge, it should work in ADMA mode. However, these NVIDIA
>> SATAs are black boxes, and rather buggy ones at that, so it's
>> possible there's an unknown issue there.
>>
>
> Maybe I should note that hdparm -I did not generated any error message.
> I post is here because it show "Power Management feature set" is
> supported by HDD. This indicate that HDD supports -B (APM) command,
> right?
As far as I know, yes.
>
>> The easiest way to test that would be to take out the condition check
>> for qc->tf.protocol == ATA_PROT_NODATA in nv_adma_use_reg_mode in
>> drivers/ata/sata_nv.c. That would force it to disable ADMA for all
>> non-data commands.
>>
>
> Ok, as now I have just SSH access to that machine, I will do kernel
> patching later (when I have physical access to it).
>
>> I really don't know why Ubuntu is disabling APM on all drives on
>> bootup however. Especially for laptops, that seems like a silly thing
>> to do explicitly. Sounds like one of the silly things Ubuntu is known
>> to do without consulting people.
>
> Looks like this comes from upstream udev/systemd project :-( Anyway, for
> laptops on battery ubuntu has another set of scripts which turn on APM
> (based on connected/disconnected AC adapter).
There's no such scripts in Fedora, so either they removed it, or it's
something that either Debian or Ubuntu has
[GIT PULL] Thermal-SoC management updates for v4.2-rc6
Hello Rui, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes to receive Thermal-SoC Management updates for v4.2-rc6 with top-most 3c19d237dd8148926e49259e495ee411f09c: thermal: exynos: Remove unused code related to platform_data on probe() (2015-08-02 19:36:57 -0700) on top of commit 74d33293e467df61de1b1d8b2fbe29e550dec33b: Linux 4.2-rc5 (2015-08-02 18:34:55 -0700) Specifics: - Minor fix on thermal core, while unbinding (need to remove weight_attr) - Change a couple of tracing on power allocator governor - Driver fixes on: Exynos BR, Eduardo Valentin Chanwoo Choi (2): thermal: exynos: Add the dependency of CONFIG_THERMAL_OF instead of CONFIG_OF thermal: exynos: Remove unused code related to platform_data on probe() Javi Merino (1): thermal: power_allocator: trace the real requested power Krzysztof Kozlowski (1): thermal: exynos: Disable the regulator on probe failure Viresh Kumar (1): thermal: remove dangling 'weight_attr' device file drivers/thermal/power_allocator.c| 26 -- drivers/thermal/samsung/Kconfig | 2 +- drivers/thermal/samsung/exynos_tmu.c | 5 ++--- drivers/thermal/thermal_core.c | 1 + 4 files changed, 20 insertions(+), 14 deletions(-) signature.asc Description: Digital signature
[PULL] modules fix
The following changes since commit d61be4b3f2684b6d76ef8c1d28ecdeb9bb20fa8f: Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2015-07-28 11:26:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git tags/fixes-for-linus for you to fetch changes up to fe0d34d242fa1e0dec059e774d146a705420bc9a: module: weaken locking assertion for oops path. (2015-07-29 06:13:22 +0930) Single overzealous locking assertion fix. Cheers, Rusty. Rusty Russell (1): module: weaken locking assertion for oops path. kernel/module.c | 8 ++-- 1 file changed, 6 insertions(+), 2 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 2/7] x86/lguest: Do not setup unused irq vectors
Thomas Gleixner writes:
> No point in assigning the interrupt vectors if there is no interrupt
> chip installed. Move it to lguest_setup_irq().
>
> Signed-off-by: Thomas Gleixner
> Cc: Rusty Russell
> ---
> arch/x86/lguest/boot.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> Index: tip/arch/x86/lguest/boot.c
> ===
> --- tip.orig/arch/x86/lguest/boot.c
> +++ tip/arch/x86/lguest/boot.c
> @@ -855,17 +855,13 @@ static void lguest_disable_irq(struct pc
>
> /*
> * This sets up the Interrupt Descriptor Table (IDT) entry for each hardware
> - * interrupt (except 128, which is used for system calls), and then tells the
> - * Linux infrastructure that each interrupt is controlled by our level-based
> - * lguest interrupt controller.
> + * interrupt (except 128, which is used for system calls).
> */
> static void __init lguest_init_IRQ(void)
> {
> unsigned int i;
>
> for (i = FIRST_EXTERNAL_VECTOR; i < FIRST_SYSTEM_VECTOR; i++) {
> - /* Some systems map "vectors" to interrupts weirdly. Not us! */
> - __this_cpu_write(vector_irq[i], i - FIRST_EXTERNAL_VECTOR);
> if (i != IA32_SYSCALL_VECTOR)
> set_intr_gate(i, irq_entries_start +
> 8 * (i - FIRST_EXTERNAL_VECTOR));
> @@ -893,8 +889,15 @@ int lguest_setup_irq(unsigned int irq)
> if (err < 0 && err != -EEXIST)
> return err;
>
> + /*
> + * Tell the Linux infrastructure that the interrupt is
> + * controlled by our level-based lguest interrupt controller.
> + */
> irq_set_chip_and_handler_name(irq, _irq_controller,
> handle_level_irq, "level");
> +
> + /* Some systems map "vectors" to interrupts weirdly. Not us! */
> + __this_cpu_write(vector_irq[FIRST_EXTERNAL_VECTOR + irq, irq);
Missing ].
Then it doesn't work:
[3.832028] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.832028] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.832028] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.839983] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.840026] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.840026] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.840026] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.848349] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.848349] do_IRQ: 0.33 No irq handler for vector (irq -1)
[3.848349] do_IRQ: 0.33 No irq handler for vector (irq -1)
[4.056027] brd: module loaded
[4.156025] loop: module loaded
[ 17.712169] do_IRQ: 4 callbacks suppressed
[ 17.712169] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.720462] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.720462] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.729129] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.729129] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.736523] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.736523] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.744288] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.744288] do_IRQ: 0.33 No irq handler for vector (irq -1)
[ 17.751889] do_IRQ: 0.33 No irq handler for vector (irq -1)
You broke interrupts :(
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] mtd: pxa3xx_nand: rework the timing setup
On 20 July 2015 at 16:49, Robert Jarzmik wrote: > Ezequiel Garcia writes: > >> Here you go: >> >> http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/pxa3xx-nand-timing-rework-v2 > > Okay, I've tested this on cm-x300. The result is not bright : > nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc > nand: Samsung NAND 512MiB 3,3V 8-bit > nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > pxa3xx-nand pxa3xx-nand: ECC strength 1, ECC step size 512 > Scanning device for bad blocks > random: nonblocking pool is initialized > Bad eraseblock 1037 at 0x081a > Creating 6 MTD partitions on "pxa3xx_nand-0": > 0x-0x0004 : "OBM" > 0x0004-0x0008 : "U-Boot" > 0x0008-0x000c : "Environment" > 0x000c-0x0020 : "reserved" > 0x0020-0x0060 : "kernel" > 0x0060-0x2000 : "fs" > > The bad black is not bad normally. > And then : > # dd if=/dev/mtd0 of=toto count=1 > pxa3xx-nand pxa3xx-nand: Wait time out!!! > 1+0 records in > 1+0 records out > # ls -l toto > -rw-r--r--1 root root 512 Jan 1 00:02 toto > # hexdump-C toto > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > || > * > 0200 > > That's not possible, as it should have dumped the OBMI. > > And yet, I hesitate to incriminate this patchset, I will try without it. It > wont > be very fast, as my USB to serial converter just broke, and my order will > take a > couple of days to complete. > Just tested linux-next (hence *without* the patchset) and I see the same "Wait time out". In other words, pxa3xx-nand is broken on PXA :/ Interestingly, the culprit doesn't seem to be in pxa3xx-nand itself. Reverting the recent commits on pxa3xx-nand doesn't help. ce914e6 mtd: nand: pxa3xx: fix build on ARM64 afca11e mtd: nand: pxa3xx: Switch FIFO draining to jiffies-based timeout e5860c1 mtd: pxa3xx_nand: cleanup wait_for_completion handling 7c2f717 mtd: pxa3xx_nand: initialiaze pxa3xx_flash_ids to 0 ed446cc Merge MTD updates into -next e423c90 mtd: pxa3xx_nand: fix driver when num_cs is 0 2454225 mtd: pxa3xx-nand: handle PIO in threaded interrupt 8dad038 mtd: nand: pxa3xx: Fix PIO FIFO draining b7e46062 mtd: pxa3xx_nand: make the driver work on big-endian systems 5b3e507 mtd: nand: pxa3xx: Use ECC strength and step size devicetree binding eee0166 mtd: nand: pxa3xx: Clean pxa_ecc_init() error handling 17754ad mtd: nand: pxa3xx: Make of_device_id array const e634ce5 mtd: nand: pxa3xx: Print actual ECC strength in error message Yet v3.18 succeeds to pass a few NAND blocks on nandtest. Robert: any ideas? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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] KVM: x86: set TMR when the interrupt is accepted
Paolo Bonzini wrote on 2015-07-31: > > > On 31/07/2015 04:49, Steve Rutherford wrote: >> Oh... Yeah. That's a damn good point, given that the interrupt can be >> injected from another thread while one is in that guest vcpu. >> >> Easiest time to update the TMR should be on guest entry through >> vcpu_scan_ioapic, as before. >> >> The best way to go is probably to ditch the new per vcpu EOI exit >> bitmap, and just update/use the TMR. There's no reason to duplicate >> that data in the representation of the apic (I suspect that the >> duplication was inspired by my mistaken notion of the TMR). The >> IOAPIC exit check can use the TMR instead. >> >> Based upon my reading of the SDM, the only reason that the eoi exit >> bitmaps are not the exact same as the TMR is that it is possible to >> have virtual-interrupt delivery enabled /without/ an apic access page >> (Note: V-ID => EOI exit bitmap enabled). >> >> Yang, do you happen to know if that is the case? >> >> [Note: Just looked back at the old code for updating the EOI exit >> bitmaps, which for some reason was configured to trigger EOI exits >> for all IOAPIC interrupts, not just level-triggered IOAPIC >> interrupts. Which is weird, and I believe totally unecessary.] > > The RTC interrupt needs to trigger an EOI exit with the in-kernel > IOAPIC, in order to detect coalesced interrupts. This is necessary to > avoid severe time drift in Windows guest. Correct! EOI exit bitmap is not absolutely same with TMR. Some interrupts (especially timer interrupt) which is edge trigger but need a notification when it got injected into guest. > > Paolo Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] kthread: Export kthread functions
yalin wang writes: >> On Aug 1, 2015, at 21:32, Neil Horman wrote: >>> strange, this is my test result: >>> >>> size built-in.o* >>> text data bss dec hex filename >>> 743937 50786 56008 850731 cfb2b built-in.o // with the patch >>> 744069 50786 56008 850863 cfbaf built-in.o_old // with out the >>> patch >>> >> So you're willing to expose the internals of kthread_park in exchange for the >> hope of saving 132 bytes of text. >> >> Thats just dumb. I agree with tglx, this shouldn't change. >> >> Neil > not just size, mainly for performance, > without inline: > > ffcd26b0: 97fff4aa bl ffccf958 > ffcd26b4: 53001c00uxtbw0, w0 > > if kthread_should_park() inline: > ffcd1a44: f85c8020 ldr x0, [x1,#-56] // kthread_should_park > line > ffcd1a48: 36100300 tbz w0, #2, ffcd1aa8 > // kthread_should_park line > > still use 2 instructions, but don’t need a function call, > maybe can do more optimisation by gcc sometimes . > Anyway, this is just a suggest, > it is up to you apply it or not. :) kthread_park() isn't exactly a performance critical function call. Saving two instructions does not outway the cost of exposing the internals of the kthread API. Jes -- 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] e100: Release skb when DMA mapping is failed in e100_xmit_prepare
When pci_dma_mapping_error in e100_xmit_prepare is failed, the skb buffer
allocated by netdev_alloc_skb_ip_align in e100_rx_alloc_skb is not
released, which causes a possible resource leak.
This patch adds error handling code to fix it.
Signed-off-by: Jia-Ju Bai
---
drivers/net/ethernet/intel/e100.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e100.c
b/drivers/net/ethernet/intel/e100.c
index d2657a4..cc90616 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -1770,8 +1770,11 @@ static int e100_xmit_prepare(struct nic *nic, struct cb
*cb,
dma_addr = pci_map_single(nic->pdev,
skb->data, skb->len, PCI_DMA_TODEVICE);
/* If we can't map the skb, have the upper layer try later */
- if (pci_dma_mapping_error(nic->pdev, dma_addr))
+ if (pci_dma_mapping_error(nic->pdev, dma_addr)) {
+ dev_kfree_skb_any(skb);
+ skb = NULL;
return -ENOMEM;
+ }
/*
* Use the last 4 bytes of the SKB payload packet as the CRC, used for
--
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 V2] iio: declare struct to fix warning
When compile iio related driver the following warning shown:
include/linux/iio/trigger.h:35:34: warning: 'struct iio_trigger'
declared inside parameter list
int (*set_trigger_state)(struct iio_trigger *trig, bool state);
include/linux/iio/trigger.h:38:18: warning: 'struct iio_dev'
declared inside parameter list
struct iio_dev *indio_dev);
'struct iio_dev' and 'struct iio_trigger' was used before declaration,
forward declaration for these structs to fix warning.
Signed-off-by: Pengyu Ma
---
include/linux/iio/trigger.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/iio/trigger.h b/include/linux/iio/trigger.h
index fa76c79..974cf73 100644
--- a/include/linux/iio/trigger.h
+++ b/include/linux/iio/trigger.h
@@ -18,6 +18,10 @@ struct iio_subirq {
bool enabled;
};
+/* forward declaration */
+struct iio_dev;
+struct iio_trigger;
+
/**
* struct iio_trigger_ops - operations structure for an iio_trigger.
* @owner: used to monitor usage count of the trigger.
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf eBPF patch ordering. was: Re: perf test LLVM was: Re: [GIT PULL 00/39] perf tools: filtering events using eBPF programs
On 2015/8/1 4:31, Arnaldo Carvalho de Melo wrote: Em Fri, Jul 31, 2015 at 12:35:22PM -0300, Arnaldo Carvalho de Melo escreveu: But point here is, when I see "enable passing bpf object file to --event" I apply the patch and expect to be able to go straight away and do: perf record -e foo.o sleep 1 And get some informative message as to hey, yes, I managed to do what you asked or something is wrong, but I get: [root@felicio ~]# perf record --event foo.o sleep event syntax error: 'foo.o' \___ parser error Run 'perf list' for a list of valid events usage: perf record [] [] or: perf record [] -- [] -e, --eventevent selector. use 'perf list' to list available events [root@felicio ~]# So, is it enabled or is it not? Doesn't look like. I.e. I think the best thing is to only expose this when it can be used. Till that time, we can I just tried gdb'ing this with a breakpoint on parse_events_load_bpf(), but when I run: (gdb) b parse_events_load_bpf Breakpoint 1 at 0x48b11b: file util/parse-events.c, line 488. (gdb) run record -e foo.o sleep 1 Starting program: /root/bin/perf record -e foo.o sleep 1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". event syntax error: 'foo.o' \___ parser error Run 'perf list' for a list of valid events Somehow it is not calling what the changeset says it would call when passing "-e foo.o", investigating... Have you tried /root/bin/perf record -e ./foo.o sleep 1 The key is './'. I have reproduced the problem. Haven't noticed that because I always use './' name. Will look into it. Thank you, and glad to see you start looking at this cset. - Arnaldo -- 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: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi, On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby wrote: > Hi Timo, > > On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson > wrote: >> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 >> boards >> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise >> the >> voltage for the lowest operating point to 1.0V so all boards can actually use >> it. > > Surely it wouldn't be added here if some could supply 0.9v. On the side, the original OPPs in the FEX files are actually frequency/voltage ranges, and not just points. Mainlines OPPv2 will support these, along with turbo frequencies. Furthermore, the FEX files also have fields that limit the minimum and maximum frequencies. > Is the code that uses this smart enough to sensibly switch between two > operating points with the same frequency and different voltages? If > so, maybe just add a 144MHz @ 1.0v operating point? You could try. Though I really don't see much to gain here. > (Alternatively, would it make sense to modify the code that uses this > to use frequencies with voltages specified that are lower than can be > supplied with the lowest voltage it can?) I think that's a bit harder to get accepted. ChenYu -- 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] KVM: x86: set TMR when the interrupt is accepted
Paolo Bonzini wrote on 2015-07-31: > > > On 31/07/2015 01:26, Zhang, Yang Z wrote: Do not compute TMR in advance. Instead, set the TMR just before the interrupt is accepted into the IRR. This limits the coupling between IOAPIC and LAPIC. >> >> Uh.., it back to original way which is wrong. You cannot modify the >> apic page(here is the TMR reg) directly when the corresponding VMCS >> may be used at same time. > > Where is this documented? The TMR is not part of the set of virtualized > APIC registers (TPR, PPR, EOI, ISR, IRR, ICR+ICR2; SDM 29.1.1). > > Only virtualized APIC register reads use the virtual TMR registers (SDM > 29.4.2 or 29.5), but these just read data from the corresponding field > in the virtual APIC page. It's not only for virtual apic page. All data structures that is used by VMCS(either directly inside in VMCS or referenced by pointer in a VMCS) need follow this rule: 24.11.4 Software Access to Related Structures In addition to data in the VMCS region itself, VMX non-root operation can be controlled by data structures that are referenced by pointers in a VMCS (for example, the I/O bitmaps). While the pointers to these data structures are parts of the VMCS, the data structures themselves are not. They are not accessible using VMREAD and VMWRITE but by ordinary memory writes. Software should ensure that each such data structure is modified only when no logical processor with a current VMCS that references it is in VMX non-root operation. Doing otherwise may lead to unpredictable behavior (including behaviors identified in Section 24.11.1). > > Paolo Best regards, Yang -- 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: [GIT PULL] Samsung Thermal FIXES for v4.2-rc1
On Mon, Jul 06, 2015 at 05:26:57PM +0200, Lukasz Majewski wrote: > Dear Eduardo, > > Please find my pull request for Samsung Thermal fixes (v4.2-rc1): > > The following changes since commit > efa86858e1d8970411a140fa1e0c4dd18a8f2a89: > > thermal: armada: Update Armada 380 thermal sensor coefficients > (2015-05-09 01:00:31 -0700) > > are available in the git repository at: > > g...@github.com:lmajewski/linux-samsung-thermal.git fixes > > for you to fetch changes up to e4dc28277205cfb02f8dd96fe694a1bcc2dc41b1: > > thermal: exynos: Remove unused code related to platform_data on > probe() (2015-07-06 17:09:15 +0200) I have rebased your work on top of my fixes branch. But everthing applied fine. Thanks a lot Lukasz. > > > Chanwoo Choi (2): > thermal: exynos: Add the dependency of CONFIG_THERMAL_OF instead > of CONFIG_OF thermal: exynos: Remove unused code related to > platform_data on probe() > > Krzysztof Kozlowski (1): > thermal: exynos: Disable the regulator on probe failure > > drivers/thermal/samsung/Kconfig | 2 +- > drivers/thermal/samsung/exynos_tmu.c | 5 ++--- > 2 files changed, 3 insertions(+), 4 deletions(-) > > > Test HW: Exynos4412 - Trats2 board. > Build GCC: 4.9.2 > SHA1: e4dc28277205cfb02f8dd96fe694a1bcc2dc41b1 > [I've rebased on top of kernel_linux-soc-thermal/fixes branch at your > repository] > > -- > Best regards, > > Lukasz Majewski > > Samsung R Institute Poland (SRPOL) | Linux Platform Group signature.asc Description: Digital signature
Re: [PATCH v2] kthread: Export kthread functions
> On Aug 1, 2015, at 21:32, Neil Horman wrote: > > On Sat, Aug 01, 2015 at 03:12:42PM +0800, yalin wang wrote: >> >>> 在 2015年7月31日，22:14，Thomas Gleixner 写道： >>> >>> >>> On Fri, 31 Jul 2015, Thomas Gleixner wrote: >>> On Fri, 31 Jul 2015, yalin wang wrote: > it is optimised to 2 instructions , > > this is my patch, hope can be merged : We are not exposing the internals of kthread management. Period. >>> >>> And your 'optimization' is completely bogus: >>> >>> Before your modification: >>> >>> size kernel/built-in.o >>> >>> text data bss dec hex filename >>> 1091514 141498 341928 1574940 18081c ../build/kernel/built-in.o >>> >>> After: >>> >>> text data bss dec hex filename >>> 1091664 141498 341928 1575090 1808b2 ../build/kernel/built-in.o >>> >>> That's an increase of text size by 150 byte. Interesting optimization. >>> >>> Thanks, >>> >>> tglx >>> >>> >> strange, this is my test result: >> >> size built-in.o* >> text data bss dec hex filename >> 743937 50786 56008 850731 cfb2b built-in.o// with the >> patch >> 744069 50786 56008 850863 cfbaf built-in.o_old // with out the >> patch >> > So you're willing to expose the internals of kthread_park in exchange for the > hope of saving 132 bytes of text. > > Thats just dumb. I agree with tglx, this shouldn't change. > > Neil not just size, mainly for performance, without inline: ffcd26b0: 97fff4aabl ffccf958 ffcd26b4: 53001c00uxtbw0, w0 if kthread_should_park() inline: ffcd1a44: f85c8020ldr x0, [x1,#-56] // kthread_should_park line ffcd1a48: 36100300tbz w0, #2, ffcd1aa8 // kthread_should_park line still use 2 instructions, but don’t need a function call, maybe can do more optimisation by gcc sometimes . Anyway, this is just a suggest, it is up to you apply it or not. :) 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] e100: Add a check after pci_pool_create to avoid null pointer dereference
The driver lacks the check of nic->cbs_pool after pci_pool_create
in e100_probe. When this function is failed, a null pointer dereference
occurs when pci_pool_alloc uses nic->cbs_pool in e100_alloc_cbs.
This patch adds a check and related error handling code to fix it.
Signed-off-by: Jia-Ju Bai
---
drivers/net/ethernet/intel/e100.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/e100.c
b/drivers/net/ethernet/intel/e100.c
index d2657a4..767c161 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -2967,6 +2967,11 @@ static int e100_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
nic->params.cbs.max * sizeof(struct cb),
sizeof(u32),
0);
+ if (!nic->cbs_pool) {
+ netif_err(nic, probe, nic->netdev, "Cannot create DMA pool,
aborting\n");
+ err = -ENOMEM;
+ goto err_out_pool;
+ }
netif_info(nic, probe, nic->netdev,
"addr 0x%llx, irq %d, MAC addr %pM\n",
(unsigned long long)pci_resource_start(pdev, use_io ? 1 : 0),
@@ -2974,6 +2979,8 @@ static int e100_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return 0;
+err_out_pool:
+ unregister_netdev(netdev);
err_out_free:
e100_free(nic);
err_out_iounmap:
--
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 3.10 ~ 3.14] efi: fix the efi 32bit boot failed problem
On 07/31/2015 08:05 PM, Matt Fleming wrote: On Fri, 31 Jul, at 09:22:33AM, fupan wrote: Hi, Matt Will you take care of this patch or I send a V2? Could you please send a V2 with the changes to the commit message that I suggested previously? Thanks! NP! Thanks! Fupan -- 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 drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_atomic_helper.c
between commit:
27667f4744fc ("i915: temporary fix for DP MST docking station NULL pointer
dereference")
from Linus' tree and commit:
fc596660dd4e ("drm/atomic: add connectors_changed to separate it from
mode_changed, v2")
from the drm-misc 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 drivers/gpu/drm/drm_atomic_helper.c
index 90065c226fe5,0b475fae067d..
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@@ -230,12 -230,10 +230,12 @@@ update_connector_routing(struct drm_ato
}
connector_state->best_encoder = new_encoder;
- idx = drm_crtc_index(connector_state->crtc);
+ if (connector_state->crtc) {
+ idx = drm_crtc_index(connector_state->crtc);
- crtc_state = state->crtc_states[idx];
- crtc_state->connectors_changed = true;
+ crtc_state = state->crtc_states[idx];
- crtc_state->mode_changed = true;
++ crtc_state->connectors_changed = true;
+ }
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
[CRTC:%d]\n",
connector->base.id,
--
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 4.2-rc5
We're getting up there to the later rc's, but it's looking like 4.2 might be one of the releases needing more than the usual seven rc releases - things aren't calming down like I would wish, and we've still had some fairly annoying issues pop up. For example, there was a core VFS fix merged just yesterday - the bug itself was old, but some changes in this merge window ended up triggering it much more easily. There's a pending i915 MST DP regression that is papered around for now, but that still needs work, and we had some fairly subtle fallout from the low-level x86 cleanups and NMI. There's also a pending question about some of the VM changes. None of this is particularly disastrous or nasty, and the issues are hard to hit and fairly small details, so it's not like I'm particularly worried. But it's just more than I wish was going on at this stage of the release. Maybe in two weeks when rc7 rolls around, I will be happier and feel like things are going smoothly and I'm getting comfy with making the final 4.2, but right now I feel like I really want things to calm down and these issues not pop up. Anyway, apart from that slight unease, things are fairly normal. Not a lot of arch noise this time(apart from the aforementioned NMI fallout on x86) - so just over three quarters of the changes are drivers, with drm, infiniband, networking and scsi leading the charge. The rest is mostly filesystem and networking code. The shortlog is appended, it gives a reasonable overview of the details. Please do keep testing things. And know that if you send me a pull request that I deem questionable, I might not react politely. We really need to calm things down (not that this rc5 is all _that_ big), Linus --- Al Viro (1): link_path_walk(): be careful when failing with ENOTDIR Alban Bedel (1): DEVICETREE: Misc fix for the AR7100 SPI controller binding Alex Deucher (4): drm/radeon: rework audio detect (v4) drm/radeon: rework audio modeset to handle non-audio hdmi features drm/radeon/combios: add some validation of lvds values drm/amdgpu: clean up init sequence for failures Alex Gartrell (2): ipvs: fix ipv6 route unreach panic ipvs: skb_orphan in case of forwarding Alex Williamson (1): vfio: Fix lockdep issue Alexander Drozdov (1): packet: tpacket_snd(): fix signed/unsigned comparison Alexander Duyck (1): fib_trie: Drop unnecessary calls to leaf_pull_suffix Alexandre Courbot (6): drm/nouveau/platform: fix compile error if !CONFIG_IOMMU drm/nouveau/ibus/gk20a: increase SM wait timeout drm/nouveau/fifo/gk104: kick channels when deactivating them drm/nouveau/gr/gf100: wait on bottom half of FE's pipeline drm/nouveau/gr/gf100: wait for GR idle after GO_IDLE bundle drm/nouveau/nouveau/ttm: fix tiled system memory with Maxwell Alexei Potashnik (6): qla2xxx: delay plogi/prli ack until existing sessions are deleted qla2xxx: Abort stale cmds on qla_tgt_wq when plogi arrives qla2xxx: added sess generations to detect RSCN update races qla2xxx: disable scsi_transport_fc registration in target mode qla2xxx: drop cmds/tmrs arrived while session is being deleted qla2xxx: terminate exchange when command is aborted by LIO Alexey Kardashevskiy (1): powerpc/powernv/ioda2: Fix calculation for memory allocated for TCE table Alistair Popple (1): powerpc/eeh-powernv: Fix unbalanced IRQ warning Anand Jain (1): btrfs: its btrfs_err() instead of btrfs_error() Andrew Lunn (1): net: fec: Ensure clocks are enabled while using mdio bus Andy Grover (2): target: Indicate success if writing 0 to pi_prot_type target: Do not return 0 from aptpl and alua configfs store functions Andy Lutomirski (2): x86/xen: Probe target addresses in set_aliased_prot() before the hypercall x86/ldt: Make modify_ldt synchronous Andy Shevchenko (7): avr32: handle NULL as a valid clock object net/macb: improve big endian CPU support net/macb: check if macb_config present net/macb: use dev_*() when netdev is not yet registered net/macb: suppress compiler warnings net/macb: replace macb_count_tx_descriptors() by DIV_ROUND_UP() net/macb: convert to kernel doc Archit Taneja (1): drm/msm: mdp4: Fix drm_framebuffer dereference crash Ard Biesheuvel (1): arm64/efi: map the entire UEFI vendor string before reading it Axel Lin (2): ASoC: sgtl5000: Fix up define for SGTL5000_SMALL_POP ASoC: pcm1681: Fix setting de-emphasis sampling rate selection Baruch Siach (1): dm crypt: update wiki page URL Beata Michalska (1): ARM: dts: Update video-phy node with syscon phandle for exynos3250 Ben Skeggs (1): drm/nouveau/kms/nv50-: guard against enabling cursor on disabled heads Ben Zhang (1): ASoC: ssm4567: Keep TDM_BCLKS in ssm4567_set_dai_fmt Brian King (3): ipr: Fix
Re: [PATCH] mm: add the block to the tail of the list in expand()
On 2015/8/1 7:24, Dave Hansen wrote: > On 07/31/2015 02:30 AM, Xishi Qiu wrote: >> __free_one_page() will judge whether the the next-highest order is free, >> then add the block to the tail or not. So when we split large order block, >> add the small block to the tail, it will reduce fragment. > > It's an interesting idea, but what does it do in practice? Can you > measure a decrease in fragmentation? > > Further, the comment above the function says: > * The order of subdivision here is critical for the IO subsystem. > * Please do not alter this order without good reasons and regression > * testing. > > Has there been regression testing? > > Also, this might not do very much good in practice. If you are > splitting a high-order page, you are doing the split because the > lower-order lists are empty. So won't that list_add() be to an empty Hi Dave, I made a mistake, you are right, all the lower-order lists are empty, so it is no sense to add to the tail. Thanks, Xishi Qiu > list most of the time? Or does the __rmqueue_fallback() > largest->smallest logic dominate? > > . > -- 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] efi: fix 32bit kernel boot failed problem using efi
From: fli
Commit 35d5134b7d5a
("x86/efi: Correct EFI boot stub use of code32_start")
imported a bug, which will cause 32bit kernel boot failed
using efi method. It should use the label's address instead
of the value stored in the label to caculate the address of
code32_start.
Signed-off-by: Fupan Li
---
arch/x86/boot/compressed/head_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/head_32.S
b/arch/x86/boot/compressed/head_32.S
index abb988a..3b28eff 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -54,7 +54,7 @@ ENTRY(efi_pe_entry)
callreloc
reloc:
popl%ecx
- sublreloc, %ecx
+ subl$reloc, %ecx
movl%ecx, BP_code32_start(%eax)
sub $0x4, %esp
--
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] net: dsa: fix EDSA frame from hwaccel frame
If the underlying network device features NETIF_F_HW_VLAN_CTAG_TX, an EDSA frame is prepended with a 802.1q header once queued. To fix this, push the VLAN tag to the payload if present, before checking the frame protocol. [note: we may prefer to access directly VLAN TCI from hwaccel frames, but this approach is simpler.] Signed-off-by: Vivien Didelot --- net/dsa/tag_edsa.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c index 2288c80..3ada4eb 100644 --- a/net/dsa/tag_edsa.c +++ b/net/dsa/tag_edsa.c @@ -9,6 +9,7 @@ */ #include +#include #include #include #include "dsa_priv.h" @@ -21,6 +22,10 @@ static struct sk_buff *edsa_xmit(struct sk_buff *skb, struct net_device *dev) struct dsa_slave_priv *p = netdev_priv(dev); u8 *edsa_header; + skb = vlan_hwaccel_push_inside(skb); + if (unlikely(!skb)) + return NULL; + /* * Convert the outermost 802.1q tag to a DSA tag and prepend * a DSA ethertype field is the packet is tagged, or insert -- 2.4.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arch: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire
On Sun, 2015-08-02 at 17:11 +0200, Andrey Konovalov wrote:
> Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
> with WRITE_ONCE() and READ_ONCE() on x86, arm, arm64, ia64, metag, mips,
> powerpc, s390, sparc and asm-generic since ACCESS_ONCE does not work
> reliably on non-scalar types.
.. and there are no restrictions on the argument to smp_load_acquire(), so it
may be a non-scalar type.
Though from a quick grep it looks like no one is doing that at the moment?
> WRITE_ONCE() and READ_ONCE() were introduced in the commits 230fa253df63
> ("kernel: Provide READ_ONCE and ASSIGN_ONCE") and 43239cbe79fc ("kernel:
> Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)").
>
> Signed-off-by: Andrey Konovalov
> ---
> Changed in v2:
> - Other archs besides x86.
>
> arch/powerpc/include/asm/barrier.h | 4 ++--
> diff --git a/arch/powerpc/include/asm/barrier.h
> b/arch/powerpc/include/asm/barrier.h
> index 51ccc72..0eca6ef 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -76,12 +76,12 @@
> do { \
> compiletime_assert_atomic_type(*p); \
> smp_lwsync(); \
> - ACCESS_ONCE(*p) = (v); \
> + WRITE_ONCE(*p, v); \
> } while (0)
>
> #define smp_load_acquire(p) \
> ({ \
> - typeof(*p) ___p1 = ACCESS_ONCE(*p); \
> + typeof(*p) ___p1 = READ_ONCE(*p); \
> compiletime_assert_atomic_type(*p); \
> smp_lwsync(); \
> ___p1; \
Acked-by: Michael Ellerman (powerpc)
cheers
--
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.10 ~ 3.14] efi: fix the efi 32bit boot failed problem
On 07/31/2015 08:21 PM, Luis Henriques wrote: On Fri, Jul 31, 2015 at 01:05:19PM +0100, Matt Fleming wrote: On Fri, 31 Jul, at 09:22:33AM, fupan wrote: Hi, Matt Will you take care of this patch or I send a V2? Could you please send a V2 with the changes to the commit message that I suggested previously? Thanks! I'm replying to this thread simply to include Jiri on the CC list as I believe 3.12 will also require this fix. Please make sure he's in the list for the v2. Hi, Luís No problem. BTW, actually all of the branch from 3.10 to 3.14 will need this fix. Fupan [ It looks like the 3.16 kernel I'm maintaining isn't affected, BTW. ] Cheers, -- Luís -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arch: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire
On Sun, 2015-08-02 at 17:11 +0200, Andrey Konovalov wrote:
> Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
> with WRITE_ONCE() and READ_ONCE() on x86, arm, arm64, ia64, metag, mips,
> powerpc, s390, sparc and asm-generic since ACCESS_ONCE does not work
> reliably on non-scalar types.
>
> WRITE_ONCE() and READ_ONCE() were introduced in the commits 230fa253df63
> ("kernel: Provide READ_ONCE and ASSIGN_ONCE") and 43239cbe79fc ("kernel:
> Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)").
>
> Signed-off-by: Andrey Konovalov
Acked-by: Davidlohr Bueso
--
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]Fix a null dereference in e1000_open
When e1000e_setup_rx_resources is failed in e1000_open, e1000e_free_tx_resources in "err_setup_rx" segment is executed. "writel(0, tx_ring->head)" statement in e1000_clean_tx_ring in e1000e_free_tx_resources will cause a null dereference(crash), because "tx_ring->head" is only assigned in e1000_configure_tx in e1000_configure, but it is after e1000e_setup_rx_resources. This patch adds a check to fix it. Signed-off-by: Jia-Ju Bai --- drivers/net/ethernet/intel/e1000e/netdev.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 89d788d..838ec8e 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -2448,7 +2448,8 @@ static void e1000_clean_tx_ring(struct e1000_ring *tx_ring) tx_ring->next_to_use = 0; tx_ring->next_to_clean = 0; - writel(0, tx_ring->head); + if (tx_ring->head) + writel(0, tx_ring->head); if (adapter->flags2 & FLAG2_PCIM2PCI_ARBITER_WA) e1000e_update_tdt_wa(tx_ring, 0); else -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3,1/8] powerpc/perf/hv-24x7: Whitespace - fix parameter alignment
On Wed, 2015-15-07 at 03:01:48 UTC, Sukadev Bhattiprolu wrote: > Fix parameter alignment to be consistent with coding style. > > Signed-off-by: Sukadev Bhattiprolu Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/40386217cd7bc38908d6 cheers -- 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: [v3, 2/8] powerpc/perf/hv-24x7: Simplify extracting counter from result buffer
On Wed, 2015-15-07 at 03:01:49 UTC, Sukadev Bhattiprolu wrote: > Simplify code that extracts a 24x7 counter from the HCALL's result buffer. > > Suggested-by: Joe Perches > Signed-off-by: Sukadev Bhattiprolu Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/465345ca387ed491c467 cheers -- 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] Documentation: minor typo fix in mailbox.txt
Fix minor typo so that can pass correct pointer variable for
container_of().
Signed-off-by: Leo Yan
---
Documentation/mailbox.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/mailbox.txt b/Documentation/mailbox.txt
index 1092ad9..f3f0ac2 100644
--- a/Documentation/mailbox.txt
+++ b/Documentation/mailbox.txt
@@ -51,8 +51,8 @@ struct demo_client {
*/
static void message_from_remote(struct mbox_client *cl, void *mssg)
{
- struct demo_client *dc = container_of(mbox_client,
- struct demo_client, cl);
+ struct demo_client *dc = container_of(cl,
+ struct demo_client, cl);
if (dc->async) {
if (is_an_ack(mssg)) {
/* An ACK to our last sample sent */
@@ -68,8 +68,8 @@ static void message_from_remote(struct mbox_client *cl, void
*mssg)
static void sample_sent(struct mbox_client *cl, void *mssg, int r)
{
- struct demo_client *dc = container_of(mbox_client,
- struct demo_client, cl);
+ struct demo_client *dc = container_of(cl,
+ struct demo_client, cl);
complete(>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/5] dt-bindings: clk: Hi6220: Document stub clock driver
Document the new compatible for stub clock driver which is used for CPU
and DDR's dynamic frequency scaling.
Signed-off-by: Leo Yan
---
.../devicetree/bindings/clock/hi6220-clock.txt| 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt
b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
index 259e30a..e4d5fea 100644
--- a/Documentation/devicetree/bindings/clock/hi6220-clock.txt
+++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
@@ -15,19 +15,36 @@ Required Properties:
- "hisilicon,hi6220-sysctrl"
- "hisilicon,hi6220-mediactrl"
- "hisilicon,hi6220-pmctrl"
+ - "hisilicon,hi6220-stub-clk"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
-For example:
+Optional Properties:
+
+- hisilicon,hi6220-clk-sram: phandle to the syscon managing the SoC internal
sram;
+ the driver need use the sram to pass parameters for frequency change.
+
+- mboxes: use the label reference for the mailbox as the first parameter, the
+ second parameter is the channel number.
+
+Example 1:
sys_ctrl: sys_ctrl@f703 {
compatible = "hisilicon,hi6220-sysctrl", "syscon";
reg = <0x0 0xf703 0x0 0x2000>;
#clock-cells = <1>;
};
+Example 2:
+ stub_clock: stub_clock {
+ compatible = "hisilicon,hi6220-stub-clk";
+ hisilicon,hi6220-clk-sram = <>;
+ #clock-cells = <1>;
+ mboxes = < 1>;
+ };
+
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
--
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/5] clk: Hi6220: add stub clock driver
On Hi6220, there have some clocks which can use mailbox channel to send
messages to power controller to change frequency; this includes CPU, GPU
and DDR clocks.
For dynamic frequency scaling, firstly need write the frequency value to
SRAM region, and then send message to mailbox to trigger power controller
to handle this requirement. This driver will use syscon APIs to pass SRAM
memory region and use common mailbox APIs for channels accessing.
This init driver will support cpu frequency change firstly.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/Kconfig | 2 +-
drivers/clk/hisilicon/Makefile | 2 +-
drivers/clk/hisilicon/clk-hi6220-stub.c | 279
3 files changed, 281 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/hisilicon/clk-hi6220-stub.c
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index b4165ba..2c16807 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,6 +1,6 @@
config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
- depends on ARCH_HISI || COMPILE_TEST
+ depends on (ARCH_HISI || COMPILE_TEST) && MAILBOX
default ARCH_HISI
help
Build the Hisilicon Hi6220 clock driver based on the common clock
framework.
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 48f0116..4a1001a 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -7,4 +7,4 @@ obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
-obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
+obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o clk-hi6220-stub.o
diff --git a/drivers/clk/hisilicon/clk-hi6220-stub.c
b/drivers/clk/hisilicon/clk-hi6220-stub.c
new file mode 100644
index 000..0931666
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi6220-stub.c
@@ -0,0 +1,279 @@
+/*
+ * Hi6220 stub clock driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Stub clocks id */
+#define HI6220_STUB_ACPU0 0
+#define HI6220_STUB_ACPU1 1
+#define HI6220_STUB_GPU2
+#define HI6220_STUB_DDR5
+
+/* Mailbox message */
+#define HI6220_MBOX_MSG_LEN8
+
+#define HI6220_MBOX_FREQ (0xA)
+#define HI6220_MBOX_CMD_SET(0x3)
+#define HI6220_MBOX_OBJ_AP (0x0)
+
+/* CPU dynamic frequency scaling */
+#define ACPU_DFS_FREQ_MAX (0x1724)
+#define ACPU_DFS_CUR_FREQ (0x17CC)
+#define ACPU_DFS_FLAG (0x1B30)
+#define ACPU_DFS_FREQ_REQ (0x1B34)
+#define ACPU_DFS_FREQ_LMT (0x1B38)
+#define ACPU_DFS_LOCK_FLAG (0xAEAEAEAE)
+
+#define to_stub_clk(hw) container_of(hw, struct hi6220_stub_clk, hw)
+
+struct hi6220_stub_clk {
+ u32 id;
+ u32 rate;
+
+ struct device *dev;
+ struct clk_hw hw;
+
+ struct regmap *dfs_map;
+ struct mbox_client cl;
+ struct mbox_chan *mbox;
+};
+
+struct hi6220_mbox_msg {
+ unsigned char type;
+ unsigned char cmd;
+ unsigned char obj;
+ unsigned char src;
+ unsigned char para[4];
+};
+
+union hi6220_mbox_data {
+ unsigned int data[HI6220_MBOX_MSG_LEN];
+ struct hi6220_mbox_msg msg;
+};
+
+static unsigned int hi6220_acpu_get_freq(struct hi6220_stub_clk *stub_clk)
+{
+ unsigned int freq;
+
+ regmap_read(stub_clk->dfs_map, ACPU_DFS_CUR_FREQ, );
+ return freq;
+}
+
+static int hi6220_acpu_set_freq(struct hi6220_stub_clk *stub_clk,
+ unsigned int freq)
+{
+ union hi6220_mbox_data data;
+
+ stub_clk->mbox = mbox_request_channel(_clk->cl, 0);
+ if (IS_ERR(stub_clk->mbox)) {
+ dev_err(stub_clk->dev, "failed get mailbox channel\n");
+ return PTR_ERR(stub_clk->mbox);
+ };
+
+ /* set the frequency in sram */
+ regmap_write(stub_clk->dfs_map, ACPU_DFS_FREQ_REQ, freq);
+
+ /* compound mailbox message */
+ data.msg.type = HI6220_MBOX_FREQ;
+ data.msg.cmd = HI6220_MBOX_CMD_SET;
+ data.msg.obj = HI6220_MBOX_OBJ_AP;
+ data.msg.src = HI6220_MBOX_OBJ_AP;
+
+ mbox_send_message(stub_clk->mbox, );
+ mbox_free_channel(stub_clk->mbox);
+ return 0;
+}
+
+static int hi6220_acpu_round_freq(struct hi6220_stub_clk *stub_clk,
+
[PATCH v3 5/5] arm64: dts: add Hi6220's stub clock node
Enable SRAM node and stub clock node for Hi6220; furthermore
add the CPU's clock so it will be used by cpufreq-dt driver.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index b42a9b7..94b8310 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -57,6 +57,17 @@
device_type = "cpu";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <_clock 0>;
+ clock-latency = <0>;
+ operating-points = <
+ /* kHz */
+ 120 0
+ 96 0
+ 729000 0
+ 432000 0
+ 208000 0
+ >;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu1: cpu@1 {
@@ -136,6 +147,11 @@
#size-cells = <2>;
ranges;
+ sram: sram@fff8 {
+ compatible = "hisilicon,hi6220-sramctrl", "syscon";
+ reg = <0x0 0xfff8 0x0 0x12000>;
+ };
+
ao_ctrl: ao_ctrl@f780 {
compatible = "hisilicon,hi6220-aoctrl", "syscon";
reg = <0x0 0xf780 0x0 0x2000>;
@@ -160,6 +176,13 @@
#clock-cells = <1>;
};
+ stub_clock: stub_clock {
+ compatible = "hisilicon,hi6220-stub-clk";
+ hisilicon,hi6220-clk-sram = <>;
+ #clock-cells = <1>;
+ mboxes = < 1>;
+ };
+
uart0: uart@f8015000 { /* console */
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0xf8015000 0x0 0x1000>;
--
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 1/5] clk: hisi: refine parameter checking for init
*of_iomap()* will check the device node pointer, and if the pointer is
NULL it will return error code. So refine clock's init flow by checking
the device node with this simple way; and polish a little for the print
out message.
Signed-off-by: Leo Yan
---
drivers/clk/hisilicon/clk.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
index c90a897..156435d 100644
--- a/drivers/clk/hisilicon/clk.c
+++ b/drivers/clk/hisilicon/clk.c
@@ -45,14 +45,9 @@ struct hisi_clock_data __init *hisi_clk_init(struct
device_node *np,
struct clk **clk_table;
void __iomem *base;
- if (np) {
- base = of_iomap(np, 0);
- if (!base) {
- pr_err("failed to map Hisilicon clock registers\n");
- goto err;
- }
- } else {
- pr_err("failed to find Hisilicon clock node in DTS\n");
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_err("%s: failed to map clock registers\n", __func__);
goto err;
}
--
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 2/5] dt-bindings: arm: Hi6220: add doc for SRAM controller
Document "hisilicon,hi6220-sramctrl" for SRAM controller.
Signed-off-by: Leo Yan
---
.../devicetree/bindings/arm/hisilicon/hisilicon.txt| 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index c431c67..c733e28 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -127,6 +127,24 @@ Example:
#clock-cells = <1>;
};
+
+Hisilicon Hi6220 SRAM controller
+
+Required properties:
+- compatible : "hisilicon,hi6220-sramctrl", "syscon"
+- reg : Register address and size
+
+Hisilicon's SoCs use sram for multiple purpose; on Hi6220 there have several
+SRAM banks for power management, modem, security, etc. Further, use "syscon"
+managing the common sram which can be shared by multiple modules.
+
+Example:
+ /*for Hi6220*/
+ sram: sram@fff8 {
+ compatible = "hisilicon,hi6220-sramctrl", "syscon";
+ reg = <0x0 0xfff8 0x0 0x12000>;
+ };
+
---
Hisilicon HiP01 system controller
--
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 0/5] clk: hisilicon: support stub clock
This series adds support for hisilicon stub clock driver. On hi6220, the bootloader needs load the firmware image and set info for OPPs; after run into kernel, the stub clock driver is used to communicate w/t firmware for cpu dynamic frequency scaling. In patch series v1/v2, the stub clock driver simply writes request in sram and send ipc to firmware; For patch series v3, the firmware has been upgraded to use mailbox, so stub clock driver will call standard mailbox APIs to request mailbox channel and send message to firmware. These patches have been tested on 96board hikey and is used by cpufreq driver. Changes from v2: * Use platform_device's probe for clock's initialization * Use mailbox channel for clock frequency change Changes from v1: * Refine parameter checking for init flow * Remove unnecessary debugging info * Modify to check spinlock pointer when register clocks Leo Yan (5): clk: hisi: refine parameter checking for init dt-bindings: arm: Hi6220: add doc for SRAM controller dt-bindings: clk: Hi6220: Document stub clock driver clk: Hi6220: add stub clock driver arm64: dts: add Hi6220's stub clock node .../bindings/arm/hisilicon/hisilicon.txt | 18 ++ .../devicetree/bindings/clock/hi6220-clock.txt | 19 +- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 23 ++ drivers/clk/hisilicon/Kconfig | 2 +- drivers/clk/hisilicon/Makefile | 2 +- drivers/clk/hisilicon/clk-hi6220-stub.c| 279 + drivers/clk/hisilicon/clk.c| 11 +- 7 files changed, 343 insertions(+), 11 deletions(-) create mode 100644 drivers/clk/hisilicon/clk-hi6220-stub.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/
[RFC PATCH 2/3] mailbox: Hisilicon: add mailbox driver
Add Hisilicon mailbox's common driver, it registers mailbox channels
into framework; it also invokes low level callback functions for
register's related operations. Enhance rx channel's message queue,
which is based on the code in drivers/mailbox/omap-mailbox.c.
Enable Hi6220 mailbox driver as the first platform to use this
framework. Hi6220's mailbox communicates with MCU; for sending data,
it can support two methods for low level implementation: one is to
use interrupt as acknowledge, another is automatic mode which without
any acknowledge. These two methods have been supported in the driver;
for receiving data, it will depend on the interrupt to notify the
channel has incoming message.
Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.
Signed-off-by: Leo Yan
---
drivers/mailbox/Kconfig| 2 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/hisilicon/Kconfig | 13 ++
drivers/mailbox/hisilicon/Makefile | 2 +
drivers/mailbox/hisilicon/common.c | 282 ++
drivers/mailbox/hisilicon/common.h | 114 +++
drivers/mailbox/hisilicon/hi6220-mailbox.c | 305 +
7 files changed, 720 insertions(+)
create mode 100644 drivers/mailbox/hisilicon/Kconfig
create mode 100644 drivers/mailbox/hisilicon/Makefile
create mode 100644 drivers/mailbox/hisilicon/common.c
create mode 100644 drivers/mailbox/hisilicon/common.h
create mode 100644 drivers/mailbox/hisilicon/hi6220-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index e269f08..a426901 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -70,4 +70,6 @@ config BCM2835_MBOX
the services of the Videocore. Say Y here if you want to use the
BCM2835 Mailbox.
+source "drivers/mailbox/hisilicon/Kconfig"
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..1e82dfb 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
+
+obj-$(CONFIG_HISI_MBOX)+= hisilicon/
diff --git a/drivers/mailbox/hisilicon/Kconfig
b/drivers/mailbox/hisilicon/Kconfig
new file mode 100644
index 000..87548a9
--- /dev/null
+++ b/drivers/mailbox/hisilicon/Kconfig
@@ -0,0 +1,13 @@
+config HISI_MBOX
+ bool "Hisilicon's Mailbox"
+ depends on ARCH_HISI || OF
+ help
+ Support for mailbox drivers on Hisilicon series of SoCs.
+
+config HI6220_MBOX
+ tristate "Hi6220 Mailbox Controller"
+ depends on HISI_MBOX
+ help
+ An implementation of the hi6220 mailbox. It is used to send message
+ between application processors and MCU. Say Y here if you want to
build
+ the Hi6220 mailbox controller driver.
diff --git a/drivers/mailbox/hisilicon/Makefile
b/drivers/mailbox/hisilicon/Makefile
new file mode 100644
index 000..59135b0
--- /dev/null
+++ b/drivers/mailbox/hisilicon/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_HISI_MBOX) += common.o
+obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
diff --git a/drivers/mailbox/hisilicon/common.c
b/drivers/mailbox/hisilicon/common.c
new file mode 100644
index 000..c3c8e49
--- /dev/null
+++ b/drivers/mailbox/hisilicon/common.c
@@ -0,0 +1,282 @@
+/*
+ * Hisilicon mailbox common driver
+ *
+ * This is skeleton driver for Hisilicon's mailbox, it registers mailbox
+ * channels into framework; it also need invoke low level's callback
+ * functions for low level operations. RX channel's message queue is
+ * based on the code written in drivers/mailbox/omap-mailbox.c.
+
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan
+ *
+ * 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, version 2 of the License.
+ *
+ * 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 "common.h"
+
+#define MBOX_MSG_LEN (32)
+#define MBOX_MSG_NUM (16)
+#define MBOX_MSG_FIFO_SIZE (MBOX_MSG_LEN * MBOX_MSG_NUM)
+
+static bool hisi_mbox_last_tx_done(struct mbox_chan *chan)
+{
+ struct hisi_mbox_chan *mchan = chan->con_priv;
+ struct hisi_mbox_hw *mbox_hw = mchan->mbox_hw;
+
+ /* Only set idle state for polling mode */
+ BUG_ON(mbox_hw->tx_irq_mode);
+
+ return mbox_hw->ops->tx_is_done(mchan);
+}
+
+static int hisi_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+
[RFC PATCH 3/3] arm64: dts: add Hi6220 mailbox node
On Hi6220, below memory regions in DDR have specific purpose:
- 0x05e0, - 0x05ef,: For MCU firmware using at runtime;
- 0x0740,f000 - 0x0740,: For MCU firmware's section;
- 0x06df,f000 - 0x06df,: For mailbox message data.
This patch reserves these memory regions and add device node for
mailbox in dts.
Signed-off-by: Leo Yan
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e36a539..1715f9d 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -7,9 +7,6 @@
/dts-v1/;
-/*Reserved 1MB memory for MCU*/
-/memreserve/ 0x05e0 0x0010;
-
#include "hi6220.dtsi"
/ {
@@ -28,4 +25,21 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ mcu-buf@05e0 {
+ no-map;
+ reg = <0x0 0x0740f000 0x0 0x1000>, /* MCU firmware
section */
+ <0x0 0x05e0 0x0 0x0010>; /* MCU firmware
buffer */
+ };
+
+ mbox-buf@06dff000 {
+ no-map;
+ reg = <0x0 0x06dff000 0x0 0x1000>; /* Mailbox
message buf */
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..b42a9b7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,13 @@
clocks = <_ctrl 36>, <_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+ mailbox: mailbox {
+ #mbox-cells = <1>;
+ compatible = "hisilicon,hi6220-mbox";
+ reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
+ <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+ interrupts = ;
+ };
};
};
--
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/
[RFC PATCH 1/3] dt-bindings: mailbox: Document Hisilicon mailbox driver
Document the new compatible for Hisilicon mailbox driver.
Signed-off-by: Leo Yan
---
.../devicetree/bindings/mailbox/hisi-mailbox.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/hisi-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/hisi-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/hisi-mailbox.txt
new file mode 100644
index 000..898823d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisi-mailbox.txt
@@ -0,0 +1,57 @@
+Hisilicon Mailbox Driver
+
+
+The Hisilicon mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+
+
+Required properties:
+
+- compatible: Shall be "hisilicon,hi6220-mbox"
+- reg: Contains the mailbox register address range (base
+ address and length); the first item is for IPC
+ registers, the second item is shared buffer for
+ slots.
+- #mbox-cells Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be
1.
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the SoCs use.
+
+Example:
+
+
+ mailbox: mailbox@F751 {
+ #mbox-cells = <1>;
+ compatible = "hisilicon,hi6220-mbox";
+ reg = <0x0 0xF751 0x0 0x1000>, /* IPC_S */
+ <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
+ interrupt-parent = <>;
+ interrupts = <0 94 4>;
+ };
+
+
+Mailbox client
+===
+
+"mboxes" and the optional "mbox-names" (please see
+Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
+of the mboxes property should contain a phandle to the mailbox controller
+device node and second argument is the channel index. It must be 0 (hardware
+support only one channel). The equivalent "mbox-names" property value can be
+used to give a name to the communication channel to be used by the client user.
+
+Example:
+
+
+ stub_clock: stub_clock {
+ compatible = "hisilicon,hi6220-stub-clk";
+ hisilicon,hi6220-clk-sram = <>;
+ #clock-cells = <1>;
+ mbox-names = "mbox-tx";
+ mboxes = < 1>;
+ };
--
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/
[RFC PATCH 0/3] mailbox: hisilicon: add mailbox driver
This patch series is to implement Hisilicon's mailbox driver and enable the mailbox controller on Hi6220. The Hisilicon mailbox supports up to 32 channels. Each channel is unidirectional with a maximum message size of 8 words. I/O is performed using register access (there is no DMA) and the cell raises an interrupt when messages are received. For easily extending for Hisilicon series SoCs (SoCs may have difference for register's definition with each other), so firstly implement common mailbox driver; this common mailbox driver provides three mainly functionality: - help register channels into framework; - hook low level callback functions for register's operations; - Enhance rx channel's message queue, which is based on the code in drivers/mailbox/omap-mailbox.c. Base on this common driver, also has enabled Hi6220 mailbox controller. Leo Yan (3): dt-bindings: mailbox: Document Hisilicon mailbox driver mailbox: Hisilicon: add mailbox driver arm64: dts: add Hi6220 mailbox node .../devicetree/bindings/mailbox/hisi-mailbox.txt | 57 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 + drivers/mailbox/Kconfig| 2 + drivers/mailbox/Makefile | 2 + drivers/mailbox/hisilicon/Kconfig | 13 + drivers/mailbox/hisilicon/Makefile | 2 + drivers/mailbox/hisilicon/common.c | 282 +++ drivers/mailbox/hisilicon/common.h | 114 drivers/mailbox/hisilicon/hi6220-mailbox.c | 305 + 10 files changed, 802 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/hisi-mailbox.txt create mode 100644 drivers/mailbox/hisilicon/Kconfig create mode 100644 drivers/mailbox/hisilicon/Makefile create mode 100644 drivers/mailbox/hisilicon/common.c create mode 100644 drivers/mailbox/hisilicon/common.h create mode 100644 drivers/mailbox/hisilicon/hi6220-mailbox.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/
Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times
On 31/07/15 19:11, Bryan O'Donoghue wrote: On 31/07/15 17:43, Bryan O'Donoghue wrote: On 31/07/15 17:36, Ilia Mirkin wrote: Do you have a reproducible way of achieving the multiple buffer on validation list thing? Ilia, Peter. I've filed a bug for you here : https://bugs.freedesktop.org/show_bug.cgi?id=91535 I've verified that Peter's PPA library when installed fixes the race condition you guys were talking about but running the test program tests/nouveau/threaded so, this issue we're discussing here is a separate one. Cheers, Bryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] serial: samsung: fix DMA for small FIFO sizes
On 31.07.2015 17:58, Robert Baldyga wrote: > Hello, > > This patch set fixes bug causing serial hang in DMA mode for FIFO sizes > smaller than cache alignment. The first patch fixes DMA mode entering > condition to avoid starting with buffer smaller than cache line size. > Second patch fixes the serial hang bug, which was caused by unproper > buffer aligning algorithm which assumed that there is always enough > free space in FIFO for excessive bytes of buffer that is being alligned. > > Best regards, > Robert Baldyga > > Changelog: > > v2: > - Add CC to stable > - Add Reported-by: Krzysztof Kozlowski > - Change title of the first patch to more relevant > > v1: http://permalink.gmane.org/gmane.linux.kernel/2008281 > > Marek Szyprowski (1): > serial: samsung: fix DMA mode enter condition for small FIFO sizes > > Robert Baldyga (1): > serial: samsung: fix DMA for FIFO smaller than cache line size > > drivers/tty/serial/samsung.c | 47 > +--- > drivers/tty/serial/samsung.h | 1 + > 2 files changed, 32 insertions(+), 16 deletions(-) > Tested on Trats2 (Exynos4412 with pl330, serial output on ttySAC2). Patchset fixes the reported issue (hang after applying "ARM: dts: exynos4: add DMA support for serial ports" [0]). However with [0] dmatest cannot execute tests on dma0 channels. Just silently passes but does not execute memcpy on any of dma0 channels. I wonder why... the serial ports use only some of dma0 channels, not all of them. Any ideas? [0] http://www.spinics.net/lists/linux-samsung-soc/msg45700.html Best regards, Krzysztof -- 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] Please pull powerpc/linux.git powerpc-4.2-3 tag
Hi Linus, Please pull some more powerpc fixes for 4.2: The following changes since commit c5dfd654d0ec0a28fe81e7bd4d4fd984a9855e09: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-07-22 14:45:25 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.2-3 for you to fetch changes up to b8d65e9662b1ffb3b52a65fd11b0b968022dc6a1: powerpc/eeh-powernv: Fix unbalanced IRQ warning (2015-07-30 19:01:32 +1000) powerpc fixes for 4.2 #2 - TCE table memory calculation fix from Alexey - Build fix for ans-lcd from Luis - Unbalanced IRQ warning fix from Alistair Alexey Kardashevskiy (1): powerpc/powernv/ioda2: Fix calculation for memory allocated for TCE table Alistair Popple (1): powerpc/eeh-powernv: Fix unbalanced IRQ warning Luis Henriques (1): macintosh/ans-lcd: fix build failure after module_init/exit relocation arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +- arch/powerpc/platforms/powernv/pci-ioda.c| 11 ++- drivers/macintosh/ans-lcd.c | 2 +- 3 files changed, 8 insertions(+), 7 deletions(-) signature.asc Description: This is a digitally signed message part
[PATCH v2] HID: hid-input: Fix accessing freed memory during device disconnect
During unbinding the driver was dereferencing a pointer to memory
already freed by power_supply_unregister().
Driver was freeing its internal description of battery through pointers
stored in power_supply structure. However, because the core owns the
power supply instance, after calling power_supply_unregister() this
memory is freed and the driver cannot access these members.
Fix this by storing the pointer to internal description of battery in a
local variable before calling power_supply_unregister(), so the pointer
remains valid.
Signed-off-by: Krzysztof Kozlowski
Reported-by: H.J. Lu
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Cc:
---
Changes since v1:
1. Re-work idea, use local variable instead of devm-like functions
(pointed out by Dmitry Torokhov).
2. Adjusted subject and commit message.
---
drivers/hid/hid-input.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 14aebe483219..460faaebaa2c 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -462,12 +462,15 @@ out:
static void hidinput_cleanup_battery(struct hid_device *dev)
{
+ struct power_supply_desc *psy_desc;
+
if (!dev->battery)
return;
+ psy_desc = dev->battery->desc;
power_supply_unregister(dev->battery);
- kfree(dev->battery->desc->name);
- kfree(dev->battery->desc);
+ kfree(psy_desc->name);
+ kfree(psy_desc);
dev->battery = NULL;
}
#else /* !CONFIG_HID_BATTERY_STRENGTH */
--
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/
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Timo, On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson wrote: > sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 > boards > (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the > voltage for the lowest operating point to 1.0V so all boards can actually use > it. Surely it wouldn't be added here if some could supply 0.9v. Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? (Alternatively, would it make sense to modify the code that uses this to use frequencies with voltages specified that are lower than can be supplied with the lowest voltage it can?) Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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 4.1.3, DRM *ERROR* Unclaimed register before interrupt
I see these in dmesg, but I don't think I've seen any actual issues in using the laptop itself. Should I be worried? lspci: 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) (prog-if 00 [VGA controller]) DeviceName: Onboard IGD Subsystem: Dell Device 05ca Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel driver in use: i915 Kernel modules: i915 dmesg (attached): [1.484760] [ cut here ] [1.484793] WARNING: CPU: 3 PID: 59 at drivers/gpu/drm/i915/intel_uncore.c:566 hsw_unclaimed_reg_debug+0x79/0xa0 [i915]() [1.484813] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [1.484814] Unclaimed register detected after writing to register 0x6101c [1.484819] Modules linked in: i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core [1.484821] CPU: 3 PID: 59 Comm: kworker/u8:1 Not tainted 4.1.3-1-ck #1 [1.484822] Hardware name: Dell Inc. Latitude E7240/0R6F3F, BIOS A15 05/19/2015 [1.484826] Workqueue: events_unbound async_run_entry_fn [1.484829] e42f33d5 8800da213758 8156bc0c [1.484830] 8800da2137b0 8800da213798 81077a0a [1.484832] 880214daa000 8802132e 0006101c 8802132e0070 [1.484832] Call Trace: [1.484838] [] dump_stack+0x4c/0x6e [1.484840] [] warn_slowpath_common+0x8a/0xc0 [1.484842] [] warn_slowpath_fmt+0x55/0x70 [1.484860] [] hsw_unclaimed_reg_debug+0x79/0xa0 [i915] [1.484875] [] hsw_write32+0x94/0x160 [i915] [1.484890] [] intel_update_pipe_size+0x74/0x1a0 [i915] [1.484910] [] intel_crtc_set_config+0x811/0x1080 [i915] [1.484916] [] ? drm_atomic_state_free+0x2c/0x60 [drm] [1.484922] [] drm_mode_set_config_internal+0x66/0x100 [drm] [1.484925] [] restore_fbdev_mode+0xc8/0xf0 [drm_kms_helper] [1.484928] [] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [1.484930] [] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [1.484950] [] intel_fbdev_set_par+0x1a/0x60 [i915] [1.484954] [] fbcon_init+0x58f/0x610 [1.484956] [] visual_init+0xbc/0x120 [1.484958] [] do_bind_con_driver+0x1ce/0x400 [1.484960] [] do_take_over_console+0x120/0x1b0 [1.484961] [] ? printk+0x55/0x6b [1.484964] [] do_fbcon_takeover+0x5b/0xc0 [1.484966] [] fbcon_event_notify+0x6e5/0x7e0 [1.484968] [] notifier_call_chain+0x4f/0x80 [1.484970] [] __blocking_notifier_call_chain+0x4b/0x70 [1.484973] [] blocking_notifier_call_chain+0x16/0x20 [1.484974] [] fb_notifier_call_chain+0x1b/0x20 [1.484976] [] register_framebuffer+0x21a/0x380 [1.484978] [] drm_fb_helper_initial_config+0x273/0x700 [drm_kms_helper] [1.484996] [] intel_fbdev_initial_config+0x1b/0x20 [i915] [1.484998] [] async_run_entry_fn+0x4c/0x170 [1.485000] [] process_one_work+0x14b/0x470 [1.485001] [] worker_thread+0x48/0x4c0 [1.485003] [] ? process_one_work+0x470/0x470 [1.485004] [] ? process_one_work+0x470/0x470 [1.485006] [] kthread+0xd8/0xf0 [1.485009] [] ? kthread_worker_fn+0x170/0x170 [1.485010] [] ret_from_fork+0x42/0x70 [1.485012] [] ? kthread_worker_fn+0x170/0x170 [1.485013] ---[ end trace a5bfacd133f540e8 ]--- [1.485780] [ cut here ] [1.485803] WARNING: CPU: 3 PID: 59 at drivers/gpu/drm/i915/intel_uncore.c:566 hsw_unclaimed_reg_debug+0x79/0xa0 [i915]() [1.485822] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [1.485823] Unclaimed register detected after writing to register 0x68080 [1.485827] Modules linked in: i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core [1.485829] CPU: 3 PID: 59 Comm: kworker/u8:1 Tainted: GW 4.1.3-1-ck #1 [1.485829] Hardware name: Dell Inc. Latitude E7240/0R6F3F, BIOS A15 05/19/2015 [1.485831] Workqueue: events_unbound async_run_entry_fn [1.485834] e42f33d5 8800da213698 8156bc0c [1.485835] 8800da2136f0 8800da2136d8 81077a0a [1.485837] 0002 8802132e 00068080 8802132e0070 [1.485837] Call Trace: [1.485840] [] dump_stack+0x4c/0x6e [1.485842] [] warn_slowpath_common+0x8a/0xc0 [1.485843] [] warn_slowpath_fmt+0x55/0x70 [1.485862] [] ? gm45_get_vblank_counter+0x32/0x40 [i915] [1.485880] [] hsw_unclaimed_reg_debug+0x79/0xa0 [i915] [1.485895] [] hsw_write32+0x94/0x160 [i915] [1.485898] [] ? wake_atomic_t_function+0x60/0x60 [1.485915] [] intel_update_pipe_size+0xf1/0x1a0 [i915] [1.485931] [] intel_commit_primary_plane+0x88/0xd0 [i915] [1.485951] []
[PATCH] pinctrl/mediatek: fix spelling mistake in dev_err error message
From: Colin Ian King
Trivial change, fix spelling mistake 'invaild' -> 'invalid' in
dev_err message.
Signed-off-by: Colin Ian King
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..5af5441 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -702,7 +702,7 @@ static int mtk_pmx_set_mux(struct pinctrl_dev *pctldev,
ret = mtk_pctrl_is_function_valid(pctl, g->pin, function);
if (!ret) {
- dev_err(pctl->dev, "invaild function %d on group %d .\n",
+ dev_err(pctl->dev, "invalid function %d on group %d .\n",
function, group);
return -EINVAL;
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
