Re: [PATCH] auxdisplay: ht16k33: select CONFIG_FB_SYS_FOPS
Hi Arnd,
On Wed, 23 Nov 2016 14:06:49 +0100
Arnd Bergmann wrote:
> The new driver caused a rare randconfig failure:
>
> drivers/auxdisplay/ht16k33.o:(.data.ht16k33_fb_ops+0xc): undefined reference
> to `fb_sys_read'
> drivers/auxdisplay/ht16k33.o:(.data.ht16k33_fb_ops+0x10): undefined reference
> to `fb_sys_write'
>
> This selects the respective helper module, like all other
> such drivers do.
Thanks for reporting this. You are right about the missing helper.
However, the fb_ops struct uses several helpers which are all missing.
static struct fb_ops ht16k33_fb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
.fb_write = fb_sys_write,
.fb_fillrect = sys_fillrect,
.fb_copyarea = sys_copyarea,
.fb_imageblit = sys_imageblit,
.fb_mmap = ht16k33_mmap,
};
HT16K33 should also select:
FB_CFB_FILLRECT
FB_CFB_COPYAREA
FB_CFB_IMAGEBLIT
>
> Fixes: 8992da44c680 ("auxdisplay: ht16k33: Driver for LED controller")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/auxdisplay/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
> index a230ea797b92..b8bbfc64a1d1 100644
> --- a/drivers/auxdisplay/Kconfig
> +++ b/drivers/auxdisplay/Kconfig
> @@ -131,6 +131,7 @@ config IMG_ASCII_LCD
> config HT16K33
> tristate "Holtek Ht16K33 LED controller with keyscan"
> depends on FB && OF && I2C && INPUT
> + select FB_SYS_FOPS
> select INPUT_MATRIXKMAP
> select FB_BACKLIGHT
> help
Regards,
Robin
[PATCH] regulator: twl: drop of_match_ptr
We can safely drop of_match_ptr since the driver
depends on CONFIG_OF symbol
Signed-off-by: Nicolae Rosia
---
Depends on "regulator: twl6030: add dependency on OF".
After sending that one I realised that twl-regulator can also
have that change. You can squash these two if you like.
drivers/regulator/twl-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 6c9ec84..48c060f 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -654,7 +654,7 @@ static struct platform_driver twlreg_driver = {
*/
.driver = {
.name = "twl4030_reg",
- .of_match_table = of_match_ptr(twl_of_match),
+ .of_match_table = twl_of_match,
},
};
--
2.9.3
Re: Multiple problems with the Linux kernel on an AMD desktop
On Thu, Nov 24, 2016 at 09:39:57PM -0200, Rogério Brito wrote: > Before I go on describing the problems that I have, I want to say that I can > bisect the kernel, apply patches and give feedback for the problems that I > am seeing. Good. We're going to need them. Please checkout lates Linus kernel: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git build it, boot it on your machine, catch dmesg and send it to me. Thanks! -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH] regulator: twl6030: add dependency on OF
This driver was converted to device tree only,
add dependency on OF symbol and drop of_match_ptr
Signed-off-by: Nicolae Rosia
---
drivers/regulator/Kconfig | 1 +
drivers/regulator/twl6030-regulator.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 936f7cc..ef70672 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -839,6 +839,7 @@ config REGULATOR_TPS80031
config REGULATOR_TWL4030
tristate "TI TWL4030/TWL5030/TWL6030/TPS659x0 PMIC"
depends on TWL4030_CORE
+ depends on OF
help
This driver supports the voltage regulators provided by
this family of companion chips.
diff --git a/drivers/regulator/twl6030-regulator.c
b/drivers/regulator/twl6030-regulator.c
index 4864b9d..1f327d7 100644
--- a/drivers/regulator/twl6030-regulator.c
+++ b/drivers/regulator/twl6030-regulator.c
@@ -773,7 +773,7 @@ static struct platform_driver twlreg_driver = {
*/
.driver = {
.name = "twl6030_reg",
- .of_match_table = of_match_ptr(twl_of_match),
+ .of_match_table = twl_of_match,
},
};
--
2.9.3
Re: [PATCH] z3fold: use %z modifier for format string
Hi Joe,
On Thu, Nov 24, 2016 at 6:08 PM, Joe Perches wrote:
> On Thu, 2016-11-24 at 17:31 +0100, Arnd Bergmann wrote:
>> Printing a size_t requires the %zd format rather than %d:
>>
>> mm/z3fold.c: In function ‘init_z3fold’:
>> include/linux/kern_levels.h:4:18: error: format ‘%d’ expects argument of
>> type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=]
>>
>> Fixes: 50a50d2676c4 ("z3fold: don't fail kernel build if z3fold_header is
>> too big")
>> Signed-off-by: Arnd Bergmann
>> ---
>> mm/z3fold.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/z3fold.c b/mm/z3fold.c
>> index e282ba073e77..66ac7a7dc934 100644
>> --- a/mm/z3fold.c
>> +++ b/mm/z3fold.c
>> @@ -884,7 +884,7 @@ static int __init init_z3fold(void)
>> {
>> /* Fail the initialization if z3fold header won't fit in one chunk */
>> if (sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED) {
>> - pr_err("z3fold: z3fold_header size (%d) is bigger than "
>> + pr_err("z3fold: z3fold_header size (%zd) is bigger than "
>> "the chunk size (%d), can't proceed\n",
>> sizeof(struct z3fold_header) , ZHDR_SIZE_ALIGNED);
>> return -E2BIG;
>
> The embedded "z3fold: " prefix here should be removed
> as there's a pr_fmt that also adds it.
>
> The test looks like it should be a BUILD_BUG_ON rather
> than any runtime test too.
It used to be BUILD_BUG_ON but we deliberately changed that because
sizeof(spinlock_t) gets bloated in debug builds, so it just won't
build with default CHUNK_SIZE.
~vitaly
Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies... [snip bloody good points I fully agree with] > I understand why there is a desire for stable tracepoints, and > that's why I suggested that there should be an in-kernel API to > declare stable tracepoints. That way we can have the best of both > worlds - tracepoints that applications need to be stable can be > declared, reviewed and explicitly marked as stable in full knowledge > of what that implies. The rest of the vast body of tracepoints can > be left as mutable with no stability or existence guarantees so that > developers can continue to treat them in a way that best suits > problem diagnosis without compromising the future development of the > code being traced. If userspace finds some of those tracepoints > useful, then they can be taken through the process of making them > into a maintainable stable form and being marked as such. My impression is that nobody (at least kernel-side) wants them to be a stable ABI, so long as nobody in userland screams about their code being broken, everything is fine. As usual, if nobody notices an ABI change, it hasn't happened. The question is what happens when somebody does. > We already have distros mounting the tracing subsystem on > /sys/kernel/tracing. Expose all the stable tracepoints there, and > leave all the other tracepoints under /sys/kernel/debug/tracing. > Simple, clear separation between stable and mutable diagnostic > tracepoints for users, combined with a simple, clear in-kernel API > and process for making tracepoints stable Yep. That kind of separation would be my preference as well - ideally, with review for stable ones being a lot less casual that for unstable; AFAICS what happens now is that we have no mechanisms for marking them as stable or unstable and everything keeps going on hope that nobody will cause a mess by creating such a userland dependency. So far it's been mostly working, but as the set of tracepoints (and their use) gets wider and wider, IMO it's only matter of time until we get seriously screwed that way. Basically, we are gambling on the next one to be cast in stone by userland dependency being sane enough to make it possible to maintain it indefinitely and I don't like the odds.
Re: [PATCH] z3fold: use %z modifier for format string
Hi Arnd,
On Thu, Nov 24, 2016 at 5:31 PM, Arnd Bergmann wrote:
> Printing a size_t requires the %zd format rather than %d:
>
> mm/z3fold.c: In function ‘init_z3fold’:
> include/linux/kern_levels.h:4:18: error: format ‘%d’ expects argument of type
> ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=]
>
> Fixes: 50a50d2676c4 ("z3fold: don't fail kernel build if z3fold_header is too
> big")
> Signed-off-by: Arnd Bergmann
Acked-by: Vitaly Wool
And thanks :)
~vitaly
> ---
> mm/z3fold.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index e282ba073e77..66ac7a7dc934 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -884,7 +884,7 @@ static int __init init_z3fold(void)
> {
> /* Fail the initialization if z3fold header won't fit in one chunk */
> if (sizeof(struct z3fold_header) > ZHDR_SIZE_ALIGNED) {
> - pr_err("z3fold: z3fold_header size (%d) is bigger than "
> + pr_err("z3fold: z3fold_header size (%zd) is bigger than "
> "the chunk size (%d), can't proceed\n",
> sizeof(struct z3fold_header) , ZHDR_SIZE_ALIGNED);
> return -E2BIG;
> --
> 2.9.0
>
Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order
Hi Viresh, On 11/25/2016 03:57 PM, Viresh Kumar wrote: > On 25-11-16, 10:54, Joonyoung Shim wrote: >> I found this problem during system suspend/resume of Odroid-XU3 board. >> >> # rtcwake -m mem -s 3 >> wakeup from "mem" at Wed Apr 4 05:54:44 2001 >> [ 15.965996] PM: Syncing filesystems ... done. >> [ 15.976333] Freezing user space processes ... (elapsed 0.002 seconds) >> done. >> [ 15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 >> seconds) done. >> [ 16.006951] wake enabled for irq 135 >> [ 16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode >> [ 16.094110] PM: suspend of devices complete after 95.038 msecs >> [ 16.105648] PM: late suspend of devices complete after 6.903 msecs >> [ 16.116356] PM: noirq suspend of devices complete after 5.912 msecs >> [ 16.121213] Disabling non-boot CPUs ... >> [ 16.154140] IRQ51 no longer affine to CPU1 >> [ 16.154709] CPU1: shutdown >> [ 16.214148] IRQ52 no longer affine to CPU2 >> [ 16.214646] CPU2: shutdown >> [ 16.273980] IRQ53 no longer affine to CPU3 >> [ 16.274458] CPU3: shutdown >> [ 16.335093] IRQ54 no longer affine to CPU4 >> [ 16.336033] CPU4: shutdown >> [ 16.389979] IRQ55 no longer affine to CPU5 >> [ 16.390823] CPU5: shutdown >> [ 16.444829] IRQ56 no longer affine to CPU6 >> [ 16.445621] CPU6: shutdown >> [ 16.509229] cpu cpu4: Failed to find opp_table: -19 >> [ 16.514008] IRQ57 no longer affine to CPU7 >> [ 16.514824] CPU7: shutdown > > Hi, > > Yes you have found a real bug it seems. I think that can be reproduced > by a simple rmmmod of cpufreq-dt.ko module as well. > > Though the solution you provided isn't good enough. > > Consider for example a case where you do this: > - offline CPU 4 > - suspend the system > > You are going to get stuck in the exact same problem again. > > I have sent a separate patch and cc'd you. Can you please verify that > it works for you ? > Thanks for the patch, i tested it and it is working well. Thanks.
Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
On 11/25/2016 03:53 PM, Viresh Kumar wrote: > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened because an earlier call to > dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file) > removed all the entries from opp_table->dev_list apart from the last CPU > device in the cpumask of CPUs sharing the OPP. > > But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator() > routines get CPU device for the first CPU in the cpumask. And so the OPP > core failed to find the OPP table for the struct device. > > This patch attempts to fix this problem by adding another field in the > struct opp_device: inactive. > > Instead of removing the entries from the list during > dev_pm_opp_of_cpumask_remove_table() function call, we mark them as > inactive. Such inactive devices will not be used by the core in most of > the cases, like before, but will be used only at special places which > need to take inactive devices into account. > > All the devices are removed from the list together now and that happens > only when the opp_table gets destroyed. > > This patch is tested on Dual A15, Exynos5250 platform by compiling the > cpufreq-dt driver as a module. The module is inserted/removed multiple > times with combinations of CPU offline/online steps. > > Signed-off-by: Viresh Kumar It's working well during system suspend/resume on my Odroid-XU3 board. Tested-by: Joonyoung Shim Thanks.
Re: automatic IRQ affinity for virtio
Btw, what's the best way to get any response to this series? But this and the predecessor seem to have completly fallen on deaf ears.
Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
On Fri, Nov 25, 2016 at 04:14:19AM +, Al Viro wrote: > [Linus Cc'd] > > On Fri, Nov 25, 2016 at 01:49:18PM +1100, Dave Chinner wrote: > > > they have become parts of stable userland ABI and are to be maintained > > > indefinitely. Don't expect "tracepoints are special case" to prevent > > > that. > > > > I call bullshit just like I always do when someone spouts this > > "tracepoints are stable ABI" garbage. > > > Quite frankly, anyone that wants to stop us from > > adding/removing/changing tracepoints or the code that they are > > reporting information about "because ABI" can go take a long walk > > off a short cliff. Diagnostic tracepoints are not part of the > > stable ABI. End of story. > > Tell that to Linus. You had been in the room, IIRC, when that had been > brought up this year in Santa Fe. No, I wasn't at KS or plumbers, so this is all news to me. Beleive me, if I was in the room when this discussion was in progress, you'd remember it /very clearly/. > "End of story" is not going to be > yours (or mine, for that matter) to declare - Linus is the only one who > can do that. If he says "if userland code relies upon it, so that > userland code needs to be fixed" - I'm very happy (and everyone involved > can count upon quite a few free drinks from me at the next summit). If > it's "that userland code really shouldn't have relied upon it, and it's > real unfortunate that it does, but we still get to keep it working" - > too bad, "because ABI" is the reality and we will be the ones to take > that long walk. When the tracepoint infrastructure was added it was considered a debugging tool and not stable - it was even exposed through /sys/kernel/debug! We connected up the ~280 /debug/ tracepoints we had in XFS at the time with the understanding it was a /diagnostic tool/. We exposed all sorts of internal details we'd previously been exposing with tracing through lcrash and kdb (and Irix before that) so we could diagnose problems quickly on a running kernel. The scope of tracepoints may have grown since then, but it does not change the fact that many of the tracepoints that were added years ago were done under the understanding that it was a mutable interface and nobody could rely on any specific tracepoint detail remaining unchanged. We're still treating then as mutable diagnostic and debugging aids across the kernel. In XFS, We've now got over *500* unique trace events and *650* tracepoints; ignoring comments, *4%* of the entire XFS kernel code base is tracing code. We expose structure contents, transaction states, locking algorithms, object life cycles, journal operations, etc. All the new reverse mapping and shared data extent code that has been merged in 4.8 and 4.9 has been extensively exposed by tracepoints - these changes also modified a significant number of existing tracepoints. Put simply: every major and most minor pieces of functionality in XFS are exposed via tracepoints. Hence if the stable ABI tracepoint rules you've just described are going to enforced, it will mean we will not be able to change anything signficant in XFS because almost everything significant we do involves changing tracepoints in some way. This leaves us with three unacceptable choices: 1. stop developing XFS so we can maintain the stable tracepoint ABI; 2. ignore the ABI rules and hope that Linus keeps pulling code that obviously ignores the ABI rules; or 3. screw over our upstream/vanilla kernel users by removing the tracepoints from Linus' tree and suck up the pain of maintaining an out of tree patch for XFS developers and distros so kernel tracepoint ABI rules can be ignored. Nobody wins if these are the only choices we are being given. I understand why there is a desire for stable tracepoints, and that's why I suggested that there should be an in-kernel API to declare stable tracepoints. That way we can have the best of both worlds - tracepoints that applications need to be stable can be declared, reviewed and explicitly marked as stable in full knowledge of what that implies. The rest of the vast body of tracepoints can be left as mutable with no stability or existence guarantees so that developers can continue to treat them in a way that best suits problem diagnosis without compromising the future development of the code being traced. If userspace finds some of those tracepoints useful, then they can be taken through the process of making them into a maintainable stable form and being marked as such. We already have distros mounting the tracing subsystem on /sys/kernel/tracing. Expose all the stable tracepoints there, and leave all the other tracepoints under /sys/kernel/debug/tracing. Simple, clear separation between stable and mutable diagnostic tracepoints for users, combined with a simple, clear in-kernel API and process for making tracepoints stable Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order
On 25-11-16, 10:54, Joonyoung Shim wrote: > I found this problem during system suspend/resume of Odroid-XU3 board. > > # rtcwake -m mem -s 3 > wakeup from "mem" at Wed Apr 4 05:54:44 2001 > [ 15.965996] PM: Syncing filesystems ... done. > [ 15.976333] Freezing user space processes ... (elapsed 0.002 seconds) done. > [ 15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) > done. > [ 16.006951] wake enabled for irq 135 > [ 16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode > [ 16.094110] PM: suspend of devices complete after 95.038 msecs > [ 16.105648] PM: late suspend of devices complete after 6.903 msecs > [ 16.116356] PM: noirq suspend of devices complete after 5.912 msecs > [ 16.121213] Disabling non-boot CPUs ... > [ 16.154140] IRQ51 no longer affine to CPU1 > [ 16.154709] CPU1: shutdown > [ 16.214148] IRQ52 no longer affine to CPU2 > [ 16.214646] CPU2: shutdown > [ 16.273980] IRQ53 no longer affine to CPU3 > [ 16.274458] CPU3: shutdown > [ 16.335093] IRQ54 no longer affine to CPU4 > [ 16.336033] CPU4: shutdown > [ 16.389979] IRQ55 no longer affine to CPU5 > [ 16.390823] CPU5: shutdown > [ 16.444829] IRQ56 no longer affine to CPU6 > [ 16.445621] CPU6: shutdown > [ 16.509229] cpu cpu4: Failed to find opp_table: -19 > [ 16.514008] IRQ57 no longer affine to CPU7 > [ 16.514824] CPU7: shutdown Hi, Yes you have found a real bug it seems. I think that can be reproduced by a simple rmmmod of cpufreq-dt.ko module as well. Though the solution you provided isn't good enough. Consider for example a case where you do this: - offline CPU 4 - suspend the system You are going to get stuck in the exact same problem again. I have sent a separate patch and cc'd you. Can you please verify that it works for you ? -- viresh
Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
On 25-11-16, 12:23, Viresh Kumar wrote: > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened because an earlier call to > dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file) > removed all the entries from opp_table->dev_list apart from the last CPU > device in the cpumask of CPUs sharing the OPP. > > But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator() > routines get CPU device for the first CPU in the cpumask. And so the OPP > core failed to find the OPP table for the struct device. > > This patch attempts to fix this problem by adding another field in the > struct opp_device: inactive. > > Instead of removing the entries from the list during > dev_pm_opp_of_cpumask_remove_table() function call, we mark them as > inactive. Such inactive devices will not be used by the core in most of > the cases, like before, but will be used only at special places which > need to take inactive devices into account. > > All the devices are removed from the list together now and that happens > only when the opp_table gets destroyed. > > This patch is tested on Dual A15, Exynos5250 platform by compiling the > cpufreq-dt driver as a module. The module is inserted/removed multiple > times with combinations of CPU offline/online steps. > > Signed-off-by: Viresh Kumar @Rafael: Can you please add following while applying the patch ? Cc: # v4.4+ Somehow git send-email wasn't working properly for me as it was trying to cc sta...@vger.kernel.org#v4.4+ and that was failing. I tried lots of options including suppress-cc but nothing worked :( -- viresh
[PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
Joonyoung Shim reported an interesting problem on his ARM octa-core
Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
was failing for a struct device for which dev_pm_opp_set_regulator() is
called earlier.
This happened because an earlier call to
dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
removed all the entries from opp_table->dev_list apart from the last CPU
device in the cpumask of CPUs sharing the OPP.
But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
routines get CPU device for the first CPU in the cpumask. And so the OPP
core failed to find the OPP table for the struct device.
This patch attempts to fix this problem by adding another field in the
struct opp_device: inactive.
Instead of removing the entries from the list during
dev_pm_opp_of_cpumask_remove_table() function call, we mark them as
inactive. Such inactive devices will not be used by the core in most of
the cases, like before, but will be used only at special places which
need to take inactive devices into account.
All the devices are removed from the list together now and that happens
only when the opp_table gets destroyed.
This patch is tested on Dual A15, Exynos5250 platform by compiling the
cpufreq-dt driver as a module. The module is inserted/removed multiple
times with combinations of CPU offline/online steps.
Signed-off-by: Viresh Kumar
---
drivers/base/power/opp/core.c| 156 ++-
drivers/base/power/opp/cpu.c | 4 +-
drivers/base/power/opp/debugfs.c | 4 +-
drivers/base/power/opp/of.c | 2 +-
drivers/base/power/opp/opp.h | 6 +-
5 files changed, 116 insertions(+), 56 deletions(-)
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 4c7c6da7a989..df3c8b3a62ea 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -40,14 +40,30 @@ do {
\
"opp_table_lock protection"); \
} while (0)
+/**
+ * _find_opp_dev - Returns existing opp_dev for opp table
+ *
+ * @dev: Device for which opp_dev needs to be found
+ * @opp_table: OPP table.
+ * @active_only: If true: find only for active entries. If false, find for both
+ * active and inactive entries.
+ */
static struct opp_device *_find_opp_dev(const struct device *dev,
- struct opp_table *opp_table)
+ struct opp_table *opp_table,
+ bool active_only)
{
struct opp_device *opp_dev;
- list_for_each_entry(opp_dev, &opp_table->dev_list, node)
- if (opp_dev->dev == dev)
- return opp_dev;
+ list_for_each_entry(opp_dev, &opp_table->dev_list, node) {
+ if (opp_dev->dev != dev)
+ continue;
+
+ /* Only return active entries ? */
+ if (active_only && opp_dev->inactive)
+ return NULL;
+
+ return opp_dev;
+ }
return NULL;
}
@@ -55,6 +71,8 @@ static struct opp_device *_find_opp_dev(const struct device
*dev,
/**
* _find_opp_table() - find opp_table struct using device pointer
* @dev: device pointer used to lookup OPP table
+ * @active_only: If true: find only for active entries. If false, find for both
+ * active and inactive entries.
*
* Search OPP table for one containing matching device. Does a RCU reader
* operation to grab the pointer needed.
@@ -68,7 +86,7 @@ static struct opp_device *_find_opp_dev(const struct device
*dev,
*
* For Writers, this function must be called with opp_table_lock held.
*/
-struct opp_table *_find_opp_table(struct device *dev)
+struct opp_table *_find_opp_table(struct device *dev, bool active_only)
{
struct opp_table *opp_table;
@@ -80,7 +98,7 @@ struct opp_table *_find_opp_table(struct device *dev)
}
list_for_each_entry_rcu(opp_table, &opp_tables, node)
- if (_find_opp_dev(dev, opp_table))
+ if (_find_opp_dev(dev, opp_table, active_only))
return opp_table;
return ERR_PTR(-ENODEV);
@@ -199,7 +217,7 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct
device *dev)
rcu_read_lock();
- opp_table = _find_opp_table(dev);
+ opp_table = _find_opp_table(dev, true);
if (IS_ERR(opp_table))
clock_latency_ns = 0;
else
@@ -229,7 +247,7 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct device
*dev)
rcu_read_lock();
- opp_table = _find_opp_table(dev);
+ opp_table = _find_opp_table(dev, true);
if (IS_ERR(opp_table)) {
rcu_read_unlock();
return 0;
@@ -302,7 +320,7 @@ struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device
*dev)
opp_rcu_lockdep_assert();
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
> Mark Lord [mailto:ml...@pobox.com]
> > Sent: Friday, November 25, 2016 12:44 AM
> [...]
> > The bad data in this case is ASCII:
> >
> > "SRC=m3400:/ TARGET=/m340"
> >
> > This data is what is seen in /run/mount/utab, a file that is read/written
> > over NFS
> on
> > each boot.
> >
> > "SRC=m3400:/ TARGET=/m3400 ROOT=/
> > ATTRS=nolock,addr=192.168.8.1\n"
> >
> > But how does this ASCII data end up at offset zero of the rx buffer??
> > Not possible -- this isn't even stale data, because only an rx_desc could
> > be at that offset in that buffer.
> >
> > So even if this were a platform memory coherency issue, one should still
> > never see ASCII data at the beginning of an rx buffer. The driver NEVER
> > writes anything to the rx buffers. Only the USB hardware ever does.
> >
> > And only the r8152 dongle/driver exhibits this issue.
> > Other USB dongles do not. They *might* still have such issues,
> > but because they use software checksums, the bad packets are
> > caught/rejected.
>
> Do you test it by rebooting? Maybe you could try a patch
> commit 93fe9b183840 ("r8152: reset the bmu"). However, it should
> only occur for the first urb buffer after rx is reset. I don't
> think you would reset the rx frequently, so the situation seems
> to be different.
Forgive me. I provide wrong information. This is about RTL8153,
not RTL8152.
Best Regards,
Hayes
[tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit
Commit-ID: 018edcfac4c3b140366ad51b0907f3becb5bb624
Gitweb: http://git.kernel.org/tip/018edcfac4c3b140366ad51b0907f3becb5bb624
Author: Ard Biesheuvel
AuthorDate: Thu, 24 Nov 2016 18:02:23 +
Committer: Ingo Molnar
CommitDate: Fri, 25 Nov 2016 07:15:23 +0100
efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit
The UEFI stub executes in the context of the firmware, which identity
maps the available system RAM, which implies that only memory below
4 GB can be used for allocations on 32-bit architectures, even on [L]PAE
capable hardware.
So ignore any reported memory above 4 GB in efi_random_alloc(). This
also fixes a reported build problem on ARM under -Os, where the 64-bit
logical shift relies on a software routine that the ARM decompressor does
not provide.
A second [minor] issue is also fixed, where the '+ 1' is moved out of
the shift, where it belongs: the reason for its presence is that a
memory region where start == end should count as a single slot, given
that 'end' takes the desired size and alignment of the allocation into
account.
To clarify the code in this regard, rename start/end to 'first_slot' and
'last_slot', respectively, and introduce 'region_end' to describe the
last usable address of the current region.
Reported-by: Arnd Bergmann
Signed-off-by: Ard Biesheuvel
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1480010543-25709-2-git-send-email-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar
---
drivers/firmware/efi/libstub/random.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/efi/libstub/random.c
b/drivers/firmware/efi/libstub/random.c
index 3a3feac..7e72954 100644
--- a/drivers/firmware/efi/libstub/random.c
+++ b/drivers/firmware/efi/libstub/random.c
@@ -45,19 +45,20 @@ static unsigned long get_entry_num_slots(efi_memory_desc_t
*md,
unsigned long align_shift)
{
unsigned long align = 1UL << align_shift;
- u64 start, end;
+ u64 first_slot, last_slot, region_end;
if (md->type != EFI_CONVENTIONAL_MEMORY)
return 0;
- start = round_up(md->phys_addr, align);
- end = round_down(md->phys_addr + md->num_pages * EFI_PAGE_SIZE - size,
-align);
+ region_end = min((u64)ULONG_MAX, md->phys_addr +
md->num_pages*EFI_PAGE_SIZE - 1);
- if (start > end)
+ first_slot = round_up(md->phys_addr, align);
+ last_slot = round_down(region_end - size + 1, align);
+
+ if (first_slot > last_slot)
return 0;
- return (end - start + 1) >> align_shift;
+ return ((unsigned long)(last_slot - first_slot) >> align_shift) + 1;
}
/*
[tip:x86/asm] x86/boot/64: Use defines for page size
Commit-ID: 9b032d21f6482ee305dcdec418c15153614b1dcc Gitweb: http://git.kernel.org/tip/9b032d21f6482ee305dcdec418c15153614b1dcc Author: Borislav Petkov AuthorDate: Thu, 24 Nov 2016 22:05:50 +0100 Committer: Ingo Molnar CommitDate: Fri, 25 Nov 2016 07:11:29 +0100 x86/boot/64: Use defines for page size ... instead of naked numbers like the rest of the asm does in this file. No code changed: # arch/x86/kernel/head_64.o: textdata bss dec hex filename 1124 2908644096 296084 48494 head_64.o.before 1124 2908644096 296084 48494 head_64.o.after md5: 87086e202588939296f66e892414ffe2 head_64.o.before.asm 87086e202588939296f66e892414ffe2 head_64.o.after.asm Signed-off-by: Borislav Petkov Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20161124210550.15025-1...@alien8.de Signed-off-by: Ingo Molnar --- arch/x86/kernel/head_64.S | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index b07cd27..a15d381 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -112,20 +112,20 @@ startup_64: movq%rdi, %rax shrq$PGDIR_SHIFT, %rax - leaq(4096 + _KERNPG_TABLE)(%rbx), %rdx + leaq(PAGE_SIZE + _KERNPG_TABLE)(%rbx), %rdx movq%rdx, 0(%rbx,%rax,8) movq%rdx, 8(%rbx,%rax,8) - addq$4096, %rdx + addq$PAGE_SIZE, %rdx movq%rdi, %rax shrq$PUD_SHIFT, %rax andl$(PTRS_PER_PUD-1), %eax - movq%rdx, 4096(%rbx,%rax,8) + movq%rdx, PAGE_SIZE(%rbx,%rax,8) incl%eax andl$(PTRS_PER_PUD-1), %eax - movq%rdx, 4096(%rbx,%rax,8) + movq%rdx, PAGE_SIZE(%rbx,%rax,8) - addq$8192, %rbx + addq$PAGE_SIZE * 2, %rbx movq%rdi, %rax shrq$PMD_SHIFT, %rdi addq$(__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL), %rax
[tip:locking/urgent] locking/selftest: Fix output since KERN_CONT changes
Commit-ID: 2513940989fa2c56d0aeb4f5792d22804d92ab4c
Gitweb: http://git.kernel.org/tip/2513940989fa2c56d0aeb4f5792d22804d92ab4c
Author: Michael Ellerman
AuthorDate: Fri, 25 Nov 2016 09:45:28 +1100
Committer: Ingo Molnar
CommitDate: Fri, 25 Nov 2016 07:12:19 +0100
locking/selftest: Fix output since KERN_CONT changes
Since the KERN_CONT changes the locking-selftest output is messed up, eg:
| spin |wlock |rlock |mutex | wsem | rsem |
--
A-A deadlock:
ok |
ok |
ok |
ok |
ok |
ok |
Use pr_cont() to get it looking normal again:
| spin |wlock |rlock |mutex | wsem | rsem |
--
A-A deadlock: ok | ok | ok | ok | ok | ok |
Reported-by: Christian Kujau
Signed-off-by: Michael Ellerman
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linuxppc-...@ozlabs.org
Link:
http://lkml.kernel.org/r/1480027528-934-1-git-send-email-...@ellerman.id.au
Signed-off-by: Ingo Molnar
---
lib/locking-selftest.c | 66 +-
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 872a15a..f3a217e 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -980,23 +980,23 @@ static void dotest(void (*testcase_fn)(void), int
expected, int lockclass_mask)
#ifndef CONFIG_PROVE_LOCKING
if (expected == FAILURE && debug_locks) {
expected_testcase_failures++;
- printk("failed|");
+ pr_cont("failed|");
}
else
#endif
if (debug_locks != expected) {
unexpected_testcase_failures++;
- printk("FAILED|");
+ pr_cont("FAILED|");
dump_stack();
} else {
testcase_successes++;
- printk(" ok |");
+ pr_cont(" ok |");
}
testcase_total++;
if (debug_locks_verbose)
- printk(" lockclass mask: %x, debug_locks: %d, expected: %d\n",
+ pr_cont(" lockclass mask: %x, debug_locks: %d, expected: %d\n",
lockclass_mask, debug_locks, expected);
/*
* Some tests (e.g. double-unlock) might corrupt the preemption
@@ -1021,26 +1021,26 @@ static inline void print_testname(const char *testname)
#define DO_TESTCASE_1(desc, name, nr) \
print_testname(desc"/"#nr); \
dotest(name##_##nr, SUCCESS, LOCKTYPE_RWLOCK); \
- printk("\n");
+ pr_cont("\n");
#define DO_TESTCASE_1B(desc, name, nr) \
print_testname(desc"/"#nr); \
dotest(name##_##nr, FAILURE, LOCKTYPE_RWLOCK); \
- printk("\n");
+ pr_cont("\n");
#define DO_TESTCASE_3(desc, name, nr) \
print_testname(desc"/"#nr); \
dotest(name##_spin_##nr, FAILURE, LOCKTYPE_SPIN); \
dotest(name##_wlock_##nr, FAILURE, LOCKTYPE_RWLOCK);\
dotest(name##_rlock_##nr, SUCCESS, LOCKTYPE_RWLOCK);\
- printk("\n");
+ pr_cont("\n");
#define DO_TESTCASE_3RW(desc, name, nr)\
print_testname(desc"/"#nr); \
dotest(name##_spin_##nr, FAILURE, LOCKTYPE_SPIN|LOCKTYPE_RWLOCK);\
dotest(name##_wlock_##nr, FAILURE, LOCKTYPE_RWLOCK);\
dotest(name##_rlock_##nr, SUCCESS, LOCKTYPE_RWLOCK);\
- printk("\n");
+ pr_cont("\n");
#define DO_TESTCASE_6(desc, name) \
print_testname(desc); \
@@ -1050,7 +1050,7 @@ static inline void print_testname(const char *testname)
dotest(name##_mutex, FAILURE, LOCKTYPE_MUTEX); \
dotest(name##_wsem, FAILURE, LOCKTYPE_RWSEM); \
dotest(name##_rsem, FAILURE, LOCKTYPE_RWSEM); \
- printk("\n");
+ pr_cont("\n");
#define DO_TESTCASE_6_SUCCESS(desc, name) \
print_testname(desc); \
@@ -1060,7 +1060,7 @@ static inline void print_testname(const char *testname)
dotest(name##_mutex, SUCCESS, LOCKTYPE_MUTEX); \
dotest(name##_wsem, SUCCESS, LOCKTYPE_RWSEM); \
dotest(name##_rsem, SUCCESS, LOCKTYPE_RWSEM); \
- printk("\n");
+ pr_cont("\n");
/*
* 'read' variant: rlocks must not trigger.
@@ -1073,7 +1073,7 @@ s
Re: [PATCH] drm/hisilicon/hibmc: mark PM functions __maybe_unused
On Thu, Nov 24, 2016 at 05:30:26PM +0100, Arnd Bergmann wrote:
> When CONFIG_PM_SLEEP is disabled, we get a harmless warning
>
> drm/hisilicon/hibmc/hibmc_drm_drv.c:115:12: error: ‘hibmc_pm_resume’ defined
> but not used [-Werror=unused-function]
> drm/hisilicon/hibmc/hibmc_drm_drv.c:97:12: error: ‘hibmc_pm_suspend’ defined
> but not used [-Werror=unused-function]
>
> Marking the functions as __maybe_unused avoids the warning without
> having to add an #ifdef.
>
> Fixes: 5e0df3a08f3d ("drm/hisilicon/hibmc: Add hisilicon hibmc drm master
> driver")
> Signed-off-by: Arnd Bergmann
Applied to drm-misc, thx.
-Daniel
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 73ba8b05f1da..fd949df46717 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -94,7 +94,7 @@ static struct drm_driver hibmc_driver = {
> .irq_handler= hibmc_drm_interrupt,
> };
>
> -static int hibmc_pm_suspend(struct device *dev)
> +static int __maybe_unused hibmc_pm_suspend(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> @@ -112,7 +112,7 @@ static int hibmc_pm_suspend(struct device *dev)
> return 0;
> }
>
> -static int hibmc_pm_resume(struct device *dev)
> +static int __maybe_unused hibmc_pm_resume(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> --
> 2.9.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
On Fri, Nov 25, 2016 at 01:28:47AM +0100, meg...@megous.com wrote: > From: Ondrej Jirman > > When adjusting PLL_CPUX on H3, the PLL is temporarily driven > too high, and the system becomes unstable (oopses or hangs). > > Add a notifier to avoid this situation by temporarily switching > to a known stable 24 MHz oscillator. > > Signed-off-by: Ondrej Jirman > Tested-by: Lutz Sammer Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] staging: most: Eliminate symbolic permissions usage
On Thu, Nov 24, 2016 at 03:10:29PM -0700, Jason Litzinger wrote: > Fix checkpatch warnings regarding the use of symbolic permissions. > > Where the MOST_CHANNEL_ATTR macro is used, convert to octal permissions > over symbolic. > > Where _ATTR is used directly, replace with _ATTR_RW/_ATTR_WO and > update the show/store function names appropriately. Please ignore this, the most driver was not checked in my config so my test-compile was worthless (it doesn't). Will submit again. -Jason
Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on
On Fri, Nov 25, 2016 at 1:23 AM, Laurent Pinchart wrote: >> > Daniel, why do we have an API the is clearly related to interrupt handling >> > but requires the caller to implement a workqueue ? >> >> Because in general you need that workqueue anyway, and up to now there was >> no driver ever who didn't have a work-queue already. > > None of the bridge drivers in drivers/gpu/drm/bridge/ have workqueues. They > call the HPD helpers from a threaded interrupt handler though. Sleeping in > that context is fine, calling functions that might rely on interrupts from the > same device to signal completion (such as reading EDID through .get_modes()) > isn't. Hm, as long as they all use the bit-banging interfaces they'll probably be all fine. For everyone else you need multiple layers of work items to make sure you never end up stalling in an interrupt vs. holding-mode_config.mutex deadlock. So still not convinced we need this ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 25, 2016 12:44 AM
[...]
> The bad data in this case is ASCII:
>
> "SRC=m3400:/ TARGET=/m340"
>
> This data is what is seen in /run/mount/utab, a file that is read/written
> over NFS on
> each boot.
>
> "SRC=m3400:/ TARGET=/m3400 ROOT=/
> ATTRS=nolock,addr=192.168.8.1\n"
>
> But how does this ASCII data end up at offset zero of the rx buffer??
> Not possible -- this isn't even stale data, because only an rx_desc could
> be at that offset in that buffer.
>
> So even if this were a platform memory coherency issue, one should still
> never see ASCII data at the beginning of an rx buffer. The driver NEVER
> writes anything to the rx buffers. Only the USB hardware ever does.
>
> And only the r8152 dongle/driver exhibits this issue.
> Other USB dongles do not. They *might* still have such issues,
> but because they use software checksums, the bad packets are caught/rejected.
Do you test it by rebooting? Maybe you could try a patch
commit 93fe9b183840 ("r8152: reset the bmu"). However, it should
only occur for the first urb buffer after rx is reset. I don't
think you would reset the rx frequently, so the situation seems
to be different.
Best Regards,
Hayes
Re: [PATCH 1/1 linux-next] ext4: add compatibility flag check
> On 25 November 2016 at 06:26 Theodore Ts'o wrote: > > > On Thu, Nov 24, 2016 at 08:47:41PM +0100, Fabian Frederick wrote: > > data=journal mount option should disable O_DIRECT access > > (See Documentation/filesystems/ext4.txt) but open operations > > using O_CREAT|O_RDWR|O_DIRECT|O_SYNC have no warning in return and file is > > being > > created. This patch adds vfs super_operations compatibility flag function > > returning -EPERM in such a case. > > > > Signed-off-by: Fabian Frederick > > The general practice by most file systems in Linux (for better or for > worse) is to silently fall back to buffered I/O instead of failing the > O_DIRECT open. Feel free to try to convince linux-fsdevel otherwise, > but that is the general and historical consensus of Linux file system > developers. > > Cheers, Thanks a lot Ted, I'll have a closer look at vfs/ext4 documentation and add some details if required. Regards, Fabian > > - Ted
Re: [PATCH v2] dmaengine: sun6i: fix the uninitialized value for v_lli
On Sun, Nov 20, 2016 at 12:43:56AM +0800, Hao Zhang wrote: > dma_pool_alloc does not initialize the value of the newly allocated > block for the v_lli, and the uninitilize value make the tests failed > which is on pine64 with dmatest. > we can fix it just change the "|=" to "=" for the v_lli->cfg. Applied, thanks -- ~Vinod
RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
Mark Lord [mailto:ml...@pobox.com] > Sent: Thursday, November 24, 2016 11:25 PM [...] > x86 has near fully-coherent memory, so it is the "easy" platform > to get things working on. But Linux supports a very diverse number > of platforms, with varying degrees of cache/memory coherency, > and it can be tricky for things to work correctly on all of them. However, I have test iperf on raspberry pi v1 which you suggest for more than one day. I still couldn't reproduce your issue. > If you are testing with the driver as currently in 4.4.34, > then you won't even notice when things are screwing up, > because the driver just silently drops packets. > Or it passes them on without noticing that they have bad data. I only drop the packet silently when the rx descriptor outside the urb buffer. Then, I check the rx descriptor before checking the length of the packet. > Here (attached) is the instrumented driver I am using here now. > I suggest you use it or something similar when testing, > and not the stock driver. I would test it again with your driver. [...] > Also, unrelated, but inside r8152_submit_rx() there is this code: > > /* The rx would be stopped, so skip submitting */ > if (test_bit(RTL8152_UNPLUG, &tp->flags) || > !test_bit(WORK_ENABLE, &tp->flags) > || !netif_carrier_ok(tp->netdev)) > return 0; > > If that "return 0" statement is ever executed, doesn't it result > in the loss/leak of a buffer? They would be found back by calling rtl_start_rx(), when the rx is restarted. Best Regards, Hayes
Re: [PATCH] dmaengine: mv_xor: use builtin_platform_driver
On Fri, Nov 18, 2016 at 10:12:26PM +0800, Geliang Tang wrote: > Use builtin_platform_driver() helper to simplify the code. Applied, thanks -- ~Vinod
RE: [PATCH V3 2/4] mfd: pv88080: MFD core support
On Monday, November 21, 2016 10:09 PM, Lee Jones Wrote:
>
> On Fri, 18 Nov 2016, Eric Jeong wrote:
>
> >
> > From: Eric Jeong
> >
> > This patch adds supports for PV88080 MFD core device.
> >
> > It provides communication through the I2C interface.
> > It contains the following components:
> > - Regulators
> > - Configurable GPIOs
> >
> > Kconfig and Makefile are updated to reflect support for PV88080 PMIC.
> >
> > Signed-off-by: Eric Jeong
> >
> > ---
> > This patch applies against linux-next and next-20161117
> >
> > Hi,
> >
> > This patch adds MFD core driver for PV88080 PMIC.
> > This is done as part of the existing PV88080 regulator driver by
> > expending the driver for GPIO function support.
> >
> > Change since PATCH V2
> > - Make one file insted of usging core and i2c file
> > - Use devm_ function to be managed resource automatically
> > - Separated mfd_cell and regmap_irq_chip declaration for clarification.
> > - Updated Kconfig to use OF and assign yes to I2C
> >
> > Change since PATCH V1
> > - Patch separated from PATCH V1
> >
> > Regards,
> > Eric Jeong, Dialog Semiconductor Ltd.
> >
> >
> > drivers/mfd/Kconfig | 12 ++
> > drivers/mfd/Makefile|1 +
> > drivers/mfd/pv88080.c | 331
> > +++
> > include/linux/mfd/pv88080.h | 222 +
> > 4 files changed, 566 insertions(+)
> > create mode 100644 drivers/mfd/pv88080.c create mode 100644
> > include/linux/mfd/pv88080.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index
> > 06dc9b0..75abf2d 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -792,6 +792,18 @@ config MFD_PM8921_CORE
> > Say M here if you want to include support for PM8921 chip as a module.
> > This will build a module called "pm8921-core".
> >
> > +config MFD_PV88080
> > + tristate "Powerventure Semiconductor PV88080 PMIC Support"
> > + select MFD_CORE
> > + select REGMAP_I2C
> > + select REGMAP_IRQ
> > + depends on I2C=y && OF
> > + help
> > + Say yes here for support for the Powerventure Semiconductor PV88080
> > PMIC.
> > + This includes the I2C driver and core APIs.
> > + Additional drivers must be enabled in order to use the functionality
> > + of the device.
> > +
> > config MFD_QCOM_RPM
> > tristate "Qualcomm Resource Power Manager (RPM)"
> > depends on ARCH_QCOM && OF
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index
> > db39377..e9e16c6 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -173,6 +173,7 @@ obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
> > obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
> > obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
> > obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o ssbi.o
> > +obj-$(CONFIG_MFD_PV88080) += pv88080.o
> > obj-$(CONFIG_MFD_QCOM_RPM) += qcom_rpm.o
> > obj-$(CONFIG_MFD_SPMI_PMIC)+= qcom-spmi-pmic.o
> > obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
> > diff --git a/drivers/mfd/pv88080.c b/drivers/mfd/pv88080.c new file
> > mode 100644 index 000..518b44f
> > --- /dev/null
> > +++ b/drivers/mfd/pv88080.c
> > @@ -0,0 +1,331 @@
> > +/*
> > + * pv88080-i2c.c - I2C access driver for PV88080
>
> Remove the filename.
>
> They have a habit of becoming out of date (like now).
OK, I will do that.
>
> > + * Copyright (C) 2016 Powerventure Semiconductor Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Alphabetical.
OK, I see.
>
> > +#include
>
> This doesn't need to be separated from the rest.
OK.
>
> > +#definePV88080_REG_EVENT_A_OFFSET 0
> > +#definePV88080_REG_EVENT_B_OFFSET 1
> > +#definePV88080_REG_EVENT_C_OFFSET 2
>
> Spaces after 'define'.
OK I will do that.
>
> > +static const struct resource regulators_aa_resources[] = {
> > + {
> > + .name = "VDD_TEMP_FAULT",
> > + .start = PV88080_AA_IRQ_VDD_FLT,
> > + .end= PV88080_AA_IRQ_OVER_TEMP,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > +};
> > +
> > +static const struct resource regulators_ba_resources[] = {
> > + {
> > + .name = "VDD_TEMP_FAULT",
> > + .start = PV88080_BA_IRQ_VDD_FLT,
> > + .end= PV88080_BA_IRQ_OVER_TEMP,
> > + .flags =
Re: [PATCH v2 2/2] dmaengine: omap-dma: Support for slave devices with data port window
On Thu, Nov 17, 2016 at 02:50:17PM +0200, Peter Ujfalusi wrote:
> @@ -921,11 +931,45 @@ static struct dma_async_tx_descriptor
> *omap_dma_prep_slave_sg(
>
> d->ccr = c->ccr | CCR_SYNC_FRAME;
> if (dir == DMA_DEV_TO_MEM) {
> - d->ccr |= CCR_DST_AMODE_POSTINC | CCR_SRC_AMODE_CONSTANT;
> d->csdp = CSDP_DST_BURST_64 | CSDP_DST_PACKED;
> +
> + d->ccr |= CCR_DST_AMODE_POSTINC;
> + if (port_window) {
> + d->ccr |= CCR_SRC_AMODE_DBLIDX;
> + d->ei = 1;
> + /*
> + * One frame covers the port_window and by configure
> + * the source frame index to be -1 * (port_window - 1)
> + * we instruct the sDMA that after a frame is processed
> + * it should move back to the start of the window.
> + */
> + d->fi = -(port_window - 1);
> +
> + if (port_window >= 64)
> + d->csdp = CSDP_SRC_BURST_64 | CSDP_SRC_PACKED;
> + else if (port_window >= 32)
> + d->csdp = CSDP_SRC_BURST_32 | CSDP_SRC_PACKED;
> + else if (port_window >= 16)
> + d->csdp = CSDP_SRC_BURST_16 | CSDP_SRC_PACKED;
this and other would look better with a switch..
--
~Vinod
Re: [PATCH 02/10] ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls
On Fri, Nov 25, 2016 at 1:43 PM, Icenowy Zheng wrote: > > > 12.11.2016, 14:57, "Chen-Yu Tsai" : >> The internal codec on A23/A33/H3 is split into 2 parts. The >> analog path controls are routed through an embedded custom register >> bus accessed through the PRCM block. >> >> The SoCs share a common set of inputs, outputs, and audio paths. >> The following table lists the differences. >> >> >> | Feature \ SoC | A23 | A33 | H3 | >> >> | Headphone | v | v | | >> >> | Line Out | | | v | >> >> | Phone In/Out | v | v | | >> >> >> Add an ASoC component driver for it. This should be tied to the codec >> audio card as an auxiliary device. This patch adds the commont paths >> and controls, and variant specific headphone out and line out. >> >> Signed-off-by: Chen-Yu Tsai >> --- >> sound/soc/sunxi/Kconfig | 8 + >> sound/soc/sunxi/Makefile | 1 + >> sound/soc/sunxi/sun8i-codec-analog.c | 665 >> +++ >> 3 files changed, 674 insertions(+) >> create mode 100644 sound/soc/sunxi/sun8i-codec-analog.c >> >> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig >> index dd2368297fd3..6c344e16aca4 100644 >> --- a/sound/soc/sunxi/Kconfig >> +++ b/sound/soc/sunxi/Kconfig >> @@ -9,6 +9,14 @@ config SND_SUN4I_CODEC >>Select Y or M to add support for the Codec embedded in the >> Allwinner >>A10 and affiliated SoCs. >> >> +config SND_SUN8I_CODEC_ANALOG >> + tristate "Allwinner sun8i Codec Analog Controls Support" >> + depends on MACH_SUN8I || COMPILE_TEST > > sun50i-a64 has a similar (or the same?) codec to A33. > I think the register offsets/fields were moved around again. Why does Allwinner always do that... :/ ChenYu >> + select REGMAP >> + help >> + Say Y or M if you want to add support for the analog controls for >> + the codec embedded in newer Allwinner SoCs. >> + >> config SND_SUN4I_I2S >> tristate "Allwinner A10 I2S Support" >> select SND_SOC_GENERIC_DMAENGINE_PCM >> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile >> index 604c7b842837..241c0df9ca0c 100644 >> --- a/sound/soc/sunxi/Makefile >> +++ b/sound/soc/sunxi/Makefile >> @@ -1,3 +1,4 @@ >> obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o >> obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o >> obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o >> +obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o >> diff --git a/sound/soc/sunxi/sun8i-codec-analog.c >> b/sound/soc/sunxi/sun8i-codec-analog.c >> new file mode 100644 >> index ..222bbd440b1e >> --- /dev/null >> +++ b/sound/soc/sunxi/sun8i-codec-analog.c >> @@ -0,0 +1,665 @@ >> +/* >> + * This driver supports the analog controls for the internal codec >> + * found in Allwinner's A31s, A23, A33 and H3 SoCs. >> + * >> + * Copyright 2016 Chen-Yu Tsai >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License as published by >> + * the Free Software Foundation; either version 2 of the License, or >> + * (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> + >> +/* Codec analog control register offsets and bit fields */ >> +#define SUN8I_ADDA_HP_VOLC 0x00 >> +#define SUN8I_ADDA_HP_VOLC_PA_CLK_GATE 7 >> +#define SUN8I_ADDA_HP_VOLC_HP_VOL 0 >> +#define SUN8I_ADDA_LOMIXSC 0x01 >> +#define SUN8I_ADDA_LOMIXSC_MIC1 6 >> +#define SUN8I_ADDA_LOMIXSC_MIC2 5 >> +#define SUN8I_ADDA_LOMIXSC_PHONE 4 >> +#define SUN8I_ADDA_LOMIXSC_PHONEN 3 >> +#define SUN8I_ADDA_LOMIXSC_LINEINL 2 >> +#define SUN8I_ADDA_LOMIXSC_DACL 1 >> +#define SUN8I_ADDA_LOMIXSC_DACR 0 >> +#define SUN8I_ADDA_ROMIXSC 0x02 >> +#define SUN8I_ADDA_ROMIXSC_MIC1 6 >> +#define SUN8I_ADDA_ROMIXSC_MIC2 5 >> +#define SUN8I_ADDA_ROMIXSC_PHONE 4 >> +#define SUN8I_ADDA_ROMIXSC_PHONEP 3 >> +#define SUN8I_ADDA_ROMIXSC_LINEINR 2 >> +#define SUN8I_ADDA_ROMIXSC_DACR 1 >> +#define SUN8I_ADDA_ROMIXSC_DACL 0 >> +#define SUN8I_ADDA_DAC_PA_SRC 0x03 >> +#define SUN8I_ADDA_DAC_PA_SRC_DACAREN 7 >> +#define SUN8I_ADDA_DAC_PA_SRC_DACALEN 6 >> +#define SUN8I_ADDA_DAC_PA_SRC_RMIXEN 5 >> +#define SUN8I_ADDA_DAC_PA_SRC_LMIXEN 4 >> +#define SUN8I_ADDA_DAC_PA_SRC_RHPPAMUTE 3 >> +#define SUN8I_ADDA_DAC_PA_SRC_LHPPAMUTE 2 >> +#define SUN8I_ADDA_DAC_PA_SRC_RHPIS 1 >> +#define SUN8I_ADDA_DAC_PA_SRC_LHPIS 0 >> +#define SUN8I_ADDA_PHONEIN_GCTRL 0x04 >> +#define SUN8I_A
Re: module: extend 'rodata=off' boot cmdline parameter to module mappings
+++ AKASHI Takahiro [14/11/16 15:15 +0900]:
The current "rodata=off" parameter disables read-only kernel mappings
under CONFIG_DEBUG_RODATA:
commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter
to disable read-only kernel mappings")
This patch is a logical extension to module mappings ie. read-only mappings
at module loading can be disabled even if CONFIG_DEBUG_SET_MODULE_RONX
(mainly for debug use). Please note, however, that it only affects RO/RW
permissions, keeping NX set.
This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory
(always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64.
Suggested-by: and Acked-by: Mark Rutland
Signed-off-by: AKASHI Takahiro
Reviewed-by: Kees Cook
Cc: Rusty Russell
Hi Rusty, could I get an (n)ack for this patch? :-)
Thanks!
Jessica
Re: [PATCH] cpuset: Remove unused 'struct cpuset*' variable
On 2016/11/25 12:55, Kirtika Ruchandani wrote:
> 'struct cpuset* cs' that is set but not used, was introduced in commit
> 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from
> subtree_control enabling").
> cpuset_cancel_attach() uses css_cs(css) instead. Compiling with W=1
> gives the folllowing harmless warning, which we'd like to fix to
> reduce the noise with W=1 in the kernel.
>
> kernel/cpuset.c: In function ‘cpuset_cancel_attach’:
> kernel/cpuset.c:1502:17: warning: variable ‘cs’ set but not used
> [-Wunused-but-set-variable]
> struct cpuset *cs;
> ^
>
> Fixes: 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration
> from subtree_control enabling").
This isn't a bug, so I don't think this tag is proper.
> Cc: Tejun Heo
> Signed-off-by: Kirtika Ruchandani
Acked-by: Zefan Li
> ---
> kernel/cpuset.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index 29f815d..af51460 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -1499,10 +1499,8 @@ static int cpuset_can_attach(struct cgroup_taskset
> *tset)
> static void cpuset_cancel_attach(struct cgroup_taskset *tset)
> {
> struct cgroup_subsys_state *css;
> - struct cpuset *cs;
>
> cgroup_taskset_first(tset, &css);
> - cs = css_cs(css);
>
> mutex_lock(&cpuset_mutex);
> css_cs(css)->attach_in_progress--;
>
RE: [patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86
> -Original Message- > From: Vadim Pasternak > Sent: Monday, November 14, 2016 10:10 AM > To: 'Andy Shevchenko' > Cc: Thomas Gleixner ; dvh...@infradead.org; platform- > driver-...@vger.kernel.org; x...@kernel.org; linux-kernel@vger.kernel.org; > j...@resnulli.us; andriy.shevche...@linux.intel.com > Subject: RE: [patch v3 1/1] platform/x86: move module mlx-platform from > arch/x86 to drivers/platform/x86 > > > > > -Original Message- > > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > > Sent: Monday, November 14, 2016 9:17 AM > > To: Vadim Pasternak > > Cc: Thomas Gleixner ; dvh...@infradead.org; > > platform- driver-...@vger.kernel.org; x...@kernel.org; > > linux-kernel@vger.kernel.org; j...@resnulli.us; > > andriy.shevche...@linux.intel.com > > Subject: Re: [patch v3 1/1] platform/x86: move module mlx-platform > > from > > arch/x86 to drivers/platform/x86 > > > > On Tue, Nov 8, 2016 at 8:19 AM, Vadim Pasternak > > wrote: > > > Hi, > > > > > > Could this patch be merged to for-next for 4.10? > > > When it's merged I'd like to submit another small patch on top of it. > > > > Hi Andy, > Thanks for reply. > > > First of all, please avoid top posting. > > Sorry for that. > I posted on top, because it doesn't come as reply to something (but it seems I > should post at bottom in suc case). > > > I will process the pdx86 mailing list and queue this week. I am very sorry for reminding, but I see that it's still not merged. Thanks, Vadim. > > > > P.S. Are you sure that is the right fix "Remove "select MLX_PLATFORM" > > from Kconfig, since it has unmet direct dependencies (X86 && > > X86_PLATFORM_DEVICES && X86_64)"? > > There were two possibility: to leave "select MLX_PLATFORM" and add " depends > on X86_64". Or just remove select. > I decide to remove, having in mind the next considerations: > If MLX_PLATFORM is not selected here - just nobody will activate hotplug > driver; > If in the feature on some systems we'll have ACPI support - hotplug still is > relevant. > > > > > >> On Mon, 31 Oct 2016, Vadim Pasternak wrote: > > >> > > >> > Since mlx-platform is not an architectural driver, it is moved > > >> > out of arch/x86/platform to drivers/platform/x86. > > >> > Relevant Makefile and Kconfig are updated. > > >> > > > >> > Signed-off-by: Vadim Pasternak > > >> > > >> Acked-by: Thomas Gleixner > > > > -- > > With Best Regards, > > Andy Shevchenko
Re: [PATCH net-next] virtio-net: enable multiqueue by default
On 2016年11月25日 12:43, Michael S. Tsirkin wrote: On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote: >We use single queue even if multiqueue is enabled and let admin to >enable it through ethtool later. This is used to avoid possible >regression (small packet TCP stream transmission). But looks like an >overkill since: > >- single queue user can disable multiqueue when launching qemu >- brings extra troubles for the management since it needs extra admin > tool in guest to enable multiqueue >- multiqueue performs much better than single queue in most of the > cases > >So this patch enables multiqueue by default: if #queues is less than or >equal to #vcpu, enable as much as queue pairs; if #queues is greater >than #vcpu, enable #vcpu queue pairs. > >Cc: Hannes Frederic Sowa >Cc: Michael S. Tsirkin >Cc: Neil Horman >Cc: Jeremy Eder >Cc: Marko Myllynen >Cc: Maxime Coquelin >Signed-off-by: Jason Wang OK at some level but all uses of num_online_cpus() like this are racy versus hotplug. I know we already have this bug but shouldn't we fix it before we add more? Not sure I get the point, do you mean adding get/put_online_cpus()? But is it a real bug? We don't do any cpu specific things so I believe it's not necessary (unless we want to keep #queues == #vcpus magically but I don't think so). Admin need to re-configure #queues after cpu hotplug if they wish. Thanks
Re: [PATCH 1/1 linux-next] ext4: add compatibility flag check
On Thu, Nov 24, 2016 at 08:47:41PM +0100, Fabian Frederick wrote: > data=journal mount option should disable O_DIRECT access > (See Documentation/filesystems/ext4.txt) but open operations > using O_CREAT|O_RDWR|O_DIRECT|O_SYNC have no warning in return and file is > being > created. This patch adds vfs super_operations compatibility flag function > returning -EPERM in such a case. > > Signed-off-by: Fabian Frederick The general practice by most file systems in Linux (for better or for worse) is to silently fall back to buffered I/O instead of failing the O_DIRECT open. Feel free to try to convince linux-fsdevel otherwise, but that is the general and historical consensus of Linux file system developers. Cheers, - Ted
Re: [PATCH 1/1] dmaengine: imx-sdma - correct the dma transfer residue calculation
On Tue, Oct 11, 2016 at 02:13:41PM +0300, Nandor Han wrote: > The residue calculation was taking in consideration that dma > transaction status will be always retrieved in the dma callback > used to inform that dma transfer is complete. However this is not > the case for all subsystems that use dma. Some subsystems use a > timer to check the dma status periodically. > > Therefore the calculation was updated and residue is calculated > accordingly by a) update the residue calculation taking in > consideration the last used buffer index by using *buf_ptail* variable > and b) chn_real_count (number of bytes transferred) is initialized to > zero, when dma channel is created, to avoid using an uninitialized > value in residue calculation when dma status is checked without > waiting dma complete event. Looks to be missed earier, so applying now Thanks -- ~Vinod
Re: [PATCH 4/7] ovl: add infrastructure for intercepting file ops
On Thu, Nov 24, 2016 at 4:08 PM, Amir Goldstein wrote:
> On Thu, Nov 24, 2016 at 3:51 PM, Miklos Szeredi wrote:
>> On Thu, Nov 24, 2016 at 2:12 PM, Amir Goldstein wrote:
>>> On Thu, Nov 24, 2016 at 2:03 PM, Miklos Szeredi wrote:
On Thu, Nov 24, 2016 at 12:52 PM, Amir Goldstein
wrote:
> On Thu, Nov 24, 2016 at 12:55 PM, Miklos Szeredi
> wrote:
>> + /*
>> +* These should be intercepted, but they are very
>> unlikely to be
>> +* a problem in practice. Leave them alone for now.
>
> It could also be handled in vfs helpers.
> Since these ops all start with establishing that src and dest are on
> the same sb,
> then the cost of copy up of src is the cost of clone_file_range from
> lower to upper,
> so it is probably worth to copy up src and leave those fops alone.
>
>> +*/
>> + ofop->fops.copy_file_range = orig->copy_file_range;
>> + ofop->fops.clone_file_range = orig->clone_file_range;
>> + ofop->fops.dedupe_file_range = orig->dedupe_file_range;
Not sure I understand. Why should we copy up src? Copy up is the
problem not the solution.
>>>
>>> Maybe the idea is ill conceived, but the reasoning is:
>>> To avoid the corner case of cloning from a stale lower src,
>>> call d_real() in vfs helpers to always copy up src before cloning from it
>>> and pass the correct file onwards.
>>
>> Which correct file? src is still the wrong one after calling d_real.
>> We need to clone-open src, just like we do in ovl_read_iter to get the
>> correct file. But then what's the use of copying it up beforehand?
>>
>> We could move the whole logic into the vfs, but I don't really see the point.
>>
Here is a relevant use case (creating several clones),
although not directly related to ro/rw inconsistency, which
justified putting the logic in vfs.
X is a file in lower
lower is different fs then upper
upper supports clone/dedup/copy_range
for i in `seq 1 100`; do cp --reflink=auto X X${i}; done
With current code the src and destination files are on the same
mount (test in ioctl_file_clone), but not on the same sb (test in
vfs_clone_file_range), so cp will fall back to 100 expensive data copies.
*If* instead we d_real() and clone-open src in start of vfs_clone_file_range
*after* verifying the dest file ops support clone, then we will get only one
expensive copy up and 100 cheap clones, so its a big win.
And for the case of src and dst inodes already on the same sb, we can
skip d_real() to avoid possible unneeded copy up, although a clone up
is going to be cheap anyway.
The so called worst case is that this was a one time clone (to X1),
but the cost in this case is not huge - 1 data copy up of X and 1 clone
X->X1 instead of just 1 data copy X->X1, so the difference is negligible.
Now it's true that this is heuristic, but arguably a good one.
Amir.
[PATCH v7 08/12] iommu/amd: Add sanity check of irq remap information of old dev table entry
Firstly split the dev table entry copy into address translation part and
irq remapping part. Because these two parts could be configured to
be available indepentently.
Secondly check if IntCtl and IntTabLen are 10b and 1000b if they are
set.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 5 -
drivers/iommu/amd_iommu_init.c | 25 ++---
drivers/iommu/amd_iommu_types.h | 8
3 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index fc8ecfb..cea90d5 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3640,11 +3640,6 @@ EXPORT_SYMBOL(amd_iommu_device_info);
static struct irq_chip amd_ir_chip;
-#define DTE_IRQ_PHYS_ADDR_MASK (((1ULL << 45)-1) << 6)
-#define DTE_IRQ_REMAP_INTCTL(2ULL << 60)
-#define DTE_IRQ_TABLE_LEN (8ULL << 1)
-#define DTE_IRQ_REMAP_ENABLE1ULL
-
static void set_dte_irq_entry(u16 devid, struct irq_remap_table *table)
{
u64 dte;
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 4233f26..4427c63 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -837,12 +837,12 @@ static int get_dev_entry_bit(u16 devid, u8 bit)
static int copy_dev_tables(void)
{
+ u64 int_ctl, int_tab_len, entry, last_entry = 0;
struct dev_table_entry *old_devtb = NULL;
u32 lo, hi, devid, old_devtb_size;
phys_addr_t old_devtb_phys;
- u64 entry, last_entry = 0;
struct amd_iommu *iommu;
- u16 dom_id, dte_v;
+ u16 dom_id, dte_v, irq_v;
static int copied;
for_each_iommu(iommu) {
@@ -881,8 +881,27 @@ static int copy_dev_tables(void)
amd_iommu_dev_table[devid] = old_devtb[devid];
dom_id = old_devtb[devid].data[1] & DEV_DOMID_MASK;
dte_v = old_devtb[devid].data[0] & DTE_FLAG_V;
- if (dte_v && dom_id)
+ if (dte_v && dom_id) {
+ amd_iommu_dev_table[devid].data[0]
+ = old_devtb[devid].data[0];
+ amd_iommu_dev_table[devid].data[1]
+ = old_devtb[devid].data[1];
__set_bit(dom_id, amd_iommu_pd_alloc_bitmap);
+ }
+
+ irq_v = old_devtb[devid].data[2] & DTE_IRQ_REMAP_ENABLE;
+ int_ctl = old_devtb[devid].data[2] &
DTE_IRQ_REMAP_INTCTL_MASK;
+ int_tab_len = old_devtb[devid].data[2] &
DTE_IRQ_TABLE_LEN_MASK;
+ if (irq_v && (int_ctl || int_tab_len)) {
+ if ((int_ctl != DTE_IRQ_REMAP_INTCTL) ||
+(int_tab_len != DTE_IRQ_TABLE_LEN)) {
+ pr_err("Wrong old irq remapping flag:
%#x\n", devid);
+ return -1;
+ }
+
+ amd_iommu_dev_table[devid].data[2]
+ = old_devtb[devid].data[2];
+ }
}
memunmap(old_devtb);
copied = 1;
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index 79ec841..b5ae18e 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -250,6 +250,14 @@
#define GA_GUEST_NR0x1
+/* Bit value definition for dte irq remapping fields*/
+#define DTE_IRQ_PHYS_ADDR_MASK (((1ULL << 45)-1) << 6)
+#define DTE_IRQ_REMAP_INTCTL_MASK (0x3ULL << 60)
+#define DTE_IRQ_TABLE_LEN_MASK (0xfULL << 1)
+#define DTE_IRQ_REMAP_INTCTL(2ULL << 60)
+#define DTE_IRQ_TABLE_LEN (8ULL << 1)
+#define DTE_IRQ_REMAP_ENABLE1ULL
+
#define PAGE_MODE_NONE0x00
#define PAGE_MODE_1_LEVEL 0x01
#define PAGE_MODE_2_LEVEL 0x02
--
2.5.5
[PATCH v7 07/12] iommu/amd: Use is_attach_deferred call-back
Implement call-back is_attach_deferred and use it to defer the
domain attach from iommu driver init to device driver init when
iommu is pre-enabled in kdump kernel.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index d5aef72..fc8ecfb 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -138,6 +138,7 @@ struct iommu_dev_data {
PPR completions */
u32 errata; /* Bitmap for errata to apply */
bool use_vapic; /* Enable device to use vapic mode */
+ bool defer_attach;
};
/*
@@ -340,12 +341,17 @@ static u16 get_alias(struct device *dev)
static struct iommu_dev_data *find_dev_data(u16 devid)
{
struct iommu_dev_data *dev_data;
+ struct amd_iommu *iommu = amd_iommu_rlookup_table[devid];
dev_data = search_dev_data(devid);
- if (dev_data == NULL)
+ if (dev_data == NULL) {
dev_data = alloc_dev_data(devid);
+ if (translation_pre_enabled(iommu))
+ dev_data->defer_attach = true;
+ }
+
return dev_data;
}
@@ -2315,11 +2321,18 @@ static void queue_add(struct dma_ops_domain *dma_dom,
static struct protection_domain *get_domain(struct device *dev)
{
struct protection_domain *domain;
+ struct iommu_domain *io_domain;
if (!check_device(dev))
return ERR_PTR(-EINVAL);
domain = get_dev_data(dev)->domain;
+ if (domain == NULL && get_dev_data(dev)->defer_attach) {
+ get_dev_data(dev)->defer_attach = false;
+ io_domain = iommu_get_domain_for_dev(dev);
+ domain = to_pdomain(io_domain);
+ attach_device(dev, domain);
+ }
if (!dma_ops_domain(domain))
return ERR_PTR(-EBUSY);
@@ -3215,6 +3228,13 @@ static void amd_iommu_apply_dm_region(struct device *dev,
WARN_ON_ONCE(reserve_iova(&dma_dom->iovad, start, end) == NULL);
}
+static bool amd_iommu_is_attach_deferred(struct iommu_domain *domain,
+struct device *dev)
+{
+ struct iommu_dev_data *dev_data = dev->archdata.iommu;
+ return dev_data->defer_attach;
+}
+
static const struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -3231,6 +3251,7 @@ static const struct iommu_ops amd_iommu_ops = {
.get_dm_regions = amd_iommu_get_dm_regions,
.put_dm_regions = amd_iommu_put_dm_regions,
.apply_dm_region = amd_iommu_apply_dm_region,
+ .is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap = AMD_IOMMU_PGSIZES,
};
--
2.5.5
[PATCH v7 03/12] iommu/amd: Define bit fields for DTE particularly
In amd-vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining their respecitve bit fields can make code more read-able. So
do it in this patch.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 8
drivers/iommu/amd_iommu_types.h | 18 ++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 754595e..0b0e50e 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1476,9 +1476,9 @@ static int iommu_map_page(struct protection_domain *dom,
if (count > 1) {
__pte = PAGE_SIZE_PTE(phys_addr, page_size);
- __pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
+ __pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
} else
- __pte = phys_addr | IOMMU_PTE_P | IOMMU_PTE_FC;
+ __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
if (prot & IOMMU_PROT_IR)
__pte |= IOMMU_PTE_IR;
@@ -1805,7 +1805,7 @@ static void set_dte_entry(u16 devid, struct
protection_domain *domain, bool ats)
pte_root |= (domain->mode & DEV_ENTRY_MODE_MASK)
<< DEV_ENTRY_MODE_SHIFT;
- pte_root |= IOMMU_PTE_IR | IOMMU_PTE_IW | IOMMU_PTE_P | IOMMU_PTE_TV;
+ pte_root |= DTE_FLAG_IR | DTE_FLAG_IW | DTE_FLAG_V | DTE_FLAG_TV;
flags = amd_iommu_dev_table[devid].data[1];
@@ -1848,7 +1848,7 @@ static void set_dte_entry(u16 devid, struct
protection_domain *domain, bool ats)
static void clear_dte_entry(u16 devid)
{
/* remove entry from the device table seen by the hardware */
- amd_iommu_dev_table[devid].data[0] = IOMMU_PTE_P | IOMMU_PTE_TV;
+ amd_iommu_dev_table[devid].data[0] = DTE_FLAG_V | DTE_FLAG_TV;
amd_iommu_dev_table[devid].data[1] &= DTE_FLAG_MASK;
amd_iommu_apply_erratum_63(devid);
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index 2bbc19d..6a4378f 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -265,7 +265,7 @@
#define PM_LEVEL_INDEX(x, a) (((a) >> PM_LEVEL_SHIFT((x))) & 0x1ffULL)
#define PM_LEVEL_ENC(x)(((x) << 9) & 0xe00ULL)
#define PM_LEVEL_PDE(x, a) ((a) | PM_LEVEL_ENC((x)) | \
-IOMMU_PTE_P | IOMMU_PTE_IR | IOMMU_PTE_IW)
+IOMMU_PTE_PR | IOMMU_PTE_IR | IOMMU_PTE_IW)
#define PM_PTE_LEVEL(pte) (((pte) >> 9) & 0x7ULL)
#define PM_MAP_4k 0
@@ -314,13 +314,23 @@
#define PTE_LEVEL_PAGE_SIZE(level) \
(1ULL << (12 + (9 * (level
-#define IOMMU_PTE_P (1ULL << 0)
-#define IOMMU_PTE_TV (1ULL << 1)
+/*
+ * Bit value definition for I/O PTE fields
+ */
+#define IOMMU_PTE_PR (1ULL << 0)
#define IOMMU_PTE_U (1ULL << 59)
#define IOMMU_PTE_FC (1ULL << 60)
#define IOMMU_PTE_IR (1ULL << 61)
#define IOMMU_PTE_IW (1ULL << 62)
+/*
+ * Bit value definition for DTE fields
+ */
+#define DTE_FLAG_V (1ULL << 0)
+#define DTE_FLAG_TV (1ULL << 1)
+#define DTE_FLAG_IR (1ULL << 61)
+#define DTE_FLAG_IW (1ULL << 62)
+
#define DTE_FLAG_IOTLB (1ULL << 32)
#define DTE_FLAG_GV(1ULL << 55)
#define DTE_FLAG_MASK (0x3ffULL << 32)
@@ -342,7 +352,7 @@
#define GCR3_VALID 0x01ULL
#define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
-#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
+#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
#define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
#define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
--
2.5.5
[PATCH v7 04/12] iommu/amd: Add function copy_dev_tables
Add function copy_dev_tables to copy the old DEV table entries of the panicked
kernel to the new allocated DEV table. Since all iommus share the same DTE table
the copy only need be done once as long as the physical address of old DEV table
is retrieved from iommu reg. Besides, we also need to:
- Check whether all IOMMUs actually use the same device table with the same
size
- Verify that the size of the old device table is the expected size.
- Reserve the old domain id occupied in 1st kernel to avoid touching the old
io-page tables. Then on-flight DMA can continue looking it up.
And define MACRO DEV_DOMID_MASK to replace magic number 0xULL because
it need be reused in copy_dev_tables.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 55 +
drivers/iommu/amd_iommu_types.h | 1 +
3 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 0b0e50e..d5aef72 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1838,7 +1838,7 @@ static void set_dte_entry(u16 devid, struct
protection_domain *domain, bool ats)
flags|= tmp;
}
- flags &= ~(0xUL);
+ flags &= ~DEV_DOMID_MASK;
flags |= domain->id;
amd_iommu_dev_table[devid].data[1] = flags;
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 9458f7c..8fc9840 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -834,6 +834,61 @@ static int get_dev_entry_bit(u16 devid, u8 bit)
}
+static int copy_dev_tables(void)
+{
+ struct dev_table_entry *old_devtb = NULL;
+ u32 lo, hi, devid, old_devtb_size;
+ phys_addr_t old_devtb_phys;
+ u64 entry, last_entry = 0;
+ struct amd_iommu *iommu;
+ u16 dom_id, dte_v;
+ static int copied;
+
+ for_each_iommu(iommu) {
+ if (!translation_pre_enabled(iommu)) {
+ pr_err("IOMMU:%d is not pre-enabled!/n",
+ iommu->index);
+ return -1;
+ }
+
+ /* All IOMMUs should use the same device table with the same
size */
+ lo = readl(iommu->mmio_base + MMIO_DEV_TABLE_OFFSET);
+ hi = readl(iommu->mmio_base + MMIO_DEV_TABLE_OFFSET + 4);
+ entry = (((u64) hi) << 32) + lo;
+ if (last_entry && last_entry != entry) {
+ pr_err("IOMMU:%d should use the same dev table as
others!/n",
+ iommu->index);
+ return -1;
+ }
+ last_entry = entry;
+
+ old_devtb_size = ((entry & ~PAGE_MASK) + 1) << 12;
+ if (old_devtb_size != dev_table_size) {
+ pr_err("The device table size of IOMMU:%d is not
expected!/n",
+ iommu->index);
+ return -1;
+ }
+
+ old_devtb_phys = entry & PAGE_MASK;
+ old_devtb = memremap(old_devtb_phys, dev_table_size,
MEMREMAP_WB);
+ if (!old_devtb)
+ return -1;
+
+ if (copied)
+ continue;
+ for (devid = 0; devid <= amd_iommu_last_bdf; ++devid) {
+ amd_iommu_dev_table[devid] = old_devtb[devid];
+ dom_id = old_devtb[devid].data[1] & DEV_DOMID_MASK;
+ dte_v = old_devtb[devid].data[0] & DTE_FLAG_V;
+ if (dte_v && dom_id)
+ __set_bit(dom_id, amd_iommu_pd_alloc_bitmap);
+ }
+ memunmap(old_devtb);
+ copied = 1;
+ }
+ return 0;
+}
+
void amd_iommu_apply_erratum_63(u16 devid)
{
int sysmgt;
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index 6a4378f..79ec841 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -336,6 +336,7 @@
#define DTE_FLAG_MASK (0x3ffULL << 32)
#define DTE_GLX_SHIFT (56)
#define DTE_GLX_MASK (3)
+#define DEV_DOMID_MASK 0xULL
#define DTE_GCR3_VAL_A(x) (((x) >> 12) & 0x7ULL)
#define DTE_GCR3_VAL_B(x) (((x) >> 15) & 0x0ULL)
--
2.5.5
[PATCH v7 01/12] iommu/amd: Detect pre enabled translation
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 25 +
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 4
3 files changed, 30 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 157e934..5ad1e023 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -251,6 +251,26 @@ static int amd_iommu_enable_interrupts(void);
static int __init iommu_go_to_state(enum iommu_init_state state);
static void init_device_table_dma(void);
+
+bool translation_pre_enabled(struct amd_iommu *iommu)
+{
+ return (iommu->flags & AMD_IOMMU_FLAG_TRANS_PRE_ENABLED);
+}
+
+static void clear_translation_pre_enabled(struct amd_iommu *iommu)
+{
+ iommu->flags &= ~AMD_IOMMU_FLAG_TRANS_PRE_ENABLED;
+}
+
+static void init_translation_status(struct amd_iommu *iommu)
+{
+ u32 ctrl;
+
+ ctrl = readl(iommu->mmio_base + MMIO_CONTROL_OFFSET);
+ if (ctrl & (1int_enabled = false;
+ init_translation_status(iommu);
+
+ if (translation_pre_enabled(iommu))
+ pr_warn("Translation is already enabled - trying to copy
translation structures\n");
+
ret = init_iommu_from_acpi(iommu, h);
if (ret)
return ret;
diff --git a/drivers/iommu/amd_iommu_proto.h b/drivers/iommu/amd_iommu_proto.h
index 7eb60c1..9560183 100644
--- a/drivers/iommu/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@ -93,4 +93,5 @@ static inline bool iommu_feature(struct amd_iommu *iommu, u64
f)
return !!(iommu->features & f);
}
+extern bool translation_pre_enabled(struct amd_iommu *iommu);
#endif /* _ASM_X86_AMD_IOMMU_PROTO_H */
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index 0d91785..2bbc19d 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -416,6 +416,7 @@ extern struct kmem_cache *amd_iommu_irq_cache;
#define APERTURE_PAGE_INDEX(a) (((a) >> 21) & 0x3fULL)
+
/*
* This struct is used to pass information about
* incoming PPR faults around.
@@ -434,6 +435,8 @@ struct iommu_domain;
struct irq_domain;
struct amd_irte_ops;
+#define AMD_IOMMU_FLAG_TRANS_PRE_ENABLED (1 << 0)
+
/*
* This structure contains generic data for IOMMU protection domains
* independent of their use.
@@ -566,6 +569,7 @@ struct amd_iommu {
struct amd_irte_ops *irte_ops;
#endif
+ u32 flags;
volatile u64 __aligned(8) cmd_sem;
};
--
2.5.5
[PATCH v7 11/12] iommu: Assign the direct mapped domain to group->domain
In iommu_request_dm_for_dev(), devices of group have all been attached
to newly created direct mapped domain. We should store the domain into
group->domain so that it works for iommu_get_domain_for_dev() and
get_domain().
Signed-off-by: Baoquan He
---
drivers/iommu/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0262eee..a2d1a8f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1612,6 +1612,7 @@ int iommu_request_dm_for_dev(struct device *dev)
if (group->default_domain)
iommu_domain_free(group->default_domain);
group->default_domain = dm_domain;
+ group->domain = dm_domain;
pr_info("Using direct mapping for device %s\n", dev_name(dev));
--
2.5.5
[PATCH v7 09/12] iommu/amd: Don't copy GCR3 table root pointer
When in kdump kernel iommu is pre_enabled, if a device is set up with
guest translations (DTE.GV=1), then don't copy GCR3 table root pointer
but move the device over to an empty guest-cr3 table and handle the
faults in the PPR log (which answer them with INVALID). After all these
PPR faults are recoverable for the device and we should not allow the
device to change old-kernels data when we don't have to.
Signed-off-by: Baoquan He
Suggested-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 26 +++---
drivers/iommu/amd_iommu_init.c | 11 +++
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 22 ++
drivers/iommu/amd_iommu_v2.c| 18 +-
5 files changed, 54 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index cea90d5..22520f6 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -120,28 +120,6 @@ int amd_iommu_max_glx_val = -1;
static struct dma_map_ops amd_iommu_dma_ops;
/*
- * This struct contains device specific data for the IOMMU
- */
-struct iommu_dev_data {
- struct list_head list;/* For domain->dev_list */
- struct list_head dev_data_list; /* For global dev_data_list */
- struct protection_domain *domain; /* Domain the device is bound to */
- u16 devid;/* PCI Device ID */
- u16 alias;/* Alias Device ID */
- bool iommu_v2;/* Device can make use of IOMMUv2 */
- bool passthrough; /* Device is identity mapped */
- struct {
- bool enabled;
- int qdep;
- } ats;/* ATS state */
- bool pri_tlp; /* PASID TLB required for
-PPR completions */
- u32 errata; /* Bitmap for errata to apply */
- bool use_vapic; /* Enable device to use vapic mode */
- bool defer_attach;
-};
-
-/*
* general struct to manage commands send to an IOMMU
*/
struct iommu_cmd {
@@ -355,10 +333,11 @@ static struct iommu_dev_data *find_dev_data(u16 devid)
return dev_data;
}
-static struct iommu_dev_data *get_dev_data(struct device *dev)
+struct iommu_dev_data *get_dev_data(struct device *dev)
{
return dev->archdata.iommu;
}
+EXPORT_SYMBOL(get_dev_data);
/*
* Find or create an IOMMU group for a acpihid device.
@@ -2378,6 +2357,7 @@ static int dir2prot(enum dma_data_direction direction)
else
return 0;
}
+
/*
* This function contains common code for mapping of a physically
* contiguous memory region into DMA address space. It is used by all
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 4427c63..d362b63 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -204,6 +204,7 @@ u16 *amd_iommu_alias_table;
* for a specific device. It is also indexed by the PCI device id.
*/
struct amd_iommu **amd_iommu_rlookup_table;
+EXPORT_SYMBOL(amd_iommu_rlookup_table);
/*
* This table is used to find the irq remapping table for a given device id
@@ -257,6 +258,7 @@ bool translation_pre_enabled(struct amd_iommu *iommu)
{
return (iommu->flags & AMD_IOMMU_FLAG_TRANS_PRE_ENABLED);
}
+EXPORT_SYMBOL(translation_pre_enabled);
static void clear_translation_pre_enabled(struct amd_iommu *iommu)
{
@@ -844,6 +846,7 @@ static int copy_dev_tables(void)
struct amd_iommu *iommu;
u16 dom_id, dte_v, irq_v;
static int copied;
+ u64 tmp;
for_each_iommu(iommu) {
if (!translation_pre_enabled(iommu)) {
@@ -887,6 +890,14 @@ static int copy_dev_tables(void)
amd_iommu_dev_table[devid].data[1]
= old_devtb[devid].data[1];
__set_bit(dom_id, amd_iommu_pd_alloc_bitmap);
+ /* If gcr3 table existed, mask it out */
+ if (old_devtb[devid].data[0] & DTE_FLAG_GV) {
+ tmp = DTE_GCR3_VAL_B(~0ULL) <<
DTE_GCR3_SHIFT_B;
+ tmp |= DTE_GCR3_VAL_C(~0ULL) <<
DTE_GCR3_SHIFT_C;
+ amd_iommu_dev_table[devid].data[1] &=
~tmp;
+ tmp = DTE_GCR3_VAL_A(~0ULL) <<
DTE_GCR3_SHIFT_A;
+ amd_iommu_dev_table[devid].data[0] &=
~tmp;
+ }
}
irq_v = old_devtb[devid].data[2] & DTE_IRQ_REMAP_ENABLE;
diff --git a/drivers/iommu/amd_iommu_proto.h b/drivers/iommu/amd_iommu_proto.h
index 9560183..d6a2c36 100644
--- a/drivers/iommu/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@ -94,4 +94,5 @@ st
[PATCH v7 05/12] iommu/amd: copy old trans table from old kernel
Here several things need be done:
- If iommu is pre-enabled in a normal kernel, just disable it and print
warning.
- If failed to copy dev table of old kernel, continue to proceed as
it does in normal kernel.
- Disable and Re-enable event/cmd buffer, install the copied DTE table
to reg, and detect and enable guest vapic.
- Flush all caches
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 51 --
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 8fc9840..4233f26 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include "amd_iommu_proto.h"
#include "amd_iommu_types.h"
#include "irq_remapping.h"
@@ -1481,9 +1482,12 @@ static int __init init_iommu_one(struct amd_iommu
*iommu, struct ivhd_header *h)
iommu->int_enabled = false;
init_translation_status(iommu);
-
- if (translation_pre_enabled(iommu))
- pr_warn("Translation is already enabled - trying to copy
translation structures\n");
+ if (translation_pre_enabled(iommu) && !is_kdump_kernel()) {
+ iommu_disable(iommu);
+ clear_translation_pre_enabled(iommu);
+ pr_warn("Translation was enabled for IOMMU:%d but we are not in
kdump mode\n",
+ iommu->index);
+ }
ret = init_iommu_from_acpi(iommu, h);
if (ret)
@@ -1975,8 +1979,7 @@ static int __init init_memory_definitions(struct
acpi_table_header *table)
}
/*
- * Init the device table to not allow DMA access for devices and
- * suppress all page faults
+ * Init the device table to not allow DMA access for devices
*/
static void init_device_table_dma(void)
{
@@ -2117,9 +2120,43 @@ static void early_enable_iommu(struct amd_iommu *iommu)
static void early_enable_iommus(void)
{
struct amd_iommu *iommu;
+ bool is_pre_enabled = false;
- for_each_iommu(iommu)
- early_enable_iommu(iommu);
+ for_each_iommu(iommu) {
+ if (translation_pre_enabled(iommu)) {
+ is_pre_enabled = true;
+ break;
+ }
+ }
+
+ if (!is_pre_enabled) {
+ for_each_iommu(iommu)
+ early_enable_iommu(iommu);
+ } else {
+ pr_warn("Translation is already enabled - trying to copy
translation structures\n");
+ if (copy_dev_tables()) {
+ pr_err("Failed to copy DEV table from previous
kernel.\n");
+ /*
+* If failed to copy dev tables from old kernel,
continue to proceed
+* as it does in normal kernel.
+*/
+ for_each_iommu(iommu) {
+ clear_translation_pre_enabled(iommu);
+ early_enable_iommu(iommu);
+ }
+ } else {
+ pr_info("Copied DEV table from previous kernel.\n");
+ for_each_iommu(iommu) {
+ iommu_disable_command_buffer(iommu);
+ iommu_disable_event_buffer(iommu);
+ iommu_enable_command_buffer(iommu);
+ iommu_enable_event_buffer(iommu);
+ iommu_enable_ga(iommu);
+ iommu_set_device_table(iommu);
+ iommu_flush_all_caches(iommu);
+ }
+ }
+ }
#ifdef CONFIG_IRQ_REMAP
if (AMD_IOMMU_GUEST_IR_VAPIC(amd_iommu_guest_ir))
--
2.5.5
[PATCH v7 12/12] iommu/amd: Allocate memory below 4G for dev table if translation pre-enabled
AMD pointed out it's unsafe to update the device-table while iommu
is enabled. It turns out that device-table pointer update is split
up into two 32bit writes in the IOMMU hardware. So updating it while
the IOMMU is enabled could have some nasty side effects.
The only way to work around this is to allocate the device-table below
4GB if translation is pre-enabled in kdump kernel. If allocation failed,
still use the old one.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index d362b63..f17f297 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2149,11 +2149,23 @@ static void early_enable_iommu(struct amd_iommu *iommu)
*/
static void early_enable_iommus(void)
{
+ struct dev_table_entry *dev_tbl;
struct amd_iommu *iommu;
bool is_pre_enabled = false;
for_each_iommu(iommu) {
if (translation_pre_enabled(iommu)) {
+ gfp_t gfp_flag = GFP_KERNEL | __GFP_ZERO | GFP_DMA32;;
+
+ dev_tbl = (void *)__get_free_pages(gfp_flag,
+ get_order(dev_table_size));
+ if (dev_tbl != NULL) {
+ memcpy(dev_tbl, amd_iommu_dev_table,
dev_table_size);
+ free_pages((unsigned long)amd_iommu_dev_table,
+ get_order(dev_table_size));
+ amd_iommu_dev_table = dev_tbl;
+ }
+
is_pre_enabled = true;
break;
}
--
2.5.5
[PATCH v7 00/12] Fix kdump faults on system with amd iommu
This is v7 post. The principle of the fix is similar to intel iommu. Just defer the assignment of device to domain to device driver init. In this version of post, a new call-back is_attach_deferred is added to iommu-ops, it's used to check whether we need defer the domain attach/detach in iommu-core code. v5: bnx2 NIC can't reset itself during driver init. Post patch to reset it during driver init. IO_PAGE_FAULT can't be seen anymore. Below is link of v5 post. https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html v5->v6: According to Joerg's comments made several below main changes: - Add sanity check when copy old dev tables. - If a device is set up with guest translations (DTE.GV=1), then don't copy that information but move the device over to an empty guest-cr3 table and handle the faults in the PPR log (which just answer them with INVALID). v6->v7: Two main changes are made according to Joerg's suggestion: - Add is_attach_deferred call-back to iommu-ops. With this domain can be deferred to device driver init cleanly. - Allocate memory below 4G for dev table if translation pre-enabled. AMD engineer pointed out that it's unsafe to update the device-table while iommu is enabled. device-table pointer update is split up into two 32bit writes in the IOMMU hardware. So updating it while the IOMMU is enabled could have some nasty side effects. Baoquan He (12): iommu/amd: Detect pre enabled translation iommu/amd: add several helper function iommu/amd: Define bit fields for DTE particularly iommu/amd: Add function copy_dev_tables iommu/amd: copy old trans table from old kernel iommu: Add is_attach_deferred call-back to iommu-ops iommu/amd: Use is_attach_deferred call-back iommu/amd: Add sanity check of irq remap information of old dev table entry iommu/amd: Don't copy GCR3 table root pointer iommu/amd: Clear out the GV flag when handle deferred domain attach iommu: Assign the direct mapped domain to group->domain iommu/amd: Allocate memory below 4G for dev table if translation pre-enabled drivers/iommu/amd_iommu.c | 78 +--- drivers/iommu/amd_iommu_init.c | 201 +--- drivers/iommu/amd_iommu_proto.h | 2 + drivers/iommu/amd_iommu_types.h | 53 ++- drivers/iommu/amd_iommu_v2.c| 18 +++- drivers/iommu/iommu.c | 9 ++ include/linux/iommu.h | 1 + 7 files changed, 313 insertions(+), 49 deletions(-) -- 2.5.5
[PATCH v7 10/12] iommu/amd: Clear out the GV flag when handle deferred domain attach
When handle deferred domain attach, we need check if the domain is
v2. If not, should try to clear out the GV flag which could be
copied from the old device table entry.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 22520f6..3a8e4ae 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1839,6 +1839,11 @@ static void clear_dte_entry(u16 devid)
amd_iommu_apply_erratum_63(devid);
}
+static void clear_dte_flag_gv(u16 devid)
+{
+ amd_iommu_dev_table[devid].data[0] &= (~DTE_FLAG_GV);
+}
+
static void do_attach(struct iommu_dev_data *dev_data,
struct protection_domain *domain)
{
@@ -2299,6 +2304,7 @@ static void queue_add(struct dma_ops_domain *dma_dom,
*/
static struct protection_domain *get_domain(struct device *dev)
{
+ struct iommu_dev_data *dev_data = get_dev_data(dev);
struct protection_domain *domain;
struct iommu_domain *io_domain;
@@ -2306,11 +2312,21 @@ static struct protection_domain *get_domain(struct
device *dev)
return ERR_PTR(-EINVAL);
domain = get_dev_data(dev)->domain;
- if (domain == NULL && get_dev_data(dev)->defer_attach) {
+ if (domain == NULL && dev_data->defer_attach) {
+ u16 alias = amd_iommu_alias_table[dev_data->devid];
get_dev_data(dev)->defer_attach = false;
io_domain = iommu_get_domain_for_dev(dev);
domain = to_pdomain(io_domain);
attach_device(dev, domain);
+ /*
+* If the deferred attached domain is not v2, should clear out
+* the old GV flag.
+*/
+ if (!(domain->flags & PD_IOMMUV2_MASK)) {
+ clear_dte_flag_gv(dev_data->devid);
+ if (alias != dev_data->devid)
+ clear_dte_flag_gv(dev_data->devid);
+ }
}
if (!dma_ops_domain(domain))
return ERR_PTR(-EBUSY);
--
2.5.5
[PATCH v7 06/12] iommu: Add is_attach_deferred call-back to iommu-ops
This new call-back will be used to check if the domain attach need be
deferred for now. If yes, the domain attach/detach will return directly.
Signed-off-by: Baoquan He
---
drivers/iommu/iommu.c | 8
include/linux/iommu.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 9a2f196..0262eee 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1083,6 +1083,10 @@ static int __iommu_attach_device(struct iommu_domain
*domain,
struct device *dev)
{
int ret;
+ if ((domain->ops->is_attach_deferred != NULL) &&
+ domain->ops->is_attach_deferred(domain, dev))
+ return 0;
+
if (unlikely(domain->ops->attach_dev == NULL))
return -ENODEV;
@@ -1124,6 +1128,10 @@ EXPORT_SYMBOL_GPL(iommu_attach_device);
static void __iommu_detach_device(struct iommu_domain *domain,
struct device *dev)
{
+ if ((domain->ops->is_attach_deferred != NULL) &&
+ domain->ops->is_attach_deferred(domain, dev))
+ return;
+
if (unlikely(domain->ops->detach_dev == NULL))
return;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 436dc21..e179313 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -200,6 +200,7 @@ struct iommu_ops {
u32 (*domain_get_windows)(struct iommu_domain *domain);
int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
+ bool (*is_attach_deferred)(struct iommu_domain *domain, struct device
*dev);
unsigned long pgsize_bitmap;
};
--
2.5.5
[PATCH v7 02/12] iommu/amd: add several helper function
Move per iommu enabling code into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 5ad1e023..9458f7c 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -625,6 +625,14 @@ static void iommu_enable_command_buffer(struct amd_iommu
*iommu)
amd_iommu_reset_cmd_buffer(iommu);
}
+/*
+ * This function disables the command buffer
+ */
+static void iommu_disable_command_buffer(struct amd_iommu *iommu)
+{
+ iommu_feature_disable(iommu, CONTROL_CMDBUF_EN);
+}
+
static void __init free_command_buffer(struct amd_iommu *iommu)
{
free_pages((unsigned long)iommu->cmd_buf, get_order(CMD_BUFFER_SIZE));
@@ -657,6 +665,14 @@ static void iommu_enable_event_buffer(struct amd_iommu
*iommu)
iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
}
+/*
+ * This function disables the command buffer
+ */
+static void iommu_disable_event_buffer(struct amd_iommu *iommu)
+{
+ iommu_feature_disable(iommu, CONTROL_EVT_LOG_EN);
+}
+
static void __init free_event_buffer(struct amd_iommu *iommu)
{
free_pages((unsigned long)iommu->evt_buf, get_order(EVT_BUFFER_SIZE));
@@ -2026,6 +2042,19 @@ static void iommu_enable_ga(struct amd_iommu *iommu)
#endif
}
+static void early_enable_iommu(struct amd_iommu *iommu)
+{
+ iommu_disable(iommu);
+ iommu_init_flags(iommu);
+ iommu_set_device_table(iommu);
+ iommu_enable_command_buffer(iommu);
+ iommu_enable_event_buffer(iommu);
+ iommu_set_exclusion_range(iommu);
+ iommu_enable_ga(iommu);
+ iommu_enable(iommu);
+ iommu_flush_all_caches(iommu);
+}
+
/*
* This function finally enables all IOMMUs found in the system after
* they have been initialized
@@ -2034,17 +2063,8 @@ static void early_enable_iommus(void)
{
struct amd_iommu *iommu;
- for_each_iommu(iommu) {
- iommu_disable(iommu);
- iommu_init_flags(iommu);
- iommu_set_device_table(iommu);
- iommu_enable_command_buffer(iommu);
- iommu_enable_event_buffer(iommu);
- iommu_set_exclusion_range(iommu);
- iommu_enable_ga(iommu);
- iommu_enable(iommu);
- iommu_flush_all_caches(iommu);
- }
+ for_each_iommu(iommu)
+ early_enable_iommu(iommu);
#ifdef CONFIG_IRQ_REMAP
if (AMD_IOMMU_GUEST_IR_VAPIC(amd_iommu_guest_ir))
--
2.5.5
[PATCH] Media: platform: vsp1: - Do not forget to call
v4l2_fh_init is already done.So call the v4l2_fh_exit in error condition
before returing from the function.
Signed-off-by: Shailendra Verma
---
drivers/media/platform/vsp1/vsp1_video.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index d351b9c..cc58163 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -1044,6 +1044,7 @@ static int vsp1_video_open(struct file *file)
ret = vsp1_device_get(video->vsp1);
if (ret < 0) {
v4l2_fh_del(vfh);
+ v4l2_fh_exit(vfh);
kfree(vfh);
}
--
1.7.9.5
[PATCH] Staging: media: davinci_vpfe: - Fix for memory leak if decoder initialization fails.
Fix to avoid possible memory leak if the decoder initialization
got failed.Free the allocated memory for file handle object
before return in case decoder initialization fails.
Signed-off-by: Shailendra Verma
---
drivers/staging/media/davinci_vpfe/vpfe_video.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 8be9f85..4215445 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -423,6 +423,9 @@ static int vpfe_open(struct file *file)
/* If decoder is not initialized. initialize it */
if (!video->initialized && vpfe_update_pipe_state(video)) {
mutex_unlock(&video->lock);
+ v4l2_fh_del(&handle->vfh);
+ v4l2_fh_exit(&handle->vfh);
+ kfree(handle);
return -ENODEV;
}
/* Increment device users counter */
--
1.7.9.5
Re: [PATCH v2 0/3] increase TSCADC clock to 24MHz and fix ti,charge-delay to represent in nS
Hi Dmitry Torokhov, On Thursday 10 November 2016 10:05 PM, Mugunthan V N wrote: > This patch series enables ADC to be clocked at 24MHz as the > TI AM335x ADC driver has already adopted to use DMA to transfer > ADC samples. Now ADC can generated upto 800K Samples per second > with the patch [1] on AM335x BBB and AM437x GP EVM. > > when ADC ref clock is set at 24MHz, I am seeing some issue with > touch screen pointer as the pointer jumps to random locations > with free draw application. The issue is due to increase in ADC > clock and charge delay for the touchscreen ADC line duration > reduced. > > So the notation of ti,charge-delay in terms of ADC clock is > wrong, it has to be represented in time and driver has to convert > the charge delay time to ADC clocks based on what ADC clock > frequency is set. > > Measured the performance with the iio_generic_buffer with the > patch [2] applied > > Verified the touch screen on AM335x GP EVM and AM335x BBB LCD7 > cape with [3] dts for display and touch screen to work. > Since there are acks from DT and MFD maintainers, can you pull the patch series if you do not have any more comments. Regards Mugunthan V N
[PATCH] Media: Platform: Exynos-gsc: - Fix for error handling
The File handle is not yet added in the vfd list.So no need to call v4l2_fh_del(&ctx->fh) if it fails to create control. Signed-off-by: Shailendra Verma --- drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c index 9f03b79..5ea97c1 100644 --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c @@ -664,8 +664,8 @@ static int gsc_m2m_open(struct file *file) error_ctrls: gsc_ctrls_delete(ctx); -error_fh: v4l2_fh_del(&ctx->fh); +error_fh: v4l2_fh_exit(&ctx->fh); kfree(ctx); unlock: -- 1.7.9.5
[PATCH] cpuset: Remove unused 'struct cpuset*' variable
'struct cpuset* cs' that is set but not used, was introduced in commit
1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from
subtree_control enabling").
cpuset_cancel_attach() uses css_cs(css) instead. Compiling with W=1
gives the folllowing harmless warning, which we'd like to fix to
reduce the noise with W=1 in the kernel.
kernel/cpuset.c: In function ‘cpuset_cancel_attach’:
kernel/cpuset.c:1502:17: warning: variable ‘cs’ set but not used
[-Wunused-but-set-variable]
struct cpuset *cs;
^
Fixes: 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from
subtree_control enabling").
Cc: Tejun Heo
Signed-off-by: Kirtika Ruchandani
---
kernel/cpuset.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 29f815d..af51460 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1499,10 +1499,8 @@ static int cpuset_can_attach(struct cgroup_taskset *tset)
static void cpuset_cancel_attach(struct cgroup_taskset *tset)
{
struct cgroup_subsys_state *css;
- struct cpuset *cs;
cgroup_taskset_first(tset, &css);
- cs = css_cs(css);
mutex_lock(&cpuset_mutex);
css_cs(css)->attach_in_progress--;
--
2.8.0.rc3.226.g39d4020
[PATCH] Staging: media: platform: davinci: - Fix for memory leak
Fix to avoid possible memory leak if the decoder initialization got failed.
Free the allocated memory for file handle object before return in case
decoder initialization fails.
Signed-off-by: Shailendra Verma
---
drivers/media/platform/davinci/vpfe_capture.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index 6efb2f1..188b333 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -526,6 +526,8 @@ static int vpfe_open(struct file *file)
if (!vpfe_dev->initialized) {
if (vpfe_initialize_device(vpfe_dev)) {
mutex_unlock(&vpfe_dev->lock);
+ v4l2_fh_exit(&fh->fh);
+ kfree(fh);
return -ENODEV;
}
}
--
1.7.9.5
[PATCH] Staging: Media: Omap4iss: Do not forget to call
v4l2_fh_init is already done.So call the v4l2_fh_exit in error condition
before returing from the function.
Signed-off-by: Shailendra Verma
---
drivers/staging/media/omap4iss/iss_video.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/media/omap4iss/iss_video.c
b/drivers/staging/media/omap4iss/iss_video.c
index c16927a..c46d14d 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -1141,6 +1141,7 @@ static int iss_video_open(struct file *file)
done:
if (ret < 0) {
v4l2_fh_del(&handle->vfh);
+ v4l2_fh_exit(&handle->vfh);
kfree(handle);
}
--
1.7.9.5
[PATCH] Media: Platform: Sti: Bdisp: - Fix for error handling
The File handle is not yet added in the vdev list.So no need to call v4l2_fh_del(&ctx->fh)if it fails to create control. Signed-off-by: Shailendra Verma --- drivers/media/platform/sti/bdisp/bdisp-v4l2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c index 45f82b5..fbf302f 100644 --- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c +++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c @@ -632,8 +632,8 @@ static int bdisp_open(struct file *file) error_ctrls: bdisp_ctrls_delete(ctx); -error_fh: v4l2_fh_del(&ctx->fh); +error_fh: v4l2_fh_exit(&ctx->fh); bdisp_hw_free_nodes(ctx); mem_ctx: -- 1.7.9.5
Re: Tearing down DMA transfer setup after DMA client has finished
On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote: > Hello, > > On my platform, setting up a DMA transfer is a two-step process: > > 1) configure the "switch box" to connect a device to a memory channel > 2) configure the transfer details (address, size, command) > > When the transfer is done, the sbox setup can be torn down, > and the DMA driver can start another transfer. > > The current software architecture for my NFC (NAND Flash controller) > driver is as follows (for one DMA transfer). > > sg_init_one > dma_map_sg > dmaengine_prep_slave_sg > dmaengine_submit > dma_async_issue_pending > configure_NFC_transfer > wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT > wait_for_NFC_idle > dma_unmap_sg Looking at thread and discussion now, first thinking would be to ensure the transaction is completed properly and then isr fired. You may need to talk to your HW designers to find a way for that. It is quite common that DMA controllers will fire and complete whereas the transaction is still in flight. If that is not doable, then since you claim this is custom part which other vendors wont use (hope we are wrong down the line), then we can have a custom api, foo_sbox_configure(bool enable, ...); This can be invoked from NFC driver when required for configuration and teardown. For very specific cases where people need some specific configuration we do allow custom APIs. Only problem with that would be it wont be a generic solution and you seem to be fine with that. -- ~Vinod
[PATCH] Media: Platform: Omap3isp: Do not forget to call
v4l2_fh_init is already done.So call the v4l2_fh_exit in error condition
before returing from the function.
Signed-off-by: Shailendra Verma
---
drivers/media/platform/omap3isp/ispvideo.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 7354469..2822e2f 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1350,6 +1350,7 @@ static int isp_video_open(struct file *file)
done:
if (ret < 0) {
v4l2_fh_del(&handle->vfh);
+ v4l2_fh_exit(&handle->vfh);
kfree(handle);
}
--
1.7.9.5
Re: [PATCH net-next] virtio-net: enable multiqueue by default
On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote:
> We use single queue even if multiqueue is enabled and let admin to
> enable it through ethtool later. This is used to avoid possible
> regression (small packet TCP stream transmission). But looks like an
> overkill since:
>
> - single queue user can disable multiqueue when launching qemu
> - brings extra troubles for the management since it needs extra admin
> tool in guest to enable multiqueue
> - multiqueue performs much better than single queue in most of the
> cases
>
> So this patch enables multiqueue by default: if #queues is less than or
> equal to #vcpu, enable as much as queue pairs; if #queues is greater
> than #vcpu, enable #vcpu queue pairs.
>
> Cc: Hannes Frederic Sowa
> Cc: Michael S. Tsirkin
> Cc: Neil Horman
> Cc: Jeremy Eder
> Cc: Marko Myllynen
> Cc: Maxime Coquelin
> Signed-off-by: Jason Wang
OK at some level but all uses of num_online_cpus()
like this are racy versus hotplug.
I know we already have this bug but shouldn't we fix it
before we add more?
> ---
> drivers/net/virtio_net.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index d4ac7a6..a21d93a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1886,8 +1886,11 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (vi->any_header_sg)
> dev->needed_headroom = vi->hdr_len;
>
> - /* Use single tx/rx queue pair as default */
> - vi->curr_queue_pairs = 1;
> + /* Enable multiqueue by default */
> + if (num_online_cpus() >= max_queue_pairs)
> + vi->curr_queue_pairs = max_queue_pairs;
> + else
> + vi->curr_queue_pairs = num_online_cpus();
> vi->max_queue_pairs = max_queue_pairs;
>
> /* Allocate/initialize the rx/tx queues, and invoke find_vqs */
> @@ -1918,6 +1921,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> goto free_unregister_netdev;
> }
>
> + virtnet_set_affinity(vi);
> +
> /* Assume link up if device can't report link status,
> otherwise get link status from config. */
> if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> --
> 2.7.4
[PATCH] Media: Platform: Exynos4-is: - Fix for error handling
The File handle is not yet added in the vfd list.So no need to call v4l2_fh_del(&ctx->fh) if it fails to create control. Signed-off-by: Shailendra Verma --- drivers/media/platform/exynos4-is/fimc-m2m.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c index 6028e4f..d8724fe 100644 --- a/drivers/media/platform/exynos4-is/fimc-m2m.c +++ b/drivers/media/platform/exynos4-is/fimc-m2m.c @@ -663,8 +663,8 @@ static int fimc_m2m_open(struct file *file) v4l2_m2m_ctx_release(ctx->fh.m2m_ctx); error_c: fimc_ctrls_delete(ctx); -error_fh: v4l2_fh_del(&ctx->fh); +error_fh: v4l2_fh_exit(&ctx->fh); kfree(ctx); unlock: -- 1.7.9.5
[git pull] drm fixes for v4.9-rc7
Hi Linus, Seems to be quietening down nicely, a few mediatek, one exynos and one hdlcd fix, along with 2 amd fixes. Dave. The following changes since commit 9c763584b7c8911106bb77af7e648bef09af9d80: Linux 4.9-rc6 (2016-11-20 13:52:19 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.9-rc7 for you to fetch changes up to 9704668e4b7105ede483f38da7f29d71b5bc0165: Merge branch 'mediatek-drm-fixes-2016-11-24' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes (2016-11-25 14:21:26 +1000) amd, mediatek, exynos and hdlcd fixes. Arvind Yadav (1): gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap Bibby Hsieh (1): drm/mediatek: fix a typo of DISP_OD_CFG to OD_RELAYMODE Dave Airlie (3): Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld into drm-fixes Merge branch 'mediatek-drm-fixes-2016-11-24' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Jitao Shi (1): drm/mediatek: fixed the calc method of data rate per lane Matthias Brugger (1): drm/mediatek: fix null pointer dereference Peter Wu (2): drm/amdgpu: fix power state when port pm is unavailable drm/radeon: fix power state when port pm is unavailable (v2) Rex Zhu (1): drm/amd/powerplay: avoid out of bounds access on array ps. Russell King (1): drm/arm: hdlcd: fix plane base address update drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 9 +++- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 12 ++--- drivers/gpu/drm/arm/hdlcd_crtc.c | 5 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 14 +++--- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 64 ++-- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 9 +++- 8 files changed, 85 insertions(+), 35 deletions(-)
[PATCH net-next] virtio-net: enable multiqueue by default
We use single queue even if multiqueue is enabled and let admin to
enable it through ethtool later. This is used to avoid possible
regression (small packet TCP stream transmission). But looks like an
overkill since:
- single queue user can disable multiqueue when launching qemu
- brings extra troubles for the management since it needs extra admin
tool in guest to enable multiqueue
- multiqueue performs much better than single queue in most of the
cases
So this patch enables multiqueue by default: if #queues is less than or
equal to #vcpu, enable as much as queue pairs; if #queues is greater
than #vcpu, enable #vcpu queue pairs.
Cc: Hannes Frederic Sowa
Cc: Michael S. Tsirkin
Cc: Neil Horman
Cc: Jeremy Eder
Cc: Marko Myllynen
Cc: Maxime Coquelin
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d4ac7a6..a21d93a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1886,8 +1886,11 @@ static int virtnet_probe(struct virtio_device *vdev)
if (vi->any_header_sg)
dev->needed_headroom = vi->hdr_len;
- /* Use single tx/rx queue pair as default */
- vi->curr_queue_pairs = 1;
+ /* Enable multiqueue by default */
+ if (num_online_cpus() >= max_queue_pairs)
+ vi->curr_queue_pairs = max_queue_pairs;
+ else
+ vi->curr_queue_pairs = num_online_cpus();
vi->max_queue_pairs = max_queue_pairs;
/* Allocate/initialize the rx/tx queues, and invoke find_vqs */
@@ -1918,6 +1921,8 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
+ virtnet_set_affinity(vi);
+
/* Assume link up if device can't report link status,
otherwise get link status from config. */
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
--
2.7.4
[PATCH 2/2] dt-bindings: Add DT bindings info for FlexRM mailbox driver
This patch adds device tree bindings document for the FlexRM
mailbox driver.
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Signed-off-by: Anup Patel
---
.../bindings/mailbox/brcm,flexrm-mbox.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
new file mode 100644
index 000..7969b1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
@@ -0,0 +1,60 @@
+Broadcom FlexRM Mailbox Driver
+===
+The Broadcom FlexRM ring manager provides a set of rings which can be
+used to submit work to offload engines. An SoC may have multiple FlexRM
+hardware blocks. There is one device tree entry per block. The FlexRM
+mailbox drivers creates a mailbox instance using FlexRM rings where
+each mailbox channel is a separate FlexRM ring.
+
+Required properties:
+
+- compatible: Should be "brcm,flexrm-mbox"
+- reg: Specifies base physical address and size of the FlexRM
+ ring registers
+- msi-parent: Phandles (and potential Device IDs) to MSI controllers
+ The FlexRM engine will send MSIs (instead of wired
+ interrupts) to CPU. There is one MSI for each FlexRM ring.
+ Refer devicetree/bindings/interrupt-controller/msi.txt
+- #mbox-cells: Specifies the number of cells needed to encode a mailbox
+ channel. This should be 3.
+
+ The 1st cell is the mailbox channel number.
+
+ The 2nd cell contains MSI completion threshold. This is the
+ number of completion messages for which FlexRM will inject
+ one MSI interrupt to CPU.
+
+ The 3nd cell contains MSI timer value representing time for
+ which FlexRM will wait to accumulate N completion messages
+ where N is the value specified by 2nd cell above. If FlexRM
+ does not get required number of completion messages in time
+ specified by this cell then it will inject one MSI interrupt
+ to CPU provided atleast one completion message is available.
+
+Optional properties:
+
+- dma-coherent:Present if DMA operations made by the FlexRM engine
(such
+ as DMA descriptor access, access to buffers pointed by DMA
+ descriptors and read/write pointer updates to DDR) are
+ cache coherent with the CPU.
+
+Example:
+
+crypto_mbox: mbox@6700 {
+ compatible = "brcm,flexrm-mbox";
+ reg = <0x6700 0x20>;
+ msi-parent = <&gic_its 0x7f00>;
+ #mbox-cells = <3>;
+};
+
+crypto_client {
+ ...
+ mboxes = <&crypto_mbox 0 0x1 0x>,
+<&crypto_mbox 1 0x1 0x>,
+<&crypto_mbox 16 0x1 0x>,
+<&crypto_mbox 17 0x1 0x>,
+<&crypto_mbox 30 0x1 0x>,
+<&crypto_mbox 31 0x1 0x>;
+ };
+ ...
+};
--
2.7.4
[PATCH 0/2] Broadcom FlexRM ring manager support
The Broadcom FlexRM ring manager provides producer-consumer style ring interface for offload engines on Broadcom iProc SoCs. We can have one or more instances of Broadcom FlexRM ring manager in a SoC. This patchset adds a mailbox driver for Broadcom FlexRM ring manager which can be used by offload engine drivers as mailbox clients. The Broadcom FlexRM mailbox driver is feature complete for RAID and Crypto offload engines. We will have incremental patches in-future for ring-level statistics using debugfs and minor optimizations. This patchset is based on Linux-4.9-rc6 and it is also available at flexrm-v1 branch of https://github.com/Broadcom/arm64-linux.git Anup Patel (2): mailbox: Add driver for Broadcom FlexRM ring manager dt-bindings: Add DT bindings info for FlexRM mailbox driver .../bindings/mailbox/brcm,flexrm-mbox.txt | 60 ++ drivers/mailbox/Kconfig| 11 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox-flexrm/Makefile| 6 + drivers/mailbox/mailbox-flexrm/flexrm-desc.c | 764 +++ drivers/mailbox/mailbox-flexrm/flexrm-desc.h | 47 ++ drivers/mailbox/mailbox-flexrm/flexrm-main.c | 829 + include/linux/mailbox/brcm-message.h | 12 +- 8 files changed, 1727 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt create mode 100644 drivers/mailbox/mailbox-flexrm/Makefile create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.c create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.h create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-main.c -- 2.7.4
[PATCH 1/2] mailbox: Add driver for Broadcom FlexRM ring manager
Some of the Broadcom iProc SoCs have FlexRM ring manager which provides a ring-based programming interface to various offload engines (e.g. RAID, Crypto, etc). This patch adds a common mailbox driver for Broadcom FlexRM ring manager which can be shared by various offload engine drivers (implemented as mailbox clients). Reviewed-by: Ray Jui Reviewed-by: Scott Branden Reviewed-by: Pramod KUMAR Signed-off-by: Anup Patel --- drivers/mailbox/Kconfig | 11 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox-flexrm/Makefile | 6 + drivers/mailbox/mailbox-flexrm/flexrm-desc.c | 764 drivers/mailbox/mailbox-flexrm/flexrm-desc.h | 47 ++ drivers/mailbox/mailbox-flexrm/flexrm-main.c | 829 +++ include/linux/mailbox/brcm-message.h | 12 +- 7 files changed, 1667 insertions(+), 4 deletions(-) create mode 100644 drivers/mailbox/mailbox-flexrm/Makefile create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.c create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-desc.h create mode 100644 drivers/mailbox/mailbox-flexrm/flexrm-main.c diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index 11eebfe..bfeced1 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -143,4 +143,15 @@ config BCM_PDC_MBOX Mailbox implementation for the Broadcom PDC ring manager, which provides access to various offload engines on Broadcom SoCs. Say Y here if you want to use the Broadcom PDC. + +config BCM_FLEXRM_MBOX + tristate "Broadcom FlexRM Mailbox" + depends on ARM64 || COMPILE_TEST + depends on HAS_DMA + select GENERIC_MSI_IRQ_DOMAIN + default ARCH_BCM_IPROC + help + Mailbox implementation of the Broadcom FlexRM ring manager, + which provides access to various offload engines on Broadcom + SoCs. Say Y here if you want to use the Broadcom FlexRM. endif diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index ace6fed..9594266 100644 --- a/drivers/mailbox/Makefile +++ b/drivers/mailbox/Makefile @@ -29,3 +29,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o + +obj-$(CONFIG_BCM_FLEXRM_MBOX) += mailbox-flexrm/ diff --git a/drivers/mailbox/mailbox-flexrm/Makefile b/drivers/mailbox/mailbox-flexrm/Makefile new file mode 100644 index 000..f5bf069 --- /dev/null +++ b/drivers/mailbox/mailbox-flexrm/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for Broadcom FlexRM Mailbox Driver. +# + +flexrm-mbox-objs := flexrm-main.o flexrm-desc.o +obj-$(CONFIG_BCM_FLEXRM_MBOX) += flexrm-mbox.o diff --git a/drivers/mailbox/mailbox-flexrm/flexrm-desc.c b/drivers/mailbox/mailbox-flexrm/flexrm-desc.c new file mode 100644 index 000..9432ec7 --- /dev/null +++ b/drivers/mailbox/mailbox-flexrm/flexrm-desc.c @@ -0,0 +1,764 @@ +/* Broadcom FlexRM Mailbox Driver + * + * Copyright (C) 2016 Broadcom + * + * 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. + * + * FlexRM descriptor library + */ + +#include +#include +#include +#include + +#include "flexrm-desc.h" + +/* Completion descriptor format */ +#define CMPL_OPAQUE_SHIFT 0 +#define CMPL_OPAQUE_MASK 0x +#define CMPL_ENGINE_STATUS_SHIFT 16 +#define CMPL_ENGINE_STATUS_MASK0x +#define CMPL_DME_STATUS_SHIFT 32 +#define CMPL_DME_STATUS_MASK 0x +#define CMPL_RM_STATUS_SHIFT 48 +#define CMPL_RM_STATUS_MASK0x + +/* Completion DME status code */ +#define DME_STATUS_MEM_COR_ERR BIT(0) +#define DME_STATUS_MEM_UCOR_ERRBIT(1) +#define DME_STATUS_FIFO_UNDERFLOW BIT(2) +#define DME_STATUS_FIFO_OVERFLOW BIT(3) +#define DME_STATUS_RRESP_ERR BIT(4) +#define DME_STATUS_BRESP_ERR BIT(5) +#define DME_STATUS_ERROR_MASK (DME_STATUS_MEM_COR_ERR | \ +DME_STATUS_MEM_UCOR_ERR | \ +DME_STATUS_FIFO_UNDERFLOW | \ +DME_STATUS_FIFO_OVERFLOW | \ +DME_STATUS_RRESP_ERR | \ +DME_STATUS_BRESP_ERR) + +/* Completion RM status code */ +#define RM_STATUS_CODE_SHIFT 0 +#define RM_STATUS_CODE_MASK0x3ff +#define RM_STATUS_CODE_GOOD0x0 +#define RM_STATUS_CODE_AE_TIMEOUT 0x3ff + +/* General descriptor format */ +#define DESC_TYPE_SHIFT
Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
[Linus Cc'd] On Fri, Nov 25, 2016 at 01:49:18PM +1100, Dave Chinner wrote: > > they have become parts of stable userland ABI and are to be maintained > > indefinitely. Don't expect "tracepoints are special case" to prevent that. > > I call bullshit just like I always do when someone spouts this > "tracepoints are stable ABI" garbage. > Quite frankly, anyone that wants to stop us from > adding/removing/changing tracepoints or the code that they are > reporting information about "because ABI" can go take a long walk > off a short cliff. Diagnostic tracepoints are not part of the > stable ABI. End of story. Tell that to Linus. You had been in the room, IIRC, when that had been brought up this year in Santa Fe. "End of story" is not going to be yours (or mine, for that matter) to declare - Linus is the only one who can do that. If he says "if userland code relies upon it, so that userland code needs to be fixed" - I'm very happy (and everyone involved can count upon quite a few free drinks from me at the next summit). If it's "that userland code really shouldn't have relied upon it, and it's real unfortunate that it does, but we still get to keep it working" - too bad, "because ABI" is the reality and we will be the ones to take that long walk. What I heard from Linus sounded a lot closer to the second variant. _IF_ I have misinterpreted that, I'd love to hear that. Linus? PS: I'm dead serious about large amounts of booze of choice at LSFS 2017. Bribery or shared celebration - call it whatever you like; I really, really want to have tracepoints free from ABIfication concerns. They certainly are useful for debugging purposes - no arguments here.
[PATCH v2] Staging: iio: adc: fix sysfs files modes in ad7192.c
Fixes sysfs entries user/group modes and coding style warnings
found by checkpatch.pl tool. Also use the IIO_DEVICE_ATTR_[RO|RW] and
macros to create device attributes
Signed-off-by: Boyan Vladinov
---
drivers/staging/iio/adc/ad7192.c | 45 +++-
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index 1fb68c01abd5..630b04d8128f 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -324,8 +324,8 @@ static int ad7192_setup(struct ad7192_state *st,
}
static ssize_t
-ad7192_show_scale_available(struct device *dev,
- struct device_attribute *attr, char *buf)
+in_v_m_v_scale_available_show(struct device *dev, struct device_attribute
*attr,
+ char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ad7192_state *st = iio_priv(indio_dev);
@@ -340,15 +340,19 @@ ad7192_show_scale_available(struct device *dev,
return len;
}
-static IIO_DEVICE_ATTR_NAMED(in_v_m_v_scale_available,
-in_voltage-voltage_scale_available,
-S_IRUGO, ad7192_show_scale_available, NULL, 0);
+static ssize_t
+in_voltage_scale_available_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return in_v_m_v_scale_available_show(dev, attr, buf);
+}
+
+static IIO_DEVICE_ATTR_RO(in_v_m_v_scale_available, 0);
-static IIO_DEVICE_ATTR(in_voltage_scale_available, S_IRUGO,
- ad7192_show_scale_available, NULL, 0);
+static IIO_DEVICE_ATTR_RO(in_voltage_scale_available, 0);
-static ssize_t ad7192_show_ac_excitation(struct device *dev,
-struct device_attribute *attr,
+static ssize_t ac_excitation_en_show(struct device *dev,
+struct device_attribute *attr,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
@@ -357,8 +361,8 @@ static ssize_t ad7192_show_ac_excitation(struct device *dev,
return sprintf(buf, "%d\n", !!(st->mode & AD7192_MODE_ACX));
}
-static ssize_t ad7192_show_bridge_switch(struct device *dev,
-struct device_attribute *attr,
+static ssize_t bridge_switch_en_show(struct device *dev,
+struct device_attribute *attr,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
@@ -367,8 +371,8 @@ static ssize_t ad7192_show_bridge_switch(struct device *dev,
return sprintf(buf, "%d\n", !!(st->gpocon & AD7192_GPOCON_BPDSW));
}
-static ssize_t ad7192_set(struct device *dev,
- struct device_attribute *attr,
+static ssize_t bridge_switch_en_store(struct device *dev,
+ struct device_attribute *attr,
const char *buf,
size_t len)
{
@@ -412,13 +416,16 @@ static ssize_t ad7192_set(struct device *dev,
return ret ? ret : len;
}
-static IIO_DEVICE_ATTR(bridge_switch_en, S_IRUGO | S_IWUSR,
- ad7192_show_bridge_switch, ad7192_set,
- AD7192_REG_GPOCON);
+static ssize_t ac_excitation_en_store(struct device *dev,
+ struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ return bridge_switch_en_store(dev, attr, buf, len);
+}
+
+static IIO_DEVICE_ATTR_RW(bridge_switch_en, AD7192_REG_GPOCON);
-static IIO_DEVICE_ATTR(ac_excitation_en, S_IRUGO | S_IWUSR,
- ad7192_show_ac_excitation, ad7192_set,
- AD7192_REG_MODE);
+static IIO_DEVICE_ATTR_RW(ac_excitation_en, AD7192_REG_MODE);
static struct attribute *ad7192_attributes[] = {
&iio_dev_attr_in_v_m_v_scale_available.dev_attr.attr,
--
2.7.4
Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v2)
On 11/17/2016 05:58 AM, Dave Hansen wrote:
> Changes from v1:
> * Do one 'Pte' line per pte size instead of mashing on one line
> * Use PMD_SIZE for pmds instead of PAGE_SIZE, whoops
> * Wrote some Documentation/
>
> --
>
> /proc/$pid/smaps has a number of fields that are intended to imply the
> kinds of PTEs used to map memory. "AnonHugePages" obviously tells you
> how many PMDs are being used. "MMUPageSize" along with the "Hugetlb"
> fields tells you how many PTEs you have for a huge page.
>
> The current mechanisms work fine when we have one or two page sizes.
> But, they start to get a bit muddled when we mix page sizes inside
> one VMA. For instance, the DAX folks were proposing adding a set of
> fields like:
So DAX is only case which creates this scenario of multi page sizes in
the same VMA ? Is there any cases other than DAX mapping ?
>
> DevicePages:
> DeviceHugePages:
> DeviceGiganticPages:
> DeviceGinormousPages:
I guess these are the page sizes supported at PTE, PMD, PUD, PGD level.
Are all these page sizes supported right now or we are just creating
place holder for future.
>
> to unmuddle things when page sizes get mixed. That's fine, but
> it does require userspace know the mapping from our various
> arbitrary names to hardware page sizes on each architecture and
> kernel configuration. That seems rather suboptimal.
>
> What folks really want is to know how much memory is mapped with
> each page size. How about we just do *that*?
>
> Patch attached. Seems harmless enough. Seems to compile on a
> bunch of random architectures. Makes smaps look like this:
>
> Private_Hugetlb: 0 kB
> Swap: 0 kB
> SwapPss: 0 kB
> KernelPageSize:4 kB
> MMUPageSize: 4 kB
> Locked:0 kB
> Ptes@4kB: 32 kB
> Ptes@2MB: 2048 kB
So in the left column we are explicitly indicating the size of the PTE
and expect the user to figure out where it can really be either at PTE,
PMD, PUD etc. Thats little bit different that 'AnonHugePages' or the
Shared_HugeTLB/Private_HugeTLB pages which we know are the the PMD/PUD
level.
>
> The format I used here should be unlikely to break smaps parsers
> unless they're looking for "kB" and now match the 'Ptes@4kB' instead
> of the one at the end of the line.
Right. So you are dropping the idea to introduce these fields as you
mentioned before for DAX mappings.
DevicePages:
DeviceHugePages:
DeviceGiganticPages:
DeviceGinormousPages:
>
> 1. I'd like to thank Dan Williams for showing me a mirror as I
>complained about the bozo that introduced 'AnonHugePages'.
>
> Cc: Christoph Hellwig
> Cc: Andrew Morton
> Cc: Dan Williams
> Cc: Anshuman Khandual
> Cc: linux...@kvack.org
>
> ---
>
> b/Documentation/filesystems/proc.txt |6 ++
> b/fs/proc/task_mmu.c | 81
> ++-
> 2 files changed, 85 insertions(+), 2 deletions(-)
>
> diff -puN fs/proc/task_mmu.c~smaps-pte-sizes fs/proc/task_mmu.c
> --- a/fs/proc/task_mmu.c~smaps-pte-sizes 2016-11-16 15:43:56.756991084
> -0800
> +++ b/fs/proc/task_mmu.c 2016-11-16 16:19:47.354789912 -0800
> @@ -445,6 +445,9 @@ struct mem_size_stats {
> unsigned long swap;
> unsigned long shared_hugetlb;
> unsigned long private_hugetlb;
> + unsigned long rss_pte;
> + unsigned long rss_pmd;
> + unsigned long rss_pud;
> u64 pss;
> u64 swap_pss;
> bool check_shmem_swap;
> @@ -519,6 +522,7 @@ static void smaps_pte_entry(pte_t *pte,
>
> if (pte_present(*pte)) {
> page = vm_normal_page(vma, addr, *pte);
> + mss->rss_pte += PAGE_SIZE;
> } else if (is_swap_pte(*pte)) {
> swp_entry_t swpent = pte_to_swp_entry(*pte);
>
> @@ -578,6 +582,7 @@ static void smaps_pmd_entry(pmd_t *pmd,
> /* pass */;
> else
> VM_BUG_ON_PAGE(1, page);
> + mss->rss_pmd += PMD_SIZE;
> smaps_account(mss, page, true, pmd_young(*pmd), pmd_dirty(*pmd));
> }
> #else
> @@ -702,11 +707,13 @@ static int smaps_hugetlb_range(pte_t *pt
> }
> if (page) {
> int mapcount = page_mapcount(page);
> + unsigned long hpage_size = huge_page_size(hstate_vma(vma));
>
> + mss->rss_pud += hpage_size;
> if (mapcount >= 2)
> - mss->shared_hugetlb += huge_page_size(hstate_vma(vma));
> + mss->shared_hugetlb += hpage_size;
> else
> - mss->private_hugetlb += huge_page_size(hstate_vma(vma));
> + mss->private_hugetlb += hpage_size;
> }
> return 0;
Hmm, is this related to these new changes ? The replacement of 'hpage_size'
instead of huge_page_size(hstate_vma(vma)) can be done in a separate patch.
> }
> @@ -716,6 +723,75 @@ void __weak arch_show_smap(struct seq_fi
> {
> }
>
> +/*
> +
[PATCH v2] fsl/usb: Workarourd for USB erratum-A005697
The EHCI specification states the following in the SUSP bit description:
In the Suspend state, the port is senstive to resume detection.
Note that the bit status does not change untile the port is suspended and
that there may be a delay in susupending a port if there is a transaction
currently in progress on the USB.
However, in NXP USBDR controller, the PORTSCx[SUSP] bit changes immediately
when the application sets it and not when the port is actually suspended.
So the application must wait for at least 10 milliseconds after a port
indicates that it is suspended, to make sure this port has entered
suspended state before initiating this port resume using the Force Port
Resume bit. This bit is for NXP controller, not EHCI compatible.
Signed-off-by: Changming Huang
Signed-off-by: Ramneek Mehresh
---
Change in v2:
- move sleep out of spin-lock and add more comment for this workaround
drivers/usb/host/ehci-fsl.c |3 +++
drivers/usb/host/ehci-hub.c |7 +++
drivers/usb/host/ehci.h |6 ++
drivers/usb/host/fsl-mph-dr-of.c |2 ++
include/linux/fsl_devices.h |1 +
5 files changed, 19 insertions(+)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 9f5ffb6..91701cc 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -286,6 +286,9 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->has_fsl_erratum_a005275 == 1)
ehci->has_fsl_hs_errata = 1;
+ if (pdata->has_fsl_erratum_a005697 == 1)
+ ehci->has_fsl_susp_errata = 1;
+
if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
(pdata->operating_mode == FSL_USB2_DR_OTG))
if (ehci_fsl_setup_phy(hcd, pdata->phy_mode, 0))
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 74f62d6..81e2310 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -310,6 +310,13 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
}
spin_unlock_irq(&ehci->lock);
+ if (changed && ehci_has_fsl_susp_errata(ehci))
+ /* Wait for at least 10 millisecondes to ensure the controller
+* enter the suspend status before initiating a port resume
+* using the Fore Port Resume bit (Not-EHCI compatible).
+*/
+ usleep_range(1, 2);
+
if ((changed && ehci->has_tdi_phy_lpm) || fs_idle_delay) {
/*
* Wait for HCD to enter low-power mode or for the bus
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 3f3b74a..7706e4a 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -219,6 +219,7 @@ struct ehci_hcd { /* one per controller */
unsignedno_selective_suspend:1;
unsignedhas_fsl_port_bug:1; /* FreeScale */
unsignedhas_fsl_hs_errata:1;/* Freescale HS quirk */
+ unsignedhas_fsl_susp_errata:1; /*Freescale SUSP quirk*/
unsignedbig_endian_mmio:1;
unsignedbig_endian_desc:1;
unsignedbig_endian_capbase:1;
@@ -703,10 +704,15 @@ struct ehci_tt {
#if defined(CONFIG_PPC_85xx)
/* Some Freescale processors have an erratum (USB A-005275) in which
* incoming packets get corrupted in HS mode
+ * Some Freescale processors have an erratum (USB A-005697) in which
+ * we need to wait for 10ms for bus to fo into suspend mode after
+ * setting SUSP bit
*/
#define ehci_has_fsl_hs_errata(e) ((e)->has_fsl_hs_errata)
+#define ehci_has_fsl_susp_errata(e)((e)->has_fsl_susp_errata)
#else
#define ehci_has_fsl_hs_errata(e) (0)
+#define ehci_has_fsl_susp_errata(e)(0)
#endif
/*
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index f07ccb2..e90ddb5 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -226,6 +226,8 @@ static int fsl_usb2_mph_dr_of_probe(struct platform_device
*ofdev)
of_property_read_bool(np, "fsl,usb-erratum-a007792");
pdata->has_fsl_erratum_a005275 =
of_property_read_bool(np, "fsl,usb-erratum-a005275");
+ pdata->has_fsl_erratum_a005697 =
+ of_property_read_bool(np, "fsl,usb_erratum-a005697");
/*
* Determine whether phy_clk_valid needs to be checked
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index f291291..60cef82 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -100,6 +100,7 @@ struct fsl_usb2_platform_data {
unsignedalready_suspended:1;
unsignedhas_fsl_erratum_a007792:1;
unsignedhas_fsl_erratum_a005275:1;
+ unsignedhas_fsl_erratum_a005697:1;
unsignedcheck_phy_clk_valid:1;
/* register save area f
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
On 16-11-24 07:27 PM, Francois Romieu wrote: > > Through aliasing the URB was given a page that contains said (previously) > received file. The ethernet chip/usb host does not write anything in it. I don't see how that could be possible. Please elaborate. The URB buffers are statically allocated by the driver at probe time, ten of them in all, allocated with usb_alloc_coherent() in the copy of the driver I am testing with. There is no possibility for them to be used for anything other than USB receive buffers, for this driver only. Nothing in the driver or kernel ever writes to those buffers after initial allocation, and only the driver and USB host controller ever have pointers to the buffers. -- Mark Lord
Re: [PATCH] reset: hisilicon: add a polarity cell for reset line specifier
On 2016/11/21 10:58, Jiancheng Xue wrote: > Hi Philipp, > >> On 2016/11/15 18:43, Philipp Zabel wrote: >>> Hi Jiancheng, >>> >>> Am Dienstag, den 15.11.2016, 15:09 +0800 schrieb Jiancheng Xue: Add a polarity cell for reset line specifier. If the reset line is asserted when the register bit is 1, the polarity is normal. Otherwise, it is inverted. Signed-off-by: Jiancheng Xue --- >> Thank you very much for replying so soon. >> >> Please allow me to decribe the reason why this patch exists first. >> All bits in the reset controller were designed to be active-high. >> But in a recent chip only one bit was implemented to be active-low :( >> .../devicetree/bindings/clock/hisi-crg.txt | 11 --- arch/arm/boot/dts/hi3519.dtsi | 2 +- drivers/clk/hisilicon/reset.c | 36 -- 3 files changed, 33 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt b/Documentation/devicetree/bindings/clock/hisi-crg.txt index e3919b6..fcbb4f3 100644 --- a/Documentation/devicetree/bindings/clock/hisi-crg.txt +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt @@ -25,19 +25,20 @@ to specify the clock which they consume. All these identifier could be found in . -- #reset-cells: should be 2. +- #reset-cells: should be 3. A reset signal can be controlled by writing a bit register in the CRG module. -The reset specifier consists of two cells. The first cell represents the +The reset specifier consists of three cells. The first cell represents the register offset relative to the base address. The second cell represents the -bit index in the register. +bit index in the register. The third cell represents the polarity of the reset +line (0 for normal, 1 for inverted). >>> > #reset-cells: Should be 2 if compatilbe string is "hisilicon,hi3519-crg". > Should be 3 otherwise. > A reset signal can be controlled by writing a bit register in the > CRG module. > The reset specifier consists of two or three cells. The first > cell represents the > register offset relative to the base address. The second cell > represents the > bit index in the register.The third cell represents the polarity > of the reset > line (0 for active-high, 1 for active-low). > > If I change the binding like this, can it be accepted? > Hi Philipp, Could you give me more suggestions about this? If you really don't like changing the reset-cells like this, I can modify the patch according to your suggestions. Thank you. Regards, Jiancheng
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
On Fri, Nov 25, 2016 at 8:28 AM, wrote: > From: Ondrej Jirman > > When adjusting PLL_CPUX on H3, the PLL is temporarily driven > too high, and the system becomes unstable (oopses or hangs). > > Add a notifier to avoid this situation by temporarily switching > to a known stable 24 MHz oscillator. > > Signed-off-by: Ondrej Jirman > Tested-by: Lutz Sammer A Fixes tag would be nice. Otherwise, Acked-by: Chen-Yu Tsai
linux-next: Tree for Nov 25
Hi all, Changes since 20161124: The akpm-current tree still had its build failure for which I added a CONFIG_KEXEC_FILE on powerpc. Non-merge commits (relative to Linus' tree): 7973 8042 files changed, 463502 insertions(+), 175899 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (with KALLSYMS_EXTRA_PASS=1) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 243 trees (counting Linus' and 34 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (16ae16c6e561 Merge tag 'mmc-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (c6a385539175 kbuild: Steal gcc's pie from the very beginning) Merging arc-current/for-curr (a25f0944ba9b Linux 4.9-rc5) Merging arm-current/fixes (575f6e7a97ab ARM: 8630/1: don't use assembler macro arguments with EXPORT_SYMBOL()) Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (a1ff57416af9 powerpc/boot: Fix the early OPAL console wrappers) Merging sparc/master (9dd35d6882a1 sparc: drop duplicate header scatterlist.h) Merging net/master (764d3be6e415 ipv6: bump genid when the IFA_F_TENTATIVE flag is clear) Merging ipsec/master (6b2264878155 flowcache: Increase threshold for refusing new allocations) Merging netfilter/master (9b6c14d51bd2 net: tcp response should set oif only if it is L3 master) Merging ipvs/master (9b6c14d51bd2 net: tcp response should set oif only if it is L3 master) Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 32-byte SSIDs) Merging mac80211/master (51b9a31c42ed tipc: eliminate obsolete socket locking policy description) Merging sound-current/for-linus (6ff1a25318eb ALSA: usb-audio: Fix use-after-free of usb_device at disconnect) Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)) Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5) Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3) Merging usb.current/usb-linus (c0da038d7afe Merge tag 'usb-serial-4.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong parenthesis in ffs_func_req_match()) Merging usb-serial-fixes/usb-linus (2ab13292d7a3 USB: serial: cp210x: add ID for the Zone DPMX) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu) Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5) Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5) Merging input-current/for-linus (e9fb7cc63801 Input: psmouse - disable automatic probing of BYD touchpads) Merging crypto-current/master (c8467f7a3620 crypto: scatterwalk - Remove unnecessary aliasing check in map_and_copy) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merging vfio-fixes/for-linus (05692d
Re: [char-misc-next] mei: request async autosuspend at the end of enumeration
On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > > > > Cc: # 4.4+ > > > > > > Looks like git send-email is not able to parse this address correctly > > > though this is suggested format by Documentation/stable_kernel_rules.txt. > > > Create wrong address If git parsers is used : > > > 'sta...@vger.kernel.org#4.4+' > > > > > > Something like s/#.*$// is needed before parsing Cc: > > > > This should be fixed by e3fdbcc8e (parse_mailboxes: accept extra text after > > <...> address, 2016-10-13), which will be released next week as part of > > v2.11. As > > a workaround, you can also install the Mail::Address perl module. See [1] > > for > > the gory details. > > Thanks for update, I failed to understand from the thread though what > decision was actually applied, I will look at the patch itself. I've > tried to install Mail::Address and it fixes the actual address, but it > appends the # 4.4+ suffix into the name as also mentioned in the > thread, which doesn't fit the stable rules doc. The patch just brings parity to the Mail::Address behavior and git's fallback parser, so that you don't end up with the broken sta...@vger.kernel.org#4.4+ address. Instead, that content goes into the name part of the address. It sounds like you want the "# 4.4+" to be dropped entirely in the rfc822 header. It looks like send-email used to do that, but stopped in b1c8a11c8 (send-email: allow multiple emails using --cc, --to and --bcc, 2015-06-30). So perhaps there are further fixes required, but it's hard to know. The input isn't a valid rfc822 header, so it's not entirely clear what the output is supposed to be. I can buy either "drop it completely" or "stick it in the name field of the cc header" as reasonable. -Peff
Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
On Wed, Nov 23, 2016 at 11:44:19AM -0700, Ross Zwisler wrote: > Tracepoints are the standard way to capture debugging and tracing > information in many parts of the kernel, including the XFS and ext4 > filesystems. Create a tracepoint header for FS DAX and add the first DAX > tracepoints to the PMD fault handler. This allows the tracing for DAX to > be done in the same way as the filesystem tracing so that developers can > look at them together and get a coherent idea of what the system is doing. > > I added both an entry and exit tracepoint because future patches will add > tracepoints to child functions of dax_iomap_pmd_fault() like > dax_pmd_load_hole() and dax_pmd_insert_mapping(). We want those messages to > be wrapped by the parent function tracepoints so the code flow is more > easily understood. Having entry and exit tracepoints for faults also > allows us to easily see what filesystems functions were called during the > fault. These filesystem functions get executed via iomap_begin() and > iomap_end() calls, for example, and will have their own tracepoints. > > For PMD faults we primarily want to understand the faulting address and > whether it fell back to 4k faults. If it fell back to 4k faults the > tracepoints should let us understand why. > > I named the new tracepoint header file "fs_dax.h" to allow for device DAX > to have its own separate tracing header in the same directory at some > point. > > Here is an example output for these events from a successful PMD fault: > > big-2057 [000] 136.396855: dax_pmd_fault: shared mapping write > address 0x10505000 vm_start 0x1020 vm_end 0x1070 pgoff 0x200 > max_pgoff 0x1400 > > big-2057 [000] 136.397943: dax_pmd_fault_done: shared mapping write > address 0x10505000 vm_start 0x1020 vm_end 0x1070 pgoff 0x200 > max_pgoff 0x1400 NOPAGE Can we make the output use the same format as most of the filesystem code? i.e. the output starts with backing device + inode number like so: xfs_ilock:dev 8:96 ino 0x493 flags ILOCK_EXCL This way we can filter the output easily across both dax and filesystem tracepoints with 'grep "ino 0x493"'... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [tpmdd-devel] [PATCH v5 3/3] tpm: add securityfs support for TPM 2.0 firmware event log
On 11/24/2016 04:10 PM, Jarkko Sakkinen wrote: On Wed, Nov 23, 2016 at 12:27:37PM -0500, Nayna Jain wrote: Unlike the device driver support for TPM 1.2, the TPM 2.0 does not support the securityfs pseudo files for displaying the firmware event log. This patch enables support for providing the TPM 2.0 event log in binary form. TPM 2.0 event log supports a crypto agile format that records multiple digests, which is different from TPM 1.2. This patch enables the tpm_bios_log_setup for TPM 2.0 and adds the event log parser which understand the TPM 2.0 crypto agile format. Signed-off-by: Nayna Jain I don't want to say much about this before I've tested it. I wonder what cheap hardware I could use to test this. Any advice is on this from anyone is much appreciated. Virtual hardware would be cheap :-) I tested this series with QEMU + vTPM + SeaBIOS with TPM 1.2 + TPM 2 support (basing the log on ACPI). I had to fix an endianess issue on the SeaBIOS side, which made it work. So for this version of the patches I can give it my tested-by: Tested-by: Stefan Berger /Jarkko -- ___ tpmdd-devel mailing list tpmdd-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing
On Thu, Nov 24, 2016 at 05:32:20PM +, Al Viro wrote: > On Wed, Nov 23, 2016 at 11:44:19AM -0700, Ross Zwisler wrote: > > Tracepoints are the standard way to capture debugging and tracing > > information in many parts of the kernel, including the XFS and ext4 > > filesystems. Create a tracepoint header for FS DAX and add the first DAX > > tracepoints to the PMD fault handler. This allows the tracing for DAX to > > be done in the same way as the filesystem tracing so that developers can > > look at them together and get a coherent idea of what the system is doing. > > It also has one hell of potential for becoming a massive nuisance. > Keep in mind that if any userland code becomes dependent on those - that's it, > they have become parts of stable userland ABI and are to be maintained > indefinitely. Don't expect "tracepoints are special case" to prevent that. I call bullshit just like I always do when someone spouts this "tracepoints are stable ABI" garbage. If we want to provide stable tracepoints, then we need to /create a stable tracepoint API/ and convert all the tracepoints that /need to be stable/ to use it. Then developers only need to be careful about modifying code around the /explicitly stable/ tracepoints and we avoid retrospectively locking the kernel implementation into a KABI so tight we can't do anything anymore Quite frankly, anyone that wants to stop us from adding/removing/changing tracepoints or the code that they are reporting information about "because ABI" can go take a long walk off a short cliff. Diagnostic tracepoints are not part of the stable ABI. End of story. > So treat anything you add in that manner as potential stable ABI > you might have to keep around forever. It's *not* a glorified debugging > printk. trace_printk() is the glorified debugging printk for tracing, not trace events. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH 3/3] tools/virtio: use {READ,WRITE}_ONCE() in uaccess.h
On 2016年11月24日 18:25, Mark Rutland wrote:
As a step towards killing off ACCESS_ONCE, use {READ,WRITE}_ONCE() for the
virtio tools uaccess primitives, pulling these in from .
With this done, we can kill off the now-unused ACCESS_ONCE() definition.
Signed-off-by: Mark Rutland
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
tools/virtio/linux/uaccess.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/virtio/linux/uaccess.h b/tools/virtio/linux/uaccess.h
index 0a578fe..fa05d01 100644
--- a/tools/virtio/linux/uaccess.h
+++ b/tools/virtio/linux/uaccess.h
@@ -1,8 +1,9 @@
#ifndef UACCESS_H
#define UACCESS_H
-extern void *__user_addr_min, *__user_addr_max;
-#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+#include
+
+extern void *__user_addr_min, *__user_addr_max;
static inline void __chk_user_ptr(const volatile void *p, size_t size)
{
@@ -13,7 +14,7 @@ static inline void __chk_user_ptr(const volatile void *p,
size_t size)
({\
typeof(ptr) __pu_ptr = (ptr); \
__chk_user_ptr(__pu_ptr, sizeof(*__pu_ptr));\
- ACCESS_ONCE(*(__pu_ptr)) = x; \
+ WRITE_ONCE(*(__pu_ptr), x); \
0; \
})
@@ -21,7 +22,7 @@ static inline void __chk_user_ptr(const volatile void *p, size_t size)
({\
typeof(ptr) __pu_ptr = (ptr); \
__chk_user_ptr(__pu_ptr, sizeof(*__pu_ptr));\
- x = ACCESS_ONCE(*(__pu_ptr)); \
+ x = READ_ONCE(*(__pu_ptr)); \
0; \
})
Reviewed-by: Jason Wang
Re: [PATCH 2/3] vringh: kill off ACCESS_ONCE()
On 2016年11月24日 18:25, Mark Rutland wrote:
Despite living under drivers/ vringh.c is also used as part of the userspace
virtio tools. Before we can kill off the ACCESS_ONCE()definition in the tools,
we must convert vringh.c to use {READ,WRITE}_ONCE().
This patch does so, along with the required include of for
the relevant definitions. The userspace tools provide their own definitions in
their own .
Signed-off-by: Mark Rutland
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/vhost/vringh.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index 3bb02c6..bb8971f 100644
--- a/drivers/vhost/vringh.c
+++ b/drivers/vhost/vringh.c
@@ -3,6 +3,7 @@
*
* Since these may be in userspace, we use (inline) accessors.
*/
+#include
#include
#include
#include
@@ -820,13 +821,13 @@ EXPORT_SYMBOL(vringh_need_notify_user);
static inline int getu16_kern(const struct vringh *vrh,
u16 *val, const __virtio16 *p)
{
- *val = vringh16_to_cpu(vrh, ACCESS_ONCE(*p));
+ *val = vringh16_to_cpu(vrh, READ_ONCE(*p));
return 0;
}
static inline int putu16_kern(const struct vringh *vrh, __virtio16 *p, u16 val)
{
- ACCESS_ONCE(*p) = cpu_to_vringh16(vrh, val);
+ WRITE_ONCE(*p, cpu_to_vringh16(vrh, val));
return 0;
}
Reviewed-by: Jason Wang
Re: [PATCH 1/3] tools/virtio: fix READ_ONCE()
On 2016年11月24日 18:25, Mark Rutland wrote:
The virtio tools implementation of READ_ONCE() has a single parameter called
'var', but erroneously refers to 'val' for its cast, and thus won't work unless
there's a variable of the correct type that happens to be called 'var'.
Fix this with s/var/val/, making READ_ONCE() work as expected regardless.
Fixes: a7c490333df3cff5 ("tools/virtio: use virt_xxx barriers")
Signed-off-by: Mark Rutland
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
tools/virtio/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virtio/linux/compiler.h b/tools/virtio/linux/compiler.h
index 845960e..c9ccfd4 100644
--- a/tools/virtio/linux/compiler.h
+++ b/tools/virtio/linux/compiler.h
@@ -4,6 +4,6 @@
#define WRITE_ONCE(var, val) \
(*((volatile typeof(val) *)(&(var))) = (val))
-#define READ_ONCE(var) (*((volatile typeof(val) *)(&(var
+#define READ_ONCE(var) (*((volatile typeof(var) *)(&(var
#endif
Reviewed-by: Jason Wang
[PATCH] f2fs: fix to determine start_cp_addr by sbi->cur_cp_pack
We don't guarantee cp_addr is fixed by cp_version.
This is to sync with f2fs-tools.
Cc: sta...@vger.kernel.org
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 5 +
fs/f2fs/f2fs.h | 14 +++---
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 54cc6a9..bf2f44c 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -789,6 +789,11 @@ int get_valid_checkpoint(struct f2fs_sb_info *sbi)
f2fs_put_page(cur_page, 1);
}
done:
+ if (cur_page == cp1)
+ sbi->cur_cp_pack = 1;
+ else
+ sbi->cur_cp_pack = 2;
+
f2fs_put_page(cp1, 1);
f2fs_put_page(cp2, 1);
return 0;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 62383d2..e22e7e1 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -792,6 +792,7 @@ struct f2fs_sb_info {
/* for checkpoint */
struct f2fs_checkpoint *ckpt; /* raw checkpoint pointer */
+ int cur_cp_pack;/* remain current cp pack */
spinlock_t cp_lock; /* for flag in ckpt */
struct inode *meta_inode; /* cache meta blocks */
struct mutex cp_mutex; /* checkpoint procedure lock */
@@ -1352,19 +1353,10 @@ static inline void *__bitmap_ptr(struct f2fs_sb_info
*sbi, int flag)
static inline block_t __start_cp_addr(struct f2fs_sb_info *sbi)
{
- block_t start_addr;
- struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
- unsigned long long ckpt_version = cur_cp_version(ckpt);
-
- start_addr = le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_blkaddr);
+ block_t start_addr = le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_blkaddr);
- /*
-* odd numbered checkpoint should at cp segment 0
-* and even segment must be at cp segment 1
-*/
- if (!(ckpt_version & 1))
+ if (sbi->cur_cp_pack == 2)
start_addr += sbi->blocks_per_seg;
-
return start_addr;
}
--
2.8.3
Re: [PATCH] PCI: altera: use builtin_platform_driver
On Rab, 2016-11-23 at 14:52 +, Geliang Tang wrote:
> Use builtin_platform_driver() helper to simplify the code.
>
> Signed-off-by: Geliang Tang
Acked-by: Ley Foon Tan
> ---
> drivers/pci/host/pcie-altera.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-
> altera.c
> index b0ac4df..eefcb38 100644
> --- a/drivers/pci/host/pcie-altera.c
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -641,8 +641,4 @@ static struct platform_driver altera_pcie_driver
> = {
> },
> };
>
> -static int altera_pcie_init(void)
> -{
> - return platform_driver_register(&altera_pcie_driver);
> -}
> -device_initcall(altera_pcie_init);
> +builtin_platform_driver(altera_pcie_driver);
> --
> 2.9.3
>
Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order
Hi Viresh. On 11/24/2016 05:34 PM, Viresh Kumar wrote: > Ho Joonyoung, > > On 24-11-16, 16:49, Joonyoung Shim wrote: >> The device that creates OPP table first should be removed from dev_list >> of OPP table in last because it can be used by other resources >> (supported_hw, prop_name, regulator), but not now. > > I am not sure what you are trying to do here? Why can't the CPU which > added the OPP should be removed last. > > Can you give a real example where you see a problem ? > >> If OPP table is >> shared by several CPUs, the CPU device that creates OPP table can be >> removed earlier than other CPU devices. > > I don't think that's a problem, though I can be wrong for sure. > I found this problem during system suspend/resume of Odroid-XU3 board. # rtcwake -m mem -s 3 wakeup from "mem" at Wed Apr 4 05:54:44 2001 [ 15.965996] PM: Syncing filesystems ... done. [ 15.976333] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 16.006951] wake enabled for irq 135 [ 16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode [ 16.094110] PM: suspend of devices complete after 95.038 msecs [ 16.105648] PM: late suspend of devices complete after 6.903 msecs [ 16.116356] PM: noirq suspend of devices complete after 5.912 msecs [ 16.121213] Disabling non-boot CPUs ... [ 16.154140] IRQ51 no longer affine to CPU1 [ 16.154709] CPU1: shutdown [ 16.214148] IRQ52 no longer affine to CPU2 [ 16.214646] CPU2: shutdown [ 16.273980] IRQ53 no longer affine to CPU3 [ 16.274458] CPU3: shutdown [ 16.335093] IRQ54 no longer affine to CPU4 [ 16.336033] CPU4: shutdown [ 16.389979] IRQ55 no longer affine to CPU5 [ 16.390823] CPU5: shutdown [ 16.444829] IRQ56 no longer affine to CPU6 [ 16.445621] CPU6: shutdown [ 16.509229] cpu cpu4: Failed to find opp_table: -19 [ 16.514008] IRQ57 no longer affine to CPU7 [ 16.514824] CPU7: shutdown CPU4-7 are offline on after system resume. Above -19 error occurs because cannot find OPP table for CPU4 from dev_pm_opp_put_regulator() when regulator resource for CPU4 is put. Odroid-XU3 board uses exynos5422 SoCs having 8 CPUs (4 little cores / 4 bit cores). CPU0-3 (little core) shares a OPP table and CPU4-7 (bit core) shares a OPP table (operating-points-v2 binding). CPU0 and CPU4 have each regulators. You can find them from below dts files, arch/arm/boot/dts/exynos5420.dtsi arch/arm/boot/dts/exynos5422-cpus.dtsi arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi Let's see CPU4-7 case. A OPP tables are created by device of CPU4 from cpufreq_init() of drivers/cpufreq/cpufreq-dt.c. Each OPP devices of CPU4-7 are registered at dev_list of OPP table created by CPU4 device as CPU4 - CPU5 - CPU6 - CPU7 order. And regulator resource for CPU4 uses OPP device of CPU4. The cpufreq_exit() tries to free OPP table for CPU4-7 during system suspend. It will remove OPP devices as CPU4 - CPU5 - CPU6 - CPU7 order, then only OPP device for CPU7 remains before regulator resource of CPU4 is put, but it needs CPU4 OPP device that creates OPP table to put regulator resource of CPU4, not CPU7 OPP device. This patch will make to remove OPP devices as CPU5 - CPU6 - CPU7 - CPU4 order. As another way, we can consider reference count for OPP device. Above problem occurs because CPU4 and regulator of CPU4 use same OPP device. Any ideas? Thanks.
[PATCH] block_dev: don't test bdev->bd_contains when it is not stable.
bdev->bd_contains is not stable before calling __blkdev_get().
When __blkdev_get() is called on a parition with ->bd_openers == 0
it sets
bdev->bd_contains = bdev;
which is not correct for a partition.
After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
and then ->bd_contains is stable.
When FMODE_EXCL is used, blkdev_get() calls
bd_start_claiming() -> bd_prepare_to_claim() -> bd_may_claim()
This call happens before __blkdev_get() is called, so ->bd_contains
is not stable. So bd_may_claim() cannot safely use ->bd_contains.
It currently tries to use it, and this can lead to a BUG_ON().
This happens when a whole device is already open with a bd_holder (in
use by dm in my particular example) and two threads race to open a
partition of that device for the first time, one opening with O_EXCL and
one without.
The thread that doesn't use O_EXCL gets through blkdev_get() to
__blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev;
Immediately thereafter the other thread, using FMODE_EXCL, calls
bd_start_claiming() from blkdev_get(). This should fail because the
whole device has a holder, but because bdev->bd_contains == bdev
bd_may_claim() incorrectly reports success.
This thread continues and blocks on bd_mutex.
The first thread then sets bdev->bd_contains correctly and drops the mutex.
The thread using FMODE_EXCL then continues and when it calls bd_may_claim()
again in:
BUG_ON(!bd_may_claim(bdev, whole, holder));
The BUG_ON fires.
Fix this by removing the dependency on ->bd_contains in
bd_may_claim(). As bd_may_claim() has direct access to the whole
device, it can simply test if the target bdev is the whole device.
Fixes: 6b4517a7913a ("block: implement bd_claiming and claiming block")
Cc: sta...@vger.kernel.org (v2.6.35+)
Signed-off-by: NeilBrown
---
fs/block_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 05b553368bb4..9166b9f63d33 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -832,7 +832,7 @@ static bool bd_may_claim(struct block_device *bdev, struct
block_device *whole,
return true; /* already a holder */
else if (bdev->bd_holder != NULL)
return false;/* held by someone else */
- else if (bdev->bd_contains == bdev)
+ else if (whole == bdev)
return true; /* is a whole device which isn't held */
else if (whole->bd_holder == bd_may_claim)
--
2.10.2
signature.asc
Description: PGP signature
[PATCH 1/2] bcache: Remove redundant set_capacity
set_capacity() has been called in bcache_device_init(), remove the redundant one. Signed-off-by: Yijing Wang --- drivers/md/bcache/super.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index 849ad44..b638a16 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -1126,9 +1126,6 @@ static int cached_dev_init(struct cached_dev *dc, unsigned block_size) if (ret) return ret; - set_capacity(dc->disk.disk, -dc->bdev->bd_part->nr_sects - dc->sb.data_offset); - dc->disk.disk->queue->backing_dev_info.ra_pages = max(dc->disk.disk->queue->backing_dev_info.ra_pages, q->backing_dev_info.ra_pages); -- 2.5.0
[PATCH 2/2] bcache: remove unused parameter
Parameter bio is no longer used, clean it.
Signed-off-by: Yijing Wang
---
drivers/md/bcache/request.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 40ffe5e..bf6e432 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -26,12 +26,12 @@ struct kmem_cache *bch_search_cache;
static void bch_data_insert_start(struct closure *);
-static unsigned cache_mode(struct cached_dev *dc, struct bio *bio)
+static unsigned cache_mode(struct cached_dev *dc)
{
return BDEV_CACHE_MODE(&dc->sb);
}
-static bool verify(struct cached_dev *dc, struct bio *bio)
+static bool verify(struct cached_dev *dc)
{
return dc->verify;
}
@@ -371,7 +371,7 @@ static struct hlist_head *iohash(struct cached_dev *dc,
uint64_t k)
static bool check_should_bypass(struct cached_dev *dc, struct bio *bio)
{
struct cache_set *c = dc->disk.c;
- unsigned mode = cache_mode(dc, bio);
+ unsigned mode = cache_mode(dc);
unsigned sectors, congested = bch_get_congested(c);
struct task_struct *task = current;
struct io *i;
@@ -746,7 +746,7 @@ static void cached_dev_read_done(struct closure *cl)
s->cache_miss = NULL;
}
- if (verify(dc, &s->bio.bio) && s->recoverable && !s->read_dirty_data)
+ if (verify(dc) && s->recoverable && !s->read_dirty_data)
bch_data_verify(dc, s->orig_bio);
bio_complete(s);
@@ -771,7 +771,7 @@ static void cached_dev_read_done_bh(struct closure *cl)
if (s->iop.error)
continue_at_nobarrier(cl, cached_dev_read_error, bcache_wq);
- else if (s->iop.bio || verify(dc, &s->bio.bio))
+ else if (s->iop.bio || verify(dc))
continue_at_nobarrier(cl, cached_dev_read_done, bcache_wq);
else
continue_at_nobarrier(cl, cached_dev_bio_complete, NULL);
@@ -898,7 +898,7 @@ static void cached_dev_write(struct cached_dev *dc, struct
search *s)
s->iop.bypass = true;
if (should_writeback(dc, s->orig_bio,
-cache_mode(dc, bio),
+cache_mode(dc),
s->iop.bypass)) {
s->iop.bypass = false;
s->iop.writeback = true;
--
2.5.0
Re: [PATCH 0/2] KEYS: Fixes
On Thu, 24 Nov 2016, David Howells wrote: > James Morris wrote: > > > $ git pull > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > > keys-fixes-20161124-3 > > fatal: Couldn't find remote ref keys-fixes-20161124-3 > > Ummm... Weird. I can see the tag through the web interface: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-fixes-20161124-3 > > and it appears on the branch there: > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes Not sure what's going on there, it looks ok when I fetch your tree and check it out locally. In any case, I manually applied the patches from email, the old fashioned way. -- James Morris
[GIT PULL] Keys fixes
Please pull these fixes for the keys code. >From David: " (1) Fix mpi_powm()'s handling of a number with a zero exponent [CVE-2016-8650]. (2) Fix double free in X.509 error handling. Ver #3: - Integrate my and Andrey's patches for mpi_powm() and use mpi_resize() instead of RESIZE_IF_NEEDED() - the latter adds a duplicate check into the execution path of a trivial case we don't normally expect to be taken. Ver #2: - Use RESIZE_IF_NEEDED() to conditionally resize the result rather than manually doing this. " The following changes since commit 16ae16c6e5616c084168740990fc508bda6655d4: Merge tag 'mmc-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc (2016-11-24 10:51:18 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Andrey Ryabinin (2): X.509: Fix double free in x509_cert_parse() [ver #3] mpi: Fix NULL ptr dereference in mpi_powm() [ver #3] crypto/asymmetric_keys/x509_cert_parser.c |1 - lib/mpi/mpi-pow.c |7 ++- 2 files changed, 6 insertions(+), 2 deletions(-)
GOOD DAY FRIEND
-- Dear Friend, Good Day, I am Mr. Piyush Gupta as a (DBSHK) banker, I have funds worth of $25.500,000.00 to secretly secure and transfer in to your account of my late client who dead with next of kin, which i will like to invest in profitable business in your country. Please if you are interested to help me without betrayed me, do and write me for more details. Here is my Email: infopiyu...@gmail.com Regards, Mr. Piyush Gupta. (DBSHK) Hong Kong.
Re: [PATCH] pinctrl: imx: fix imx_pinctrl_desc initialization
Hi Gary,
On Thu, Nov 24, 2016 at 07:11:51PM +0100, Gary Bisson wrote:
>Was introduced by:
>6e408ed pinctrl: imx: fix initialization of imx_pinctrl_desc
>
>Signed-off-by: Gary Bisson
>---
> drivers/pinctrl/freescale/pinctrl-imx.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
>b/drivers/pinctrl/freescale/pinctrl-imx.c
>index 79c4e14..5ef7e87 100644
>--- a/drivers/pinctrl/freescale/pinctrl-imx.c
>+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
>@@ -778,10 +778,10 @@ int imx_pinctrl_probe(struct platform_device *pdev,
> imx_pinctrl_desc->name = dev_name(&pdev->dev);
> imx_pinctrl_desc->pins = info->pins;
> imx_pinctrl_desc->npins = info->npins;
>- imx_pinctrl_desc->pctlops = &imx_pctrl_ops,
>- imx_pinctrl_desc->pmxops = &imx_pmx_ops,
>- imx_pinctrl_desc->confops = &imx_pinconf_ops,
>- imx_pinctrl_desc->owner = THIS_MODULE,
>+ imx_pinctrl_desc->pctlops = &imx_pctrl_ops;
>+ imx_pinctrl_desc->pmxops = &imx_pmx_ops;
>+ imx_pinctrl_desc->confops = &imx_pinconf_ops;
>+ imx_pinctrl_desc->owner = THIS_MODULE;
Thanks for the fix.
Reviewed-by: Peng Fan
>
> ret = imx_pinctrl_probe_dt(pdev, info);
> if (ret) {
>--
>2.9.3
>
--
mptbase: fix printk output using pr_cont
With current linus git, Fusion MPT driver prints out unnecessary new lines.
[2.090255] Fusion MPT base driver 3.04.20
[2.090257] Copyright (c) 1999-2008 LSI Corporation
[2.090262] Fusion MPT SPI Host driver 3.04.20
[2.090979] mptbase: ioc0: Initiating bringup
[2.196306] ioc0:
[2.196310] LSI53C1030 B0:
[2.196312] Capabilities={
[2.196313] Initiator
[2.196314] }
I modified set of printk()s to pr_cont to fix the problem.
Not sure if it's correct, but now I can see the message as previous.
[2.404271] Fusion MPT base driver 3.04.20
[2.404274] Copyright (c) 1999-2008 LSI Corporation
[2.404279] Fusion MPT SPI Host driver 3.04.20
[2.405037] mptbase: ioc0: Initiating bringup
[2.509568] ioc0: LSI53C1030 B0: Capabilities={Initiator}
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 89c7ed1..0d434de 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -2866,23 +2866,23 @@ MptDisplayIocCapabilities(MPT_ADAPTER *ioc)
{
int i = 0;
- printk(KERN_INFO "%s: ", ioc->name);
+ pr_cont(KERN_INFO "%s: ", ioc->name);
if (ioc->prod_name)
- printk("%s: ", ioc->prod_name);
- printk("Capabilities={");
+ pr_cont("%s: ", ioc->prod_name);
+ pr_cont("Capabilities={");
if (ioc->pfacts[0].ProtocolFlags & MPI_PORTFACTS_PROTOCOL_INITIATOR) {
- printk("Initiator");
+ pr_cont("Initiator");
i++;
}
if (ioc->pfacts[0].ProtocolFlags & MPI_PORTFACTS_PROTOCOL_TARGET) {
- printk("%sTarget", i ? "," : "");
+ pr_cont("%sTarget", i ? "," : "");
i++;
}
if (ioc->pfacts[0].ProtocolFlags & MPI_PORTFACTS_PROTOCOL_LAN) {
- printk("%sLAN", i ? "," : "");
+ pr_cont("%sLAN", i ? "," : "");
i++;
}
@@ -2891,12 +2891,11 @@ MptDisplayIocCapabilities(MPT_ADAPTER *ioc)
* This would probably evoke more questions than it's worth
*/
if (ioc->pfacts[0].ProtocolFlags & MPI_PORTFACTS_PROTOCOL_TARGET) {
- printk("%sLogBusAddr", i ? "," : "");
+ pr_cont("%sLogBusAddr", i ? "," : "");
i++;
}
#endif
-
- printk("}\n");
+ pr_cont("}\n");
}
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
[PATCH] regmap: cache: Remove unused 'blksize' variable
Commit 2cbbb579bcbe ("regmap: Add the LZO cache support") introduced
'blksize' in regcache_lzo_read() and regcache_lzo_write(), that is
set but not used. Compiling with W=1 gives the following warnings,
fix them.
drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_read’:
drivers/base/regmap/regcache-lzo.c:239:9: warning: variable ‘blksize’ set but
not used [-Wunused-but-set-variable]
size_t blksize, tmp_dst_len;
^
drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_write’:
drivers/base/regmap/regcache-lzo.c:278:9: warning: variable ‘blksize’ set but
not used [-Wunused-but-set-variable]
size_t blksize, tmp_dst_len;
^
These are harmless warnings and are only being fixed to reduce the
noise with W=1 in the kernel.
Fixes: 2cbbb579bcbe ("regmap: Add the LZO cache support")
Cc: Dimitris Papastamos
Cc: Mark Brown
Signed-off-by: Kirtika Ruchandani
---
drivers/base/regmap/regcache-lzo.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/base/regmap/regcache-lzo.c
b/drivers/base/regmap/regcache-lzo.c
index 6f77d73..4ff3113 100644
--- a/drivers/base/regmap/regcache-lzo.c
+++ b/drivers/base/regmap/regcache-lzo.c
@@ -236,15 +236,13 @@ static int regcache_lzo_read(struct regmap *map,
{
struct regcache_lzo_ctx *lzo_block, **lzo_blocks;
int ret, blkindex, blkpos;
- size_t blksize, tmp_dst_len;
+ size_t tmp_dst_len;
void *tmp_dst;
/* index of the compressed lzo block */
blkindex = regcache_lzo_get_blkindex(map, reg);
/* register index within the decompressed block */
blkpos = regcache_lzo_get_blkpos(map, reg);
- /* size of the compressed block */
- blksize = regcache_lzo_get_blksize(map);
lzo_blocks = map->cache;
lzo_block = lzo_blocks[blkindex];
@@ -275,15 +273,13 @@ static int regcache_lzo_write(struct regmap *map,
{
struct regcache_lzo_ctx *lzo_block, **lzo_blocks;
int ret, blkindex, blkpos;
- size_t blksize, tmp_dst_len;
+ size_t tmp_dst_len;
void *tmp_dst;
/* index of the compressed lzo block */
blkindex = regcache_lzo_get_blkindex(map, reg);
/* register index within the decompressed block */
blkpos = regcache_lzo_get_blkpos(map, reg);
- /* size of the compressed block */
- blksize = regcache_lzo_get_blksize(map);
lzo_blocks = map->cache;
lzo_block = lzo_blocks[blkindex];
--
2.8.0.rc3.226.g39d4020
Re: [PATCH 4.8 00/67] 4.8.11-stable review
On 11/24/2016 07:26 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.8.11 release. There are 67 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Nov 26 14:54:42 UTC 2016. Anything received after that time might be too late. Build results: total: 149 pass: 149 fail: 0 Qemu test results: total: 114 pass: 114 fail: 0 Details are available at http://kerneltests.org/builders. Guenter
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, 24 Nov 2016 16:24:10 +0100 Greg Kroah-Hartman wrote: > On Thu, Nov 24, 2016 at 09:31:52PM +1100, Nicholas Piggin wrote: > > On Thu, 24 Nov 2016 10:56:22 +0100 > > Greg Kroah-Hartman wrote: > > > > > On Thu, Nov 24, 2016 at 06:53:22PM +1100, Nicholas Piggin wrote: > > > > On Thu, 24 Nov 2016 08:36:39 +0100 > > > > Greg Kroah-Hartman wrote: > > > > > > > > > On Thu, Nov 24, 2016 at 06:20:26PM +1100, Nicholas Piggin wrote: > > > > > > But still, modversions is pretty complicated for what it gives us. > > > > > > It sends > > > > > > preprocessed C into a C parser that makes CRCs using type > > > > > > definitions of > > > > > > exported symbols, then turns those CRCs into a linker script which > > > > > > which is > > > > > > used to link the .o file with. What we get in return is a quite > > > > > > limited and > > > > > > symbol "versioning" system. > > > > > > > > > > > > What if we ripped all that out and just attached an explicit > > > > > > version to > > > > > > each export, and incompatible changes require an increment? > > > > > > > > > > How would that work for structures? Would that be required for every > > > > > EXPORT_SYMBOL* somehow? > > > > > > > > Yeah just have EXPORT_SYMBOL take another parameter which attaches a > > > > version > > > > number and use that as the value for the __crc_ symbol versions rather > > > > than > > > > a calculated CRC. > > > > > > > > Yes it would require some level of care from developers and may be a > > > > small > > > > annoyance when changing exports. But making people think a tiny bit more > > > > before chnaging exported ABI shouldn't be the end of the world. > > > > > > That wouldn't work at all for structures that change, as we never > > > explicitly "mark" them for export anywhere. > > > > Well, the module arrives at the objects one way or another via an exported > > symbol. Although it can be by following a lot of pointers so yes it's > > probably near impossible to do well. > > Yes, manual "marking" is never going to be a viable solution. I guess it really depends on how exactly you want to use it. For distros that do stable ABI but rarely may have to break something for security reasons, it should work and give exact control. What else do people *actually* use it for? Preventing mismatched modules when .git version is not attached and release version of the kernel has not been bumped. Is that it? > > > You need a tool that looks > > > at either the source code (what we have today), or looks at the > > > > What we have today only looks at the type of the exported function or > > variable I think (or does it? I didn't look that far into the parser). > > It should catch things if you change a structure layout of something > that is an argument in a function (like a pointer to a structure), > otherwise it wouldn't really be that good of a check, and kind of > useless. > > > Does not follow down all possible derivable pointer types. > > It should be pretty good, as I think the code is based on the old SuSE > scripts that used to do this really well. But it's been a long time > since I looked at it, so I could be wrong. Yeah... turns out modversions is in the "kind of useless" camp. The crc is based on the name of the type and that's it (that's what I thought, I just now verify it). > > > > > > Google tells me > > > > > > Linus is not a neutral bystander on the topic of symbol versioning, > > > > > > so I'm > > > > > > bracing for a robust response :) (actually I don't much care either > > > > > > way, I'm > > > > > > happy to put a couple of bandaids on it and keep it going) > > > > > > > > > > There are tools that people are working on to make it more obvious > > > > > where > > > > > API breaks happen by looking at the .o debug data instead of our crazy > > > > > current system (which is really better than nothing), perhaps we > > > > > should > > > > > start using them instead? > > > > > > > > > > See here for more details about this: > > > > > > > > > > https://kernel-recipes.org/en/2016/talks/would-an-abi-changes-visualization-tool-be-useful-to-linux-kernel-maintenance/ > > > > > > > > > > > > > Hmm. I guess it's basically similar to modversions, so has downsides of > > > > not > > > > detecting a semantic change unless it changes the type. But still, if > > > > we could > > > > replace our custom code with a tool like this for modversions > > > > functionality, > > > > that alone would be a massive improvement. But requiring debug info > > > > might be > > > > a bit of a show stopper. I also don't know if that would handle asm > > > > functions. > > > > > > I think we can live without asm functions changing their arguments as > > > that is usually very rare. And maybe debugging info being a requirement > > > for those that want modversions (i.e. the distros), is ok as they > > > already generate that as part of their build. > > > > Maybe
[PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
From: Ondrej Jirman
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a known stable 24 MHz oscillator.
Signed-off-by: Ondrej Jirman
Tested-by: Lutz Sammer
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 614d47c..cf266c9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -809,6 +809,13 @@ static const struct sunxi_ccu_desc sun8i_h3_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
};
+static struct ccu_mux_nb sun8i_h3_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_h3_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -827,6 +834,9 @@ static void __init sun8i_h3_ccu_setup(struct device_node
*node)
writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_h3_cpu_nb);
}
CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
sun8i_h3_ccu_setup);
--
2.10.2
Re: [fuse-devel] fuse: feasible to distinguish between umount and abort?
On Nov 24 2016, Miklos Szeredi wrote: > On Thu, Nov 24, 2016 at 12:11 AM, Nikolaus Rath wrote: >> Hello, >> >> Currently, both a call to umount(2) and writing "1" to >> /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the >> same state: reading from it returns ENODEV, and polling on it returns >> POLLERR. >> >> This causes problems for filesystems that want to ensure that the >> mountpoint is free when they exit. If accessing the device fd gives the >> above errors, they have to do an additional check to determine if they >> still need to unmount the mountpoint. This is difficult to do without >> race conditions (think of someone unmounting and immediately re-starting >> a new filesystem instance). >> >> Would it be possible to change the behavior of the /dev/fuse fd so that >> userspace can distinguish between a regular umount and use of the >> /sys/fs/fuse abort)? > > Yes. My proposal would be for the kernel to send FUSE_DESTROY > asynchronously and only return ENODEV once that request was read by > userspace. Currently FUSE_DESTROY is sent synchronously for fuseblk > mounts, but not for plain fuse mounts. I trust that this is a good plan, but from the description I can't quite tell how the filesystem would make the distinction between umount/abort based on this. Would FUSE_DESTROY be send only for unmount, but not for abort? > Please file a bug somewhere. I don't mind if kernel bugs are also > kept at the github project as long as they can easily be found. Already done at https://github.com/libfuse/libfuse/issues/122. Thanks! -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
Mark Lord : [...] > >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). > > The driver itself NEVER writes anything to that buffer, > and nobody else has a pointer to it other than the USB host controller, > so there's nothing else that can write to it either. > > According to the driver writer, the chip should only ever write a fresh > rx_desc struct at the beginning of a buffer, never ASCII data. > > So how does that buffer end up containing ASCII data from the NFS transfers? Through aliasing the URB was given a page that contains said (previously) received file. The ethernet chip/usb host does not write anything in it. There could be a device or a driver problem but it may not be the real problem. So far the analysis focused on "how was this corrupted content written into this receive buffer page ?". If I read David correctly (?) the "nobody else has a pointer to it other than the USB host controller" point may be replaced with "the pointer to it aliases some already used page". -- Ueimor
Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on
Hi Daniel, On Wednesday 23 Nov 2016 08:55:37 Daniel Vetter wrote: > On Tue, Nov 22, 2016 at 08:23:38PM +0200, Laurent Pinchart wrote: > > On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote: > >> On Tue, Nov 22, 2016 at 9:38 AM, John Stultz wrote: > >>> Interestingly, without the msleep added in this patch, removing the > >>> wait_event_interruptible_timeout() method in adv7511_wait_for_edid() > >>> and using the polling loop seems to make things just as reliable. So > >>> maybe something is off with the irq handling here instead? > >> > >> A.. So I think the trouble here is the that when we fail waiting > >> for the irq, the backtrace is as follows: > >> > >> [8.318654] [] dump_backtrace+0x0/0x1a0 > >> [8.318661] [] show_stack+0x14/0x20 > >> [8.318671] [] dump_stack+0x90/0xb0 > >> [8.318680] [] adv7511_get_edid_block+0x2c8/0x320 > >> [8.318687] [] drm_do_get_edid+0x78/0x280 > >> [8.318693] [] adv7511_get_modes+0x80/0xd8 > >> [8.318700] [] > >> adv7511_connector_get_modes+0x14/0x20 > >> [8.318710] [] > >> drm_helper_probe_single_connector_modes+0x2bc/0x500 > >> [8.318718] [] > >> drm_fb_helper_hotplug_event+0x130/0x188 > >> [8.318726] [] > >> drm_fbdev_cma_hotplug_event+0x10/0x20 > >> [8.318733] [] > >> kirin_fbdev_output_poll_changed+0x20/0x58 > >> [8.318740] [] > >> drm_kms_helper_hotplug_event+0x28/0x38 > >> [8.318748] [] drm_helper_hpd_irq_event+0x138/0x180 > >> [8.318754] [] adv7511_irq_process+0x78/0xd8 > >> [8.318761] [] adv7511_irq_handler+0x14/0x28 > >> [8.318769] [] irq_thread_fn+0x28/0x68 > >> [8.318775] [] irq_thread+0x128/0x1e8 > >> [8.318782] [] kthread+0xd0/0xe8 > >> [8.318788] [] ret_from_fork+0x10/0x50 > >> > >> So we're actually in irq handling the hotplug interrupt, which is why > >> we never get the irq notification when the edid is read. > >> > >> I suspect we need to use a workqueue to do the hotplug handling out of > >> irq. > > > > Lovely :-) > > > > Quoting the DRM documentation: > > > > /** > > * drm_helper_hpd_irq_event - hotplug processing > > * @dev: drm_device > > * > > * Drivers can use this helper function to run a detect cycle on all > > connectors > > * which have the DRM_CONNECTOR_POLL_HPD flag set in their &polled member. > > All > > * other connectors are ignored, which is useful to avoid reprobing fixed > > * panels. > > * > > * This helper function is useful for drivers which can't or don't track > > hotplug > > * interrupts for each connector. > > * > > * Drivers which support hotplug interrupts for each connector > > individually and > > * which have a more fine-grained detect logic should bypass this code and > > * directly call drm_kms_helper_hotplug_event() in case the connector > > state > > * changed. > > * > > * This function must be called from process context with no mode > > * setting locks held. > > * > > * Note that a connector can be both polled and probed from the hotplug > > handler, > > * in case the hotplug interrupt is known to be unreliable. > > */ > > > > So it looks like we should use drm_kms_helper_hotplug_event() instead. > > > > /** > > * drm_kms_helper_hotplug_event - fire off KMS hotplug events > > * @dev: drm_device whose connector state changed > > * > > * This function fires off the uevent for userspace and also calls the > > * output_poll_changed function, which is most commonly used to inform the > > fbdev > > * emulation code and allow it to update the fbcon output configuration. > > * > > * Drivers should call this from their hotplug handling code when a change > > is > > * detected. Note that this function does not do any output detection of > > its > > * own, like drm_helper_hpd_irq_event() does - this is assumed to be done > > by the > > * driver already. > > * > > * This function must be called from process context with no mode > > * setting locks held. > > */ > > > > The function suffers from the same problem though, that it must be called > > from process context. > > > > Daniel, why do we have an API the is clearly related to interrupt handling > > but requires the caller to implement a workqueue ? > > Because in general you need that workqueue anyway, and up to now there was > no driver ever who didn't have a work-queue already. None of the bridge drivers in drivers/gpu/drm/bridge/ have workqueues. They call the HPD helpers from a threaded interrupt handler though. Sleeping in that context is fine, calling functions that might rely on interrupts from the same device to signal completion (such as reading EDID through .get_modes()) isn't. > Nesting workqueues > within workqueues seemed beyond silly, hence why I removed them in: > > commit 69787f7da6b2adc4054357a661aaa1701a9ca76f > Author: Daniel Vetter > Date: Tue Oct 23 18:23:34 2012 + > > drm: run the hpd irq event code directly > > I guess we could talk about re-introducing a work-item based version of > drm_helper_hpd_irq_event.
