Re: [PATCH 0/5] Android: Small documentation changes and a bug fix
Sorry, I didn't realize that text would look so ugly in LKML. I'll be sure to keep the lines nice and short next time. ~Cruz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 4/4 v3] mm: fix possible incorrect return value of move_pages() syscall
On Mon, Jul 30, 2012 at 9:29 PM, Christoph Lameter wrote: > On Sat, 28 Jul 2012, JoonSoo Kim wrote: > >> 2012/7/28 Christoph Lameter : >> > On Sat, 28 Jul 2012, Joonsoo Kim wrote: >> > >> >> move_pages() syscall may return success in case that >> >> do_move_page_to_node_array return positive value which means migration >> >> failed. >> > >> > Nope. It only means that the migration for some pages has failed. This may >> > still be considered successful for the app if it moves 1 pages and one >> > failed. >> > >> > This patch would break the move_pages() syscall because an error code >> > return from do_move_pages_to_node_array() will cause the status byte for >> > each page move to not be updated anymore. Application will not be able to >> > tell anymore which pages were successfully moved and which are not. >> >> In case of returning non-zero, valid status is not required according >> to man page. > > Cannot find a statement like that in the man page. The return code > description is incorrect. It should that that is returns the number of > pages not moved otherwise an error code (Michael please fix the manpage). Hi Christoph, Is the patch below acceptable? (I've attached the complete page as well.) See you in San Diego (?), Michael --- a/man2/migrate_pages.2 +++ b/man2/migrate_pages.2 @@ -29,7 +29,7 @@ migrate_pages \- move all pages in a process to another set of nodes Link with \fI\-lnuma\fP. .SH DESCRIPTION .BR migrate_pages () -moves all pages of the process +attempts to move all pages of the process .I pid that are in memory nodes .I old_nodes @@ -87,7 +87,8 @@ privilege. .SH "RETURN VALUE" On success .BR migrate_pages () -returns zero. +returns the number of pages that cold not be moved +(i.e., a return of zero means that all pages were successfully moved). On error, it returns \-1, and sets .I errno to indicate the error. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ migrate_pages.2 Description: Binary data
RE: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On Wed, 1 Aug 2012, Jingoo Han wrote:
On Wednesday, August 01, 2012 1:38 PM Sachin Kamat wrote:
On 1 August 2012 10:00, Jingoo Han wrote:
On Wednesday, August 01, 2012 1:00 PMSachin Kamat wrote:
On 1 August 2012 04:51, Jingoo Han wrote:
On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
From: Damien Cassou
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Damien Cassou
---
drivers/video/exynos/exynos_dp_core.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index c6c016a..00fe4f0 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct platform_device
*pdev)
dp->dev = >dev;
- dp->clock = clk_get(>dev, "dp");
+ dp->clock = devm_clk_get(>dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(>dev, "failed to get clock\n");
return PTR_ERR(dp->clock);
@@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
platform_device *pdev)
clk_enable(dp->clock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(>dev, "failed to get registers\n");
- ret = -EINVAL;
- goto err_clock;
- }
Why do you remove this return check?
If there is no reason, please, do it as follows:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(>dev, "failed to get registers\n");
- ret = -EINVAL;
- goto err_clock;
+ return -EINVAL;
}
devm_request_and_ioremap function checks the validity of res. Hence
this check above is redundant and can be removed.
I don't think so.
Even though function called next checks the NULL value,
for robustness, the return value of platform_get_resource() should be
checked.
It is possible that devm_request_and_ioremap() can be changed in the future,
as request_mem_region() & ioremap() were changed to devm_request_and_ioremap().
They are not changed. They still exist. devm_request_and_ioremap() is
an additional function provided for device managed resources.
OK, I see. I accept it.
Anyway it is simpler.
This thread contains a discussion about the issue
http://lkml.org/lkml/2012/1/28/10
Look for the comments by Wolfram Sang, who
implemented devm_request_and_ioremap, and who suggests that the NULL test
be removed.
I rather agree with the desire to be safe and uniform, but these
initialization functions are really large, and with error handling code
(although not in this case) there is always the danger of jumping to the
wrong place, and thus making more of a mess. It would be nice if the
platform_get_resource could be merged with devm_request_and_ioremap, but I
think that I looked once and there were not enough calls that were similar
enough to make that compelling.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On Wednesday, August 01, 2012 1:00 PM Sachin Kamat wrote:
>
> On 1 August 2012 04:51, Jingoo Han wrote:
> > On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
> >>
> >> From: Damien Cassou
> >>
> >> The various devm_ functions allocate memory that is released when a driver
> >> detaches. This patch uses these functions for data that is allocated in
> >> the probe function of a platform device and is only freed in the remove
> >> function.
> >>
> >> Signed-off-by: Damien Cassou
> >>
> >> ---
> >> drivers/video/exynos/exynos_dp_core.c | 27 +++
> >> 1 file changed, 7 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/video/exynos/exynos_dp_core.c
> >> b/drivers/video/exynos/exynos_dp_core.c
> >> index c6c016a..00fe4f0 100644
> >> --- a/drivers/video/exynos/exynos_dp_core.c
> >> +++ b/drivers/video/exynos/exynos_dp_core.c
> >> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >>
> >> dp->dev = >dev;
> >>
> >> - dp->clock = clk_get(>dev, "dp");
> >> + dp->clock = devm_clk_get(>dev, "dp");
> >> if (IS_ERR(dp->clock)) {
> >> dev_err(>dev, "failed to get clock\n");
> >> return PTR_ERR(dp->clock);
> >> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> clk_enable(dp->clock);
> >>
> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> - if (!res) {
> >> - dev_err(>dev, "failed to get registers\n");
> >> - ret = -EINVAL;
> >> - goto err_clock;
> >> - }
> >
> > Why do you remove this return check?
> > If there is no reason, please, do it as follows:
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!res) {
> > dev_err(>dev, "failed to get registers\n");
> > - ret = -EINVAL;
> > - goto err_clock;
> > + return -EINVAL;
> > }
> >
> >
>
> devm_request_and_ioremap function checks the validity of res. Hence
> this check above is redundant and can be removed.
>
> Damien,
> This patch only adds devm_clk_get() function. Hence you could make the
> subject line more specific.
To Damien,
As Sachin Kamat mentioned, please change the subject more specific. For example,
video: exynos_dp: use devm_clk_get function
Best regards,
Jingoo Han
>
>
>
>
> > Best regards,
> > Jingoo Han
> >
> >
> >>
> >> dp->reg_base = devm_request_and_ioremap(>dev, res);
> >> if (!dp->reg_base) {
> >> dev_err(>dev, "failed to ioremap\n");
> >> - ret = -ENOMEM;
> >> - goto err_clock;
> >> + return -ENOMEM;
> >> }
> >>
> >> dp->irq = platform_get_irq(pdev, 0);
> >> if (!dp->irq) {
> >> dev_err(>dev, "failed to get irq\n");
> >> - ret = -ENODEV;
> >> - goto err_clock;
> >> + return -ENODEV;
> >> }
> >>
> >> ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler, 0,
> >> "exynos-dp", dp);
> >> if (ret) {
> >> dev_err(>dev, "failed to request irq\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> dp->video_info = pdata->video_info;
> >> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> ret = exynos_dp_detect_hpd(dp);
> >> if (ret) {
> >> dev_err(>dev, "unable to detect hpd\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> exynos_dp_handle_edid(dp);
> >> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> dp->video_info->link_rate);
> >> if (ret) {
> >> dev_err(>dev, "unable to do link train\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> exynos_dp_enable_scramble(dp, 1);
> >> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> ret = exynos_dp_config_video(dp, dp->video_info);
> >> if (ret) {
> >> dev_err(>dev, "unable to config video\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> platform_set_drvdata(pdev, dp);
> >>
> >> return 0;
> >> -
> >> -err_clock:
> >> - clk_put(dp->clock);
> >> -
> >> - return ret;
> >> }
> >>
> >> static int __devexit exynos_dp_remove(struct platform_device *pdev)
> >> @@ -962,7 +950,6 @@ static int __devexit exynos_dp_remove(struct
> >> platform_device *pdev)
> >> pdata->phy_exit();
> >>
> >> clk_disable(dp->clock);
> >> - clk_put(dp->clock);
> >>
> >> return 0;
> >> }
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message
Re: [GIT PULL] PWM subsystem for v3.6
On Tue, Jul 31, 2012 at 06:08:01PM -0700, Linus Torvalds wrote: > On Tue, Jul 31, 2012 at 1:19 AM, Thierry Reding > wrote: > > > > I just sent a new pull request with a signed tag. I've also included a > > more detailed description of why this is useful, along the lines of what > > Arnd already mentioned. > > > > My key was signed by Sebastian Andrzej Siewior today and I uploaded the > > signature only now, so it may take some time to propagate. > > Ok. I had decided that I had lots of acks for your code and had > actually pulled your code yesterday, so my merge doesn't have that new > tag information. But I verified your tag separately, and everything > looks fine. So future pulls will then be properly signed in my repo > too if you use tags, Great! Thanks, Thierry pgp53IGxNAW3S.pgp Description: PGP signature
RE: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On Wednesday, August 01, 2012 1:38 PM Sachin Kamat wrote:
>
> On 1 August 2012 10:00, Jingoo Han wrote:
> > On Wednesday, August 01, 2012 1:00 PMSachin Kamat wrote:
> >>
> >> On 1 August 2012 04:51, Jingoo Han wrote:
> >> > On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
> >> >>
> >> >> From: Damien Cassou
> >> >>
> >> >> The various devm_ functions allocate memory that is released when a
> >> >> driver
> >> >> detaches. This patch uses these functions for data that is allocated in
> >> >> the probe function of a platform device and is only freed in the remove
> >> >> function.
> >> >>
> >> >> Signed-off-by: Damien Cassou
> >> >>
> >> >> ---
> >> >> drivers/video/exynos/exynos_dp_core.c | 27
> >> >> +++
> >> >> 1 file changed, 7 insertions(+), 20 deletions(-)
> >> >>
> >> >> diff --git a/drivers/video/exynos/exynos_dp_core.c
> >> >> b/drivers/video/exynos/exynos_dp_core.c
> >> >> index c6c016a..00fe4f0 100644
> >> >> --- a/drivers/video/exynos/exynos_dp_core.c
> >> >> +++ b/drivers/video/exynos/exynos_dp_core.c
> >> >> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct
> >> >> platform_device *pdev)
> >> >>
> >> >> dp->dev = >dev;
> >> >>
> >> >> - dp->clock = clk_get(>dev, "dp");
> >> >> + dp->clock = devm_clk_get(>dev, "dp");
> >> >> if (IS_ERR(dp->clock)) {
> >> >> dev_err(>dev, "failed to get clock\n");
> >> >> return PTR_ERR(dp->clock);
> >> >> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
> >> >> platform_device *pdev)
> >> >> clk_enable(dp->clock);
> >> >>
> >> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> >> - if (!res) {
> >> >> - dev_err(>dev, "failed to get registers\n");
> >> >> - ret = -EINVAL;
> >> >> - goto err_clock;
> >> >> - }
> >> >
> >> > Why do you remove this return check?
> >> > If there is no reason, please, do it as follows:
> >> >
> >> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> > if (!res) {
> >> > dev_err(>dev, "failed to get registers\n");
> >> > - ret = -EINVAL;
> >> > - goto err_clock;
> >> > + return -EINVAL;
> >> > }
> >> >
> >> >
> >>
> >> devm_request_and_ioremap function checks the validity of res. Hence
> >> this check above is redundant and can be removed.
> >
> >
> > I don't think so.
> > Even though function called next checks the NULL value,
> > for robustness, the return value of platform_get_resource() should be
> > checked.
> >
> > It is possible that devm_request_and_ioremap() can be changed in the future,
> > as request_mem_region() & ioremap() were changed to
> > devm_request_and_ioremap().
>
> They are not changed. They still exist. devm_request_and_ioremap() is
> an additional function provided for device managed resources.
OK, I see. I accept it.
Anyway it is simpler.
>
>
> >
> >
> > Best regards,
> > Jingoo Han
> >
> >
> >>
> >> Damien,
> >> This patch only adds devm_clk_get() function. Hence you could make the
> >> subject line more specific.
> >>
> >>
> >>
> >>
> >> > Best regards,
> >> > Jingoo Han
> >> >
> >> >
> >> >>
> >> >> dp->reg_base = devm_request_and_ioremap(>dev, res);
> >> >> if (!dp->reg_base) {
> >> >> dev_err(>dev, "failed to ioremap\n");
> >> >> - ret = -ENOMEM;
> >> >> - goto err_clock;
> >> >> + return -ENOMEM;
> >> >> }
> >> >>
> >> >> dp->irq = platform_get_irq(pdev, 0);
> >> >> if (!dp->irq) {
> >> >> dev_err(>dev, "failed to get irq\n");
> >> >> - ret = -ENODEV;
> >> >> - goto err_clock;
> >> >> + return -ENODEV;
> >> >> }
> >> >>
> >> >> ret = devm_request_irq(>dev, dp->irq,
> >> >> exynos_dp_irq_handler, 0,
> >> >> "exynos-dp", dp);
> >> >> if (ret) {
> >> >> dev_err(>dev, "failed to request irq\n");
> >> >> - goto err_clock;
> >> >> + return ret;
> >> >> }
> >> >>
> >> >> dp->video_info = pdata->video_info;
> >> >> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct
> >> >> platform_device *pdev)
> >> >> ret = exynos_dp_detect_hpd(dp);
> >> >> if (ret) {
> >> >> dev_err(>dev, "unable to detect hpd\n");
> >> >> - goto err_clock;
> >> >> + return ret;
> >> >> }
> >> >>
> >> >> exynos_dp_handle_edid(dp);
> >> >> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct
> >> >> platform_device *pdev)
> >> >> dp->video_info->link_rate);
> >> >> if (ret) {
> >> >> dev_err(>dev, "unable to do link train\n");
> >> >> - goto err_clock;
> >> >> + return ret;
> >> >> }
> >> >>
> >> >> exynos_dp_enable_scramble(dp, 1);
> >> >> @@ -940,17 +933,12
[PATCH 4/5] Redocument some functions in android/logger.c
I will document the rest later if they remain unchanged
Normally, I would do them all at once, but I don't have the chance to do them
all at the moment
Signed-off-by: Cruz Julian Bishop
---
drivers/staging/android/logger.c | 90 +-
1 file changed, 60 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 1d5ed47..226d8b5 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -78,15 +78,20 @@ struct logger_reader {
size_t r_off;
};
-/* logger_offset - returns index 'n' into the log via (optimized) modulus */
+/**
+ * logger_offset() - returns index 'n' into the log via (optimized) modulus
+ * @log: The log being referenced
+ * @n: The index number being referenced
+ */
static size_t logger_offset(struct logger_log *log, size_t n)
{
return n & (log->size - 1);
}
-/*
- * file_get_log - Given a file structure, return the associated log
+/**
+ * file_get_log() - Given a file, return the associated log
+ * @file: The file being referenced
*
* This isn't aesthetic. We have several goals:
*
@@ -108,9 +113,11 @@ static inline struct logger_log *file_get_log(struct file
*file)
return file->private_data;
}
-/*
- * get_entry_len - Grabs the length of the payload of the next entry starting
- * from 'off'.
+/**
+ * get_entry_len() - Grabs the length of the payload of the entry starting
+ * at @off
+ * @log: The log being referenced
+ * @off: The offset to start counting at
*
* An entry length is 2 bytes (16 bits) in host endian order.
* In the log, the length does not include the size of the log entry structure.
@@ -134,9 +141,13 @@ static __u32 get_entry_len(struct logger_log *log, size_t
off)
return sizeof(struct logger_entry) + val;
}
-/*
- * do_read_log_to_user - reads exactly 'count' bytes from 'log' into the
- * user-space buffer 'buf'. Returns 'count' on success.
+/**
+ * do_read_log_to_user() - reads exactly @count bytes from @log into the
+ * user-space buffer @buf. Returns @count on success.
+ * @log: The log being read from
+ * @reader:The logger reader that reads from @log
+ * @buf: The user-space buffer being written into
+ * @count: The number of bytes being read
*
* Caller must hold log->mutex.
*/
@@ -169,8 +180,12 @@ static ssize_t do_read_log_to_user(struct logger_log *log,
return count;
}
-/*
- * logger_read - our log's read() method
+/**
+ * logger_read() - our log's read() method
+ * @file: The file being read from
+ * @buf: The user-space buffer being written into
+ * @count: The minimum number of bytes to be read
+ * @pos: Unused, posssibly the write position or offset in @buf
*
* Behavior:
*
@@ -241,11 +256,14 @@ out:
return ret;
}
-/*
- * get_next_entry - return the offset of the first valid entry at least 'len'
- * bytes after 'off'.
+/**
+ * get_next_entry() - return the offset of the first valid entry at least @len
+ * bytes after @off.
+ * @log: The log being read from
+ * @off: The offset / number of bytes to skip
+ * @len: The minimum number of bytes to read
*
- * Caller must hold log->mutex.
+ * Caller must hold @log->mutex.
*/
static size_t get_next_entry(struct logger_log *log, size_t off, size_t len)
{
@@ -260,19 +278,21 @@ static size_t get_next_entry(struct logger_log *log,
size_t off, size_t len)
return off;
}
-/*
- * is_between - is a < c < b, accounting for wrapping of a, b, and c
+/**
+ * is_between() - is @a < @c < @b, accounting for wrapping of @a, @b, and @c
*positions in the buffer
+ * @a: The starting position
+ * @b: The finishing position
+ * @c: The position being searched for
*
- * That is, if ab, check for c outside (not between) a and b
+ * That is, if @a < @b, check for @c between @a and @b
+ * and if @a > @b, check for @c outside (not between) @a and @b
*
* |--- a b |
* c^
*
* |x b - a x|
- *c^
- * orc^
+ *c^or c^
*/
static inline int is_between(size_t a, size_t b, size_t c)
{
@@ -289,13 +309,17 @@ static inline int is_between(size_t a, size_t b, size_t c)
return 0;
}
-/*
- * fix_up_readers - walk the list of all readers and "fix up" any who were
- * lapped by the writer; also do the same for the default "start head".
+/**
+ * fix_up_readers() - walk the list of all readers and "fix up" any who were
+ * lapped by the writer.
+ * @log: The log being referenced
+ * @len: The number of bytes to "pull" the reader forward by
+ *
+ * Also does the same for the default "start head".
* We do this by "pulling forward" the readers and start head to the first
* entry after the new write head.
*
- * The caller needs to hold log->mutex.
+ * The caller needs to hold
[PATCH 2/5] Complete documentation of logger_entry in android/logger.h
Previously, there were simply comments after each part - Now, it is completed
properly according to "Kernel doc"
Sorry in advance if I made any mistakes.
Signed-off-by: Cruz Julian Bishop
---
drivers/staging/android/logger.h | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/logger.h b/drivers/staging/android/logger.h
index 2cb06e9..9b929a8 100644
--- a/drivers/staging/android/logger.h
+++ b/drivers/staging/android/logger.h
@@ -20,14 +20,24 @@
#include
#include
+/**
+ * struct logger_entry - defines a single entry that is given to a logger
+ * @len: The length of the payload
+ * @__pad: Two bytes of padding that appear to be required
+ * @pid: The generating process' process ID
+ * @tid: The generating process' thread ID
+ * @sec: The number of seconds that have elapsed since the Epoch
+ * @nsec: The number of nanoseconds that have elapsed since @sec
+ * @msg: The message that is to be logged
+ */
struct logger_entry {
- __u16 len;/* length of the payload */
- __u16 __pad; /* no matter what, we get 2 bytes of padding */
- __s32 pid;/* generating process's pid */
- __s32 tid;/* generating process's tid */
- __s32 sec;/* seconds since Epoch */
- __s32 nsec; /* nanoseconds */
- charmsg[0]; /* the entry's payload */
+ __u16 len;
+ __u16 __pad;
+ __s32 pid;
+ __s32 tid;
+ __s32 sec;
+ __s32 nsec;
+ charmsg[0];
};
#define LOGGER_LOG_RADIO "log_radio" /* radio-related messages */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] Fixes a potential bug in android/logger.c
Previously, when calling is_between(a, b, c), the calculation was wrong.
It counted C as between A and B if C was equal to B, but not A.
Example of this are:
is_between(1, 10, 10) = 1 (Expected: 0)
is_between(1, 10, 1) = 0 (Expected: 0)
is_between(20, 10, 10) = 1 (Expected: 0)
And so on and so forth.
Obviously, ten is not a number between one and ten - only two to eight are, so
I made this patch :)
Signed-off-by: Cruz Julian Bishop
---
drivers/staging/android/logger.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 226d8b5..925df5c 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -298,11 +298,11 @@ static inline int is_between(size_t a, size_t b, size_t c)
{
if (a < b) {
/* is c between a and b? */
- if (a < c && c <= b)
+ if (a < c && c < b)
return 1;
} else {
/* is c outside of b through a? */
- if (c <= b || a < c)
+ if (c < b || a < c)
return 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/
[PATCH 3/5] Finish documentation of two structs in android/logger.c
Signed-off-by: Cruz Julian Bishop
---
drivers/staging/android/logger.c | 40 +-
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index f7b8237..1d5ed47 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -32,38 +32,50 @@
#include
-/*
+/**
* struct logger_log - represents a specific log, such as 'main' or 'radio'
+ * @buffer:The actual ring buffer
+ * @misc: The "misc" device representing the log
+ * @wq:The wait queue for @readers
+ * @readers: This log's readers
+ * @mutex: The mutex that protects the @buffer
+ * @w_off: The current write head offset
+ * @head: The head, or location that readers start reading at.
+ * @size: The size of the log
+ * @logs: The list of log channels
*
* This structure lives from module insertion until module removal, so it does
* not need additional reference counting. The structure is protected by the
* mutex 'mutex'.
*/
struct logger_log {
- unsigned char *buffer;/* the ring buffer itself */
- struct miscdevice misc; /* misc device representing the log */
- wait_queue_head_t wq; /* wait queue for readers */
- struct list_headreaders; /* this log's readers */
- struct mutexmutex; /* mutex protecting buffer */
- size_t w_off; /* current write head offset */
- size_t head; /* new readers start here */
- size_t size; /* size of the log */
- struct list_headlogs; /* list of log channels (myself)*/
+ unsigned char *buffer;
+ struct miscdevice misc;
+ wait_queue_head_t wq;
+ struct list_headreaders;
+ struct mutexmutex;
+ size_t w_off;
+ size_t head;
+ size_t size;
+ struct list_headlogs;
};
static LIST_HEAD(log_list);
-/*
+/**
* struct logger_reader - a logging device open for reading
+ * @log: The associated log
+ * @list: The associated entry in @logger_log's list
+ * @r_off: The current read head offset.
*
* This object lives from open to release, so we don't need additional
* reference counting. The structure is protected by log->mutex.
*/
struct logger_reader {
- struct logger_log *log; /* associated log */
- struct list_headlist; /* entry in logger_log's list */
- size_t r_off; /* current read head offset */
+ struct logger_log *log;
+ struct list_headlist;
+ size_t r_off;
};
/* logger_offset - returns index 'n' into the log via (optimized) modulus */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Fix comment/license formatting in android/ashmem.c
Signed-off-by: Cruz Julian Bishop --- drivers/staging/android/ashmem.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 69cf2db..94a740d 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -1,20 +1,20 @@ /* mm/ashmem.c -** -** Anonymous Shared Memory Subsystem, ashmem -** -** Copyright (C) 2008 Google, Inc. -** -** Robert Love -** -** 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. -*/ + * + * Anonymous Shared Memory Subsystem, ashmem + * + * Copyright (C) 2008 Google, Inc. + * + * Robert Love + * + * 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. + */ #define pr_fmt(fmt) "ashmem: " fmt -- 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 0/5] Android: Small documentation changes and a bug fix
Hi, This set of patches completes more documentation in android/logger.c, as well as fixing a bug there and a comment formatting issue in android/ashmem.c. Sorry if kernel-doc was not supposed to be applied to driver files - If it isn't, I'll be sure to remember that for next time. :) Cruz Julian Bishop (5): Fix comment/license formatting in android/ashmem.c Complete documentation of logger_entry in android/logger.h Finish documentation of two structs in android/logger.c Redocument some functions in android/logger.c Fixes a potential bug in android/logger.c drivers/staging/android/ashmem.c | 32 - drivers/staging/android/logger.c | 134 +- drivers/staging/android/logger.h | 24 +-- 3 files changed, 121 insertions(+), 69 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On 1 August 2012 10:00, Jingoo Han wrote:
> On Wednesday, August 01, 2012 1:00 PMSachin Kamat wrote:
>>
>> On 1 August 2012 04:51, Jingoo Han wrote:
>> > On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
>> >>
>> >> From: Damien Cassou
>> >>
>> >> The various devm_ functions allocate memory that is released when a driver
>> >> detaches. This patch uses these functions for data that is allocated in
>> >> the probe function of a platform device and is only freed in the remove
>> >> function.
>> >>
>> >> Signed-off-by: Damien Cassou
>> >>
>> >> ---
>> >> drivers/video/exynos/exynos_dp_core.c | 27 +++
>> >> 1 file changed, 7 insertions(+), 20 deletions(-)
>> >>
>> >> diff --git a/drivers/video/exynos/exynos_dp_core.c
>> >> b/drivers/video/exynos/exynos_dp_core.c
>> >> index c6c016a..00fe4f0 100644
>> >> --- a/drivers/video/exynos/exynos_dp_core.c
>> >> +++ b/drivers/video/exynos/exynos_dp_core.c
>> >> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct
>> >> platform_device *pdev)
>> >>
>> >> dp->dev = >dev;
>> >>
>> >> - dp->clock = clk_get(>dev, "dp");
>> >> + dp->clock = devm_clk_get(>dev, "dp");
>> >> if (IS_ERR(dp->clock)) {
>> >> dev_err(>dev, "failed to get clock\n");
>> >> return PTR_ERR(dp->clock);
>> >> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
>> >> platform_device *pdev)
>> >> clk_enable(dp->clock);
>> >>
>> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> >> - if (!res) {
>> >> - dev_err(>dev, "failed to get registers\n");
>> >> - ret = -EINVAL;
>> >> - goto err_clock;
>> >> - }
>> >
>> > Why do you remove this return check?
>> > If there is no reason, please, do it as follows:
>> >
>> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> > if (!res) {
>> > dev_err(>dev, "failed to get registers\n");
>> > - ret = -EINVAL;
>> > - goto err_clock;
>> > + return -EINVAL;
>> > }
>> >
>> >
>>
>> devm_request_and_ioremap function checks the validity of res. Hence
>> this check above is redundant and can be removed.
>
>
> I don't think so.
> Even though function called next checks the NULL value,
> for robustness, the return value of platform_get_resource() should be
> checked.
>
> It is possible that devm_request_and_ioremap() can be changed in the future,
> as request_mem_region() & ioremap() were changed to
> devm_request_and_ioremap().
They are not changed. They still exist. devm_request_and_ioremap() is
an additional function provided for device managed resources.
>
>
> Best regards,
> Jingoo Han
>
>
>>
>> Damien,
>> This patch only adds devm_clk_get() function. Hence you could make the
>> subject line more specific.
>>
>>
>>
>>
>> > Best regards,
>> > Jingoo Han
>> >
>> >
>> >>
>> >> dp->reg_base = devm_request_and_ioremap(>dev, res);
>> >> if (!dp->reg_base) {
>> >> dev_err(>dev, "failed to ioremap\n");
>> >> - ret = -ENOMEM;
>> >> - goto err_clock;
>> >> + return -ENOMEM;
>> >> }
>> >>
>> >> dp->irq = platform_get_irq(pdev, 0);
>> >> if (!dp->irq) {
>> >> dev_err(>dev, "failed to get irq\n");
>> >> - ret = -ENODEV;
>> >> - goto err_clock;
>> >> + return -ENODEV;
>> >> }
>> >>
>> >> ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler,
>> >> 0,
>> >> "exynos-dp", dp);
>> >> if (ret) {
>> >> dev_err(>dev, "failed to request irq\n");
>> >> - goto err_clock;
>> >> + return ret;
>> >> }
>> >>
>> >> dp->video_info = pdata->video_info;
>> >> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct
>> >> platform_device *pdev)
>> >> ret = exynos_dp_detect_hpd(dp);
>> >> if (ret) {
>> >> dev_err(>dev, "unable to detect hpd\n");
>> >> - goto err_clock;
>> >> + return ret;
>> >> }
>> >>
>> >> exynos_dp_handle_edid(dp);
>> >> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct
>> >> platform_device *pdev)
>> >> dp->video_info->link_rate);
>> >> if (ret) {
>> >> dev_err(>dev, "unable to do link train\n");
>> >> - goto err_clock;
>> >> + return ret;
>> >> }
>> >>
>> >> exynos_dp_enable_scramble(dp, 1);
>> >> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct
>> >> platform_device *pdev)
>> >> ret = exynos_dp_config_video(dp, dp->video_info);
>> >> if (ret) {
>> >> dev_err(>dev, "unable to config video\n");
>> >> - goto err_clock;
>> >> + return ret;
>> >> }
>> >>
>> >> platform_set_drvdata(pdev, dp);
>> >>
>> >> return 0;
>> >> -
>> >> -err_clock:
Re: [PATCH v2] powerpc/crypto: fix defconfig break
Seth Jennings wrote: > As part of the Kconfig rework for drivers/crypto/nx, the meaning of > CONFIG_CRYPTO_DEV_NX was changed. At the same time this commit was > heading upstream > > fd297b3a7302ab866306f53c1fd1e97b083fe83e > powerpc: Enable pseries hardware RNG and crypto module > > still used the old meaning, set CONFIG_CRYPTO_DEV_NX=m when it > is now a bool in the Kconfig. This patch repairs the break. > > Reported-by: Michael Neuling > Signed-off-by: Seth Jennings Works, thanks. Tested-by: Michael Neuling > --- > This patch is based on Linus master which already contains > the commit above. Please apply this patch before my patchset > (powerpc/crypto: IBM Power7+ in-Nest compression support) to > avoid the defconfig break. > > arch/powerpc/configs/ppc64_defconfig |3 ++- > arch/powerpc/configs/pseries_defconfig |3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/configs/ppc64_defconfig > b/arch/powerpc/configs/ppc64_defconfig > index db27c82..2d9150a1 100644 > --- a/arch/powerpc/configs/ppc64_defconfig > +++ b/arch/powerpc/configs/ppc64_defconfig > @@ -487,7 +487,8 @@ CONFIG_CRYPTO_TWOFISH=m > CONFIG_CRYPTO_LZO=m > # CONFIG_CRYPTO_ANSI_CPRNG is not set > CONFIG_CRYPTO_HW=y > -CONFIG_CRYPTO_DEV_NX=m > +CONFIG_CRYPTO_DEV_NX=y > +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m > CONFIG_VIRTUALIZATION=y > CONFIG_KVM_BOOK3S_64=m > CONFIG_KVM_BOOK3S_64_HV=y > diff --git a/arch/powerpc/configs/pseries_defconfig > b/arch/powerpc/configs/pseries_defconfig > index 1f65b3c..9f4a936 100644 > --- a/arch/powerpc/configs/pseries_defconfig > +++ b/arch/powerpc/configs/pseries_defconfig > @@ -369,7 +369,8 @@ CONFIG_CRYPTO_TWOFISH=m > CONFIG_CRYPTO_LZO=m > # CONFIG_CRYPTO_ANSI_CPRNG is not set > CONFIG_CRYPTO_HW=y > -CONFIG_CRYPTO_DEV_NX=m > +CONFIG_CRYPTO_DEV_NX=y > +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m > CONFIG_VIRTUALIZATION=y > CONFIG_KVM_BOOK3S_64=m > CONFIG_KVM_BOOK3S_64_HV=y > -- > 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 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On Wednesday, August 01, 2012 1:00 PMSachin Kamat wrote:
>
> On 1 August 2012 04:51, Jingoo Han wrote:
> > On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
> >>
> >> From: Damien Cassou
> >>
> >> The various devm_ functions allocate memory that is released when a driver
> >> detaches. This patch uses these functions for data that is allocated in
> >> the probe function of a platform device and is only freed in the remove
> >> function.
> >>
> >> Signed-off-by: Damien Cassou
> >>
> >> ---
> >> drivers/video/exynos/exynos_dp_core.c | 27 +++
> >> 1 file changed, 7 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/video/exynos/exynos_dp_core.c
> >> b/drivers/video/exynos/exynos_dp_core.c
> >> index c6c016a..00fe4f0 100644
> >> --- a/drivers/video/exynos/exynos_dp_core.c
> >> +++ b/drivers/video/exynos/exynos_dp_core.c
> >> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >>
> >> dp->dev = >dev;
> >>
> >> - dp->clock = clk_get(>dev, "dp");
> >> + dp->clock = devm_clk_get(>dev, "dp");
> >> if (IS_ERR(dp->clock)) {
> >> dev_err(>dev, "failed to get clock\n");
> >> return PTR_ERR(dp->clock);
> >> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> clk_enable(dp->clock);
> >>
> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> - if (!res) {
> >> - dev_err(>dev, "failed to get registers\n");
> >> - ret = -EINVAL;
> >> - goto err_clock;
> >> - }
> >
> > Why do you remove this return check?
> > If there is no reason, please, do it as follows:
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!res) {
> > dev_err(>dev, "failed to get registers\n");
> > - ret = -EINVAL;
> > - goto err_clock;
> > + return -EINVAL;
> > }
> >
> >
>
> devm_request_and_ioremap function checks the validity of res. Hence
> this check above is redundant and can be removed.
I don't think so.
Even though function called next checks the NULL value,
for robustness, the return value of platform_get_resource() should be
checked.
It is possible that devm_request_and_ioremap() can be changed in the future,
as request_mem_region() & ioremap() were changed to devm_request_and_ioremap().
Best regards,
Jingoo Han
>
> Damien,
> This patch only adds devm_clk_get() function. Hence you could make the
> subject line more specific.
>
>
>
>
> > Best regards,
> > Jingoo Han
> >
> >
> >>
> >> dp->reg_base = devm_request_and_ioremap(>dev, res);
> >> if (!dp->reg_base) {
> >> dev_err(>dev, "failed to ioremap\n");
> >> - ret = -ENOMEM;
> >> - goto err_clock;
> >> + return -ENOMEM;
> >> }
> >>
> >> dp->irq = platform_get_irq(pdev, 0);
> >> if (!dp->irq) {
> >> dev_err(>dev, "failed to get irq\n");
> >> - ret = -ENODEV;
> >> - goto err_clock;
> >> + return -ENODEV;
> >> }
> >>
> >> ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler, 0,
> >> "exynos-dp", dp);
> >> if (ret) {
> >> dev_err(>dev, "failed to request irq\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> dp->video_info = pdata->video_info;
> >> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> ret = exynos_dp_detect_hpd(dp);
> >> if (ret) {
> >> dev_err(>dev, "unable to detect hpd\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> exynos_dp_handle_edid(dp);
> >> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> dp->video_info->link_rate);
> >> if (ret) {
> >> dev_err(>dev, "unable to do link train\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> exynos_dp_enable_scramble(dp, 1);
> >> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct
> >> platform_device *pdev)
> >> ret = exynos_dp_config_video(dp, dp->video_info);
> >> if (ret) {
> >> dev_err(>dev, "unable to config video\n");
> >> - goto err_clock;
> >> + return ret;
> >> }
> >>
> >> platform_set_drvdata(pdev, dp);
> >>
> >> return 0;
> >> -
> >> -err_clock:
> >> - clk_put(dp->clock);
> >> -
> >> - return ret;
> >> }
> >>
> >> static int __devexit exynos_dp_remove(struct platform_device *pdev)
> >> @@ -962,7 +950,6 @@ static int __devexit exynos_dp_remove(struct
> >> platform_device *pdev)
> >> pdata->phy_exit();
> >>
> >> clk_disable(dp->clock);
> >> -
[PATCH v2] powerpc/crypto: fix defconfig break
As part of the Kconfig rework for drivers/crypto/nx, the meaning of CONFIG_CRYPTO_DEV_NX was changed. At the same time this commit was heading upstream fd297b3a7302ab866306f53c1fd1e97b083fe83e powerpc: Enable pseries hardware RNG and crypto module still used the old meaning, set CONFIG_CRYPTO_DEV_NX=m when it is now a bool in the Kconfig. This patch repairs the break. Reported-by: Michael Neuling Signed-off-by: Seth Jennings --- This patch is based on Linus master which already contains the commit above. Please apply this patch before my patchset (powerpc/crypto: IBM Power7+ in-Nest compression support) to avoid the defconfig break. arch/powerpc/configs/ppc64_defconfig |3 ++- arch/powerpc/configs/pseries_defconfig |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index db27c82..2d9150a1 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -487,7 +487,8 @@ CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y -CONFIG_CRYPTO_DEV_NX=m +CONFIG_CRYPTO_DEV_NX=y +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m CONFIG_VIRTUALIZATION=y CONFIG_KVM_BOOK3S_64=m CONFIG_KVM_BOOK3S_64_HV=y diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index 1f65b3c..9f4a936 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -369,7 +369,8 @@ CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y -CONFIG_CRYPTO_DEV_NX=m +CONFIG_CRYPTO_DEV_NX=y +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m CONFIG_VIRTUALIZATION=y CONFIG_KVM_BOOK3S_64=m CONFIG_KVM_BOOK3S_64_HV=y -- 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: [PATCHv8 00/13] perf: Add backtrace post dwarf unwind
On Fri, Jul 27, 2012 at 2:23 PM, Jiri Olsa wrote: > hi, > patches available also as tarball in here: > http://people.redhat.com/~jolsa/perf_post_unwind_v8.tar.bz2 > > v8 changes: >- patch 2 - added dump registers ABI specification as suggested >by Stephane >- v7 patches 9,10,16,17 already in > Patches 4, 7 do not apply cleanly for me on tip-master @ commit 2a7d7ce when I use the tarball version of the patchset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On 1 August 2012 04:51, Jingoo Han wrote:
> On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
>>
>> From: Damien Cassou
>>
>> The various devm_ functions allocate memory that is released when a driver
>> detaches. This patch uses these functions for data that is allocated in
>> the probe function of a platform device and is only freed in the remove
>> function.
>>
>> Signed-off-by: Damien Cassou
>>
>> ---
>> drivers/video/exynos/exynos_dp_core.c | 27 +++
>> 1 file changed, 7 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/video/exynos/exynos_dp_core.c
>> b/drivers/video/exynos/exynos_dp_core.c
>> index c6c016a..00fe4f0 100644
>> --- a/drivers/video/exynos/exynos_dp_core.c
>> +++ b/drivers/video/exynos/exynos_dp_core.c
>> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct
>> platform_device *pdev)
>>
>> dp->dev = >dev;
>>
>> - dp->clock = clk_get(>dev, "dp");
>> + dp->clock = devm_clk_get(>dev, "dp");
>> if (IS_ERR(dp->clock)) {
>> dev_err(>dev, "failed to get clock\n");
>> return PTR_ERR(dp->clock);
>> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
>> platform_device *pdev)
>> clk_enable(dp->clock);
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> - if (!res) {
>> - dev_err(>dev, "failed to get registers\n");
>> - ret = -EINVAL;
>> - goto err_clock;
>> - }
>
> Why do you remove this return check?
> If there is no reason, please, do it as follows:
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(>dev, "failed to get registers\n");
> - ret = -EINVAL;
> - goto err_clock;
> + return -EINVAL;
> }
>
>
devm_request_and_ioremap function checks the validity of res. Hence
this check above is redundant and can be removed.
Damien,
This patch only adds devm_clk_get() function. Hence you could make the
subject line more specific.
> Best regards,
> Jingoo Han
>
>
>>
>> dp->reg_base = devm_request_and_ioremap(>dev, res);
>> if (!dp->reg_base) {
>> dev_err(>dev, "failed to ioremap\n");
>> - ret = -ENOMEM;
>> - goto err_clock;
>> + return -ENOMEM;
>> }
>>
>> dp->irq = platform_get_irq(pdev, 0);
>> if (!dp->irq) {
>> dev_err(>dev, "failed to get irq\n");
>> - ret = -ENODEV;
>> - goto err_clock;
>> + return -ENODEV;
>> }
>>
>> ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler, 0,
>> "exynos-dp", dp);
>> if (ret) {
>> dev_err(>dev, "failed to request irq\n");
>> - goto err_clock;
>> + return ret;
>> }
>>
>> dp->video_info = pdata->video_info;
>> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct
>> platform_device *pdev)
>> ret = exynos_dp_detect_hpd(dp);
>> if (ret) {
>> dev_err(>dev, "unable to detect hpd\n");
>> - goto err_clock;
>> + return ret;
>> }
>>
>> exynos_dp_handle_edid(dp);
>> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct
>> platform_device *pdev)
>> dp->video_info->link_rate);
>> if (ret) {
>> dev_err(>dev, "unable to do link train\n");
>> - goto err_clock;
>> + return ret;
>> }
>>
>> exynos_dp_enable_scramble(dp, 1);
>> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct
>> platform_device *pdev)
>> ret = exynos_dp_config_video(dp, dp->video_info);
>> if (ret) {
>> dev_err(>dev, "unable to config video\n");
>> - goto err_clock;
>> + return ret;
>> }
>>
>> platform_set_drvdata(pdev, dp);
>>
>> return 0;
>> -
>> -err_clock:
>> - clk_put(dp->clock);
>> -
>> - return ret;
>> }
>>
>> static int __devexit exynos_dp_remove(struct platform_device *pdev)
>> @@ -962,7 +950,6 @@ static int __devexit exynos_dp_remove(struct
>> platform_device *pdev)
>> pdata->phy_exit();
>>
>> clk_disable(dp->clock);
>> - clk_put(dp->clock);
>>
>> return 0;
>> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With warm regards,
Sachin
--
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] OLPC platform updates for 3.6
Hi Linus,
These move the OLPC Embedded Controller driver out of arch/x86/platform and
into drivers/platform/olpc. OLPC machines are now ARM-based (which means lots
of x86 and ARM changes), but are typically pretty self-contained.. so it makes
more sense to go through a separate OLPC tree after getting the appropriate
review/ACKs.
The following changes since commit 08843b79fb35d33859e0f8f11a7318341076e4d1:
Merge branch 'nfsd-next' of git://linux-nfs.org/~bfields/linux (2012-07-31
14:42:28 -0700)
are available in the git repository at:
git://dev.laptop.org/users/dilinger/linux-olpc/ for-linus-3.6
Andres Salomon (9):
Platform: OLPC: add a stub to drivers/platform/ for the OLPC EC driver
drivers: OLPC: update various drivers to include olpc-ec.h
Platform: OLPC: allow EC cmd to be overridden, and create a workqueue to
call it
Platform: OLPC: turn EC driver into a platform_driver
Platform: OLPC: add a suspended flag to the EC driver
x86: OLPC: switch over to using new EC driver on x86
Platform: OLPC: move debugfs support from x86 EC driver
Platform: OLPC: move global variables into priv struct
x86: OLPC: move s/r-related EC cmds to EC driver
arch/x86/include/asm/olpc.h| 19 --
arch/x86/platform/olpc/olpc-xo1-pm.c | 16 +--
arch/x86/platform/olpc/olpc-xo1-sci.c |1 +
arch/x86/platform/olpc/olpc-xo15-sci.c |1 +
arch/x86/platform/olpc/olpc.c | 190 ++
drivers/net/wireless/libertas/if_usb.c |1 +
drivers/platform/Makefile |1 +
drivers/platform/olpc/Makefile |4 +
drivers/platform/olpc/olpc-ec.c| 336
drivers/platform/x86/xo1-rfkill.c |3 +-
drivers/power/olpc_battery.c |1 +
drivers/staging/olpc_dcon/olpc_dcon.c |1 +
include/linux/olpc-ec.h| 41
13 files changed, 451 insertions(+), 164 deletions(-)
create mode 100644 drivers/platform/olpc/Makefile
create mode 100644 drivers/platform/olpc/olpc-ec.c
create mode 100644 include/linux/olpc-ec.h
diff --git a/arch/x86/include/asm/olpc.h b/arch/x86/include/asm/olpc.h
index 87bdbca..72f9adf6 100644
--- a/arch/x86/include/asm/olpc.h
+++ b/arch/x86/include/asm/olpc.h
@@ -100,25 +100,6 @@ extern void olpc_xo1_pm_wakeup_clear(u16 value);
extern int pci_olpc_init(void);
-/* EC related functions */
-
-extern int olpc_ec_cmd(unsigned char cmd, unsigned char *inbuf, size_t inlen,
- unsigned char *outbuf, size_t outlen);
-
-/* EC commands */
-
-#define EC_FIRMWARE_REV0x08
-#define EC_WRITE_SCI_MASK 0x1b
-#define EC_WAKE_UP_WLAN0x24
-#define EC_WLAN_LEAVE_RESET0x25
-#define EC_READ_EB_MODE0x2a
-#define EC_SET_SCI_INHIBIT 0x32
-#define EC_SET_SCI_INHIBIT_RELEASE 0x34
-#define EC_WLAN_ENTER_RESET0x35
-#define EC_WRITE_EXT_SCI_MASK 0x38
-#define EC_SCI_QUERY 0x84
-#define EC_EXT_SCI_QUERY 0x85
-
/* SCI source values */
#define EC_SCI_SRC_EMPTY 0x00
diff --git a/arch/x86/platform/olpc/olpc-xo1-pm.c
b/arch/x86/platform/olpc/olpc-xo1-pm.c
index 0ce8616c..d75582d 100644
--- a/arch/x86/platform/olpc/olpc-xo1-pm.c
+++ b/arch/x86/platform/olpc/olpc-xo1-pm.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -51,16 +52,11 @@ EXPORT_SYMBOL_GPL(olpc_xo1_pm_wakeup_clear);
static int xo1_power_state_enter(suspend_state_t pm_state)
{
unsigned long saved_sci_mask;
- int r;
/* Only STR is supported */
if (pm_state != PM_SUSPEND_MEM)
return -EINVAL;
- r = olpc_ec_cmd(EC_SET_SCI_INHIBIT, NULL, 0, NULL, 0);
- if (r)
- return r;
-
/*
* Save SCI mask (this gets lost since PM1_EN is used as a mask for
* wakeup events, which is not necessarily the same event set)
@@ -76,16 +72,6 @@ static int xo1_power_state_enter(suspend_state_t pm_state)
/* Restore SCI mask (using dword access to CS5536_PM1_EN) */
outl(saved_sci_mask, acpi_base + CS5536_PM1_STS);
- /* Tell the EC to stop inhibiting SCIs */
- olpc_ec_cmd(EC_SET_SCI_INHIBIT_RELEASE, NULL, 0, NULL, 0);
-
- /*
-* Tell the wireless module to restart USB communication.
-* Must be done twice.
-*/
- olpc_ec_cmd(EC_WAKE_UP_WLAN, NULL, 0, NULL, 0);
- olpc_ec_cmd(EC_WAKE_UP_WLAN, NULL, 0, NULL, 0);
-
return 0;
}
diff --git a/arch/x86/platform/olpc/olpc-xo1-sci.c
b/arch/x86/platform/olpc/olpc-xo1-sci.c
index 04b8c73..63d4aa4 100644
--- a/arch/x86/platform/olpc/olpc-xo1-sci.c
+++ b/arch/x86/platform/olpc/olpc-xo1-sci.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/x86/platform/olpc/olpc-xo15-sci.c
b/arch/x86/platform/olpc/olpc-xo15-sci.c
index
[GIT PULL] irqdomain changes for v3.6
Hi Linus, Here are the irqdomain changes I've got queued up. I held off sending this pull request due to a late discovered bug and I wanted to give it some extra time in linux-next. All should be good now. Please pull. g. The following changes since commit bdc0077af574800d24318b6945cf2344e8dbb050: Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2012-07-24 18:11:22 -0700) are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 tags/irqdomain-for-linus for you to fetch changes up to f5a1ad057e6da5d0fc9c5677ff44797d193d3e62: irqdomain: Improve diagnostics when a domain mapping fails (2012-07-24 22:37:30 -0600) irqdomain changes for Linux v3.6 Round of refactoring and enhancements to irq_domain infrastructure. This series starts the process of simplifying irqdomain. The ultimate goal is to merge LEGACY, LINEAR and TREE mappings into a single system, but had to back off from that after some last minute bugs. Instead it mainly reorganizes the code and ensures that the reverse map gets populated when the irq is mapped instead of the first time it is looked up. Merging of the irq_domain types is deferred to v3.7 In other news, this series adds helpers for creating static mappings on a linear or tree mapping. Dong Aisheng (1): irq_domain: correct a minor wrong comment for linear revmap Grant Likely (11): devicetree: add helper inline for retrieving a node's full name irqdomain: Remove unnecessary test for IRQ_DOMAIN_MAP_LEGACY irqdomain: Make ops->map hook optional Merge tag 'v3.5-rc6' into irqdomain/next irqdomain: Split disassociating code into separate function irqdomain: Always update revmap when setting up a virq irqdomain: Support for static IRQ mapping and association. irqdomain: Eliminate dedicated radix lookup functions irqdomain: Fix irq_create_direct_mapping() to test irq_domain type. Merge remote-tracking branch 'origin' into irqdomain/next irqdomain: eliminate slow-path revmap lookups Mark Brown (2): irq_domain: Standardise legacy/linear domain selection irqdomain: Improve diagnostics when a domain mapping fails Paul Mundt (1): irqdomain: Simple NUMA awareness. Documentation/IRQ-domain.txt |5 + arch/powerpc/sysdev/xics/icp-hv.c |2 +- arch/powerpc/sysdev/xics/icp-native.c |2 +- arch/powerpc/sysdev/xics/xics-common.c |3 - include/linux/irqdomain.h | 28 ++- include/linux/of.h | 15 +- kernel/irq/irqdomain.c | 362 ++-- 7 files changed, 248 insertions(+), 169 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] KVM: Only print vcpu_unimpl when DEBUG is set
On Thu, Jul 26, 2012 at 02:22:48PM +0200, Markus Trippelsdorf wrote:
> Every time I start qemu-kvm on my system the following line is added to
> the syslog:
>
> vcpu0 unhandled rdmsr: 0xc0010001
>
> AFAICS all calls to vcpu_unimpl only contain debugging info with little
> or no value for the end user.
>
> Wouldn't something like the following patch make sense?
>
> Signed-off-by: Markus Trippelsdorf
It could be useful for debugging (but then lots of other things could).
Anyone has a use for this?
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index b70b48b..6bd816f 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -321,7 +321,7 @@ struct kvm {
> #define kvm_debug(fmt, ...) \
> pr_debug("kvm [%i]: " fmt, task_pid_nr(current), ## __VA_ARGS__)
> #define kvm_pr_unimpl(fmt, ...) \
> - pr_err_ratelimited("kvm [%i]: " fmt, \
> + pr_debug_ratelimited("kvm [%i]: " fmt, \
> task_tgid_nr(current), ## __VA_ARGS__)
>
> /* The guest did something we don't support. */
>
> --
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RAID extremely slow
Kevin Ross wrote:
On 07/27/2012 09:45 PM, Grant Coady wrote:
On Fri, 27 Jul 2012 14:45:18 -0700, you wrote:
On 07/27/2012 12:08 PM, Bill Davidsen wrote:
Have you set the io scheduler to deadline on all members of the array?
That's kind of "job one" on older kernels.
I have not, thanks for the tip, I'll look into that now.
Plus I disable the on-drive queuing (NCQ) during startup, right now
I don't have benchmarks to show the difference. This on a six by 1TB
drive RAID6 array I built over a year ago on Slackware64-13.37:
# cat /etc/rc.d/rc.local
...
# turn off NCQ on the RAID drives by adjusting queue depth to 1
n=1
echo "rc.local: Disable RAID drives' NCQ"
for d in a b c d e f
do
echo " set NCQ depth to $n on sd${d}"
echo $n> /sys/block/sd${d}/device/queue_depth
done
...
Maybe you could try that? See if it makes a difference. My drives
are Seagate.
Grant.
Does disabling NCQ improve performance?
Does for me!
The suggestion to use kernel 3.4.6 has been working quite well so far,
hopefully that fixes the problem. I'll know for sure in a few more days...
Thanks!
-- Kevin
--
Bill Davidsen
We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination. -me, 2010
--
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] Documentation/kvm : Add documentation on Hypercalls
On Tue, Jul 24, 2012 at 02:23:59PM +0530, Raghavendra K T wrote: > From: Raghavendra K T > > Thanks Alex for KVM_HC_FEATURES inputs and Jan for VAPIC_POLL_IRQ, > and Peter (HPA) for suggesting hypercall ABI addition. > > Signed-off-by: Raghavendra K T > --- > Please have a closer look at Hypercall ABI newly added > > Changes since last post: > - Added hypercall ABI (Peter) > - made KVM_HC_VAPIC_POLL_IRQ active explicitly (Randy) > > TODO: We need to add history details of each hypercall as suggested by HPA, > which I could not trace easily. Hope it is easy for hypercall authors > > Documentation/virtual/hypercalls.txt | 71 > ++ > 1 files changed, 71 insertions(+), 0 deletions(-) > create mode 100644 Documentation/virtual/hypercalls.txt > > diff --git a/Documentation/virtual/hypercalls.txt > b/Documentation/virtual/hypercalls.txt > new file mode 100644 > index 000..caffc08 > --- /dev/null > +++ b/Documentation/virtual/hypercalls.txt > @@ -0,0 +1,71 @@ > +Hypercall ABI: > += > +A brief look at calling conventions of X86, S390 and PPC > +X86: > + KVM Hypercalls have a three-byte sequence of either the vmrun or the vmmrun > + instruction. The hypervisor can replace it with instructions that are > + guaranteed to be supported. vmcall. > + > + Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively. > + The hypercall number should be placed in rax and the return value will be > + placed in rax. No other registers will be clobbered unless explicitly > stated > + by the particular hypercall. It depends on the hypercall. It happens that current hypercalls use the four registers, but its not an ABI (hyper-v hypercalls uses r8, for example). -- 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] Fix firmware installation for images w/o subdirs
On 31.07.2012 22:59, s...@shealevy.com wrote: On some setups (probably due to too new a GNU Make), firmware installation fails with *** No rule to make target `lib/firmware/./', needed by `lib/firmware/.fw'. Stop. when a file in the top-level firmware/ directory is needed. Original patch idea by Denys Dmytriyenko, see http://permalink.gmane.org/gmane.linux.embedded.yocto.meta-ti/27 Signed-off-by: Shea Levy --- scripts/Makefile.fwinst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Whoops, sorry for the double post. -- 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 firmware installation for images w/o subdirs
On some setups (probably due to too new a GNU Make), firmware installation fails with *** No rule to make target `lib/firmware/./', needed by `lib/firmware/.fw'. Stop. when a file in the top-level firmware/ directory is needed. Original patch idea by Denys Dmytriyenko, see http://permalink.gmane.org/gmane.linux.embedded.yocto.meta-ti/27 Signed-off-by: Shea Levy --- scripts/Makefile.fwinst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst index 6bf8e87..4d908d1 100644 --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -27,7 +27,7 @@ endif installed-mod-fw := $(addprefix $(INSTALL_FW_PATH)/,$(mod-fw)) installed-fw := $(addprefix $(INSTALL_FW_PATH)/,$(fw-shipped-all)) -installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/. +installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/./ # Workaround for make < 3.81, where .SECONDEXPANSION doesn't work. PHONY += $(INSTALL_FW_PATH)/$$(%) install-all-dirs
[PATCH] Fix firmware installation for images w/o subdirs
On some setups (probably due to too new a GNU Make), firmware installation fails with *** No rule to make target `lib/firmware/./', needed by `lib/firmware/.fw'. Stop. when a file in the top-level firmware/ directory is needed. Original patch idea by Denys Dmytriyenko, see http://permalink.gmane.org/gmane.linux.embedded.yocto.meta-ti/27 Signed-off-by: Shea Levy --- scripts/Makefile.fwinst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst index 6bf8e87..4d908d1 100644 --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -27,7 +27,7 @@ endif installed-mod-fw := $(addprefix $(INSTALL_FW_PATH)/,$(mod-fw)) installed-fw := $(addprefix $(INSTALL_FW_PATH)/,$(fw-shipped-all)) -installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/. +installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/./ # Workaround for make < 3.81, where .SECONDEXPANSION doesn't work. PHONY += $(INSTALL_FW_PATH)/$$(%) install-all-dirs
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 07/31/2012 07:19 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
On 07/30/2012 08:33 PM, Thierry Reding wrote:
+You will need an instance of power_seq_resources to keep track of the resources
+that are already allocated. On success, the function returns a devm allocated
+resolved sequence that is ready to be passed to power_seq_run(). In case of
+failure, and error code is returned.
I don't quite understand why the struct power_seq_resources is needed.
Can this not be stored within power_seq?
power_seq_resources serves two purposes:
1) When parsing sequences, it keeps track of the resources we have
already allocated to avoid getting the same resource twice
2) On cleanup, it cleans the resources that needs to be freed (i.e.
those that are not devm-handled).
2) can certainly be removed either by enforcing use of devm, or by
doing reference counting. 1) seems more difficult to avoid - we need
to keep track of the resources we already own between calls to
power_seq_build(). I'd certainly be glad to remove that structure
from public view and simplify the code if that is possible though.
I still don't see the problem. Managing the resources should be part of
the power_seq core and shouldn't be visible to users. Maybe what you are
worried about is that you may need the same resource both for a power-up
and a power-down sequence? I can see how that would require a global
list of resources.
Yes, that is precisely my concern. Sorry for not stating that more clearly.
However I still think it would be easier to encapsulate that completely.
Maybe another level of abstraction is required. You could for example
add another type to encapsulate several power sequences and that could
keep a list of used resources. I can't think of a good name, but maybe
the following DT snippet clarifies what I mean:
power-sequences {
#address-cells = <1>;
#size-cells = <0>;
sequence@0 {
name = "up";
#address-cells = <1>;
#size-cells = <0>;
step@0 {
...
};
...
};
sequence@1 {
name = "down";
#address-cells = <1>;
#size-cells = <0>;
step@0 {
...
};
...
};
};
If you add a name property like this, you could extend the API to
support running a named sequence:
power_seq_run(seq, "up");
...
power_seq_run(seq, "down);
Mmm, that's something to consider. Forcing power sequences to be grouped
within a "power-sequences" node would also make parsing easier from the
driver side since it would not have to explicitly parse every sequence.
We could even imagine some tighter integration with the device subsystem
to automatically run specifically-named sequences during suspend/resume.
But maybe I'm thinking too much here.
Also, is there some way we can make the id property for GPIOs not
require the -gpio suffix? If the resource type is already GPIO, then it
seems redundant to add -gpio to the ID.
There is unfortunately an inconsistency between the way regulators
and GPIOs are gotten by name. regulator_get(id) will expect to find
a property named "id-supply", while gpio_request_one(id) expects a
property named exactly "id". To workaround this we could sprintf the
correct property name from a non-suffixed property name within the
driver, but I think this actually speaks more in favor of having
phandles directly into the sequences.
Yes, if it can be made to work by specifying the phandle directly that
is certainly better.
Let's do that then - as for the PWM issue I had, let's address that by
clearly stating in the documentation that phandles referring to a same
device *must* be identical.
+ if (!seq) return 0;
I don't think this is acceptable according to the coding style. Also,
perhaps returning -EINVAL would be more meaningful?
I neglected running checkpatch before submitting, apologies for
that. The return value seems correct to me, a NULL sequence has no
effect.
But seq == NULL should never happen anyway, right?
It could if you are parsing a NULL node. It seems safe to me to consider
that a NULL sequence is an empty sequence, but if I go for your solution
involving another data structure to encapsulate the sequence, then this
might change.
Perhaps this should check for POWER_SEQ_STOP instead?
There is no resource for POWER_SEQ_STOP - therefore, a NULL resource
is used instead.
Still, you use POWER_SEQ_STOP as an explicit sentinel to mark the end of
a sequence, so intuitively I'd be looking for that as a stop
Re: [PATCH -alternative] mm: hugetlbfs: Close race during teardown of hugetlbfs shared page tables V2 (resend)
On 07/31/2012 04:06 PM, Michal Hocko wrote: On Tue 31-07-12 13:49:21, Larry Woodman wrote: On 07/31/2012 08:46 AM, Mel Gorman wrote: Fundamentally I think the problem is that we are not correctly detecting that page table sharing took place during huge_pte_alloc(). This patch is longer and makes an API change but if I'm right, it addresses the underlying problem. The first VM_MAYSHARE patch is still necessary but would you mind testing this on top please? Hi Mel, yes this does work just fine. It ran for hours without a panic so I'll Ack this one if you send it to the list. Hi Larry, thanks for testing! I have a different patch which tries to address this very same issue. I am not saying it is better or that it should be merged instead of Mel's one but I would be really happy if you could give it a try. We can discuss (dis)advantages of both approaches later. Thanks! Hi Michal, the system hung when I tested this patch on top of the latest 3.5 kernel. I wont have AltSysrq access to the system until tomorrow AM. I'll retry this kernel and get AltSysrq output and let you know whats happening in the morning. Larry --- From 8cbf3bd27125fc0a2a46cd5b1085d9e63f9c01fd Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Tue, 31 Jul 2012 15:00:26 +0200 Subject: [PATCH] mm: hugetlbfs: Correctly populate shared pmd Each page mapped in a processes address space must be correctly accounted for in _mapcount. Normally the rules for this are straight-forward but hugetlbfs page table sharing is different. The page table pages at the PMD level are reference counted while the mapcount remains the same. If this accounting is wrong, it causes bugs like this one reported by Larry Woodman [ 1106.156569] [ cut here ] [ 1106.161731] kernel BUG at mm/filemap.c:135! [ 1106.166395] invalid opcode: [#1] SMP [ 1106.170975] CPU 22 [ 1106.173115] Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi] [ 1106.201770] [ 1106.203426] Pid: 18001, comm: mpitest Tainted: GW3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2 [ 1106.213822] RIP: 0010:[] [] __delete_from_page_cache+0x15d/0x170 [ 1106.224117] RSP: 0018:880428973b88 EFLAGS: 00010002 [ 1106.230032] RAX: 0001 RBX: ea0006b8 RCX: ffb0 [ 1106.237979] RDX: 00016df1 RSI: 0009 RDI: 88043ffd9e00 [ 1106.245927] RBP: 880428973b98 R08: 0050 R09: 0003 [ 1106.253876] R10: 000d R11: R12: 880428708150 [ 1106.261826] R13: 880428708150 R14: R15: ea0006b8 [ 1106.269780] FS: () GS:88042fd6() knlGS: [ 1106.278794] CS: 0010 DS: ES: CR0: 80050033 [ 1106.285193] CR2: 003a1d38c4a8 CR3: 0187d000 CR4: 000406e0 [ 1106.293149] DR0: DR1: DR2: [ 1106.301097] DR3: DR6: 0ff0 DR7: 0400 [ 1106.309046] Process mpitest (pid: 18001, threadinfo 880428972000, task 880428b5cc20) [ 1106.318447] Stack: [ 1106.320690] ea0006b8 880428973bc8 8112d040 [ 1106.328958] 880428973bc8 02ab 02a0 880428973c18 [ 1106.337234] 880428973cc8 8125b405 88040001 [ 1106.345513] Call Trace: [ 1106.348235] [] delete_from_page_cache+0x40/0x80 [ 1106.355128] [] truncate_hugepages+0x115/0x1f0 [ 1106.361826] [] hugetlbfs_evict_inode+0x18/0x30 [ 1106.368615] [] evict+0x9f/0x1b0 [ 1106.373951] [] iput_final+0xe3/0x1e0 [ 1106.379773] [] iput+0x3e/0x50 [ 1106.384922] [] d_kill+0xf8/0x110 [ 1106.390356] [] dput+0xe2/0x1b0 [ 1106.395595] [] __fput+0x162/0x240 During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc() shared page tables with the check dst_pte == src_pte. The logic is if the PMD page is the same, they must be shared. This assumes that the sharing is between the parent and child. However, if the sharing is with a different process entirely then this check fails as in this diagram. parent | >pmd src_pte--> data page ^ other->pmd| ^ child---| dst_pte For this situation to occur, it must be possible for Parent and Other to have faulted and failed to share page tables with each other. This is possible due to the following style of race. PROC A PROC B copy_hugetlb_page_range copy_hugetlb_page_range src_pte == huge_pte_offset src_pte == huge_pte_offset !src_pte so no sharing !src_pte so no sharing (time passes) hugetlb_fault hugetlb_fault huge_pte_alloc
Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
2012/7/27 Wen Congyang :
> We don't call __add_pages() directly in the function add_memory()
> because some other architecture related things need to be done
> before or after calling __add_pages(). So we should introduce
> a new function arch_remove_memory() to revert the things
> done in arch_add_memory().
>
> Note: the function for s390 is not implemented(I don't know how to
> implement it for s390).
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Signed-off-by: Wen Congyang
> ---
> arch/ia64/mm/init.c | 16
> arch/powerpc/mm/mem.c| 14 +++
> arch/s390/mm/init.c |8 ++
> arch/sh/mm/init.c| 15 +++
> arch/tile/mm/init.c |8 ++
> arch/x86/include/asm/pgtable_types.h |1 +
> arch/x86/mm/init_32.c| 10 ++
> arch/x86/mm/init_64.c| 160
> ++
> arch/x86/mm/pageattr.c | 47 +-
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c |1 +
> 11 files changed, 259 insertions(+), 22 deletions(-)
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index 0eab454..1e345ed 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -688,6 +688,22 @@ int arch_add_memory(int nid, u64 start, u64 size)
>
> return ret;
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn = start >> PAGE_SHIFT;
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + int ret;
> +
> + ret = __remove_pages(start_pfn, nr_pages);
> + if (ret)
> + pr_warn("%s: Problem encountered in __remove_pages() as"
> + " ret=%d\n", __func__, ret);
> +
> + return ret;
> +}
> +#endif
> #endif
>
in 3.5 ia64 implementation did not call __remove_pages at all. so why?
> /*
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index baaafde..249cef4 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -133,6 +133,20 @@ int arch_add_memory(int nid, u64 start, u64 size)
>
> return __add_pages(nid, zone, start_pfn, nr_pages);
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn = start >> PAGE_SHIFT;
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> +
> + start = (unsigned long)__va(start);
> + if (remove_section_mapping(start, start + size))
> + return -EINVAL;
> +
> + return __remove_pages(start_pfn, nr_pages);
> +}
> +#endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
>
> /*
> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> index 6adbc08..ca4bc46 100644
> --- a/arch/s390/mm/init.c
> +++ b/arch/s390/mm/init.c
> @@ -257,4 +257,12 @@ int arch_add_memory(int nid, u64 start, u64 size)
> vmem_remove_mapping(start, size);
> return rc;
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + /* TODO */
> + return -EBUSY;
> +}
> +#endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
> diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
> index 82cc576..fc84491 100644
> --- a/arch/sh/mm/init.c
> +++ b/arch/sh/mm/init.c
> @@ -558,4 +558,19 @@ int memory_add_physaddr_to_nid(u64 addr)
> EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> #endif
>
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + unsigned long start_pfn = start >> PAGE_SHIFT;
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + int ret;
> +
> + ret = __remove_pages(start_pfn, nr_pages);
> + if (unlikely(ret))
> + pr_warn("%s: Failed, __remove_pages() == %d\n", __func__,
> + ret);
> +
> + return ret;
> +}
> +#endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
> diff --git a/arch/tile/mm/init.c b/arch/tile/mm/init.c
> index ef29d6c..2749515 100644
> --- a/arch/tile/mm/init.c
> +++ b/arch/tile/mm/init.c
> @@ -935,6 +935,14 @@ int remove_memory(u64 start, u64 size)
> {
> return -EINVAL;
> }
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +int arch_remove_memory(u64 start, u64 size)
> +{
> + /* TODO */
> + return -EBUSY;
> +}
> +#endif
> #endif
>
> struct kmem_cache *pgd_cache;
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index 013286a..b725af2 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -334,6 +334,7 @@ static inline void update_page_count(int level, unsigned
> long pages) { }
> * as a pte too.
> */
> extern pte_t *lookup_address(unsigned long address, unsigned int *level);
> +extern int
Re: [ 28/73] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
On Tue, 2012-07-31 at 22:56 -0300, Herton Ronaldo Krzesinski wrote: > On Tue, Jul 31, 2012 at 05:43:38AM +0100, Ben Hutchings wrote: > > 3.2-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Nishanth Menon > > > > commit b110547e586eb5825bc1d04aa9147bff83b57672 upstream. > > This change is uneeded in 3.2, but doesn't do any harm either... it just > seems to fix the code because of the continue added in 9fa2df6b (ARM: > OMAP2+: OPP: allow OPP enumeration to continue if device is not present), > change which 3.2 doesn't have. A noop for 3.2 anyway, so either way it's > fine, applying or not, just commenting on it. [...] I'll drop it. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
[PATCH 2/2] Made core dump functionality optional
From: Alex
Adds an expert Kconfig option, CONFIG_COREDUMP, which allows disabling of core
dump.
This saves approximately 2.6k in the compiled kernel, and complements
CONFIG_ELF_CORE,
which now depends on it.
CONFIG_COREDUMP also disables coredump-related sysctls, except for
suid_dumpable and
related functions, which are necessary for ptrace.
Signed-off-by: Alex Kelly
Reviewed-by: Josh Triplett
---
fs/Kconfig.binfmt | 8
fs/Makefile | 3 ++-
include/linux/binfmts.h | 4
init/Kconfig| 1 +
kernel/sysctl.c | 6 +-
5 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index 0225742..0efd152 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -164,3 +164,11 @@ config BINFMT_MISC
You may say M here for module support and later load the module when
you have use for it; the module is called binfmt_misc. If you
don't know what to answer at this point, say Y.
+
+config COREDUMP
+ bool "Enable core dump support" if EXPERT
+ default y
+ help
+ This option enables support for performing core dumps. You almost
+ certainly want to say Y here. Not necessary on systems that never
+ need debugging or only ever run flawless code.
diff --git a/fs/Makefile b/fs/Makefile
index 8938f82..1d7af79 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -11,7 +11,7 @@ obj-y := open.o read_write.o file_table.o super.o \
attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
- stack.o fs_struct.o statfs.o coredump.o
+ stack.o fs_struct.o statfs.o
ifeq ($(CONFIG_BLOCK),y)
obj-y += buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
@@ -48,6 +48,7 @@ obj-$(CONFIG_FS_MBCACHE) += mbcache.o
obj-$(CONFIG_FS_POSIX_ACL) += posix_acl.o xattr_acl.o
obj-$(CONFIG_NFS_COMMON) += nfs_common/
obj-$(CONFIG_GENERIC_ACL) += generic_acl.o
+obj-$(CONFIG_COREDUMP) += coredump.o
obj-$(CONFIG_FHANDLE) += fhandle.o
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index 366422b..00e2e89 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -132,7 +132,11 @@ extern int copy_strings_kernel(int argc, const char *const
*argv,
struct linux_binprm *bprm);
extern int prepare_bprm_creds(struct linux_binprm *bprm);
extern void install_exec_creds(struct linux_binprm *bprm);
+#ifdef CONFIG_COREDUMP
extern void do_coredump(long signr, int exit_code, struct pt_regs *regs);
+#else
+static inline void do_coredump(long signr, int exit_code, struct pt_regs
*regs) {}
+#endif
extern void set_binfmt(struct linux_binfmt *new);
extern void free_bprm(struct linux_binprm *);
diff --git a/init/Kconfig b/init/Kconfig
index d07dcf9..1bd0b52 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1215,6 +1215,7 @@ config BUG
Just say Y.
config ELF_CORE
+ depends on COREDUMP
default y
bool "Enable ELF core dumps" if EXPERT
help
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4ab1187..dc0745f 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -96,10 +96,12 @@
extern int sysctl_overcommit_memory;
extern int sysctl_overcommit_ratio;
extern int max_threads;
-extern int core_uses_pid;
extern int suid_dumpable;
+#ifdef CONFIG_COREDUMP
+extern int core_uses_pid;
extern char core_pattern[];
extern unsigned int core_pipe_limit;
+#endif
extern int pid_max;
extern int min_free_kbytes;
extern int pid_max_min, pid_max_max;
@@ -398,6 +400,7 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+#ifdef CONFIG_COREDUMP
{
.procname = "core_uses_pid",
.data = _uses_pid,
@@ -419,6 +422,7 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+#endif
#ifdef CONFIG_PROC_SYSCTL
{
.procname = "tainted",
--
1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Moved core dump functionality into its own file
This was done in preparation for making core dump functionality optional.
The variable "suid_dumpable" and associated functions are left in fs/exec.c
because they're used elsewhere, such as in ptrace.
Signed-off-by: Alex Kelly
Reviewed-by: Josh Triplett
---
fs/Makefile | 2 +-
fs/coredump.c | 684 ++
fs/exec.c | 642 +-
include/linux/sched.h | 1 +
4 files changed, 687 insertions(+), 642 deletions(-)
create mode 100644 fs/coredump.c
diff --git a/fs/Makefile b/fs/Makefile
index 2fb9779..8938f82 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -11,7 +11,7 @@ obj-y := open.o read_write.o file_table.o super.o \
attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
- stack.o fs_struct.o statfs.o
+ stack.o fs_struct.o statfs.o coredump.o
ifeq ($(CONFIG_BLOCK),y)
obj-y += buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
diff --git a/fs/coredump.c b/fs/coredump.c
new file mode 100644
index 000..17951da
--- /dev/null
+++ b/fs/coredump.c
@@ -0,0 +1,684 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include "internal.h"
+
+#include
+
+int core_uses_pid;
+char core_pattern[CORENAME_MAX_SIZE] = "core";
+unsigned int core_pipe_limit;
+static atomic_t call_count = ATOMIC_INIT(1);
+
+/* The maximal length of core_pattern is also specified in sysctl.c */
+static int zap_process(struct task_struct *start, int exit_code)
+{
+ struct task_struct *t;
+ int nr = 0;
+
+ start->signal->flags = SIGNAL_GROUP_EXIT;
+ start->signal->group_exit_code = exit_code;
+ start->signal->group_stop_count = 0;
+
+ t = start;
+ do {
+ task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK);
+ if (t != current && t->mm) {
+ sigaddset(>pending.signal, SIGKILL);
+ signal_wake_up(t, 1);
+ nr++;
+ }
+ } while_each_thread(start, t);
+
+ return nr;
+}
+
+
+/*
+ * Core dumping helper functions. These are the only things you should
+ * do on a core-file: use only these functions to write out all the
+ * necessary info.
+ */
+int dump_write(struct file *file, const void *addr, int nr)
+{
+ return access_ok(VERIFY_READ, addr, nr) && file->f_op->write(file,
addr, nr, >f_pos) == nr;
+}
+EXPORT_SYMBOL(dump_write);
+
+struct core_name {
+ char *corename;
+ int used, size;
+};
+
+static int expand_corename(struct core_name *cn)
+{
+ char *old_corename = cn->corename;
+
+ cn->size = CORENAME_MAX_SIZE * atomic_inc_return(_count);
+ cn->corename = krealloc(old_corename, cn->size, GFP_KERNEL);
+
+ if (!cn->corename) {
+ kfree(old_corename);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static int cn_printf(struct core_name *cn, const char *fmt, ...)
+{
+ char *cur;
+ int need;
+ int ret;
+ va_list arg;
+
+ va_start(arg, fmt);
+ need = vsnprintf(NULL, 0, fmt, arg);
+ va_end(arg);
+
+ if (likely(need < cn->size - cn->used - 1))
+ goto out_printf;
+
+ ret = expand_corename(cn);
+ if (ret)
+ goto expand_fail;
+
+out_printf:
+ cur = cn->corename + cn->used;
+ va_start(arg, fmt);
+ vsnprintf(cur, need + 1, fmt, arg);
+ va_end(arg);
+ cn->used += need;
+ return 0;
+
+expand_fail:
+ return ret;
+}
+
+static void cn_escape(char *str)
+{
+ for (; *str; str++)
+ if (*str == '/')
+ *str = '!';
+}
+
+static int cn_print_exe_file(struct core_name *cn)
+{
+ struct file *exe_file;
+ char *pathbuf, *path;
+ int ret;
+
+ exe_file = get_mm_exe_file(current->mm);
+ if (!exe_file) {
+ char *commstart = cn->corename + cn->used;
+ ret = cn_printf(cn, "%s (path unknown)", current->comm);
+ cn_escape(commstart);
+ return ret;
+ }
+
+ pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY);
+ if (!pathbuf) {
+ ret = -ENOMEM;
+ goto put_exe_file;
+ }
+
+ path = d_path(_file->f_path, pathbuf, PATH_MAX);
+ if (IS_ERR(path)) {
+ ret = PTR_ERR(path);
+ goto free_buf;
+ }
+
+ cn_escape(path);
+
+ ret = cn_printf(cn, "%s",
Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
On Jul 31, 2012, at 7:10 PM, "Jianbin Kang" wrote: >> Actually this is what I'm working on now, using async_tx to replace the >> memcpy. I believe the changes shouldn't be that significant. >> >> Is the "hardware that can setup dma" you refer to something that does >> not use this interface? >> > > Yes, they use this interface, but split 'memcpy_toio' to two operation: > 1. setup dma > 2. wait/poll for the dma to finish. > So maybe it need to provide a generic function 'tx' for different hardwares. > It's not worth it to do sync DMA. The performance is terrible. > If async_tx is available, it's much better than this 'sync dma/memcpy'. > One problem with async_tx is, it can't detect memcpy error. > If the remote ntb goes down when async_memcpy is in operation, async_tx > will trigger an oops. Yes that is something that needs to be addressed when we get async DMA support working. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 8/1/2012 9:47 AM, Alex Courbot wrote:
> On 07/31/2012 09:55 PM, Mitch Bradley wrote:
>> On 7/31/2012 8:38 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>> I wonder if using the same structure/array as input and output would
>>> simplify the API; the platform data would fill in the fields mentioned
>>> above, and power_seq_build() would parse those, then set other fields in
>>> the same structs to the looked-up handle values?
>>
>> The thing is that I am not sure what happens to the platform data
>> once probe() is done. Isn't it customary to mark it with __devinit
>> and have it freed after probing is successful?
>
> No, platform data should stay around forever. Otherwise, consider what
> would happen if your driver is built as a module and you unload and load
> it again.
>
>> More generally, I think it is a good practice to have data
>> structures tailored right for what they need to do - code with
>> members that are meaningful only at given points of an instance's
>> life tends to be more confusing.
>
> I agree. Furthermore the driver unload/reload would be another reason
> not to reuse platform data as the output of the build() function.
>
> But maybe what Stephen meant was more like filling a structure with data
> taken from the platform data and pass that to a resolve() function which
> would fill in the missing pieces like pointers to actual resources. I
> imagine a managed interface would become a little trickier to do using
> such an approach.
>
>>> If the nodes have a unit address (i.e. end in "@n"), which they will
>>> have to if all named "step" and there's more than one of them, then they
>>> will need a matching reg property. Equally, the parent node will need
>>> #address-cells and #size-cells too. So, the last couple lines would be:
>>>
>>> power-on-sequence {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> step@0 {
>>> reg = <0>;
>>
>> That's precisely what I would like to avoid - I don't need the steps
>> to be numbered and I certainly have no use for a reg property. Isn't
>> there a way to make it simpler?
>
> It's not technically valid to not have the reg property. Or
> #address-cells and #size-cells properties for that matter.
I'm not keen on this representation where individual steps are nodes.
That seems like it could end up being too "heavyweight" for a long
sequence.
>>>
>>> The other alternative would involve using a single property to encode
>>> one sequence. I think that was the initial proposal, though using proper
>>> phandle encoding it could probably be enhanced a bit. However anything
>>> that involves a single property has the problem that we need to encode
>>> the type of resource as an integer, and that makes things very hard to
>>> read.
>>>
>>> So it would look something like this:
>>>
>>> power-on = <1 6 01
>>> 0 1
>>> 2 1
>>> 30 500 1>;
>>>
>>> power-off = <30 500 0
>>> 2 0
>>> 0 1
>>> 1 6 00>;
>>>
>>> So the first cell would encode the type:
>>>0: delay
>>>1: gpio
>>>2: regulator
>>>3: PWM
>>>
>>> The next n cells would be the phandle and the specifier, while the last
>>> cell would encode a resource-specific parameter:
>>>delay: time in microseconds
>>>gpio: set level (0: low, 1: high)
>>>regulator: 0: disable, 1: enable
>>>pwm: 0: disable, 1: enable
>>>
>>> I guess this would be more compact, but it is also very hard to read. Is
>>> that something you would be happier with? Perhaps you were thinking of
>>> something completely different?
>>
>>
>> Perhaps a compact/flexible encoding could be designed, with a textual
>> encoding that is easy to read. A separate tool could convert the text
>> encoding to the integer format, annotated with comments containing
>> the "source text". A file containing that output could be #included
>> into the dts file.
>
> Do you mean having a external compiler that would run before dtc just
> for producing the power sequences? That sounds a little bit overkill for
> something that ough to remain simple.
>
> Also, although I admit I don't have the whole picture of where they
> could be used, I don't expect the power sequences to grow to sizes that
> would make us bother about their footprint.
It is axiomatic that every
Re: [PATCH 1/2] ACPI: replace all acpi_get_table_with_size with acpi_get_table
On Tue, 31 Jul 2012 13:56:58 -0700
Yinghai Lu wrote:
> On Mon, Jul 30, 2012 at 8:20 PM, Len Brown wrote:
> > Applied.
> >
> > thanks,
> > Len Brown, Intel Open Source Technology Center
> >
> > ps. next time, please send to linux-a...@vger.kernel.org list
> > also, put comments not for the commit log after the "---"
> >
>
> other two reference need to be changed:
>
> drivers/iommu/amd_iommu_init.c: status =
> acpi_get_table_with_size("IVRS", 0, _base, _size);
> drivers/iommu/amd_iommu_init.c: status =
> acpi_get_table_with_size("IVRS", 0, _base, _size);
Thanks for the reminder! I will send a follow-on patch
Thanks,
Feng
>
>
> Thanks
>
> Yinghai
--
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 v2 1/2] PCI-Express Non-Transparent Bridge Support
> Actually this is what I'm working on now, using async_tx to replace the > memcpy. I believe the changes shouldn't be that significant. > > Is the "hardware that can setup dma" you refer to something that does > not use this interface? > Yes, they use this interface, but split 'memcpy_toio' to two operation: 1. setup dma 2. wait/poll for the dma to finish. So maybe it need to provide a generic function 'tx' for different hardwares. If async_tx is available, it's much better than this 'sync dma/memcpy'. One problem with async_tx is, it can't detect memcpy error. If the remote ntb goes down when async_memcpy is in operation, async_tx will trigger an oops. -- 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/8] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi 1. This patch is based on the kernel of 3.5 2. In this patch, we add new micro for matching the series USB devices with vendor ID and interface information. 3. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi --- --- test/linux-3.5/include/linux/usb.h 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/include/linux/usb.h 2012-07-26 14:40:40.0 +0800 @@ -828,6 +828,27 @@ static inline int usb_make_path(struct u .bInterfaceClass = (cl), \ .bInterfaceSubClass = (sc), \ .bInterfaceProtocol = (pr) +/** + * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a class of usb interfaces, but independent of product ID + * @vend: the 16 bit USB Vendor ID + * @cl: bInterfaceClass value + * @sc: bInterfaceSubClass value + * @pr: bInterfaceProtocol value + * + * This macro is used to create a struct usb_device_id that matches a + * series of devices with a vendor ID and a specific class of interfaces. + * + * This is especially useful when explicitly matching the specific interface for series of different devices with + * the same vendor. + */ + +#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \ + .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \ + | USB_DEVICE_ID_MATCH_VENDOR, \ + .idVendor = (vend), \ + .bInterfaceClass = (cl), \ + .bInterfaceSubClass = (sc), \ + .bInterfaceProtocol = (pr) /* --- */ --- test/linux-3.5/drivers/usb/serial/option.c 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/drivers/usb/serial/option.c 2012-07-26 15:51:30.0 +0800 @@ -80,85 +80,9 @@ static void option_instat_callback(struc #define OPTION_PRODUCT_GTM380_MODEM0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E6000x1001 -#define HUAWEI_PRODUCT_E2200x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432 0x1432 -#define HUAWEI_PRODUCT_E1433
Build failure when installing atm ambassador firmware
Hello, When building with MODLIB=/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/modules/3.5.0 and INSTALL_FW_PATH="/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware", building Linux 3.5 with CONFIG_ATM_AMBASSADOR=m fails with: "make[2]: *** No rule to make target `"/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware"/./', needed by `"/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware"/atmsar11.fw'. Stop." My .config is after the message. Note that while I believe this should work even with the unusual MODLIB/INSTALL_FW_PATH, a quick Google search replacing those paths with the normal /lib shows others have the same error. The error seems to be due to make version, I'm using GNU Make 3.8.2. Regards, Shea Levy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.5.0 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_FHANDLE is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y # CONFIG_KPROBES is not set # CONFIG_JUMP_LABEL is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
Re: [ 28/73] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
On Tue, Jul 31, 2012 at 05:43:38AM +0100, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Nishanth Menon
>
> commit b110547e586eb5825bc1d04aa9147bff83b57672 upstream.
This change is uneeded in 3.2, but doesn't do any harm either... it just
seems to fix the code because of the continue added in 9fa2df6b (ARM:
OMAP2+: OPP: allow OPP enumeration to continue if device is not present),
change which 3.2 doesn't have. A noop for 3.2 anyway, so either way it's
fine, applying or not, just commenting on it.
>
> Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
> (ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present)
> makes the logic:
> for (i = 0; i < opp_def_size; i++) {
>
> if (!oh || !oh->od) {
>
> continue;
> }
>
> opp_def++;
> }
>
> In short, the moment we hit a "Bad OPP", we end up looping the list
> comparing against the bad opp definition pointer for the rest of the
> iteration count. Instead, increment opp_def in the for loop itself
> and allow continue to be used in code without much thought so that
> we check the next set of OPP definition pointers :)
>
> Cc: Steve Sakoman
> Cc: Tony Lindgren
> Signed-off-by: Nishanth Menon
> Signed-off-by: Kevin Hilman
> Signed-off-by: Ben Hutchings
> ---
> arch/arm/mach-omap2/opp.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
> index de6d464..d8f6dbf 100644
> --- a/arch/arm/mach-omap2/opp.c
> +++ b/arch/arm/mach-omap2/opp.c
> @@ -53,7 +53,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
> omap_table_init = 1;
>
> /* Lets now register with OPP library */
> - for (i = 0; i < opp_def_size; i++) {
> + for (i = 0; i < opp_def_size; i++, opp_def++) {
> struct omap_hwmod *oh;
> struct device *dev;
>
> @@ -86,7 +86,6 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
> __func__, opp_def->freq,
> opp_def->hwmod_name, i, r);
> }
> - opp_def++;
> }
>
> return 0;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
[]'s
Herton
--
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 00/17] vfs: add the ability to retry on ESTALE to several syscalls
2012/7/27, Jeff Layton : > On Fri, 27 Jul 2012 11:15:23 +0900 > Namjae Jeon wrote: > >> Hi Jeff. >> >> Which testcase(or test method) do I use to know improved point from >> ESTALE error ? >> I want to know before & after using testcase with this patch-set. >> > > It's a bit labor intensive, I'm afraid... > > Attached is a cleaned-up copy of the test program that Peter wrote to > test his original patchset. The basic idea is to run this on both the > client and server at the same time so they race against each other. He > was able to run it overnight when testing with his patchset. > > With this patchset, that doesn't work since we're only retrying the > lookup and call once. So, what I've been doing is modifying the program > so that it just runs one test at a time, and sniffing traffic to see > whether the lookups and calls are retried after an ESTALE return from > the server. Sorry for late response. I will check this patch with testcase you shared. Thanks Jeff. > > -- > Jeff Layton > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 07/31/2012 09:55 PM, Mitch Bradley wrote:
On 7/31/2012 8:38 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same structure/array as input and output would
simplify the API; the platform data would fill in the fields mentioned
above, and power_seq_build() would parse those, then set other fields in
the same structs to the looked-up handle values?
The thing is that I am not sure what happens to the platform data
once probe() is done. Isn't it customary to mark it with __devinit
and have it freed after probing is successful?
No, platform data should stay around forever. Otherwise, consider what
would happen if your driver is built as a module and you unload and load
it again.
More generally, I think it is a good practice to have data
structures tailored right for what they need to do - code with
members that are meaningful only at given points of an instance's
life tends to be more confusing.
I agree. Furthermore the driver unload/reload would be another reason
not to reuse platform data as the output of the build() function.
But maybe what Stephen meant was more like filling a structure with data
taken from the platform data and pass that to a resolve() function which
would fill in the missing pieces like pointers to actual resources. I
imagine a managed interface would become a little trickier to do using
such an approach.
If the nodes have a unit address (i.e. end in "@n"), which they will
have to if all named "step" and there's more than one of them, then they
will need a matching reg property. Equally, the parent node will need
#address-cells and #size-cells too. So, the last couple lines would be:
power-on-sequence {
#address-cells = <1>;
#size-cells = <0>;
step@0 {
reg = <0>;
That's precisely what I would like to avoid - I don't need the steps
to be numbered and I certainly have no use for a reg property. Isn't
there a way to make it simpler?
It's not technically valid to not have the reg property. Or
#address-cells and #size-cells properties for that matter.
I'm not keen on this representation where individual steps are nodes.
That seems like it could end up being too "heavyweight" for a long sequence.
The other alternative would involve using a single property to encode
one sequence. I think that was the initial proposal, though using proper
phandle encoding it could probably be enhanced a bit. However anything
that involves a single property has the problem that we need to encode
the type of resource as an integer, and that makes things very hard to
read.
So it would look something like this:
power-on = <1 6 01
0 1
2 1
30 500 1>;
power-off = <30 500 0
2 0
0 1
1 6 00>;
So the first cell would encode the type:
0: delay
1: gpio
2: regulator
3: PWM
The next n cells would be the phandle and the specifier, while the last
cell would encode a resource-specific parameter:
delay: time in microseconds
gpio: set level (0: low, 1: high)
regulator: 0: disable, 1: enable
pwm: 0: disable, 1: enable
I guess this would be more compact, but it is also very hard to read. Is
that something you would be happier with? Perhaps you were thinking of
something completely different?
Perhaps a compact/flexible encoding could be designed, with a textual
encoding that is easy to read. A separate tool could convert the text
encoding to the integer format, annotated with comments containing
the "source text". A file containing that output could be #included
into the dts file.
Do you mean having a external compiler that would run before dtc just
for producing the power sequences? That sounds a little bit overkill for
something that ough to remain simple.
Also, although I admit I don't have the whole picture of where they
could be used, I don't expect the power sequences to grow to sizes that
would make us bother about their footprint.
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 07/31/2012 09:22 PM, Mitch Bradley wrote:
On 7/31/2012 6:56 PM, Thierry Reding wrote:
On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
On 07/31/2012 07:45 AM, Stephen Warren wrote:
I wonder if using the same structure/array as input and output would
simplify the API; the platform data would fill in the fields mentioned
above, and power_seq_build() would parse those, then set other fields in
the same structs to the looked-up handle values?
The thing is that I am not sure what happens to the platform data
once probe() is done. Isn't it customary to mark it with __devinit
and have it freed after probing is successful?
No, platform data should stay around forever. Otherwise, consider what
would happen if your driver is built as a module and you unload and load
it again.
More generally, I think it is a good practice to have data
structures tailored right for what they need to do - code with
members that are meaningful only at given points of an instance's
life tends to be more confusing.
I agree. Furthermore the driver unload/reload would be another reason
not to reuse platform data as the output of the build() function.
But maybe what Stephen meant was more like filling a structure with data
taken from the platform data and pass that to a resolve() function which
would fill in the missing pieces like pointers to actual resources. I
imagine a managed interface would become a little trickier to do using
such an approach.
If the nodes have a unit address (i.e. end in "@n"), which they will
have to if all named "step" and there's more than one of them, then they
will need a matching reg property. Equally, the parent node will need
#address-cells and #size-cells too. So, the last couple lines would be:
power-on-sequence {
#address-cells = <1>;
#size-cells = <0>;
step@0 {
reg = <0>;
That's precisely what I would like to avoid - I don't need the steps
to be numbered and I certainly have no use for a reg property. Isn't
there a way to make it simpler?
It's not technically valid to not have the reg property. Or
#address-cells and #size-cells properties for that matter.
I'm not keen on this representation where individual steps are nodes.
That seems like it could end up being too "heavyweight" for a long sequence.
Using nodes has a big advantage though: we can use any arbitrary
property to add extra parameters to the resource being controlled. Right
now we only use enable/disable, but for example one can imagine an
optional voltage setting for a regulator. It is much more future-proof
than a design where the number of parameters would be fixed and could
not be extended without breaking compatibility.
I experimented encoding the whole sequence within a single property. It
works of course, but is not really flexible, hard to read, and quite
error-prone overall. The memory footprint gain was not so obvious
neither (although it was indeed more compact).
What bothers me is to have to specify the cells layout and reg property
for *every single sequence*, but well, I guess we can live with that.
Alex.
--
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 v5 12/19] memory-hotplug: introduce new function arch_remove_memory()
At 07/31/2012 08:40 PM, Gerald Schaefer Wrote: > On Mon, 30 Jul 2012 18:35:37 +0800 > Wen Congyang wrote: > >> At 07/30/2012 06:23 PM, Heiko Carstens Wrote: >>> On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote: We don't call __add_pages() directly in the function add_memory() because some other architecture related things need to be done before or after calling __add_pages(). So we should introduce a new function arch_remove_memory() to revert the things done in arch_add_memory(). Note: the function for s390 is not implemented(I don't know how to implement it for s390). >>> >>> There is no hardware or firmware interface which could trigger a >>> hot memory remove on s390. So there is nothing that needs to be >>> implemented. >> >> Thanks for providing this information. >> >> According to this, arch_remove_memory() for s390 can just return >> -EBUSY. > > Yes, but there is a prototype mismatch for arch_remove_memory() on s390 > and also other architectures (u64 vs. unsigned long). > > arch/s390/mm/init.c:262: error: conflicting types for > ‘arch_remove_memory’ include/linux/memory_hotplug.h:88: error: previous > declaration of ‘arch_remove_memory’ was here > > In memory_hotplug.h you have: > extern int arch_remove_memory(unsigned long start, unsigned long size); > > On all archs other than x86 you have: > int arch_remove_memory(u64 start, u64 size) Thanks for pointing it out. I will fix it. Wen Congyang > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 07/10] mm: use mm->exe_file instead of first VM_EXECUTABLE vma->vm_file
On Tue, 31 Jul 2012, Konstantin Khlebnikov wrote: > Some security modules and oprofile still uses VM_EXECUTABLE for retrieving > task's executable file, after this patch they will use mm->exe_file directly. > mm->exe_file protected with mm->mmap_sem, so locking stays the same. > Acked-by: James Morris -- 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: Complaint - pid-owner Support Removed (CONFIG_NETFILTER_XT_MATCH_OWNER)
On Tue, 31 Jul 2012 12:41:21 +1000, NeilBrown said: > On Mon, 30 Jul 2012 21:22:10 +0200 "C. Schmid" > wrote: > > i want to complain about the removal of the --pid-owner Support for > > iptables. > > As far as i understand it this support was just removed without replacement. > > Yes, 7 years ago. > "Unfixably broken" Even *before* it was removed, it declared itself "broken on SMP" (which is a good hint on exactly *why* it was unfixable), and why it's not applicable to most modern desktop systems anyhow - even an iPad is a dual-core. And to be honest, the "Linux only cares about big iron not the desktop" is a total red herring - if anything, many laptops *are* essentially a single-user environment, while big iron boxes are even *more* concerned about per-user issues. I just checked one of the compute clusters across the hall, 1100+ actual users defined. How often do desktops/laptops have that many real live users? pgp9emhwKtjbv.pgp Description: PGP signature
[PATCH] regulator: wm8400: Simplify set REGULATOR_MODE_IDLE mode in wm8400_dcdc_set_mode
To set REGULATOR_MODE_IDLE mode, what we do is to clear DC1_ACTIVE and DC1_SLEEP bits, this can be done in one wm8400_set_bits() call. Signed-off-by: Axel Lin --- drivers/regulator/wm8400-regulator.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/regulator/wm8400-regulator.c b/drivers/regulator/wm8400-regulator.c index 9035dd0..27c746e 100644 --- a/drivers/regulator/wm8400-regulator.c +++ b/drivers/regulator/wm8400-regulator.c @@ -120,13 +120,8 @@ static int wm8400_dcdc_set_mode(struct regulator_dev *dev, unsigned int mode) case REGULATOR_MODE_IDLE: /* Datasheet: standby */ - ret = wm8400_set_bits(wm8400, WM8400_DCDC1_CONTROL_1 + offset, - WM8400_DC1_ACTIVE, 0); - if (ret != 0) - return ret; return wm8400_set_bits(wm8400, WM8400_DCDC1_CONTROL_1 + offset, - WM8400_DC1_SLEEP, 0); - + WM8400_DC1_ACTIVE | WM8400_DC1_SLEEP, 0); default: return -EINVAL; } -- 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: [GIT PULL] PWM subsystem for v3.6
On Tue, Jul 31, 2012 at 1:19 AM, Thierry Reding wrote: > > I just sent a new pull request with a signed tag. I've also included a > more detailed description of why this is useful, along the lines of what > Arnd already mentioned. > > My key was signed by Sebastian Andrzej Siewior today and I uploaded the > signature only now, so it may take some time to propagate. Ok. I had decided that I had lots of acks for your code and had actually pulled your code yesterday, so my merge doesn't have that new tag information. But I verified your tag separately, and everything looks fine. So future pulls will then be properly signed in my repo too if you use tags, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v4] mmc: core: Remove bounce buffer in mmc_send_cxd_data()
It is expected that Extended CSD register(the size of this register
is larger than CID/CSD) will be referenced more frequently as more
fields have been added to Extended CSD and it seems that it is not
a good option to double the memory used.
This patch is intended to avoid the use of bounce buffer for reading
Extended CSD register in mmc_send_cxd_data().
Signed-off-by: Kyungsik Lee
Signed-off-by: S, Venkatraman
---
Changes in v2:
- Handling on-stack buffer if it's used in caller.
Changes in v3:
- Remove unnecesary code.
Changes in v4:
- Modify codes based-on S, Venkatraman's comments.
---
drivers/mmc/core/mmc_ops.c | 54 +++-
1 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 0ed2cc5..920a017 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -239,13 +239,19 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
struct mmc_data data = {0};
struct scatterlist sg;
void *data_buf;
+ int is_on_stack;
- /* dma onto stack is unsafe/nonportable, but callers to this
-* routine normally provide temporary on-stack buffers ...
-*/
- data_buf = kmalloc(len, GFP_KERNEL);
- if (data_buf == NULL)
- return -ENOMEM;
+ is_on_stack = object_is_on_stack(buf);
+ if (is_on_stack) {
+
+ /* dma onto stack is unsafe/nonportable, but callers to this
+* routine normally provide temporary on-stack buffers ...
+*/
+ data_buf = kmalloc(len, GFP_KERNEL);
+ if (data_buf == NULL)
+ return -ENOMEM;
+ } else
+ data_buf = buf;
mrq.cmd =
mrq.data =
@@ -280,8 +286,10 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
mmc_wait_for_req(host, );
- memcpy(buf, data_buf, len);
- kfree(data_buf);
+ if (is_on_stack) {
+ memcpy(buf, data_buf, len);
+ kfree(data_buf);
+ }
if (cmd.error)
return cmd.error;
@@ -294,24 +302,32 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host
*host,
int mmc_send_csd(struct mmc_card *card, u32 *csd)
{
int ret, i;
+ u32 *csd_tmp;
if (!mmc_host_is_spi(card->host))
return mmc_send_cxd_native(card->host, card->rca << 16,
csd, MMC_SEND_CSD);
- ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd, 16);
+ csd_tmp = kmalloc(16, GFP_KERNEL);
+ if (!csd_tmp)
+ return -ENOMEM;
+
+ ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd_tmp, 16);
if (ret)
- return ret;
+ goto err;
for (i = 0;i < 4;i++)
- csd[i] = be32_to_cpu(csd[i]);
+ csd[i] = be32_to_cpu(csd_tmp[i]);
- return 0;
+err:
+ kfree(csd_tmp);
+ return ret;
}
int mmc_send_cid(struct mmc_host *host, u32 *cid)
{
int ret, i;
+ u32 *cid_tmp;
if (!mmc_host_is_spi(host)) {
if (!host->card)
@@ -320,14 +336,20 @@ int mmc_send_cid(struct mmc_host *host, u32 *cid)
cid, MMC_SEND_CID);
}
- ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid, 16);
+ cid_tmp = kmalloc(16, GFP_KERNEL);
+ if (!cid_tmp)
+ return -ENOMEM;
+
+ ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid_tmp, 16);
if (ret)
- return ret;
+ goto err;
for (i = 0;i < 4;i++)
- cid[i] = be32_to_cpu(cid[i]);
+ cid[i] = be32_to_cpu(cid_tmp[i]);
- return 0;
+err:
+ kfree(cid_tmp);
+ return ret;
}
int mmc_send_ext_csd(struct mmc_card *card, u8 *ext_csd)
--
1.7.0.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: How to use the generic thermal sysfs.
On 五, 2012-07-27 at 18:48 +0800, Wei Ni wrote: > On Fri, 2012-07-27 at 15:39 +0800, Zhang Rui wrote: > > On 五, 2012-07-27 at 09:30 +0200, Jean Delvare wrote: > > > On Fri, 27 Jul 2012 10:58:21 +0800, Wei Ni wrote: > > > > On Fri, 2012-07-27 at 09:21 +0800, Zhang Rui wrote: > > > > > is it possible to program the sensor at this time, in your own thermal > > > > > driver? > > > > > > > > Since we are using the generic thermal driver lm90.c, I'm not sure if we > > > > could program these limits in the generic driver, I think it's better to > > > > have a generic interface to set the limits, so I wish to add a > > > > callback .set_limits() in the generic thermal framework. > > > > > > I can confirm that hwmon drivers do not set limits, it is up to > > > user-space to do it if they want. So if there is a need to do so in the > > > kernel itself, a proper interface at the generic thermal framework > > > level seems appropriate. > > > > > oh, setting limits from userspace? > > I think you can program the senor when writing the trip point? > > with this patch, > > http://marc.info/?l=linux-acpi=134318814620429=2 > > Do you mean it can use .set_trip_temp() to set limits when writing the > trip point? But I think this callback is used to change the trip_temp, > it could not used to set the limits, in here the limit value is used to > trigger the interrupt. > yes, you are right. .set_trip_temp does not work. usually, this is needed to re-program the sensor when the temperature hits a trip point , right? can we make use of the thermal_zone_device_ops.notify()? say we invoke .notify() in thermal_zone_device_update for each trip point. thanks, rui > > > > thanks, > > rui > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 0/5 V2] x86: mce: Bugfixes, cleanups and a new CMCI poll version
On Thu, Jul 19, 2012 at 01:59:36PM -0400, Chen Gong wrote: > Date: Thu, 19 Jul 2012 13:59:36 -0400 > From: Chen Gong > To: t...@linutronix.de > Cc: tony.l...@intel.com, b...@amd64.org, x...@kernel.org, > linux-kernel@vger.kernel.org > Subject: [RESEND PATCH 0/5 V2] x86: mce: Bugfixes, cleanups and a new > CMCI poll version > X-Mailer: git-send-email 1.7.10.4 > > [PATCH 1/5] x86: mce: Disable preemption when calling raise_local() > [PATCH 2/5] x86: mce: Serialize mce injection > [PATCH 3/5] x86: mce: Split timer init > [PATCH 4/5] x86: mce: Remove the frozen cases in the hotplug code > [PATCH 5/5] x86: mce: Add cmci poll mode > > The following series fixes a few interesting bugs (found by review in > context of the CMCI poll effort) and a cleanup to the timer/hotplug > code followed by a consolidated version of the CMCI poll > implementation. This series is based on Linus' tree. > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > Thanks Boris to point out how to use git to commit correct authorship :-). > Hi, Thomas Would you please help to merge this patch series into a proper tree? signature.asc Description: Digital signature
Re: Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences)
On Mon, Jul 30, 2012 at 10:59:39PM +0200, Rafael J. Wysocki wrote:
[...]
> > Well, currently drivers/power/ is indeed just for power supply class
> > subsystem and drivers. But if the trend is to gather power management
> > ("policy") stuff under one directory, i.e.
> >
> > drivers/
> > power/
> > supplies/<- former "power supply class and drivers"
> > regulators/
> > idle/
> > cpuidle/
> > cpufreq/
> > devfreq/
> > avs/
> > ...
> >
> > That would probably make sense, we could easily see the big picture.
> > But if we're not going to do this long-term,
>
> Yes, we may do this eventually, but surely not right now.
OK, great! Then I'll probably start thinking about moving power supply
drivers into its own directory, maybe in 3.7.
Thanks!
--
Anton Vorontsov
Email: cbouatmai...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/12] commit 22126843cb3c2a782c2d52614486115f3e9db478
On Fri, Jun 22, 2012 at 10:04 AM, Alan Cox wrote:
> On Fri, 22 Jun 2012 08:36:57 -0700
> Greg KH wrote:
>
>> On Fri, Jun 22, 2012 at 04:44:59PM +0100, Alan Cox wrote:
>> > From: Alan Cox
>> >
>> > tty: move the termios object into the tty
>> >
>> > This will let us sort out a whole pile of tty related races. The
>> > alternative would be to keep points and refcount the termios objects.
>> > However
>> > 1. They are tiny anyway
>> > 2. Many devices don't use the stored copies
>> > 3. We can remove a pty special case
>> >
>> > Signed-off-by: Alan Cox
>>
>> Odd subject line, and formatting, did something go wrong with your
>> scripts?
>
> Apparently so. I will given them a stern talking to and repost
looks the one in tty-next still missed some changes...
commit adc8d746caa67fff4b53ba3e5163a6cbacc3b523
Author: Alan Cox
Date: Sat Jul 14 15:31:47 2012 +0100
tty: move the termios object into the tty
This will let us sort out a whole pile of tty related races. The
alternative would be to keep points and refcount the termios objects.
However
1. They are tiny anyway
2. Many devices don't use the stored copies
3. We can remove a pty special case
Signed-off-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
...
still need
diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
index b9cca6d..9a56428 100644
--- a/drivers/usb/serial/console.c
+++ b/drivers/usb/serial/console.c
@@ -165,8 +165,8 @@ static int usb_console_setup(struct console *co,
char *options)
}
if (serial->type->set_termios) {
- tty->termios->c_cflag = cflag;
- tty_termios_encode_baud_rate(tty->termios, baud, baud);
+ tty->termios.c_cflag = cflag;
+ tty_termios_encode_baud_rate(>termios, baud, baud);
memset(, 0, sizeof(struct ktermios));
serial->type->set_termios(tty, port, );
--
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 12/12] tty: move the handling of the tty release logic
On Fri, Jun 22, 2012 at 8:47 AM, Alan Cox wrote: > Now that we don't have tty->termios tied to drivers->tty we can untangle > the logic here. In addition we can push the removal logic out of the > destructor path. > > At that point we can think about sorting out tty_port and console and all > the other ugly hangovers. > > An important other property we now have is that the tty mutex does now cover > the drivers array. An assumption other bits of the code made and which is > necessary for the tty lock patch. > > Signed-off-by: Alan Cox > --- > > drivers/tty/pty.c |8 > drivers/tty/tty_io.c| 16 +--- > drivers/tty/vt/vt.c |1 - > drivers/usb/serial/usb-serial.c |3 +-- > include/linux/tty.h |1 - > include/linux/tty_driver.h | 11 +++ > 6 files changed, 9 insertions(+), 31 deletions(-) Hi, Alan This one cause regression on my test setup. that setup is booting from pxe and initrd is updated from opensuse 11.3 rescue disk. kernel has command line 115200, and later serial console will use 115200 automatically. but with this one, serial console will switch back to 9600 instead. bisect said: 36b3c070d2346c890d690d71f6eab02f8c511137 is the first bad commit commit 36b3c070d2346c890d690d71f6eab02f8c511137 Author: Alan Cox Date: Tue Jul 17 17:06:57 2012 +0100 tty: Move the handling of the tty release logic Now that we don't have tty->termios tied to drivers->tty we can untangle the logic here. In addition we can push the removal logic out of the destructor path. At that point we can think about sorting out tty_port and console and all the other ugly hangovers. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman :04 04 44db8111f7e5be2f60ae2b41328108a6e533f8a4 d0af41e84b2657e308a92e2ebad04ea5594e6bb4 M drivers :04 04 f75618c564287072c6a6a9d5462355ab780b06b8 4606b8b123694a2e8aaf1d3708fda66bda843742 M include -- 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/
pci_get_subsys: GFP_KERNEL allocations with IRQs disabled
On Tue, Jul 31, 2012 at 05:18:11PM -0700, Paul E. McKenney wrote: > On Tue, Jul 31, 2012 at 08:09:38PM -0400, Steven Rostedt wrote: > > On Tue, 2012-07-31 at 16:57 -0700, Paul E. McKenney wrote: > > > > > > What was the next lines? I bet you it was "PASSED". Which means it did > > > > not fail. This is the second bug you found that has to do with RCU being > > > > called in 'idle'. The one that Paul posted a patch for. > > > > > > Though it needs another patch to actually use it in the right place... > > > > Right. Something like this: > > Looks good to me! With all 3 patches applied, the warning on __update_max_tr finally goes away. Thanks! However, this unrelated warning still reliably remains (the same config). I think it's pci_get_subsys() triggered this assert: /* * Oi! Can't be having __GFP_FS allocations with IRQs disabled. */ if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))) return; [ 91.282131] machine restart [ 91.283895] [ cut here ] [ 91.284731] WARNING: at /c/wfg/linux/kernel/lockdep.c:2739 lockdep_trace_alloc+0x1fb/0x210() [ 91.286132] Modules linked in: [ 91.286703] Pid: 697, comm: reboot Not tainted 3.5.0-00024-g01ff5db-dirty #4 [ 91.287859] Call Trace: [ 91.288289] [<81050148>] warn_slowpath_common+0xb8/0x100 [ 91.289338] [<8110acdb>] ? lockdep_trace_alloc+0x1fb/0x210 [ 91.290264] [<8110acdb>] ? lockdep_trace_alloc+0x1fb/0x210 [ 91.291161] [<810501ce>] warn_slowpath_null+0x3e/0x50 [ 91.292042] [<8110acdb>] lockdep_trace_alloc+0x1fb/0x210 [ 91.292934] [<81228e25>] kmem_cache_alloc_trace+0x55/0x600 [ 91.292934] [<813025ca>] ? kobject_put+0x9a/0x160 [ 91.292934] [<814e95e0>] ? klist_iter_exit+0x30/0x50 [ 91.292934] [<81405881>] ? bus_find_device+0xf1/0x120 [ 91.292934] [<81361a3c>] ? pci_get_subsys+0x11c/0x1b0 [ 91.292934] [<81361a3c>] pci_get_subsys+0x11c/0x1b0 [ 91.292934] [<81361afe>] pci_get_device+0x2e/0x40 [ 91.292934] [<81033e25>] mach_reboot_fixups+0xa5/0xd0 [ 91.292934] [<81027611>] native_machine_emergency_restart+0x1f1/0x590 [ 91.292934] [<814f2e00>] ? printk+0x4b/0x5b [ 91.292934] [<810269ef>] native_machine_restart+0x6f/0x80 [ 91.292934] [<810271cc>] machine_restart+0x1c/0x30 [ 91.292934] [<810886e0>] kernel_restart+0x70/0xc0 [ 91.292934] [<81088a85>] sys_reboot+0x325/0x380 [ 91.292934] [<811f796c>] ? handle_pte_fault+0xdc/0x1740 [ 91.292934] [<811f93e7>] ? handle_mm_fault+0x417/0x4a0 [ 91.292934] [<8103e07b>] ? do_page_fault+0x7fb/0xb30 [ 91.292934] [<810b33e7>] ? up_read+0x37/0x70 [ 91.292934] [<8103e07b>] ? do_page_fault+0x7fb/0xb30 [ 91.292934] [<8123c063>] ? do_sys_open+0x3a3/0x3f0 [ 91.292934] [<8123c063>] ? do_sys_open+0x3a3/0x3f0 [ 91.292934] [<810b0270>] ? update_rmtp+0xe0/0xe0 [ 91.292934] [<8150376e>] ? restore_all+0xf/0xf [ 91.292934] [<8103d880>] ? vmalloc_sync_all+0x320/0x320 [ 91.292934] [<81109fca>] ? trace_hardirqs_on_caller+0x28a/0x380 [ 91.292934] [<81311594>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 91.292934] [<81503735>] syscall_call+0x7/0xb Thanks, Fengguang -- 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/
[RESEND PATCH] block: do not artificially constrain max_sectors for stacking drivers
blk_set_stacking_limits is intended to allow stacking drivers to build up the limits of the stacked device based on the underlying devices' limits. But defaulting 'max_sectors' to BLK_DEF_MAX_SECTORS (1024) doesn't allow the stacking driver to inherit a max_sectors larger than 1024 -- due to blk_stack_limits' use of min_not_zero. It is now clear that this artificial limit is getting in the way so change blk_set_stacking_limits's max_sectors to UINT_MAX (which allows stacking drivers like dm-multipath to inherit 'max_sectors' from the underlying paths). Reported-by: Vijay Chauhan Tested-by: Vijay Chauhan Signed-off-by: Mike Snitzer --- block/blk-settings.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/block/blk-settings.c b/block/blk-settings.c index d3234fc..565a678 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -143,8 +143,7 @@ void blk_set_stacking_limits(struct queue_limits *lim) lim->discard_zeroes_data = 1; lim->max_segments = USHRT_MAX; lim->max_hw_sectors = UINT_MAX; - - lim->max_sectors = BLK_DEF_MAX_SECTORS; + lim->max_sectors = UINT_MAX; } EXPORT_SYMBOL(blk_set_stacking_limits); -- 1.7.4.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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Jul 31, 2012 at 08:09:38PM -0400, Steven Rostedt wrote: > On Tue, 2012-07-31 at 16:57 -0700, Paul E. McKenney wrote: > > > > What was the next lines? I bet you it was "PASSED". Which means it did > > > not fail. This is the second bug you found that has to do with RCU being > > > called in 'idle'. The one that Paul posted a patch for. > > > > Though it needs another patch to actually use it in the right place... > > Right. Something like this: Looks good to me! Thanx, Paul > -- Steve > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 5638104..d915638 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -631,7 +631,12 @@ __update_max_tr(struct trace_array *tr, struct > task_struct *tsk, int cpu) > > memcpy(max_data->comm, tsk->comm, TASK_COMM_LEN); > max_data->pid = tsk->pid; > - max_data->uid = task_uid(tsk); > + /* > + * task_uid() calls rcu_read_lock, but this can be called > + * outside of RCU state monitoring (irq going back to idle). > + */ > + RCU_NONIDLE(max_data->uid = task_uid(tsk)); > + > max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO; > max_data->policy = tsk->policy; > max_data->rt_priority = tsk->rt_priority; > > -- 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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, 2012-07-31 at 16:57 -0700, Paul E. McKenney wrote: > > What was the next lines? I bet you it was "PASSED". Which means it did > > not fail. This is the second bug you found that has to do with RCU being > > called in 'idle'. The one that Paul posted a patch for. > > Though it needs another patch to actually use it in the right place... Right. Something like this: -- Steve diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 5638104..d915638 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -631,7 +631,12 @@ __update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu) memcpy(max_data->comm, tsk->comm, TASK_COMM_LEN); max_data->pid = tsk->pid; - max_data->uid = task_uid(tsk); + /* +* task_uid() calls rcu_read_lock, but this can be called +* outside of RCU state monitoring (irq going back to idle). +*/ + RCU_NONIDLE(max_data->uid = task_uid(tsk)); + max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO; max_data->policy = tsk->policy; max_data->rt_priority = tsk->rt_priority; -- 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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Jul 31, 2012 at 07:51:39PM -0400, Steven Rostedt wrote:
> On Wed, 2012-08-01 at 07:43 +0800, Fengguang Wu wrote:
> > On Tue, Jul 31, 2012 at 09:13:39AM -0400, Steven Rostedt wrote:
> > > On Tue, 2012-07-31 at 15:50 +0300, Avi Kivity wrote:
> > > > On 07/31/2012 03:43 PM, Steven Rostedt wrote:
> > >
> > > > That would be better. A hypervisor might be real-time capable (with
> > > > some effort kvm can do this), so we don't want to turn off real time
> > > > features just based on that.
> > >
> > > It would only turn off if you enable selftests and the timing falied. If
> > > the kvm had real time features, this most likely would fail anyway. But
> > > that said, here's a patch that should solve this:
> >
> > No luck.. it still fails:
>
> I bet you it didn't ;-)
>
> >
> > [2.360068] Testing tracer irqsoff: [2.854529]
> > [2.854828] ===
> > [2.855560] [ INFO: suspicious RCU usage. ]
> > [2.856266] 3.5.0-00024-g01ff5db-dirty #3 Not tainted
> > [2.857182] ---
> > [2.857933] /c/wfg/linux/include/linux/rcupdate.h:730 rcu_read_lock()
> > used illegally while idle!
> > [2.859450]
> > [2.859450] other info that might help us debug this:
> > [2.859450]
> > [2.860874]
> > [2.860874] RCU used illegally from idle CPU!
> > [2.860874] rcu_scheduler_active = 1, debug_locks = 0
> > [2.862754] RCU used illegally from extended quiescent state!
> > [2.863741] 2 locks held by swapper/0/0:
> >
> > [2.864377] #0: [2.864423] (max_trace_lock){..}, at:
> > [<814f6bfe>] check_critical_timing+0xd7/0x286
> > [2.864423] #1: (rcu_read_lock){.+.+..}, at: [<8116f930>]
> > __update_max_tr+0x0/0x430
> >
> > [2.864423] stack backtrace:
> > [2.864423] Pid: 0, comm: swapper/0 Not tainted
> > 3.5.0-00024-g01ff5db-dirty #3
> > [2.864423] Call Trace:
> > [2.864423] [<81103a06>] lockdep_rcu_suspicious+0x1c6/0x210
> > [2.864423] [<8116fc9a>] __update_max_tr+0x36a/0x430
> > [2.864423] [<8116f930>] ? tracing_record_cmdline+0x200/0x200
> > [2.864423] [<8117186e>] update_max_tr_single+0x14e/0x2c0
> > [2.864423] [<81170baa>] ? __trace_stack+0x2a/0x40
> > [2.864423] [<814f6d22>] check_critical_timing+0x1fb/0x286
> > [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> > [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> > [2.864423] [<8110a0e7>] ? trace_hardirqs_on+0x27/0x40
> > [2.864423] [<8117ea5e>] time_hardirqs_on+0x1de/0x220
> > [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> > [2.864423] [<81109d6d>] trace_hardirqs_on_caller+0x2d/0x380
> > [2.864423] [<8110a0e7>] trace_hardirqs_on+0x27/0x40
> > [2.864423] [<81013313>] default_idle+0x593/0xc30
> > [2.864423] [<8101692d>] cpu_idle+0x2dd/0x390
> > [2.864423] [<814eb841>] rest_init+0x2f5/0x314
> > [2.864423] [<814eb54c>] ? __read_lock_failed+0x14/0x14
> > [2.864423] [<817a43b4>] start_kernel+0x866/0x87a
>
> What was the next lines? I bet you it was "PASSED". Which means it did
> not fail. This is the second bug you found that has to do with RCU being
> called in 'idle'. The one that Paul posted a patch for.
Yeah, PASSED!
[2.898070] [<8117ea5e>] time_hardirqs_on+0x1de/0x220
[2.898070] [<81013313>] ? default_idle+0x593/0xc30
[2.898070] [<81109d6d>] trace_hardirqs_on_caller+0x2d/0x380
[2.898070] [<8110a0e7>] trace_hardirqs_on+0x27/0x40
[2.898070] [<81013313>] default_idle+0x593/0xc30
[2.898070] [<8101692d>] cpu_idle+0x2dd/0x390
[2.898070] [<817fbe97>] start_secondary+0x44b/0x460
[3.150115] PASSED
[3.390079] Testing tracer function_graph: PASSED
I'll test Paul's patch on top of yours right away.
Thanks,
Fengguang
--
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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Jul 31, 2012 at 07:51:39PM -0400, Steven Rostedt wrote:
> On Wed, 2012-08-01 at 07:43 +0800, Fengguang Wu wrote:
> > On Tue, Jul 31, 2012 at 09:13:39AM -0400, Steven Rostedt wrote:
> > > On Tue, 2012-07-31 at 15:50 +0300, Avi Kivity wrote:
> > > > On 07/31/2012 03:43 PM, Steven Rostedt wrote:
> > >
> > > > That would be better. A hypervisor might be real-time capable (with
> > > > some effort kvm can do this), so we don't want to turn off real time
> > > > features just based on that.
> > >
> > > It would only turn off if you enable selftests and the timing falied. If
> > > the kvm had real time features, this most likely would fail anyway. But
> > > that said, here's a patch that should solve this:
> >
> > No luck.. it still fails:
>
> I bet you it didn't ;-)
>
> >
> > [2.360068] Testing tracer irqsoff: [2.854529]
> > [2.854828] ===
> > [2.855560] [ INFO: suspicious RCU usage. ]
> > [2.856266] 3.5.0-00024-g01ff5db-dirty #3 Not tainted
> > [2.857182] ---
> > [2.857933] /c/wfg/linux/include/linux/rcupdate.h:730 rcu_read_lock()
> > used illegally while idle!
> > [2.859450]
> > [2.859450] other info that might help us debug this:
> > [2.859450]
> > [2.860874]
> > [2.860874] RCU used illegally from idle CPU!
> > [2.860874] rcu_scheduler_active = 1, debug_locks = 0
> > [2.862754] RCU used illegally from extended quiescent state!
> > [2.863741] 2 locks held by swapper/0/0:
> >
> > [2.864377] #0: [2.864423] (max_trace_lock){..}, at:
> > [<814f6bfe>] check_critical_timing+0xd7/0x286
> > [2.864423] #1: (rcu_read_lock){.+.+..}, at: [<8116f930>]
> > __update_max_tr+0x0/0x430
> >
> > [2.864423] stack backtrace:
> > [2.864423] Pid: 0, comm: swapper/0 Not tainted
> > 3.5.0-00024-g01ff5db-dirty #3
> > [2.864423] Call Trace:
> > [2.864423] [<81103a06>] lockdep_rcu_suspicious+0x1c6/0x210
> > [2.864423] [<8116fc9a>] __update_max_tr+0x36a/0x430
> > [2.864423] [<8116f930>] ? tracing_record_cmdline+0x200/0x200
> > [2.864423] [<8117186e>] update_max_tr_single+0x14e/0x2c0
> > [2.864423] [<81170baa>] ? __trace_stack+0x2a/0x40
> > [2.864423] [<814f6d22>] check_critical_timing+0x1fb/0x286
> > [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> > [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> > [2.864423] [<8110a0e7>] ? trace_hardirqs_on+0x27/0x40
> > [2.864423] [<8117ea5e>] time_hardirqs_on+0x1de/0x220
> > [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> > [2.864423] [<81109d6d>] trace_hardirqs_on_caller+0x2d/0x380
> > [2.864423] [<8110a0e7>] trace_hardirqs_on+0x27/0x40
> > [2.864423] [<81013313>] default_idle+0x593/0xc30
> > [2.864423] [<8101692d>] cpu_idle+0x2dd/0x390
> > [2.864423] [<814eb841>] rest_init+0x2f5/0x314
> > [2.864423] [<814eb54c>] ? __read_lock_failed+0x14/0x14
> > [2.864423] [<817a43b4>] start_kernel+0x866/0x87a
>
> What was the next lines? I bet you it was "PASSED". Which means it did
> not fail. This is the second bug you found that has to do with RCU being
> called in 'idle'. The one that Paul posted a patch for.
Though it needs another patch to actually use it in the right place...
Thanx, Paul
--
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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Wed, 2012-08-01 at 07:43 +0800, Fengguang Wu wrote:
> On Tue, Jul 31, 2012 at 09:13:39AM -0400, Steven Rostedt wrote:
> > On Tue, 2012-07-31 at 15:50 +0300, Avi Kivity wrote:
> > > On 07/31/2012 03:43 PM, Steven Rostedt wrote:
> >
> > > That would be better. A hypervisor might be real-time capable (with
> > > some effort kvm can do this), so we don't want to turn off real time
> > > features just based on that.
> >
> > It would only turn off if you enable selftests and the timing falied. If
> > the kvm had real time features, this most likely would fail anyway. But
> > that said, here's a patch that should solve this:
>
> No luck.. it still fails:
I bet you it didn't ;-)
>
> [2.360068] Testing tracer irqsoff: [2.854529]
> [2.854828] ===
> [2.855560] [ INFO: suspicious RCU usage. ]
> [2.856266] 3.5.0-00024-g01ff5db-dirty #3 Not tainted
> [2.857182] ---
> [2.857933] /c/wfg/linux/include/linux/rcupdate.h:730 rcu_read_lock() used
> illegally while idle!
> [2.859450]
> [2.859450] other info that might help us debug this:
> [2.859450]
> [2.860874]
> [2.860874] RCU used illegally from idle CPU!
> [2.860874] rcu_scheduler_active = 1, debug_locks = 0
> [2.862754] RCU used illegally from extended quiescent state!
> [2.863741] 2 locks held by swapper/0/0:
>
> [2.864377] #0: [2.864423] (max_trace_lock){..}, at:
> [<814f6bfe>] check_critical_timing+0xd7/0x286
> [2.864423] #1: (rcu_read_lock){.+.+..}, at: [<8116f930>]
> __update_max_tr+0x0/0x430
>
> [2.864423] stack backtrace:
> [2.864423] Pid: 0, comm: swapper/0 Not tainted 3.5.0-00024-g01ff5db-dirty
> #3
> [2.864423] Call Trace:
> [2.864423] [<81103a06>] lockdep_rcu_suspicious+0x1c6/0x210
> [2.864423] [<8116fc9a>] __update_max_tr+0x36a/0x430
> [2.864423] [<8116f930>] ? tracing_record_cmdline+0x200/0x200
> [2.864423] [<8117186e>] update_max_tr_single+0x14e/0x2c0
> [2.864423] [<81170baa>] ? __trace_stack+0x2a/0x40
> [2.864423] [<814f6d22>] check_critical_timing+0x1fb/0x286
> [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> [2.864423] [<8110a0e7>] ? trace_hardirqs_on+0x27/0x40
> [2.864423] [<8117ea5e>] time_hardirqs_on+0x1de/0x220
> [2.864423] [<81013313>] ? default_idle+0x593/0xc30
> [2.864423] [<81109d6d>] trace_hardirqs_on_caller+0x2d/0x380
> [2.864423] [<8110a0e7>] trace_hardirqs_on+0x27/0x40
> [2.864423] [<81013313>] default_idle+0x593/0xc30
> [2.864423] [<8101692d>] cpu_idle+0x2dd/0x390
> [2.864423] [<814eb841>] rest_init+0x2f5/0x314
> [2.864423] [<814eb54c>] ? __read_lock_failed+0x14/0x14
> [2.864423] [<817a43b4>] start_kernel+0x866/0x87a
What was the next lines? I bet you it was "PASSED". Which means it did
not fail. This is the second bug you found that has to do with RCU being
called in 'idle'. The one that Paul posted a patch for.
-- Steve
--
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] platform: Add support for automatic device IDs
On Fri, Jul 27, 2012 at 10:14:59PM +0200, Jean Delvare wrote: > Right now we have support for explicit platform device IDs, as well as > ID-less platform devices when a given device type can only have one > instance. However there are cases where multiple instances of a device > type can exist, and their IDs aren't (and can't be) known in advance > and do not matter. In that case we need automatic device IDs to avoid > device name collisions. > > I am using magic ID value -2 (PLATFORM_DEVID_AUTO) for this, similar > to -1 for ID-less devices. The automatically allocated device IDs are > global (to avoid an additional per-driver cost.) We keep note that the > ID was automatically allocated so that it can be freed later. > > Note that we also restore the ID to PLATFORM_DEVID_AUTO on error and > device deletion, to avoid avoid unexpected behavior on retry. I don't > really expect retries on platform device addition, but better safe > than sorry. > > Signed-off-by: Jean Delvare > Cc: Greg Kroah-Hartman Looks sane to me, want me to queue it up for 3.7? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/crypto: fix pseries_defconfig break
Seth Jennings wrote: > As part of the Kconfig rework for drivers/crypto/nx, the meaning of > CONFIG_CRYPTO_DEV_NX was changed. At the same time this commit was > heading upstream > > fd297b3a7302ab866306f53c1fd1e97b083fe83e > powerpc: Enable pseries hardware RNG and crypto module > > still used the old meaning, set CONFIG_CRYPTO_DEV_NX=m when it > is now a bool in the Kconfig. This patch repairs the break. > > Reported-by: Michael Neuling > Signed-off-by: Seth Jennings > --- > This patch is based on Linus master which already contains > the commit above. Please apply this patch before my patchset > (powerpc/crypto: IBM Power7+ in-Nest compression support) to > avoid the pseries_defconfig break. > > arch/powerpc/configs/pseries_defconfig |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) ppc64_defconfig needs fixing too. grep CONFIG_CRYPTO_DEV_NX=m arch/powerpc/configs/* arch/powerpc/configs/ppc64_defconfig:CONFIG_CRYPTO_DEV_NX=m arch/powerpc/configs/pseries_defconfig:CONFIG_CRYPTO_DEV_NX=m Mikey > > diff --git a/arch/powerpc/configs/pseries_defconfig > b/arch/powerpc/configs/pseries_defconfig > index 1f65b3c..9f4a936 100644 > --- a/arch/powerpc/configs/pseries_defconfig > +++ b/arch/powerpc/configs/pseries_defconfig > @@ -369,7 +369,8 @@ CONFIG_CRYPTO_TWOFISH=m > CONFIG_CRYPTO_LZO=m > # CONFIG_CRYPTO_ANSI_CPRNG is not set > CONFIG_CRYPTO_HW=y > -CONFIG_CRYPTO_DEV_NX=m > +CONFIG_CRYPTO_DEV_NX=y > +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m > CONFIG_VIRTUALIZATION=y > CONFIG_KVM_BOOK3S_64=m > CONFIG_KVM_BOOK3S_64_HV=y > -- > 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] powerpc/crypto: fix pseries_defconfig break
Hi Seth, On Tue, 31 Jul 2012 18:34:51 -0500 Seth Jennings wrote: > > diff --git a/arch/powerpc/configs/pseries_defconfig > b/arch/powerpc/configs/pseries_defconfig > index 1f65b3c..9f4a936 100644 > --- a/arch/powerpc/configs/pseries_defconfig > +++ b/arch/powerpc/configs/pseries_defconfig > @@ -369,7 +369,8 @@ CONFIG_CRYPTO_TWOFISH=m > CONFIG_CRYPTO_LZO=m > # CONFIG_CRYPTO_ANSI_CPRNG is not set > CONFIG_CRYPTO_HW=y > -CONFIG_CRYPTO_DEV_NX=m > +CONFIG_CRYPTO_DEV_NX=y > +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m > CONFIG_VIRTUALIZATION=y > CONFIG_KVM_BOOK3S_64=m > CONFIG_KVM_BOOK3S_64_HV=y The same change is needed to ppc64_defconfig, please. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpcR8fZfzdgV.pgp Description: PGP signature
Re: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Jul 31, 2012 at 09:13:39AM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 15:50 +0300, Avi Kivity wrote:
> > On 07/31/2012 03:43 PM, Steven Rostedt wrote:
>
> > That would be better. A hypervisor might be real-time capable (with
> > some effort kvm can do this), so we don't want to turn off real time
> > features just based on that.
>
> It would only turn off if you enable selftests and the timing falied. If
> the kvm had real time features, this most likely would fail anyway. But
> that said, here's a patch that should solve this:
No luck.. it still fails:
[2.360068] Testing tracer irqsoff: [2.854529]
[2.854828] ===
[2.855560] [ INFO: suspicious RCU usage. ]
[2.856266] 3.5.0-00024-g01ff5db-dirty #3 Not tainted
[2.857182] ---
[2.857933] /c/wfg/linux/include/linux/rcupdate.h:730 rcu_read_lock() used
illegally while idle!
[2.859450]
[2.859450] other info that might help us debug this:
[2.859450]
[2.860874]
[2.860874] RCU used illegally from idle CPU!
[2.860874] rcu_scheduler_active = 1, debug_locks = 0
[2.862754] RCU used illegally from extended quiescent state!
[2.863741] 2 locks held by swapper/0/0:
[2.864377] #0: [2.864423] (max_trace_lock){..}, at: [<814f6bfe>]
check_critical_timing+0xd7/0x286
[2.864423] #1: (rcu_read_lock){.+.+..}, at: [<8116f930>]
__update_max_tr+0x0/0x430
[2.864423] stack backtrace:
[2.864423] Pid: 0, comm: swapper/0 Not tainted 3.5.0-00024-g01ff5db-dirty #3
[2.864423] Call Trace:
[2.864423] [<81103a06>] lockdep_rcu_suspicious+0x1c6/0x210
[2.864423] [<8116fc9a>] __update_max_tr+0x36a/0x430
[2.864423] [<8116f930>] ? tracing_record_cmdline+0x200/0x200
[2.864423] [<8117186e>] update_max_tr_single+0x14e/0x2c0
[2.864423] [<81170baa>] ? __trace_stack+0x2a/0x40
[2.864423] [<814f6d22>] check_critical_timing+0x1fb/0x286
[2.864423] [<81013313>] ? default_idle+0x593/0xc30
[2.864423] [<81013313>] ? default_idle+0x593/0xc30
[2.864423] [<8110a0e7>] ? trace_hardirqs_on+0x27/0x40
[2.864423] [<8117ea5e>] time_hardirqs_on+0x1de/0x220
[2.864423] [<81013313>] ? default_idle+0x593/0xc30
[2.864423] [<81109d6d>] trace_hardirqs_on_caller+0x2d/0x380
[2.864423] [<8110a0e7>] trace_hardirqs_on+0x27/0x40
[2.864423] [<81013313>] default_idle+0x593/0xc30
[2.864423] [<8101692d>] cpu_idle+0x2dd/0x390
[2.864423] [<814eb841>] rest_init+0x2f5/0x314
[2.864423] [<814eb54c>] ? __read_lock_failed+0x14/0x14
[2.864423] [<817a43b4>] start_kernel+0x866/0x87a
Thanks,
Fengguang
--
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] powerpc/crypto: fix pseries_defconfig break
As part of the Kconfig rework for drivers/crypto/nx, the meaning of CONFIG_CRYPTO_DEV_NX was changed. At the same time this commit was heading upstream fd297b3a7302ab866306f53c1fd1e97b083fe83e powerpc: Enable pseries hardware RNG and crypto module still used the old meaning, set CONFIG_CRYPTO_DEV_NX=m when it is now a bool in the Kconfig. This patch repairs the break. Reported-by: Michael Neuling Signed-off-by: Seth Jennings --- This patch is based on Linus master which already contains the commit above. Please apply this patch before my patchset (powerpc/crypto: IBM Power7+ in-Nest compression support) to avoid the pseries_defconfig break. arch/powerpc/configs/pseries_defconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig index 1f65b3c..9f4a936 100644 --- a/arch/powerpc/configs/pseries_defconfig +++ b/arch/powerpc/configs/pseries_defconfig @@ -369,7 +369,8 @@ CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y -CONFIG_CRYPTO_DEV_NX=m +CONFIG_CRYPTO_DEV_NX=y +CONFIG_CRYPTO_DEV_NX_ENCRYPT=m CONFIG_VIRTUALIZATION=y CONFIG_KVM_BOOK3S_64=m CONFIG_KVM_BOOK3S_64_HV=y -- 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 1/6] w1: omap-hdq: add section annotation to remove
On Wed, Aug 01, 2012 at 03:19:10AM +0400, Evgeniy Polyakov wrote: > On Fri, Jul 27, 2012 at 10:04:44AM +0300, Felipe Balbi (ba...@ti.com) wrote: > > > Feel free to add my acked-by: Evgeniy Polyakov > > > > I thought you would :-p Then I guess Tony, maybe ? > > Greg, will you pick this patchset? > It is fairly simple and without any behaviour changes, but things look > like being stuck here... Yes, after 3.6-rc1 is out I will. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] xconfig: Display dependency values in debug_info
On 07/31/2012 11:58 AM, Salar Ali Mumtaz wrote:
> Now the debug_info only shows y/n/m values.
>
or no value at all??
for CONFIG_BINFMT_ELF:
Kernel support for ELF binaries (BINFMT_ELF)
type: boolean
unknown property: symbol
dep: ( MMU y && (BROKEN n || !FRV ) ) =y
prompt: Kernel support for ELF binaries
dep: ( MMU y && (BROKEN n || !FRV ) ) =y
default: y
dep: ( MMU y && (BROKEN n || !FRV ) ) =y
defined at fs/Kconfig.binfmt:1
CONFIG_BINFMT_ELF:
> Signed-off-by: Salar Ali Mumtaz
> ---
> scripts/kconfig/qconf.cc | 14 +-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> index df274fe..b6a7cc5 100644
> --- a/scripts/kconfig/qconf.cc
> +++ b/scripts/kconfig/qconf.cc
> @@ -1073,8 +1073,10 @@ QString ConfigInfoView::debug_info(struct symbol *sym)
> debug += " (choice)";
> debug += "";
> if (sym->rev_dep.expr) {
> - debug += "reverse dep: ";
> + debug += "reverse dep: (";
> expr_print(sym->rev_dep.expr, expr_print_help, , E_NONE);
> + debug += " ) =";
> + debug += print_filter(sym_get_string_value(sym));
> debug += "";
> }
> for (struct property *prop = sym->prop; prop; prop = prop->next) {
> @@ -1108,7 +1110,10 @@ QString ConfigInfoView::debug_info(struct symbol *sym)
> }
> if (prop->visible.expr) {
> debug += "dep: ";
> + debug += " ( ";
> expr_print(prop->visible.expr, expr_print_help, ,
> E_NONE);
> + debug += " ) =";
> + debug += print_filter(sym_get_string_value(sym));
> debug += "";
> }
> }
> @@ -1152,11 +1157,18 @@ void ConfigInfoView::expr_print_help(void *data,
> struct symbol *sym, const char
> {
> QString* text = reinterpret_cast(data);
> QString str2 = print_filter(str);
> + QString value;
>
> if (sym && sym->name && !(sym->flags & SYMBOL_CONST)) {
> + value = print_filter(sym_get_string_value(sym));
> +
> *text += QString().sprintf("", sym);
> *text += str2;
> *text += "";
> + *text += " ";
> + if(value == "y" || value == "m" || value == "n")
> + *text += print_filter(sym_get_string_value(sym));
> + *text += "";
> } else
> *text += str2;
> }
thanks,
--
~Randy
--
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] gpio: samsung: Fix off-by-one bug in gpio addresses
Linus Walleij wrote: > > On Fri, Jul 20, 2012 at 10:58 PM, Sean Paul wrote: > > > Move gpc4 to the end of the automatically processed gpio controllers so > > we don't taint the automatic offset calculation. > > > > This bug caused all controllers coming after gpc4 to map to the > > incorrect address. The result is < 0 0 0 0> would actually map to > > GPIO 0 in gpd0. > > > > Signed-off-by: Sean Paul > > Samsung people, please comment on this patch. > Looks good to me, please keep going on. And feel free to add my ack on this. Acked-by: Kukjin Kim Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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] gpio: Add Avionic Design N-bit GPIO expander support
On 07/31/2012 04:03 PM, Rob Herring wrote: > On 07/30/2012 02:47 AM, Thierry Reding wrote: >> On Sun, Jul 29, 2012 at 07:13:57PM +0200, Linus Walleij wrote: >>> On Mon, Jul 23, 2012 at 1:59 PM, Thierry Reding >>> wrote: >>> This commit adds a driver for the Avionic Design N-bit GPIO expander. The expander provides a variable number of GPIO pins with interrupt support. diff --git a/Documentation/devicetree/bindings/gpio/gpio-adnp.txt b/Documentation/devicetree/bindings/gpio/gpio-adnp.txt +Required properties: +- nr-gpios: The number of pins supported by the controller. > For nr-gpios, I think it is typically not needed. Generally, you will > know how many gpio lines the h/w has based on the compatible string. If > this part really is the same part but different packages with different > numbers of gpio, then this property makes sense. Otherwise, I would say > drop it. > > If your goal is how many gpios are you using, you really need a bitmap > instead if you want it to be generic. > > IIRC, Tegra also needed this in that they N instances of some number of > bits and the registers are interleaved so they can't have separate nodes. In the end, I got away without having a separate property to represent this. Instead, the code keys off the number of interrupts listed in the interrupts property, there being one interrupt per GPIO bank, and hence dynamically instantiates the number of banks based on that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] drivers/video/exynos/exynos_dp_core.c: use devm_ functions
On Wednesday, August 01, 2012 1:39 AM Damien Cassou wrote:
>
> From: Damien Cassou
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou
>
> ---
> drivers/video/exynos/exynos_dp_core.c | 27 +++
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c
> b/drivers/video/exynos/exynos_dp_core.c
> index c6c016a..00fe4f0 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -872,7 +872,7 @@ static int __devinit exynos_dp_probe(struct
> platform_device *pdev)
>
> dp->dev = >dev;
>
> - dp->clock = clk_get(>dev, "dp");
> + dp->clock = devm_clk_get(>dev, "dp");
> if (IS_ERR(dp->clock)) {
> dev_err(>dev, "failed to get clock\n");
> return PTR_ERR(dp->clock);
> @@ -881,31 +881,24 @@ static int __devinit exynos_dp_probe(struct
> platform_device *pdev)
> clk_enable(dp->clock);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(>dev, "failed to get registers\n");
> - ret = -EINVAL;
> - goto err_clock;
> - }
Why do you remove this return check?
If there is no reason, please, do it as follows:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(>dev, "failed to get registers\n");
- ret = -EINVAL;
- goto err_clock;
+ return -EINVAL;
}
Best regards,
Jingoo Han
>
> dp->reg_base = devm_request_and_ioremap(>dev, res);
> if (!dp->reg_base) {
> dev_err(>dev, "failed to ioremap\n");
> - ret = -ENOMEM;
> - goto err_clock;
> + return -ENOMEM;
> }
>
> dp->irq = platform_get_irq(pdev, 0);
> if (!dp->irq) {
> dev_err(>dev, "failed to get irq\n");
> - ret = -ENODEV;
> - goto err_clock;
> + return -ENODEV;
> }
>
> ret = devm_request_irq(>dev, dp->irq, exynos_dp_irq_handler, 0,
> "exynos-dp", dp);
> if (ret) {
> dev_err(>dev, "failed to request irq\n");
> - goto err_clock;
> + return ret;
> }
>
> dp->video_info = pdata->video_info;
> @@ -917,7 +910,7 @@ static int __devinit exynos_dp_probe(struct
> platform_device *pdev)
> ret = exynos_dp_detect_hpd(dp);
> if (ret) {
> dev_err(>dev, "unable to detect hpd\n");
> - goto err_clock;
> + return ret;
> }
>
> exynos_dp_handle_edid(dp);
> @@ -926,7 +919,7 @@ static int __devinit exynos_dp_probe(struct
> platform_device *pdev)
> dp->video_info->link_rate);
> if (ret) {
> dev_err(>dev, "unable to do link train\n");
> - goto err_clock;
> + return ret;
> }
>
> exynos_dp_enable_scramble(dp, 1);
> @@ -940,17 +933,12 @@ static int __devinit exynos_dp_probe(struct
> platform_device *pdev)
> ret = exynos_dp_config_video(dp, dp->video_info);
> if (ret) {
> dev_err(>dev, "unable to config video\n");
> - goto err_clock;
> + return ret;
> }
>
> platform_set_drvdata(pdev, dp);
>
> return 0;
> -
> -err_clock:
> - clk_put(dp->clock);
> -
> - return ret;
> }
>
> static int __devexit exynos_dp_remove(struct platform_device *pdev)
> @@ -962,7 +950,6 @@ static int __devexit exynos_dp_remove(struct
> platform_device *pdev)
> pdata->phy_exit();
>
> clk_disable(dp->clock);
> - clk_put(dp->clock);
>
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 35/73] ASoC: dapm: Fix locking during codec shutdown
On Tue, 2012-07-31 at 17:13 +0100, Mark Brown wrote: > On Tue, Jul 31, 2012 at 01:11:01PM -0300, Herton Ronaldo Krzesinski wrote: > > > Hi, this doesn't build on 3.2: > > > linux-stable/sound/soc/soc-dapm.c: In function 'soc_dapm_shutdown_codec': > > linux-stable/sound/soc/soc-dapm.c:2982:18: error: 'struct snd_soc_card' has > > no member named 'dapm_mutex' > > linux-stable/sound/soc/soc-dapm.c:3007:20: error: 'struct snd_soc_card' has > > no member named 'dapm_mutex' > > > Looking at it, I'm not sure the fix is needed on 3.2, and introducing > > dapm_mutex would be several changes. > > Yes, this is irrelevant on v3.2. OK, I've dropped this. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/6] w1: omap-hdq: add section annotation to remove
On Fri, Jul 27, 2012 at 10:04:44AM +0300, Felipe Balbi (ba...@ti.com) wrote: > > Feel free to add my acked-by: Evgeniy Polyakov > > I thought you would :-p Then I guess Tony, maybe ? Greg, will you pick this patchset? It is fairly simple and without any behaviour changes, but things look like being stuck here... -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On 07/30/2012 11:25 AM, Mark Brown wrote: > On Mon, Jul 30, 2012 at 11:00:04AM -0600, Stephen Warren wrote: >> On 07/29/2012 02:36 PM, Mark Brown wrote: >>> On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote: > >> I had implemented this in regmap since you'd specifically mentioned >> doing that. If I convert the code not to use separate IRQ domains for > > I think what I'd said was that we should factor it out rather than that > it should be specifically done in regmap. > >> this, would that be acceptable? > > Probably. The more I think about this, the more I prefer the way the way it is in the patch I posted. I don't think it's appropriate to put this support into the IRQ core. The main issue is that all the handlers for any shared wired-or interrupt line have to be registered before the IRQ is enabled, to avoid some initially active interrupt continually firing before the IRQ is enabled. Co-ordinating this when the wired-or line is on a board outside a device driver rather than internal to a chip and one device driver is a bit more than the IRQ core should probably be doing, hence I imagine why it doesn't support it. Co-ordinating this setup where all the sources of the wired-or are in one chip seems to belong to the chip driver, which is where my patch did this. I guess I could modify regmaps_irq_thread() so that instead of: for (i = 0; i < d->nchips; i++) handle_nested_irq(irq_find_mapping(d->irqdom, i)); ... it short-circuited and instead did something like: for (i = 0; i < d->nchips; i++) regmap_irq_thread(irq_find_mapping(d->irqdom, i), d->datas[i]); but it seems a little hokey to short-circuit the IRQ core; it would prevent execution of any statistics gathering or stuck interrupt handling that handle_nested_irq() might do for example. Now, if we made each child regmap_irq not be its own IRQ domain or irq_chip, but simply had one top-level domain/chip that aggregated them, that argument would be moot. However, that top-level domain/chip would become rather complex and just end up doing a bunch of demultiplexing code that's not needed if we do it like in my patch... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
On Tue, Jul 31, 2012 at 05:48:38PM -0500, Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
> and if that happens on the first insertion, the host controller
> port will enter in Compliance Mode as per xHCI Spec. The patch
> creates a timer which polls every 2 seconds the link state of each
> host controller's port (this by reading the PORTSC register) and
> recovers the port by issuing a Warm reset every time Compliance mode
> is detected.
>
> Signed-off-by: Alexis R. Cortes
> ---
> drivers/usb/host/xhci-hub.c | 27 ++
> drivers/usb/host/xhci.c | 81
> +++
> drivers/usb/host/xhci.h |6 +++
> 3 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 7b01094..4ea498d 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -493,7 +493,19 @@ static void xhci_hub_report_link_state(u32 *status, u32
> status_reg)
>* when this bit is set.
>*/
> pls |= USB_PORT_STAT_CONNECTION;
> + } else {
> + /*
> + * If CAS bit isn't set but the Port is already at
> + * Compliance Mode, fake a connection so the USB core
> + * notices the Compliance state and resets the port.
> + * This resolves an issue generated by the SN65LVPE502CP
> + * in which sometimes the port enters compliance mode
> + * caused by a delay on the host-device negotiation.
> + */
> + if (pls == USB_SS_PORT_LS_COMP_MOD)
> + pls |= USB_PORT_STAT_CONNECTION;
> }
> +
> /* update status field */
> *status |= pls;
> }
> @@ -645,6 +657,21 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
> u16 wValue,
> /* Update Port Link State for super speed ports*/
> if (hcd->speed == HCD_USB3) {
> xhci_hub_report_link_state(, temp);
> + /*
> + * Verify if all USB3 Ports Have entered U0. Delete
> compliance
> + * mode timer if so.
> + */
> + if (xhci->quirks & XHCI_COMP_MODE_QUIRK) {
> + if (xhci->port_status_u0 != ((1 <<
> xhci->num_usb3_ports)-1)) {
> + if ((temp & PORT_PLS_MASK) == XDEV_U0)
> + xhci->port_status_u0 |= 1 <<
> wIndex;
> + } else {
> + /* Deleting Compliance Mode Recovery
> Timer */
> + if
> (del_timer_sync(>comp_mode_recovery_timer))
> + xhci_dbg(xhci, "Compliance Mode
> Recovery Timer Deleted. "
> +"All USB3 ports
> have entered U0 at least once.\n");
You need to disable the quirk flag here now, right? Otherwise can't the
timer be deleted twice if the module is unloaded after this happens?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
On Tue, Jul 31, 2012 at 05:54:04PM -0500, Alexis Cortes wrote: > Hi Greg, > > I have resent the patch. Hopefully it know arrives properly. BTW, I'm using > Thunderbird configured as described in Documentation/email-clients.txt for > sending the patch. The resend looks like it worked properly, thanks for resending it. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 20/22] ARM: keystone: introducing TI Keystone platform
On Tuesday 31 July 2012, Cyril Chemparathy wrote:
> Texas Instruments Keystone family of multicore devices now includes an
> upcoming slew of Cortex A15 based devices. This patch adds basic definitions
> for a new Keystone sub-architecture in ARM.
>
> Subsequent patches in this series will extend support to include SMP and take
> advantage of the large physical memory addressing capabilities via LPAE.
>
> Signed-off-by: Vitaly Andrianov
> Signed-off-by: Cyril Chemparathy
Reviewed-by: Arnd Bergmann
And some nitpicking:
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 debug earlyprintk lpj=5
> rdinit=/bin/ash rw root=/dev/ram0 initrd=0x8500,9M";
> + };
This command line should not really be here. Most of what you put in it is not
generic to the platform at all.
In order to select the console, use an alias for the serial device.
> +
> +static void __init keystone_map_io(void)
> +{
> + iotable_init(io_desc, sizeof(io_desc)/sizeof(struct map_desc));
> +}
Use the ARRAY_SIZE macro here.
Arnd
--
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 v2 1/2] PCI-Express Non-Transparent Bridge Support
On Tue, Jul 31, 2012 at 03:51:05PM -0700, Jon Mason wrote: > On Tue, Jul 31, 2012 at 03:23:38PM -0700, Greg KH wrote: > > On Sun, Jul 29, 2012 at 05:26:33PM -0700, Jon Mason wrote: > > > + * You should have received a copy of the GNU General Public License > > > + * along with this program; if not, write to the Free Software > > > + * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA > > > 02110-1301 USA. > > > > You really are going to track the FSF's office movements for the next > > 40+ years? > > > > > + * The full GNU General Public License is included in this distribution > > > + * in the file called LICENSE.GPL. > > > > No it isn't, this sentance is totally wrong for any in-kernel code, > > please remove it. > > > > Also do the same for all the other files you added please. > > I echo'ed your original comments on this to Intel Legal and am waiting > on a response. I 100% agree, but I need their signoff first. > > It is worth noting that this version of the license is already in the > kernel in numerous other drivers: > drivers/sfi/* > drivers/scsi/isci/* > drivers/dma/ioat/dma_v3.c > drivers/net/wireless/iwlwifi/* > drivers/net/wireless/iwlegacy/* Just because others got it wrong, doesn't mean you need to continue to :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 06/73] mm: compaction: introduce sync-light migration for use by compaction
On Tue, 2012-07-31 at 18:03 +0100, Mel Gorman wrote: > On Tue, Jul 31, 2012 at 06:00:51PM +0100, Mel Gorman wrote: > > On Tue, Jul 31, 2012 at 01:42:04PM -0300, Herton Ronaldo Krzesinski wrote: > > > On Tue, Jul 31, 2012 at 05:43:16AM +0100, Ben Hutchings wrote: > > > > 3.2-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > > > -- > > > > > > > > From: Mel Gorman > > > > > > > > commit a6bc32b899223a877f595ef9ddc1e89ead5072b8 upstream. > > > > > > We need also to pick recent fix dc32f63453f56d07a1073a697dcd843dd3098c09 > > > after > > > applying this one. > > > > > > > mel@machina:~/git-public/linux-2.6 > git remote update > > Fetching linux-next > > Fetching stable > > Fetching net-next > > mel@machina:~/git-public/linux-2.6 > git show > > dc32f63453f56d07a1073a697dcd843dd3098c09 > > fatal: bad object dc32f63453f56d07a1073a697dcd843dd3098c09 > > > > What commit is this, where did it come from and why is it needed? > > > > Bah, I'm an idiot. Yes, this patch should be included as well. OK, I've added this. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
[PATCH 16/22] ARM: mm: cleanup checks for membank overlap with vmalloc area
On Keystone platforms, physical memory is entirely outside the 32-bit
addressible range. Therefore, the (bank->start > ULONG_MAX) check below marks
the entire system memory as highmem, and this causes unpleasentness all over.
This patch eliminates the extra bank start check (against ULONG_MAX) by
checking bank->start against the physical address corresponding to vmalloc_min
instead.
In the process, this patch also cleans up parts of the highmem sanity check
code by removing what has now become a redundant check for banks that entirely
overlap with the vmalloc range.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/mm/mmu.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index adaf8c3..4840efa 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -907,15 +907,12 @@ void __init sanity_check_meminfo(void)
struct membank *bank = [j];
*bank = meminfo.bank[i];
- if (bank->start > ULONG_MAX)
- highmem = 1;
-
-#ifdef CONFIG_HIGHMEM
if (bank->start >= vmalloc_limit)
highmem = 1;
bank->highmem = highmem;
+#ifdef CONFIG_HIGHMEM
/*
* Split those memory banks which are partially overlapping
* the vmalloc area greatly simplifying things later.
@@ -938,8 +935,6 @@ void __init sanity_check_meminfo(void)
bank->size = vmalloc_limit - bank->start;
}
#else
- bank->highmem = highmem;
-
/*
* Highmem banks not allowed with !CONFIG_HIGHMEM.
*/
@@ -952,18 +947,6 @@ void __init sanity_check_meminfo(void)
}
/*
-* Check whether this memory bank would entirely overlap
-* the vmalloc area.
-*/
- if (bank->start >= vmalloc_limit) {
- printk(KERN_NOTICE "Ignoring RAM at %.8llx-%.8llx "
- "(vmalloc region overlap).\n",
- (unsigned long long)bank->start,
- (unsigned long long)bank->start + bank->size -
1);
- continue;
- }
-
- /*
* Check whether this memory bank would partially overlap
* the vmalloc area.
*/
--
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 18/22] ARM: add virt_to_idmap for interconnect aliasing
From: Vitaly Andrianov
On some PAE systems (e.g. TI Keystone), memory is above the 32-bit addressible
limit, and the interconnect provides an aliased view of parts of physical
memory in the 32-bit addressible space. This alias is strictly for boot time
usage, and is not otherwise usable because of coherency limitations.
On such systems, the idmap mechanism needs to take this aliased mapping into
account. This patch introduces a virt_to_idmap() macro, which can be used on
such sub-architectures to represent the interconnect supported boot time
alias. Most other systems would leave this macro untouched, i.e., do a simply
virt_to_phys() and nothing more.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/include/asm/memory.h |9 +
arch/arm/kernel/smp.c |4 ++--
arch/arm/mm/idmap.c |4 ++--
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 0c1b396..4bf47ed 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -231,6 +231,15 @@ static inline void *phys_to_virt(phys_addr_t x)
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
/*
+ * These are for systems that have a hardware interconnect supported alias of
+ * physical memory for idmap purposes. Most cases should leave these
+ * untouched.
+ */
+#ifndef virt_to_idmap
+#define virt_to_idmap(x) virt_to_phys(x)
+#endif
+
+/*
* Virtual <-> DMA view memory address translations
* Again, these are *only* valid on the kernel direct mapped RAM
* memory. Use of these is *deprecated* (and that doesn't mean
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index e41e1be..cce630c 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -72,10 +72,10 @@ int __cpuinit __cpu_up(unsigned int cpu, struct task_struct
*idle)
*/
secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
- pgdir = virt_to_phys(idmap_pgd);
+ pgdir = virt_to_idmap(idmap_pgd);
secondary_data.pgdir = pgdir >> ARCH_PGD_SHIFT;
- pgdir = virt_to_phys(swapper_pg_dir);
+ pgdir = virt_to_idmap(swapper_pg_dir);
secondary_data.swapper_pg_dir = pgdir >> ARCH_PGD_SHIFT;
__cpuc_flush_dcache_area(_data, sizeof(secondary_data));
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index ab88ed4..919cb6e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -85,8 +85,8 @@ static int __init init_static_idmap(void)
return -ENOMEM;
/* Add an identity mapping for the physical address of the section. */
- idmap_start = virt_to_phys((void *)__idmap_text_start);
- idmap_end = virt_to_phys((void *)__idmap_text_end);
+ idmap_start = virt_to_idmap((void *)__idmap_text_start);
+ idmap_end = virt_to_idmap((void *)__idmap_text_end);
pr_info("Setting up static identity map for 0x%llx - 0x%llx\n",
(long long)idmap_start, (long long)idmap_end);
--
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 06/22] ARM: LPAE: use phys_addr_t in alloc_init_pud()
From: Vitaly Andrianov
This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
unsigned long when passing in the phys argument.
This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a, which
applied similar changes elsewhere in the ARM memory management code.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/mm/mmu.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index cf4528d..226985c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -628,7 +628,8 @@ static void __init alloc_init_section(pud_t *pud, unsigned
long addr,
}
static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
- unsigned long end, unsigned long phys, const struct mem_type *type)
+ unsigned long end, phys_addr_t phys,
+ const struct mem_type *type)
{
pud_t *pud = pud_offset(pgd, addr);
unsigned long next;
--
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 11/22] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem
This patch adds an architecture defined override for ARCH_LOW_ADDRESS_LIMIT. On PAE systems, the absence of this override causes bootmem to incorrectly limit itself to 32-bit addressable physical memory. Signed-off-by: Cyril Chemparathy Signed-off-by: Vitaly Andrianov --- arch/arm/include/asm/memory.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h index 110495c..0c1b396 100644 --- a/arch/arm/include/asm/memory.h +++ b/arch/arm/include/asm/memory.h @@ -281,6 +281,8 @@ static inline __deprecated void *bus_to_virt(unsigned long x) #define arch_is_coherent() 0 #endif +#define ARCH_LOW_ADDRESS_LIMIT PHYS_MASK + #endif #include -- 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 15/22] ARM: mm: use physical addresses in highmem sanity checks
This patch modifies the highmem sanity checking code to use physical addresses
instead. This change eliminates the wrap-around problems associated with the
original virtual address based checks, and this simplifies the code a bit.
The one constraint imposed here is that low physical memory must be mapped in
a monotonically increasing fashion if there are multiple banks of memory,
i.e., x < y must => pa(x) < pa(y).
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/mm/mmu.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 226985c..adaf8c3 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -901,6 +901,7 @@ phys_addr_t arm_lowmem_limit __initdata = 0;
void __init sanity_check_meminfo(void)
{
int i, j, highmem = 0;
+ phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
for (i = 0, j = 0; i < meminfo.nr_banks; i++) {
struct membank *bank = [j];
@@ -910,8 +911,7 @@ void __init sanity_check_meminfo(void)
highmem = 1;
#ifdef CONFIG_HIGHMEM
- if (__va(bank->start) >= vmalloc_min ||
- __va(bank->start) < (void *)PAGE_OFFSET)
+ if (bank->start >= vmalloc_limit)
highmem = 1;
bank->highmem = highmem;
@@ -920,8 +920,8 @@ void __init sanity_check_meminfo(void)
* Split those memory banks which are partially overlapping
* the vmalloc area greatly simplifying things later.
*/
- if (!highmem && __va(bank->start) < vmalloc_min &&
- bank->size > vmalloc_min - __va(bank->start)) {
+ if (!highmem && bank->start < vmalloc_limit &&
+ bank->size > vmalloc_limit - bank->start) {
if (meminfo.nr_banks >= NR_BANKS) {
printk(KERN_CRIT "NR_BANKS too low, "
"ignoring high memory\n");
@@ -930,12 +930,12 @@ void __init sanity_check_meminfo(void)
(meminfo.nr_banks - i) * sizeof(*bank));
meminfo.nr_banks++;
i++;
- bank[1].size -= vmalloc_min - __va(bank->start);
- bank[1].start = __pa(vmalloc_min - 1) + 1;
+ bank[1].size -= vmalloc_limit - bank->start;
+ bank[1].start = vmalloc_limit;
bank[1].highmem = highmem = 1;
j++;
}
- bank->size = vmalloc_min - __va(bank->start);
+ bank->size = vmalloc_limit - bank->start;
}
#else
bank->highmem = highmem;
@@ -955,8 +955,7 @@ void __init sanity_check_meminfo(void)
* Check whether this memory bank would entirely overlap
* the vmalloc area.
*/
- if (__va(bank->start) >= vmalloc_min ||
- __va(bank->start) < (void *)PAGE_OFFSET) {
+ if (bank->start >= vmalloc_limit) {
printk(KERN_NOTICE "Ignoring RAM at %.8llx-%.8llx "
"(vmalloc region overlap).\n",
(unsigned long long)bank->start,
@@ -968,9 +967,8 @@ void __init sanity_check_meminfo(void)
* Check whether this memory bank would partially overlap
* the vmalloc area.
*/
- if (__va(bank->start + bank->size) > vmalloc_min ||
- __va(bank->start + bank->size) < __va(bank->start)) {
- unsigned long newsize = vmalloc_min - __va(bank->start);
+ if (bank->start + bank->size > vmalloc_limit)
+ unsigned long newsize = vmalloc_limit - bank->start;
printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx "
"to -%.8llx (vmalloc region overlap).\n",
(unsigned long long)bank->start,
--
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/
[RFC 22/22] ARM: keystone: add switch over to high physical address range
Keystone platforms have their physical memory mapped at an address outside the
32-bit physical range. A Keystone machine with 16G of RAM would find its
memory at 0x08 - 0x0b.
For boot purposes, the interconnect supports a limited alias of some of this
memory within the 32-bit addressable space (0x8000 - 0x). This
aliasing is implemented in hardware, and is not intended to be used much
beyond boot. For instance, DMA coherence does not work when running out of
this aliased address space.
Therefore, we've taken the approach of booting out of the low physical address
range, and subsequently we switch over to the high range once we're safely
inside machine specific territory. This patch implements this switch over
mechanism, which involves rewiring the TTBRs and page tables to point to the
new physical address space.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/Kconfig |1 +
arch/arm/boot/dts/keystone-sim.dts |8 +++---
arch/arm/configs/keystone_defconfig |1 +
arch/arm/mach-keystone/include/mach/memory.h | 25 +
arch/arm/mach-keystone/keystone.c| 37 ++
arch/arm/mach-keystone/platsmp.c | 18 +++--
6 files changed, 84 insertions(+), 6 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7a76924..33a17c7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -373,6 +373,7 @@ config ARCH_KEYSTONE
select NEED_MACH_MEMORY_H
select HAVE_SCHED_CLOCK
select HAVE_SMP
+ select ZONE_DMA if ARM_LPAE
help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
diff --git a/arch/arm/boot/dts/keystone-sim.dts
b/arch/arm/boot/dts/keystone-sim.dts
index 118d631..5912fa1 100644
--- a/arch/arm/boot/dts/keystone-sim.dts
+++ b/arch/arm/boot/dts/keystone-sim.dts
@@ -4,8 +4,8 @@
/ {
model = "Texas Instruments Keystone 2 SoC";
compatible = "ti,keystone-evm";
- #address-cells = <1>;
- #size-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
interrupt-parent = <>;
aliases {
@@ -13,11 +13,11 @@
};
chosen {
- bootargs = "console=ttyS0,115200n8 debug earlyprintk lpj=5
rdinit=/bin/ash rw root=/dev/ram0 initrd=0x8500,9M";
+ bootargs = "console=ttyS0,115200n8 debug earlyprintk lpj=5
rdinit=/bin/ash rw root=/dev/ram0 initrd=0x80500,9M";
};
memory {
- reg = <0x8000 0x800>;
+ reg = <0x0008 0x 0x 0x800>;
};
cpus {
diff --git a/arch/arm/configs/keystone_defconfig
b/arch/arm/configs/keystone_defconfig
index 5f71e66..8ea3b96 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -1,6 +1,7 @@
CONFIG_EXPERIMENTAL=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_ARCH_KEYSTONE=y
+CONFIG_ARM_LPAE=y
CONFIG_SMP=y
CONFIG_ARM_ARCH_TIMER=y
CONFIG_NR_CPUS=4
diff --git a/arch/arm/mach-keystone/include/mach/memory.h
b/arch/arm/mach-keystone/include/mach/memory.h
index 7c78b1e..a5f7a1a 100644
--- a/arch/arm/mach-keystone/include/mach/memory.h
+++ b/arch/arm/mach-keystone/include/mach/memory.h
@@ -19,4 +19,29 @@
#define MAX_PHYSMEM_BITS 36
#define SECTION_SIZE_BITS 34
+#define KEYSTONE_LOW_PHYS_START0x8000ULL
+#define KEYSTONE_LOW_PHYS_SIZE 0x8000ULL /* 2G */
+#define KEYSTONE_LOW_PHYS_END (KEYSTONE_LOW_PHYS_START + \
+KEYSTONE_LOW_PHYS_SIZE - 1)
+
+#define KEYSTONE_HIGH_PHYS_START 0x8ULL
+#define KEYSTONE_HIGH_PHYS_SIZE0x4ULL /* 16G */
+#define KEYSTONE_HIGH_PHYS_END (KEYSTONE_HIGH_PHYS_START + \
+KEYSTONE_HIGH_PHYS_SIZE - 1)
+#ifdef CONFIG_ARM_LPAE
+
+#ifndef __ASSEMBLY__
+
+static inline phys_addr_t __virt_to_idmap(unsigned long x)
+{
+ return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET +
+ KEYSTONE_LOW_PHYS_START;
+}
+
+#define virt_to_idmap(x) __virt_to_idmap((unsigned long)(x))
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* CONFIG_ARM_LPAE */
+
#endif /* __ASM_MACH_MEMORY_H */
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index a4eed57..e8aee85 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -74,6 +74,39 @@ static const char *keystone_match[] __initconst = {
NULL,
};
+static void __init keystone_init_meminfo(void)
+{
+ bool lpae = IS_ENABLED(CONFIG_ARM_LPAE);
+ bool pvpatch = IS_ENABLED(CONFIG_ARM_PATCH_PHYS_VIRT);
+ phys_addr_t mem_start, mem_end;
+
+ BUG_ON(meminfo.nr_banks < 1);
+
+ mem_start = meminfo.bank[0].start;
+ mem_end = mem_start + meminfo.bank[0].size - 1;
+
+ /*
[RFC 21/22] ARM: keystone: enable SMP on Keystone machines
This patch adds basic SMP support for Keystone machines. Nothing very fancy
here, just enough to get 4 CPUs booted up. This does not include support for
hotplug, etc.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/Kconfig|1 +
arch/arm/configs/keystone_defconfig |2 +
arch/arm/mach-keystone/Makefile |1 +
arch/arm/mach-keystone/keystone.c |3 ++
arch/arm/mach-keystone/keystone.h | 23 +++
arch/arm/mach-keystone/platsmp.c| 74 +++
6 files changed, 104 insertions(+)
create mode 100644 arch/arm/mach-keystone/keystone.h
create mode 100644 arch/arm/mach-keystone/platsmp.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e0588e3..7a76924 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -372,6 +372,7 @@ config ARCH_KEYSTONE
select SPARSE_IRQ
select NEED_MACH_MEMORY_H
select HAVE_SCHED_CLOCK
+ select HAVE_SMP
help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
diff --git a/arch/arm/configs/keystone_defconfig
b/arch/arm/configs/keystone_defconfig
index 7f2a04b..5f71e66 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -1,7 +1,9 @@
CONFIG_EXPERIMENTAL=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_ARCH_KEYSTONE=y
+CONFIG_SMP=y
CONFIG_ARM_ARCH_TIMER=y
+CONFIG_NR_CPUS=4
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_VFP=y
diff --git a/arch/arm/mach-keystone/Makefile b/arch/arm/mach-keystone/Makefile
index d4671d5..3f6b8ab 100644
--- a/arch/arm/mach-keystone/Makefile
+++ b/arch/arm/mach-keystone/Makefile
@@ -1 +1,2 @@
obj-y := keystone.o
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 4bc60ec..a4eed57 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -26,6 +26,8 @@
#include
#include
+#include "keystone.h"
+
static struct map_desc io_desc[] = {
{
.virtual= 0xfe80UL,
@@ -73,6 +75,7 @@ static const char *keystone_match[] __initconst = {
};
DT_MACHINE_START(KEYSTONE, "Keystone")
+ smp_ops(keystone_smp_ops)
.map_io = keystone_map_io,
.init_irq = keystone_init_irq,
.timer = _timer,
diff --git a/arch/arm/mach-keystone/keystone.h
b/arch/arm/mach-keystone/keystone.h
new file mode 100644
index 000..71bd0f4
--- /dev/null
+++ b/arch/arm/mach-keystone/keystone.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2010-2012 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH 02/22] ARM: use late patch framework for phys-virt patching
This patch replaces the original physical offset patching implementation
with one that uses the newly added patching framework. In the process, we now
unconditionally initialize the __pv_phys_offset and __pv_offset globals in the
head.S code.
Signed-off-by: Cyril Chemparathy
---
arch/arm/include/asm/memory.h | 20 ++---
arch/arm/kernel/head.S| 96 +
arch/arm/kernel/module.c |5 ---
arch/arm/kernel/vmlinux.lds.S |5 ---
4 files changed, 15 insertions(+), 111 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index fcb5757..01c710d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_NEED_MACH_MEMORY_H
#include
@@ -151,35 +152,22 @@
#ifndef __virt_to_phys
#ifdef CONFIG_ARM_PATCH_PHYS_VIRT
-/*
- * Constants used to force the right instruction encodings and shifts
- * so that all we need to do is modify the 8-bit constant field.
- */
-#define __PV_BITS_31_240x8100
-
extern unsigned long __pv_phys_offset;
#define PHYS_OFFSET __pv_phys_offset
-#define __pv_stub(from,to,instr,type) \
- __asm__("@ __pv_stub\n" \
- "1: " instr " %0, %1, %2\n" \
- " .pushsection .pv_table,\"a\"\n" \
- " .long 1b\n" \
- " .popsection\n" \
- : "=r" (to) \
- : "r" (from), "I" (type))
+extern unsigned long __pv_offset;
static inline unsigned long __virt_to_phys(unsigned long x)
{
unsigned long t;
- __pv_stub(x, t, "add", __PV_BITS_31_24);
+ early_patch_imm8(x, t, "add", __pv_offset);
return t;
}
static inline unsigned long __phys_to_virt(unsigned long x)
{
unsigned long t;
- __pv_stub(x, t, "sub", __PV_BITS_31_24);
+ early_patch_imm8(x, t, "sub", __pv_offset);
return t;
}
#else
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 835898e..d165896 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -109,9 +109,13 @@ ENTRY(stext)
#ifndef CONFIG_XIP_KERNEL
adr r3, 2f
- ldmia r3, {r4, r8}
+ ldmia r3, {r4, r5, r6, r8}
sub r4, r3, r4 @ (PHYS_OFFSET - PAGE_OFFSET)
add r8, r8, r4 @ PHYS_OFFSET
+ add r5, r5, r4
+ str r8, [r5]@ set __pv_phys_offset
+ add r6, r6, r4
+ str r4, [r6]@ set __pv_offset
#else
ldr r8, =PHYS_OFFSET@ always constant in this case
#endif
@@ -124,9 +128,6 @@ ENTRY(stext)
#ifdef CONFIG_SMP_ON_UP
bl __fixup_smp
#endif
-#ifdef CONFIG_ARM_PATCH_PHYS_VIRT
- bl __fixup_pv_table
-#endif
bl __create_page_tables
/*
@@ -148,6 +149,8 @@ ENDPROC(stext)
.ltorg
#ifndef CONFIG_XIP_KERNEL
2: .long .
+ .long __pv_phys_offset
+ .long __pv_offset
.long PAGE_OFFSET
#endif
@@ -522,94 +525,17 @@ ENTRY(fixup_smp)
ldmfd sp!, {r4 - r6, pc}
ENDPROC(fixup_smp)
-#ifdef CONFIG_ARM_PATCH_PHYS_VIRT
-
-/* __fixup_pv_table - patch the stub instructions with the delta between
- * PHYS_OFFSET and PAGE_OFFSET, which is assumed to be 16MiB aligned and
- * can be expressed by an immediate shifter operand. The stub instruction
- * has a form of '(add|sub) rd, rn, #imm'.
- */
- __HEAD
-__fixup_pv_table:
- adr r0, 1f
- ldmia r0, {r3-r5, r7}
- sub r3, r0, r3 @ PHYS_OFFSET - PAGE_OFFSET
- add r4, r4, r3 @ adjust table start address
- add r5, r5, r3 @ adjust table end address
- add r7, r7, r3 @ adjust __pv_phys_offset address
- str r8, [r7]@ save computed PHYS_OFFSET to __pv_phys_offset
- mov r6, r3, lsr #24 @ constant for add/sub instructions
- teq r3, r6, lsl #24 @ must be 16MiB aligned
-THUMB( it ne @ cross section branch )
- bne __error
- str r6, [r7, #4]@ save to __pv_offset
- b __fixup_a_pv_table
-ENDPROC(__fixup_pv_table)
-
- .align
-1: .long .
- .long __pv_table_begin
- .long __pv_table_end
-2: .long __pv_phys_offset
-
- .text
-__fixup_a_pv_table:
-#ifdef CONFIG_THUMB2_KERNEL
- lslsr6, #24
- beq 2f
- clz r7, r6
- lsr r6, #24
- lsl r6, r7
- bic r6, #0x0080
- lsrsr7, #1
- orrcs r6, #0x0080
- orr r6, r6, r7, lsl #12
- orr r6, #0x4000
- b 2f
-1: add r7, r3
- ldrhip, [r7, #2]
- and ip, 0x8f00
- orr ip, r6 @ mask in offset bits 31-24
- strh
[PATCH 12/22] ARM: LPAE: factor out T1SZ and TTBR1 computations
This patch moves the TTBR1 offset calculation and the T1SZ calculation out of the TTB setup assembly code. This should not affect functionality in any way, but improves code readability as well as readability of subsequent patches in this series. Signed-off-by: Cyril Chemparathy Signed-off-by: Vitaly Andrianov --- arch/arm/include/asm/pgtable-3level-hwdef.h | 10 ++ arch/arm/mm/proc-v7-3level.S| 16 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/arch/arm/include/asm/pgtable-3level-hwdef.h b/arch/arm/include/asm/pgtable-3level-hwdef.h index d795282..b501650 100644 --- a/arch/arm/include/asm/pgtable-3level-hwdef.h +++ b/arch/arm/include/asm/pgtable-3level-hwdef.h @@ -74,4 +74,14 @@ #define PHYS_MASK_SHIFT(40) #define PHYS_MASK ((1ULL << PHYS_MASK_SHIFT) - 1) +#if defined CONFIG_VMSPLIT_2G +#define TTBR1_OFFSET (1 << 4)/* skip two L1 entries */ +#elif defined CONFIG_VMSPLIT_3G +#define TTBR1_OFFSET (4096 * (1 + 3))/* only L2, skip pgd + 3*pmd */ +#else +#define TTBR1_OFFSET 0 +#endif + +#define TTBR1_SIZE (((PAGE_OFFSET >> 30) - 1) << 16) + #endif diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S index 0001581..3b1a745 100644 --- a/arch/arm/mm/proc-v7-3level.S +++ b/arch/arm/mm/proc-v7-3level.S @@ -120,18 +120,10 @@ ENDPROC(cpu_v7_set_pte_ext) * booting secondary CPUs would end up using TTBR1 for the identity * mapping set up in TTBR0. */ - bhi 9001f @ PHYS_OFFSET > PAGE_OFFSET? - orr \tmp, \tmp, #(((PAGE_OFFSET >> 30) - 1) << 16) @ TTBCR.T1SZ -#if defined CONFIG_VMSPLIT_2G - /* PAGE_OFFSET == 0x8000, T1SZ == 1 */ - add \ttbr1, \ttbr1, #1 << 4 @ skip two L1 entries -#elif defined CONFIG_VMSPLIT_3G - /* PAGE_OFFSET == 0xc000, T1SZ == 2 */ - add \ttbr1, \ttbr1, #4096 * (1 + 3) @ only L2 used, skip pgd+3*pmd -#endif - /* CONFIG_VMSPLIT_1G does not need TTBR1 adjustment */ -9001: mcr p15, 0, \tmp, c2, c0, 2 @ TTB control register - mcrrp15, 1, \ttbr1, \zero, c2 @ load TTBR1 + orrls \tmp, \tmp, #TTBR1_SIZE @ TTBCR.T1SZ + mcr p15, 0, \tmp, c2, c0, 2 @ TTBCR + addls \ttbr1, \ttbr1, #TTBR1_OFFSET + mcrrp15, 1, \ttbr1, \zero, c2 @ load TTBR1 .endm __CPUINIT -- 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 01/22] ARM: add mechanism for late code patching
The original phys_to_virt/virt_to_phys patching implementation relied on early
patching prior to MMU initialization. On PAE systems running out of >4G
address space, this would have entailed an additional round of patching after
switching over to the high address space.
The approach implemented here conceptually extends the original PHYS_OFFSET
patching implementation with the introduction of "early" patch stubs. Early
patch code is required to be functional out of the box, even before the patch
is applied. This is implemented by inserting functional (but inefficient)
load code into the .patch.code init section. Having functional code out of
the box then allows us to defer the init time patch application until later
in the init sequence.
In addition to fitting better with our need for physical address-space
switch-over, this implementation should be somewhat more extensible by virtue
of its more readable (and hackable) C implementation. This should prove
useful for other similar init time specialization needs, especially in light
of our multi-platform kernel initiative.
This code has been boot tested in both ARM and Thumb-2 modes on an ARMv7
(Cortex-A8) device.
Note: the obtuse use of stringified symbols in patch_stub() and
early_patch_stub() is intentional. Theoretically this should have been
accomplished with formal operands passed into the asm block, but this requires
the use of the 'c' modifier for instantiating the long (e.g. .long %c0).
However, the 'c' modifier has been found to ICE certain versions of GCC, and
therefore we resort to stringified symbols here.
Signed-off-by: Cyril Chemparathy
---
arch/arm/include/asm/patch.h | 123 +
arch/arm/kernel/module.c |4 +
arch/arm/kernel/setup.c | 175 +
arch/arm/kernel/vmlinux.lds.S | 10 +++
4 files changed, 312 insertions(+)
create mode 100644 arch/arm/include/asm/patch.h
diff --git a/arch/arm/include/asm/patch.h b/arch/arm/include/asm/patch.h
new file mode 100644
index 000..a89749f
--- /dev/null
+++ b/arch/arm/include/asm/patch.h
@@ -0,0 +1,123 @@
+/*
+ * arch/arm/include/asm/patch.h
+ *
+ * Copyright (C) 2012, Texas Instruments
+ *
+ * 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.
+ *
+ * Note: this file should not be included by non-asm/.h files
+ */
+#ifndef __ASM_ARM_PATCH_H
+#define __ASM_ARM_PATCH_H
+
+#include
+
+#ifndef __ASSEMBLY__
+
+extern unsigned __patch_table_begin, __patch_table_end;
+
+struct patch_info {
+ u32 type;
+ u32 size;
+ void*insn_start;
+ void*insn_end;
+ u32 patch_data[0];
+};
+
+#define patch_next(p) ((void *)(p) + (p)->size)
+
+#define PATCH_TYPE_MASK0x
+#define PATCH_IMM8 0x0001
+
+#define PATCH_EARLY0x1
+
+#define patch_stub(type, code, patch_data, ...)\
+ __asm__("@ patch stub\n"\
+ "1:\n" \
+ code\
+ "2:\n" \
+ " .pushsection .patch.table, \"a\"\n" \
+ "3:\n" \
+ " .long (" __stringify(type) ")\n"\
+ " .long (4f-3b)\n"\
+ " .long 1b\n" \
+ " .long 2b\n" \
+ patch_data \
+ "4:\n" \
+ " .popsection\n" \
+ __VA_ARGS__)
+
+#define early_patch_stub(type, code, patch_data, ...) \
+ __asm__("@ patch stub\n"\
+ "1:\n" \
+ " b 5f\n" \
+ "2:\n" \
+ " .pushsection .patch.table, \"a\"\n" \
+ "3:\n" \
+ " .long (" __stringify(type | PATCH_EARLY) ")\n" \
+ " .long (4f-3b)\n"\
+ " .long 1b\n" \
+ " .long 2b\n" \
+ patch_data \
+ "4:\n" \
+ " .popsection\n" \
+ " .pushsection .patch.code, \"ax\"\n" \
+ "5:\n"
[PATCH 07/22] ARM: LPAE: use phys_addr_t in free_memmap()
From: Vitaly Andrianov
The free_memmap() was mistakenly using unsigned long type to represent
physical addresses. This breaks on PAE systems where memory could be placed
above the 32-bit addressible limit.
This patch fixes this function to properly use phys_addr_t instead.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/mm/init.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index f54d592..8252c31 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -457,7 +457,7 @@ static inline void
free_memmap(unsigned long start_pfn, unsigned long end_pfn)
{
struct page *start_pg, *end_pg;
- unsigned long pg, pgend;
+ phys_addr_t pg, pgend;
/*
* Convert start_pfn/end_pfn to a struct page pointer.
@@ -469,8 +469,8 @@ free_memmap(unsigned long start_pfn, unsigned long end_pfn)
* Convert to physical addresses, and
* round start upwards and end downwards.
*/
- pg = (unsigned long)PAGE_ALIGN(__pa(start_pg));
- pgend = (unsigned long)__pa(end_pg) & PAGE_MASK;
+ pg = PAGE_ALIGN(__pa(start_pg));
+ pgend = __pa(end_pg) & PAGE_MASK;
/*
* If there are free pages between these,
--
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 04/22] ARM: LPAE: support 64-bit virt/phys patching
This patch adds support for 64-bit physical addresses in virt_to_phys
patching. This does not do real 64-bit add/sub, but instead patches in the
upper 32-bits of the phys_offset directly into the output of virt_to_phys.
In addition to adding 64-bit support, this patch also adds a set_phys_offset()
helper that is needed on architectures that need to modify PHYS_OFFSET during
initialization.
Signed-off-by: Cyril Chemparathy
---
arch/arm/include/asm/memory.h | 22 +++---
arch/arm/kernel/head.S|6 ++
arch/arm/kernel/setup.c | 14 ++
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 4a0108f..110495c 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -153,23 +153,31 @@
#ifdef CONFIG_ARM_PATCH_PHYS_VIRT
extern unsigned long __pv_phys_offset;
-#define PHYS_OFFSET __pv_phys_offset
-
+extern unsigned long __pv_phys_offset_high;
extern unsigned long __pv_offset;
+extern void set_phys_offset(phys_addr_t po);
+
+#define PHYS_OFFSET__virt_to_phys(PAGE_OFFSET)
+
static inline phys_addr_t __virt_to_phys(unsigned long x)
{
- unsigned long t;
- early_patch_imm8(x, t, "add", __pv_offset);
- return t;
+ unsigned long tlo, thi = 0;
+
+ early_patch_imm8(x, tlo, "add", __pv_offset);
+ if (sizeof(phys_addr_t) > 4)
+ early_patch_imm8(0, thi, "add", __pv_phys_offset_high);
+
+ return (u64)tlo | (u64)thi << 32;
}
static inline unsigned long __phys_to_virt(phys_addr_t x)
{
- unsigned long t;
- early_patch_imm8(x, t, "sub", __pv_offset);
+ unsigned long t, xlo = x;
+ early_patch_imm8(xlo, t, "sub", __pv_offset);
return t;
}
+
#else
#define __virt_to_phys(x) \
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index d165896..fa820b3 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -532,6 +532,12 @@ __pv_phys_offset:
.long 0
.size __pv_phys_offset, . - __pv_phys_offset
+ .globl __pv_phys_offset_high
+ .type __pv_phys_offset_high, %object
+__pv_phys_offset_high:
+ .long 0
+ .size __pv_phys_offset_high, . - __pv_phys_offset_high
+
.globl __pv_offset
.type __pv_offset, %object
__pv_offset:
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 15a7699..bba3fdc 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -67,6 +67,20 @@
#define MEM_SIZE (16*1024*1024)
#endif
+#ifdef CONFIG_ARM_PATCH_PHYS_VIRT
+/*
+ * set_phys_offset() sets PHYS_OFFSET and pv_offset.
+ * Note: this is unsafe to use beyond setup_arch().
+ */
+void __init set_phys_offset(phys_addr_t po)
+{
+ __pv_phys_offset= po;
+ __pv_phys_offset_high = (u64)po >> 32;
+ __pv_offset = po - PAGE_OFFSET;
+}
+
+#endif
+
#if defined(CONFIG_FPE_NWFPE) || defined(CONFIG_FPE_FASTFPE)
char fpe_type[8];
--
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 14/22] ARM: LPAE: accomodate >32-bit addresses for page table base
This patch redefines the early boot time use of the R4 register to steal a few
low order bits (ARCH_PGD_SHIFT bits), allowing for up to 38-bit physical
addresses.
This is probably not the best means to the end, and a better alternative may
be to modify the head.S register allocations to fit in full register pairs for
pgdir and swapper_pg_dir. However, squeezing out these extra registers seemed
to be a far greater pain than squeezing out a few low order bits from the page
table addresses.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/include/asm/cache.h |9 +
arch/arm/kernel/head.S |7 +--
arch/arm/kernel/smp.c| 11 +--
arch/arm/mm/proc-arm1026.S |2 ++
arch/arm/mm/proc-mohawk.S|2 ++
arch/arm/mm/proc-v6.S|2 ++
arch/arm/mm/proc-v7-2level.S |2 ++
arch/arm/mm/proc-v7-3level.S |7 +++
arch/arm/mm/proc-v7.S|1 +
arch/arm/mm/proc-xsc3.S |2 ++
10 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
index 75fe66b..986480c 100644
--- a/arch/arm/include/asm/cache.h
+++ b/arch/arm/include/asm/cache.h
@@ -17,6 +17,15 @@
#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
/*
+ * Minimum guaranted alignment in pgd_alloc(). The page table pointers passed
+ * around in head.S and proc-*.S are shifted by this amount, in order to
+ * leave spare high bits for systems with physical address extension. This
+ * does not fully accomodate the 40-bit addressing capability of ARM LPAE, but
+ * gives us about 38-bits or so.
+ */
+#define ARCH_PGD_SHIFT L1_CACHE_SHIFT
+
+/*
* With EABI on ARMv5 and above we must have 64-bit aligned slab pointers.
*/
#if defined(CONFIG_AEABI) && (__LINUX_ARM_ARCH__ >= 5)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 7b1a3be..af029ec 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_DEBUG_LL
#include
@@ -163,7 +164,7 @@ ENDPROC(stext)
*
* Returns:
* r0, r3, r5-r7 corrupted
- * r4 = physical page table address
+ * r4 = page table (see ARCH_PGD_SHIFT in asm/cache.h)
*/
__create_page_tables:
pgtbl r4, r8 @ page table address
@@ -323,6 +324,7 @@ __create_page_tables:
#ifdef CONFIG_ARM_LPAE
sub r4, r4, #0x1000 @ point to the PGD table
#endif
+ mov r4, r4, lsr #ARCH_PGD_SHIFT
mov pc, lr
ENDPROC(__create_page_tables)
.ltorg
@@ -395,7 +397,7 @@ __secondary_data:
* r0 = cp#15 control register
* r1 = machine ID
* r2 = atags or dtb pointer
- * r4 = page table pointer
+ * r4 = page table (see ARCH_PGD_SHIFT in asm/cache.h)
* r9 = processor ID
* r13 = *virtual* address to jump to upon completion
*/
@@ -424,6 +426,7 @@ __enable_mmu:
@ has the processor setup already programmed the page table pointer?
addsr5, r4, #1
+ movne r4, r4, lsl #ARCH_PGD_SHIFT
mcrne p15, 0, r4, c2, c0, 0 @ load page table pointer
b __turn_mmu_on
ENDPROC(__enable_mmu)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..e41e1be 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
/*
* as from 2.5, kernels no longer have an init_tasks structure
@@ -62,6 +63,7 @@ static DECLARE_COMPLETION(cpu_running);
int __cpuinit __cpu_up(unsigned int cpu, struct task_struct *idle)
{
+ phys_addr_t pgdir;
int ret;
/*
@@ -69,8 +71,13 @@ int __cpuinit __cpu_up(unsigned int cpu, struct task_struct
*idle)
* its stack and the page tables.
*/
secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
- secondary_data.pgdir = virt_to_phys(idmap_pgd);
- secondary_data.swapper_pg_dir = virt_to_phys(swapper_pg_dir);
+
+ pgdir = virt_to_phys(idmap_pgd);
+ secondary_data.pgdir = pgdir >> ARCH_PGD_SHIFT;
+
+ pgdir = virt_to_phys(swapper_pg_dir);
+ secondary_data.swapper_pg_dir = pgdir >> ARCH_PGD_SHIFT;
+
__cpuc_flush_dcache_area(_data, sizeof(secondary_data));
outer_clean_range(__pa(_data), __pa(_data + 1));
diff --git a/arch/arm/mm/proc-arm1026.S b/arch/arm/mm/proc-arm1026.S
index c28070e..4556f77 100644
--- a/arch/arm/mm/proc-arm1026.S
+++ b/arch/arm/mm/proc-arm1026.S
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "proc-macros.S"
@@ -403,6 +404,7 @@ __arm1026_setup:
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer on v4
#ifdef CONFIG_MMU
mcr p15, 0, r0, c8, c7 @ invalidate I,D TLBs on v4
+ mov r4, r4, lsl #ARCH_PGD_SHIFT
mcr p15, 0, r4, c2, c0 @ load page table pointer
mvn r4, #0 @ do not set
[PATCH 03/22] ARM: LPAE: use phys_addr_t on virt <--> phys conversion
This patch fixes up the types used when converting back and forth between
physical and virtual addresses.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/include/asm/memory.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 01c710d..4a0108f 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -157,22 +157,27 @@ extern unsigned long __pv_phys_offset;
extern unsigned long __pv_offset;
-static inline unsigned long __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys(unsigned long x)
{
unsigned long t;
early_patch_imm8(x, t, "add", __pv_offset);
return t;
}
-static inline unsigned long __phys_to_virt(unsigned long x)
+static inline unsigned long __phys_to_virt(phys_addr_t x)
{
unsigned long t;
early_patch_imm8(x, t, "sub", __pv_offset);
return t;
}
#else
-#define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
-#define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET)
+
+#define __virt_to_phys(x) \
+ ((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET)
+
+#define __phys_to_virt(x) \
+ ((unsigned long)((phys_addr_t)(x) - PHYS_OFFSET + PAGE_OFFSET))
+
#endif
#endif
@@ -207,14 +212,14 @@ static inline phys_addr_t virt_to_phys(const volatile
void *x)
static inline void *phys_to_virt(phys_addr_t x)
{
- return (void *)(__phys_to_virt((unsigned long)(x)));
+ return (void *)__phys_to_virt(x);
}
/*
* Drivers should NOT use these either.
*/
#define __pa(x)__virt_to_phys((unsigned long)(x))
-#define __va(x)((void *)__phys_to_virt((unsigned
long)(x)))
+#define __va(x)((void
*)__phys_to_virt((phys_addr_t)(x)))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
/*
--
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/
[RFC 20/22] ARM: keystone: introducing TI Keystone platform
Texas Instruments Keystone family of multicore devices now includes an
upcoming slew of Cortex A15 based devices. This patch adds basic definitions
for a new Keystone sub-architecture in ARM.
Subsequent patches in this series will extend support to include SMP and take
advantage of the large physical memory addressing capabilities via LPAE.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/Kconfig | 18 +
arch/arm/Makefile |1 +
arch/arm/boot/dts/keystone-sim.dts| 77 +++
arch/arm/configs/keystone_defconfig | 20 +
arch/arm/mach-keystone/Makefile |1 +
arch/arm/mach-keystone/Makefile.boot |1 +
arch/arm/mach-keystone/include/mach/debug-macro.S | 44 +++
arch/arm/mach-keystone/include/mach/memory.h | 22 ++
arch/arm/mach-keystone/include/mach/timex.h | 21 ++
arch/arm/mach-keystone/include/mach/uncompress.h | 24 ++
arch/arm/mach-keystone/keystone.c | 82 +
11 files changed, 311 insertions(+)
create mode 100644 arch/arm/boot/dts/keystone-sim.dts
create mode 100644 arch/arm/configs/keystone_defconfig
create mode 100644 arch/arm/mach-keystone/Makefile
create mode 100644 arch/arm/mach-keystone/Makefile.boot
create mode 100644 arch/arm/mach-keystone/include/mach/debug-macro.S
create mode 100644 arch/arm/mach-keystone/include/mach/memory.h
create mode 100644 arch/arm/mach-keystone/include/mach/timex.h
create mode 100644 arch/arm/mach-keystone/include/mach/uncompress.h
create mode 100644 arch/arm/mach-keystone/keystone.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..e0588e3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -358,6 +358,24 @@ config ARCH_HIGHBANK
help
Support for the Calxeda Highbank SoC based boards.
+config ARCH_KEYSTONE
+ bool "Texas Instruments Keystone Devices"
+ select ARCH_WANT_OPTIONAL_GPIOLIB
+ select ARM_GIC
+ select MULTI_IRQ_HANDLER
+ select CLKDEV_LOOKUP
+ select COMMON_CLK
+ select CLKSRC_MMIO
+ select CPU_V7
+ select GENERIC_CLOCKEVENTS
+ select USE_OF
+ select SPARSE_IRQ
+ select NEED_MACH_MEMORY_H
+ select HAVE_SCHED_CLOCK
+ help
+ Support for boards based on the Texas Instruments Keystone family of
+ SoCs.
+
config ARCH_CLPS711X
bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
select CPU_ARM720T
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 0298b00..13d6ef5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -143,6 +143,7 @@ machine-$(CONFIG_ARCH_EP93XX) := ep93xx
machine-$(CONFIG_ARCH_GEMINI) := gemini
machine-$(CONFIG_ARCH_H720X) := h720x
machine-$(CONFIG_ARCH_HIGHBANK):= highbank
+machine-$(CONFIG_ARCH_KEYSTONE):= keystone
machine-$(CONFIG_ARCH_INTEGRATOR) := integrator
machine-$(CONFIG_ARCH_IOP13XX) := iop13xx
machine-$(CONFIG_ARCH_IOP32X) := iop32x
diff --git a/arch/arm/boot/dts/keystone-sim.dts
b/arch/arm/boot/dts/keystone-sim.dts
new file mode 100644
index 000..118d631
--- /dev/null
+++ b/arch/arm/boot/dts/keystone-sim.dts
@@ -0,0 +1,77 @@
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Texas Instruments Keystone 2 SoC";
+ compatible = "ti,keystone-evm";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <>;
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 debug earlyprintk lpj=5
rdinit=/bin/ash rw root=/dev/ram0 initrd=0x8500,9M";
+ };
+
+ memory {
+ reg = <0x8000 0x800>;
+ };
+
+ cpus {
+ interrupt-parent = <>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a15";
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a15";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a15";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a15";
+ };
+
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "ti,keystone","simple-bus";
+ interrupt-parent = <>;
+
+ gic:interrupt-controller@0256 {
+ compatible = "arm,cortex-a15-gic";
+ #interrupt-cells = <3>;
+ #size-cells = <0>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0x02561000 0x1000>,
+ <0x02562000 0x2000>;
+
[PATCH 00/22] Introducing the TI Keystone platform
This series is a follow on to the RFC series posted earlier (archived at [1]). The major change introduced here is the modification to the kernel patching mechanism for phys_to_virt/virt_to_phys, in order to support LPAE platforms that require late patching. In addition to these changes, we've updated the series based on feedback from the earlier posting. Most of the patches in this series are fixes and extensions to LPAE support on ARM. The last three patches in this series are specific to the TI Keystone platform, and are being provided here for the sake of completeness. These three patches are dependent on the smpops patch set (see [2]), and are not ready to be merged in as yet. [1] - https://lkml.org/lkml/2012/7/23/460 [2] - http://permalink.gmane.org/gmane.linux.ports.arm.kernel/171540 Cyril Chemparathy (18): ARM: add mechanism for late code patching ARM: use late patch framework for phys-virt patching ARM: LPAE: use phys_addr_t on virt <--> phys conversion ARM: LPAE: support 64-bit virt/phys patching ARM: LPAE: use signed arithmetic for mask definitions ARM: LPAE: use 64-bit pgd physical address in switch_mm() ARM: LPAE: use 64-bit accessors for TTBR registers ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem ARM: LPAE: factor out T1SZ and TTBR1 computations ARM: LPAE: allow proc override of TTB setup ARM: LPAE: accomodate >32-bit addresses for page table base ARM: mm: use physical addresses in highmem sanity checks ARM: mm: cleanup checks for membank overlap with vmalloc area ARM: mm: clean up membank size limit checks ARM: recreate kernel mappings in early_paging_init() ARM: keystone: introducing TI Keystone platform ARM: keystone: enable SMP on Keystone machines ARM: keystone: add switch over to high physical address range Vitaly Andrianov (4): ARM: LPAE: use phys_addr_t in alloc_init_pud() ARM: LPAE: use phys_addr_t in free_memmap() ARM: LPAE: use phys_addr_t for initrd location and size ARM: add virt_to_idmap for interconnect aliasing arch/arm/Kconfig | 20 +++ arch/arm/Makefile |1 + arch/arm/boot/dts/keystone-sim.dts| 77 + arch/arm/configs/keystone_defconfig | 23 +++ arch/arm/include/asm/cache.h |9 + arch/arm/include/asm/mach/arch.h |1 + arch/arm/include/asm/memory.h | 68 +--- arch/arm/include/asm/page.h |2 +- arch/arm/include/asm/patch.h | 123 + arch/arm/include/asm/pgtable-3level-hwdef.h | 10 ++ arch/arm/include/asm/pgtable-3level.h |6 +- arch/arm/include/asm/proc-fns.h | 28 ++- arch/arm/kernel/head.S| 119 +++-- arch/arm/kernel/module.c |7 +- arch/arm/kernel/setup.c | 192 + arch/arm/kernel/smp.c | 11 +- arch/arm/kernel/vmlinux.lds.S | 13 +- arch/arm/mach-keystone/Makefile |2 + arch/arm/mach-keystone/Makefile.boot |1 + arch/arm/mach-keystone/include/mach/debug-macro.S | 44 + arch/arm/mach-keystone/include/mach/memory.h | 47 + arch/arm/mach-keystone/include/mach/timex.h | 21 +++ arch/arm/mach-keystone/include/mach/uncompress.h | 24 +++ arch/arm/mach-keystone/keystone.c | 122 + arch/arm/mach-keystone/keystone.h | 23 +++ arch/arm/mach-keystone/platsmp.c | 88 ++ arch/arm/mm/context.c | 13 +- arch/arm/mm/idmap.c |4 +- arch/arm/mm/init.c| 20 +-- arch/arm/mm/mmu.c | 106 arch/arm/mm/proc-arm1026.S|3 + arch/arm/mm/proc-mohawk.S |3 + arch/arm/mm/proc-v6.S |6 +- arch/arm/mm/proc-v7-2level.S |7 +- arch/arm/mm/proc-v7-3level.S | 29 ++-- arch/arm/mm/proc-v7.S |2 + arch/arm/mm/proc-xsc3.S |3 + 37 files changed, 1065 insertions(+), 213 deletions(-) create mode 100644 arch/arm/boot/dts/keystone-sim.dts create mode 100644 arch/arm/configs/keystone_defconfig create mode 100644 arch/arm/include/asm/patch.h create mode 100644 arch/arm/mach-keystone/Makefile create mode 100644 arch/arm/mach-keystone/Makefile.boot create mode 100644 arch/arm/mach-keystone/include/mach/debug-macro.S create mode 100644 arch/arm/mach-keystone/include/mach/memory.h create mode 100644 arch/arm/mach-keystone/include/mach/timex.h create mode 100644 arch/arm/mach-keystone/include/mach/uncompress.h create mode 100644
[PATCH 08/22] ARM: LPAE: use phys_addr_t for initrd location and size
From: Vitaly Andrianov
This patch fixes the initrd setup code to use phys_addr_t instead of assuming
32-bit addressing. Without this we cannot boot on systems where initrd is
located above the 4G physical address limit.
Signed-off-by: Vitaly Andrianov
Signed-off-by: Cyril Chemparathy
---
arch/arm/mm/init.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8252c31..51f3e92 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -36,12 +36,12 @@
#include "mm.h"
-static unsigned long phys_initrd_start __initdata = 0;
-static unsigned long phys_initrd_size __initdata = 0;
+static phys_addr_t phys_initrd_start __initdata = 0;
+static phys_addr_t phys_initrd_size __initdata = 0;
static int __init early_initrd(char *p)
{
- unsigned long start, size;
+ phys_addr_t start, size;
char *endp;
start = memparse(p, );
@@ -347,14 +347,14 @@ void __init arm_memblock_init(struct meminfo *mi, struct
machine_desc *mdesc)
#ifdef CONFIG_BLK_DEV_INITRD
if (phys_initrd_size &&
!memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08lx+0x%08lx is not a memory region -
disabling initrd\n",
- phys_initrd_start, phys_initrd_size);
+ pr_err("INITRD: 0x%08llx+0x%08llx is not a memory region -
disabling initrd\n",
+ (u64)phys_initrd_start, (u64)phys_initrd_size);
phys_initrd_start = phys_initrd_size = 0;
}
if (phys_initrd_size &&
memblock_is_region_reserved(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08lx+0x%08lx overlaps in-use memory region -
disabling initrd\n",
- phys_initrd_start, phys_initrd_size);
+ pr_err("INITRD: 0x%08llx+0x%08llx overlaps in-use memory region
- disabling initrd\n",
+ (u64)phys_initrd_start, (u64)phys_initrd_size);
phys_initrd_start = phys_initrd_size = 0;
}
if (phys_initrd_size) {
--
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 19/22] ARM: recreate kernel mappings in early_paging_init()
This patch adds a step in the init sequence, in order to recreate the kernel
code/data page table mappings prior to full paging initialization. This is
necessary on LPAE systems that run out of a physical address space outside the
4G limit. On these systems, this implementation provides a machine descriptor
hook that allows the PHYS_OFFSET to be overridden in a machine specific
fashion.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/include/asm/mach/arch.h |1 +
arch/arm/kernel/setup.c |3 ++
arch/arm/mm/mmu.c| 57 ++
3 files changed, 61 insertions(+)
diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 0b1c94b..2b9ecc5 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -37,6 +37,7 @@ struct machine_desc {
charrestart_mode; /* default restart mode */
void(*fixup)(struct tag *, char **,
struct meminfo *);
+ void(*init_meminfo)(void);
void(*reserve)(void);/* reserve mem blocks */
void(*map_io)(void);/* IO mapping function */
void(*init_early)(void);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index bba3fdc..ccf052c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -93,6 +93,7 @@ static int __init fpe_setup(char *line)
__setup("fpe=", fpe_setup);
#endif
+extern void early_paging_init(struct machine_desc *, struct proc_info_list *);
extern void paging_init(struct machine_desc *desc);
extern void sanity_check_meminfo(void);
extern void reboot_setup(char *str);
@@ -1152,6 +1153,8 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
sort(, meminfo.nr_banks, sizeof(meminfo.bank[0]),
meminfo_cmp, NULL);
+
+ early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
sanity_check_meminfo();
arm_memblock_init(, mdesc);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6b0baf3..21fb171 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1175,6 +1176,62 @@ static void __init map_lowmem(void)
}
/*
+ * early_paging_init() recreates boot time page table setup, allowing machines
+ * to switch over to a high (>4G) address space on LPAE systems
+ */
+void __init early_paging_init(struct machine_desc *mdesc,
+ struct proc_info_list *procinfo)
+{
+ bool lpae = IS_ENABLED(CONFIG_ARM_LPAE);
+ pmdval_t pmdprot = procinfo->__cpu_mm_mmu_flags;
+ unsigned long map_start, map_end;
+ pgd_t *pgd0, *pgdk;
+ pud_t *pud0, *pudk;
+ pmd_t *pmd0, *pmdk;
+ phys_addr_t phys;
+ int i;
+
+ if (!lpae)
+ return;
+
+ /* remap kernel code and data */
+ map_start = init_mm.start_code;
+ map_end = init_mm.brk;
+
+ /* get a handle on things... */
+ pgd0 = pgd_offset_k(0);
+ pud0 = pud_offset(pgd0, 0);
+ pmd0 = pmd_offset(pud0, 0);
+
+ pgdk = pgd_offset_k(map_start);
+ pudk = pud_offset(pgdk, map_start);
+ pmdk = pmd_offset(pudk, map_start);
+
+ phys = PHYS_OFFSET;
+
+ if (mdesc->init_meminfo)
+ mdesc->init_meminfo();
+
+ /* remap level 1 table */
+ for (i = 0; i < PTRS_PER_PGD; i++) {
+ *pud0++ = __pud(__pa(pmd0) | PMD_TYPE_TABLE | L_PGD_SWAPPER);
+ pmd0 += PTRS_PER_PMD;
+ }
+
+ /* remap pmds for kernel mapping */
+ phys = __pa(map_start) & PMD_MASK;
+ do {
+ *pmdk++ = __pmd(phys | pmdprot);
+ phys += PMD_SIZE;
+ } while (phys < map_end);
+
+ flush_cache_all();
+ cpu_set_ttbr(0, __pa(pgd0));
+ cpu_set_ttbr(1, __pa(pgd0) + TTBR1_OFFSET);
+ local_flush_tlb_all();
+}
+
+/*
* paging_init() sets up the page tables, initialises the zone memory
* maps, and sets up the zero page, bad page and bad page tables.
*/
--
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 13/22] ARM: LPAE: allow proc override of TTB setup
This patch allows ARM processor setup functions (*_setup in proc-*.S) to
indicate that the page table has already been programmed. This is
done by setting r4 (page table pointer) to -1 before returning from the
processor setup handler.
This capability is particularly needed on LPAE systems, where the translation
table base needs to be programmed differently with 64-bit control
register operations.
Further, a few of the processors (arm1026, mohawk, xsc3) were programming the
TTB twice. This patch prevents the main head.S code from programming TTB the
second time on these machines.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/kernel/head.S | 10 +-
arch/arm/mm/proc-arm1026.S |1 +
arch/arm/mm/proc-mohawk.S|1 +
arch/arm/mm/proc-v6.S|2 ++
arch/arm/mm/proc-v7-2level.S |3 ++-
arch/arm/mm/proc-v7-3level.S |1 +
arch/arm/mm/proc-v7.S|1 +
arch/arm/mm/proc-xsc3.S |1 +
8 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index fa820b3..7b1a3be 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -414,17 +414,17 @@ __enable_mmu:
#ifdef CONFIG_CPU_ICACHE_DISABLE
bic r0, r0, #CR_I
#endif
-#ifdef CONFIG_ARM_LPAE
- mov r5, #0
- mcrrp15, 0, r4, r5, c2 @ load TTBR0
-#else
+#ifndef CONFIG_ARM_LPAE
mov r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | \
domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | \
domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | \
domain_val(DOMAIN_IO, DOMAIN_CLIENT))
mcr p15, 0, r5, c3, c0, 0 @ load domain access register
- mcr p15, 0, r4, c2, c0, 0 @ load page table pointer
#endif
+
+ @ has the processor setup already programmed the page table pointer?
+ addsr5, r4, #1
+ mcrne p15, 0, r4, c2, c0, 0 @ load page table pointer
b __turn_mmu_on
ENDPROC(__enable_mmu)
diff --git a/arch/arm/mm/proc-arm1026.S b/arch/arm/mm/proc-arm1026.S
index fbc1d5f..c28070e 100644
--- a/arch/arm/mm/proc-arm1026.S
+++ b/arch/arm/mm/proc-arm1026.S
@@ -404,6 +404,7 @@ __arm1026_setup:
#ifdef CONFIG_MMU
mcr p15, 0, r0, c8, c7 @ invalidate I,D TLBs on v4
mcr p15, 0, r4, c2, c0 @ load page table pointer
+ mvn r4, #0 @ do not set page table pointer
#endif
#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
mov r0, #4 @ explicitly disable writeback
diff --git a/arch/arm/mm/proc-mohawk.S b/arch/arm/mm/proc-mohawk.S
index fbb2124..a26303c 100644
--- a/arch/arm/mm/proc-mohawk.S
+++ b/arch/arm/mm/proc-mohawk.S
@@ -390,6 +390,7 @@ __mohawk_setup:
mcr p15, 0, r0, c8, c7 @ invalidate I,D TLBs
orr r4, r4, #0x18 @ cache the page table in L2
mcr p15, 0, r4, c2, c0, 0 @ load page table pointer
+ mvn r4, #0 @ do not set page table pointer
mov r0, #0 @ don't allow CP access
mcr p15, 0, r0, c15, c1, 0 @ write CP access register
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 566c658..872156e 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -210,7 +210,9 @@ __v6_setup:
ALT_UP(orr r4, r4, #TTB_FLAGS_UP)
ALT_SMP(orr r8, r8, #TTB_FLAGS_SMP)
ALT_UP(orr r8, r8, #TTB_FLAGS_UP)
+ mcr p15, 0, r4, c2, c0, 0 @ load TTB0
mcr p15, 0, r8, c2, c0, 1 @ load TTB1
+ mvn r4, #0 @ do not set page table pointer
#endif /* CONFIG_MMU */
adr r5, v6_crval
ldmia r5, {r5, r6}
diff --git a/arch/arm/mm/proc-v7-2level.S b/arch/arm/mm/proc-v7-2level.S
index 3397803..cc78c0c 100644
--- a/arch/arm/mm/proc-v7-2level.S
+++ b/arch/arm/mm/proc-v7-2level.S
@@ -139,7 +139,7 @@ ENDPROC(cpu_v7_set_pte_ext)
/*
* Macro for setting up the TTBRx and TTBCR registers.
-* - \ttb0 and \ttb1 updated with the corresponding flags.
+* - \ttbr0 and \ttbr1 updated with the corresponding flags.
*/
.macro v7_ttb_setup, zero, ttbr0, ttbr1, tmp
mcr p15, 0, \zero, c2, c0, 2@ TTB control register
@@ -147,6 +147,7 @@ ENDPROC(cpu_v7_set_pte_ext)
ALT_UP(orr \ttbr0, \ttbr0, #TTB_FLAGS_UP)
ALT_SMP(orr \ttbr1, \ttbr1, #TTB_FLAGS_SMP)
ALT_UP(orr \ttbr1, \ttbr1, #TTB_FLAGS_UP)
+ mcr p15, 0, \ttbr0, c2, c0, 0 @ load TTB0
mcr p15, 0, \ttbr1, c2, c0, 1 @ load TTB1
.endm
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 3b1a745..5e3bed1 100644
--- a/arch/arm/mm/proc-v7-3level.S
+++
[PATCH 17/22] ARM: mm: clean up membank size limit checks
This patch cleans up the highmem sanity check code by simplifying the range
checks with a pre-calculated size_limit. This patch should otherwise have no
functional impact on behavior.
This patch also removes a redundant (bank->start < vmalloc_limit) check, since
this is already covered by the !highmem condition.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/mm/mmu.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4840efa..6b0baf3 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -905,10 +905,15 @@ void __init sanity_check_meminfo(void)
for (i = 0, j = 0; i < meminfo.nr_banks; i++) {
struct membank *bank = [j];
+ phys_addr_t size_limit;
+
*bank = meminfo.bank[i];
+ size_limit = bank->size;
if (bank->start >= vmalloc_limit)
highmem = 1;
+ else
+ size_limit = vmalloc_limit - bank->start;
bank->highmem = highmem;
@@ -917,8 +922,7 @@ void __init sanity_check_meminfo(void)
* Split those memory banks which are partially overlapping
* the vmalloc area greatly simplifying things later.
*/
- if (!highmem && bank->start < vmalloc_limit &&
- bank->size > vmalloc_limit - bank->start) {
+ if (!highmem && bank->size > size_limit) {
if (meminfo.nr_banks >= NR_BANKS) {
printk(KERN_CRIT "NR_BANKS too low, "
"ignoring high memory\n");
@@ -927,12 +931,12 @@ void __init sanity_check_meminfo(void)
(meminfo.nr_banks - i) * sizeof(*bank));
meminfo.nr_banks++;
i++;
- bank[1].size -= vmalloc_limit - bank->start;
+ bank[1].size -= size_limit;
bank[1].start = vmalloc_limit;
bank[1].highmem = highmem = 1;
j++;
}
- bank->size = vmalloc_limit - bank->start;
+ bank->size = size_limit;
}
#else
/*
@@ -950,14 +954,13 @@ void __init sanity_check_meminfo(void)
* Check whether this memory bank would partially overlap
* the vmalloc area.
*/
- if (bank->start + bank->size > vmalloc_limit)
- unsigned long newsize = vmalloc_limit - bank->start;
+ if (bank->size > size_limit) {
printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx "
"to -%.8llx (vmalloc region overlap).\n",
(unsigned long long)bank->start,
(unsigned long long)bank->start + bank->size - 1,
- (unsigned long long)bank->start + newsize - 1);
- bank->size = newsize;
+ (unsigned long long)bank->start + size_limit -
1);
+ bank->size = size_limit;
}
#endif
if (!bank->highmem && bank->start + bank->size >
arm_lowmem_limit)
--
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 10/22] ARM: LPAE: use 64-bit accessors for TTBR registers
This patch adds TTBR accessor macros, and modifies cpu_get_pgd() and
the LPAE version of cpu_set_reserved_ttbr0() to use these instead.
In the process, we also fix these functions to correctly handle cases
where the physical address lies beyond the 4G limit of 32-bit addressing.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/include/asm/proc-fns.h | 24 +++-
arch/arm/mm/context.c | 13 ++---
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index fa6554e..918b4f9 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -116,13 +116,27 @@ extern void cpu_resume(void);
#define cpu_switch_mm(pgd,mm) cpu_do_switch_mm(virt_to_phys(pgd),mm)
#ifdef CONFIG_ARM_LPAE
+
+#define cpu_get_ttbr(nr) \
+ ({ \
+ u64 ttbr; \
+ __asm__("mrrc p15, " #nr ", %Q0, %R0, c2" \
+ : "=r" (ttbr) \
+ : : "cc"); \
+ ttbr; \
+ })
+
+#define cpu_set_ttbr(nr, val) \
+ do {\
+ u64 ttbr = val; \
+ __asm__("mcrr p15, " #nr ", %Q0, %R0, c2" \
+ : : "r" (ttbr) \
+ : "cc");\
+ } while (0)
+
#define cpu_get_pgd() \
({ \
- unsigned long pg, pg2; \
- __asm__("mrrc p15, 0, %0, %1, c2" \
- : "=r" (pg), "=r" (pg2) \
- : \
- : "cc");\
+ u64 pg = cpu_get_ttbr(0); \
pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1); \
(pgd_t *)phys_to_virt(pg); \
})
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index 806cc4f..ad70bd8 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -15,6 +15,7 @@
#include
#include
+#include
static DEFINE_RAW_SPINLOCK(cpu_asid_lock);
unsigned int cpu_last_asid = ASID_FIRST_VERSION;
@@ -22,17 +23,7 @@ unsigned int cpu_last_asid = ASID_FIRST_VERSION;
#ifdef CONFIG_ARM_LPAE
void cpu_set_reserved_ttbr0(void)
{
- unsigned long ttbl = __pa(swapper_pg_dir);
- unsigned long ttbh = 0;
-
- /*
-* Set TTBR0 to swapper_pg_dir which contains only global entries. The
-* ASID is set to 0.
-*/
- asm volatile(
- " mcrrp15, 0, %0, %1, c2 @ set TTBR0\n"
- :
- : "r" (ttbl), "r" (ttbh));
+ cpu_set_ttbr(0, __pa(swapper_pg_dir));
isb();
}
#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/
[PATCH 09/22] ARM: LPAE: use 64-bit pgd physical address in switch_mm()
This patch modifies the switch_mm() processor functions to use 64-bit
addresses. We use u64 instead of phys_addr_t, in order to avoid having config
dependent register usage when calling into switch_mm assembly code.
The changes in this patch are primarily adjustments for registers used for
arguments to switch_mm. The few processor definitions that did use the second
argument have been modified accordingly.
Arguments and calling conventions aside, this patch should be a no-op on v6
and non-LPAE v7 processors. On LPAE systems, we now honor the upper 32-bits
of the physical address that is being passed in.
Signed-off-by: Cyril Chemparathy
Signed-off-by: Vitaly Andrianov
---
arch/arm/include/asm/proc-fns.h |4 ++--
arch/arm/mm/proc-v6.S |2 +-
arch/arm/mm/proc-v7-2level.S|2 +-
arch/arm/mm/proc-v7-3level.S|5 +++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index f3628fb..fa6554e 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -60,7 +60,7 @@ extern struct processor {
/*
* Set the page table
*/
- void (*switch_mm)(unsigned long pgd_phys, struct mm_struct *mm);
+ void (*switch_mm)(u64 pgd_phys, struct mm_struct *mm);
/*
* Set a possibly extended PTE. Non-extended PTEs should
* ignore 'ext'.
@@ -82,7 +82,7 @@ extern void cpu_proc_init(void);
extern void cpu_proc_fin(void);
extern int cpu_do_idle(void);
extern void cpu_dcache_clean_area(void *, int);
-extern void cpu_do_switch_mm(unsigned long pgd_phys, struct mm_struct *mm);
+extern void cpu_do_switch_mm(u64 pgd_phys, struct mm_struct *mm);
#ifdef CONFIG_ARM_LPAE
extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte);
#else
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 5900cd5..566c658 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -100,8 +100,8 @@ ENTRY(cpu_v6_dcache_clean_area)
*/
ENTRY(cpu_v6_switch_mm)
#ifdef CONFIG_MMU
+ ldr r1, [r2, #MM_CONTEXT_ID]@ get mm->context.id
mov r2, #0
- ldr r1, [r1, #MM_CONTEXT_ID]@ get mm->context.id
ALT_SMP(orr r0, r0, #TTB_FLAGS_SMP)
ALT_UP(orr r0, r0, #TTB_FLAGS_UP)
mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB
diff --git a/arch/arm/mm/proc-v7-2level.S b/arch/arm/mm/proc-v7-2level.S
index 42ac069..3397803 100644
--- a/arch/arm/mm/proc-v7-2level.S
+++ b/arch/arm/mm/proc-v7-2level.S
@@ -39,8 +39,8 @@
*/
ENTRY(cpu_v7_switch_mm)
#ifdef CONFIG_MMU
+ ldr r1, [r2, #MM_CONTEXT_ID]@ get mm->context.id
mov r2, #0
- ldr r1, [r1, #MM_CONTEXT_ID]@ get mm->context.id
ALT_SMP(orr r0, r0, #TTB_FLAGS_SMP)
ALT_UP(orr r0, r0, #TTB_FLAGS_UP)
#ifdef CONFIG_ARM_ERRATA_430973
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 8de0f1d..0001581 100644
--- a/arch/arm/mm/proc-v7-3level.S
+++ b/arch/arm/mm/proc-v7-3level.S
@@ -47,9 +47,10 @@
*/
ENTRY(cpu_v7_switch_mm)
#ifdef CONFIG_MMU
- ldr r1, [r1, #MM_CONTEXT_ID]@ get mm->context.id
- and r3, r1, #0xff
+ ldr r2, [r2, #MM_CONTEXT_ID]@ get mm->context.id
+ and r3, r2, #0xff
mov r3, r3, lsl #(48 - 32) @ ASID
+ orr r3, r3, r1 @ upper 32-bits of pgd phys
mcrrp15, 0, r0, r3, c2 @ set TTB 0
isb
#endif
--
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/
