Re: [PATCH v6 14/17] ARM: mvebu: add Device Tree description of xHCI controllers on Armada 38x
On Thu, May 15, 2014 at 12:17:39PM +0200, Gregory CLEMENT wrote: > The Marvell Armada 38x SoCs contains two xHCI controllers. This commit > adds the Device Tree description of those interfaces at the SoC level, > and also enables the two USB3 ports on the Armada 385 DB platform and > one USB3 port on the Armada 385 RD platform. > > Signed-off-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > --- > arch/arm/boot/dts/armada-385-db.dts | 8 > arch/arm/boot/dts/armada-385-rd.dts | 4 > arch/arm/boot/dts/armada-38x.dtsi | 17 + > 3 files changed, 29 insertions(+) Patches 14 through 17 applied to mvebu/dt. Patch 17 amended as Sergei suggested. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: pl330: Add support for DMA_PAUSE command
At Thu, 15 May 2014 21:21:12 +0200, Lars-Peter Clausen wrote: > > On 05/15/2014 02:01 PM, Tushar Behera wrote: > > On 14 May 2014 17:54, Lars-Peter Clausen wrote: > >> On 05/14/2014 02:07 PM, Tushar Behera wrote: > >>> > >>> On 14 May 2014 17:29, Jassi Brar wrote: > > On Wed, May 14, 2014 at 8:53 AM, Tushar Behera > wrote: > > > > While playing back audio, pmc_dmaengine requests the DMA channel to > > stop DMA transmission through DMA_PAUSE command. > > > > Currently PL330 driver doesn't support DMA pause command, leaving > > the DMA state inconsistent when the system resumes. Instead, it would > > be better to terminate the DMA transfer during suspend and restart > > again during resume. > > > > Tested with audio playback across a suspend-resume cycle. > > > What is pmc_dmaengine? How does DMA_PAUSE help, when there is no > DMA_RESUME? > > >>> > >>> Sorry, it is a typo. > >>> > >>> sound/core/pcm_dmaengine.c:snd_dmaengine_pcm_trigger() --> > >>> dmaengine_pause() is called during system suspend. > >> > >> > >> It is only called if the DMA driver has support for pausing and resuming > >> DMA > >> transfers. Or at least that is the intention. > >> > >> - Lars > > > > During suspend, snd_dmaengine_pcm_trigger():SNDRV_PCM_TRIGGER_SUSPEND > > is called which unconditionally calls dmaengine_pause(). Should we > > update snd_dmaengine_pcm_trigger() to check for DMA pause/resume > > support and call dmaengine_pause() or dmaengine_terminate_all() > > accordingly? > > As far as I understand it we do not have to do anything for TRIGGER_SUSPEND > if we do not set the SNDRV_PCM_INFO_RESUME flag. It looks like > TRIGGER_SUSPEND is called unconditionally during suspend. But since the > error code is ignored it should be fine if we just call dmaengine_pause() > and that return -ENOSYS or similar. Well, TRIGGER_SUSPEND is issued by PCM core no matter whether SNDRV_PCM_INFO_RESUME flag is set or not. The resume behavior depends on the flag (SNDRV_PCM_TRIGGER_RESUME is issued if the flag is set, otherwise the normal setup is done by alsa-lib at resume), but the suspend is always triggered in the same way. So, PCM core assumes that the driver stops the stream somehow by SNDRV_PCM_TRIGGER_SUSPEND. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 12/17] ARM: configs: enable XHCI mvebu support in mvebu_v7_defconfig
On Thu, May 15, 2014 at 12:17:37PM +0200, Gregory CLEMENT wrote: > The Marvell Armada 38x platform needs the xhci_mvebu driver enabled > for the xHCI USB hosts, so this commit enables the corresponding > Kconfig option in mvebu_v7_defconfig. > > Signed-off-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > --- > arch/arm/configs/mvebu_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) Applied to mvebu/defconfig thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 10/17] ARM: mvebu: add USB3 support for Armada 38x
On Thu, May 15, 2014 at 12:17:35PM +0200, Gregory CLEMENT wrote: > This patch adds the selection of the config symbol needed to build the > USB3 support for Armada 38x into mvebu_v7_defconfig. > > Signed-off-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > --- > arch/arm/mach-mvebu/Kconfig | 1 + > 1 file changed, 1 insertion(+) Patches 10 and 11 applied to mvebu/soc thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s
Am 15.05.2014 17:19, schrieb Alexander Holler: Am 15.05.2014 16:50, schrieb Alexander Holler: Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz: This timeout seems arbitrary so I suppose we can increase it if we feel it is necessary but we used already different timeout for different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can identify which command is more likely to timeout. We could perhaps auto reset if a command timeout if there is really no other way to recover. It is arbitrary but 2s is not enough here. And as I've written in the description, there is absolutely no reason to keep this timeout unnecessarily short. No one cares if an error message appears after 2s or 8s if the communication with the dongle is in both cases broken afterwards. One of the commands I experieced the problem with was e.g. HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE. The problem is that you can never be sure what the origin of a timeouted command was. It might have been e.g. the USB-subsystem through wich the command and the response has to travel (in case of USB dongles) and not the dongle itself. To explain a bit more, the box I'm experiencing these problems boots from USB2.0 HD. So it's likely that there is quiet some action on the bus and that shouldn't affect the operation of the BT-stack (besides slowing it maybe a bit down). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH staging-next] goldfish: pipe: fix warnings for 32bit builds
drivers/platform/goldfish/goldfish_pipe.c: In function 'goldfish_cmd_status':
drivers/platform/goldfish/goldfish_pipe.c:164:14: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
writel((u32)(u64)pipe, dev->base + PIPE_REG_CHANNEL);
^
drivers/platform/goldfish/goldfish_pipe.c: In function 'goldfish_cmd':
drivers/platform/goldfish/goldfish_pipe.c:180:14: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
writel((u32)(u64)pipe, dev->base + PIPE_REG_CHANNEL);
^
drivers/platform/goldfish/goldfish_pipe.c: In function
'goldfish_pipe_read_write':
drivers/platform/goldfish/goldfish_pipe.c:337:16: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
writel((u32)(u64)pipe, dev->base + PIPE_REG_CHANNEL);
Reported-by: Fengguang Wu
Cc: Jun Tian
Cc: Alan Cox
Signed-off-by: Octavian Purdila
---
drivers/platform/goldfish/goldfish_pipe.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index c86180b..d9a09d9 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -158,7 +158,7 @@ static u32 goldfish_cmd_status(struct goldfish_pipe *pipe,
u32 cmd)
struct goldfish_pipe_dev *dev = pipe->dev;
spin_lock_irqsave(>lock, flags);
- gf_write64((u64)pipe, dev->base + PIPE_REG_CHANNEL,
+ gf_write64((u64)(unsigned long)pipe, dev->base + PIPE_REG_CHANNEL,
dev->base + PIPE_REG_CHANNEL_HIGH);
writel(cmd, dev->base + PIPE_REG_COMMAND);
status = readl(dev->base + PIPE_REG_STATUS);
@@ -172,7 +172,7 @@ static void goldfish_cmd(struct goldfish_pipe *pipe, u32
cmd)
struct goldfish_pipe_dev *dev = pipe->dev;
spin_lock_irqsave(>lock, flags);
- gf_write64((u64)pipe, dev->base + PIPE_REG_CHANNEL,
+ gf_write64((u64)(unsigned long)pipe, dev->base + PIPE_REG_CHANNEL,
dev->base + PIPE_REG_CHANNEL_HIGH);
writel(cmd, dev->base + PIPE_REG_COMMAND);
spin_unlock_irqrestore(>lock, flags);
@@ -327,8 +327,9 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
char __user *buffer,
spin_lock_irqsave(>lock, irq_flags);
if (access_with_param(dev, CMD_WRITE_BUFFER + cmd_offset,
address, avail, pipe, )) {
- gf_write64((u64)pipe, dev->base + PIPE_REG_CHANNEL,
- dev->base + PIPE_REG_CHANNEL_HIGH);
+ gf_write64((u64)(unsigned long)pipe,
+ dev->base + PIPE_REG_CHANNEL,
+ dev->base + PIPE_REG_CHANNEL_HIGH);
writel(avail, dev->base + PIPE_REG_SIZE);
gf_write64(address, dev->base + PIPE_REG_ADDRESS,
dev->base + PIPE_REG_ADDRESS_HIGH);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH staging-next] goldfish: bus: fix warnings for 32bit builds
drivers/platform/goldfish/pdev_bus.c: In function 'goldfish_new_pdev': drivers/platform/goldfish/pdev_bus.c:136:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] writel((u32)(u64)name, pdev_bus_base + PDEV_BUS_GET_NAME); Reported-by: Fengguang Wu Cc: Jun Tian Cc: Alan Cox Signed-off-by: Octavian Purdila --- drivers/platform/goldfish/pdev_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/goldfish/pdev_bus.c b/drivers/platform/goldfish/pdev_bus.c index eb25440..8c43589 100644 --- a/drivers/platform/goldfish/pdev_bus.c +++ b/drivers/platform/goldfish/pdev_bus.c @@ -133,7 +133,7 @@ static int goldfish_new_pdev(void) #ifdef CONFIG_64BIT writel((u32)((u64)name>>32), pdev_bus_base + PDEV_BUS_GET_NAME_HIGH); #endif - writel((u32)(u64)name, pdev_bus_base + PDEV_BUS_GET_NAME); + writel((u32)(unsigned long)name, pdev_bus_base + PDEV_BUS_GET_NAME); name[name_len] = '\0'; dev->pdev.id = readl(pdev_bus_base + PDEV_BUS_ID); dev->pdev.resource[0].start = base; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] pwm: i.MX: Avoid sample FIFO overflow for i.MX PWM version2
The i.MX PWM version2 is embedded in several i.MX SoCs,
such as i.MX27, i.MX51 and i.MX6SL. There are four 16bit
sample FIFOs in this IP, each of which determines the duty
period of a PWM waveform in one full cycle. The IP spec
mentions that we should not write a fourth sample because
the FIFOs will become full and trigger a FIFO write error
(FWE) which will prevent the PWM from starting once it is
enabled. In order to avoid any sample FIFO overflow issue,
this patch clears all sample FIFOs or waits for a rollover
event to consume a FIFO slot when necessary. In this way,
only the first FIFO slot will be loaded at most.
Note that the PWM controller will not generate any rollover
event if the duty period is zero. This makes the logic a
bit complicated to determine if we clear the sample FIFOs
or wait for a rollover event.
The FIFO overflow issue can be reproduced by the following
commands on the i.MX6SL EVK platform, assuming we use PWM2
for the debug LED which is driven by the pin HSIC_STROBE
and the maximal brightness is 255.
echo 0 > /sys/class/leds/user/brightness
echo 0 > /sys/class/leds/user/brightness
echo 0 > /sys/class/leds/user/brightness
echo 0 > /sys/class/leds/user/brightness
echo 255 > /sys/class/leds/user/brightness
Here, FWE happens(PWMSR register reads 0x58) and the LED
can not be lighten.
Cc: Thierry Reding
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Lothar Waßmann
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Liu Ying
---
v2->v3:
* Wait for a rollover event before configuration when PWM
is active with non-zero duty period. And, update commit
message for that.
* Fix some typos in commit head and message(fifo -> FIFO,
pwm -> PWM, etc).
* Cc linux-kernel@vger.kernel.org.
v1->v2:
* To address Lothar Waßmann's comment, add a timeout mechanism
instead of endless polling the SWR bit to be cleared by the
hardware.
drivers/pwm/pwm-imx.c | 89 -
1 file changed, 88 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index d797c7b..204f4a9 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -14,7 +14,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -30,6 +32,7 @@
/* i.MX27, i.MX31, i.MX35 share the same PWM function block: */
#define MX3_PWMCR 0x00/* PWM Control Register */
+#define MX3_PWMIR 0x08/* PWM Interrupt Register */
#define MX3_PWMSAR0x0C/* PWM Sample Register */
#define MX3_PWMPR 0x10/* PWM Period Register */
#define MX3_PWMCR_PRESCALER(x)(((x - 1) & 0xFFF) << 4)
@@ -38,7 +41,12 @@
#define MX3_PWMCR_DBGEN(1 << 22)
#define MX3_PWMCR_CLKSRC_IPG_HIGH (2 << 16)
#define MX3_PWMCR_CLKSRC_IPG (1 << 16)
+#define MX3_PWMCR_SWR(1 << 3)
#define MX3_PWMCR_EN (1 << 0)
+#define MX3_PWMSR_ROV (1 << 4)
+#define MX3_PWMIR_RIE (1 << 1)
+
+#define MX3_PWM_SWR_LOOP 5
struct imx_chip {
struct clk *clk_per;
@@ -48,6 +56,9 @@ struct imx_chip {
struct pwm_chip chip;
+ unsigned intirq;
+ struct completion rov_complete;
+
int (*config)(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns);
void (*set_enable)(struct pwm_chip *chip, bool enable);
@@ -99,12 +110,33 @@ static void imx_pwm_set_enable_v1(struct pwm_chip *chip,
bool enable)
writel(val, imx->mmio_base + MX1_PWMC);
}
+/* Software reset clears all sample FIFOs. */
+static void imx_pwm_software_reset_v2(struct pwm_chip *chip)
+{
+ struct imx_chip *imx = to_imx_chip(chip);
+ struct device *dev = chip->dev;
+ int wait_count = 0;
+ u32 cr;
+
+ writel(MX3_PWMCR_SWR, imx->mmio_base + MX3_PWMCR);
+ do {
+ usleep_range(200, 1000);
+ cr = readl(imx->mmio_base + MX3_PWMCR);
+ } while ((cr & MX3_PWMCR_SWR) &&
+(wait_count++ < MX3_PWM_SWR_LOOP));
+
+ if (cr & MX3_PWMCR_SWR)
+ dev_warn(dev, "software reset timeout\n");
+}
+
static int imx_pwm_config_v2(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
{
struct imx_chip *imx = to_imx_chip(chip);
+ struct device *dev = chip->dev;
unsigned long long c;
unsigned long period_cycles, duty_cycles, prescale;
+ bool enable = test_bit(PWMF_ENABLED, >flags);
u32 cr;
c = clk_get_rate(imx->clk_per);
@@ -128,6 +160,13 @@ static int imx_pwm_config_v2(struct pwm_chip *chip,
else
period_cycles = 0;
+ if (!enable || duty_cycles == 0)
+ imx_pwm_software_reset_v2(chip);
+ else if (readl(imx->mmio_base + MX3_PWMSAR))
+ /* No rollover irq generated if duty peroid is zero. */
Re: [PATCH] i915: Add module option to support VGA arbiter on HD devices
On Fri, 2014-05-16 at 00:50 +0200, Daniel Vetter wrote: > On Thu, May 15, 2014 at 11:43 PM, Alex Williamson > wrote: > > I don't know what to do with this. It seems like a lot of wishful > > thinking that in the best case would drag on for years. Even if we get > > VGA arbitration out of Xorg, the bit about making the userspace VGA > > arbiter interface lie depending on current->comm sounds tricky and > > horrible. If we can lie to Xorg there, why don't we do that now? If we > > can't lie to Xorg now, then what deprecation event or detection of the > > caller is going to allow us to do so in the future? > > Well we wouldn't necessarily need to lie to X, but could instead look > whether all the vga devices in a system are claimed by kms drivers. If > that's the case the userspace doesn't have an awful lot of business > touching the VGA registers and we could simply not obey a vga arb > request from userspace. > > More advanced would be if we still obey it for those devices not > claimed by kms drivers. So not really a need to key on current->comm. This is a requirement for me, I don't really care about KMS or Xorg, the use case I want to enable is binding a VGA device to vfio-pci so that it can be assigned to a guest virtual machine. This works on an unmodified kernel today so long as you don't have an Intel IGD in your system. If you do, we try to switch the VGA device, but it doesn't actually get switched because i915 opts-out of arbitration yet still claims VGA accesses. > > Meanwhile anyone that wants i915 to participate in arbitration like it > > should have from the start needs to patch their kernel with forward > > ports of the reverted commits. > > > > I just don't see this moving forward, which is why I thought a module > > option at least gives us a workaround. Thanks, > > I know that this is awful, but a module option means that the few > people interested in moving this forward will be happy enough to no > longer bother. Which is even worse from my pov as driver maintainer. I > highly consider module options used in production evil. If I had a solution, I wouldn't be sending this patch :-\ Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > I think having to pick and choose what device nodes you want in a > > container is a good thing. Becides, you would have to do the same thing > > in the kernel anyway, what's wrong with userspace making the decision > > here, especially as it knows exactly what it wants to do much more so > > than the kernel ever can. > > For 'real' devices that sounds sensible. The thing about loop devices > is that we simply want to allow a container to say "give me a loop > device to use" and have it receive a unique loop device (or 3), without > having to pre-assign them. I think that would be cleaner to do using > a pseudofs and loop-control device, rather than having to have a > daemon in userspace on the host farming those out in response to > some, I don't know, dbus request? I agree that loop devices would be nice to have in a container, and that the existing loop interface doesn't really lend itself to that. So create a new type of thing that acts like a loop device in a container. But don't try to mess with the whole driver core just for a single type of device. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
Hey, Mike :) On 05/16/2014 10:51 AM, Mike Galbraith wrote: > On Fri, 2014-05-16 at 10:23 +0800, Michael wang wrote: > >> But we found that one difference when group get deeper is the tasks of >> that group become to gathered on CPU more often, some time all the >> dbench instances was running on the same CPU, this won't happen for l1 >> group, may could explain why dbench could not get CPU more than 100% any >> more. > > Right. I played a little (sane groups), saw load balancing as well. Yeah, now we found that even l2 groups will face the same issue, allow me to re-list the details here: Firstly do workaround (10 times latency): echo 24000 > /proc/sys/kernel/sched_latency_ns echo NO_GENTLE_FAIR_SLEEPERS > /sys/kernel/debug/sched_features This workaround may related to another issue about vruntime bonus for sleeper, but let's put it down currently and focus on the gather issue. Create groups like: mkdir /sys/fs/cgroup/cpu/A mkdir /sys/fs/cgroup/cpu/B mkdir /sys/fs/cgroup/cpu/C mkdir /sys/fs/cgroup/cpu/l1 mkdir /sys/fs/cgroup/cpu/l1/A mkdir /sys/fs/cgroup/cpu/l1/B mkdir /sys/fs/cgroup/cpu/l1/C Run workload like (6 is half of the CPUS on my box): echo $$ > /sys/fs/cgroup/cpu/A/tasks ; dbench 6 echo $$ > /sys/fs/cgroup/cpu/B/tasks ; stress 6 echo $$ > /sys/fs/cgroup/cpu/C/tasks ; stress 6 Check top, each dbench instance got around 45%, totally around 270%, this is close to the case when only dbench running (300%) since we use the workaround, otherwise we will see it to be around 100%, but that's another issue... By sample /proc/sched_debug, rarely see more than 2 dbench instances on same rq. Now re-run workload like: echo $$ > /sys/fs/cgroup/cpu/l1/A/tasks ; dbench 6 echo $$ > /sys/fs/cgroup/cpu/l1/B/tasks ; stress 6 echo $$ > /sys/fs/cgroup/cpu/l1/C/tasks ; stress 6 Check top, each dbench instance got around 20%, totally around 120%, sometime dropped under 100%, and dbench throughput dropped. By sample /proc/sched_debug, frequently see 4 or 5 dbench instances on same rq. So just one level deeper from l1 to l2 and such a big difference, and groups with same shares not equally share the resources... BTW, by bind each dbench instances to different CPU, dbench in l2 groups will regain all the CPU% which is 300%. I'll keep investigation and try to figure out why l2 group's tasks starting to gather, please let me know if there are any suggestions ;-) Regards, Michael Wang > > -Mike > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perfevents: irq loop stuck!
On Thu, 15 May 2014, Peter Zijlstra wrote: > > So, not sure how to fix this without a total re-write, unless we want to > > cheat and just say sample_period is capped at 62-bits or something. > > 63 bits should do I think, but yes, we hit a very similar but a few days > ago in the sched_deadline code. > > I'm fine with capping it, allowing the full 64bit would mean we need 65 > bits (effectively 96 or 128 bit of course) math to make it all work > which would be tedious and give no real gain. Yes, it looks like 63 bits will be fine although I had to think about some of the logic there to make sure there's no signed overflow. > We'll then not make progress for a while, print the msg, get throttled, > goto 1. This is possible if we're allowed 100+ interrupts per jiffy, so > if you adjust /proc/sys/kernel/perf_event_max_sample_rate to below that > and it doesn't trigger anymore we know the throttle works. The odd thing is that even when I try to write a small reproducer I can easily get the overflow of period to 2 to happen, but it doesn't trigger the message. It will on occasion give a throttle message but that is all. The fuzzer can reliably reproduce the actual IRQ warning, but a replay of a gathered trace will not. Even weirder, the even that triggers it is attached to CPU0 but only triggers if the fuzzer itself is running on a different CPU. Also the trigger event has all of exclude_kernel, exclude_user, and exclude_hv set so I'm not sure how it even counts up to the 2 retired instructions to trigger an overflow anyway. It doesn't help that there are 100+ other active events at the time, although suspiciously a few of them are apic_irq tracepoints (though attached to CPUs other than the trouble one). anyway I'm not sure if it's worth tracking this more if it's possible to mostly fix the case by fixing the sample_period bounds. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] sched,numa: decay wakee_flips instead of zeroing
Affine wakeups have the potential to interfere with NUMA placement.
If a task wakes up too many other tasks, affine wakeups will get
disabled.
However, regardless of how many other tasks it wakes up, it gets
re-enabled once a second, potentially interfering with NUMA
placement of other tasks.
By decaying wakee_wakes in half instead of zeroing it, we can avoid
that problem for some workloads.
Signed-off-by: Rik van Riel
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4f01e2f1..0381b11 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4009,7 +4009,7 @@ static void record_wakee(struct task_struct *p)
* about the loss.
*/
if (jiffies > current->wakee_flip_decay_ts + HZ) {
- current->wakee_flips = 0;
+ current->wakee_flips >>= 1;
current->wakee_flip_decay_ts = jiffies;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched/fair: cleanup, clamp values with macros clamp() and max().
Rather than use "if" to check and clamp values to allowed minmum or maxmum, this patch use macros clamp() and max() to clean it up. Signed-off-by: Dongsheng Yang --- kernel/sched/fair.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7570dd9..939a7ab 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2041,10 +2041,7 @@ static long calc_cfs_shares(struct cfs_rq *cfs_rq, struct task_group *tg) if (tg_weight) shares /= tg_weight; - if (shares < MIN_SHARES) - shares = MIN_SHARES; - if (shares > tg->shares) - shares = tg->shares; + shares = clamp(shares, MIN_SHARES, tg->shares); return shares; } @@ -4133,8 +4130,7 @@ static long effective_load(struct task_group *tg, int cpu, long wl, long wg) * those are clipped to [MIN_SHARES, ...) do so now. See * calc_cfs_shares(). */ - if (wl < MIN_SHARES) - wl = MIN_SHARES; + wl = max(wl, MIN_SHARES); /* * wl = dw_i = S * (s'_i - s_i); see (3) -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/6] exynos: cpuidle: do not allow cpuidle registration for Exynos5420
Hi Tomasz, On 16 May 2014 02:56, Tomasz Figa wrote: > Hi Chander, > > On 14.05.2014 10:03, Chander Kashyap wrote: >> Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle >> driver. >> Hence do not allow exynos cpuidle driver registration for Exynos5420. >> >> Signed-off-by: Chander Kashyap >> Signed-off-by: Chander Kashyap >> Acked-by: Daniel Lezcano >> --- >> arch/arm/mach-exynos/cpuidle.c |3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c >> index 3dd385e..807a386 100644 >> --- a/arch/arm/mach-exynos/cpuidle.c >> +++ b/arch/arm/mach-exynos/cpuidle.c >> @@ -218,6 +218,9 @@ static int exynos_cpuidle_probe(struct platform_device >> *pdev) >> int cpu_id, ret; >> struct cpuidle_device *device; >> >> + if (soc_is_exynos5420()) >> + return -ENODEV; >> + >> if (soc_is_exynos5250()) >> exynos5_core_down_clk(); >> >> > > Why not put this in exynos.c in exynos_dt_machine_init(), so > exynos_cpuidle_init() is called only if not running on Exynos5420? > That makes more sense. I will update this Thanks > Best regards, > Tomasz -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/15] PCI/iommu: Fix DMA alias problems
On Fri, 2014-05-16 at 07:45 +0800, Andrew Cooks wrote: > Hi Alex > > On Fri, May 16, 2014 at 1:43 AM, Alex Williamson > wrote: > > On Thu, 2014-05-15 at 07:40 +0800, Andrew Cooks wrote: > >> Hi Alex > >> > >> On Fri, May 9, 2014 at 11:28 PM, Alex Williamson > >> wrote: > >> > > >> > > >> > Original description: > >> > > >> > This series attempts to fix a couple issues we've had outstanding in > >> > the PCI/IOMMU code for a while. The first issue is with devices that > >> > use the wrong requester ID for DMA transactions. We already have a > >> > sort of half-baked attempt to fix this for several Ricoh devices, but > >> > the fix only helps them be useful through IOMMU groups, not the > >> > general DMA case. There are also several Marvell devices which use > >> > use a different wrong requester ID and don't even fit into the DMA > >> > source idea. This series creates a DMA alias iterator that will > >> > step through each possible alias of a device, allowing IOMMUs to > >> > insert mappings for both the device and its aliases. > >> > > >> > Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() > >> > function, which is known to blowup when it finds itself suddenly at > >> > a PCIe device without crossing a PCIe-to-PCI bridge (as identified by > >> > the PCIe capability). It also likes to make the invalid assumption > >> > that a PCIe device never has its requester ID masked by any usptream > >> > bus. We can fix this using the above new DMA alias iterator, since > >> > that's effectively what this function was meant to do. > >> > > >> > >> There are two cases where the DMA requester id seems to use the wrong > >> slot (as opposed to function) in the patch I attached to > >> https://bugzilla.kernel.org/show_bug.cgi?id=42679 > >> The original bug reports are listed in the patch. > >> > >> Unfortunately, I wasn't able to get test feedback on those two cases, > >> but I'm wondering... > >> Did I understand correctly that a slot alias is something that could be > >> needed? > >> If so, is it a variation of the PCIe-to-PCI bridge case that's already > >> covered or will it require a different approach? > > > > Wow, I didn't think that kind of broken was possible. Maybe instead of > > a bitmap of function aliases we could have a single devfn alias for a > > device. That means we'd only be able to support a single alias for a > > device, but since I don't think we've seen devices that use more than a > > single alias, maybe that's ok. > > The current patch creates a context entry for the reported device > (function 0), plus it's alias (function 1). Is there reason to always > add a context entry for the reported devfn and define 'alias' to mean > 'one additional devfn'? That will work for all the Marvell cases. Right, that's effectively what it would become, probably making use of a flag bit to indicate whether the alias devfn is valid. The pci_for_each_dma_alias() would just drop the loop over the dma_alias_funcs bitmap at replace it with a test of the flag and single dma alias devfn. I need to think about whether the IOMMU group code can is such a simple replacement. I think it makes sense to always include both the actual devfn and, if it exists, an alias devfn. Otherwise we'd just end up with more quirks to add later. > In the testing I did, the Marvell controllers needed context entries > for both function 0 and 1. It would be nice if someone could confirm > or debunk this. I tested with a 88SE9172 with both ports of the > controller in use. I think 0 needs to be quirked to 1, but I don't think 1 needs to be quirked to 0. Unfortunately intel-iommu doesn't do any of the reference counting that amd_iommu does, so if we have 0 aliased to 1 and we unbind function 0 from the driver, intel-iommu will also teardown the mapping for function 1. It's horrible. That's a problem beyond what I'm trying to do here though, it already exists if you have two devices behind a PCIe-to-PCI bridge. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: dwc3: gadget: check link trb after free_slot is increased
Hi On Thu, May 15, 2014 at 10:37:57AM -0500, Felipe Balbi wrote: > Hi > > On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: > > In ISOC transfers, when free_slot points to the last TRB (i.e. Link > > TRB), and all queued requests meet Missed Interval Isoc error, busy_slot > > points to trb0. > > busy_slot->trb0 > >trb1 > >... > > free_slot->trb31(Link TRB) > > > > After end transfer and receiving the XferNotReady event, trb_left is > > caculated as 1 which is wrong, and no TRB will be primed to the > > endpoint. > > > > The root cause is free_slot is not increased the same way as busy_slot. > > When busy_slot is increased by one, it checks if points to a link TRB > > after increasement, but free_slot checks it before increasement. > > free_slot should behave the same as busy_slot to make the trb_left > > caculation correct. > > > > Signed-off-by: Zhuang Jin Can > > Signed-off-by: Jiebing Li > > --- > > drivers/usb/dwc3/gadget.c |8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > > index 54da8c8..2ebe82b 100644 > > --- a/drivers/usb/dwc3/gadget.c > > +++ b/drivers/usb/dwc3/gadget.c > > @@ -828,10 +828,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, > > length, last ? " last" : "", > > chain ? " chain" : ""); > > > > - /* Skip the LINK-TRB on ISOC */ > > - if (((dep->free_slot & DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) && > > - usb_endpoint_xfer_isoc(dep->endpoint.desc)) > > - dep->free_slot++; > > > > trb = >trb_pool[dep->free_slot & DWC3_TRB_MASK]; > > I have a feeling this has a negative side effect of letting us use the > link TRB for data transfer... I mean, if we don't increment free_slot > before accessing our trb_pool, we have no way to skip link trb on this > access here. After every free_slot++ Link TRB is checked and increased if appropriate, this guarantees you next time access free_slot, it can't be a Link TRB. > > How did you find the bug ? do you have good instructions on how to > reproduce it ? How did you test the patch and for how long ? The bug is reproduced on Android with f_audio_source.c enabled, which has an isoc-in endpoint keeps sending audio data to host in an interval of 1 ms. Normally, you need to run for 12+ hours to hit the issue. So I think you can just run some isoc transfers for a long time to reproduce it. To accelarte the reproducing, you can run some concurrent data transfer as well, so the possibility to meet missed interval error is larger. The patch is tested for basic functionality like enumeration, data transfers. For this bug, it was tested for 20+ hours. Thanks Jincan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: workqueue: WARN at at kernel/workqueue.c:2176
On 05/15/2014 12:52 AM, Jason J. Herne wrote:
> On 05/12/2014 10:17 PM, Sasha Levin wrote:
>> I don't have an easy way to reproduce it as I only saw the bug once, but
>> it happened when I started pressuring CPU hotplug paths by adding and
>> removing
>> CPUs often. Maybe it has anything to do with that?
>
> As per the original report
> (http://article.gmane.org/gmane.linux.kernel/1643027)
> I am able to reproduce the problem.
>
> The workload is (on S390 architecture):
> 2 processes onlining random cpus in a tight loop by using 'echo 1 >
> /sys/bus/cpu.../online'
> 2 processes offlining random cpus in a tight loop by using 'echo 0 >
> /sys/bus/cpu.../online'
> Otherwise, fairly idle system. load average: 5.82, 6.27, 6.27
>
> The machine has 10 processors.
> The warning message some times hits within a few minutes on starting the
> workload. Other times it takes several hours.
>
>
> -- Jason J. Herne (jjhe...@linux.vnet.ibm.com)
>
>
Hi, Peter and other scheduler Gurus:
When I was trying to test wq-VS-hotplug, I always hit a problem in scheduler
with the following WARNING:
[ 74.765519] WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124
native_smp_send_reschedule+0x2d/0x4b()
[ 74.765520] Modules linked in: wq_hotplug(O) fuse cpufreq_ondemand ipv6
kvm_intel kvm uinput snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_codec_hdmi e1000e snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer ptp iTCO_wdt
iTCO_vendor_support lpc_ich snd mfd_core pps_core soundcore acpi_cpufreq
i2c_i801 microcode wmi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core
[ 74.765545] CPU: 1 PID: 13 Comm: migration/1 Tainted: G O
3.15.0-rc3+ #153
[ 74.765546] Hardware name: LENOVO ThinkCentre M8200T/ , BIOS 5JKT51AUS
11/02/2010
[ 74.765547] 007c 880236199c88 814d7d2c
[ 74.765550] 880236199cc8 8103add4
880236199cb8
[ 74.765552] 81023e1b 8802361861c0 0001
88023fd92b40
[ 74.76] Call Trace:
[ 74.765559] [] dump_stack+0x51/0x75
[ 74.765562] [] warn_slowpath_common+0x81/0x9b
[ 74.765564] [] ? native_smp_send_reschedule+0x2d/0x4b
[ 74.765566] [] warn_slowpath_null+0x1a/0x1c
[ 74.765568] [] native_smp_send_reschedule+0x2d/0x4b
[ 74.765571] [] smp_send_reschedule+0xa/0xc
[ 74.765574] [] resched_task+0x5e/0x62
[ 74.765576] [] check_preempt_curr+0x43/0x77
[ 74.765578] [] __migrate_task+0xda/0x100
[ 74.765580] [] ? __migrate_task+0x100/0x100
[ 74.765582] [] migration_cpu_stop+0x1d/0x22
[ 74.765585] [] cpu_stopper_thread+0x84/0x116
[ 74.765587] [] ? __schedule+0x559/0x581
[ 74.765590] [] ? _raw_spin_lock_irqsave+0x12/0x3c
[ 74.765592] [] ? __smpboot_create_thread+0x109/0x109
[ 74.765594] [] smpboot_thread_fn+0x1d1/0x1d6
[ 74.765598] [] kthread+0xad/0xb5
[ 74.765600] [] ? kthread_freezable_should_stop+0x41/0x41
[ 74.765603] [] ret_from_fork+0x7c/0xb0
[ 74.765605] [] ? kthread_freezable_should_stop+0x41/0x41
[ 74.765607] ---[ end trace 662efb362b4e8ed0 ]---
After debugging, I found the hotlug-in cpu is atctive but !online in this case.
the problem was introduced by 5fbd036b.
Some code assumes that any cpu in cpu_active_mask is also online, but 5fbd036b
breaks
this assumption, so the corresponding code with this assumption should be
changed too.
Hi, Jason J. Herne and Sasha Levin
Thank you for testing wq-VS-hotplug.
The following patch is just a workaround. After it is applied, the above WARNING
is gone, but I can't hit the wq problem that you found.
You can use the following workaround patch to test wq-VS-hotplug again or just
wait the scheduler guys give us a proper patch.
(A interesting thing, 5fbd036b also touches the arch s390).
Thanks,
Lai
---
diff --git a/kernel/cpu.c b/kernel/cpu.c
index a9e710e..253a129 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -726,9 +726,10 @@ void set_cpu_present(unsigned int cpu, bool present)
void set_cpu_online(unsigned int cpu, bool online)
{
- if (online)
+ if (online) {
cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits));
- else
+ cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits));
+ } else
cpumask_clear_cpu(cpu, to_cpumask(cpu_online_bits));
}
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 268a45e..c1a712d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5043,7 +5043,6 @@ static int sched_cpu_active(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
switch (action & ~CPU_TASKS_FROZEN) {
- case CPU_STARTING:
case CPU_DOWN_FAILED:
set_cpu_active((long)hcpu, true);
return NOTIFY_OK;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH v2 0/5] Smart Card(SC) interface, TI USIM & NxP SC phy driver
On 1/30/2014 6:35 PM, Greg KH wrote: On Thu, Jan 30, 2014 at 11:22:48AM +0530, Satish Patel wrote: On 1/20/2014 10:03 AM, Satish Patel wrote: Changes from v1: * RFC(v1) comments are fixed ** removed "gpio_to_irq" as GPIO controller process cell from DT and give it to DT node ** comments on documentation ** few other comments on null checks are resolved * BWT timing configuration is added to ti-usim driver v1 cover letter link# https://lkml.org/lkml/2014/1/6/250 Satish Patel (5): sc_phy:SmartCard(SC) PHY interface to SC controller misc: tda8026: Add NXP TDA8026 PHY driver char: ti-usim: Add driver for USIM module on AM43xx ARM: dts: AM43xx: DT entries added for ti-usim ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy Documentation/devicetree/bindings/misc/tda8026.txt | 19 + .../devicetree/bindings/ti-usim/ti-usim.txt| 31 + Documentation/sc_phy.txt | 171 ++ arch/arm/boot/dts/am4372.dtsi | 10 + arch/arm/boot/dts/am43x-epos-evm.dts | 43 + drivers/char/Kconfig |7 + drivers/char/Makefile |1 + drivers/char/ti-usim-hw.h | 863 + drivers/char/ti-usim.c | 1859 drivers/misc/Kconfig |7 + drivers/misc/Makefile |1 + drivers/misc/tda8026.c | 1255 + include/linux/sc_phy.h | 132 ++ include/linux/ti-usim.h| 98 + 14 files changed, 4497 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt create mode 100644 Documentation/sc_phy.txt create mode 100644 drivers/char/ti-usim-hw.h create mode 100644 drivers/char/ti-usim.c create mode 100644 drivers/misc/tda8026.c create mode 100644 include/linux/sc_phy.h create mode 100644 include/linux/ti-usim.h Any comments on this patch series ? If not, Can you accept these patches for next merge window It's the middle of this merge window, and I can't accept any patches until after 3.14-rc1 is out, at which point I'll start to work on my patch backlog. Are these to be consider for next submission ? Or you want me to start review cycle one more time. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug? Older 32 bit program (CivCTP) no longer works under 64 bit kernel
On Thu, May 15, 2014 at 08:24:05PM -0500, David Hagood wrote:
> I have an old native Linux 32 bit copy of Civilization: Call to Power. It
> used to work under a 64 bit environment back in the 3.0.x days. However,
> under recent versions (>3.5) it no longer runs - it complains that it cannot
> find certain files in the directory. The exact same code will run just fine
> under a 32 bit version of 3.11. I have a Pentium II as well as the Core 2
> Duo, both running Ubuntu 14.04, same version of the kernel other than one is
> 32 bit and one is 64 bit. I've copied the files over from the 32 bit
> machine, where it runs, to the 64 bit machine, where it does not. I've even
> gone so far as to copy all the system 32 bit libraries into the CivCTP
> directory, and forced the program to use them (including using the
> ld-linux.so loader from that directory) - so in theory it's all the same
> user space libraries running - the only difference that I can see is that
> one kernel is 64 bit and one is 32 bit.
>
> Running strace on the program shows that the directories being searched for
> game assets are corrupted:
>
> 16218 stat64("/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt",
>
>
> Note the "englisish" rather than "english".
>
> I'm looking for any suggestions on where to look for what might cause such
> an issue - what can I do to start tracking this down.
I've no ideas about what part of the kernel is causing this, so
I'll just offer you some thoughts on how to track it down. At a
guess, you will have to run 'git bisect' to nail which change broke
this (or alternatively which change exposed a latent problem).
Bisection is fairly well covered on google, for example it finds
http://landley.net/writing/git-bisect-howto.html
The corrupt filename looks (to me, with no experience) like
something which might be in the filesystem area. It probably isn't,
but I don't recall anything at all like this, so I'd better ask - are
you using an uncommon filesystem for this data ? This looks like
such a grievous fault that I would expect someone to have noticed it
between 3.5.0 and now.
And, have you tried any recent kernels (e.g. 3.14.4) to confirm
that the problem still exists ? If it turns out that somebody
already fixed it, that would save you a lot of effort.
You will need a network connection to clone linus' tree, and some
space for it. And git, of course. To bisect, you should build in
the git tree, AND set CONFIG_LOCALVERSION_AUTO - in
General setup
[ ] Automatically append version information to the version
so that the kernel version, and the version in /lib/modules, will
add -X-g information to each non-release install - that
is useful when you are bisecting, so that each set of modules is
kept separate. See e.g.
http://yarchive.net/comp/linux/CONFIG_LOCALVERSION_AUTO.html
It might speed this up if you can minimise the kernel config
(distros tend to build the whole kitchen sink as modules) - the
fewer unnecessary things you build, the less time it takes.
Does it work on 3.4.0 ? I know 3.4 is supported, and therefore
there are continuing releases with backported fixes, but for
bisection it is easiest to start testing with .0 releases. If it
doesn't work there (I'm unclear if 3.5 was the earliest post-3.0
kernel that you tried), find which was the last .0 kernel where it
worked. You can then label that version as "good", e.g.
git bisect good v3.4 [ or whichever version - without the .0 ].
Once you are certain which .0 version was the last which worked,
the next can be marked as bad, e.g. v3.5 - and then you bisect.
Do not be surprised if the kernel identifies itself as an earlier
version than the last good one - see Linus's post referenced at
yarchive.net above. And good luck, bisection is usually tedious.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: at91: remove ISI code for AT91SAM9263
Hi, Paul
On 5/15/2014 4:34 PM, Paul Bolle wrote:
In v2.6.25 code was added for an Image Sensor Interface (ISI) for
AT91SAM9263. That code depended on the Kconfig macro
CONFIG_VIDEO_AT91_ISI and its MODULE variant. The related Kconfig symbol
has never been added to the tree. The net effect of this was that
at91_add_device_isi() was a NOP. No one noticed because no callers of
that function were added to the tree at that time.
The first caller of a function with that name was added in v3.4. But
that caller apparently only called the function defined for AT91SAM9G45.
(that function was also added in v3.4). So even then AT91SAM9263's NOP
version of at91_add_device_isi() remained unused. This means that the
ISI code for AT91SAM9263 can be removed.
Signed-off-by: Paul Bolle
---
Untested!
Could someone please verify that this definition of
at91_add_device_isi() really never will be called.
Right. There is no implement to support for at91sam9263 ISI. So in
at91sam9263ek it will not call at91_add_device_isi().
Current ISI driver only support at91sam9g45 and later chips.
Acked-by: Josh Wu
Best Regards,
Josh Wu
arch/arm/mach-at91/at91sam9263_devices.c | 57
1 file changed, 57 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c
b/arch/arm/mach-at91/at91sam9263_devices.c
index 43d53d6156dd..f2dab0a872a1 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -897,63 +897,6 @@ void __init at91_add_device_lcdc(struct atmel_lcdfb_pdata
*data) {}
/*
- * Image Sensor Interface
- * */
-
-#if defined(CONFIG_VIDEO_AT91_ISI) || defined(CONFIG_VIDEO_AT91_ISI_MODULE)
-
-struct resource isi_resources[] = {
- [0] = {
- .start = AT91SAM9263_BASE_ISI,
- .end= AT91SAM9263_BASE_ISI + SZ_16K - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
- .end= NR_IRQS_LEGACY + AT91SAM9263_ID_ISI,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device at91sam9263_isi_device = {
- .name = "at91_isi",
- .id = -1,
- .resource = isi_resources,
- .num_resources = ARRAY_SIZE(isi_resources),
-};
-
-void __init at91_add_device_isi(struct isi_platform_data *data,
- bool use_pck_as_mck)
-{
- at91_set_A_periph(AT91_PIN_PE0, 0); /* ISI_D0 */
- at91_set_A_periph(AT91_PIN_PE1, 0); /* ISI_D1 */
- at91_set_A_periph(AT91_PIN_PE2, 0); /* ISI_D2 */
- at91_set_A_periph(AT91_PIN_PE3, 0); /* ISI_D3 */
- at91_set_A_periph(AT91_PIN_PE4, 0); /* ISI_D4 */
- at91_set_A_periph(AT91_PIN_PE5, 0); /* ISI_D5 */
- at91_set_A_periph(AT91_PIN_PE6, 0); /* ISI_D6 */
- at91_set_A_periph(AT91_PIN_PE7, 0); /* ISI_D7 */
- at91_set_A_periph(AT91_PIN_PE8, 0); /* ISI_PCK */
- at91_set_A_periph(AT91_PIN_PE9, 0); /* ISI_HSYNC */
- at91_set_A_periph(AT91_PIN_PE10, 0);/* ISI_VSYNC */
- at91_set_B_periph(AT91_PIN_PE12, 0);/* ISI_PD8 */
- at91_set_B_periph(AT91_PIN_PE13, 0);/* ISI_PD9 */
- at91_set_B_periph(AT91_PIN_PE14, 0);/* ISI_PD10 */
- at91_set_B_periph(AT91_PIN_PE15, 0);/* ISI_PD11 */
-
- if (use_pck_as_mck) {
- at91_set_B_periph(AT91_PIN_PE11, 0);/* ISI_MCK (PCK3) */
-
- /* TODO: register the PCK for ISI_MCK and set its parent */
- }
-}
-#else
-void __init at91_add_device_isi(struct isi_platform_data *data,
- bool use_pck_as_mck) {}
-#endif
-
-
-/*
* Timer/Counter block
* */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: phy: Don't call phy_resume if phy_init_hw failed
From: Guenter Roeck Date: Wed, 14 May 2014 13:12:49 -0700 > After the call to phy_init_hw failed in phy_attach_direct, phy_detach is > called > to detach the phy device from its network device. If the attached driver is a > generic phy driver, this also detaches the driver. Subsequently phy_resume > is called, which assumes without checking that a driver is attached to the > device. This will result in a crash such as > > Unable to handle kernel paging request for data at address 0xff90 > Faulting instruction address: 0xc03a0e18 > Oops: Kernel access of bad area, sig: 11 [#1] > ... > NIP [c03a0e18] .phy_attach_direct+0x68/0x17c > LR [c03a0e6c] .phy_attach_direct+0xbc/0x17c > Call Trace: > [c003fc0475d0] [c03a0e6c] .phy_attach_direct+0xbc/0x17c > (unreliable) > [c003fc047670] [c03a0ff8] .phy_connect_direct+0x28/0x98 > [c003fc047700] [c03f0074] .of_phy_connect+0x4c/0xa4 > > Only call phy_resume if phy_init_hw was successful. > > Signed-off-by: Guenter Roeck Applied and queued up for -stable, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] of: Make of_find_node_by_path() handle /aliases
On 5/13/2014 7:58 AM, Grant Likely wrote:
> Make of_find_node_by_path() handle aliases as prefixes. To make this
> work the name search is refactored to search by path component instead
> of by full string. This should be a more efficient search, and it makes
> it possible to start a search at a subnode of a tree.
>
> Signed-off-by: David Daney
> Signed-off-by: Pantelis Antoniou
> [grant.likely: Rework to not require allocating at runtime]
> Acked-by: Rob Herring
> Signed-off-by: Grant Likely
> ---
> drivers/of/base.c | 60
> +++
> 1 file changed, 56 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 6e240698353b..60089b9a3014 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -771,9 +771,38 @@ struct device_node *of_get_child_by_name(const struct
> device_node *node,
> }
> EXPORT_SYMBOL(of_get_child_by_name);
>
> +static struct device_node *__of_find_node_by_path(struct device_node *parent,
> + const char *path)
> +{
> + struct device_node *child;
> + int len = strchrnul(path, '/') - path;
> +
> + if (!len)
> + return parent;
(!len) is true if the the final character of the path passed into
of_find_node_by_path()
was "/". Strictly speaking, ->full_name will never end with "/", so the return
value
should be NULL, indicating that the match fails.
> +
> + for_each_child_of_node(parent, child) {
> + const char *name = strrchr(child->full_name, '/');
> + if (WARN(!name, "malformed device_node %s\n", child->full_name))
> + continue;
> + name++;
Why go to the effort of finding the final component of child->full_name instead
of just using child->name?
> + if (strncmp(path, name, len) == 0 && (strlen(name) == len))
> + return child;
> + }
> + return NULL;
> +}
> +
> /**
> * of_find_node_by_path - Find a node matching a full OF path
> * @path: The full path to match
> + * @path: Either the full path to match, or if the path does not
Delete the old @path description.
> + * start with '/', the name of a property of the /aliases
> + * node (an alias). In the case of an alias, the node
> + * matching the alias' value will be returned.
> + *
> + * Valid paths:
> + * /foo/barFull path
> + * foo Valid alias
> + * foo/bar Valid alias + relative path
> *
> * Returns a node pointer with refcount incremented, use
> * of_node_put() on it when done.
> @@ -781,13 +810,36 @@ EXPORT_SYMBOL(of_get_child_by_name);
> struct device_node *of_find_node_by_path(const char *path)
> {
> struct device_node *np = of_allnodes;
> + struct property *pp;
> unsigned long flags;
>
> + /* The path could begin with an alias */
> + if (*path != '/') {
> + char *p = strchrnul(path, '/');
> + int len = p - path;
> +
> + /* of_aliases must not be NULL */
> + if (!of_aliases)
> + return NULL;
> +
> + np = NULL;
> + for_each_property_of_node(of_aliases, pp) {
> + if (strlen(pp->name) == len && !strncmp(pp->name, path,
> len)) {
> + np = of_find_node_by_path(pp->value);
> + break;
> + }
> + }
> + if (!np)
> + return NULL;
> + path = p;
> + }
> +
> + /* Step down the tree matching path components */
> raw_spin_lock_irqsave(_lock, flags);
> - for (; np; np = np->allnext) {
> - if (np->full_name && (of_node_cmp(np->full_name, path) == 0)
> - && of_node_get(np))
> - break;
> + while (np && *path == '/') {
> + path++; /* Increment past '/' delimiter */
> + np = __of_find_node_by_path(np, path);
> + path = strchrnul(path, '/');
> }
> raw_spin_unlock_irqrestore(_lock, flags);
> return np;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
On Fri, 2014-05-16 at 10:23 +0800, Michael wang wrote: > But we found that one difference when group get deeper is the tasks of > that group become to gathered on CPU more often, some time all the > dbench instances was running on the same CPU, this won't happen for l1 > group, may could explain why dbench could not get CPU more than 100% any > more. Right. I played a little (sane groups), saw load balancing as well. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/5] pci: designware: enhancements to support keystone pcie
On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote:
>
> keystone pcie hardware is based on designware hw version 3.65.
> There is no support for ATU port and has registers in
> application space to configure inbound/outbound access. Also
> doesn't support PCI PVM option. The MSI IRQ registers available
> in application space is used to mask/unmask/enable the MSI IRQs.
>
> DW core driver is a set of common functions that are abstracted
> to support DW pci drivers. To allow re-use of these functions for
> keystone pci driver, core driver is to be enhanced.
>
> Following are done to allow re-use of the functions on keystone pci
> driver.
>
> 1. Some of the variables in pcie_port struct is folded inside
> a union that now contains both new DW hw related variables as well
> as old hardware related variables such as application reg base.
> 2. Added a dw_pcie_common_host_init() function that holds common
> host initialization code for old and new hw.
> 3. dw_pcie_parse_resource() is used for parsing resource related
> information from DT bindings.
> 4. dw_pcie_host_init() is called by new DW hw drivers as before.
> Added dw_old_pcie_host_init() is it's counter part on old dw hw.
> Both these functions now call dw_pcie_common_host_init().
> 5. Some of the static functions are made global to allow use from
> dw old pci drivers such as pci-keystone.
>
> CC: Mohit Kumar
> CC: Jingoo Han
> CC: Bjorn Helgaas
> CC: Santosh Shilimkar
>
> Signed-off-by: Murali Karicheri
> ---
> drivers/pci/host/pcie-designware.c | 101
>
> drivers/pci/host/pcie-designware.h | 42 ---
> 2 files changed, 103 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> index c4e3732..9ea8e79 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -277,11 +277,15 @@ static int assign_irq(int no_irqs, struct msi_desc
> *desc, int *pos)
> }
> set_bit(pos0 + i, pp->msi_irq_in_use);
> /*Enable corresponding interrupt in MSI interrupt controller */
> - res = ((pos0 + i) / 32) * 12;
> - bit = (pos0 + i) % 32;
> - dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, );
> - val |= 1 << bit;
> - dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val);
> + if (!(pp->version & DW_VERSION_OLD)) {
(+cc Pratyush Anand, Richard Zhu, Kishon Vijay Abraham I, Marek Vasut)
DW_VERSION_OLD?
I don't this name. What is OLD? It is too general.
There should be the proper feature name between your 3.65 version
and other newer versions. This feature name can be defined as DT
property. Also, this code should be selected by DT property.
> + res = ((pos0 + i) / 32) * 12;
> + bit = (pos0 + i) % 32;
> + dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
> + 4, );
> + val |= 1 << bit;
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
> + 4, val);
> + }
> }
>
> *pos = pos0;
> @@ -349,7 +353,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip,
> struct pci_dev *pdev,
>*/
> desc->msi_attrib.multiple = msgvec;
>
> - msg.address_lo = virt_to_phys((void *)pp->msi_data);
> + if (pp->ops->get_msi_data)
> + msg.address_lo = pp->ops->get_msi_data(pp);
> + else
> + msg.address_lo = virt_to_phys((void *)pp->msi_data);
> msg.address_hi = 0x0;
> msg.data = pos;
> write_msi_msg(irq, );
> @@ -389,13 +396,11 @@ static const struct irq_domain_ops msi_domain_ops = {
> .map = dw_pcie_msi_map,
> };
>
> -int __init dw_pcie_host_init(struct pcie_port *pp)
> +int __init dw_pcie_parse_resource(struct pcie_port *pp)
> {
> struct device_node *np = pp->dev->of_node;
> - struct of_pci_range range;
> struct of_pci_range_parser parser;
> - u32 val;
> - int i;
> + struct of_pci_range range;
>
> if (of_pci_range_parser_init(, np)) {
> dev_err(pp->dev, "missing ranges property\n");
> @@ -440,23 +445,17 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> return -ENOMEM;
> }
> }
> -
> - pp->cfg0_base = pp->cfg.start;
> - pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
> pp->mem_base = pp->mem.start;
>
> - pp->va_cfg0_base = devm_ioremap(pp->dev, pp->cfg0_base,
> - pp->config.cfg0_size);
> - if (!pp->va_cfg0_base) {
> - dev_err(pp->dev, "error with ioremap in function\n");
> - return -ENOMEM;
> - }
> - pp->va_cfg1_base = devm_ioremap(pp->dev, pp->cfg1_base,
> -
[PATCH 1/1] mem-hotplug: Avoid illegal state prefixed with legal state when changing state of memory_block.
We use the following command to online a memory_block:
echo online|online_kernel|online_movable >
/sys/devices/system/memory/memoryXXX/state
But, if we typed "online_movbale" by mistake (typo, not "online_movable"), it
will be
recognized as "online", and it will online the memory block successfully.
"online" command
will put the memory block into the same zone as it was in before last offlined,
which may
be ZONE_NORMAL, not ZONE_MOVABLE. Since it succeeds without any warning, it may
confuse
users.
Furthermore, if we do the following:
echo online_fhsjkghfkd > /sys/devices/system/memory/memoryXXX/state
the block will also be onlined.
echo offline_ohjkjewrj > /sys/devices/system/memory/memoryXXX/state
the block will also be offlined.
This is because the following code in store_mem_state() does not compare the
whole string,
but only the prefix of the string.
store_mem_state()
{
..
328 if (!strncmp(buf, "online_kernel", min_t(int, count, 13)))
Here, only compare the first 13 letters of the string. If we give
"online_kernelXX",
it will be recognized as online_kernel, which is incorrect.
329 online_type = ONLINE_KERNEL;
330 else if (!strncmp(buf, "online_movable", min_t(int, count, 14)))
We have the same problem here,
331 online_type = ONLINE_MOVABLE;
332 else if (!strncmp(buf, "online", min_t(int, count, 6)))
here,
(Here is more problematic. If we give online_movalbe, which is a typo of
online_movable,
it will be recognized as online without noticing the author.)
333 online_type = ONLINE_KEEP;
334 else if (!strncmp(buf, "offline", min_t(int, count, 7)))
and here.
335 online_type = -1;
336 else {
337 ret = -EINVAL;
338 goto err;
339 }
..
}
This patch fix this problem by checking if the length of the string is
6,7,13,14, and then
compare the whole string.
And in store_mem_state(), the parameter count passed from user space includes
'\0' in the
end of the string, so the real length of the string is count-1.
Reported-by: Hu Tao
Signed-off-by: Tang Chen
---
drivers/base/memory.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bece691..3ff2adb 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -319,19 +319,27 @@ store_mem_state(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct memory_block *mem = to_memory_block(dev);
- int ret, online_type;
+ int ret, online_type, len;
ret = lock_device_hotplug_sysfs();
if (ret)
return ret;
- if (!strncmp(buf, "online_kernel", min_t(int, count, 13)))
+ /*
+* count passed from user space includes \0, so the real length
+* is count-1.
+*/
+ len = count - 1;
+
+ if (len == strlen("online_kernel") &&
+ !strncmp(buf, "online_kernel", len))
online_type = ONLINE_KERNEL;
- else if (!strncmp(buf, "online_movable", min_t(int, count, 14)))
+ else if (len == strlen("online_movable") &&
+!strncmp(buf, "online_movable", len))
online_type = ONLINE_MOVABLE;
- else if (!strncmp(buf, "online", min_t(int, count, 6)))
+ else if (len == strlen("online") && !strncmp(buf, "online", len))
online_type = ONLINE_KEEP;
- else if (!strncmp(buf, "offline", min_t(int, count, 7)))
+ else if (len == strlen("offline") && !strncmp(buf, "offline", len))
online_type = -1;
else {
ret = -EINVAL;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
On 05/15/2014 07:57 PM, Peter Zijlstra wrote: [snip] >> >> It's like: >> >> /cgroup/cpu/l1/l2/l3/l4/l5/l6/A >> >> about level 7, the issue can not be solved any more. > > That's pretty retarded and yeah, that's way past the point where things > make sense. You might be lucky and have l1-5 as empty/pointless > hierarchy so the effective depth is less and then things will work, but > *shees*.. Exactly, that's the simulation of cgroup topology setup by libvirt, really doesn't make sense... rather torture than deployment, but they do make things like that... > [snip] >> I'm not sure which account will turns to be huge when group get deeper, >> the load accumulation will suffer discount when passing up, isn't it? >> > > It'll use 20 bits for precision instead of 10, so it gives a little more > 'room' for deeper hierarchies/big cpu-count. Got it :) > > All assuming you're running 64bit kernels of course. Yes, it's 64bit, I tried the testing with this feature on, seems like haven't address the issue... But we found that one difference when group get deeper is the tasks of that group become to gathered on CPU more often, some time all the dbench instances was running on the same CPU, this won't happen for l1 group, may could explain why dbench could not get CPU more than 100% any more. But why the gather happen when group get deeper is unclear... will try to make it out :) Regards, Michael Wang > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xfs: fixes for 3.15-rc6
Hi Linus, Can you please pull the updates listed below? I found a bunch of error sign issues while determine what we need to do to rid XFS of this problem permanently. A couple of the bugs are in data integirty operations, a couple more are in the new COLLAPSE_RANGE code. One of these came in through a recent ext4 merge and so I had to update the base tree to 3.15-rc5 before fixing the issues. -Dave. The following changes since commit d6d211db37e75de2ddc3a4f979038c40df7cc79c: Linux 3.15-rc5 (2014-05-09 13:10:52 -0700) are available in the git repository at: git://oss.sgi.com/xfs/xfs.git tags/xfs-for-linus-3.15-rc6 for you to fetch changes up to ee4eec478be4677b93775d17bc079efb5922b276: xfs: list_lru_init returns a negative error (2014-05-15 09:23:24 +1000) xfs: fixes for 3.15-rc6 Code inspection of the XFS error number sign translations found a bunch of issues, including returning incorrectly signed errors for some data integrity operations. These leak to userspace and result in applications not getting the errors correctly reported. Hence they need fixing sooner rather than later. Dave Chinner (9): xfs: xfs_dir_fsync() returns positive errno xfs: fix incorrect error sign in xfs_file_aio_read xfs: xfs_commit_metadata returns wrong errno xfs: correct error sign on COLLAPSE_RANGE errors xfs: fix wrong errno from xfs_initxattrs xfs: fix wrong err sign on xfs_set_acl() xfs: negate mount workqueue init error value xfs: negate xfs_icsb_init_counters error value xfs: list_lru_init returns a negative error fs/xfs/xfs_export.c |2 +- fs/xfs/xfs_file.c |8 fs/xfs/xfs_iops.c | 12 ++-- fs/xfs/xfs_qm.c | 26 ++ fs/xfs/xfs_super.c |4 ++-- 5 files changed, 27 insertions(+), 25 deletions(-) -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got conflicts in
drivers/net/ethernet/altera/altera_msgdma.c and
drivers/net/ethernet/altera/altera_sgdma.c between commit 898305806ad5
("Altera TSE: Fix sparse errors and warnings") from the net tree and
commit d42f157b3498 ("Altera TSE: Remove unnecessary cast of void
pointers") from the net-next tree.
I fixed it up (mostly the former removed lines updated by the latter,
but see below) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/ethernet/altera/altera_sgdma.c
index 99cc56f451cf,dbd40e15b5cc..
--- a/drivers/net/ethernet/altera/altera_sgdma.c
+++ b/drivers/net/ethernet/altera/altera_sgdma.c
@@@ -179,11 -184,11 +179,10 @@@ void sgdma_clear_txirq(struct altera_ts
*/
int sgdma_tx_buffer(struct altera_tse_private *priv, struct tse_buffer
*buffer)
{
- struct sgdma_descrip __iomem *descbase =
- (struct sgdma_descrip __iomem *)priv->tx_dma_desc;
- int pktstx = 0;
- struct sgdma_descrip *descbase = priv->tx_dma_desc;
++ struct sgdma_descrip __iomem *descbase = priv->tx_dma_desc;
- struct sgdma_descrip *cdesc = [0];
- struct sgdma_descrip *ndesc = [1];
+ struct sgdma_descrip __iomem *cdesc = [0];
+ struct sgdma_descrip __iomem *ndesc = [1];
/* wait 'til the tx sgdma is ready for the next transmit request */
if (sgdma_txbusy(priv))
@@@ -240,13 -245,16 +239,12 @@@ void sgdma_add_rx_desc(struct altera_ts
*/
u32 sgdma_rx_status(struct altera_tse_private *priv)
{
- struct sgdma_descrip __iomem *base =
- (struct sgdma_descrip __iomem *)priv->rx_dma_desc;
- struct sgdma_csr *csr = priv->rx_dma_csr;
- struct sgdma_descrip *base = priv->rx_dma_desc;
- struct sgdma_descrip *desc = NULL;
- int pktsrx;
- unsigned int rxstatus = 0;
- unsigned int pktlength = 0;
- unsigned int pktstatus = 0;
++ struct sgdma_descrip __iomem *base = priv->rx_dma_desc;
+ struct sgdma_descrip __iomem *desc = NULL;
struct tse_buffer *rxbuffer = NULL;
+ unsigned int rxstatus = 0;
- u32 sts = ioread32(>status);
+ u32 sts = csrrd32(priv->rx_dma_csr, sgdma_csroffs(status));
desc = [0];
if (sts & SGDMA_STSREG_EOP) {
@@@ -348,11 -350,10 +346,10 @@@ static void sgdma_setup_descrip(struct
*/
static int sgdma_async_read(struct altera_tse_private *priv)
{
- struct sgdma_descrip __iomem *descbase =
- (struct sgdma_descrip __iomem *)priv->rx_dma_desc;
- struct sgdma_csr *csr = priv->rx_dma_csr;
- struct sgdma_descrip *descbase = priv->rx_dma_desc;
- struct sgdma_descrip *cdesc = [0];
- struct sgdma_descrip *ndesc = [1];
++ struct sgdma_descrip __iomem *descbase = priv->rx_dma_desc;
+
+ struct sgdma_descrip __iomem *cdesc = [0];
+ struct sgdma_descrip __iomem *ndesc = [1];
struct tse_buffer *rxbuffer = NULL;
signature.asc
Description: PGP signature
RE: [RESEND PATCH V1] regulator: DA9211 : new regulator driver
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, May 15, 2014 5:20 AM
> To: Opensource [James Seong-Won Ban]
> Cc: Liam Girdwood; Support Opensource; LKML; Guennadi Liakhovetski;
> David Dajun Chen
> Subject: Re: [RESEND PATCH V1] regulator: DA9211 : new regulator driver
>
> On Wed, May 14, 2014 at 04:02:34AM +0100, James Ban wrote:
> > This is the driver for the Dialog DA9211 Multi-phase 12A DC-DC Buck
> > Converter regulator. It communicates via an I2C bus to the device.
>
> This looks a lot like the DA9210 driver, is there really no opportunity for
> code
> sharing here?
>
DA9210 has only one buck. But DA9211 has two buck configuration.
And the register map is different between two driver.
So it is not possible to share the code.
> > + /*
> > +* There are two voltage register set A & B for voltage ramping but
> > +* either one of then can be active therefore we first determine
> > +* the active register set.
> > +*/
>
> I see this but...
>
> > + /* Select register set B for suspend voltage ramping. */
> > + if (regulator->reg_rselect == DA9211_RSEL_NO_GPIO) {
> > + ret = regmap_update_bits(chip->regmap, info->conf.reg,
> > + info->conf.sel_mask,
> > + DA9211_VBUCKA_SEL_B);
> > + if (ret < 0)
> > + return ret;
> > + }
>
> ..this fairly clearly says that suspend mode is set B and normal mode is set
> A.
>
This is a case with no gpio configuration.
If gpio is configured, the active voltage A/B will be controlled by gpio.
Function da9211_regulator_get/set_voltage_sel is designed for covering both
cases.
> > +static int da9211_suspend_enable(struct regulator_dev *rdev) {
> > + struct da9211_regulator *regulator = rdev_get_drvdata(rdev);
> > + struct da9211_regulator_info *info = regulator->info;
> > + struct da9211 *chip = regulator->da9211;
> > +
> > + /* Select register set B for voltage ramping. */
> > + if (regulator->reg_rselect == DA9211_RSEL_NO_GPIO)
> > + return regmap_update_bits(chip->regmap, info->conf.reg,
> > + info->conf.sel_mask,
> > + DA9211_VBUCKA_SEL_B);
> > + else
> > + return 0;
> > +}
>
> This looks like it will immediately shift to the suspend voltage but what this
> should do is set the voltage which will be set in suspend mode - something
> else (usually a hardware signal during suspend) should actually enter it.
>
The output voltage A/B of DA9211 could be selected by a hardware signal or
register.
So if there is no gpio configuration, B voltage channel should be selected
during suspend mode.
If user wants to stay same voltage level at suspend mode in case of no gpio
configuration,
user must set same voltage level at A/B register.
> > +int da9211_enable_irq(struct da9211 *chip, int irq) {
> > + enable_irq(irq);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(da9211_enable_irq);
>
> > +int da9211_disable_irq(struct da9211 *chip, int irq) int
> > +da9211_mask_irq(struct da9211 *chip, int irq) int
> > +da9211_unmask_irq(struct da9211 *chip, int irq)
>
> This looks bad... similarly most of the rest of the interrupt code.
> What is it supposed to be doing?
Originally it is supposed for user to enable/disable various interrupt signal.
But indeed it seems a redundant code. The code will be reorganized and
submitted again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Quoting Greg Kroah-Hartman (gre...@linuxfoundation.org):
> On Thu, May 15, 2014 at 05:42:54PM +, Serge Hallyn wrote:
> > What exactly defines '"normal" use case for a container'?
>
> Well, I'd say "acting like a virtual machine" is a good start :)
>
> > Not too long ago much of what we can now do with network namespaces
> > was not a normal container use case. Neither "you can't do it now"
> > nor "I don't use it like that" should be grounds for a pre-emptive
> > nack. "It will horribly break security assumptions" certainly would
> > be.
>
> I agree, and maybe we will get there over time, but this patch is nto
> the way to do that.
Ok. [ I/we may be asking for more details later, but think there is enough
below :), particularly the point about event forwarding ] Thanks.
> > That's not to say there might not be good reasons why this in particular
> > is not appropriate, but ISTM if things are going to be nacked without
> > consideration of the patchset itself, we ought to be having a ksummit
> > session to come to a consensus [ or receive a decree, presumably by you :)
> > but after we have a chance to make our case ] on what things are going to
> > be un/acceptable.
>
> I already stood up and publically said this last year at Plumbers, why
> is anything now different?
Well I've simply never had a chance to talk to you since then to find out
exactly what it is that is unacceptable, and why. And, of course, code
makes it easier to discuss these things.
> And this patchset is proof of why it's not a good idea. You really
> didn't do anything with all of the namespace stuff, except change loop.
> That's the only thing that cares, so, just do it there, like I said to
> do so, last August.
Sorry, just do it where?
> And you are ignoring the notifications to userspace and how namespaces
> here would deal with that.
Good point. Addressing that is at the same time necessary, interesting,
and complicated.
> > > > Serge mentioned something to me about a loopdevfs (?) thing that someone
> > > > else is working on. That would seem to be a better solution in this
> > > > particular case but I don't know much about it or where it's at.
> > >
> > > Ok, let's see those patches then.
> >
> > I think Seth has a git tree ready, but not sure which branch he'd want
> > us to look at.
> >
> > Splitting a namespaced devtmpfs from loopdevfs discussion might be
> > sensible. However, in defense of a namespaced devtmpfs I'd say
> > that for userspace to, at every container startup, bind-mount in
> > devices from the global devtmpfs into a private tmpfs (for systemd's
> > sake it can't just be on the container rootfs), seems like something
> > worth avoiding.
>
> I think having to pick and choose what device nodes you want in a
> container is a good thing. Becides, you would have to do the same thing
> in the kernel anyway, what's wrong with userspace making the decision
> here, especially as it knows exactly what it wants to do much more so
> than the kernel ever can.
For 'real' devices that sounds sensible. The thing about loop devices
is that we simply want to allow a container to say "give me a loop
device to use" and have it receive a unique loop device (or 3), without
having to pre-assign them. I think that would be cleaner to do using
a pseudofs and loop-control device, rather than having to have a
daemon in userspace on the host farming those out in response to
some, I don't know, dbus request?
> > PS - Apparently both parallels and Michael independently
> > project devices which are hot-plugged on the host into containers.
> > That also seems like something worth talking about (best practices,
> > shortcomings, use cases not met by it, any ways tha the kernel can
> > help out) at ksummit/linuxcon.
>
> I was told that containers would never want devices hotplugged into
> them. What use case has this happening / needed?
I'm pretty sure I didn't say that . But I guess
we are combining two topics here, the loop psuedofs and the namespaced
devtmpfs.
The use case of loop-control device and loop pseudofs is to have
multiple chrooted/namespaced programs be able to grab a loop device
on demand which they can use for the obvious things (building a livecd,
extracting file contents, etc) without stepping on each other's toes. The
namespaced devtmpfs is not required for this.
One advantage of a namespaced devtmpfs would be sane-looking devices
in unprivileged containers. Currently we have to bind-mount the host's
/dev/{full,zero,etc} which, due to uid and guid mappings, then shows up
as:
crw-rw-rw- 1 nobody nogroup 1, 7 May 12 13:35 full
Also you mentioned uevent forwarding above. Michael has talked several
times about having userspace on the host 'pass' devices into the
container. One thing which I believe he and Eric have discussed
before was how to have userspace in the container be notified when
a device is passed in. It seems to me that at least this is something
that would be
Re: [PATCHv2] ARM: ioremap: Fix static vm area boundary checking.
On Fri, May 16, 2014 at 1:28 AM, Nicolas Pitre wrote:
> On Thu, 15 May 2014, Richard Lee wrote:
>
>> Static vm area boundary check:
>>
>> paddr1 --->| |
>> | |
>> |---| <-\--- svm->vm->addr(is page aligned)
>> paddr2 --->| ||
>> | --| <--|-- svm->vm->phys_addr
>> | ||
>> paddr3 --->| ||
>> | ||
>> |---| <--|-- next page boundary
>> | ||
>> paddr4 --->| || <- svm->vm->size(including guard page)
>> | ||
>> | ||
>> max paddr_end -->|---| <--|-- svm->vm's phys_addr_end
>> | / ||
>> paddr5 --->| guard ||
>> | page ||
>> | / ||
>> --- <-/--- svm->vm->addr + svm->vm_size
>>
>> <1> If the paddr == paddr1, then continue;
>> <2> If the paddr == paddr2~paddr4 and paddr_end > phys_addr_end,
>> then continue;
>> <3> if the paddr >= paddr5 then continue;
>>
>> Signed-off-by: Richard Lee
>
> instead of doing this repeatedly, why not simply ensure the recorded
> static vm information is already page aligned in the first place?
>
Sorry, I'm not very sure what vm information you meant here.
And the 'svm->vm->addr' and 'svm->vm->size' are all page aligned
already, but we cannot make sure that the 'paddr' and
'svm->vm->phys_addr' are page aligned.
Thanks,
BRs
Richard Lee
>
>
>> ---
>>
>>
>> Change in V2:
>> - PAGE_SIZE --> PAGE_MASK
>> - remove the 'size' page size align operation.
>>
>>
>>
>>
>>
>>
>> arch/arm/mm/ioremap.c | 40 ++--
>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
>> index be69333..f235ab7 100644
>> --- a/arch/arm/mm/ioremap.c
>> +++ b/arch/arm/mm/ioremap.c
>> @@ -47,16 +47,52 @@ static struct static_vm
>> *find_static_vm_paddr(phys_addr_t paddr,
>> {
>> struct static_vm *svm;
>> struct vm_struct *vm;
>> + size_t offset;
>> +
>> + offset = paddr & ~PAGE_MASK;
>>
>> list_for_each_entry(svm, _vmlist, list) {
>> + phys_addr_t paddr_end, phys_addr_end;
>> + size_t vmoff;
>> +
>> vm = >vm;
>> if (!(vm->flags & VM_ARM_STATIC_MAPPING))
>> continue;
>> if ((vm->flags & VM_ARM_MTYPE_MASK) != VM_ARM_MTYPE(mtype))
>> continue;
>>
>> - if (vm->phys_addr > paddr ||
>> - paddr + size - 1 > vm->phys_addr + vm->size - 1)
>> + /* Static vm area boundary check:
>> + *
>> + * paddr1 --->| |
>> + * | |
>> + * |---| <-\--- svm->vm->addr(page
>> aligned)
>> + * paddr2 --->| ||
>> + * | --| <--|-- svm->vm->phys_addr
>> + * | ||
>> + * paddr3 --->| ||
>> + * | ||
>> + * |---| <--|-- next page boundary
>> + * | ||
>> + * paddr4 --->| || <- svm->vm->size,
>> + * | || including guard page
>> + * | ||
>> + * max paddr_end -->|---| <--|-- svm->vm's phys_addr_end
>> + * | / ||
>> + * paddr5 --->| guard ||
>> + * | page ||
>> + * | / ||
>> + * --- <-/-- svm->vm->addr +
>> svm->vm_size
>> + *
>> + * <1> If paddr == paddr1, then continue;
>> + * <2> If paddr == paddr2~paddr4 and paddr_end > phys_addr_end,
>> + * then continue;
>> + * <3> if paddr >= paddr5 then continue;
>> + */
>> + vmoff = vm->phys_addr & ~PAGE_MASK;
>> + phys_addr_end = vm->phys_addr + vm->size - PAGE_SIZE - vmoff;
>> + paddr_end = paddr + size - offset;
>> + if (__phys_to_pfn(vm->phys_addr) > __phys_to_pfn(paddr) ||
>> + paddr_end - 1 > phys_addr_end - 1)
>> continue;
>>
>> return svm;
>> --
>> 1.8.4
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Thu, 2014-05-15 at 15:15 -0700, Greg Kroah-Hartman wrote: > On Thu, May 15, 2014 at 05:42:54PM +, Serge Hallyn wrote: > > What exactly defines '"normal" use case for a container'? > Well, I'd say "acting like a virtual machine" is a good start :) Ok... And virtual machines (VirtualBox, VMware, etc, etc) have hot plug USB devices. I use the USB hotplug with VirtualBox. I plug a configured USB device in and the VirtualBox VM grabs it. Virtual machines have loopback devices. I've used them and using them in containers is significantly more efficient. VirtualBox has remote audio and a host of other device features. Now we have some agreement. Normal is "acting like a virtual machine". That's a goal I can agree with. I want to work toward that goal of containers "acting like a virtual machine" just running on a common kernel with the host. It's a challenge. We're getting there. > > Not too long ago much of what we can now do with network namespaces > > was not a normal container use case. Neither "you can't do it now" > > nor "I don't use it like that" should be grounds for a pre-emptive > > nack. "It will horribly break security assumptions" certainly would > > be. > I agree, and maybe we will get there over time, but this patch is nto > the way to do that. Ok... We have a goal. Now we can haggle over the details (to paraphrase a joke that's as old as I am). > > That's not to say there might not be good reasons why this in particular > > is not appropriate, but ISTM if things are going to be nacked without > > consideration of the patchset itself, we ought to be having a ksummit > > session to come to a consensus [ or receive a decree, presumably by you :) > > but after we have a chance to make our case ] on what things are going to > > be un/acceptable. > I already stood up and publically said this last year at Plumbers, why > is anything now different? Not much really. The reality is that more and more people are trying to use hotplug devices, network interfaces, and loopback devices in containers just like they would in full para or hw virt machines. We're trying to make them work, without it looking like a kludge. I personally agree with you that much of this can be done in host user space and, coming out of LinuxPlumbers last year, I've implemented some ideas that did not require kernel patches that achieve some of my goals. > And this patchset is proof of why it's not a good idea. You really > didn't do anything with all of the namespace stuff, except change loop. > That's the only thing that cares, so, just do it there, like I said to > do so, last August. > And you are ignoring the notifications to userspace and how namespaces > here would deal with that. That's a problem to deal with. I don't thing anyone is ignoring them. > > > > Serge mentioned something to me about a loopdevfs (?) thing that someone > > > > else is working on. That would seem to be a better solution in this > > > > particular case but I don't know much about it or where it's at. > > > > > > Ok, let's see those patches then. > > > > I think Seth has a git tree ready, but not sure which branch he'd want > > us to look at. > > > > Splitting a namespaced devtmpfs from loopdevfs discussion might be > > sensible. However, in defense of a namespaced devtmpfs I'd say > > that for userspace to, at every container startup, bind-mount in > > devices from the global devtmpfs into a private tmpfs (for systemd's > > sake it can't just be on the container rootfs), seems like something > > worth avoiding. > I think having to pick and choose what device nodes you want in a > container is a good thing. Both static and dynamic devices. It's got to support hotplug. We have (I have) use cases. That's what I'm trying to do with host udev rules and some custom configurations. I can play games with udev rules. Maybe we can keep the user spaces policies in user space and not burden the kernel. > Becides, you would have to do the same thing > in the kernel anyway, what's wrong with userspace making the decision > here, especially as it knows exactly what it wants to do much more so > than the kernel ever can. IMHO, there's nothing wrong with that as long as we agree on how it's to be done. I'm not convinced that it can all be done in user space and I'm not convinced that name spaced devtmpfs is the magic pill to make it all go away either. Making the user space make the decisions and having the kernel enforce them is a principle worth considering. > > PS - Apparently both parallels and Michael independently > > project devices which are hot-plugged on the host into containers. > > That also seems like something worth talking about (best practices, > > shortcomings, use cases not met by it, any ways tha the kernel can > > help out) at ksummit/linuxcon. > I was told that containers would never want devices hotplugged into > them. Interesting. You were told they (who they?) would never want them? Who
Re: [PATCHSET cgroup/for-3.16] cgroup: iterate cgroup_subsys_states directly
On 2014/5/10 5:31, Tejun Heo wrote:
> Hello,
>
> Currently, while csses (cgroup_subsys_states) have ->parent linkage
> too, only cgroups form full tree through their ->children and
> ->sibling fields and css iterations naturally is implemented by
> iterating cgroups and then dereferencing the css for the specified
> subsystem.
>
> There are now use cases where controllers need to iterate through
> csses regardless of their online state as long as they have positive
> reference. This can't easily be achieved by iterating cgroups because
> its css pointer array needs to be cleared on offline and there may be
> multiple dying csses for a cgroup for the same subsystem and there's
> only one pointer per cgroup-subsystem pair.
>
> This patchset moves ->children and ->sibling from cgroup to css and
> link all csses in proper trees and then make css iterators walk csses
> directly instead of going through cgroups. This achieves iteration of
> all non-released csses while also simplifying the iteration
> implementation. This is also in line with the general direction of
> using csses as the primary structural component.
>
> This patchset contains the following fourteen patches.
>
> 0001-cgroup-remove-css_parent.patch
> 0002-cgroup-remove-pointless-has-tasks-children-test-from.patch
> 0003-memcg-update-memcg_has_children-to-use-css_next_chil.patch
> 0004-device_cgroup-remove-direct-access-to-cgroup-childre.patch
> 0005-cgroup-remove-cgroup-parent.patch
> 0006-cgroup-move-cgroup-sibling-and-children-into-cgroup_.patch
> 0007-cgroup-link-all-cgroup_subsys_states-in-their-siblin.patch
> 0008-cgroup-move-cgroup-serial_nr-into-cgroup_subsys_stat.patch
> 0009-cgroup-introduce-CSS_RELEASED-and-reduce-css-iterati.patch
> 0010-cgroup-iterate-cgroup_subsys_states-directly.patch
> 0011-cgroup-use-CSS_ONLINE-instead-of-CGRP_DEAD.patch
> 0012-cgroup-convert-cgroup_has_live_children-into-css_has.patch
> 0013-device_cgroup-use-css_has_online_children-instead-of.patch
> 0014-cgroup-implement-css_tryget.patch
>
> 0001-0004 are prep patches.
>
> 0005-0008 move fields from cgroup to css and link csses in tree
> structure instead of cgroups.
>
> 0009-0010 implement direct css iteration.
>
> 0011-0013 convert a cgroup based interface to a css one, which is now
> possible as both are the same in terms of the tree structure, and fix
> devcg brekage using it.
>
> 0014 implements css_tryget() which is to be used to gain access to
> offline but not-yet-released csses.
>
> This pachset is on top of
>
> b9a63d0116e8 ("Merge branch 'for-3.16' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu into for-3.16")
> + [1] [PATCHSET v2 cgroup/for-3.16] cgroup: post unified hierarchy fixes and
> updates
> + [2] (REFRESHED) [PATCHSET cgroup/for-3.16] cgroup: implement
> cftype->write()
> + [3] (REFRESHED) [PATCHSET cgroup/for-3.16] cgroup: remove cgroup_tree_mutex
> + [4] [PATCHSET cgroup/for-3.16] cgroup: use css->refcnt for cgroup
> reference counting
>
> and available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-direct-css-iteration
>
> diffstat follows. Thanks.
>
> block/blk-cgroup.h |2
> include/linux/cgroup.h | 122 +++-
> kernel/cgroup.c | 257
> ---
> kernel/cgroup_freezer.c |2
> kernel/cpuset.c |2
> kernel/sched/core.c |2
> kernel/sched/cpuacct.c |2
> mm/hugetlb_cgroup.c |2
> mm/memcontrol.c | 45 +++
> net/core/netclassid_cgroup.c |2
> net/core/netprio_cgroup.c|2
> security/device_cgroup.c | 17 --
> 12 files changed, 251 insertions(+), 206 deletions(-)
>
Acked-by: Li Zefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET cgroup/for-3.16] cgroup: iterate cgroup_subsys_states directly
On2014/5/14 21:07, Tejun Heo wrote: > Hello, Li. > > On Wed, May 14, 2014 at 12:21:25PM +0800, Li Zefan wrote: >>> There are now use cases where controllers need to iterate through >>> csses regardless of their online state as long as they have positive >> >> What use cases are we talking about here? > > memcg wants to be able to iterate all csses whose refcnts haven't > reached zero yet so that it can treat offline csses the same way as > online ones in terms of memory reclaim. They don't contain new tasks > so new charges won't be created but offlining won't try to transfer > all charges to the parent but just leave the offline child attached > until all charges are eventually reclaimed from the pressure from the > parent. > > I'm not too familiar with the details but this makes sense in generic > sense too. Offline marks an object starting its draining phase and > release marks the actual destruction point. For controllers with > persistent states like memcg, it's a lot more natural to deal offlined > csses as "active but draining following the usual hierarchical > operation" rather than trying to explicitly update the states from > offline to move them to the parent especially as the effort there > essentially is a waste as most of those moved charges aren't gonna be > used in the parent and will be released eventually. > > Guaranteeing iteration of offline but not-released csses allow > controllers to treat the draining stage between offline and release > more or less identically to online state which in turn can make > ->css_offline() significantly simpler and lighter. > yeah, fair enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bug? Older 32 bit program (CivCTP) no longer works under 64 bit kernel
I have an old native Linux 32 bit copy of Civilization: Call to Power.
It used to work under a 64 bit environment back in the 3.0.x days.
However, under recent versions (>3.5) it no longer runs - it complains
that it cannot find certain files in the directory. The exact same code
will run just fine under a 32 bit version of 3.11. I have a Pentium II
as well as the Core 2 Duo, both running Ubuntu 14.04, same version of
the kernel other than one is 32 bit and one is 64 bit. I've copied the
files over from the 32 bit machine, where it runs, to the 64 bit
machine, where it does not. I've even gone so far as to copy all the
system 32 bit libraries into the CivCTP directory, and forced the
program to use them (including using the ld-linux.so loader from that
directory) - so in theory it's all the same user space libraries running
- the only difference that I can see is that one kernel is 64 bit and
one is 32 bit.
Running strace on the program shows that the directories being searched
for game assets are corrupted:
16218 stat64("/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt",
Note the "englisish" rather than "english".
I'm looking for any suggestions on where to look for what might cause
such an issue - what can I do to start tracking this down.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/6] watchdog: Add API to trigger reboots
Some hardware implements reboot through its watchdog hardware,
for example by triggering a watchdog timeout. Platform specific
code starts to spread into watchdog drivers, typically by setting
pointers to a callback functions which is then called from the
platform reset handler.
To simplify code and provide a unified API to trigger reboots by
watchdog drivers, provide a single API to trigger such reboots
through the watchdog subsystem.
Signed-off-by: Guenter Roeck
---
v4: Protect accesses to wdd_reboot_dev with spinlock to avoid potential
race conditions.
Drop Acked-by and Tested-by tags because changes are too significant
and warrant re-evaluation and re-testing.
v3: Drop reboot mode and cmd string parameters from API
v2: Remove unnecessary check for ops in reboot function
drivers/watchdog/watchdog_core.c | 27 +++
include/linux/watchdog.h | 8
2 files changed, 35 insertions(+)
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index cec9b55..e61f4ed 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -37,12 +37,27 @@
#include /* For ida_* macros */
#include /* For IS_ERR macros */
#include /* For of_get_timeout_sec */
+#include /* For spinlock */
#include "watchdog_core.h" /* For watchdog_dev_register/... */
static DEFINE_IDA(watchdog_ida);
static struct class *watchdog_class;
+static DEFINE_SPINLOCK(wdd_reboot_lock);
+static struct watchdog_device *wdd_reboot_dev;
+
+void watchdog_do_reboot(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(_reboot_lock, flags);
+ if (wdd_reboot_dev)
+ wdd_reboot_dev->ops->reboot(wdd_reboot_dev);
+ spin_unlock_irqrestore(_reboot_lock, flags);
+}
+EXPORT_SYMBOL(watchdog_do_reboot);
+
static void watchdog_check_min_max_timeout(struct watchdog_device *wdd)
{
/*
@@ -111,6 +126,7 @@ EXPORT_SYMBOL_GPL(watchdog_init_timeout);
int watchdog_register_device(struct watchdog_device *wdd)
{
int ret, id, devno;
+ unsigned long flags;
if (wdd == NULL || wdd->info == NULL || wdd->ops == NULL)
return -EINVAL;
@@ -162,6 +178,11 @@ int watchdog_register_device(struct watchdog_device *wdd)
return ret;
}
+ spin_lock_irqsave(_reboot_lock, flags);
+ if (wdd->ops->reboot && !wdd_reboot_dev)
+ wdd_reboot_dev = wdd;
+ spin_unlock_irqrestore(_reboot_lock, flags);
+
return 0;
}
EXPORT_SYMBOL_GPL(watchdog_register_device);
@@ -177,10 +198,16 @@ void watchdog_unregister_device(struct watchdog_device
*wdd)
{
int ret;
int devno;
+ unsigned long flags;
if (wdd == NULL)
return;
+ spin_lock_irqsave(_reboot_lock, flags);
+ if (wdd == wdd_reboot_dev)
+ wdd_reboot_dev = NULL;
+ spin_unlock_irqrestore(_reboot_lock, flags);
+
devno = wdd->cdev.dev;
ret = watchdog_dev_unregister(wdd);
if (ret)
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 2a3038e..1e9da0a 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -23,6 +23,7 @@ struct watchdog_device;
* @start: The routine for starting the watchdog device.
* @stop: The routine for stopping the watchdog device.
* @ping: The routine that sends a keepalive ping to the watchdog device.
+ * @reboot:The routine for rebooting the system
* @status:The routine that shows the status of the watchdog device.
* @set_timeout:The routine for setting the watchdog devices timeout value.
* @get_timeleft:The routine that get's the time that's left before a reset.
@@ -42,6 +43,7 @@ struct watchdog_ops {
int (*stop)(struct watchdog_device *);
/* optional operations */
int (*ping)(struct watchdog_device *);
+ void (*reboot)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
@@ -142,4 +144,10 @@ extern int watchdog_init_timeout(struct watchdog_device
*wdd,
extern int watchdog_register_device(struct watchdog_device *);
extern void watchdog_unregister_device(struct watchdog_device *);
+#ifdef CONFIG_WATCHDOG_CORE
+extern void watchdog_do_reboot(void);
+#else
+static inline void watchdog_do_reboot(void) { }
+#endif
+
#endif /* ifndef _LINUX_WATCHDOG_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/5] Add Keystone PCIe controller driver
On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote: > > This patch adds a PCIe controller driver for Keystone SoCs. This > is based on the origin RFC patch that I had sent earlier. I have > incorporated following comments:- > > - Add a interrupt controller node for Legacy irq chip and use >interrupt map/map-mask property to map legacy IRQs A/B/C/D > - Add a Phy driver to replace the original serdes driver > - Move common applicaiton register handling code to a separate >file to allow re-use across other platforms that use older >DW PCIe h/w > - PCI quirk for maximum read request size. Check and override only >if the maximum is higher than what controller can handle. > - Converted to a module platform driver. > > CC: Santosh Shilimkar > CC: Russell King > CC: Grant Likely > CC: Rob Herring > CC: Mohit Kumar > CC: Jingoo Han > CC: Bjorn Helgaas > Your patches modify 'pcie-designware.c', and affects other PCIe drivers using designware PCIe Core IP. Please add the following people to CC list. They are also related to the designware PCIe. Pratyush Anand Richard Zhu Kishon Vijay Abraham I Marek Vasut Best regards, Jingoo Han > > Murali Karicheri (5): > ARM: keystone: add pcie related options > pci: designware: enhancements to support keystone pcie > phy: pci serdes phy driver for keystone > pci: dw: add common functions to support old hw based pci driver > pci: keystone: add pcie driver based on designware core driver > > .../devicetree/bindings/pci/pcie-keystone.txt | 68 > arch/arm/mach-keystone/Kconfig |2 + > drivers/pci/host/Kconfig | 12 + > drivers/pci/host/Makefile |2 + > drivers/pci/host/pci-dw-old-msi.c | 150 > drivers/pci/host/pci-dw-old.c | 371 ++ > drivers/pci/host/pci-dw-old.h | 30 ++ > drivers/pci/host/pci-keystone.c| 400 > > drivers/pci/host/pcie-designware.c | 101 +++-- > drivers/pci/host/pcie-designware.h | 42 +- > drivers/pci/quirks.c | 13 + > drivers/phy/Kconfig|6 + > drivers/phy/Makefile |1 + > drivers/phy/phy-keystone.c | 230 +++ > 14 files changed, 1388 insertions(+), 40 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/pcie-keystone.txt > create mode 100644 drivers/pci/host/pci-dw-old-msi.c > create mode 100644 drivers/pci/host/pci-dw-old.c > create mode 100644 drivers/pci/host/pci-dw-old.h > create mode 100644 drivers/pci/host/pci-keystone.c > create mode 100644 drivers/phy/phy-keystone.c > > -- > 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Fri, May 16, 2014 at 10:11:56AM +1000, Dave Chinner wrote: > On Fri, May 16, 2014 at 01:19:09AM +0200, Mateusz Guzik wrote: > > Except there is no log entry if /var got frozen (and this is not an > > imaginary example). > > Freezing the filesystem that the freezing daemon logs to is, well, a > major application architecture fail. Sorry, catering for the lowest > common denominator (i.e. stupidity) is not an valid argument for > adding stuff to the kernel > I'm only saying what you can encounter in varous companies. If aiding this problem the way I proposed is not a good idea (and it turns out there is a much better way), I'm not insisting. > > Grabbig a debugger to inspect daemon's state is not > > exactly what your typical support associate can or should do. > > No, but they can read /proc/self/mountinfo, and grab sysrq-w output. > And they should be able to read that and tell that there is a freeze > hang from that info. This "filesystem hang triage 101" stuff > > > But this was a side request, I'm not going to argue about including > > this since turns out there is a better way. > > > > Somewhere in the thread an idea to log long-standing freezes was > > mentioned which would provide sufficient information as far as > > You've already got the hung task timer firing when a fs is frozen > for too long. You'll see processes hung in sb_write_wait(), and that > tells you the filesystem is frozen. Then look at > /proc/self/mountinfo to find which fs is frozen > But additional question was what initiated the freeze and it is not answered by this. Hopefully a warning for long-standing freezes will be implemented and that will answer the question. Once more, I'm fine with mere 'frozen' in mountinfo, so I suggest we drop this now side subject. If you really want to continue we can discuss this in private. :-> -- Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU
On Thu, 15 May 2014 22:37:31 +0200, Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 02:05:30PM +0200, Arnd Bergmann wrote:
> [...]
> > let me clarify by example:
> >
> > iommu@1 {
> > compatible = "some,simple-iommu";
> > reg = <1>;
> > #iommu-cells = <0>; /* supports only one master */
> > };
> >
> > iommu@2 {
> > compatible = "some,other-iommu";
> > reg = <3>;
> > #iommu-cells = <1>; /* contains master ID */
> > };
> >
> > iommu@3 {
> > compatible = "some,windowed-iommu";
> > reg = <2>;
> > #iommu-cells = <2>; /* contains dma-window */
> > };
> >
> > device@4 {
> > compatible = "some,ethernet";
> > iommus = <&/iommu@1>;
> > };
> >
> > device@5 {
> > compatible = "some,dmaengine";
> > iommus = <&/iommu@2 0x4000 0x100>,
> > <&/iommu@3 0x101>;
> > };
> >
> > The device at address 4 has a one-one relationship with iommu@1, so there
> > is no need for any data. device@5 has two master ports. One is connected to
> > an IOMMU that has a per-device aperture, device@5 can only issue transfers
> > to the 256MB area at 0x4000, and the IOMMU will have to put entries for
> > this device into that address. The second master port is connected to
> > iommu@3, which uses a master ID that gets passed along with each transfer,
> > so that needs to be put into the IOTLBs.
>
> iommu@3 and the second port of device@5 seem to match what we need for
> Tegra (and as I understand also Exynos). Can we settle on this for now
> so that Hiroshi and Cho can go update their drivers for this binding?
>
Currently, Exynos IOMMU is the case of iommu@1.
But in the near future, it will support multiple masters with a single context
that means all masters that shares a single System MMU also views the same
address space.
For some cases, we may need iommu@3 that supports dma-window.
So, I have no other opinion.
By the way, iommu framework should allow to process the parameters
to 'iommus' property in the master nodes by iommu driver implementations
because it is depended on implementations.
> > A variation would be to not use #iommu-cells at all, but provide a
> > #address-cells / #size-cells pair in the IOMMU, and have a translation
> > as we do for dma-ranges. This is probably most flexible.
>
> The remainder of this discussion seems to indicate that #iommu-cells and
> dma-ranges don't have to be mutually exclusive. For some IOMMUs it might
> make sense to use both.
>
> In fact perhaps we should require every IOMMU user to also specify a
> dma-ranges property, even if for some cases the range would be simply
> the complete physical address space. Perhaps in analogy to the ranges
> property an empty dma-ranges property could be taken to mean all of the
> physical address space.
>
> I'm aware that this doesn't cover any of the more exotic cases out
> there, but the fact is that we have real devices out there that ship
> with some variations of these simple IOMMUs and I don't think we're
> doing ourselves a favour by blocking support for these to be added on
> the hope of merging the perfect solution that covers all use-cases.
> Patches for Tegra have already been around for close to half a year.
>
> Thierry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3][Resend] ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend
From: Rafael J. Wysocki
Rework the ACPI PM domain's PM callbacks to avoid resuming devices
during system suspend (in order to modify their wakeup settings etc.)
if that isn't necessary.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/device_pm.c | 46 ++
drivers/acpi/scan.c |4
include/acpi/acpi_bus.h |3 ++-
3 files changed, 48 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -907,20 +907,44 @@ int acpi_subsys_prepare(struct device *d
if (dev->power.ignore_children)
pm_runtime_resume(dev);
+ pm_set_direct_resume(dev, true);
return pm_generic_prepare(dev);
}
EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
/**
- * acpi_subsys_suspend - Run the device driver's suspend callback.
+ * acpi_subsys_suspend - Handle device suspend stage of system suspend.
* @dev: Device to handle.
- *
- * Follow PCI and resume devices suspended at run time before running their
- * system suspend callbacks.
*/
int acpi_subsys_suspend(struct device *dev)
{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ u32 sys_target;
+
+ if (!adev || !pm_runtime_enabled_and_suspended(dev)) {
+ pm_set_direct_resume(dev, false);
+ goto out;
+ }
+ if (!pm_direct_resume_is_set(dev)
+ || device_may_wakeup(dev) != !!adev->wakeup.prepare_count)
+ goto resume;
+
+ sys_target = acpi_target_system_state();
+ if (sys_target != ACPI_STATE_S0) {
+ int ret, state;
+
+ if (adev->power.flags.dsw_present)
+ goto resume;
+
+ ret = acpi_dev_pm_get_state(dev, adev, sys_target, NULL,
);
+ if (!ret && state == adev->power.state)
+ return 0;
+ }
+
+ resume:
pm_runtime_resume(dev);
+
+ out:
return pm_generic_suspend(dev);
}
@@ -954,6 +978,19 @@ int acpi_subsys_resume_early(struct devi
EXPORT_SYMBOL_GPL(acpi_subsys_resume_early);
/**
+ * acpi_subsys_resume - Handle device resume stage of system resume.
+ * @dev: Device to handle.
+ */
+int acpi_subsys_resume(struct device *dev)
+{
+ if (pm_direct_resume_is_set(dev)) {
+ pm_runtime_resume(dev);
+ return 0;
+ }
+ return pm_generic_resume(dev);
+}
+
+/**
* acpi_subsys_freeze - Run the device driver's freeze callback.
* @dev: Device to handle.
*/
@@ -982,6 +1019,7 @@ static struct dev_pm_domain acpi_general
.suspend = acpi_subsys_suspend,
.suspend_late = acpi_subsys_suspend_late,
.resume_early = acpi_subsys_resume_early,
+ .resume = acpi_subsys_resume,
.freeze = acpi_subsys_freeze,
.poweroff = acpi_subsys_suspend,
.poweroff_late = acpi_subsys_suspend_late,
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -261,7 +261,8 @@ struct acpi_device_power_flags {
u32 inrush_current:1; /* Serialize Dx->D0 */
u32 power_removed:1;/* Optimize Dx->D0 */
u32 ignore_parent:1;/* Power is independent of parent power state */
- u32 reserved:27;
+ u32 dsw_present:1; /* _DSW present? */
+ u32 reserved:26;
};
struct acpi_device_power_state {
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -1551,9 +1551,13 @@ static void acpi_bus_get_power_flags(str
*/
if (acpi_has_method(device->handle, "_PSC"))
device->power.flags.explicit_get = 1;
+
if (acpi_has_method(device->handle, "_IRC"))
device->power.flags.inrush_current = 1;
+ if (acpi_has_method(device->handle, "_DSW"))
+ device->power.flags.dsw_present = 1;
+
/*
* Enumerate supported power management states
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] (was: Re: PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)
On Thursday, May 15, 2014 01:13:02 PM Rafael J. Wysocki wrote:
> On Wednesday, May 14, 2014 10:53:16 AM Alan Stern wrote:
> > On Tue, 13 May 2014, Rafael J. Wysocki wrote:
[cut]
> >
> > if (dev->power.direct_complete) {
> > if (pm_runtime_status_suspended(dev)) {
> > pm_runtime_disable(dev);
> > if (dev->power.disable_depth == 1
> > && pm_runtime_status_suspended(dev))
> > goto Complete;
> > pm_runtime_enable(dev);
> > }
> > dev->power.direct_complete = false;
> > }
>
> That is a good idea, thanks!
New patches follow.
[1/3] is the core change with the above added.
> > Also, now that we have finally settled on the appropriate API, there
> > needs to ba a patch updating the PM documentation.
>
> Absolutely. I thought about updating the documentation in the same patch
> (at least the comments in pm.h), but I guess a separate patch for files
> under Documentation/ may be better.
[2/3] is the corresponding documentation update (I hope I haven't overlooked
anything important).
[3/3] is a resend of the ACPI PM patch on top of the core change.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] PM / sleep: Update device PM documentation to cover direct_complete
From: Rafael J. Wysocki Update the device PM documentation in devices.txt and runtime_pm.txt to reflect the changes in the system suspend and resume handling related to the introduction of the new power.direct_complete flag. Signed-off-by: Rafael J. Wysocki --- Documentation/power/devices.txt| 34 ++ Documentation/power/runtime_pm.txt | 17 + 2 files changed, 47 insertions(+), 4 deletions(-) Index: linux-pm/Documentation/power/devices.txt === --- linux-pm.orig/Documentation/power/devices.txt +++ linux-pm/Documentation/power/devices.txt @@ -2,6 +2,7 @@ Device Power Management Copyright (c) 2010-2011 Rafael J. Wysocki , Novell Inc. Copyright (c) 2010 Alan Stern +Copyright (c) 2014 Intel Corp., Rafael J. Wysocki Most of the code in Linux is device drivers, so most of the Linux power @@ -326,6 +327,20 @@ the phases are: driver in some way for the upcoming system power transition, but it should not put the device into a low-power state. + For devices supporting runtime power management, the return value of the + prepare callback can be used to indicate to the PM core that it may + safely leave the device in runtime suspend (if runtime-suspended + already), provided that all of the device's descendants are also left in + runtime suspend. Namely, if the prepare callback returns a positive + number and that happens for all of the descendants of the device too, + and all of them (including the device itself) are runtime-suspended, the + PM core will skip the suspend, suspend_late and suspend_noirq suspend + phases as well as the resume_noirq, resume_early and resume phases of + the following system resume for all of these devices. In that case, + the complete callback will be called directly after the prepare callback + and is entirely responsible for bringing the device back to the + functional state as appropriate. + 2. The suspend methods should quiesce the device to stop it from performing I/O. They also may save the device registers and put it into the appropriate low-power state, depending on the bus type the device is on, @@ -400,12 +415,23 @@ When resuming from freeze, standby or me the resume callbacks occur; it's not necessary to wait until the complete phase. + Moreover, if the preceding prepare callback returned a positive number, + the device may have been left in runtime suspend throughout the whole + system suspend and resume (the suspend, suspend_late, suspend_noirq + phases of system suspend and the resume_noirq, resume_early, resume + phases of system resume may have been skipped for it). In that case, + the complete callback is entirely responsible for bringing the device + back to the functional state after system suspend if necessary. [For + example, it may need to queue up a runtime resume request for the device + for this purpose.] To check if that is the case, the complete callback + can consult the device's power.direct_complete flag. Namely, if that + flag is set when the complete callback is being run, it has been called + directly after the preceding prepare and special action may be required + to make the device work correctly afterward. + At the end of these phases, drivers should be as functional as they were before suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are -gated on. Even if the device was in a low-power state before the system sleep -because of runtime power management, afterwards it should be back in its -full-power state. There are multiple reasons why it's best to do this; they are -discussed in more detail in Documentation/power/runtime_pm.txt. +gated on. However, the details here may again be platform-specific. For example, some systems support multiple "run" states, and the mode in effect at Index: linux-pm/Documentation/power/runtime_pm.txt === --- linux-pm.orig/Documentation/power/runtime_pm.txt +++ linux-pm/Documentation/power/runtime_pm.txt @@ -2,6 +2,7 @@ Runtime Power Management Framework for I (C) 2009-2011 Rafael J. Wysocki , Novell Inc. (C) 2010 Alan Stern +(C) 2014 Intel Corp., Rafael J. Wysocki 1. Introduction @@ -444,6 +445,10 @@ drivers/base/power/runtime.c and include bool pm_runtime_status_suspended(struct device *dev); - return true if the device's runtime PM status is 'suspended' + bool pm_runtime_suspended_if_enabled(struct device *dev); +- return true if the device's runtime PM status is 'suspended' and its + 'power.disable_depth' field is equal to 1 + void pm_runtime_allow(struct device *dev); - set the power.runtime_auto flag for the device and decrease
RE: ATTN
2million USD donation to you from Evelyn,Contact her on (
cu36er...@rogers.com ) For more info
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 1/3] PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily
From: Rafael J. Wysocki
Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
resume all runtime-suspended devices during system suspend, mostly
because those devices may need to be reprogrammed due to different
wakeup settings for system sleep and for runtime PM.
For some devices, though, it's OK to remain in runtime suspend
throughout a complete system suspend/resume cycle (if the device was in
runtime suspend at the start of the cycle). We would like to do this
whenever possible, to avoid the overhead of extra power-up and power-down
events.
However, problems may arise because the device's descendants may require
it to be at full power at various points during the cycle. Therefore the
most straightforward way to do this safely is if the device and all its
descendants can remain runtime suspended until the complete stage of
system resume.
To this end, introduce a new device PM flag, power.direct_complete
and modify the PM core to use that flag as follows.
If the ->prepare() callback of a device returns a positive number,
the PM core will regard that as an indication that it may leave the
device runtime-suspended. It will then check if the system power
transition in progress is a suspend (and not hibernation in particular)
and if the device is, indeed, runtime-suspended. In that case, the PM
core will set the device's power.direct_complete flag. Otherwise it
will clear power.direct_complete for the device and it also will later
clear it for the device's parent (if there's one).
Next, the PM core will not invoke the ->suspend() ->suspend_late(),
->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume()
callbacks for all devices having power.direct_complete set. It
will invoke their ->complete() callbacks, however, and those
callbacks are then responsible for resuming the devices as
appropriate, if necessary. For example, in some cases they may
need to queue up runtime resume requests for the devices using
pm_request_resume().
Changelog partly based on an Alan Stern's description of the idea
(http://marc.info/?l=linux-pm=139940466625569=2).
Signed-off-by: Rafael J. Wysocki
---
drivers/base/power/main.c | 66 ++---
include/linux/pm.h | 36 +++-
include/linux/pm_runtime.h |6
3 files changed, 85 insertions(+), 23 deletions(-)
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -93,13 +93,23 @@ typedef struct pm_message {
* been registered) to recover from the race condition.
* This method is executed for all kinds of suspend transitions and is
* followed by one of the suspend callbacks: @suspend(), @freeze(), or
- * @poweroff(). The PM core executes subsystem-level @prepare() for all
- * devices before starting to invoke suspend callbacks for any of them, so
- * generally devices may be assumed to be functional or to respond to
- * runtime resume requests while @prepare() is being executed. However,
- * device drivers may NOT assume anything about the availability of user
- * space at that time and it is NOT valid to request firmware from within
- * @prepare() (it's too late to do that). It also is NOT valid to allocate
+ * @poweroff(). If the transition is a suspend to memory or standby (that
+ * is, not related to hibernation), the return value of @prepare() may be
+ * used to indicate to the PM core to leave the device in runtime suspend
+ * if applicable. Namely, if @prepare() returns a positive number, the PM
+ * core will understand that as a declaration that the device appears to be
+ * runtime-suspended and it may be left in that state during the entire
+ * transition and during the subsequent resume if all of its descendants
+ * are left in runtime suspend too. If that happens, @complete() will be
+ * executed directly after @prepare() and it must ensure the proper
+ * functioning of the device after the system resume.
+ * The PM core executes subsystem-level @prepare() for all devices before
+ * starting to invoke suspend callbacks for any of them, so generally
+ * devices may be assumed to be functional or to respond to runtime resume
+ * requests while @prepare() is being executed. However, device drivers
+ * may NOT assume anything about the availability of user space at that
+ * time and it is NOT valid to request firmware from within @prepare()
+ * (it's too late to do that). It also is NOT valid to allocate
* substantial amounts of memory from @prepare() in the GFP_KERNEL mode.
* [To work around these limitations, drivers may register suspend and
* hibernation notifiers to be executed before the freezing of tasks.]
@@ -112,7 +122,16 @@ typedef struct pm_message {
* of the other devices that the PM core has
Alert...
Congrats:You have won ( £500,000.00 Pounds )Contact Mr Andrew James:money.transfe...@qq.com ,Mobile:+447509531953 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
> So in sum, it very much looks like the intention is for > PTRACE_GETREGSET/PTRACE_SETREGSET to return ENODEV in the > case the regset doesn't exist on the running machine, and then > it looks like at least x86 works that way. Good point... agreed. We should ENODEV when we don't have TM hardware (like POWER7). Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/5] ARM: keystone: add pcie related options
On Friday, May 16, 2014 1:01 AM, Murali Karicheri wrote:
>
> Add pcie related options by default for keystone architecture
>
> CC: Santosh Shilimkar
> CC: Russell King
>
> Signed-off-by: Murali Karicheri
> ---
> arch/arm/mach-keystone/Kconfig |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
> index f50bc93..f87844d 100644
> --- a/arch/arm/mach-keystone/Kconfig
> +++ b/arch/arm/mach-keystone/Kconfig
> @@ -8,6 +8,8 @@ config ARCH_KEYSTONE
> select COMMON_CLK_KEYSTONE
> select ARCH_SUPPORTS_BIG_ENDIAN
> select ZONE_DMA if ARM_LPAE
> + select MIGHT_HAVE_PCI
> + select ARCH_SUPPORTS_MSI
Please, don't select ARCH_SUPPORTS_MSI, because this kconfig
option was already removed in v3.12 by the commit ebd97be635
('PCI: remove ARCH_SUPPORTS_MSI kconfig option'). So. there is
NO need to select 'ARCH_SUPPORTS_MSI'.
Best regards,
Jingoo Han
> help
> Support for boards based on the Texas Instruments Keystone family of
> SoCs.
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Fri, May 16, 2014 at 01:19:09AM +0200, Mateusz Guzik wrote: > On Fri, May 16, 2014 at 08:51:41AM +1000, Dave Chinner wrote: > > On Fri, May 16, 2014 at 12:34:40AM +0200, Mateusz Guzik wrote: > > > On Fri, May 16, 2014 at 08:21:35AM +1000, Dave Chinner wrote: > > > > > IOW, a new column in mountinfo. For frozen filesystems it would > > > > > contain > > > > > 'frozen_by=[%s]:[%d]' (escaped comm, pid). > > > > > > > > I really don't see that the process that froze the filesystem is > > > > particularly useful - it many cases that process is long gone (e.g. > > > > fsfreeze is being used to allow a HW array to take a snapshot). Just > > > > the fact it is in the process of freezing (if stuck, stack trace in > > > > sysrq-w should be present) or frozen (freezing process may be long > > > > gone, and is mostly irrelevant because you're now tracking down why > > > > a thaw hasn't happened)... > > > > > > There are deamons which perform freezing and unfreezing on their own. > > > Thus storing the name along with pid helps to determine whether someone > > > went behind such daemon's back, or maybe it's the daemon which "forgot" to > > > unfreeze after all. > > > > Such a daemon should be logging the fact that it's freezing and > > thawing the filesystem. The kernel is not the place to track what > > buggy userspace applications are doing wrong. > > > > Except there is no log entry if /var got frozen (and this is not an > imaginary example). Freezing the filesystem that the freezing daemon logs to is, well, a major application architecture fail. Sorry, catering for the lowest common denominator (i.e. stupidity) is not an valid argument for adding stuff to the kernel > Grabbig a debugger to inspect daemon's state is not > exactly what your typical support associate can or should do. No, but they can read /proc/self/mountinfo, and grab sysrq-w output. And they should be able to read that and tell that there is a freeze hang from that info. This "filesystem hang triage 101" stuff > But this was a side request, I'm not going to argue about including > this since turns out there is a better way. > > Somewhere in the thread an idea to log long-standing freezes was > mentioned which would provide sufficient information as far as You've already got the hung task timer firing when a fs is frozen for too long. You'll see processes hung in sb_write_wait(), and that tells you the filesystem is frozen. Then look at /proc/self/mountinfo to find which fs is frozen Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sysrq,rcu: suppress RCU stall warnings while sysrq runs
On Thu, May 15, 2014 at 04:24:12PM -0700, Andrew Morton wrote: > On Tue, 29 Apr 2014 14:06:36 -0400 r...@redhat.com wrote: > > > From: Rik van Riel > > > > Some sysrq handlers can run for a long time, because they dump a lot > > of data onto a serial console. Having RCU stall warnings pop up in > > the middle of them only makes the problem worse. > > > > This patch temporarily disables RCU stall warnings while a sysrq > > request is handled. > > > > ... > > > > drivers/tty/sysrq.c | 3 +++ > > include/linux/rcupdate.h | 12 > > kernel/rcu/update.c | 12 > > OK, what's going on here. Someone (of, I suspect, a Paulish nature) > has plucked out the rcu parts of this patch, put them in linux-next and > omitted the drivers/tty part. Very tricky! Sounds like something I might do... ;-) I intend to push this for the upcoming merge window, in case it matters. > I have done the opposite and have staged two patches against linux-next: > > http://ozlabs.org/~akpm/mmots/broken-out/sysrq-rcu-ify-__handle_sysrq.patch I defer to Rik for this one. > http://ozlabs.org/~akpm/mmots/broken-out/sysrqrcu-suppress-rcu-stall-warnings-while-sysrq-runs.patch The "[paul...@linux.vnet.ibm.com: fix TINY_RCU build error]" should be removed, since it goes with the patch I queued. Not that it matters that much, I suppose. Thanx, Paul > Please check, review, comment, etc. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/15] PCI/iommu: Fix DMA alias problems
Hi Alex On Fri, May 16, 2014 at 1:43 AM, Alex Williamson wrote: > On Thu, 2014-05-15 at 07:40 +0800, Andrew Cooks wrote: >> Hi Alex >> >> On Fri, May 9, 2014 at 11:28 PM, Alex Williamson >> wrote: >> > >> > >> > Original description: >> > >> > This series attempts to fix a couple issues we've had outstanding in >> > the PCI/IOMMU code for a while. The first issue is with devices that >> > use the wrong requester ID for DMA transactions. We already have a >> > sort of half-baked attempt to fix this for several Ricoh devices, but >> > the fix only helps them be useful through IOMMU groups, not the >> > general DMA case. There are also several Marvell devices which use >> > use a different wrong requester ID and don't even fit into the DMA >> > source idea. This series creates a DMA alias iterator that will >> > step through each possible alias of a device, allowing IOMMUs to >> > insert mappings for both the device and its aliases. >> > >> > Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() >> > function, which is known to blowup when it finds itself suddenly at >> > a PCIe device without crossing a PCIe-to-PCI bridge (as identified by >> > the PCIe capability). It also likes to make the invalid assumption >> > that a PCIe device never has its requester ID masked by any usptream >> > bus. We can fix this using the above new DMA alias iterator, since >> > that's effectively what this function was meant to do. >> > >> >> There are two cases where the DMA requester id seems to use the wrong >> slot (as opposed to function) in the patch I attached to >> https://bugzilla.kernel.org/show_bug.cgi?id=42679 >> The original bug reports are listed in the patch. >> >> Unfortunately, I wasn't able to get test feedback on those two cases, >> but I'm wondering... >> Did I understand correctly that a slot alias is something that could be >> needed? >> If so, is it a variation of the PCIe-to-PCI bridge case that's already >> covered or will it require a different approach? > > Wow, I didn't think that kind of broken was possible. Maybe instead of > a bitmap of function aliases we could have a single devfn alias for a > device. That means we'd only be able to support a single alias for a > device, but since I don't think we've seen devices that use more than a > single alias, maybe that's ok. The current patch creates a context entry for the reported device (function 0), plus it's alias (function 1). Is there reason to always add a context entry for the reported devfn and define 'alias' to mean 'one additional devfn'? That will work for all the Marvell cases. In the testing I did, the Marvell controllers needed context entries for both function 0 and 1. It would be nice if someone could confirm or debunk this. I tested with a 88SE9172 with both ports of the controller in use. Thanks, a. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 0/4] ACPI / LPSS: Solution for two issues seen on Asus T100
On 2014/5/16 0:11, Mika Westerberg wrote: > On Thu, May 15, 2014 at 11:59:46PM +0800, Li, Aubrey wrote: >> On 2014/5/15 22:53, Andy Shevchenko wrote: >>> On Thu, 2014-05-15 at 22:35 +0800, Li, Aubrey wrote: On 2014/5/15 21:40, Heikki Krogerus wrote: > Changes since v1: > - now using do_div() in clk_fd_recalc_rate() as suggested by Andy > - NULL checks for clk_name allocation in acpi_lpss.c > > This combines two patch sets for LPSS that I had already send for > review separately. They conflicted with each other. > > The first two patches will fix a problem were the context of the > private LPSS registers is lost when entering D3. The last two will add > support for the M/N dividers on LPSS by adding a new basic clock type > for fractional dividers. The UART driver needs support for it in order > to get clock rates that suit the requested baud rates. The major issue in my mind is, this proposal makes a couple between I2C designware, HSUART, or probably DMA driver as well with LPSS driver. >>> >>> acpi_lpss driver creates platform devices for each found and enumerated >>> device. >> >>> If there no acpi_lpss enabled the drivers work as supposed without it. >> >> This is not true. > > The drivers work fine on non-LPSS platform. If you make them depend on > acpi_lpss, you break that. > People don't know the relationship between LPSS driver and I2C/HSUART, there is nowhere to describe that. If LPSS driver is unchecked, they will encounter a weird issue which is very hard to figure out what's going on. Thanks, -Aubrey > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] checkpatch: Add warning for kmalloc/kzalloc with multiply
Protect against sizeof overflows by preferring
kmalloc_array/kcalloc over kmalloc/kzalloc
with a sizeof multiply.
Signed-off-by: Joe Perches
---
V2: Make it a WARN instead.
Add capability to --fix it too.
scripts/checkpatch.pl | 24
1 file changed, 24 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e7ff52a..7774025 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4378,6 +4378,30 @@ sub process {
"Prefer $3(sizeof(*$1)...) over $3($4...)\n" .
$herecurr);
}
+# check for k[mz]alloc with multiplies that could be kmalloc_array/kcalloc
+ if ($^V && $^V ge 5.10.0 &&
+ $line =~
/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/)
{
+ my $oldfunc = $3;
+ my $a1 = $4;
+ my $a2 = $10;
+ my $newfunc = "kmalloc_array";
+ $newfunc = "kcalloc" if ($oldfunc eq "kzalloc");
+ if ($a1 =~ /^sizeof\s*\S/ || $a2 =~ /^sizeof\s*\S/) {
+ if (WARN("ALLOC_WITH_MULTIPLY",
+"Prefer $newfunc over $oldfunc with
multiply\n" . $herecurr) &&
+ $fix) {
+ my $r1 = $a1;
+ my $r2 = $a2;
+ if ($a1 =~ /^sizeof\s*\S/) {
+ $r1 = $a2;
+ $r2 = $a1;
+ }
+ $fixed[$linenr - 1] =~
s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1
. ' = ' . "$newfunc(" . trim($r1) . ', ' . trim($r2)/e;
+
+ }
+ }
+ }
+
# check for krealloc arg reuse
if ($^V && $^V ge 5.10.0 &&
$line =~
/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*krealloc\s*\(\s*\1\s*,/) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sysrq,rcu: suppress RCU stall warnings while sysrq runs
On Tue, 29 Apr 2014 14:06:36 -0400 r...@redhat.com wrote: > From: Rik van Riel > > Some sysrq handlers can run for a long time, because they dump a lot > of data onto a serial console. Having RCU stall warnings pop up in > the middle of them only makes the problem worse. > > This patch temporarily disables RCU stall warnings while a sysrq > request is handled. > > ... > > drivers/tty/sysrq.c | 3 +++ > include/linux/rcupdate.h | 12 > kernel/rcu/update.c | 12 OK, what's going on here. Someone (of, I suspect, a Paulish nature) has plucked out the rcu parts of this patch, put them in linux-next and omitted the drivers/tty part. Very tricky! I have done the opposite and have staged two patches against linux-next: http://ozlabs.org/~akpm/mmots/broken-out/sysrq-rcu-ify-__handle_sysrq.patch http://ozlabs.org/~akpm/mmots/broken-out/sysrqrcu-suppress-rcu-stall-warnings-while-sysrq-runs.patch Please check, review, comment, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Fri, May 16, 2014 at 08:51:41AM +1000, Dave Chinner wrote: > On Fri, May 16, 2014 at 12:34:40AM +0200, Mateusz Guzik wrote: > > On Fri, May 16, 2014 at 08:21:35AM +1000, Dave Chinner wrote: > > > > IOW, a new column in mountinfo. For frozen filesystems it would contain > > > > 'frozen_by=[%s]:[%d]' (escaped comm, pid). > > > > > > I really don't see that the process that froze the filesystem is > > > particularly useful - it many cases that process is long gone (e.g. > > > fsfreeze is being used to allow a HW array to take a snapshot). Just > > > the fact it is in the process of freezing (if stuck, stack trace in > > > sysrq-w should be present) or frozen (freezing process may be long > > > gone, and is mostly irrelevant because you're now tracking down why > > > a thaw hasn't happened)... > > > > There are deamons which perform freezing and unfreezing on their own. > > Thus storing the name along with pid helps to determine whether someone > > went behind such daemon's back, or maybe it's the daemon which "forgot" to > > unfreeze after all. > > Such a daemon should be logging the fact that it's freezing and > thawing the filesystem. The kernel is not the place to track what > buggy userspace applications are doing wrong. > Except there is no log entry if /var got frozen (and this is not an imaginary example). Grabbig a debugger to inspect daemon's state is not exactly what your typical support associate can or should do. But this was a side request, I'm not going to argue about including this since turns out there is a better way. Somewhere in the thread an idea to log long-standing freezes was mentioned which would provide sufficient information as far as troubleshooting this stuff is concerned. Thanks and sorry :-> -- Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP
On Thu, May 15, 2014 at 10:55:45PM +0200, Paul Bolle wrote:
> Commit 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built")
> apparently required that checks for CONFIG_USB_GADGET_OMAP would be
> replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining
> checks for CONFIG_USB_GADGET_OMAP, even though these checks have
> basically been broken since v3.1.
>
> Fixes: 193ab2a60700 ("usb: gadget: allow multiple gadgets to be built")
> Signed-off-by: Paul Bolle
> ---
> Also untested.
>
> It seems efficient to also include the change to phy-isp1301-omap.c in
> this patch (ie, not ship that as a separate patch).
>
> arch/arm/mach-omap1/board-h2.c| 2 +-
> arch/arm/mach-omap1/board-h3.c| 2 +-
> arch/arm/mach-omap1/board-innovator.c | 2 +-
> arch/arm/mach-omap1/board-osk.c | 2 +-
> drivers/usb/phy/phy-isp1301-omap.c| 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index 65d2acb31498..57092bc7f4f1 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -346,7 +346,7 @@ static struct omap_usb_config h2_usb_config __initdata = {
> /* usb1 has a Mini-AB port and external isp1301 transceiver */
> .otg= 2,
>
> -#ifdef CONFIG_USB_GADGET_OMAP
> +#ifdef CONFIG_USB_OMAP
CONFIG_USB_OMAP is tristate, it might be better to use
IS_ENABLED(CONFIG_USB_OMAP) here. Likewise for the rest of the patch.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] checkpatch: Add --strict test for kmalloc/kzalloc with multiply
On Thu, 15 May 2014 16:04:46 -0700 Joe Perches wrote:
> On Thu, 2014-05-15 at 15:58 -0700, Andrew Morton wrote:
> > On Tue, 13 May 2014 16:48:49 -0700 Joe Perches wrote:
> > > Protect against sizeof overflows by preferring
> > > kmalloc_array and kcalloc to kmalloc/kzalloc
> > > with a sizeof multiply.
> []
> > > +# check for k[mz]alloc with multiplies that could be
> > > kmalloc_array/kcalloc
> > > + if ($^V && $^V ge 5.10.0 &&
> > > + $line =~
> > > /\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/)
> > > {
> > > + my $oldfunc = $3;
> > > + my $a1 = $4;
> > > + my $a2 = $10;
> > > + my $newfunc = "kmalloc_array";
> > > + $newfunc = "kcalloc" if ($oldfunc eq "kzalloc");
> > > + if ($a1 =~ /^sizeof\s*\S/ || $a2 =~ /^sizeof\s*\S/) {
> > > + CHK("ALLOC_WITH_MULTIPLY",
> > > + "Prefer $newfunc over $oldfunc with
> > > multiply\n" . $herecurr);
> > > + }
> > > + }
> > > +
> >
> > Why hide this behind --strict?
>
> Non-obvious CHK/--strict tests are less controversial.
>
> The block above it
> "prefer foo = alloc(sizeof(*foo)) over foo = alloc(sizeof(struct bar))"
> used CHK so I copied it.
>
> I've no objection to making it WARN instead,
I'd prefer that - this is one of my regular comment-on-during-review
things.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: Add --strict test for kmalloc/kzalloc with multiply
On Thu, 2014-05-15 at 15:58 -0700, Andrew Morton wrote:
> On Tue, 13 May 2014 16:48:49 -0700 Joe Perches wrote:
> > Protect against sizeof overflows by preferring
> > kmalloc_array and kcalloc to kmalloc/kzalloc
> > with a sizeof multiply.
[]
> > +# check for k[mz]alloc with multiplies that could be kmalloc_array/kcalloc
> > + if ($^V && $^V ge 5.10.0 &&
> > + $line =~
> > /\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/)
> > {
> > + my $oldfunc = $3;
> > + my $a1 = $4;
> > + my $a2 = $10;
> > + my $newfunc = "kmalloc_array";
> > + $newfunc = "kcalloc" if ($oldfunc eq "kzalloc");
> > + if ($a1 =~ /^sizeof\s*\S/ || $a2 =~ /^sizeof\s*\S/) {
> > + CHK("ALLOC_WITH_MULTIPLY",
> > + "Prefer $newfunc over $oldfunc with
> > multiply\n" . $herecurr);
> > + }
> > + }
> > +
>
> Why hide this behind --strict?
Non-obvious CHK/--strict tests are less controversial.
The block above it
"prefer foo = alloc(sizeof(*foo)) over foo = alloc(sizeof(struct bar))"
used CHK so I copied it.
I've no objection to making it WARN instead,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx: clean up error handling
Hello Dan,
Thanks for the review and sorry for the late reply.
On Thu, May 15, 2014 at 11:32:13PM +0300, Dan Carpenter wrote:
> On Thu, May 15, 2014 at 09:24:30PM +0200, Emil Goode wrote:
> > If we fail to allocate struct platform_device pdev we
> > dereference it after the goto label err.
> >
> > I have rearranged the error handling a bit to fix the issue
> > and also make it more clear.
> >
> > Signed-off-by: Emil Goode
> > ---
> > arch/arm/mach-imx/devices/platform-ipu-core.c | 22 +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > index fc4dd7c..14d61d9 100644
> > --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > @@ -77,34 +77,38 @@ struct platform_device *__init imx_alloc_mx3_camera(
> >
> > pdev = platform_device_alloc("mx3-camera", 0);
> > if (!pdev)
> > - goto err;
> > + return ERR_PTR(ret);
>
> It's more readable to say "return ERR_PTR(-ENOMEM);".
I think so to, will change this one but still use the ret variable at the
bottom of the function.
>
> This patch is great but the subject should say "fix" and not "clean up"
> since it fixes a NULL dereference bug. The people who call their
> checkpatch.pl clean ups "fixes" are also doing it wrong but those are
> newbies and not worth educating.
I agree, it's a bug fix and not a clean up.
Will resend tomorrow.
Best regards,
Emil Goode
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: fix exec_start/task_hot on migrated tasks
task_hot checks exec_start on any runnable task, but if it has been migrated since the it last ran, then exec_start is a clock_task from another cpu. If the old cpu's clock_task was sufficiently far ahead of this cpu's then the task will not be considered for another migration until it has run. Instead reset exec_start whenever a task is migrated, since it is presumably no longer hot anyway. Signed-off-by: Ben Segall --- kernel/sched/fair.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 28ccf50..9f8dfeb 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4544,6 +4544,9 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu) atomic_long_add(se->avg.load_avg_contrib, _rq->removed_load); } + + /* We have migrated, no longer consider this task hot */ + se.exec_start = 0; } #endif /* CONFIG_SMP */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: Add --strict test for kmalloc/kzalloc with multiply
On Tue, 13 May 2014 16:48:49 -0700 Joe Perches wrote:
> Protect against sizeof overflows by preferring
> kmalloc_array and kcalloc to kmalloc/kzalloc
> with a sizeof multiply.
>
> ...
>
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4378,6 +4378,20 @@ sub process {
> "Prefer $3(sizeof(*$1)...) over $3($4...)\n" .
> $herecurr);
> }
>
> +# check for k[mz]alloc with multiplies that could be kmalloc_array/kcalloc
> + if ($^V && $^V ge 5.10.0 &&
> + $line =~
> /\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*(k[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/)
> {
> + my $oldfunc = $3;
> + my $a1 = $4;
> + my $a2 = $10;
> + my $newfunc = "kmalloc_array";
> + $newfunc = "kcalloc" if ($oldfunc eq "kzalloc");
> + if ($a1 =~ /^sizeof\s*\S/ || $a2 =~ /^sizeof\s*\S/) {
> + CHK("ALLOC_WITH_MULTIPLY",
> + "Prefer $newfunc over $oldfunc with
> multiply\n" . $herecurr);
> + }
> + }
> +
Why hide this behind --strict?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/6] acerhdf/thermal: adding new models, appropriate governor and minor clean up
Hi Eduardo, Eduardo Valentin writes: Hello Peter, On Sat, May 03, 2014 at 07:59:20PM +0200, Peter Feuerer wrote: Hi, This patch series is intended to: * Introduce "manual mode" support (Patch 1 & 2), which is needed to control the fan of a few new models. * Add an appropriate thermal governor (Patch 3 & 4). Manipulating and fiddling around with the step-wise governor has been a very fragile thing in the past and as it broke again, I used the opportunity to add a two point thermal governor which implements the actual fan handling required by acerhdf and puts from my point of view things straight. Can you please provide more groundings why step_wise is not working? Step_wise does (or did) not support hysteresis functionality, so what we've done in the past was to manipulate the fan handling within acerhdf (e.g. reporting different trip temperature, based whether the fan is on or not). But this was very fragile and with each change in step_wise we had to find another method to somehow fit acerhdf into it again. Step_wise is clearly intended for fans which can be regulated in speed and it has some fancy algorithms like trend monitoring which work fine there. But for the audience of acerhdf it has always been overkill and they've noticed broken fan control, when things changed in step_wise again. I had a look on bang bang proposal patch and to me, at a first glance, step_wise should cover the target behavior. Of course, that also depend on the cooling device you attach to it. Actually even Rui stated a while ago, creation of a separate governor would be one thinkable solution to get a more robust solution for the two step regulation of acerhdf. Is it possible to report the problems you have with step_wise? This way we could benefit the other users of it as well. There is no problem in step_wise in general. It is just so, that the governor is overkill for the simple on-off fan of acerhdf. And what's the deal of having plugable governors, when you try to fit every single feature into one gigantic? Aren't the unix philosophies of modularity, serparation and simplicity valid in the kernel too? kind regards, --peter; * Do some minor clean up like: - adding second trip point for critical temperature (Patch 5) - removing _t suffix from struct which isn't typedef and replace unsigned char by u8 (Patch 6) Thanks and kind regards, peter Cc: Andrew Morton Cc: Andreas Mohr Cc: Borislav Petkov Cc: Zhang Rui Cc: Javi Merino Peter Feuerer (6): acerhdf: Adding support for "manual mode" acerhdf: Adding support for new models thermal: Added Bang-bang thermal governor acerhdf: Use bang-bang thermal governor acerhdf: added critical trip point acerhdf: minor clean up drivers/platform/x86/Kconfig| 2 +- drivers/platform/x86/acerhdf.c | 260 +--- drivers/thermal/Kconfig | 10 ++ drivers/thermal/Makefile| 1 + drivers/thermal/gov_bang_bang.c | 131 drivers/thermal/thermal_core.c | 5 + drivers/thermal/thermal_core.h | 8 ++ 7 files changed, 321 insertions(+), 96 deletions(-) create mode 100644 drivers/thermal/gov_bang_bang.c -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Fri, May 16, 2014 at 12:34:40AM +0200, Mateusz Guzik wrote: > On Fri, May 16, 2014 at 08:21:35AM +1000, Dave Chinner wrote: > > > IOW, a new column in mountinfo. For frozen filesystems it would contain > > > 'frozen_by=[%s]:[%d]' (escaped comm, pid). > > > > I really don't see that the process that froze the filesystem is > > particularly useful - it many cases that process is long gone (e.g. > > fsfreeze is being used to allow a HW array to take a snapshot). Just > > the fact it is in the process of freezing (if stuck, stack trace in > > sysrq-w should be present) or frozen (freezing process may be long > > gone, and is mostly irrelevant because you're now tracking down why > > a thaw hasn't happened)... > > There are deamons which perform freezing and unfreezing on their own. > Thus storing the name along with pid helps to determine whether someone > went behind such daemon's back, or maybe it's the daemon which "forgot" to > unfreeze after all. Such a daemon should be logging the fact that it's freezing and thawing the filesystem. The kernel is not the place to track what buggy userspace applications are doing wrong. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i915: Add module option to support VGA arbiter on HD devices
On Thu, May 15, 2014 at 11:43 PM, Alex Williamson wrote: > I don't know what to do with this. It seems like a lot of wishful > thinking that in the best case would drag on for years. Even if we get > VGA arbitration out of Xorg, the bit about making the userspace VGA > arbiter interface lie depending on current->comm sounds tricky and > horrible. If we can lie to Xorg there, why don't we do that now? If we > can't lie to Xorg now, then what deprecation event or detection of the > caller is going to allow us to do so in the future? Well we wouldn't necessarily need to lie to X, but could instead look whether all the vga devices in a system are claimed by kms drivers. If that's the case the userspace doesn't have an awful lot of business touching the VGA registers and we could simply not obey a vga arb request from userspace. More advanced would be if we still obey it for those devices not claimed by kms drivers. So not really a need to key on current->comm. > Meanwhile anyone that wants i915 to participate in arbitration like it > should have from the start needs to patch their kernel with forward > ports of the reverted commits. > > I just don't see this moving forward, which is why I thought a module > option at least gives us a workaround. Thanks, I know that this is awful, but a module option means that the few people interested in moving this forward will be happy enough to no longer bother. Which is even worse from my pov as driver maintainer. I highly consider module options used in production evil. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hello From KM
Good Day, Please letâs talk and see if we can partner together to achieve our various future goals. Lets talk about real business deal. Regards, KM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for possible null pointer dereference in node.c
On Thu, May 15, 2014 at 11:53:53PM +0200, Rickard Strandqvist wrote: > There is otherwise a risk of a possible null pointer dereference. > None of the callers pass in a NULL hnode so there isn't actually a NULL dereference here. You could just remove the check. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm, hugetlb: move the error handle logic out of normal code path
On Wed, 2014-05-14 at 15:10 +0800, Jianyu Zhan wrote: > alloc_huge_page() now mixes normal code path with error handle logic. > This patches move out the error handle logic, to make normal code > path more clean and redue code duplicate. > > Signed-off-by: Jianyu Zhan Acked-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm, hugetlb: move the error handle logic out of normal code path
On Thu, 15 May 2014 11:01:42 +0200 Michal Hocko wrote:
> On Wed 14-05-14 15:10:59, Jianyu Zhan wrote:
> > alloc_huge_page() now mixes normal code path with error handle logic.
> > This patches move out the error handle logic, to make normal code
> > path more clean and redue code duplicate.
>
> I don't know. Part of the function returns and cleans up on its own and
> other part relies on clean up labels. This is not so much nicer than the
> previous state.
That's actually a common pattern:
foo()
{
if (check which doesn't change any state)
return -Efoo;
if (another check which doesn't change any state)
return -Ebar;
do_something_which_changes_state()
if (another check)
goto undo_that_state_chage;
...
undo_that_state_change:
...
}
This ties into the main reason why we use all these gotos: to support
evolution of the code. With multiple return points we risk later
adding resource leaks and locking errors. Plus the code becomes more
and more duplicative and spaghettified.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Fri, May 16, 2014 at 08:21:35AM +1000, Dave Chinner wrote: > On Thu, May 15, 2014 at 12:47:48PM +0200, Mateusz Guzik wrote: > > On Thu, May 15, 2014 at 12:40:19PM +0200, Lukáš Czerner wrote: > > > On Wed, 14 May 2014, Eric Sandeen wrote: > > > > > > > Date: Wed, 14 May 2014 17:40:22 -0500 > > > > From: Eric Sandeen > > > > Reply-To: sand...@redhat.com > > > > To: Dave Chinner , Jan Kara > > > > Cc: Mateusz Guzik , linux-kernel@vger.kernel.org, > > > > linux-fsde...@vger.kernel.org, Josef Bacik , > > > > Al Viro , Joe Perches > > > > Subject: Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing > > > > filesystems > > > > > > > > On 5/14/14, 5:37 PM, Dave Chinner wrote: > > > > > On Thu, May 15, 2014 at 08:00:52AM +1000, Dave Chinner wrote: > > > > >> On Wed, May 14, 2014 at 01:39:45PM +0200, Jan Kara wrote: > > > > >>> On Wed 14-05-14 13:26:21, Mateusz Guzik wrote: > > > > On Wed, May 14, 2014 at 01:14:49PM +0200, Jan Kara wrote: > > > > > On Wed 14-05-14 00:04:43, Mateusz Guzik wrote: > > > > >> This helps hang troubleshooting efforts when only dmesg is > > > > >> available. > > > > >> > > > > >> While here remove code duplication with MS_RDONLY case and fix a > > > > >> whitespace nit. > > > > > I'm somewhat undecided here I have to say. On one hand I don't > > > > > like > > > > > printing to kernel log when everything is fine and kernel is > > > > > operating > > > > > normally. On the other hand I've seen quite a few cases where > > > > > people have > > > > > shot themselves in the foot with filesystem freezing so having > > > > > some trace > > > > > of this in the log doesn't seem like a completely bad thing > > > > > either. What do > > > > > other people think? > > > > > > > > > > > > > I would like to note that the kernel already prints messages when > > > > e.g. > > > > filesystems get mounted. > > > > >>> Yeah, that's a fair point. > > > > >> > > > > >> But filesystems choose to output that info, not the VFS. When you do > > > > >> a remount,ro there is no output in syslog, because filesystems don't > > > > >> need to dump any output - the state change is reflected in > > > > >> /proc/self/mounts. IMO frozen should state should be communicated > > > > >> the same way so that it is silent when it just works, and the state > > > > >> can easily be determined when something goes wrong. > > > > > > > > > > Say, like this: > > > > > > > > > > $ grep /mnt/test /proc/mounts > > > > > /dev/vda /mnt/test xfs rw,relatime,attr2,inode64,noquota 0 0 > > > > > $ sudo xfs_freeze -f /mnt/test > > > > > $ grep /mnt/test /proc/mounts > > > > > /dev/vda /mnt/test xfs rw,frozen,relatime,attr2,inode64,noquota 0 0 > > > > > $ sudo xfs_freeze -u /mnt/test > > > > > $ grep /mnt/test /proc/mounts > > > > > /dev/vda /mnt/test xfs rw,relatime,attr2,inode64,noquota 0 0 > > > > > $ > > > > > > > > I'm not totally convinced that including a non-mount option in what > > > > has always (?) been a list of mount options is a great idea. > > > > > > I do not like it either. Mixing this together with other mount > > > options does not seem like a great idea, however we really need a > > > way to report this and I guess we can not just change the > > > /proc/self/mounts, or /proc/self/mountinfo format. > > > > > > So what about crating a new file /proc/self/frozen with the list of > > > frozen file systems in the same format what mounts, or mountinfo has > > > ? > > > > > > > As the time goes on there will be more data to present about given > > mountpoint. So either mountinfo should be extendable to support this > > (can't see why not) or new generic file with that property should be > > provided. I vote for the former. > > > > IOW, a new column in mountinfo. For frozen filesystems it would contain > > 'frozen_by=[%s]:[%d]' (escaped comm, pid). > > I really don't see that the process that froze the filesystem is > particularly useful - it many cases that process is long gone (e.g. > fsfreeze is being used to allow a HW array to take a snapshot). Just > the fact it is in the process of freezing (if stuck, stack trace in > sysrq-w should be present) or frozen (freezing process may be long > gone, and is mostly irrelevant because you're now tracking down why > a thaw hasn't happened)... > There are deamons which perform freezing and unfreezing on their own. Thus storing the name along with pid helps to determine whether someone went behind such daemon's back, or maybe it's the daemon which "forgot" to unfreeze after all. -- Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?
Hi Mark, Thank you for the quick reply. On Thursday 15 May 2014 15:08:44 Mark A. Greer wrote: > On Thu, May 15, 2014 at 10:29:26PM +0200, Laurent Pinchart wrote: > > Hello, > > [Adding Anton Vorontsov to CC list.] > > Hi Laurent. > > > I'm trying to enable battery charging on an OMAP4 board based on a twl6030 > > PMIC with external bq24190 battery charger and bq27510 fuel gauge. > > > > The system has an OTG USB port that can be used to charge the battery, and > > that can also be used in host mode. In that case the bq24190 needs to be > > switched to boost mode to provide the +5V power supply from the battery. > > > > The bq24190 has a charge configuration register field that supports charge > > disabled, charge enabled and OTG (boost mode). The field is set by the > > bq24190 driver in response to setting the charge type : > > POWER_SUPPLY_CHARGE_TYPE_NONE will disable charing, and > > POWER_SUPPLY_CHARGE_TYPE_TRICKLE and > > POWER_SUPPLY_CHARGE_TYPE_FAST will enable it. However, OTG boost mode is > > not supported. > > > > > > The driver exposes most register fields as sysfs attributes (which doesn't > > sound very safe to me, but that's another story). I can thus enable OTG > > boost mode directly from userspace through the driver-specific API, but > > that just bypasses the power supply API. I'm thus not very fond of that > > solution. > > No, its not a good solution. As indicated in the commit log, the sysfs > entries are there because there are just so many fields that don't map > well to the existing interface. > > Maybe we should add support for a DT entry to enable exporting those > fields(disabled by default)? > > > Possibly due to my really basic (not to say nonexistent) knowledge of the > > power supply subsystem I haven't found an API to expose this feature. I > > was wondering if someone had given a though regarding how to implement > > this properly. > > What if we just added something like POWER_SUPPLY_CHARGE_TYPE_BOOST? That was actually my first thought, and I assumed it would be rejected as boost mode is not a charge type but a discharge type :-) This being said, I don't have enough experience with battery chargers to decide whether this is a good solution. If you believe it is, I'll trust you on that. On a side note, is there any reference userspace implementation of a battery manager ? The vendor BSP I've received with the board hardcodes calls to the bq24190 in the MUSB driver to switch between OTG and trickle charge modes based on USB cable connection/disconnection events. That's pretty ugly, and I assume this should be handled in userspace - or is there a standard kernel infrastructure for that ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] x86: SROP mitigation: implement signal canaries
On Thu, May 15, 2014 at 02:31:40PM -0700, Andi Kleen wrote: > Erik Bosman writes: > > > > > diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c > > index 2206757..1a9285a 100644 > > --- a/arch/x86/ia32/ia32_signal.c > > +++ b/arch/x86/ia32/ia32_signal.c > > @@ -212,9 +212,18 @@ asmlinkage long sys32_sigreturn(void) > > struct sigframe_ia32 __user *frame = (struct sigframe_ia32 __user > > *)(regs->sp-8); > > sigset_t set; > > unsigned int ax; > > +#ifdef CONFIG_SIGNAL_CANARY > > + u32 canary; > > +#endif > > Don't you completely break the ABI here? I'm sure there are programs out > there who hard code the offset into the FP state. > > I think you either need to put it at the total end or somewhere > currently unused > Hrmz.. FP state is aligned on a 64 byte boundary, the signal frame (separately) on a 16 byte-sizeof(long) boundary. But it looks like that for 32 and 64 bit rt_sigreturn this means no padding :-/ It looks like I'll have to put the canary beyond the fp state. :-( I had hoped to avoid pointer arithmetic. :-/ Erik > Besides that I would remove the CONFIG_* once it works and just do it > unconditionally. > > -Andi > > > -- > a...@linux.intel.com -- Speaking for myself only > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Thu, May 15, 2014 at 12:47:48PM +0200, Mateusz Guzik wrote: > On Thu, May 15, 2014 at 12:40:19PM +0200, Lukáš Czerner wrote: > > On Wed, 14 May 2014, Eric Sandeen wrote: > > > > > Date: Wed, 14 May 2014 17:40:22 -0500 > > > From: Eric Sandeen > > > Reply-To: sand...@redhat.com > > > To: Dave Chinner , Jan Kara > > > Cc: Mateusz Guzik , linux-kernel@vger.kernel.org, > > > linux-fsde...@vger.kernel.org, Josef Bacik , > > > Al Viro , Joe Perches > > > Subject: Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing > > > filesystems > > > > > > On 5/14/14, 5:37 PM, Dave Chinner wrote: > > > > On Thu, May 15, 2014 at 08:00:52AM +1000, Dave Chinner wrote: > > > >> On Wed, May 14, 2014 at 01:39:45PM +0200, Jan Kara wrote: > > > >>> On Wed 14-05-14 13:26:21, Mateusz Guzik wrote: > > > On Wed, May 14, 2014 at 01:14:49PM +0200, Jan Kara wrote: > > > > On Wed 14-05-14 00:04:43, Mateusz Guzik wrote: > > > >> This helps hang troubleshooting efforts when only dmesg is > > > >> available. > > > >> > > > >> While here remove code duplication with MS_RDONLY case and fix a > > > >> whitespace nit. > > > > I'm somewhat undecided here I have to say. On one hand I don't > > > > like > > > > printing to kernel log when everything is fine and kernel is > > > > operating > > > > normally. On the other hand I've seen quite a few cases where > > > > people have > > > > shot themselves in the foot with filesystem freezing so having some > > > > trace > > > > of this in the log doesn't seem like a completely bad thing either. > > > > What do > > > > other people think? > > > > > > > > > > I would like to note that the kernel already prints messages when > > > e.g. > > > filesystems get mounted. > > > >>> Yeah, that's a fair point. > > > >> > > > >> But filesystems choose to output that info, not the VFS. When you do > > > >> a remount,ro there is no output in syslog, because filesystems don't > > > >> need to dump any output - the state change is reflected in > > > >> /proc/self/mounts. IMO frozen should state should be communicated > > > >> the same way so that it is silent when it just works, and the state > > > >> can easily be determined when something goes wrong. > > > > > > > > Say, like this: > > > > > > > > $ grep /mnt/test /proc/mounts > > > > /dev/vda /mnt/test xfs rw,relatime,attr2,inode64,noquota 0 0 > > > > $ sudo xfs_freeze -f /mnt/test > > > > $ grep /mnt/test /proc/mounts > > > > /dev/vda /mnt/test xfs rw,frozen,relatime,attr2,inode64,noquota 0 0 > > > > $ sudo xfs_freeze -u /mnt/test > > > > $ grep /mnt/test /proc/mounts > > > > /dev/vda /mnt/test xfs rw,relatime,attr2,inode64,noquota 0 0 > > > > $ > > > > > > I'm not totally convinced that including a non-mount option in what > > > has always (?) been a list of mount options is a great idea. > > > > I do not like it either. Mixing this together with other mount > > options does not seem like a great idea, however we really need a > > way to report this and I guess we can not just change the > > /proc/self/mounts, or /proc/self/mountinfo format. > > > > So what about crating a new file /proc/self/frozen with the list of > > frozen file systems in the same format what mounts, or mountinfo has > > ? > > > > As the time goes on there will be more data to present about given > mountpoint. So either mountinfo should be extendable to support this > (can't see why not) or new generic file with that property should be > provided. I vote for the former. > > IOW, a new column in mountinfo. For frozen filesystems it would contain > 'frozen_by=[%s]:[%d]' (escaped comm, pid). I really don't see that the process that froze the filesystem is particularly useful - it many cases that process is long gone (e.g. fsfreeze is being used to allow a HW array to take a snapshot). Just the fact it is in the process of freezing (if stuck, stack trace in sysrq-w should be present) or frozen (freezing process may be long gone, and is mostly irrelevant because you're now tracking down why a thaw hasn't happened)... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tools lib traceevent: Added support for __get_bitmask() macro
Coming in v3.16, trace events will be able to save bitmasks in raw
format in the ring buffer and output it with the __get_bitmask() macro.
In order for userspace tools to parse this, it must be able to handle
the __get_bitmask() call and be able to convert the data that's in
the ring buffer into a nice bitmask format. The output is similar to
what the kernel uses to print bitmasks, with a comma separator every
4 bytes (8 characters).
This allows for cpumasks to also be saved efficiently.
The first user is the thermal:thermal_power_limit event which has the
following output:
thermal_power_limit: cpus=000f freq=190 cdev_state=0 power=5252
Link: http://lkml.kernel.org/r/20140506132238.22e13...@gandalf.local.home
Suggested-by: Javi Merino
Tested-by: Javi Merino
Signed-off-by: Steven Rostedt
---
tools/lib/traceevent/event-parse.c | 113 +
tools/lib/traceevent/event-parse.h | 7 +++
2 files changed, 120 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index baec7d8..c76ca5c 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -765,6 +765,9 @@ static void free_arg(struct print_arg *arg)
case PRINT_BSTRING:
free(arg->string.string);
break;
+ case PRINT_BITMASK:
+ free(arg->bitmask.bitmask);
+ break;
case PRINT_DYNAMIC_ARRAY:
free(arg->dynarray.index);
break;
@@ -2268,6 +2271,7 @@ static int arg_num_eval(struct print_arg *arg, long long
*val)
case PRINT_FIELD ... PRINT_SYMBOL:
case PRINT_STRING:
case PRINT_BSTRING:
+ case PRINT_BITMASK:
default:
do_warning("invalid eval type %d", arg->type);
ret = 0;
@@ -2296,6 +2300,7 @@ static char *arg_eval (struct print_arg *arg)
case PRINT_FIELD ... PRINT_SYMBOL:
case PRINT_STRING:
case PRINT_BSTRING:
+ case PRINT_BITMASK:
default:
do_warning("invalid eval type %d", arg->type);
break;
@@ -2683,6 +2688,35 @@ process_str(struct event_format *event __maybe_unused,
struct print_arg *arg,
return EVENT_ERROR;
}
+static enum event_type
+process_bitmask(struct event_format *event __maybe_unused, struct print_arg
*arg,
+ char **tok)
+{
+ enum event_type type;
+ char *token;
+
+ if (read_expect_type(EVENT_ITEM, ) < 0)
+ goto out_free;
+
+ arg->type = PRINT_BITMASK;
+ arg->bitmask.bitmask = token;
+ arg->bitmask.offset = -1;
+
+ if (read_expected(EVENT_DELIM, ")") < 0)
+ goto out_err;
+
+ type = read_token();
+ *tok = token;
+
+ return type;
+
+ out_free:
+ free_token(token);
+ out_err:
+ *tok = NULL;
+ return EVENT_ERROR;
+}
+
static struct pevent_function_handler *
find_func_handler(struct pevent *pevent, char *func_name)
{
@@ -2797,6 +2831,10 @@ process_function(struct event_format *event, struct
print_arg *arg,
free_token(token);
return process_str(event, arg, tok);
}
+ if (strcmp(token, "__get_bitmask") == 0) {
+ free_token(token);
+ return process_bitmask(event, arg, tok);
+ }
if (strcmp(token, "__get_dynamic_array") == 0) {
free_token(token);
return process_dynamic_array(event, arg, tok);
@@ -3324,6 +3362,7 @@ eval_num_arg(void *data, int size, struct event_format
*event, struct print_arg
return eval_type(val, arg, 0);
case PRINT_STRING:
case PRINT_BSTRING:
+ case PRINT_BITMASK:
return 0;
case PRINT_FUNC: {
struct trace_seq s;
@@ -3556,6 +3595,60 @@ static void print_str_to_seq(struct trace_seq *s, const
char *format,
trace_seq_printf(s, format, str);
}
+static void print_bitmask_to_seq(struct pevent *pevent,
+struct trace_seq *s, const char *format,
+int len_arg, const void *data, int size)
+{
+ int nr_bits = size * 8;
+ int str_size = (nr_bits + 3) / 4;
+ int len = 0;
+ char buf[3];
+ char *str;
+ int index;
+ int i;
+
+ /*
+* The kernel likes to put in commas every 32 bits, we
+* can do the same.
+*/
+ str_size += (nr_bits - 1) / 32;
+
+ str = malloc(str_size + 1);
+ if (!str) {
+ do_warning("%s: not enough memory!", __func__);
+ return;
+ }
+ str[str_size] = 0;
+
+ /* Start out with -2 for the two chars per byte */
+ for (i = str_size - 2; i >= 0; i -= 2) {
+ /*
+* data points to a bit mask of size bytes.
+* In the kernel, this is an array of long words, thus
+*
Re: [PATCH 1/3] lib: add glibc style strchrnul() variant
On 5/13/2014 7:58 AM, Grant Likely wrote:
> The strchrnul() variant helpfully returns a the end of the string
> instead of a NULL if the requested character is not found. This can
> simplify string parsing code since it doesn't need to expicitly check
> for a NULL return. If a valid string pointer is passed in, then a valid
> null terminated string will always come back out.
>
> Signed-off-by: Grant Likely
> ---
> include/linux/string.h | 3 +++
> lib/string.c | 15 +++
> 2 files changed, 18 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index ac889c5ea11b..d36977e029af 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -52,6 +52,9 @@ extern int strncasecmp(const char *s1, const char *s2,
> size_t n);
> #ifndef __HAVE_ARCH_STRCHR
> extern char * strchr(const char *,int);
> #endif
> +#ifndef __HAVE_ARCH_STRCHRNUL
> +extern char * strchrnul(const char *,int);
> +#endif
> #ifndef __HAVE_ARCH_STRNCHR
> extern char * strnchr(const char *, size_t, int);
> #endif
> diff --git a/lib/string.c b/lib/string.c
> index 9b1f9062a202..059636f92c26 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -301,6 +301,21 @@ char *strchr(const char *s, int c)
> EXPORT_SYMBOL(strchr);
> #endif
>
> +#ifndef __HAVE_ARCH_STRCHRNUL
> +/**
> + * strchr - Find the first occurrence of a character in a string
s/strchr/strchrnul/
Add to the end of the description: if c is not found in s then return
a pointer to the null byte at the end of s
> + * @s: The string to be searched
> + * @c: The character to search for
> + */
> +char *strchrnul(const char *s, int c)
> +{
> + while (*s && *s != (char)c)
> + s++;
> + return (char *)s;
> +}
> +EXPORT_SYMBOL(strchrnul);
> +#endif
> +
> #ifndef __HAVE_ARCH_STRRCHR
> /**
> * strrchr - Find the last occurrence of a character in a string
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems
On Thu, May 15, 2014 at 12:13:56PM +0200, Jan Kara wrote: > On Thu 15-05-14 08:37:45, Dave Chinner wrote: > > On Thu, May 15, 2014 at 08:00:52AM +1000, Dave Chinner wrote: > > > On Wed, May 14, 2014 at 01:39:45PM +0200, Jan Kara wrote: > > > > On Wed 14-05-14 13:26:21, Mateusz Guzik wrote: > > > > > On Wed, May 14, 2014 at 01:14:49PM +0200, Jan Kara wrote: > > > > > > On Wed 14-05-14 00:04:43, Mateusz Guzik wrote: > > > > > > > This helps hang troubleshooting efforts when only dmesg is > > > > > > > available. > > > > > > > > > > > > > > While here remove code duplication with MS_RDONLY case and fix a > > > > > > > whitespace nit. > > > > > > I'm somewhat undecided here I have to say. On one hand I don't > > > > > > like > > > > > > printing to kernel log when everything is fine and kernel is > > > > > > operating > > > > > > normally. On the other hand I've seen quite a few cases where > > > > > > people have > > > > > > shot themselves in the foot with filesystem freezing so having some > > > > > > trace > > > > > > of this in the log doesn't seem like a completely bad thing either. > > > > > > What do > > > > > > other people think? > > > > > > > > > > > > > > > > I would like to note that the kernel already prints messages when e.g. > > > > > filesystems get mounted. > > > > Yeah, that's a fair point. > > > > > > But filesystems choose to output that info, not the VFS. When you do > > > a remount,ro there is no output in syslog, because filesystems don't > > > need to dump any output - the state change is reflected in > > > /proc/self/mounts. IMO frozen should state should be communicated > > > the same way so that it is silent when it just works, and the state > > > can easily be determined when something goes wrong. > > > > Say, like this: > > > > $ grep /mnt/test /proc/mounts > > /dev/vda /mnt/test xfs rw,relatime,attr2,inode64,noquota 0 0 > > $ sudo xfs_freeze -f /mnt/test > > $ grep /mnt/test /proc/mounts > > /dev/vda /mnt/test xfs rw,frozen,relatime,attr2,inode64,noquota 0 0 > > $ sudo xfs_freeze -u /mnt/test > > $ grep /mnt/test /proc/mounts > > /dev/vda /mnt/test xfs rw,relatime,attr2,inode64,noquota 0 0 > > $ > > > > Patch below does this. > Hum, same as Eric I'm not very enthusiastic about a fake mount option in > /proc/mounts. Maybe we could stuff some extra field in /proc/self/mountinfo? sure - I'd forgotten about /proc/self/mountinfo, but the way i wrote the patch will also dump the information into it. It's just a case of moving the code to show_mountinfo() rather than show_sb_opts(). If that's acceptible for everyone, then I'll update the patch to do that Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bq24190: What's the correct API to turn boost mode (OTG) on for the battery charger ?
On Thu, May 15, 2014 at 10:29:26PM +0200, Laurent Pinchart wrote: > Hello, [Adding Anton Vorontsov to CC list.] Hi Laurent. > I'm trying to enable battery charging on an OMAP4 board based on a twl6030 > PMIC with external bq24190 battery charger and bq27510 fuel gauge. > > The system has an OTG USB port that can be used to charge the battery, and > that can also be used in host mode. In that case the bq24190 needs to be > switched to boost mode to provide the +5V power supply from the battery. > > The bq24190 has a charge configuration register field that supports charge > disabled, charge enabled and OTG (boost mode). The field is set by the > bq24190 > driver in response to setting the charge type : POWER_SUPPLY_CHARGE_TYPE_NONE > will disable charing, and POWER_SUPPLY_CHARGE_TYPE_TRICKLE and > POWER_SUPPLY_CHARGE_TYPE_FAST will enable it. However, OTG boost mode is not > supported. > > The driver exposes most register fields as sysfs attributes (which doesn't > sound very safe to me, but that's another story). I can thus enable OTG boost > mode directly from userspace through the driver-specific API, but that just > bypasses the power supply API. I'm thus not very fond of that solution. No, its not a good solution. As indicated in the commit log, the sysfs entries are there because there are just so many fields that don't map well to the existing interface. Maybe we should add support for a DT entry to enable exporting those fields(disabled by default)? > Possibly due to my really basic (not to say nonexistent) knowledge of the > power supply subsystem I haven't found an API to expose this feature. I was > wondering if someone had given a though regarding how to implement this > properly. What if we just added something like POWER_SUPPLY_CHARGE_TYPE_BOOST? Mark -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm: NULL ptr deref handling mmaping of special mappings
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov wrote: > On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote: >> > >> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of >> > variables >> > be kind of immutable constants? If yes, we could calculate where the >> > additional >> > vma lives without requiring any kind of [vdso] mark in proc/pid/maps >> > output. >> >> Please don't! >> >> These might, in principle, even vary between tasks on the same system. >> Certainly the relative positions of the vmas will be different >> between 3.15 and 3.16, since we need almost my entire cleanup series >> to reliably put them into their 3.16 location. And I intend to change >> the number of pages in 3.16 or 3.17. > > There are other ways how to find where additional pages are laying but it > would be great if there a straightforward interface for that (ie some mark > in /proc/pid/maps output). I'll try to write a patch in time for 3.15. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for possible null pointer dereference in node.c
Hi all, and Greg! Good idea! I will do it in all the other mail. Best regards Rickard Strandqvist 2014-05-16 0:08 GMT+02:00 Greg Kroah-Hartman : > On Thu, May 15, 2014 at 11:53:53PM +0200, Rickard Strandqvist wrote: >> There is otherwise a risk of a possible null pointer dereference. >> >> Was largely found by using a static code analysis program called cppcheck. >> >> Signed-off-by: Rickard Strandqvist >> --- >> drivers/staging/tidspbridge/rmgr/node.c |4 ++-- >> 1 fil ändrad, 2 tillägg(+), 2 borttagningar(-) > > Please work a bit on your Subject lines to make it easier to figure out > where the patches belong. > > For this one, it should be: > Subject: staging: tidspridge: fix for possible null pointer > dereference in node.c > or: > Subject: staging: tidspridge: node.c: fix for possible null pointer > dereference > > That way people can figure out _what_ node.c file you are referring to > and to see if they care about it or not :) > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Thu, May 15, 2014 at 05:42:54PM +, Serge Hallyn wrote: > What exactly defines '"normal" use case for a container'? Well, I'd say "acting like a virtual machine" is a good start :) > Not too long ago much of what we can now do with network namespaces > was not a normal container use case. Neither "you can't do it now" > nor "I don't use it like that" should be grounds for a pre-emptive > nack. "It will horribly break security assumptions" certainly would > be. I agree, and maybe we will get there over time, but this patch is nto the way to do that. > That's not to say there might not be good reasons why this in particular > is not appropriate, but ISTM if things are going to be nacked without > consideration of the patchset itself, we ought to be having a ksummit > session to come to a consensus [ or receive a decree, presumably by you :) > but after we have a chance to make our case ] on what things are going to > be un/acceptable. I already stood up and publically said this last year at Plumbers, why is anything now different? And this patchset is proof of why it's not a good idea. You really didn't do anything with all of the namespace stuff, except change loop. That's the only thing that cares, so, just do it there, like I said to do so, last August. And you are ignoring the notifications to userspace and how namespaces here would deal with that. > > > Serge mentioned something to me about a loopdevfs (?) thing that someone > > > else is working on. That would seem to be a better solution in this > > > particular case but I don't know much about it or where it's at. > > > > Ok, let's see those patches then. > > I think Seth has a git tree ready, but not sure which branch he'd want > us to look at. > > Splitting a namespaced devtmpfs from loopdevfs discussion might be > sensible. However, in defense of a namespaced devtmpfs I'd say > that for userspace to, at every container startup, bind-mount in > devices from the global devtmpfs into a private tmpfs (for systemd's > sake it can't just be on the container rootfs), seems like something > worth avoiding. I think having to pick and choose what device nodes you want in a container is a good thing. Becides, you would have to do the same thing in the kernel anyway, what's wrong with userspace making the decision here, especially as it knows exactly what it wants to do much more so than the kernel ever can. > PS - Apparently both parallels and Michael independently > project devices which are hot-plugged on the host into containers. > That also seems like something worth talking about (best practices, > shortcomings, use cases not met by it, any ways tha the kernel can > help out) at ksummit/linuxcon. I was told that containers would never want devices hotplugged into them. What use case has this happening / needed? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for possible null pointer dereference in auth.c
Hi
I do not know, I'm not an expert on this code.
But since there before was a if (cred) someone must have thought this
could happen.
Best regards
Rickard Strandqvist
2014-05-16 0:07 GMT+02:00 Trond Myklebust :
> On Thu, May 15, 2014 at 5:56 PM, Rickard Strandqvist
> wrote:
>> There is otherwise a risk of a possible null pointer dereference.
>>
>> Was largely found by using a static code analysis program called cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> net/sunrpc/auth.c | 10 +++---
>> 1 fil ändrad, 7 tillägg(+), 3 borttagningar(-)
>>
>> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
>> index 5285ead..3a55698 100644
>> --- a/net/sunrpc/auth.c
>> +++ b/net/sunrpc/auth.c
>> @@ -801,10 +801,14 @@ rpcauth_invalcred(struct rpc_task *task)
>> {
>> struct rpc_cred *cred = task->tk_rqstp->rq_cred;
>>
>> - dprintk("RPC: %5u invalidating %s cred %p\n",
>> - task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
>> - if (cred)
>> + if (cred) {
>> + dprintk("RPC: %5u invalidating %s cred %p\n",
>> + task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
>> +
>> clear_bit(RPCAUTH_CRED_UPTODATE, >cr_flags);
>> + }
>> + else
>> + dprintk("RPC: %5u invalidating is NULL\n", task->tk_pid);
>> }
>>
>>
>
> Can you please explain how we can get to rpcauth_invalcred() without a
> valid cred pointer? I'm not seeing it...
>
> Cheers
> Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf_fuzzer crash on pentium 4
On Thu, May 15, 2014 at 01:31:16AM -0400, Vince Weaver wrote: > On Thu, 15 May 2014, Cyrill Gorcunov wrote: > > > So I'm experiencing the same problem on latest -tip + my patches applied. > > glad it's not just me. > > I find the problem to be reproducible and so in theory it might be > possible to generate a small reproducing test case. > I meant to do that already but I got distracted by other things. Please ping me once you manage to create such case. > > I think I managed to have a trace I recorded and replayed recreate the > issue, but narrowing things down from a 2000+ syscall trace can be > tedious. I imagine :/ > > Let me know if you have any other issues with the perf_fuzzer. Sure. Because the testing machine I'm having is connected remotely when hang happens the only notification I get is unresposible ssh connection, sigh... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for possible null pointer dereference in auth.c
On Thu, May 15, 2014 at 5:56 PM, Rickard Strandqvist
wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> net/sunrpc/auth.c | 10 +++---
> 1 fil ändrad, 7 tillägg(+), 3 borttagningar(-)
>
> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
> index 5285ead..3a55698 100644
> --- a/net/sunrpc/auth.c
> +++ b/net/sunrpc/auth.c
> @@ -801,10 +801,14 @@ rpcauth_invalcred(struct rpc_task *task)
> {
> struct rpc_cred *cred = task->tk_rqstp->rq_cred;
>
> - dprintk("RPC: %5u invalidating %s cred %p\n",
> - task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
> - if (cred)
> + if (cred) {
> + dprintk("RPC: %5u invalidating %s cred %p\n",
> + task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
> +
> clear_bit(RPCAUTH_CRED_UPTODATE, >cr_flags);
> + }
> + else
> + dprintk("RPC: %5u invalidating is NULL\n", task->tk_pid);
> }
>
>
Can you please explain how we can get to rpcauth_invalcred() without a
valid cred pointer? I'm not seeing it...
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] perf, tools: Query terminal width and use in perf list
From: Andi Kleen
Automatically adapt the now wider and word wrapped perf list
output to wider terminals. This requires querying the terminal
before the auto pager takes over, and exporting this
information from the pager subsystem.
Signed-off-by: Andi Kleen
---
tools/perf/util/cache.h | 1 +
tools/perf/util/pager.c | 15 +++
tools/perf/util/pmu.c | 12 ++--
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 7b176dd..07527d6 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -31,6 +31,7 @@ extern void setup_pager(void);
extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
+int pager_get_columns(void);
char *alias_lookup(const char *alias);
int split_cmdline(char *cmdline, const char ***argv);
diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c
index 3322b84..60fa3fe 100644
--- a/tools/perf/util/pager.c
+++ b/tools/perf/util/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include
/*
* This is split up from the rest of git so that we can do
@@ -8,6 +9,7 @@
*/
static int spawned_pager;
+static int pager_columns;
static void pager_preexec(void)
{
@@ -47,9 +49,12 @@ static void wait_for_pager_signal(int signo)
void setup_pager(void)
{
const char *pager = getenv("PERF_PAGER");
+ struct winsize sz;
if (!isatty(1))
return;
+ if (ioctl(1, TIOCGWINSZ, ) == 0)
+ pager_columns = sz.ws_col;
if (!pager) {
if (!pager_program)
perf_config(perf_default_config, NULL);
@@ -98,3 +103,13 @@ int pager_in_use(void)
env = getenv("PERF_PAGER_IN_USE");
return env ? perf_config_bool("PERF_PAGER_IN_USE", env) : 0;
}
+
+int pager_get_columns(void)
+{
+ char *s;
+
+ s = getenv("COLUMNS");
+ if (s)
+ return atoi(s);
+ return (pager_columns ? pager_columns : 80) - 2;
+}
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index fa21319..8714f9a 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -9,6 +9,7 @@
#include "pmu.h"
#include "parse-events.h"
#include "cpumap.h"
+#include "cache.h"
#include "jevents.h"
const char *json_file;
@@ -789,15 +790,6 @@ static void wordwrap(char *s, int start, int max, int corr)
}
}
-static int get_columns(void)
-{
- /*
-* Should ask the terminal with TIOCGWINSZ here, but we
-* need the original fd before the pager.
-*/
- return 79;
-}
-
void print_pmu_events(const char *event_glob, bool name_only)
{
struct perf_pmu *pmu;
@@ -807,7 +799,7 @@ void print_pmu_events(const char *event_glob, bool
name_only)
int len, j;
struct pair *aliases;
int numdesc = 0;
- int columns = get_columns();
+ int columns = pager_get_columns();
pmu = NULL;
len = 0;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] perf, tools: Add jsmn `jasmine' JSON parser v2
From: Andi Kleen
I need a JSON parser. This adds the simplest JSON
parser I could find -- Serge Zaitsev's jsmn `jasmine' --
to the perf library. I merely converted it to (mostly)
Linux style and added support for non 0 terminated input.
The parser is quite straight forward and does not
copy any data, just returns tokens with offsets
into the input buffer. So it's relatively efficient
and simple to use.
The code is not fully checkpatch clean, but I didn't
want to completely fork the upstream code.
Original source: http://zserge.bitbucket.org/jsmn.html
In addition I added a simple wrapper that mmaps a json
file and provides some straight forward access functions.
Used in follow-on patches to parse event files.
v2: Address review feedback.
Signed-off-by: Andi Kleen
---
tools/perf/Makefile.perf | 4 +
tools/perf/util/jsmn.c | 312 +++
tools/perf/util/jsmn.h | 67 ++
tools/perf/util/json.c | 155 +++
tools/perf/util/json.h | 13 ++
5 files changed, 551 insertions(+)
create mode 100644 tools/perf/util/jsmn.c
create mode 100644 tools/perf/util/jsmn.h
create mode 100644 tools/perf/util/json.c
create mode 100644 tools/perf/util/json.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2baf61c..43d4109 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -300,6 +300,8 @@ LIB_H += ui/progress.h
LIB_H += ui/util.h
LIB_H += ui/ui.h
LIB_H += util/data.h
+LIB_H += util/jsmn.h
+LIB_H += util/json.h
LIB_OBJS += $(OUTPUT)util/abspath.o
LIB_OBJS += $(OUTPUT)util/alias.o
@@ -373,6 +375,8 @@ LIB_OBJS += $(OUTPUT)util/stat.o
LIB_OBJS += $(OUTPUT)util/record.o
LIB_OBJS += $(OUTPUT)util/srcline.o
LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/jsmn.o
+LIB_OBJS += $(OUTPUT)util/json.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/util/jsmn.c b/tools/perf/util/jsmn.c
new file mode 100644
index 000..156294e
--- /dev/null
+++ b/tools/perf/util/jsmn.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright (c) 2010 Serge A. Zaitsev
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Slightly modified by AK to not assume 0 terminated input.
+ */
+
+#include
+#include "jsmn.h"
+
+/*
+ * Allocates a fresh unused token from the token pool.
+ */
+static jsmntok_t *jsmn_alloc_token(jsmn_parser *parser,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+ jsmntok_t *tok;
+
+ if ((unsigned)parser->toknext >= num_tokens)
+ return NULL;
+ tok = [parser->toknext++];
+ tok->start = tok->end = -1;
+ tok->size = 0;
+ return tok;
+}
+
+/*
+ * Fills token type and boundaries.
+ */
+static void jsmn_fill_token(jsmntok_t *token, jsmntype_t type,
+ int start, int end)
+{
+ token->type = type;
+ token->start = start;
+ token->end = end;
+ token->size = 0;
+}
+
+/*
+ * Fills next available token with JSON primitive.
+ */
+static jsmnerr_t jsmn_parse_primitive(jsmn_parser *parser, const char *js,
+ size_t len,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+ jsmntok_t *token;
+ int start;
+
+ start = parser->pos;
+
+ for (; parser->pos < len; parser->pos++) {
+ switch (js[parser->pos]) {
+#ifndef JSMN_STRICT
+ /*
+* In strict mode primitive must be followed by ","
+* or "}" or "]"
+*/
+ case ':':
+#endif
+ case '\t':
+ case '\r':
+ case '\n':
+ case ' ':
+ case ',':
+ case ']':
+ case '}':
+ goto found;
+ default:
+ break;
+ }
+ if (js[parser->pos] < 32
[PATCH 9/9] perf, tools, record: Always allow to overide default period v2
From: Andi Kleen
Fix the logic to allow overriding event default periods with -c or -F
on the command line. I'm not sure I understand this if() fully, but
this change makes all cases I tested work (tracepoint with default, default,
,-c, -F)
This fixed specifying -c / -F with json event list events,
which have a default period. It should do the same
for trace point events.
Cc: fweis...@gmail.com
v2: Simplify, just change || to &&
Signed-off-by: Andi Kleen
---
tools/perf/util/evsel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 5c28d82..d9ceede 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -592,7 +592,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct
record_opts *opts)
* We default some events to a 1 default interval. But keep
* it a weak assumption overridable by the user.
*/
- if (!attr->sample_period || (opts->user_freq != UINT_MAX &&
+ if (!attr->sample_period && (opts->user_freq != UINT_MAX &&
opts->user_interval != ULLONG_MAX)) {
if (opts->freq) {
perf_evsel__set_sample_bit(evsel, PERIOD);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for possible null pointer dereference in node.c
On Thu, May 15, 2014 at 11:53:53PM +0200, Rickard Strandqvist wrote: > There is otherwise a risk of a possible null pointer dereference. > > Was largely found by using a static code analysis program called cppcheck. > > Signed-off-by: Rickard Strandqvist > --- > drivers/staging/tidspbridge/rmgr/node.c |4 ++-- > 1 fil ändrad, 2 tillägg(+), 2 borttagningar(-) Please work a bit on your Subject lines to make it easier to figure out where the patches belong. For this one, it should be: Subject: staging: tidspridge: fix for possible null pointer dereference in node.c or: Subject: staging: tidspridge: node.c: fix for possible null pointer dereference That way people can figure out _what_ node.c file you are referring to and to see if they care about it or not :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] perf, tools: Add support for reading JSON event files v2
From: Andi Kleen
Add a parser for Intel style JSON event files. This allows
to use an Intel event list directly with perf. The Intel
event lists can be quite large and are too big to store
in unswappable kernel memory.
The parser code knows how to convert the JSON fields
to perf fields. The conversion code is straight forward.
It knows (very little) Intel specific information, and can be easily
extended to handle fields for other CPUs.
The parser code is partially shared with an independent parsing
library, which is 2-clause BSD licenced. To avoid any conflicts I marked
those files as BSD licenced too. As part of perf they become GPLv2.
The events are handled using the existing alias machinery.
We output the BriefDescription in perf list.
Right now the json file can be specified as an argument
to perf stat/record/list. Followon patches will automate this.
v2: Address review feedback. Rename option to --event-files
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-list.txt | 6 +
tools/perf/Documentation/perf-record.txt | 3 +
tools/perf/Documentation/perf-stat.txt | 3 +
tools/perf/Makefile.perf | 2 +
tools/perf/builtin-list.c| 2 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-stat.c| 2 +
tools/perf/util/jevents.c| 250 +++
tools/perf/util/jevents.h| 3 +
tools/perf/util/pmu.c| 14 ++
tools/perf/util/pmu.h| 2 +
11 files changed, 290 insertions(+)
create mode 100644 tools/perf/util/jevents.c
create mode 100644 tools/perf/util/jevents.h
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index 6fce6a6..9305a37 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -15,6 +15,12 @@ DESCRIPTION
This command displays the symbolic event types which can be selected in the
various perf commands with the -e option.
+OPTIONS
+---
+--events-file=::
+Specify JSON event list file to use for parsing events.
+
+
[[EVENT_MODIFIERS]]
EVENT MODIFIERS
---
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index c71b0f3..cff0869 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -213,6 +213,9 @@ if combined with -a or -C options.
After starting the program, wait msecs before measuring. This is useful to
filter out the startup phase of the program, which is often very different.
+--events-file=::
+Specify JSON event list file to use for parsing events.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 29ee857..7adbb08 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -142,6 +142,9 @@ filter out the startup phase of the program, which is often
very different.
Print statistics of transactional execution if supported.
+--events-file=::
+Specify JSON event list file to use for parsing events.
+
EXAMPLES
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 43d4109..8800838 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -302,6 +302,7 @@ LIB_H += ui/ui.h
LIB_H += util/data.h
LIB_H += util/jsmn.h
LIB_H += util/json.h
+LIB_H += util/jevents.h
LIB_OBJS += $(OUTPUT)util/abspath.o
LIB_OBJS += $(OUTPUT)util/alias.o
@@ -377,6 +378,7 @@ LIB_OBJS += $(OUTPUT)util/srcline.o
LIB_OBJS += $(OUTPUT)util/data.o
LIB_OBJS += $(OUTPUT)util/jsmn.o
LIB_OBJS += $(OUTPUT)util/json.o
+LIB_OBJS += $(OUTPUT)util/jevents.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..086c96f 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -20,6 +20,8 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
{
int i;
const struct option list_options[] = {
+ OPT_STRING(0, "events-file", _file, "json file",
+ "Read event json file"),
OPT_END()
};
const char * const list_usage[] = {
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index e4c85b8..ed00556 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -25,6 +25,7 @@
#include "util/cpumap.h"
#include "util/thread_map.h"
#include "util/data.h"
+#include "util/pmu.h"
#include
#include
@@ -871,6 +872,8 @@ const struct option record_options[] = {
"sample transaction flags (special events only)"),
OPT_BOOLEAN(0, "per-thread", _thread,
"use per-thread mmaps"),
+ OPT_STRING(0, "events-file", _file, "json file",
+
perf: Add support for full Intel event lists v4
[v2: Review feedback addressed and some minor improvements] [v3: More review feedback addressed and handle test failures better. Ported to latest tip/core.] [v4: Addressed Namhyung's feedback] perf has high level events which are useful in many cases. However there are some tuning situations where low level events in the CPU are needed. Traditionally this required specifying the event in raw form (very awkward) or using non standard frontends like ocperf or patching in libpfm. Intel CPUs can have very large event files (Haswell has ~336 core events, much more if you add uncore or all the offcore combinations), which is too large to describe through the kernel interface. It would require tying up significant amounts of unswappable memory for this. oprofile always had separate event list files that were maintained by the CPU vendors. The oprofile events were shipped with the tool. The Intel events get updated regularly, for example to add references to the specification updates or add new events. Unfortunately oprofile usually did not keep up with these updates, so the events in oprofile were often out of date. In addition it ties up quite a bit of disk space, mostly for CPUs you don't have. This patch kit implements another mechanism that avoids these problems. Intel releases the event lists for CPUs in a standardized JSON format on a download server. I implemented an automatic downloader to get the event file for the current CPU. The events are stored in ~/.cache/pmu-events. Then perf adds a parser that converts the JSON format into perf event aliases, which then can be used directly as any other perf event. The parsing is done using a simple existing JSON library. The events are still abstracted for perf, but the abstraction mechanism is through the downloaded file instead of through the kernel. The JSON format and perf parser has some minor Intelisms, but they are simple and small and optional. It's easy to extend, so it would be possible to use it for other CPUs too, add different pmu attributes, and add new download sites to the downloader tool. Currently only core events are supported, uncore may come at a later point. No kernel changes, all code in perf user tools only. Some of the parser files are partially shared with separate event parser library and are thus 2-clause BSD licensed. Patches also available from git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/json Example output: % perf download Downloading models file Downloading readme.txt 2014-03-05 10:39:33 URL:https://download.01.org/perfmon/readme.txt [10320/10320] -> "readme.txt" [1] 2014-03-05 10:39:34 URL:https://download.01.org/perfmon/mapfile.csv [1207/1207] -> "mapfile.csv" [1] Downloading events file % perf list ... br_inst_exec.all_branches [Speculative and retired branches] br_inst_exec.all_conditional [Speculative and retired macro-conditional branches] br_inst_exec.all_direct_jmp[Speculative and retired macro-unconditional branches excluding calls and indirects] ... 333 more new events ... % perf stat -e br_inst_exec.all_direct_jmp true Performance counter stats for 'true': 6,817 cpu/br_inst_exec.all_direct_jmp/ 0.003503212 seconds time elapsed One nice feature is that a pointer to the specification update is now included in the description, which will hopefully clear up many problems: % perf list ... mem_load_uops_l3_hit_retired.xsnp_hit [Retired load uops which data sources were L3 and cross-core snoop hits in on-pkg core cache. Supports address when precise. Spec update: HSM26, HSM30 (Precise event)] ... -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] perf, tools: Add perf download to download event files v3
From: Andi Kleen Add a downloader to automatically download the right files from a download site. This is implemented as a script calling wget, similar to perf archive. The perf driver automatically calls the right binary. The downloader is extensible, but currently only implements an Intel event download. It would be straightforward to add other sites too for other vendors. The downloaded event files are put into ~/.cache/pmu-events, where the builtin event parser in util/* can find them automatically. v2: Use ~/.cache v3: Check for wget. Some cleanups. Signed-off-by: Andi Kleen --- tools/perf/Documentation/perf-download.txt | 28 +++ tools/perf/Documentation/perf-list.txt | 12 ++- tools/perf/Makefile.perf | 5 ++- tools/perf/perf-download.sh| 57 ++ 4 files changed, 100 insertions(+), 2 deletions(-) create mode 100644 tools/perf/Documentation/perf-download.txt create mode 100755 tools/perf/perf-download.sh diff --git a/tools/perf/Documentation/perf-download.txt b/tools/perf/Documentation/perf-download.txt new file mode 100644 index 000..7af841b --- /dev/null +++ b/tools/perf/Documentation/perf-download.txt @@ -0,0 +1,28 @@ +perf-download(1) +=== + +NAME + +perf-download - Download event files for current CPU. + +SYNOPSIS + +[verse] +'perf download' [vendor-family-model] + +DESCRIPTION +--- +This command automatically downloads event list for the current CPU and +stores them in $XDG_CACHE_HOME/pmu-events (or $HOME/.cache/pmu-events). +The other tools automatically look for them there. The CPU can be also +specified at the command line. + +The downloading is done using http through wget, which needs +to be installed. + +The user should regularly call this to download updated event lists +for the current CPU. + +Note the downloaded files are stored per user, so if you use +perf as normal user or with sudo you have to run perf download +for both or specify --events-file for the users manually. diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt index 9305a37..2b4eba0 100644 --- a/tools/perf/Documentation/perf-list.txt +++ b/tools/perf/Documentation/perf-list.txt @@ -61,6 +61,16 @@ Sampling). Examples to use IBS: perf record -a -e r076:p ... # same as -e cpu-cycles:p perf record -a -e r0C1:p ... # use ibs op counting micro-ops +PER CPU EVENT LISTS +--- + +For some CPUs (particularly modern Intel CPUs) "perf download" can +download additional CPU specific event definitions, which then +become visible in perf list and available in the other perf tools. + +This obsoletes the raw event description method described below +for most cases. + RAW HARDWARE EVENT DESCRIPTOR - Even when an event is not available in a symbolic form within perf right now, @@ -123,6 +133,6 @@ types specified. SEE ALSO linkperf:perf-stat[1], linkperf:perf-top[1], -linkperf:perf-record[1], +linkperf:perf-record[1], linkperf:perf-download[1], http://www.intel.com/Assets/PDF/manual/253669.pdf[Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide], http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf[AMD64 Architecture Programmer’s Manual Volume 2: System Programming] diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 8800838..4dc1682 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -126,6 +126,7 @@ PYRF_OBJS = SCRIPT_SH = SCRIPT_SH += perf-archive.sh +SCRIPT_SH += perf-download.sh grep-libs = $(filter -l%,$(1)) strip-libs = $(filter-out -l%,$(1)) @@ -872,6 +873,8 @@ install-bin: all install-gtk $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)' $(call QUIET_INSTALL, perf-archive) \ $(INSTALL) $(OUTPUT)perf-archive -t '$(DESTDIR_SQ)$(perfexec_instdir_SQ)' + $(call QUIET_INSTALL, perf-download) \ + $(INSTALL) $(OUTPUT)perf-download -t '$(DESTDIR_SQ)$(perfexec_instdir_SQ)' ifndef NO_LIBPERL $(call QUIET_INSTALL, perl-scripts) \ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)/scripts/perl/Perf-Trace-Util/lib/Perf/Trace'; \ @@ -917,7 +920,7 @@ config-clean: @$(MAKE) -C config/feature-checks clean >/dev/null clean: $(LIBTRACEEVENT)-clean $(LIBAPIKFS)-clean config-clean - $(call QUIET_CLEAN, core-objs) $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)perf.o $(LANG_BINDINGS) $(GTK_OBJS) + $(call QUIET_CLEAN, core-objs) $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)/perf-download $(OUTPUT)perf.o $(LANG_BINDINGS) $(GTK_OBJS) $(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf $(call QUIET_CLEAN, core-gen) $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS tags
[PATCH 4/9] perf, tools: Automatically look for event file name for cpu v2
From: Andi Kleen
When no JSON event file is specified automatically look
for a suitable file in ~/.cache/pmu-events. A "perf download" can
automatically add files there for the current CPUs.
This does not include the actual event files with perf,
but they can be automatically downloaded instead
(implemented in the next patch)
This has the advantage that the events can be always uptodate,
because they are freshly downloaded. In oprofile we always
had problems with out of date or incomplete events files.
The event file format is per architecture, but can be
extended for other architectures.
v2: Supports XDG_CACHE_HOME and defaults to ~/.cache/pmu-events
Signed-off-by: Andi Kleen
---
tools/perf/arch/x86/Makefile | 1 +
tools/perf/arch/x86/util/cpustr.c | 34 ++
tools/perf/util/jevents.c | 31 +++
tools/perf/util/jevents.h | 1 +
tools/perf/util/pmu.c | 2 +-
5 files changed, 68 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/arch/x86/util/cpustr.c
diff --git a/tools/perf/arch/x86/Makefile b/tools/perf/arch/x86/Makefile
index 1641542..0efeb14 100644
--- a/tools/perf/arch/x86/Makefile
+++ b/tools/perf/arch/x86/Makefile
@@ -14,4 +14,5 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/dwarf-unwind.o
endif
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/tsc.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/cpustr.o
LIB_H += arch/$(ARCH)/util/tsc.h
diff --git a/tools/perf/arch/x86/util/cpustr.c
b/tools/perf/arch/x86/util/cpustr.c
new file mode 100644
index 000..e1cd76c
--- /dev/null
+++ b/tools/perf/arch/x86/util/cpustr.c
@@ -0,0 +1,34 @@
+#include
+#include
+#include "../../util/jevents.h"
+
+char *get_cpu_str(void)
+{
+ char *line = NULL;
+ size_t llen = 0;
+ int found = 0, n;
+ char vendor[30];
+ int model, fam;
+ char *res = NULL;
+ FILE *f = fopen("/proc/cpuinfo", "r");
+
+ if (!f)
+ return NULL;
+ while (getline(, , f) > 0) {
+ if (sscanf(line, "vendor_id : %30s", vendor) == 1)
+ found++;
+ else if (sscanf(line, "model : %d", ) == 1)
+ found++;
+ else if (sscanf(line, "cpu family : %d", ) == 1)
+ found++;
+ if (found == 3) {
+ n = asprintf(, "%s-%d-%X-core", vendor, fam, model);
+ if (n < 0)
+ res = NULL;
+ break;
+ }
+ }
+ free(line);
+ fclose(f);
+ return res;
+}
diff --git a/tools/perf/util/jevents.c b/tools/perf/util/jevents.c
index 943a1fc..b26c0b6 100644
--- a/tools/perf/util/jevents.c
+++ b/tools/perf/util/jevents.c
@@ -33,10 +33,39 @@
#include
#include
#include
+#include "cache.h"
#include "jsmn.h"
#include "json.h"
#include "jevents.h"
+__attribute__((weak)) char *get_cpu_str(void)
+{
+ return NULL;
+}
+
+static const char *json_default_name(void)
+{
+ char *cache = getenv("XDG_CACHE_HOME");
+ char *idstr = get_cpu_str();
+ char *res = NULL;
+ char *home = NULL;
+
+ if (!cache) {
+ home = getenv("HOME");
+ if (!home || asprintf(, "%s/.cache", home) < 0)
+ goto out;
+ }
+ if (cache && idstr)
+ res = mkpath("%s/pmu-events/%s.json",
+cache,
+idstr);
+ if (home)
+ free(cache);
+out:
+ free(idstr);
+ return res;
+}
+
static void addfield(char *map, char **dst, const char *sep,
const char *a, jsmntok_t *bt)
{
@@ -174,6 +203,8 @@ int json_events(const char *fn,
int i, j, len;
char *map;
+ if (!fn)
+ fn = json_default_name();
tokens = parse_json(fn, , , );
if (!tokens)
return -EIO;
diff --git a/tools/perf/util/jevents.h b/tools/perf/util/jevents.h
index 4c2b879..6a377a8 100644
--- a/tools/perf/util/jevents.h
+++ b/tools/perf/util/jevents.h
@@ -1,3 +1,4 @@
int json_events(const char *fn,
int (*func)(void *data, char *name, char *event, char *desc),
void *data);
+char *get_cpu_str(void);
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 9f154af..fa21319 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -433,7 +433,7 @@ static struct perf_pmu *pmu_lookup(const char *name)
if (pmu_aliases(name, ))
return NULL;
- if (!strcmp(name, "cpu") && json_file)
+ if (!strcmp(name, "cpu"))
json_events(json_file, add_alias, );
if (pmu_type(name, ))
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 6/9] perf, tools: Allow events with dot
From: Andi Kleen
The Intel events use a dot to separate event name and unit mask.
Allow dot in names in the scanner, and remove special handling
of dot as EOF. Also remove the hack in jevents to replace dot
with underscore. This way dotted events can be specified
directly by the user.
I'm not fully sure this change to the scanner is correct
(what was the dot special case good for?), but I haven't
found anything that breaks with it so far at least.
Signed-off-by: Andi Kleen
---
tools/perf/util/jevents.c | 9 +
tools/perf/util/parse-events.l | 3 +--
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/jevents.c b/tools/perf/util/jevents.c
index b26c0b6..fe51dc8 100644
--- a/tools/perf/util/jevents.c
+++ b/tools/perf/util/jevents.c
@@ -90,15 +90,8 @@ static void addfield(char *map, char **dst, const char *sep,
static void fixname(char *s)
{
- for (; *s; s++) {
+ for (; *s; s++)
*s = tolower(*s);
- /*
-* Remove '.' for now, until the parser
-* can deal with it.
-*/
- if (*s == '.')
- *s = '_';
- }
}
static void fixdesc(char *s)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 3432995..709fa3b 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -81,7 +81,7 @@ num_dec [0-9]+
num_hex0x[a-fA-F0-9]+
num_raw_hex[a-fA-F0-9]+
name [a-zA-Z_*?][a-zA-Z0-9_*?]*
-name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?]*
+name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?.]*
/* If you add a modifier you need to update check_modifier() */
modifier_event [ukhpGHSD]+
modifier_bp[rwx]{1,3}
@@ -119,7 +119,6 @@ modifier_bp [rwx]{1,3}
return PE_EVENT_NAME;
}
-. |
<>{
BEGIN(INITIAL); yyless(0);
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] perf, tools: Add support for text descriptions of events and alias add
From: Andi Kleen
Change pmu.c to allow descriptions of events and add interfaces
to add aliases. Used in the next patch.
Signed-off-by: Andi Kleen
---
tools/perf/util/pmu.c | 127 ++
1 file changed, 98 insertions(+), 29 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 7a811eb..baec090 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -14,6 +14,7 @@
struct perf_pmu_alias {
char *name;
+ char *desc;
struct list_head terms;
struct list_head list;
char unit[UNIT_MAX_LEN+1];
@@ -171,17 +172,12 @@ error:
return -1;
}
-static int perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
FILE *file)
+static int __perf_pmu__new_alias(struct list_head *list, char *name,
+char *dir, char *desc, char *val)
{
struct perf_pmu_alias *alias;
- char buf[256];
int ret;
- ret = fread(buf, 1, sizeof(buf), file);
- if (ret == 0)
- return -EINVAL;
- buf[ret] = 0;
-
alias = malloc(sizeof(*alias));
if (!alias)
return -ENOMEM;
@@ -190,24 +186,45 @@ static int perf_pmu__new_alias(struct list_head *list,
char *dir, char *name, FI
alias->scale = 1.0;
alias->unit[0] = '\0';
- ret = parse_events_terms(>terms, buf);
+ ret = parse_events_terms(>terms, val);
if (ret) {
+ pr_err("Cannot parse alias %s: %d\n", val, ret);
free(alias);
return ret;
}
alias->name = strdup(name);
- /*
-* load unit name and scale if available
-*/
- perf_pmu__parse_unit(alias, dir, name);
- perf_pmu__parse_scale(alias, dir, name);
+ if (dir) {
+ /*
+* load unit name and scale if available
+*/
+ perf_pmu__parse_unit(alias, dir, name);
+ perf_pmu__parse_scale(alias, dir, name);
+ }
+
+ alias->desc = desc ? strdup(desc) : NULL;
list_add_tail(>list, list);
return 0;
}
+static int perf_pmu__new_alias(struct list_head *list,
+ char *dir,
+ char *name,
+ FILE *file)
+{
+ char buf[256];
+ int ret;
+
+ ret = fread(buf, 1, sizeof(buf), file);
+ if (ret == 0)
+ return -EINVAL;
+ buf[ret] = 0;
+
+ return __perf_pmu__new_alias(list, name, dir, NULL, buf);
+}
+
/*
* Process all the sysfs attributes located under the directory
* specified in 'dir' parameter.
@@ -720,11 +737,51 @@ static char *format_alias_or(char *buf, int len, struct
perf_pmu *pmu,
return buf;
}
-static int cmp_string(const void *a, const void *b)
+struct pair {
+ char *name;
+ char *desc;
+};
+
+static int cmp_pair(const void *a, const void *b)
+{
+ const struct pair *as = a;
+ const struct pair *bs = b;
+
+ /* Put downloaded event list last */
+ if (!!as->desc != !!bs->desc)
+ return !!as->desc - !!bs->desc;
+ return strcmp(as->name, bs->name);
+}
+
+static void wordwrap(char *s, int start, int max, int corr)
{
- const char * const *as = a;
- const char * const *bs = b;
- return strcmp(*as, *bs);
+ int column = start;
+ int n;
+
+ while (*s) {
+ int wlen = strcspn(s, " \t");
+
+ if (column + wlen >= max && column > start) {
+ printf("\n%*s", start, "");
+ column = start + corr;
+ }
+ n = printf("%s%.*s", column > start ? " " : "", wlen, s);
+ if (n <= 0)
+ break;
+ s += wlen;
+ column += n;
+ while (isspace(*s))
+ s++;
+ }
+}
+
+static int get_columns(void)
+{
+ /*
+* Should ask the terminal with TIOCGWINSZ here, but we
+* need the original fd before the pager.
+*/
+ return 79;
}
void print_pmu_events(const char *event_glob, bool name_only)
@@ -734,21 +791,24 @@ void print_pmu_events(const char *event_glob, bool
name_only)
char buf[1024];
int printed = 0;
int len, j;
- char **aliases;
+ struct pair *aliases;
+ int numdesc = 0;
+ int columns = get_columns();
pmu = NULL;
len = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL)
list_for_each_entry(alias, >aliases, list)
len++;
- aliases = malloc(sizeof(char *) * len);
+ aliases = malloc(sizeof(struct pair) * len);
if (!aliases)
return;
pmu = NULL;
j = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL)
list_for_each_entry(alias, >aliases, list) {
- char
[PATCH 8/9] perf, tools, test: Add test case for alias and JSON parsing v2
From: Andi Kleen
Add a simple test case to perf test that runs perf download and parses
all the events. This needs adding an all event iterator to pmu.c
v2: Rename identifiers
Signed-off-by: Andi Kleen
---
tools/perf/Makefile.perf| 1 +
tools/perf/tests/aliases.c | 58 +
tools/perf/tests/builtin-test.c | 4 +++
tools/perf/tests/tests.h| 1 +
tools/perf/util/pmu.c | 18 +
tools/perf/util/pmu.h | 2 ++
6 files changed, 84 insertions(+)
create mode 100644 tools/perf/tests/aliases.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 4dc1682..3e6ed5a 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -417,6 +417,7 @@ endif
LIB_OBJS += $(OUTPUT)tests/code-reading.o
LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
LIB_OBJS += $(OUTPUT)tests/parse-no-sample-id-all.o
+LIB_OBJS += $(OUTPUT)tests/aliases.o
ifndef NO_DWARF_UNWIND
ifeq ($(ARCH),x86)
LIB_OBJS += $(OUTPUT)tests/dwarf-unwind.o
diff --git a/tools/perf/tests/aliases.c b/tools/perf/tests/aliases.c
new file mode 100644
index 000..68396e7
--- /dev/null
+++ b/tools/perf/tests/aliases.c
@@ -0,0 +1,58 @@
+/* Check if we can set up all aliases and can read JSON files */
+#include
+#include "tests.h"
+#include "pmu.h"
+#include "evlist.h"
+#include "parse-events.h"
+
+static struct perf_evlist *evlist;
+
+static int num_events;
+static int failed;
+
+static int test__event(const char *name)
+{
+ int ret;
+
+ /* Not supported for now */
+ if (!strncmp(name, "energy-", 7))
+ return 0;
+
+ ret = parse_events(evlist, name);
+
+ if (ret) {
+ /*
+* We only print on failure because common perf setups
+* have events that cannot be parsed.
+*/
+ fprintf(stderr, "invalid or unsupported event: '%s'\n", name);
+ ret = 0;
+ failed++;
+ } else
+ num_events++;
+ return ret;
+}
+
+int test__aliases(void)
+{
+ int err;
+
+ /* Download JSON files */
+ /* XXX assumes perf is installed */
+ /* For now user must manually download */
+ if (0 && system("perf download > /dev/null") < 0) {
+ /* Don't error out for this for now */
+ fprintf(stderr, "perf download failed\n");
+ }
+
+ evlist = perf_evlist__new();
+ if (evlist == NULL)
+ return -ENOMEM;
+
+ err = pmu_iterate_events(test__event);
+ fprintf(stderr, " Parsed %d events :", num_events);
+ if (failed > 0)
+ pr_debug(" %d events failed", failed);
+ perf_evlist__delete(evlist);
+ return err;
+}
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 0d5afaf..d62601c 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -115,6 +115,10 @@ static struct test {
.desc = "Test parsing with no sample_id_all bit set",
.func = test__parse_no_sample_id_all,
},
+ {
+ .desc = "Test parsing JSON aliases",
+ .func = test__aliases,
+ },
#if defined(__x86_64__) || defined(__i386__)
#ifdef HAVE_DWARF_UNWIND_SUPPORT
{
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index a9d7cb0..38e98df 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -44,6 +44,7 @@ int test__dwarf_unwind(void);
int test__hists_filter(void);
int test__mmap_thread_lookup(void);
int test__thread_mg_share(void);
+int test__aliases(void);
#if defined(__x86_64__) || defined(__i386__)
#ifdef HAVE_DWARF_UNWIND_SUPPORT
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 8714f9a..b87f520 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -869,3 +869,21 @@ bool pmu_have_event(const char *pname, const char *name)
}
return false;
}
+
+int pmu_iterate_events(int (*func)(const char *name))
+{
+ int ret = 0;
+ struct perf_pmu *pmu;
+ struct perf_pmu_alias *alias;
+
+ perf_pmu__find("cpu"); /* Load PMUs */
+ pmu = NULL;
+ while ((pmu = perf_pmu__scan(pmu)) != NULL) {
+ list_for_each_entry(alias, >aliases, list) {
+ ret = func(alias->name);
+ if (ret != 0)
+ break;
+ }
+ }
+ return ret;
+}
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 583d21e..a8ed283 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -47,5 +47,7 @@ bool pmu_have_event(const char *pname, const char *name);
int perf_pmu__test(void);
+int pmu_iterate_events(int (*func)(const char *name));
+
extern const char *json_file;
#endif /* __PMU_H */
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: [PATCH] staging: sep: fix coding style issue
On Tue, May 06, 2014 at 07:54:41PM +0200, Clément Calmels wrote:
> This is a patch to fix coding style issue found by
> scripts/checkpatch.pl utility.
>
> Signed-off-by: Clément Calmels
> ---
> drivers/staging/sep/sep_dev.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/sep/sep_dev.h b/drivers/staging/sep/sep_dev.h
> index 5f6a07f..5faeefa1 100644
> --- a/drivers/staging/sep/sep_dev.h
> +++ b/drivers/staging/sep/sep_dev.h
> @@ -139,12 +139,14 @@ struct sep_queue_info {
> static inline void sep_write_reg(struct sep_device *dev, int reg, u32 value)
> {
> void __iomem *addr = dev->reg_addr + reg;
> +
> writel(value, addr);
> }
>
> static inline u32 sep_read_reg(struct sep_device *dev, int reg)
> {
> void __iomem *addr = dev->reg_addr + reg;
> +
> return readl(addr);
> }
>
> @@ -152,6 +154,7 @@ static inline u32 sep_read_reg(struct sep_device *dev,
> int reg)
> static inline void sep_wait_sram_write(struct sep_device *dev)
> {
> u32 reg_val;
> +
> do {
> reg_val = sep_read_reg(dev, HW_SRAM_DATA_READY_REG_ADDR);
> } while (!(reg_val & 1));
Someone else already sent in this same patch, sorry.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: msm: remove board file for Nexus One (ie. mahimahi)
On Thu, May 15, 2014 at 08:10:13PM +0200, Paul Bolle wrote:
> Daniel,
>
> On Thu, 2014-05-15 at 17:44 +, dwal...@fifo99.com wrote:
> > On Wed, May 14, 2014 at 11:07:36PM +0200, Paul Bolle wrote:
> > > Commit 1b802ff79f03 ("arm: msm: add board file for Nexus One (ie.
> > > mahimahi)") added just board-mahimahi.c. It did not add
> > > board-mahimahi.h, Makefile changes or Kconfig changes.
> > >
> > > Four years have passed and this file is still dangling. Remove it.
> > >
> > > Signed-off-by: Paul Bolle
> > > ---
> > > Untested. But what to test here?
> > >
> > I don't mine if Sapphire gets removed,
>
> Could you ACK that patch, please?
I don't mind if it gets removed, but I wouldn't ACK it's removal ..
> > but I'm working on this one now..
>
> That's good to hear.
>
> > So I don't want it deleted.
>
> This is not something I get to decide. Nevertheless, given that this
> file shouldn't have been merged to begin with, I'd appreciate it if some
> deadline could be agreed upon.
I think I merged it actually, but there's no rules about what gets merged. How
when what order, etc.
It's all free form.
> That being said, I'm not sure how having just this file in mainline
> helps your development efforts. It seems it did receive some updates
> for, well, treewide stuff. But it surely didn't get build coverage or
> runtime testing. So would you lose much if it only remains in your
> development tree?
It's effort to remove it.. Your asking for it to get removed, then re-added..
That sounds
like a fairly large amount of effort vs just leaving it in place.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm: NULL ptr deref handling mmaping of special mappings
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote: > > > > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of > > variables > > be kind of immutable constants? If yes, we could calculate where the > > additional > > vma lives without requiring any kind of [vdso] mark in proc/pid/maps output. > > Please don't! > > These might, in principle, even vary between tasks on the same system. > Certainly the relative positions of the vmas will be different > between 3.15 and 3.16, since we need almost my entire cleanup series > to reliably put them into their 3.16 location. And I intend to change > the number of pages in 3.16 or 3.17. There are other ways how to find where additional pages are laying but it would be great if there a straightforward interface for that (ie some mark in /proc/pid/maps output). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/mem.c: Add /dev/ioports, supporting 16-bit and 32-bit ports
On Tue, May 13, 2014 at 03:10:59PM -0700, H. Peter Anvin wrote:
> On 05/09/2014 03:38 PM, Josh Triplett wrote:
> > On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
> >> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
> >>>
> However, if we're going to have these devices I'm wondering if having
> /dev/portw and /dev/portl (or something like that) might not make sense,
> rather than requiring a system call per transaction.
> >>>
> >>> Actually the behavior of /dev/port for >1 byte writes seems questionable
> >>> already: There are very few devices on which writing to consecutive
> >>> port numbers makes sense. Normally you just want to write a series
> >>> of bytes (or 16/32 bit words) into the same port number instead,
> >>> as the outsb()/outsw()/outsl() functions do.
> >>>
> >>
> >> Indeed. I missed the detail that it increments the port index; it is
> >> virtually guaranteed to be bogus.
> >
> > Exactly. It might make sense to have ioport8/ioport16/ioport32 devices
> > that accept arbitrary-length reads and writes (divisible by the size)
> > and do the equivalent of the string I/O instructions outs/ins, but for
> > the moment I'd like to add the single device that people always seem to
> > want and can't get from /dev/port. If someone's doing enough writes
> > that doing a syscall per in/out instruction seems like too much
> > overhead, they can write a real device driver or use ioperm/iopl.
>
> I really have a problem with the logic "our current interface is wrong,
> so let's introduce another wrong interface which solves a narrow use
> case". In some ways it would actually be *better* to use an ioctl
> interface on /dev/port in that case...
ioport{8,16,32} seems preferable to an ioctl on /dev/port, but in any
case, I'd be happy to adapt this patch to whatever interface seems
preferable. I just don't want to let the perfect be the enemy of the
good here; 16-bit and 32-bit port operations are currently completely
impossible via /dev/port, and I'm primarily interested in fixing that,
not necessarily in creating a completely generalized interface for doing
high-performance repeated I/O operations that ought to be in the kernel
anyway.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] cgroup: use cgroup->self.refcnt for cgroup refcnting
On 05/15/2014 01:07 PM, Stephen Warren wrote: > On 05/09/2014 03:13 PM, Tejun Heo wrote: >> Currently cgroup implements refcnting separately using atomic_t >> cgroup->refcnt. The destruction paths of cgroup and css are rather >> complex and bear a lot of similiarities including the use of RCU and >> bouncing to a work item. >> >> This patch makes cgroup use the refcnt of self css for refcnting >> instead of using its own. This makes cgroup refcnting use css's >> percpu refcnt and share the destruction mechanism. >> ... > > In next-20150515, this patch causes silent boot failures on NVIDIA Tegra > ARM systems. There isn't even any earlyprintk. Reverting this one patch > solves this. > > I was a bit surprised that cgroups would cause such an issue, but > looking at a normal kernel boot, I guess cgroup does get initialized > very early: > > Uncompressing Linux... done, booting the kernel. > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Initializing cgroup subsys cpu > [0.00] Initializing cgroup subsys cpuacct > > Anyway, I'll try to track down what the problem is, but if someone > familiar with this patch could give it a look, that'd be very useful, > since I'm not at all familiar with this code or feature. It looks like this has something to do with the new code using percpu_ functions from within cgroup_init_early, yet that function being called before init/main.c calls setup_per_cpu_areas() etc.? Unfortunately I have to run to some meetings now, so won't look at this until tomorrow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix for possible null pointer dereference in dma.c
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
sound/soc/samsung/dma.c | 10 ++
1 fil ändrad, 6 tillägg(+), 4 borttagningar(-)
diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
index dc09b71..b1f6757 100644
--- a/sound/soc/samsung/dma.c
+++ b/sound/soc/samsung/dma.c
@@ -115,17 +115,19 @@ static void dma_enqueue(struct snd_pcm_substream
*substream)
static void audio_buffdone(void *data)
{
struct snd_pcm_substream *substream = data;
- struct runtime_data *prtd = substream->runtime->private_data;
+ struct runtime_data *prtd = NULL;
pr_debug("Entered %s\n", __func__);
- if (prtd->state & ST_RUNNING) {
+ if(substream)
+ prtd = substream->runtime->private_data;
+
+ if (prtd && prtd->state & ST_RUNNING) {
prtd->dma_pos += prtd->dma_period;
if (prtd->dma_pos >= prtd->dma_end)
prtd->dma_pos = prtd->dma_start;
- if (substream)
- snd_pcm_period_elapsed(substream);
+ snd_pcm_period_elapsed(substream);
spin_lock(>lock);
if (!samsung_dma_has_circular()) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix for possible null pointer dereference in auth.c
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
net/sunrpc/auth.c | 10 +++---
1 fil ändrad, 7 tillägg(+), 3 borttagningar(-)
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index 5285ead..3a55698 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -801,10 +801,14 @@ rpcauth_invalcred(struct rpc_task *task)
{
struct rpc_cred *cred = task->tk_rqstp->rq_cred;
- dprintk("RPC: %5u invalidating %s cred %p\n",
- task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
- if (cred)
+ if (cred) {
+ dprintk("RPC: %5u invalidating %s cred %p\n",
+ task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
+
clear_bit(RPCAUTH_CRED_UPTODATE, >cr_flags);
+ }
+ else
+ dprintk("RPC: %5u invalidating is NULL\n", task->tk_pid);
}
int
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
