Re: 3.13: disagrees about version of symbol
Am 26.01.2014 15:22, schrieb Tetsuo Handa: > Thomas B臘hler wrote: >> This looks exactly like the problem experienced by Tetsuo Handa in [1]. >> However, for me, his solution, i.e. setting >> CONFIG_PHYSICAL_ALIGN=0x100 >> instead of >> CONFIG_PHYSICAL_ALIGN=0x10 >> doesn't help and the symptoms stay the same (and, according to the >> documentation and to Kbuild, both are valid values on i686). > > I tried your config with "make localmodconfig" and saw the symptoms. I changed > CONFIG_PHYSICAL_ALIGN from 0x10 to 0x100 and no longer see the > symptoms. No idea why this worked for you. Anyway, if CONFIG_PHYSICAL_ALIGN=0x100 is necessary, then Kconfig should enforce it. And none of this changes that symbols without CRC are a bug. > Did you save your config after changing CONFIG_PHYSICAL_ALIGN ? Well, of course. signature.asc Description: OpenPGP digital signature
Re: [BISECTED] OMAP: DSS: clk rate mismatch
On 2014-01-27 19:30, Ivaylo Dimitrov wrote: > Hi Tomi, > > linux-next-20140124 DSS is broken on N900 - display stays black (there > is some noise though). I booted the kernel with qemu and it gives the > following warning: > > [0.623779] DSS: set fck to 17280 > [0.624237] [ cut here ] > [0.624298] WARNING: CPU: 0 PID: 1 at > drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c() > [0.624359] clk rate mismatch: 28800 != 17280 That says that the omapdss tries to set the func clock to 172.8 MHz, but after setting the rate, the clock is at 288 MHz. I just hit the same warning with beagle-xm yesterday, with v3.13-rc6 + DSS device tree patches, although it might be a different thing. I see that the actual clock is lower than what omapdss tries to set, you have the other way around. The beagle-xm issue is related to a clk-divider fix I have sent some time ago: http://mid.gmane.org/1383736008-22764-1-git-send-email-tomi.valkei...@ti.com Basically the issue is that omapdss needs to produce very precise pixel clocks, derived from fck, but the fck rate options are quite limited. So omapdss tries to find out what kind of rates it could get for the fck, i.e. it does the clock divider calculations itself that would normally be left to the clock framework. That means the omapdss should do rounding the same way as the clock framework does. But clock framework has no rules about the rounding, so omapdss easily gets it wrong. And when you add the bug for which I posted the patch above, it seems the omapdss clock calculations are not very functional at the moment with fractional clock rates. However, I think the issue I see with beagle-xm should always result in lower actual fck than requested, but you see the other way around. So I wonder if it's something else... N900 clock calculations do initiate from sdi.c, instead of dpi.c for beagle, but they do look rather similar, and use the same helper functions from dss.c and dispc.c. How is the dss clock calculated on n900? Can you attach debug/clk/clk_summary output? Tomi signature.asc Description: OpenPGP digital signature
[GIT PULL] MTD changes for 3.14
Hi Linus,
Here are the MTD updates for 3.14. Sorry, I still haven't gotten many
useful signatures on my key yet. I don't know too many local developers
in your web of trust. I'll try to get to a conference soon enough.
Notably, I'm adding myself to MAINTAINERS. I've gotten an ack from Artem
(an unofficial maintainer), but David's ack would be nice.
Regards,
Brian
The following changes since commit 802eee95bde72fd0cd0f3a5b2098375a487d1eda:
Linux 3.13-rc6 (2013-12-29 16:01:33 -0800)
are available in the git repository at:
git://git.infradead.org/linux-mtd.git tags/for-linus-20140127
for you to fetch changes up to 0ff76a920e3558307567b45aa0a91fb914924bfc:
mtd: gpmi: add sanity check when mapping DMA for read_buf/write_buf
(2014-01-27 21:55:03 -0800)
MTD updates for 3.14:
- Add me (Brian Norris) as an additional MTD maintainer (it'd be nice to get
David's "ack" for this; I'm sure he approves, but he's been pretty silent
lately)
- Add Ezequiel Garcia as maintainer for the pxa3xx NAND driver
- Last (?) round of pxa3xx improvements for supporting Armada 370/XP
- Typical churn in driver boilerplate (OOM messages, printk()'s, devm_*, etc.)
- Quad read mode support for SPI NOR driver (m25p80)
- Update Davinci NAND driver to prepare for use on new platforms
- Begin to kill off NAND_MAX_{PAGE,OOB}SIZE macros; more work is pending
- Miscellaneous NAND device support (new IDs)
- Add READ RETRY support for Micron MLC NAND
- Support new GPMI NAND ECC layout device-tree binding
- Avoid mapping stack/vmalloc() memory for GPMI NAND DMA
Alexander Shiyan (1):
mtd: nand: diskonchip: Request memory region prior ioremap()
Axel Lin (3):
mtd: convert to use ATTRIBUTE_GROUPS
mtd: make deregister_mtd_parser return void
mtd: make register_mtd_parser return void
Brian Norris (14):
mtd: nand: pxa3xx: make ECC configuration checks more explicit
mtd: nand: fix misspelling in ONFI parameter field name
MAINTAINERS: mtd: add Brian Norris for MTD maintenance
mtd: nand: lpc32xx_mlc: drop custom write_page callback
mtd: nand-gpio: don't waste memory for OF failure
mtd: omap2: use nand_base defaults for polled I/O
mtd: onenand: fix warning (integer used as pointer)
mtd: nand: localize ECC failures per page
mtd: nand: add ONFI vendor block for Micron
mtd: nand: add generic READ RETRY support
mtd: nand: support Micron READ RETRY
mtd: nand: use __packed shorthand
mtd: m25p80: assign default read command
mtd: mtdram: add missing 'const'
Cai Zhiyong (1):
mtd: nand: assign mtd->name in find_full_id_nand
Ezequiel Garcia (33):
mtd: nand: omap2: Fix OMAP_BCH option dependency
mtd: nand: pxa3xx: devicetree binding update
mtd: nand: pxa3xx: Add documentation about the controller
mtd: nand: pxa3xx: Make config menu show supported platforms
mtd: nand: pxa3xx: Prevent sub-page writes
mtd: nand: pxa3xx: read_page() returns max_bitflips
mtd: nand: pxa3xx: Early variant detection
mtd: nand: pxa3xx: Use chip->cmdfunc instead of the internal
mtd: nand: pxa3xx: Split FIFO size from to-be-read FIFO count
mtd: nand: pxa3xx: Replace host->page_size by mtd->writesize
mtd: nand: pxa3xx: Add a nice comment to pxa3xx_set_datasize()
mtd: nand: pxa3xx: Use a completion to signal device ready
mtd: nand: pxa3xx: Use waitfunc() to wait for the device to be ready
mtd: nand: pxa3xx: Add bad block handling
mtd: nand: pxa3xx: Add driver-specific ECC BCH support
mtd: nand: pxa3xx: Clear cmd buffer #3 (NDCB3) on command start
mtd: nand: pxa3xx: Add helper function to set page address
mtd: nand: pxa3xx: Remove READ0 switch/case falltrough
mtd: nand: pxa3xx: Split prepare_command_pool() in two stages
mtd: nand: pxa3xx: Move the data buffer clean to prepare_start_command()
mtd: nand: pxa3xx: Fix SEQIN column address set
mtd: nand: pxa3xx: Add a read/write buffers markers
mtd: nand: pxa3xx: Introduce multiple page I/O support
mtd: nand: pxa3xx: Add multiple chunk write support
mtd: nand: pxa3xx: Add ECC BCH correctable errors detection
mtd: nand: refactor print messages
MAINTAINERS: mtd: add PXA3xx NAND driver to MAINTAINERS
mtd: nand: sh_flctl: Remove unneeded CONFIG_OF
mtd: nand: pxa3xx: Clear need_wait flag when starting a command
mtd: nand: pxa3xx: Use extended cmdfunc() only if needed
mtd: nand: pxa3xx: Consolidate ECC initialization
mtd: Hide CONFIG_MTD_BLKDEVS from the menu
mtd: nand: pxa3xx: Add "armada370-nand" compatible
Fabio Estevam (4):
mtd: gpmi: Use devm_clk_get()
mtd: gpmi-lib: Make
[PATCH] MAINTAINERS: ADI Linux development mailing lists change to the new server.
From: Sonic Zhang Update Blackfin arch branch maintainer's email as well. Signed-off-by: Sonic Zhang --- MAINTAINERS | 42 -- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7cacc88..bd49e70 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -288,36 +288,36 @@ F:sound/pci/ad1889.* AD525X ANALOG DEVICES DIGITAL POTENTIOMETERS DRIVER M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/AD5254 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/misc/ad525x_dpot.c AD5398 CURRENT REGULATOR DRIVER (AD5398/AD5821) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/AD5398 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/regulator/ad5398.c AD714X CAPACITANCE TOUCH SENSOR DRIVER (AD7142/3/7/8/7A) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/AD7142 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/input/misc/ad714x.c AD7877 TOUCHSCREEN DRIVER M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/AD7877 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/input/touchscreen/ad7877.c AD7879 TOUCHSCREEN DRIVER (AD7879/AD7889) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/AD7879 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/input/touchscreen/ad7879.c @@ -353,8 +353,8 @@ F: include/media/adp1653.h ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/ADP5520 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/mfd/adp5520.c F: drivers/video/backlight/adp5520_bl.c @@ -364,16 +364,16 @@ F:drivers/input/keyboard/adp5520-keys.c ADP5588 QWERTY KEYPAD AND IO EXPANDER DRIVER (ADP5588/ADP5587) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/ADP5588 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/input/keyboard/adp5588-keys.c F: drivers/gpio/gpio-adp5588.c ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/ADP8860 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/video/backlight/adp8860_bl.c @@ -399,8 +399,8 @@ F: drivers/hwmon/adt7475.c ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346) M: Michael Hennerich -L: device-drivers-de...@blackfin.uclinux.org W: http://wiki.analog.com/ADXL345 +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/input/misc/adxl34x.c @@ -588,9 +588,9 @@ F: drivers/media/i2c/adv7604* ANALOG DEVICES INC ASOC CODEC DRIVERS M: Lars-Peter Clausen -L: device-drivers-de...@blackfin.uclinux.org L: alsa-de...@alsa-project.org (moderated for non-subscribers) W: http://wiki.analog.com/ +W: http://ez.analog.com/community/linux-device-drivers S: Supported F: sound/soc/codecs/adau* F: sound/soc/codecs/adav* @@ -599,7 +599,7 @@ F: sound/soc/codecs/ssm* F: sound/soc/codecs/sigmadsp.* ANALOG DEVICES INC ASOC DRIVERS -L: uclinux-dist-de...@blackfin.uclinux.org +L: adi-buildroot-de...@lists.sourceforge.net L: alsa-de...@alsa-project.org (moderated for non-subscribers) W: http://blackfin.uclinux.org/ S: Supported @@ -1666,56 +1666,54 @@ F: fs/bfs/ F: include/uapi/linux/bfs_fs.h BLACKFIN ARCHITECTURE -M: Mike Frysinger -L: uclinux-dist-de...@blackfin.uclinux.org +M: Steven Miao +L: adi-buildroot-de...@lists.sourceforge.net W: http://blackfin.uclinux.org S: Supported F: arch/blackfin/ BLACKFIN EMAC DRIVER -L: uclinux-dist-de...@blackfin.uclinux.org +L: adi-buildroot-de...@lists.sourceforge.net W: http://blackfin.uclinux.org S: Supported F: drivers/net/ethernet/adi/ BLACKFIN RTC DRIVER -M: Mike Frysinger -L: uclinux-dist-de...@blackfin.uclinux.org +L: adi-buildroot-de...@lists.sourceforge.net W: http://blackfin.uclinux.org S: Supported F: drivers/rtc/rtc-bfin.c BLACKFIN SDH DRIVER M: Sonic Zhang -L: uclinux-dist-de...@blackfin.uclinux.org +L: adi-buildroot-de...@lists.sourceforge.net W: http://blackfin.uclinux.org S: Supported F: drivers/mmc/host/bfin_sdh.c BLACKFIN SERIAL DRIVER M: Sonic Zhan
Re: How to identify 6to4 and 6in4 tunnels
On 01/28/2014 03:32 PM, zhuyj wrote: On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could we have any way to get the actual tunnel for 6in4 and 6to4 from current linux version? Both 6in4 and 6to4 have the same protocol “IPPROTO_IPV6” in Linux kernel. The only difference is the ip address on the tunnel. Can we distinguish them in Linux kernel? Just check the prefix, like it is done in check_6rd(). Regards, Nicolas Hi, Nicolas Thanks for your reply. Maybe I can configure 6to4 tunnel by the following commands: ip tunnel add tun6to4 mode sit remote any local 1.202.252.122 ttl 64 ip link set dev tun6to4 up ip -6 addr add 2002:01ca:fc7a::0012:0225:2122/128 dev tun6to4 ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 But the kernel can not identify the tunnel is 6to4 tunnel or 6in4 tunnel immediately. After the packets travel through this tunnel, the kernel can identify the type of the tunnel by check_6rd. Is it right? Best Regards! Zhu Yanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: fixed: update to devm_* API
On Tuesday, 28. January 2014 12:46:01 Manish Badarkhe wrote:
> Hi Dmitry,
>
> Thank you for your review.
>
> On Tue, Jan 28, 2014 at 12:03 PM, Dmitry Torokhov
>
> wrote:
> > Hi Manish,
> >
> > On Tue, Jan 28, 2014 at 08:42:00AM +0530, Manish Badarkhe wrote:
> >> Update the code to use devm_* API so that driver core will manage
> >> resources.
> >>
> >> Signed-off-by: Manish Badarkhe
> >> ---
> >> Changes since V1:
> >> 1. Updated driver to use "devm_kzalloc" to "kstrdup".
> >> 2. Updated commit message.
> >>
> >> Not tested on any board.
> >>
> >> :100644 100644 5ea64b9... e9763a4... Mdrivers/regulator/fixed.c
> >> :
> >> drivers/regulator/fixed.c | 42
> >> --
> >> 1 file changed, 12 insertions(+), 30 deletions(-)
> >>
> >> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> >> index 5ea64b9..e9763a4 100644
> >> --- a/drivers/regulator/fixed.c
> >> +++ b/drivers/regulator/fixed.c
> >> @@ -132,15 +132,15 @@ static int reg_fixed_voltage_probe(struct
> >> platform_device *pdev)>>
> >> GFP_KERNEL);
> >>
> >> if (drvdata == NULL) {
> >>
> >> dev_err(&pdev->dev, "Failed to allocate device data\n");
> >>
> >> - ret = -ENOMEM;
> >> - goto err;
> >> + return -ENOMEM;
> >>
> >> }
> >>
> >> - drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
> >> + drvdata->desc.name = devm_kzalloc(&pdev->dev,
> >> + strlen(config->supply_name) + 1,
> >> + GFP_KERNEL);
> >>
> >> if (drvdata->desc.name == NULL) {
> >>
> >> dev_err(&pdev->dev, "Failed to allocate supply name\n");
> >>
> >> - ret = -ENOMEM;
> >> - goto err;
> >> + return -ENOMEM;
> >>
> >> }
> >
> > Umm, I am fairly certain that devm_kzalloc() can't be used as a
> > substitute for kstrdup, at least not without accompanying memcpy.
>
> Yes, I have provided allocation but it should be followed with assignment.
> Can I modify like this,
>
> + drvdata->desc.name = devm_kzalloc(&pdev->dev,
> + strlen(config->supply_name) + 1,
> + GFP_KERNEL);
> + if (drvdata->desc.name)
> + sprintf(drvdata->desc.name, "%s", config->supply_name);
hmm, so you replaced a general helper function by open coding the string-
duplication. Doesn't this defeat the target of simplifying the code?
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to identify 6to4 and 6in4 tunnels
On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could we have any way to get the actual tunnel for 6in4 and 6to4 from current linux version? Both 6in4 and 6to4 have the same protocol “IPPROTO_IPV6” in Linux kernel. The only difference is the ip address on the tunnel. Can we distinguish them in Linux kernel? Just check the prefix, like it is done in check_6rd(). Regards, Nicolas Hi, Nicolas Thanks for your reply. Maybe I can configure 6to4 tunnel by the following commands: ip tunnel add tun6to4 mode sit remote any local 1.202.252.122 ttl 64 ip link set dev tun6to4 up ip -6 addr add 2002:01ca:fc7a::0012:0225:2122/128 dev tun6to4 ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 But the kernel can not identify the tunnel is 6to4 tunnel or 6in4 tunnel immediately. After the packets travel through this tunnel, the kernel can identify the type of the tunnel by check_6rd. Is it right? Best Regards! Zhu Yanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -tip] sched/deadline: switched_to_dl() -- skip if task is current
v2: Changed comment
When p is current and it's not of dl class, then there are no other
dl taks in the rq. If we had had pushable tasks in some other rq,
they would have been pushed earlier. So, skip "p == rq->curr" case.
[This is confirmed by Juri Lelli and LKML was CC'ed, but
unfotunately I can't find direct link on lkml.org]
Signed-off-by: Kirill Tkhai
CC: Juri Lelli
CC: Peter Zijlstra
CC: Ingo Molnar
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 0de2482..dd19d6d 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1559,7 +1559,7 @@ static void switched_to_dl(struct rq *rq, struct
task_struct *p)
if (unlikely(p->dl.dl_throttled))
return;
- if (p->on_rq || rq->curr != p) {
+ if (p->on_rq && rq->curr != p) {
#ifdef CONFIG_SMP
if (rq->dl.overloaded && push_dl_task(rq) && rq != task_rq(p))
/* Only reschedule if pushing failed */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dw: Add suspend and resume handling for PCI mode DW_DMAC.
> -Original Message- > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] > Sent: Monday, January 27, 2014 6:17 PM > To: Koul, Vinod > Cc: Andy Shevchenko; Chew, Chiau Ee; Viresh Kumar; Williams, Dan J; > dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] dma: dw: Add suspend and resume handling for PCI mode > DW_DMAC. > > On Sun, 2014-01-26 at 16:47 +0530, Vinod Koul wrote: > > > > > > > For these cases, I have been using suspend_late. Since the > > > > > > dmaengine driver is providing service to other clients (SPI), > > > > > > it needs to esnure that it suspends after SPI using > > > > > > suspend_late and resume using resume_early. That way dma is > > > > > > availble whenever the client is active > > > > > > > > > > suspend_late is working in context that interrupt handler may be > > > > > invoked. Thus, to have DMA driver be properly shut down we have > > > > > to wait / terminate possible ongoing transfer. > > > > Well client is already suspended via .suspend. So where is the > > > > transaction :) > > > > > > ...as I already wrote before we have no parent-child relationship > > > between DMA and, for example, SPI. That means we may possible have > > > the case when SPI's .suspend() will be called later than DMA's one. > > > > > > > > It seems for me all DMA drivers that are using system > > > > > .suspend()/.resume() are potentially buggy. > > > > Yup! > > > > > > So, we have to decide what to do with them. .suspend_late() still > > > seems for me not the best approach. *Or* we have to check for > > > ongoing transaction and do something with it. *Or* just shut down > > > the device and rely on DMA transaction initiator that it handles the > > > terminated transaction properly. > > > > As you clearly said, we dont have a parent-child relatation though we > > have big dependency. I think this is true for DMA clients, i ran into > > similar situation with i2c few days back! > > > > So only think which can give us a good system behaviour would be > > clients getting suspended first and then then service providing subsystems. > > Agree. > > > (same reason why we > > do dma driver loading and init much before others drivers) > > Yes, it would be done via deferred probe. > > > So yes in the .suspend callback of the client, it needs to > > 1) abort any transactions it has > > 2) make the client quiscent > > > > then the .late_suspend kicks in and suspend the core drivers like dma. > > > > This is how it has worked reliably for me in production systems. I am > > all ears if we have a better and cleaner apprach to this problem :) > > Yes, summarize everything we discussed we have to: > - provide suspend_late, resume_early callbacks in the DMA driver instead of > *_noirq versions > - ensure that all clients on our platforms follow the described scenario > > Chiau Ee, I think you may to change your patch accordingly. Ok. Noted > > > -- > Andy Shevchenko > Intel Finland Oy
[PATCH -tip] sched/deadline: switched_to_dl() -- skip if task is current
When p is current and it's not of dl class, then there are no other
dl taks in the rq. If we had had pushable tasks in some other rq,
they would have been pushed earlier. So, skip "p == rq->curr" case.
This helps to skip excess schedule() when class is changed.
The situation may be not rare. For example:
a small number of deadline tasks which have common rt_spinlocks
with fair tasks. Priority inheritance mechanism does this every
time it is acquiring a lock.
[This is confirmed by Juri Lelli and LKML was CC'ed, but
unfotunately I can't find direct link on lkml.org]
Signed-off-by: Kirill Tkhai
CC: Juri Lelli
CC: Peter Zijlstra
CC: Ingo Molnar
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 0de2482..dd19d6d 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1559,7 +1559,7 @@ static void switched_to_dl(struct rq *rq, struct
task_struct *p)
if (unlikely(p->dl.dl_throttled))
return;
- if (p->on_rq || rq->curr != p) {
+ if (p->on_rq && rq->curr != p) {
#ifdef CONFIG_SMP
if (rq->dl.overloaded && push_dl_task(rq) && rq != task_rq(p))
/* Only reschedule if pushing failed */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: fixed: update to devm_* API
Hi Dmitry,
Thank you for your review.
On Tue, Jan 28, 2014 at 12:03 PM, Dmitry Torokhov
wrote:
> Hi Manish,
>
> On Tue, Jan 28, 2014 at 08:42:00AM +0530, Manish Badarkhe wrote:
>> Update the code to use devm_* API so that driver core will manage
>> resources.
>>
>> Signed-off-by: Manish Badarkhe
>> ---
>> Changes since V1:
>> 1. Updated driver to use "devm_kzalloc" to "kstrdup".
>> 2. Updated commit message.
>>
>> Not tested on any board.
>>
>> :100644 100644 5ea64b9... e9763a4... Mdrivers/regulator/fixed.c
>> drivers/regulator/fixed.c | 42 --
>> 1 file changed, 12 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
>> index 5ea64b9..e9763a4 100644
>> --- a/drivers/regulator/fixed.c
>> +++ b/drivers/regulator/fixed.c
>> @@ -132,15 +132,15 @@ static int reg_fixed_voltage_probe(struct
>> platform_device *pdev)
>> GFP_KERNEL);
>> if (drvdata == NULL) {
>> dev_err(&pdev->dev, "Failed to allocate device data\n");
>> - ret = -ENOMEM;
>> - goto err;
>> + return -ENOMEM;
>> }
>>
>> - drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
>> + drvdata->desc.name = devm_kzalloc(&pdev->dev,
>> + strlen(config->supply_name) + 1,
>> + GFP_KERNEL);
>> if (drvdata->desc.name == NULL) {
>> dev_err(&pdev->dev, "Failed to allocate supply name\n");
>> - ret = -ENOMEM;
>> - goto err;
>> + return -ENOMEM;
>> }
>
> Umm, I am fairly certain that devm_kzalloc() can't be used as a
> substitute for kstrdup, at least not without accompanying memcpy.
Yes, I have provided allocation but it should be followed with assignment.
Can I modify like this,
+ drvdata->desc.name = devm_kzalloc(&pdev->dev,
+ strlen(config->supply_name) + 1,
+ GFP_KERNEL);
+ if (drvdata->desc.name)
+ sprintf(drvdata->desc.name, "%s", config->supply_name);
Thanks
Manish Badakhe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFCv2,2/2] i2c: add new dual Flash driver,LM3646
On 01/28/2014 07:55 AM, Daniel Jeong wrote:
> Add new dual flash driver.
> LM3646 is a dual Flash LED Driver, LED1 and LED2, following the datasheet.
> But there is no registers to contorl LED2 brightness.
> LED2 brightness can be controlled by limiting max brightness.
> LED2 brightness = Total brightness - LED1 brightness
> LED2 will be off if LED2 brightness is set equal to or bigger than Total
> brightness.
> And the brightness step is very small, 1.46mA for Torch, 11.71mA for Flash.
> If the step is changed to mA, maximum brightness cannot be reachable.
>
> Signed-off-by: Daniel Jeong
> ---
> drivers/media/i2c/Kconfig |9 +
> drivers/media/i2c/Makefile |1 +
> drivers/media/i2c/lm3646.c | 400
>
> include/media/lm3646.h | 87 ++
> 4 files changed, 497 insertions(+)
> create mode 100644 drivers/media/i2c/lm3646.c
> create mode 100644 include/media/lm3646.h
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 842654d..654df46 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -630,6 +630,15 @@ config VIDEO_LM3560
> This is a driver for the lm3560 dual flash controllers. It controls
> flash, torch LEDs.
>
> +config VIDEO_LM3646
> + tristate "LM3646 dual flash driver support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on MEDIA_CAMERA_SUPPORT
> + select REGMAP_I2C
> + ---help---
> + This is a driver for the lm3646 dual flash controllers. It controls
> + flash, torch LEDs.
> +
> comment "Video improvement chips"
>
> config VIDEO_UPD64031A
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index e03f177..a52cda6 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_S5C73M3) += s5c73m3/
> obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
> obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o
> obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
> +obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
> obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
> obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
> diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
> new file mode 100644
> index 000..4b025f2
> --- /dev/null
> +++ b/drivers/media/i2c/lm3646.c
> @@ -0,0 +1,400 @@
> +/*
> + * drivers/media/i2c/lm3646.c
> + * General device driver for TI lm3646, Dual FLASH LED Driver
> + *
> + * Copyright (C) 2014 Texas Instruments
> + *
> + * Contact: Daniel Jeong
> + * Ldd-Mlp
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* registers definitions */
> +#define REG_ENABLE 0x01
> +#define REG_TORCH_BR 0x05
> +#define REG_FLASH_BR 0x05
> +#define REG_FLASH_TOUT 0x04
> +#define REG_FLAG 0x08
> +#define REG_STROBE_SRC 0x06
> +#define REG_LED1_FLASH_BR 0x06
> +#define REG_LED1_TORCH_BR 0x07
> +
> +#define MASK_ENABLE 0x03
> +#define MASK_TORCH_BR0x70
> +#define MASK_FLASH_BR0x0F
> +#define MASK_FLASH_TOUT 0x07
> +#define MASK_FLAG0xFF
> +#define MASK_STROBE_SRC 0x80
> +
> +/* Fault Mask */
> +#define FAULT_TIMEOUT(1<<0)
> +#define FAULT_SHORT_CIRCUIT (1<<1)
> +#define FAULT_UVLO (1<<2)
> +#define FAULT_IVFM (1<<3)
> +#define FAULT_OCP(1<<4)
> +#define FAULT_OVERTEMP (1<<5)
> +#define FAULT_NTC_TRIP (1<<6)
> +#define FAULT_OVP(1<<7)
> +
> +enum led_mode {
> + MODE_SHDN = 0x0,
> + MODE_TORCH = 0x2,
> + MODE_FLASH = 0x3,
> +};
> +
> +/*
> + * struct lm3646_flash
> + *
> + * @pdata: platform data
> + * @regmap: reg. map for i2c
> + * @lock: muxtex for serial access.
> + * @led_mode: V4L2 LED mode
> + * @ctrls_led: V4L2 contols
> + * @subdev_led: V4L2 subdev
> + */
> +struct lm3646_flash {
> + struct device *dev;
> + struct lm3646_platform_data *pdata;
> + struct regmap *regmap;
> +
> + enum v4l2_flash_led_mode led_mode;
> + struct v4l2_ctrl_handler ctrls_led;
> + struct v4l2_subdev subdev_led;
> +};
> +
> +#define to_lm3646_flash(_ctrl) \
> + container_of(_ctrl->handler, struct lm3646_flash, ctrls_led)
> +
> +/* enable mode control */
> +static int lm3646_mode_ctrl(struct lm3646_flash *flash)
> +{
> + int rval = -EINVAL;
> +
> + switch (flash->led_mode) {
> + case V4L2_FLASH_LED_MODE_NONE:
> + rval = regmap_update_bits(flash->regmap,
> + REG_ENABLE, MASK_ENABLE, MODE_SHDN);
> + break;
> + case V4L2_FLASH_LED_MODE_TORCH:
> + rval =
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
Hi Dave, I think here is the overflow problem. Not the stackoverflow, but the array index overflow. Please have a look at the following path: numa_init() |---> numa_register_memblks() | |---> memblock_set_node(memory) set correct nid in memblock.memory | |---> memblock_set_node(reserved) set correct nid in memblock.reserved | |.. | |---> setup_node_data() | |---> memblock_alloc_nid() here, nid is set to MAX_NUMNODES (1024) |.. |---> numa_clear_kernel_node_hotplug() |---> node_set() here, we have an index 1024, and overflowed For now, I think this is the first problem you mentioned. Will send a new patch to fix it and do more tests. Thanks. On 01/28/2014 01:31 PM, Tang Chen wrote: On 01/28/2014 12:47 PM, Dave Jones wrote: On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote: > On 01/28/2014 11:55 AM, Dave Jones wrote: > > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote: > > > > > > I did a bisect with the patch above applied each step of the way. > > > > This time I got a plausible looking result > > > > > > I cannot reproduce this. Would you please share how to reproduce it ? > > > Or does it just happen during the booting ? > > > > Just during boot. Very early. So early in fact, I have no logging facilities > > like usb-serial, just what is on vga console. > > > > If you want me to add some printk's, I can add a while (1); before > > the part that oopses so we can diagnose further.. > > Sure. Would you please do that for me ? Maybe we can find something in > the early log. I was hoping you'd have suggestions what you'd like me to dump ;-) I think I found something. Since I can reproduce the first problem on 3.10, I found some memory ranges in memblock have nid = 1024. When we use node_set(), it will crash. I'll see if we have the same problem on the latest kernel. [ 0.00] NUMA: Initialized distance table, cnt=2 [ 0.00] NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10 [ 0.00] NUMA: Node 0 [mem 0x-0x7fff] + [mem 0x1-0x47fff] -> [mem 0x-0x47fff] [ 0.00] Initmem setup node 0 [mem 0x-0x47fff] [ 0.00] NODE_DATA [mem 0x47ffd9000-0x47fff] [ 0.00] Initmem setup node 1 [mem 0x48000-0x87fff] [ 0.00] NODE_DATA [mem 0x87ffbb000-0x87ffe1fff] [ 0.00] : i = 0, nid = 0 [ 0.00] : i = 1, nid = 0 [ 0.00] : i = 2, nid = 0 [ 0.00] : i = 3, nid = 0 [ 0.00] : i = 4, nid = 1024 [ 0.00] : i = 5, nid = 1024 [ 0.00] : i = 6, nid = 1 [ 0.00] : i = 7, nid = 1 [ 0.00] Reserving 128MB of memory at 704MB for crashkernel (System RAM: 32406MB) [ 0.00] [ea00-ea0011ff] PMD -> [88047020-88047fdf] on node 0 [ 0.00] [ea001200-ea0021ff] PMD -> [88086f60-88087f5f] on node 1 [ 0.00] Zone ranges: [ 0.00] DMA [mem 0x1000-0x00ff] [ 0.00] DMA32 [mem 0x0100-0x] [ 0.00] Normal [mem 0x1-0x87fff] [ 0.00] Movable zone start for each node [ 0.00] Early memory node ranges [ 0.00] node 0: [mem 0x1000-0x00098fff] [ 0.00] node 0: [mem 0x0010-0x696f7fff] [ 0.00] node 0: [mem 0x1-0x47fff] [ 0.00] node 1: [mem 0x48000-0x87fff] 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] Intel MPX support
On 01/28/2014 02:42 PM, Ingo Molnar wrote: * Ren Qiaowei wrote: MPX kernel code, namely this patchset, has mainly the 2 responsibilities: provide handlers for bounds faults (#BR), and manage bounds memory. AFAICS the kernel side implementation causes no runtime overhead for non-MPX workloads, and also causes no runtime overhead for non-MPX hardware, right? Yes. Actually, I think that's not entirely true. For example if within the same mm there's a lot of non-MPX threads and an MPX thread, then the MMU notifier will be called for MMU operations of every non-MPX thread as well! So MPX state of a thread will slow down all the other non-MPX threads as well. The statement is only true for non-MPX tasks that have their separate mm's that does not have a single MPX thread. Yes. Though all non-MPX threads are slowed down, the whole process benefit from MPX. Anyway, HPA suggest these syscalls, which use MMU notifier, should be not needed, we can do what they do in userspace runtime. What do you think about it? I guess that I should remove the third patch which adds new prctl() syscalls in next version of this patchset. Thanks, Qiaowei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RFCv2,1/2] v4l2-controls.h: add addtional Flash fault bits
On 01/28/2014 07:55 AM, Daniel Jeong wrote:
> Add additional FLASH Fault bits to dectect faults from chip.
> Some Flash drivers support UVLO, IVFM, NTC Trip faults.
> UVLO :Under Voltage Lock Out Threshold crossed
> IVFM :IVFM block reported and/or adjusted LED current Input Voltage
> Flash Monitor trip threshold
> NTC :NTC Threshold crossed. Many Flash drivers have a pin and the
> fault bit to
> serves as a threshold detector for negative temperature coefficient (NTC)
> thermistors.
Please document these new flags as well in
Documentation/DocBook/media/v4l/controls.xml.
Regards,
Hans
>
> Signed-off-by: Daniel Jeong
> ---
> include/uapi/linux/v4l2-controls.h |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index 1666aab..01d730c 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -803,6 +803,9 @@ enum v4l2_flash_strobe_source {
> #define V4L2_FLASH_FAULT_SHORT_CIRCUIT (1 << 3)
> #define V4L2_FLASH_FAULT_OVER_CURRENT(1 << 4)
> #define V4L2_FLASH_FAULT_INDICATOR (1 << 5)
> +#define V4L2_FLASH_FAULT_UVLO(1 << 6)
> +#define V4L2_FLASH_FAULT_IVFM(1 << 7)
> +#define V4L2_FLASH_FAULT_NTC_TRIP(1 << 8)
>
> #define V4L2_CID_FLASH_CHARGE
> (V4L2_CID_FLASH_CLASS_BASE + 11)
> #define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFCv2,2/2] i2c: add new dual Flash driver,LM3646
Add new dual flash driver.
LM3646 is a dual Flash LED Driver, LED1 and LED2, following the datasheet.
But there is no registers to contorl LED2 brightness.
LED2 brightness can be controlled by limiting max brightness.
LED2 brightness = Total brightness - LED1 brightness
LED2 will be off if LED2 brightness is set equal to or bigger than Total
brightness.
And the brightness step is very small, 1.46mA for Torch, 11.71mA for Flash.
If the step is changed to mA, maximum brightness cannot be reachable.
Signed-off-by: Daniel Jeong
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/lm3646.c | 400
include/media/lm3646.h | 87 ++
4 files changed, 497 insertions(+)
create mode 100644 drivers/media/i2c/lm3646.c
create mode 100644 include/media/lm3646.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 842654d..654df46 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -630,6 +630,15 @@ config VIDEO_LM3560
This is a driver for the lm3560 dual flash controllers. It controls
flash, torch LEDs.
+config VIDEO_LM3646
+ tristate "LM3646 dual flash driver support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on MEDIA_CAMERA_SUPPORT
+ select REGMAP_I2C
+ ---help---
+ This is a driver for the lm3646 dual flash controllers. It controls
+ flash, torch LEDs.
+
comment "Video improvement chips"
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index e03f177..a52cda6 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_S5C73M3) += s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
obj-$(CONFIG_VIDEO_LM3560) += lm3560.o
+obj-$(CONFIG_VIDEO_LM3646) += lm3646.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
diff --git a/drivers/media/i2c/lm3646.c b/drivers/media/i2c/lm3646.c
new file mode 100644
index 000..4b025f2
--- /dev/null
+++ b/drivers/media/i2c/lm3646.c
@@ -0,0 +1,400 @@
+/*
+ * drivers/media/i2c/lm3646.c
+ * General device driver for TI lm3646, Dual FLASH LED Driver
+ *
+ * Copyright (C) 2014 Texas Instruments
+ *
+ * Contact: Daniel Jeong
+ * Ldd-Mlp
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* registers definitions */
+#define REG_ENABLE 0x01
+#define REG_TORCH_BR 0x05
+#define REG_FLASH_BR 0x05
+#define REG_FLASH_TOUT 0x04
+#define REG_FLAG 0x08
+#define REG_STROBE_SRC 0x06
+#define REG_LED1_FLASH_BR 0x06
+#define REG_LED1_TORCH_BR 0x07
+
+#define MASK_ENABLE0x03
+#define MASK_TORCH_BR 0x70
+#define MASK_FLASH_BR 0x0F
+#define MASK_FLASH_TOUT0x07
+#define MASK_FLAG 0xFF
+#define MASK_STROBE_SRC0x80
+
+/* Fault Mask */
+#define FAULT_TIMEOUT (1<<0)
+#define FAULT_SHORT_CIRCUIT(1<<1)
+#define FAULT_UVLO (1<<2)
+#define FAULT_IVFM (1<<3)
+#define FAULT_OCP (1<<4)
+#define FAULT_OVERTEMP (1<<5)
+#define FAULT_NTC_TRIP (1<<6)
+#define FAULT_OVP (1<<7)
+
+enum led_mode {
+ MODE_SHDN = 0x0,
+ MODE_TORCH = 0x2,
+ MODE_FLASH = 0x3,
+};
+
+/*
+ * struct lm3646_flash
+ *
+ * @pdata: platform data
+ * @regmap: reg. map for i2c
+ * @lock: muxtex for serial access.
+ * @led_mode: V4L2 LED mode
+ * @ctrls_led: V4L2 contols
+ * @subdev_led: V4L2 subdev
+ */
+struct lm3646_flash {
+ struct device *dev;
+ struct lm3646_platform_data *pdata;
+ struct regmap *regmap;
+
+ enum v4l2_flash_led_mode led_mode;
+ struct v4l2_ctrl_handler ctrls_led;
+ struct v4l2_subdev subdev_led;
+};
+
+#define to_lm3646_flash(_ctrl) \
+ container_of(_ctrl->handler, struct lm3646_flash, ctrls_led)
+
+/* enable mode control */
+static int lm3646_mode_ctrl(struct lm3646_flash *flash)
+{
+ int rval = -EINVAL;
+
+ switch (flash->led_mode) {
+ case V4L2_FLASH_LED_MODE_NONE:
+ rval = regmap_update_bits(flash->regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_SHDN);
+ break;
+ case V4L2_FLASH_LED_MODE_TORCH:
+ rval = regmap_update_bits(flash->regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_TORCH);
+ break;
+ case V4L2_FLASH_LED_MODE_FLASH:
+ rval = regmap_update_bits(flash->regmap,
+ REG_ENABLE, MASK_ENABLE, MODE_
[RFCv2,1/2] v4l2-controls.h: add addtional Flash fault bits
Add additional FLASH Fault bits to dectect faults from chip.
Some Flash drivers support UVLO, IVFM, NTC Trip faults.
UVLO : Under Voltage Lock Out Threshold crossed
IVFM : IVFM block reported and/or adjusted LED current Input Voltage Flash
Monitor trip threshold
NTC : NTC Threshold crossed. Many Flash drivers have a pin and the fault bit
to
serves as a threshold detector for negative temperature coefficient (NTC)
thermistors.
Signed-off-by: Daniel Jeong
---
include/uapi/linux/v4l2-controls.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 1666aab..01d730c 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -803,6 +803,9 @@ enum v4l2_flash_strobe_source {
#define V4L2_FLASH_FAULT_SHORT_CIRCUIT (1 << 3)
#define V4L2_FLASH_FAULT_OVER_CURRENT (1 << 4)
#define V4L2_FLASH_FAULT_INDICATOR (1 << 5)
+#define V4L2_FLASH_FAULT_UVLO (1 << 6)
+#define V4L2_FLASH_FAULT_IVFM (1 << 7)
+#define V4L2_FLASH_FAULT_NTC_TRIP (1 << 8)
#define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11)
#define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
--
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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Tue, Jan 28, 2014 at 01:17:21PM +0800, Tang Chen wrote: > Seeing from your earlier mail, it crashed at: > > while (zonelist_zone_idx(z) > highest_zoneidx) >de: 3b 77 08cmp0x8(%rdi),%esi > > > I stuck this at the top of the function.. > > printk(KERN_ERR "z:%p nodes:%p highest:%d\n", z, nodes, > highest_zoneidx); > > and got > > z: 1d08 nodes: (null) highest:3 > > > nodes=null and highest=3, they are correct. When looking into > next_zones_zonelist(), > I cannot see why it crashed. So, can you print the zone id in the > for_each_zone_zonelist() loop in nr_free_zone_pages() ? > I want to know why it crashed. A NULL pointer ? Which one ? It's not so easy further in the function, because the oops scrolls off any useful printks, there's no scrollback, and no logging.. I even tried adding some udelays to slow things down (and using boot_delay) but that makes things just hang seemingly indefinitly. What about that 'z' ptr though ? 0x1d08 seems like a strange address for us to have a structure at, though I'm not too familiar with the early boot code, so maybe we do have something down there ? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] x86, mpx: hook #BR exception handler to allocate bound tables
On 01/28/2014 02:42 PM, Andy Lutomirski wrote:
I just read it. do_trap_no_signal presumably calls fixup_exception
because #UD uses it and #UD needs that handling. (I'm guessing that
there is actually a legitimate use for a kernel fixup on #UD somewhere
-- there's probably something that isn't covered by cpuid.)
There should not be a #BR from the kernel using the fixup mechanism.
IMO if the exception comes from the kernel, it should unconditionally
call die.
Oh. I agree with you, and if a #BR from the kernel it should
unconditionally call die.
if (!user_mode(regs))
die("bounds", regs, error_code);
Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Input: zforce - fix various small issues
On Mon, Jan 27, 2014 at 07:46:09PM +0100, Luis Ortega wrote: > As a kernel newbie and owner of a Barnes & Noble e-reader I was > curious to review this driver to learn more about the touchscreen. > > The first two patches are fairly innocuous whereas the last two > slightly modify the code to fix two small issues I discovered. > I don't have the setup to test them but they look logically correct > to me. > > [PATCH 1/4] Input: zforce - fix spelling errors > [PATCH 2/4] Input: zforce - fix lines exceeding 80 columns > [PATCH 3/4] Input: zforce - Remove unnecessary payload data checks > [PATCH 4/4] Input: zforce - reduce stack memory allocated to frames Applied all 4, thank you. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] x86, mpx: hook #BR exception handler to allocate bound tables
On Mon, Jan 27, 2014 at 9:39 PM, Ren Qiaowei wrote:
> On 01/28/2014 01:21 PM, Andy Lutomirski wrote:
>>
>> On Mon, Jan 27, 2014 at 7:35 PM, Ren Qiaowei
>> wrote:
>>>
>>> On 01/28/2014 04:36 AM, Andy Lutomirski wrote:
>
>
> + bd_entry = status & MPX_BNDSTA_ADDR_MASK;
> + if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
> + allocate_bt(bd_entry);
What happens if this fails? Retrying forever isn't very nice.
>>> If allocation of the bound table fail, the related entry in the bound
>>> directory is still invalid. The following access to this entry still
>>> produce
>>> #BR fault.
>>>
>>
>> By the "following access" I think you mean the same instruction that
>> just trapped -- it will trap again because the exception hasn't been
>> fixed up. Then mmap will fail again, and you'll retry again, leading
>> to an infinite loop.
>>
> I don't mean the same instruction that just trapped.
I haven't dug to the right page of the docs, I guess. What is RIP set
to when an MPX instruction causes #BR?
It's *certainly* not okay to fail the fixup and skip the offending instruction.
>
>
>> I think that failure to fix up the exception should either let the
>> normal bounds error through or should raise SIGBUS.
>>
> Maybe we need HPA help answer this question. Peter, what do you think about
> it? If allocation of the bound table fail, what should we do?
>
>
>>>
> + if (!user_mode(regs)) {
> + if (!fixup_exception(regs)) {
> + tsk->thread.error_code = error_code;
> + tsk->thread.trap_nr = X86_TRAP_BR;
> + die("bounds", regs, error_code);
> + }
Why the fixup? Unless I'm missing something, the kernel has no business
getting #BR on access to a user address.
Or are you adding code to allow the kernel to use MPX itself? If so,
shouldn't this use an MPX-specific fixup to allow normal C code to use
this stuff?
>>> It checks whether #BR come from user-space. You can see
>>> do_trap_no_signal().
>>
>>
>> Wasn't #BR using do_trap before? do_trap doesn't call
>> fixup_exception. I don't see why it should do it now. (I also don't
>> think it should come from kernel space until someone adds kernel-mode
>> MPX support.)
>>
> do_trap() -> do_trap_no_signal() call similar code to check if the fault
> occurred in userspace or kernel space. You can see previous discussion for
> the first version of this patchset.
I just read it. do_trap_no_signal presumably calls fixup_exception
because #UD uses it and #UD needs that handling. (I'm guessing that
there is actually a legitimate use for a kernel fixup on #UD somewhere
-- there's probably something that isn't covered by cpuid.)
There should not be a #BR from the kernel using the fixup mechanism.
IMO if the exception comes from the kernel, it should unconditionally
call die.
At some point there might be legitimate #BR faults from the kernel due
to actual in-kernel use of the MPX translation table. This is a whole
different story.
(Presumably the right thing to do is to have gcc support for wide
pointers that contain their own bounds.)
--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 v3 0/4] Intel MPX support
* Ren Qiaowei wrote: > >> MPX kernel code, namely this patchset, has mainly the 2 > >> responsibilities: provide handlers for bounds faults (#BR), and > >> manage bounds memory. > > > > AFAICS the kernel side implementation causes no runtime overhead > > for non-MPX workloads, and also causes no runtime overhead for > > non-MPX hardware, right? > > Yes. Actually, I think that's not entirely true. For example if within the same mm there's a lot of non-MPX threads and an MPX thread, then the MMU notifier will be called for MMU operations of every non-MPX thread as well! So MPX state of a thread will slow down all the other non-MPX threads as well. The statement is only true for non-MPX tasks that have their separate mm's that does not have a single MPX thread. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuset: update MAINTAINERS entry
On Tue, 28 Jan 2014, Li Zefan wrote: > diff --git a/MAINTAINERS b/MAINTAINERS > index 8285ed4..81bcbe0 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2376,8 +2376,10 @@ F: tools/power/cpupower/ > > CPUSETS > M: Li Zefan > +L: cgro...@vger.kernel.org > W: http://www.bullopensource.org/cpuset/ > W: http://oss.sgi.com/projects/cpusets/ > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git > S: Maintained > F: Documentation/cgroups/cpusets.txt > F: include/linux/cpuset.h It seems like Tejun would obviously be a maintainer as well? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] regulator: fixed: update to devm_* API
Hi Manish,
On Tue, Jan 28, 2014 at 08:42:00AM +0530, Manish Badarkhe wrote:
> Update the code to use devm_* API so that driver core will manage
> resources.
>
> Signed-off-by: Manish Badarkhe
> ---
> Changes since V1:
> 1. Updated driver to use "devm_kzalloc" to "kstrdup".
> 2. Updated commit message.
>
> Not tested on any board.
>
> :100644 100644 5ea64b9... e9763a4... Mdrivers/regulator/fixed.c
> drivers/regulator/fixed.c | 42 --
> 1 file changed, 12 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> index 5ea64b9..e9763a4 100644
> --- a/drivers/regulator/fixed.c
> +++ b/drivers/regulator/fixed.c
> @@ -132,15 +132,15 @@ static int reg_fixed_voltage_probe(struct
> platform_device *pdev)
> GFP_KERNEL);
> if (drvdata == NULL) {
> dev_err(&pdev->dev, "Failed to allocate device data\n");
> - ret = -ENOMEM;
> - goto err;
> + return -ENOMEM;
> }
>
> - drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
> + drvdata->desc.name = devm_kzalloc(&pdev->dev,
> + strlen(config->supply_name) + 1,
> + GFP_KERNEL);
> if (drvdata->desc.name == NULL) {
> dev_err(&pdev->dev, "Failed to allocate supply name\n");
> - ret = -ENOMEM;
> - goto err;
> + return -ENOMEM;
> }
Umm, I am fairly certain that devm_kzalloc() can't be used as a
substitute for kstrdup, at least not without accompanying memcpy.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.13: BUG: unable to handle kernel paging request at 00000000b4343e88
> It looks like gcov exploded when running a module's constructors or > init function, but I'm unable to work out which module it was :( > >>> [...] > >>> > Maybe it's tg3. > > Could you add `ignore_loglevel' to the kernel boot parameters? That > should make all pr_debug()s come out and they include the module's > name. > >> > >> I'm not sure if this related, but all 3 kernel logs consistently contain > >> this error message: > >> > >>> [0.617401] gcov: could not create file > >> > >> which should only be shown in case of severe out-of-memory situations or > >> duplicate object file names. > >> > >> Could you retry with the following patch applied (2 times if possible) > >> and send dmesg output? > > > > This seems to be relevant - now there is a reproducible crash during the > > printk. Captured end of the backtrace from HP ILO as image, attached. > > This is reproducible. > > Ok, that's a lead. It appears that gcov-kernel receives gcov_info > structures in an unexpected format. Based on your previous dmesg output, > your kernel was compiled using gcc 4.7.2 which gcov-kernel should be able > to handle just fine. Could you please try out this debugging patch > (replacing the previous one)? Output will likely be quite verbose, so you > might consider using log_buf_len=1M or similar as kernel parameter. I do not get very far - it still crashes on startuo. PNG attached. -- Meelis Roos (mr...@linux.ee)<>
[Patch v3 1/2] dmaengine: add Qualcomm BAM dma driver
Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
found in the MSM 8x74 platforms.
Each BAM DMA device is associated with a specific on-chip peripheral. Each
channel provides a uni-directional data transfer engine that is capable of
transferring data between the peripheral and system memory (System mode), or
between two peripherals (BAM2BAM).
The initial release of this driver only supports slave transfers between
peripherals and system memory.
Signed-off-by: Andy Gross
---
drivers/dma/Kconfig|9 +
drivers/dma/Makefile |1 +
drivers/dma/qcom_bam_dma.c | 1083
3 files changed, 1093 insertions(+)
create mode 100644 drivers/dma/qcom_bam_dma.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index c10eb89..1b2f6cf 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -386,4 +386,13 @@ config DMATEST
config DMA_ENGINE_RAID
bool
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_MSM_DT || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 0ce2da9..7ef950a 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
obj-$(CONFIG_TI_CPPI41) += cppi41.o
obj-$(CONFIG_K3_DMA) += k3dma.o
+obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
new file mode 100644
index 000..3574d2a
--- /dev/null
+++ b/drivers/dma/qcom_bam_dma.c
@@ -0,0 +1,1083 @@
+/*
+ * QCOM BAM DMA engine driver
+ *
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * QCOM BAM DMA blocks are distributed amongst a number of the on-chip
+ * peripherals on the MSM 8x74. The configuration of the channels are
dependent
+ * on the way they are hard wired to that specific peripheral. The peripheral
+ * device tree entries specify the configuration of each channel.
+ *
+ * The DMA controller requires the use of external memory for storage of the
+ * hardware descriptors for each channel. The descriptor FIFO is accessed as a
+ * circular buffer and operations are managed according to the offset within
the
+ * FIFO. After pipe/channel reset, all of the pipe registers and internal
state
+ * are back to defaults.
+ *
+ * During DMA operations, we write descriptors to the FIFO, being careful to
+ * handle wrapping and then write the last FIFO offset to that channel's
+ * P_EVNT_REG register to kick off the transaction. The P_SW_OFSTS register
+ * indicates the current FIFO offset that is being processed, so there is some
+ * indication of where the hardware is currently working.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+enum bam_channel_dir {
+ BAM_PIPE_CONSUMER = 0, /* channel reads from data-fifo or memory */
+ BAM_PIPE_PRODUCER, /* channel writes to data-fifo or memory */
+};
+
+struct bam_desc_hw {
+ u32 addr; /* Buffer physical address */
+ u16 size; /* Buffer size in bytes */
+ u16 flags;
+};
+
+#define DESC_FLAG_INT BIT(15)
+#define DESC_FLAG_EOT BIT(14)
+#define DESC_FLAG_EOB BIT(13)
+
+struct bam_async_desc {
+ struct virt_dma_desc vd;
+
+ u32 num_desc;
+ u32 xfer_len;
+ struct bam_desc_hw *curr_desc;
+
+ enum bam_channel_dir dir;
+ size_t length;
+ struct bam_desc_hw desc[0];
+};
+
+#define BAM_CTRL 0x
+#define BAM_REVISION 0x0004
+#define BAM_SW_REVISION0x0080
+#define BAM_NUM_PIPES 0x003C
+#define BAM_TIMER 0x0040
+#define BAM_TIMER_CTRL 0x0044
+#define BAM_DESC_CNT_TRSHLD0x0008
+#define BAM_IRQ_SRCS 0x000C
+#define BAM_IRQ_SRCS_MSK 0x0010
+#define BAM_IRQ_SRCS_UNMASKED 0x0030
+#define BAM_IRQ_STTS 0x0014
+#define BAM_IRQ_CLR0x0018
+#define BAM_IRQ_EN
fyi
-- My name is Lewis,Sequel to your non response to my previous email, I am re-sending this to you again thus; A deceased client of mine, that shares the same last name as yours,left behind some certain funds which I would like you to help distribute. Regards, Lewis Baach -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Add device tree binding support for the QCOM BAM DMA driver.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/dma/qcom_bam_dma.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
new file mode 100644
index 000..53fd10a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -0,0 +1,52 @@
+QCOM BAM DMA controller
+
+Required properties:
+- compatible: Must be "qcom,bam-v1.4.0" for MSM8974 V1
+ Must be "qcom,bam-v1.4.1" for MSM8974 V2
+- reg: Address range for DMA registers
+- interrupts: single interrupt for this controller
+- #dma-cells: must be <2>
+- clocks: required clock
+- clock-names: name of clock
+- qcom,ee : indicates the active Execution Environment identifier (0-7)
+
+Example:
+
+ uart-bam: dma@f9984000 = {
+ compatible = "qcom,bam-v1.4.1";
+ reg = <0xf9984000 0x15000>;
+ interrupts = <0 94 0>;
+ clocks = <&gcc GCC_BAM_DMA_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <2>;
+ qcom,ee = <0>;
+ };
+
+Client:
+Required properties:
+- dmas: List of dma channel requests
+- dma-names: Names of aforementioned requested channels
+
+Clients must use the format described in the dma.txt file, using a three cell
+specifier for each channel.
+
+The three cells in order are:
+ 1. A phandle pointing to the DMA controller
+ 2. The channel number
+ 3. Direction of the fixed unidirectional channel
+ 0 - Memory to Device
+ 1 - Device to Memory
+ 2 - Device to Device
+
+Example:
+ serial@f991e000 {
+ compatible = "qcom,msm-uart";
+ reg = <0xf991e000 0x1000>
+ <0xf9944000 0x19000>;
+ interrupts = <0 108 0>;
+ clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, <&gcc
GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+
+ dmas = <&uart-bam 0 1>, <&uart-bam 1 0>;
+ dma-names = "rx", "tx";
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/kaslr for v3.14
* Kees Cook wrote: > On Mon, Jan 27, 2014 at 9:20 AM, Richard Weinberger wrote: > > Am 27.01.2014 18:05, schrieb Kees Cook: > >> I would argue that decoding a non-panic oops on a running system is > >> entirely possible as-is, since the offset can be found from > >> /proc/kallsyms as root. It was the dead system that needed the offset > >> exported: via text in the panic, or via an ELF note in a core. > > > > The problem is that you have to pickup information from two sources. > > As a kernel developer users/customers often show you a backtrace (oops or > > panic) > > and want you do find the problem. > > They barley manage it copy&paste the topmost full trace from dmesg or > > /var/log/messages. > > If I have to ask them a bit later to tell me the offset from /proc/kallsyms > > or something else > > I'm lost. Mostly because they have already rebooted the box... > > As long as I can turn it off, I'd be happy. :) > /proc/sys/kernel/kaslr_in_oops or something? Yeah, as long as it decodes by default. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v3 0/2] Add Qualcomm BAM dmaengine driver
This patch set introduces the dmaengine driver for the Qualcomm Bus Access Manager (BAM) DMA controller present on MSM 8x74 devices. A number of the on-chip devices have their own BAM DMA controller and use it to move data between system memory and peripherals or between two peripherals. The initial version of this driver will only support slave DMA operations between system memory and peripherals. Changes from v2: - Corrected Kconfig dependencies - Moved execution environment ID to controller DT binding. The EE is a global setting across all of the channels on the controller. - Combined header into source file. - Corrected copyright date. - Moved channel hardware initialization to occur when channel is used for the first time. - Converted dma_alloc_coherent to dma_alloc_writecombine - Removed unecessary reset of channel from the dma terminate_all - Corrected usage of EE in irq handler and channel configuration functions. - Changed resource functions inside probe to use correct APIs. - Removed dma filter function and modified dma_xlate to use dma_get_slave_channel API - Fixed various nit comments Changes from v1: - Converted driver to use virt-dma - Reworked probe function per review comments - tx_status function now computes and returns residuals - Removed proprietary slave config. Removed associated include file. - Renamed files to reflect vendor name instead of specific device - Converted to use (readl|writel)_relaxed w/ appropriate barriers - Removed unions in favor of standard types. Andy Gross (2): dmaengine: add Qualcomm BAM dma driver dmaengine: qcom_bam_dma: Add device tree binding .../devicetree/bindings/dma/qcom_bam_dma.txt | 52 + drivers/dma/Kconfig|9 + drivers/dma/Makefile |1 + drivers/dma/qcom_bam_dma.c | 1083 4 files changed, 1145 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt create mode 100644 drivers/dma/qcom_bam_dma.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Input: i8042-io - Exclude mips platforms when allocating/deallocating IO regions.
Hi Aaro,
>
> On Sun, Jan 26, 2014 at 10:56:38PM -0800, Dmitry Torokhov wrote:
> > On Mon, Jan 27, 2014 at 12:32:36AM +, Raghu Gandham wrote:
> > > > On Sat, Jan 25, 2014 at 11:01:54AM -0800, Raghu Gandham wrote:
> > > > > The standard IO regions are already reserved by the platform
> > > > > code on most MIPS devices(malta, cobalt, sni). The Commit
> > > > > 197a1e96c8be5b6005145af3a4c0e45e2d651444
> > > > > ("Input: i8042-io - fix up region handling on MIPS") introduced
> > > > > a bug on these MIPS platforms causing i8042 driver to fail when
> > > > > trying to reserve IO ports.
> > > > > Prior to the above mentioned commit request_region is skipped on
> > > > > MIPS but release_region is called.
> > > > >
> > > > > This patch reverts commit
> > > > > 197a1e96c8be5b6005145af3a4c0e45e2d651444
> > > > > and also avoids calling release_region for MIPS.
> > > >
> > > > The problem is that IO regions are reserved on _most_, but not
> > > > _all_ devices.
> > > > MIPS should figure out what they want to do with i8042 registers
> > > > and be consistent on all devices.
> > >
> > > Please examine the attached patch which went upstream in April of 2004.
> > > Since then it had been a convention not to call request_region
> > > routine in
> > > i8042 for MIPS. The attached patch had a glitch that it guarded
> > > request_region in i8042-io.h but skipped guarding release_region in
> > > i8042-io.h. I believe that the issue Aaro saw was due to this
> > > glitch. Below is the error quoted in Aaro's commit message.
> > >
> > > [2.112000] Trying to free nonexistent resource <0060-
> 006f>
> > >
> > > My patch reinstates the convention followed on MIPS devices along
> > > with fixing Aaro's issue.
> >
> > I assume that Aaro did test his patch and on his box request_region()
> > succeeds. That would indicate that various MIPS sub-arches still not
> > settled on the topic.
>
> request_region() succeeds on Loongson and OCTEON.
This would mean that before your patch in oct of 2012, Loongson and Octeon
were not reserving the IO space for i8042.
>
> On OCTEONs without PCI, request_region() will fail which is correct as there
> is no I/O space.
>
> I wasn't aware of that 2004 patch (it pre-dates GIT history of mainline
> Linux).
> Why the regions are already reserved by the platform code?
The only information I have is the comment before request_region in i8042-io.h
that
touching data register on some platforms is flaky. If your patch was primarily
aimed at
addressing the error message from release_region, the current patch I uploaded
should
also take care of it too.
Thanks,
Raghu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation/development-process: update release history to 3.x
Just update release history examples from 2.6.x to 3.x Signed-off-by: SeongJae Park --- Documentation/development-process/2.Process | 74 ++--- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 2e06179..5e85037 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -14,16 +14,16 @@ The kernel developers use a loosely time-based release process, with a new major kernel release happening every two or three months. The recent release history looks like this: - 2.6.38 March 14, 2011 - 2.6.37 January 4, 2011 - 2.6.36 October 20, 2010 - 2.6.35 August 1, 2010 - 2.6.34 May 15, 2010 - 2.6.33 February 24, 2010 - -Every 2.6.x release is a major kernel release with new features, internal -API changes, and more. A typical 2.6 release can contain nearly 10,000 -changesets with changes to several hundred thousand lines of code. 2.6 is + 3.13January 20, 2014 + 3.12November 4, 2013 + 3.11September 2, 2013 + 3.10July 1, 2013 + 3.9 April 29, 2013 + 3.8 February 19, 2013 + +Every 3.x release is a major kernel release with new features, internal +API changes, and more. A typical 3.x release can contain nearly 10,000 +changesets with changes to several hundred thousand lines of code. 3.x is thus the leading edge of Linux kernel development; the kernel uses a rolling development model which is continually integrating major changes. @@ -43,9 +43,9 @@ detail later on). The merge window lasts for approximately two weeks. At the end of this time, Linus Torvalds will declare that the window is closed and release the -first of the "rc" kernels. For the kernel which is destined to be 2.6.40, +first of the "rc" kernels. For the kernel which is destined to be 3.14, for example, the release which happens at the end of the merge window will -be called 2.6.40-rc1. The -rc1 release is the signal that the time to +be called 3.14-rc1. The -rc1 release is the signal that the time to merge new features has passed, and that the time to stabilize the next kernel has begun. @@ -62,22 +62,21 @@ add at any time). As fixes make their way into the mainline, the patch rate will slow over time. Linus releases new -rc kernels about once a week; a normal series will get up to somewhere between -rc6 and -rc9 before the kernel is -considered to be sufficiently stable and the final 2.6.x release is made. +considered to be sufficiently stable and the final 3.x release is made. At that point the whole process starts over again. -As an example, here is how the 2.6.38 development cycle went (all dates in -2011): +As an example, here is how the 3.13 development cycle went: - January 4 2.6.37 stable release - January 18 2.6.38-rc1, merge window closes - January 21 2.6.38-rc2 - February 1 2.6.38-rc3 - February 7 2.6.38-rc4 - February 15 2.6.38-rc5 - February 21 2.6.38-rc6 - March 1 2.6.38-rc7 - March 7 2.6.38-rc8 - March 142.6.38 stable release + November 4, 20133.12 stable release + November 22, 2013 3.13-rc1, merge window closes + November 29, 2013 3.13-rc2 + December 6, 20133.13-rc3 + December 15, 2013 3.13-rc4 + December 22, 2013 3.13-rc5 + December 30, 2013 3.13-rc6 + January 5, 2014 3.13-rc7 + January 12, 20143.13-rc8 + January 20, 20143.13 stable release How do the developers decide when to close the development cycle and create the stable release? The most significant metric used is the list of @@ -92,34 +91,35 @@ release is made. In the real world, this kind of perfection is hard to achieve; there are just too many variables in a project of this size. There comes a point where delaying the final release just makes the problem worse; the pile of changes waiting for the next merge window will grow -larger, creating even more regressions the next time around. So most 2.6.x +larger, creating even more regressions the next time around. So most 3.x kernels go out with a handful of known regressions though, hopefully, none of them are serious. Once a stable release is made, its ongoing maintenance is passed off to the "stable team," currently consisting of Greg Kroah-Hartman. The stable team -will release occasional updates to the stable release using the 2.6.x.y +will release occasional updates to the stable release using the 3.x.y numbering scheme. To be considered for an update release, a patch must (1) fix a significant bug, and (2) already be merged into the mainline for the next development kernel. Kernels will typically receive stable updates for a little more tha
[PATCH v5 1/3] mm: Create utility function for accessing a tasks commandline value
introduce get_cmdline() for retreiving the value of a processes
proc/self/cmdline value.
Acked-by: David Rientjes
Acked-by: Stephen Smalley
Signed-off-by: William Roberts
---
include/linux/mm.h |1 +
mm/util.c | 48
2 files changed, 49 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f28f46e..db89a94 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1175,6 +1175,7 @@ void account_page_writeback(struct page *page);
int set_page_dirty(struct page *page);
int set_page_dirty_lock(struct page *page);
int clear_page_dirty_for_io(struct page *page);
+int get_cmdline(struct task_struct *task, char *buffer, int buflen);
/* Is the vma a continuation of the stack vma above it? */
static inline int vma_growsdown(struct vm_area_struct *vma, unsigned long addr)
diff --git a/mm/util.c b/mm/util.c
index a24aa22..8122710 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -445,6 +445,54 @@ unsigned long vm_commit_limit(void)
return allowed;
}
+/**
+ * get_cmdline() - copy the cmdline value to a buffer.
+ * @task: the task whose cmdline value to copy.
+ * @buffer: the buffer to copy to.
+ * @buflen: the length of the buffer. Larger cmdline values are truncated
+ *to this length.
+ * Returns the size of the cmdline field copied. Note that the copy does
+ * not guarantee an ending NULL byte.
+ */
+int get_cmdline(struct task_struct *task, char *buffer, int buflen)
+{
+ int res = 0;
+ unsigned int len;
+ struct mm_struct *mm = get_task_mm(task);
+ if (!mm)
+ goto out;
+ if (!mm->arg_end)
+ goto out_mm;/* Shh! No looking before we're done */
+
+ len = mm->arg_end - mm->arg_start;
+
+ if (len > buflen)
+ len = buflen;
+
+ res = access_process_vm(task, mm->arg_start, buffer, len, 0);
+
+ /*
+* If the nul at the end of args has been overwritten, then
+* assume application is using setproctitle(3).
+*/
+ if (res > 0 && buffer[res-1] != '\0' && len < buflen) {
+ len = strnlen(buffer, res);
+ if (len < res) {
+ res = len;
+ } else {
+ len = mm->env_end - mm->env_start;
+ if (len > buflen - res)
+ len = buflen - res;
+ res += access_process_vm(task, mm->env_start,
+buffer+res, len, 0);
+ res = strnlen(buffer, res);
+ }
+ }
+out_mm:
+ mmput(mm);
+out:
+ return res;
+}
/* Tracepoints definitions. */
EXPORT_TRACEPOINT_SYMBOL(kmalloc);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/3] audit: Audit proc cmdline value
During an audit event, cache and print the value of the process's
cmdline value (proc//cmdline). This is useful in situations
where processes are started via fork'd virtual machines where the
comm field is incorrect. Often times, setting the comm field still
is insufficient as the comm width is not very wide and most
virtual machine "package names" do not fit. Also, during execution,
many threads have their comm field set as well. By tying it back to
the global cmdline value for the process, audit records will be more
complete in systems with these properties. An example of where this
is useful and applicable is in the realm of Android. With Android,
their is no fork/exec for VM instances. The bare, preloaded Dalvik
VM listens for a fork and specialize request. When this request comes
in, the VM forks, and the loads the specific application (specializing).
This was done to take advantage of COW and to not require a load of
basic packages by the VM on very app spawn. When this spawn occurs,
the package name is set via setproctitle() and shows up in procfs.
Many of these package names are longer then 16 bytes, the historical
width of task->comm. Having the cmdline in the audit records will
couple the application back to the record directly. Also, on my
Debian development box, some audit records were more useful then
what was printed under comm.
The cached cmdline is tied to the life-cycle of the audit_context
structure and is built on demand.
Example denial prior to patch (Ubuntu):
CALL msg=audit(1387828084.070:361): arch=c03e syscall=82 success=yes exit=0
a0=4184bf a1=418547 a2=0 a3=0 items=0 ppid=1 pid=1329 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none)
comm="console-kit-dae" exe="/usr/sbin/console-kit-daemon"
subj=system_u:system_r:consolekit_t:s0-s0:c0.c255 key=(null)
After Patches (Ubuntu):
type=SYSCALL msg=audit(1387828084.070:361): arch=c03e syscall=82
success=yes exit=0 a0=4184bf a1=418547 a2=0 a3=0 items=0 ppid=1 pid=1329
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
ses=4294967295 tty=(none) comm="console-kit-dae"
exe="/usr/sbin/console-kit-daemon"
subj=system_u:system_r:consolekit_t:s0-s0:c0.c255
cmdline="/usr/lib/dbus-1.0/dbus-daemon-launch-helper" key=(null)
Example denial prior to patch (Android):
type=1300 msg=audit(248323.940:247): arch=4028 syscall=54 per=84
success=yes exit=0 a0=39 a1=540b a2=2 a3=750eecec items=0 ppid=224 pid=1858
auid=4294967295 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002
sgid=1002 fsgid=1002 tty=(none) ses=4294967295 comm="bt_hc_worker"
exe="/system/bin/app_process" subj=u:r:bluetooth:s0 key=(null)
After Patches (Android):
type=1300 msg=audit(248323.940:247): arch=4028 syscall=54 per=84
success=yes exit=0 a0=39 a1=540b a2=2 a3=750eecec items=0 ppid=224 pid=1858
auid=4294967295 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002
sgid=1002 fsgid=1002 tty=(none) ses=4294967295 comm="bt_hc_worker"
exe="/system/bin/app_process" cmdline="com.android.bluetooth"
subj=u:r:bluetooth:s0 key=(null)
Signed-off-by: William Roberts
---
kernel/audit.h |6 ++
kernel/auditsc.c | 51 +++
2 files changed, 57 insertions(+)
diff --git a/kernel/audit.h b/kernel/audit.h
index 57cc64d..aae1b21 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -106,6 +106,11 @@ struct audit_names {
boolshould_free;
};
+struct audit_cmdline {
+ int len;/* length of the cmdline field. */
+ char*value; /* the cmdline field */
+};
+
/* The per-task audit context. */
struct audit_context {
int dummy; /* must be the first element */
@@ -202,6 +207,7 @@ struct audit_context {
} execve;
};
int fds[2];
+ struct audit_cmdline cmdline;
#if AUDIT_DEBUG
int put_count;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 10176cd..2a5d2ef 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -79,6 +79,9 @@
/* no execve audit message should be longer than this (userspace limits) */
#define MAX_EXECVE_AUDIT_LEN 7500
+/* max length to print of cmdline value during audit */
+#define MAX_CMDLINE_AUDIT_LEN 128
+
/* number of audit rules */
int audit_n_rules;
@@ -842,6 +845,13 @@ static inline struct audit_context
*audit_get_context(struct task_struct *tsk,
return context;
}
+static inline void audit_cmdline_free(struct audit_context *context)
+{
+ kfree(context->cmdline.value);
+ context->cmdline.value = NULL;
+ context->cmdline.len = 0;
+}
+
static inline void audit_free_names(struct audit_context *context)
{
struct audit_names *n, *next;
@@ -955,6 +965,7 @@ static inline void audit_free_context(struct audit_context
*context)
audit_free_aux(context);
kfree(context->filterkey);
kfree(context->sockaddr
[PATCH v5 2/3] proc: Update get proc_pid_cmdline() to use mm.h helpers
Re-factor proc_pid_cmdline() to use get_cmdline() helper
from mm.h.
Acked-by: David Rientjes
Acked-by: Stephen Smalley
Signed-off-by: William Roberts
---
fs/proc/base.c | 36 ++--
1 file changed, 2 insertions(+), 34 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 5150706..f0c5927 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -200,41 +200,9 @@ static int proc_root_link(struct dentry *dentry, struct
path *path)
return result;
}
-static int proc_pid_cmdline(struct task_struct *task, char * buffer)
+static int proc_pid_cmdline(struct task_struct *task, char *buffer)
{
- int res = 0;
- unsigned int len;
- struct mm_struct *mm = get_task_mm(task);
- if (!mm)
- goto out;
- if (!mm->arg_end)
- goto out_mm;/* Shh! No looking before we're done */
-
- len = mm->arg_end - mm->arg_start;
-
- if (len > PAGE_SIZE)
- len = PAGE_SIZE;
-
- res = access_process_vm(task, mm->arg_start, buffer, len, 0);
-
- // If the nul at the end of args has been overwritten, then
- // assume application is using setproctitle(3).
- if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
- len = strnlen(buffer, res);
- if (len < res) {
- res = len;
- } else {
- len = mm->env_end - mm->env_start;
- if (len > PAGE_SIZE - res)
- len = PAGE_SIZE - res;
- res += access_process_vm(task, mm->env_start,
buffer+res, len, 0);
- res = strnlen(buffer, res);
- }
- }
-out_mm:
- mmput(mm);
-out:
- return res;
+ return get_cmdline(task, buffer, PAGE_SIZE);
}
static int proc_pid_auxv(struct task_struct *task, char *buffer)
--
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: fanotify use after free.
On Tue, Jan 28, 2014 at 12:40:17AM +0100, Jan Kara wrote: > On Fri 24-01-14 08:26:45, Jiri Kosina wrote: > > On Fri, 24 Jan 2014, Jan Kara wrote: > > > > > Strange. I've installed systemd system (openSUSE 13.1) and it boots > > > with the latest Linus' kernel just fine (and I have at least FANOTIFY > > > and SLAB debugging set the same way as you). But it was only a KVM > > > guest. I'll try tomorrow with a physical machine I guess. > > > > FWIW the system I am reliably able to reproduce this on is opensuse 12.3 > > with this systemd version: > > > > Version : 195 > > Release : 13.18.1 > Hum, still no luck with reproduction (either on physical machine or with > KVM). Anyway, I've looked at the code again and the previous patch had a > stupid bug (passing different pointer to fsnotify_destroy_event() than we > should have), plus also the merging function in fanotify was too > aggressive. Can you try the attached patch? It boots for me but that means > nothing since I cannot reproduce the issue... Thanks! still not good I'm afraid. I still see corruption very early on in boot and now it panics and locks up too. Again, this happens so early that I can't grab it over usb-serial. I stuck an mdelay(1) in the slub corruption detector, and managed to grab a photo of the first trace. Trace: ? preempt_schedule lock_acquire ? lockref_put_or_lock _raw_spin_lock ? lockref_put_or_lock dput path_put fanotify_free_event fsnotify_destroy_event fanotify_handle_event ? mntput ? path_openat ? handle_mm_fault send_to_group ? fsnotify fsnotify do_sys_open sys_open RIP: lock_acquire 2b:* 4d 8b 64 c6 08 mov0x8(%r14,%rax,8),%r12 <-- trapping instruction R14 is 0x6b6b6b6b6b6b6c03, which looks like a use-after-free. I also notice you mention SLAB above, but I've been using SLUB. I don't know if the choice of allocator makes a difference in reproducability. It's also worth noting that I have lockdep enabled, which may be perturbing things to some degree. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/22] Rewrite XIP code and add XIP support to ext4
On Thu, Jan 23, 2014 at 12:12:43PM +, Wilcox, Matthew R wrote: > Are you hitting the same problems with ext4 fsck that we did? Version 1.42.8 > reports spurious corruption. From the 1.42.9 changelog: > > * Fixed a regression introduced in 1.42.8 which would cause e2fsck to > erroneously report uninitialized extents past i_size to be invalid. Don't think so - I'm running 1.42.9 on my test VM. 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 v4 1/3] mm: Create utility function for accessing a tasks commandline value
introduce get_cmdline() for retreiving the value of a processes
proc/self/cmdline value.
Signed-off-by: William Roberts
---
include/linux/mm.h |1 +
mm/util.c | 48
2 files changed, 49 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f28f46e..db89a94 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1175,6 +1175,7 @@ void account_page_writeback(struct page *page);
int set_page_dirty(struct page *page);
int set_page_dirty_lock(struct page *page);
int clear_page_dirty_for_io(struct page *page);
+int get_cmdline(struct task_struct *task, char *buffer, int buflen);
/* Is the vma a continuation of the stack vma above it? */
static inline int vma_growsdown(struct vm_area_struct *vma, unsigned long addr)
diff --git a/mm/util.c b/mm/util.c
index a24aa22..8122710 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -445,6 +445,54 @@ unsigned long vm_commit_limit(void)
return allowed;
}
+/**
+ * get_cmdline() - copy the cmdline value to a buffer.
+ * @task: the task whose cmdline value to copy.
+ * @buffer: the buffer to copy to.
+ * @buflen: the length of the buffer. Larger cmdline values are truncated
+ *to this length.
+ * Returns the size of the cmdline field copied. Note that the copy does
+ * not guarantee an ending NULL byte.
+ */
+int get_cmdline(struct task_struct *task, char *buffer, int buflen)
+{
+ int res = 0;
+ unsigned int len;
+ struct mm_struct *mm = get_task_mm(task);
+ if (!mm)
+ goto out;
+ if (!mm->arg_end)
+ goto out_mm;/* Shh! No looking before we're done */
+
+ len = mm->arg_end - mm->arg_start;
+
+ if (len > buflen)
+ len = buflen;
+
+ res = access_process_vm(task, mm->arg_start, buffer, len, 0);
+
+ /*
+* If the nul at the end of args has been overwritten, then
+* assume application is using setproctitle(3).
+*/
+ if (res > 0 && buffer[res-1] != '\0' && len < buflen) {
+ len = strnlen(buffer, res);
+ if (len < res) {
+ res = len;
+ } else {
+ len = mm->env_end - mm->env_start;
+ if (len > buflen - res)
+ len = buflen - res;
+ res += access_process_vm(task, mm->env_start,
+buffer+res, len, 0);
+ res = strnlen(buffer, res);
+ }
+ }
+out_mm:
+ mmput(mm);
+out:
+ return res;
+}
/* Tracepoints definitions. */
EXPORT_TRACEPOINT_SYMBOL(kmalloc);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] proc: Update get proc_pid_cmdline() to use mm.h helpers
Re-factor proc_pid_cmdline() to use get_cmdline() helper
from mm.h.
Signed-off-by: William Roberts
---
fs/proc/base.c | 36 ++--
1 file changed, 2 insertions(+), 34 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 5150706..f0c5927 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -200,41 +200,9 @@ static int proc_root_link(struct dentry *dentry, struct
path *path)
return result;
}
-static int proc_pid_cmdline(struct task_struct *task, char * buffer)
+static int proc_pid_cmdline(struct task_struct *task, char *buffer)
{
- int res = 0;
- unsigned int len;
- struct mm_struct *mm = get_task_mm(task);
- if (!mm)
- goto out;
- if (!mm->arg_end)
- goto out_mm;/* Shh! No looking before we're done */
-
- len = mm->arg_end - mm->arg_start;
-
- if (len > PAGE_SIZE)
- len = PAGE_SIZE;
-
- res = access_process_vm(task, mm->arg_start, buffer, len, 0);
-
- // If the nul at the end of args has been overwritten, then
- // assume application is using setproctitle(3).
- if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
- len = strnlen(buffer, res);
- if (len < res) {
- res = len;
- } else {
- len = mm->env_end - mm->env_start;
- if (len > PAGE_SIZE - res)
- len = PAGE_SIZE - res;
- res += access_process_vm(task, mm->env_start,
buffer+res, len, 0);
- res = strnlen(buffer, res);
- }
- }
-out_mm:
- mmput(mm);
-out:
- return res;
+ return get_cmdline(task, buffer, PAGE_SIZE);
}
static int proc_pid_auxv(struct task_struct *task, char *buffer)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] audit: Audit proc cmdline value
During an audit event, cache and print the value of the process's
cmdline value (proc//cmdline). This is useful in situations
where processes are started via fork'd virtual machines where the
comm field is incorrect. Often times, setting the comm field still
is insufficient as the comm width is not very wide and most
virtual machine "package names" do not fit. Also, during execution,
many threads have their comm field set as well. By tying it back to
the global cmdline value for the process, audit records will be more
complete in systems with these properties. An example of where this
is useful and applicable is in the realm of Android. With Android,
their is no fork/exec for VM instances. The bare, preloaded Dalvik
VM listens for a fork and specialize request. When this request comes
in, the VM forks, and the loads the specific application (specializing).
This was done to take advantage of COW and to not require a load of
basic packages by the VM on very app spawn. When this spawn occurs,
the package name is set via setproctitle() and shows up in procfs.
Many of these package names are longer then 16 bytes, the historical
width of task->comm. Having the cmdline in the audit records will
couple the application back to the record directly. Also, on my
Debian development box, some audit records were more useful then
what was printed under comm.
The cached cmdline is tied to the life-cycle of the audit_context
structure and is built on demand.
Example denial prior to patch (Ubuntu):
CALL msg=audit(1387828084.070:361): arch=c03e syscall=82 success=yes exit=0
a0=4184bf a1=418547 a2=0 a3=0 items=0 ppid=1 pid=1329 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none)
comm="console-kit-dae" exe="/usr/sbin/console-kit-daemon"
subj=system_u:system_r:consolekit_t:s0-s0:c0.c255 key=(null)
After Patches (Ubuntu):
type=SYSCALL msg=audit(1387828084.070:361): arch=c03e syscall=82
success=yes exit=0 a0=4184bf a1=418547 a2=0 a3=0 items=0 ppid=1 pid=1329
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
ses=4294967295 tty=(none) comm="console-kit-dae"
exe="/usr/sbin/console-kit-daemon"
subj=system_u:system_r:consolekit_t:s0-s0:c0.c255
cmdline="/usr/lib/dbus-1.0/dbus-daemon-launch-helper" key=(null)
Example denial prior to patch (Android):
type=1300 msg=audit(248323.940:247): arch=4028 syscall=54 per=84
success=yes exit=0 a0=39 a1=540b a2=2 a3=750eecec items=0 ppid=224 pid=1858
auid=4294967295 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002
sgid=1002 fsgid=1002 tty=(none) ses=4294967295 comm="bt_hc_worker"
exe="/system/bin/app_process" subj=u:r:bluetooth:s0 key=(null)
After Patches (Android):
type=1300 msg=audit(248323.940:247): arch=4028 syscall=54 per=84
success=yes exit=0 a0=39 a1=540b a2=2 a3=750eecec items=0 ppid=224 pid=1858
auid=4294967295 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002
sgid=1002 fsgid=1002 tty=(none) ses=4294967295 comm="bt_hc_worker"
exe="/system/bin/app_process" cmdline="com.android.bluetooth"
subj=u:r:bluetooth:s0 key=(null)
Signed-off-by: William Roberts
---
kernel/audit.h |6 ++
kernel/auditsc.c | 51 +++
2 files changed, 57 insertions(+)
diff --git a/kernel/audit.h b/kernel/audit.h
index 57cc64d..aae1b21 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -106,6 +106,11 @@ struct audit_names {
boolshould_free;
};
+struct audit_cmdline {
+ int len;/* length of the cmdline field. */
+ char*value; /* the cmdline field */
+};
+
/* The per-task audit context. */
struct audit_context {
int dummy; /* must be the first element */
@@ -202,6 +207,7 @@ struct audit_context {
} execve;
};
int fds[2];
+ struct audit_cmdline cmdline;
#if AUDIT_DEBUG
int put_count;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 10176cd..2a5d2ef 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -79,6 +79,9 @@
/* no execve audit message should be longer than this (userspace limits) */
#define MAX_EXECVE_AUDIT_LEN 7500
+/* max length to print of cmdline value during audit */
+#define MAX_CMDLINE_AUDIT_LEN 128
+
/* number of audit rules */
int audit_n_rules;
@@ -842,6 +845,13 @@ static inline struct audit_context
*audit_get_context(struct task_struct *tsk,
return context;
}
+static inline void audit_cmdline_free(struct audit_context *context)
+{
+ kfree(context->cmdline.value);
+ context->cmdline.value = NULL;
+ context->cmdline.len = 0;
+}
+
static inline void audit_free_names(struct audit_context *context)
{
struct audit_names *n, *next;
@@ -955,6 +965,7 @@ static inline void audit_free_context(struct audit_context
*context)
audit_free_aux(context);
kfree(context->filterkey);
kfree(context->sockaddr
Re: [f2fs-dev] [PATCH] f2fs: use inode mutex to keep atomicity of f2fs_falloc
Hi, 2014-01-28 (화), 10:29 +0800, Chao Yu: > Previously without protection of inode mutex, f2fs_falloc and other data > correlated operations will interfere with each other. Could you explain a little bit more what kind of scenarios wrt this? > So let's use inode mutex to keep atomicity of f2fs_falloc. > > Signed-off-by: Chao Yu > --- > fs/f2fs/file.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index 85e91ca..ece380f 100644 > --- a/fs/f2fs/file.c > +++ b/fs/f2fs/file.c > @@ -559,6 +559,8 @@ static long f2fs_fallocate(struct file *file, int mode, > if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) > return -EOPNOTSUPP; > > + mutex_lock(&inode->i_mutex); > + > if (mode & FALLOC_FL_PUNCH_HOLE) > ret = punch_hole(inode, offset, len); > else > @@ -568,6 +570,9 @@ static long f2fs_fallocate(struct file *file, int mode, > inode->i_mtime = inode->i_ctime = CURRENT_TIME; > mark_inode_dirty(inode); > } > + > + mutex_unlock(&inode->i_mutex); > + > trace_f2fs_fallocate(inode, mode, offset, len, ret); > return ret; > } -- Jaegeuk Kim Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] f2fs: update_inode_page should be done all the time
In order to make fs consistency, update_inode_page should not be failed all
the time. Otherwise, it is possible to lose some metadata in the inode like
a link count.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 3 +--
fs/f2fs/f2fs.h | 8 +++-
fs/f2fs/inode.c | 20
3 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0ae5587..6827359 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -62,8 +62,7 @@ static void f2fs_write_end_io(struct bio *bio, int err)
if (unlikely(!uptodate)) {
SetPageError(page);
set_bit(AS_EIO, &page->mapping->flags);
- set_ckpt_flags(sbi->ckpt, CP_ERROR_FLAG);
- sbi->sb->s_flags |= MS_RDONLY;
+ f2fs_stop_checkpoint(sbi);
}
end_page_writeback(page);
dec_page_count(sbi, F2FS_WRITEBACK);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index af51a0b..42903c3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1023,6 +1023,12 @@ static inline int f2fs_readonly(struct super_block *sb)
return sb->s_flags & MS_RDONLY;
}
+static inline void f2fs_stop_checkpoint(struct f2fs_sb_info *sbi)
+{
+ set_ckpt_flags(sbi->ckpt, CP_ERROR_FLAG);
+ sbi->sb->s_flags |= MS_RDONLY;
+}
+
/*
* file.c
*/
@@ -1044,7 +1050,7 @@ void f2fs_set_inode_flags(struct inode *);
struct inode *f2fs_iget(struct super_block *, unsigned long);
int try_to_free_nats(struct f2fs_sb_info *, int);
void update_inode(struct inode *, struct page *);
-int update_inode_page(struct inode *);
+void update_inode_page(struct inode *);
int f2fs_write_inode(struct inode *, struct writeback_control *);
void f2fs_evict_inode(struct inode *);
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 4d67ed7..1a4ba27 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -212,24 +212,28 @@ void update_inode(struct inode *inode, struct page
*node_page)
clear_inode_flag(F2FS_I(inode), FI_DIRTY_INODE);
}
-int update_inode_page(struct inode *inode)
+void update_inode_page(struct inode *inode)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
struct page *node_page;
-
+retry:
node_page = get_node_page(sbi, inode->i_ino);
- if (IS_ERR(node_page))
- return PTR_ERR(node_page);
+ if (IS_ERR(node_page)) {
+ if (PTR_ERR(node_page) == -ENOMEM) {
+ cond_resched();
+ goto retry;
+ } else {
+ f2fs_stop_checkpoint(sbi);
+ }
+ }
update_inode(inode, node_page);
f2fs_put_page(node_page, 1);
- return 0;
}
int f2fs_write_inode(struct inode *inode, struct writeback_control *wbc)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
- int ret;
if (inode->i_ino == F2FS_NODE_INO(sbi) ||
inode->i_ino == F2FS_META_INO(sbi))
@@ -243,13 +247,13 @@ int f2fs_write_inode(struct inode *inode, struct
writeback_control *wbc)
* during the urgent cleaning time when runing out of free sections.
*/
f2fs_lock_op(sbi);
- ret = update_inode_page(inode);
+ update_inode_page(inode);
f2fs_unlock_op(sbi);
if (wbc)
f2fs_balance_fs(sbi);
- return ret;
+ return 0;
}
/*
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] f2fs: fix to recover xattr node block
If a new xattr node page was allocated and its inode is fsynced, we should
recover the xattr node page during the roll-forward process after power-cut.
But, previously, f2fs didn't handle that case, resulting in kernel panic as
follows reported by Tom Li.
BUG: unable to handle kernel paging request at c9001c861a98
IP: [] check_index_in_prev_nodes+0x86/0x2d0 [f2fs]
Call Trace:
[] ? printk+0x48/0x4a
[] recover_fsync_data+0xdca/0xf50 [f2fs]
[] f2fs_fill_super+0x92e/0x970 [f2fs]
[] mount_bdev+0x1b8/0x200
[] ? f2fs_remount+0x130/0x130 [f2fs]
[] f2fs_mount+0x10/0x20 [f2fs]
[] mount_fs+0x3e/0x1b0
[] ? __alloc_percpu+0xb/0x10
[] vfs_kern_mount+0x6f/0x120
[] do_mount+0x259/0xa90
[] ? memdup_user+0x3d/0x80
[] ? strndup_user+0x53/0x70
[] SyS_mount+0x89/0xd0
[] system_call_fastpath+0x16/0x1b
This patch adds a recovery function of xattr node pages.
Reported-by: Tom Li
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 40
fs/f2fs/recovery.c | 3 +++
3 files changed, 44 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 6e9515d..80a64fd 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1117,6 +1117,7 @@ void alloc_nid_done(struct f2fs_sb_info *, nid_t);
void alloc_nid_failed(struct f2fs_sb_info *, nid_t);
void recover_node_page(struct f2fs_sb_info *, struct page *,
struct f2fs_summary *, struct node_info *, block_t);
+bool recover_xattr_data(struct inode *, struct page *, block_t);
int recover_inode_page(struct f2fs_sb_info *, struct page *);
int restore_node_summary(struct f2fs_sb_info *, unsigned int,
struct f2fs_summary_block *);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b0649b7..82f4753 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1535,6 +1535,46 @@ void recover_node_page(struct f2fs_sb_info *sbi, struct
page *page,
clear_node_page_dirty(page);
}
+bool recover_xattr_data(struct inode *inode, struct page *page, block_t
blkaddr)
+{
+ struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
+ nid_t prev_xnid = F2FS_I(inode)->i_xattr_nid;
+ nid_t new_xnid = nid_of_node(page);
+ struct node_info ni;
+
+ if (ofs_of_node(page) != XATTR_NODE_OFFSET)
+ return false;
+
+ /* 1: invalidate the previous xattr nid */
+ if (!prev_xnid)
+ goto recover_xnid;
+
+ /* Deallocate node address */
+ get_node_info(sbi, prev_xnid, &ni);
+ f2fs_bug_on(ni.blk_addr == NULL_ADDR);
+ invalidate_blocks(sbi, ni.blk_addr);
+ dec_valid_node_count(sbi, inode);
+ set_node_addr(sbi, &ni, NULL_ADDR);
+
+recover_xnid:
+ /* 2: allocate new xattr nid */
+ if (unlikely(!inc_valid_node_count(sbi, inode)))
+ f2fs_bug_on(1);
+
+ remove_free_nid(NM_I(sbi), new_xnid);
+ get_node_info(sbi, new_xnid, &ni);
+ ni.ino = inode->i_ino;
+ set_node_addr(sbi, &ni, NEW_ADDR);
+ F2FS_I(inode)->i_xattr_nid = new_xnid;
+
+ /* 3: update xattr blkaddr */
+ refresh_sit_entry(sbi, NEW_ADDR, blkaddr);
+ set_node_addr(sbi, &ni, blkaddr);
+
+ update_inode_page(inode);
+ return true;
+}
+
int recover_inode_page(struct f2fs_sb_info *sbi, struct page *page)
{
struct f2fs_inode *src, *dst;
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 976a7a9..f1b0b89 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -301,6 +301,9 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct
inode *inode,
if (recover_inline_data(inode, page))
goto out;
+ if (recover_xattr_data(inode, page, blkaddr))
+ goto out;
+
start = start_bidx_of_node(ofs_of_node(page), fi);
if (IS_INODE(page))
end = start + ADDRS_PER_INODE(fi);
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] f2fs: handle dirty segments inside refresh_sit_entry
This patch cleans up the refresh_sit_entry to handle locate_dirty_segments.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h| 1 +
fs/f2fs/segment.c | 19 ---
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 42903c3..6e9515d 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1132,6 +1132,7 @@ void destroy_node_manager_caches(void);
void f2fs_balance_fs(struct f2fs_sb_info *);
void f2fs_balance_fs_bg(struct f2fs_sb_info *);
void invalidate_blocks(struct f2fs_sb_info *, block_t);
+void refresh_sit_entry(struct f2fs_sb_info *, block_t, block_t);
void clear_prefree_segments(struct f2fs_sb_info *);
int npages_for_summary_flush(struct f2fs_sb_info *);
void allocate_new_segments(struct f2fs_sb_info *);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 7caac5f..89aa503 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -434,12 +434,14 @@ static void update_sit_entry(struct f2fs_sb_info *sbi,
block_t blkaddr, int del)
get_sec_entry(sbi, segno)->valid_blocks += del;
}
-static void refresh_sit_entry(struct f2fs_sb_info *sbi,
- block_t old_blkaddr, block_t new_blkaddr)
+void refresh_sit_entry(struct f2fs_sb_info *sbi, block_t old, block_t new)
{
- update_sit_entry(sbi, new_blkaddr, 1);
- if (GET_SEGNO(sbi, old_blkaddr) != NULL_SEGNO)
- update_sit_entry(sbi, old_blkaddr, -1);
+ update_sit_entry(sbi, new, 1);
+ if (GET_SEGNO(sbi, old) != NULL_SEGNO)
+ update_sit_entry(sbi, old, -1);
+
+ locate_dirty_segment(sbi, GET_SEGNO(sbi, old));
+ locate_dirty_segment(sbi, GET_SEGNO(sbi, new));
}
void invalidate_blocks(struct f2fs_sb_info *sbi, block_t addr)
@@ -886,12 +888,11 @@ void allocate_data_block(struct f2fs_sb_info *sbi, struct
page *page,
* since SSR needs latest valid block information.
*/
refresh_sit_entry(sbi, old_blkaddr, *new_blkaddr);
+ locate_dirty_segment(sbi, old_cursegno);
if (!__has_curseg_space(sbi, type))
sit_i->s_ops->allocate_segment(sbi, type, false);
- locate_dirty_segment(sbi, old_cursegno);
- locate_dirty_segment(sbi, GET_SEGNO(sbi, old_blkaddr));
mutex_unlock(&sit_i->sentry_lock);
if (page && IS_NODESEG(type))
@@ -992,9 +993,7 @@ void recover_data_page(struct f2fs_sb_info *sbi,
__add_sum_entry(sbi, type, sum);
refresh_sit_entry(sbi, old_blkaddr, new_blkaddr);
-
locate_dirty_segment(sbi, old_cursegno);
- locate_dirty_segment(sbi, GET_SEGNO(sbi, old_blkaddr));
mutex_unlock(&sit_i->sentry_lock);
mutex_unlock(&curseg->curseg_mutex);
@@ -1045,9 +1044,7 @@ void rewrite_node_page(struct f2fs_sb_info *sbi,
f2fs_submit_page_mbio(sbi, page, new_blkaddr, &fio);
f2fs_submit_merged_bio(sbi, NODE, WRITE);
refresh_sit_entry(sbi, old_blkaddr, new_blkaddr);
-
locate_dirty_segment(sbi, old_cursegno);
- locate_dirty_segment(sbi, GET_SEGNO(sbi, old_blkaddr));
mutex_unlock(&sit_i->sentry_lock);
mutex_unlock(&curseg->curseg_mutex);
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] f2fs: fix a build warning
This patch modifies flow a little bit to avoid the following build warnings.
src/fs/f2fs/recovery.c: In function ‘check_index_in_prev_nodes’:
src/fs/f2fs/recovery.c:288:51: warning: ‘sum...ofs_in_node’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
src/fs/f2fs/recovery.c:260:23: warning: ‘sum.nid’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/recovery.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index f1b0b89..cdc4bdd 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -220,11 +220,11 @@ static int check_index_in_prev_nodes(struct f2fs_sb_info
*sbi,
unsigned int segno = GET_SEGNO(sbi, blkaddr);
unsigned short blkoff = GET_SEGOFF_FROM_SEG0(sbi, blkaddr) &
(sbi->blocks_per_seg - 1);
+ struct f2fs_summary_block *sum_node;
struct f2fs_summary sum;
+ struct page *sum_page, *node_page;
nid_t ino, nid;
- void *kaddr;
struct inode *inode;
- struct page *node_page;
unsigned int offset;
block_t bidx;
int i;
@@ -238,18 +238,15 @@ static int check_index_in_prev_nodes(struct f2fs_sb_info
*sbi,
struct curseg_info *curseg = CURSEG_I(sbi, i);
if (curseg->segno == segno) {
sum = curseg->sum_blk->entries[blkoff];
- break;
+ goto got_it;
}
}
- if (i > CURSEG_COLD_DATA) {
- struct page *sum_page = get_sum_page(sbi, segno);
- struct f2fs_summary_block *sum_node;
- kaddr = page_address(sum_page);
- sum_node = (struct f2fs_summary_block *)kaddr;
- sum = sum_node->entries[blkoff];
- f2fs_put_page(sum_page, 1);
- }
+ sum_page = get_sum_page(sbi, segno);
+ sum_node = (struct f2fs_summary_block *)page_address(sum_page);
+ sum = sum_node->entries[blkoff];
+ f2fs_put_page(sum_page, 1);
+got_it:
/* Use the locked dnode page and inode */
nid = le32_to_cpu(sum.nid);
if (dn->inode->i_ino == nid) {
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c-designware-pcidrv: fix the incorrect return of idle callback
From: "xinhui.pan" i2c_dw_pci_runtime_idle should return -EBUSY rather than zero if it do success. Otherwise rpm_idle will call pm_suspend again and that may cause pm_schedule_suspend delay invalidate. Signed-off-by: bo.he Signed-off-by: xinhui.pan --- drivers/i2c/busses/i2c-designware-pcidrv.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c b/drivers/i2c/busses/i2c-designware-pcidrv.c index f6ed06c..96e81f6 100644 --- a/drivers/i2c/busses/i2c-designware-pcidrv.c +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c @@ -190,8 +190,8 @@ static int i2c_dw_pci_runtime_idle(struct device *dev) int err = pm_schedule_suspend(dev, 500); dev_dbg(dev, "runtime_idle called\n"); - if (err != 0) - return 0; + if (err) + return err; return -EBUSY; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] x86, mpx: hook #BR exception handler to allocate bound tables
On 01/28/2014 01:21 PM, Andy Lutomirski wrote:
On Mon, Jan 27, 2014 at 7:35 PM, Ren Qiaowei wrote:
On 01/28/2014 04:36 AM, Andy Lutomirski wrote:
+ bd_entry = status & MPX_BNDSTA_ADDR_MASK;
+ if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
+ allocate_bt(bd_entry);
What happens if this fails? Retrying forever isn't very nice.
If allocation of the bound table fail, the related entry in the bound
directory is still invalid. The following access to this entry still produce
#BR fault.
By the "following access" I think you mean the same instruction that
just trapped -- it will trap again because the exception hasn't been
fixed up. Then mmap will fail again, and you'll retry again, leading
to an infinite loop.
I don't mean the same instruction that just trapped.
I think that failure to fix up the exception should either let the
normal bounds error through or should raise SIGBUS.
Maybe we need HPA help answer this question. Peter, what do you think
about it? If allocation of the bound table fail, what should we do?
+ if (!user_mode(regs)) {
+ if (!fixup_exception(regs)) {
+ tsk->thread.error_code = error_code;
+ tsk->thread.trap_nr = X86_TRAP_BR;
+ die("bounds", regs, error_code);
+ }
Why the fixup? Unless I'm missing something, the kernel has no business
getting #BR on access to a user address.
Or are you adding code to allow the kernel to use MPX itself? If so,
shouldn't this use an MPX-specific fixup to allow normal C code to use
this stuff?
It checks whether #BR come from user-space. You can see do_trap_no_signal().
Wasn't #BR using do_trap before? do_trap doesn't call
fixup_exception. I don't see why it should do it now. (I also don't
think it should come from kernel space until someone adds kernel-mode
MPX support.)
do_trap() -> do_trap_no_signal() call similar code to check if the fault
occurred in userspace or kernel space. You can see previous discussion
for the first version of this patchset.
Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On 01/28/2014 12:47 PM, Dave Jones wrote: On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote: > On 01/28/2014 11:55 AM, Dave Jones wrote: > > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote: > > > >> > I did a bisect with the patch above applied each step of the way. > >> > This time I got a plausible looking result > >> > >> I cannot reproduce this. Would you please share how to reproduce it ? > >> Or does it just happen during the booting ? > > > > Just during boot. Very early. So early in fact, I have no logging facilities > > like usb-serial, just what is on vga console. > > > > If you want me to add some printk's, I can add a while (1); before > > the part that oopses so we can diagnose further.. > > Sure. Would you please do that for me ? Maybe we can find something in > the early log. I was hoping you'd have suggestions what you'd like me to dump ;-) I think I found something. Since I can reproduce the first problem on 3.10, I found some memory ranges in memblock have nid = 1024. When we use node_set(), it will crash. I'll see if we have the same problem on the latest kernel. [0.00] NUMA: Initialized distance table, cnt=2 [0.00] NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10 [0.00] NUMA: Node 0 [mem 0x-0x7fff] + [mem 0x1-0x47fff] -> [mem 0x-0x47fff] [0.00] Initmem setup node 0 [mem 0x-0x47fff] [0.00] NODE_DATA [mem 0x47ffd9000-0x47fff] [0.00] Initmem setup node 1 [mem 0x48000-0x87fff] [0.00] NODE_DATA [mem 0x87ffbb000-0x87ffe1fff] [0.00] : i = 0, nid = 0 [0.00] : i = 1, nid = 0 [0.00] : i = 2, nid = 0 [0.00] : i = 3, nid = 0 [0.00] : i = 4, nid = 1024 [0.00] : i = 5, nid = 1024 [0.00] : i = 6, nid = 1 [0.00] : i = 7, nid = 1 [0.00] Reserving 128MB of memory at 704MB for crashkernel (System RAM: 32406MB) [0.00] [ea00-ea0011ff] PMD -> [88047020-88047fdf] on node 0 [0.00] [ea001200-ea0021ff] PMD -> [88086f60-88087f5f] on node 1 [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x87fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x00098fff] [0.00] node 0: [mem 0x0010-0x696f7fff] [0.00] node 0: [mem 0x1-0x47fff] [0.00] node 1: [mem 0x48000-0x87fff] 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 v3 2/4] x86, mpx: hook #BR exception handler to allocate bound tables
On Mon, Jan 27, 2014 at 7:35 PM, Ren Qiaowei wrote:
> On 01/28/2014 04:36 AM, Andy Lutomirski wrote:
>>>
>>> + bd_entry = status & MPX_BNDSTA_ADDR_MASK;
>>> + if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
>>> + allocate_bt(bd_entry);
>>
>>
>> What happens if this fails? Retrying forever isn't very nice.
>>
> If allocation of the bound table fail, the related entry in the bound
> directory is still invalid. The following access to this entry still produce
> #BR fault.
>
By the "following access" I think you mean the same instruction that
just trapped -- it will trap again because the exception hasn't been
fixed up. Then mmap will fail again, and you'll retry again, leading
to an infinite loop.
I think that failure to fix up the exception should either let the
normal bounds error through or should raise SIGBUS.
>
>>> + if (!user_mode(regs)) {
>>> + if (!fixup_exception(regs)) {
>>> + tsk->thread.error_code = error_code;
>>> + tsk->thread.trap_nr = X86_TRAP_BR;
>>> + die("bounds", regs, error_code);
>>> + }
>>
>>
>> Why the fixup? Unless I'm missing something, the kernel has no business
>> getting #BR on access to a user address.
>>
>> Or are you adding code to allow the kernel to use MPX itself? If so,
>> shouldn't this use an MPX-specific fixup to allow normal C code to use
>> this stuff?
>>
> It checks whether #BR come from user-space. You can see do_trap_no_signal().
Wasn't #BR using do_trap before? do_trap doesn't call
fixup_exception. I don't see why it should do it now. (I also don't
think it should come from kernel space until someone adds kernel-mode
MPX support.)
>
>
>>> + goto exit;
>>> + }
>>> +
>>> + if (!boot_cpu_has(X86_FEATURE_MPX)) {
>>> + do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code,
>>> NULL);
>>> + goto exit;
>>
>>
>> This, as well as the status == 0 case, should probably document that the
>> exception is from BOUND, not MPX.
>>
> Ok. I will add one comment for this.
>
>
>
>>> + break;
>>> +
>>> + case 1: /* Bound violation. */
>>> + case 0: /* No MPX exception. */
>>> + do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code,
>>> NULL);
>>> + break;
>>
>>
>> What does "No Intel MPX exception" mean? Surely that has business
>> sending #BR.
>>
> Oh. It comes from spec, and just mean it is not from MPX. :) I will change
> it to be accurate.
>
>
>>> +
>>> + default:
>>> + break;
>>
>>
>> What does status 3 mean? The docs say "reserved". Presumably this
>> should log and kill the process.
>
> I guess it should be a good suggestion.
>
> Thanks,
> Qiaowei
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On 01/28/2014 12:47 PM, Dave Jones wrote: On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote: > On 01/28/2014 11:55 AM, Dave Jones wrote: > > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote: > > > >> > I did a bisect with the patch above applied each step of the way. > >> > This time I got a plausible looking result > >> > >> I cannot reproduce this. Would you please share how to reproduce it ? > >> Or does it just happen during the booting ? > > > > Just during boot. Very early. So early in fact, I have no logging facilities > > like usb-serial, just what is on vga console. > > > > If you want me to add some printk's, I can add a while (1); before > > the part that oopses so we can diagnose further.. > > Sure. Would you please do that for me ? Maybe we can find something in > the early log. I was hoping you'd have suggestions what you'd like me to dump ;-) Sorry. I didn't say it clearly. :) Seeing from your earlier mail, it crashed at: while (zonelist_zone_idx(z) > highest_zoneidx) de: 3b 77 08cmp0x8(%rdi),%esi I stuck this at the top of the function.. printk(KERN_ERR "z:%p nodes:%p highest:%d\n", z, nodes, highest_zoneidx); and got z: 1d08 nodes: (null) highest:3 nodes=null and highest=3, they are correct. When looking into next_zones_zonelist(), I cannot see why it crashed. So, can you print the zone id in the for_each_zone_zonelist() loop in nr_free_zone_pages() ? I want to know why it crashed. A NULL pointer ? Which one ? Thanks. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote: > On 01/28/2014 11:55 AM, Dave Jones wrote: > > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote: > > > > > > I did a bisect with the patch above applied each step of the way. > > > > This time I got a plausible looking result > > > > > > I cannot reproduce this. Would you please share how to reproduce it ? > > > Or does it just happen during the booting ? > > > > Just during boot. Very early. So early in fact, I have no logging > > facilities > > like usb-serial, just what is on vga console. > > > > If you want me to add some printk's, I can add a while (1); before > > the part that oopses so we can diagnose further.. > > Sure. Would you please do that for me ? Maybe we can find something in > the early log. I was hoping you'd have suggestions what you'd like me to dump ;-) Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On 01/28/2014 11:55 AM, Dave Jones wrote: On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote: > > I did a bisect with the patch above applied each step of the way. > > This time I got a plausible looking result > > I cannot reproduce this. Would you please share how to reproduce it ? > Or does it just happen during the booting ? Just during boot. Very early. So early in fact, I have no logging facilities like usb-serial, just what is on vga console. If you want me to add some printk's, I can add a while (1); before the part that oopses so we can diagnose further.. Sure. Would you please do that for me ? Maybe we can find something in the early log. Thanks. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! This is the patch that I had sent after -rc8 and which we decided to wait before merging. It's based on a different tree than my -next branch (it needs some pre-reqs that were in -rc4 or so while my -next is based on -rc1) so I left it as a separate branch for your to pull. It's identical to the request I did 2 or 3 weeks back. This fixes crashes in mremap with THP on powerpc. The fix however requires a small change in the generic code. It moves a condition into a helper we can override from the arch which is harmless, but it *also* slightly changes the order of the set_pmd and the withdraw & deposit, which should be fine according to Kirill (who wrote that code) but I agree -rc8 is a bit late... It was acked by Kirill and Andrew told me to just merge it via powerpc. Cheers, Ben. The following changes since commit a6da83f98267bc8ee4e34aa899169991eb0ceb93: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2014-01-13 10:59:05 +0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to b3084f4db3aeb991c507ca774337c7e7893ed04f: powerpc/thp: Fix crash on mremap (2014-01-15 15:46:38 +1100) Aneesh Kumar K.V (1): powerpc/thp: Fix crash on mremap arch/powerpc/include/asm/pgtable-ppc64.h | 14 ++ include/asm-generic/pgtable.h| 12 mm/huge_memory.c | 14 +- 3 files changed, 31 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc.git next branch
Hi Linus ! So here's my next branch for powerpc. A bit late as I was on vacation last week. It's mostly the same stuff that was in next already, I just added two patches today which are the wiring up of lockref for powerpc, which for some reason fell through the cracks last time and is trivial. The merge has conflicts that aren't too nasty but in case you have an issue resolving them, I've put a resolved branch in "test" of the same repository for you to look at. The highlights are, in addition to a bunch of bug fixes: - Reworked Machine Check handling on kernels running without a hypervisor (or acting as a hypervisor). Provides hooks to handle some errors in real mode such as TLB errors, handle SLB errors, etc... - Support for retrieving memory error information from the service processor on IBM servers running without a hypervisor and routing them to the memory poison infrastructure. - _PAGE_NUMA support on server processors - 32-bit BookE relocatable kernel support - FSL e6500 hardware tablewalk support - A bunch of new/revived board support - FSL e6500 deeper idle states and altivec powerdown support I have a remaining fix that is still based on a different branch for which I will send you a pull request separately (it's the patch that didn't make it in -rc8 since it might potentially affect x86). You'll notice a generic mm change here, it has been acked by the relevant authorities and is a pre-req for our _PAGE_NUMA support. The following changes since commit f991db1cf1bdca43675b5d2df0af991719727029: Merge remote-tracking branch 'agust/merge' into merge (2013-12-30 14:48:27 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to 7179ba52889bef7e5e23f72908270e1ab2b7fc6f: powerpc: Implement arch_spin_is_locked() using arch_spin_value_unlocked() (2014-01-28 14:45:44 +1100) Alexey Kardashevskiy (1): PPC: POWERNV: move iommu_add_device earlier Alistair Popple (3): powerpc/iommu: Update constant names to reflect their hardcoded page size powerpc/iommu: Add it_page_shift field to determine iommu page size powerpc/iommu: Update the generic code to use dynamic iommu page sizes Andreas Schwab (1): powerpc: Add vr save/restore functions Aneesh Kumar K.V (5): mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE powerpc/mm: Use HPTE constants when updating hpte bits powerpc/mm: Free up _PAGE_COHERENCE for numa fault use later powerpc/mm: Only check for _PAGE_PRESENT in set_pte/pmd functions powerpc/mm: Enable _PAGE_NUMA for book3s Anton Blanchard (2): powerpc: Fix endian issues in power7/8 machine check handler drivers/tty: ehv_bytechan fails to build as a module Benjamin Herrenschmidt (3): powerpc: Fix races with irq_work Brian King (1): powerpc: Increase EEH recovery timeout for SR-IOV Chen Gang (1): powerpc: kernel: remove useless code which related with 'max_cpus' Christian Engelmayer (1): powerpc/sysdev: Fix a pci section mismatch for Book E Denis Efremov (1): powerpc/ps3: Remove inline marking of EXPORT_SYMBOL functions Diana Craciun (1): powerpc: Replaced tlbilx with tlbwe in the initialization code Gavin Shan (9): powerpc/powernv: Move PHB-diag dump functions around powerpc/eeh: Output PHB diag-data powerpc/powernv: Remove unnecessary assignment powerpc/eeh: Add restore_config operation powerpc/eeh: Call opal_pci_reinit() on powernv for restoring config space powerpc/eeh: Hotplug improvement powerpc/iommu: Don't detach device without IOMMU group powerpc/eeh: Handle multiple EEH errors powerpc/eeh: Escalate error on non-existing PE Geert Uytterhoeven (2): powerpc/windfarm: Remove superfluous name casts powerpc: Make add_system_ram_resources() __init Ian Campbell (3): powerpc/4xx: Fix warning in kilauea.dtb powerpc/dts/virtex440: Declare address/size-cells for phy device powerpc/boot: Ignore .dtb files. Jeremy Kerr (2): powerpc: Make slb_shadow a local powerpc: Dynamically allocate slb_shadow from memblock Joseph Myers (6): powerpc: fix exception clearing in e500 SPE float emulation powerpc: fix e500 SPE float rounding inexactness detection math-emu: fix floating-point to integer unsigned saturation math-emu: fix floating-point to integer overflow detection powerpc: fix e500 SPE float to integer and fixed-point conversions powerpc: fix e500 SPE float SIGFPE generation Kevin Hao (14): powerpc: Move the patch_exception to a common place powerpc: Use patch_exception to update the debug exception handler powerpc: purge all the prefetched instructions for the coherent icache flush powerpc/85xx: don't init the mpic ipi for the SoC which ha
Re: [PATCH 0/3] perf-bench: introduce futex microbenchmarks
On Fri, 2014-01-24 at 10:13 -0800, Darren Hart wrote: > On Mon, 2013-12-16 at 06:44 -0800, Davidlohr Bueso wrote: > > On Mon, 2013-12-16 at 11:08 +0100, Ingo Molnar wrote: > > > * Davidlohr Bueso wrote: > > > > > > > This patchset adds three programs that stress and measure different > > > > futex operations: (i) uaddr hashing, (ii) wakeups and (iii) > > > > requeuing/waiting. > > > > > > > > More details and usage examples in each individual patch, along with > > > > parameter descriptions in the code. > > > > > > > > While the previous effort (https://lkml.org/lkml/2012/5/17/207) to > > > > add futex benchmarks to perf-bench failed, I strongly believe that > > > > perf is an ideal place for these kinds of programs. This patchset is > > > > different from Hitoshi's because it does not try to take over > > > > Darren's futextest suite, and only deals with finer grained aspects > > > > of the kernel's implementation, and thus mostly useful for kernel > > > > hacking. Furthermore, by being part of the kernel tree, it can get > > > > more attention and naturally evolve with time. > > > > > > Looks pretty useful! > > > > > > Could the two approaches be merged? > > > > Unless Darren doesn't want to, I don't see why not. I can resurrect > > Hitoshi's original patch if/after this series is applied. > > Apologies, I only am just now seeing this. > > I agree that we should take whatever makes sense for perf out of > futex-test and merge it with perf. It will see greater use and receive > more review and improvements than it will in my obscure repository. > > With trinity covering the fuzz testing and perf handling performance > tests, I think futex-test can be reduced down to a functional > test-suite, which is perfectly fine with me. > > If there is still interest here, I'll support it. Arnaldo, could you consider this for 3.15? I've also got some additional work for perf-bench but am waiting for this to get settled first. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] acpi-cpufreq: De-register cpu notifier and free struct msr on error.
If cpufreq_register_driver() fails we would free the acpi driver
related structures but not free the ones allocated
by acpi_cpufreq_boost_init() function. This meant that as
the driver error-ed out and a CPU online/offline event came
we would crash and burn as one of the CPU notifiers would point
to garbage.
This fixes a regression that commit cfc9c8ed03e4d908f2388af8815f44c87b503aaf
"acpi-cpufreq: Adjust the code to use the common boost attribute"
introduced.
CC: Lukasz Majewski
CC: Myungjoo Ham
CC: Viresh Kumar
CC: Rafael J. Wysocki
CC: Boris Ostrovsky
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/cpufreq/acpi-cpufreq.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 79e5608..3e856d6 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -969,9 +969,10 @@ static int __init acpi_cpufreq_init(void)
acpi_cpufreq_boost_init();
ret = cpufreq_register_driver(&acpi_cpufreq_driver);
- if (ret)
+ if (ret) {
free_acpi_perf_data();
-
+ acpi_cpufreq_boost_exit();
+ }
return ret;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote: > > I did a bisect with the patch above applied each step of the way. > > This time I got a plausible looking result > > I cannot reproduce this. Would you please share how to reproduce it ? > Or does it just happen during the booting ? Just during boot. Very early. So early in fact, I have no logging facilities like usb-serial, just what is on vga console. If you want me to add some printk's, I can add a while (1); before the part that oopses so we can diagnose further.. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 22/22] XIP: Add support for unwritten extents
On Mon, Jan 27, 2014 at 04:32:07PM -0700, Ross Zwisler wrote:
> It looks like we have an additional bit of complexity with the hole case. The
> issue is that for holes, bh->b_size is just the full size of the write as set
> earlier in the function:
>
> bh->b_size = ALIGN(end - offset, PAGE_SIZE);
>
> >From this code it seems like you hoped the call into get_block() would adjust
> bh->b_size to the size of the hole, allowing you to zero just the hole space
> in the user buffer. It doesn't look like it does, though, at least for ext4.
Argh. I got confused. ext4 *has* this information, it just doesn't
propagate it into the bh if it's a hole! Should it? The comments in
the direct IO code imply that it *may*, but doesn't *have* to. What it's
doing now (not touching it) is probably wrong.
> To just assume the current FS block is a hole, we can do something like this:
Yes, this should fix things on an interim basis. Bit inefficient,
but it'll work.
> diff --git a/fs/xip.c b/fs/xip.c
> index 35e401e..e902593 100644
> --- a/fs/xip.c
> +++ b/fs/xip.c
> @@ -122,7 +122,7 @@ static ssize_t xip_io(int rw, struct inode *inode, const
> struct
>
> if (hole) {
> addr = NULL;
> - size = bh->b_size - first;
> + size = (1 << inode->i_blkbits) - first;
> } else {
> retval = xip_get_addr(inode, bh, &addr);
> if (retval < 0)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V0 PATCH] pvh: Disable PSE feature for now
On Mon, Jan 27, 2014 at 06:18:39PM -0800, Mukesh Rathor wrote: > Until now, xen did not expose PSE to pvh guest, but a patch was submitted > to xen list to enable bunch of features for a pvh guest. PSE has not been Which 'patch'? > looked into for PVH, so until we can do that and test it to make sure it > works, disable the feature to avoid flood of bugs. I think we want a flood of bugs, no? > > Signed-off-by: Mukesh Rathor > --- > arch/x86/xen/enlighten.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index a4d7b64..4e952046 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -1497,6 +1497,11 @@ static void __init xen_pvh_early_guest_init(void) > xen_have_vector_callback = 1; > xen_pvh_set_cr_flags(0); > > +/* pvh guests are not quite ready for large pages yet */ > +setup_clear_cpu_cap(X86_FEATURE_PSE); > +setup_clear_cpu_cap(X86_FEATURE_PSE36); > + > + > #ifdef CONFIG_X86_32 > BUG(); /* PVH: Implement proper support. */ > #endif > -- > 1.7.2.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] x86, mpx: add documentation on Intel MPX
On 01/28/2014 04:27 AM, Andy Lutomirski wrote: On 01/26/2014 01:08 AM, Qiaowei Ren wrote: +1) Providing handlers for bounds faults (#BR). + +When MPX is enabled, there are 2 new situations that can generate +#BR faults. If a bounds overflow occurs then a #BR is generated. +The fault handler will decode MPX instructions to get violation +address and set this address into extended struct siginfo. Can you document exactly where the insn address and pointer value end up? (If it's in the (IMO hideous) cr2 field in ucontext, this needs to be documented. If it's somewhere useful in siginfo, that should also be documented to save people the time it takes to figure it out.) Ok. I will describe extended siginfo at this documentation. Thanks, Qiaowei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] x86, mpx: hook #BR exception handler to allocate bound tables
On 01/28/2014 04:36 AM, Andy Lutomirski wrote:
+ bd_entry = status & MPX_BNDSTA_ADDR_MASK;
+ if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
+ allocate_bt(bd_entry);
What happens if this fails? Retrying forever isn't very nice.
If allocation of the bound table fail, the related entry in the bound
directory is still invalid. The following access to this entry still
produce #BR fault.
+ if (!user_mode(regs)) {
+ if (!fixup_exception(regs)) {
+ tsk->thread.error_code = error_code;
+ tsk->thread.trap_nr = X86_TRAP_BR;
+ die("bounds", regs, error_code);
+ }
Why the fixup? Unless I'm missing something, the kernel has no business
getting #BR on access to a user address.
Or are you adding code to allow the kernel to use MPX itself? If so,
shouldn't this use an MPX-specific fixup to allow normal C code to use
this stuff?
It checks whether #BR come from user-space. You can see do_trap_no_signal().
+ goto exit;
+ }
+
+ if (!boot_cpu_has(X86_FEATURE_MPX)) {
+ do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL);
+ goto exit;
This, as well as the status == 0 case, should probably document that the
exception is from BOUND, not MPX.
Ok. I will add one comment for this.
+ break;
+
+ case 1: /* Bound violation. */
+ case 0: /* No MPX exception. */
+ do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL);
+ break;
What does "No Intel MPX exception" mean? Surely that has business
sending #BR.
Oh. It comes from spec, and just mean it is not from MPX. :) I will
change it to be accurate.
+
+ default:
+ break;
What does status 3 mean? The docs say "reserved". Presumably this
should log and kill the process.
I guess it should be a good suggestion.
Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Tree for Jan 28
Hi all, Please do *not* add material destined for v3.15 to your linux-next included trees until after v3.14-rc1 is released. This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140124: Dropped trees: imx-mxs (complex merge conflicts against the arm tree) The powerpc tree still had its build failure. Tip tree gained a conflict against Linus' tree. The staging tree lost its build failure. The scsi tree lost its conflicts so it is back. The init tree lost some more of its patches. Non-merge commits (relative to Linus' tree): 2689 3435 files changed, 215376 insertions(+), 61940 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 208 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (ba635f8cd20e Merge tag 'trace-fixes-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (b25f3e1c3584 ARM: 7938/1: OMAP4/highbank: Flush L2 cache before disabling) Merging m68k-current/for-linus (56931d73697c m68k/mac: Make SCC reset work more reliably) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (bb9fbe2ddd6d AF_PACKET: Add documentation for queue mapping fanout mode) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (e7729a415315 ALSA: hda - Fix silent output on MacBook Air 1,1) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (7d0d46da750a Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging driver-core.current/driver-core-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging staging.current/staging-linus (77d143de7581 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml) Merging char-misc.current/char-misc-linus (90804ed61f24 Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs) Merging input-current/for-linus (55df811f2066 Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (79ba451d66ca crypto: aesni - fix build on x86 (32bit)) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current
Re: [PATCH] HID: i2c-hid: add runtime PM support
On Tue, Jan 14, 2014 at 5:13 AM, Mika Westerberg
wrote:
> This patch adds runtime PM support for the HID over I2C driver. When the
> i2c-hid device is first opened we power it on and on the last close we
> power it off.
>
> The implementation is not the most power efficient because it needs some
> interaction from the userspace (e.g close the device node whenever we are
> no more interested in getting events), nevertheless it allows us to save
> some power and works with devices that are not wake capable.
>
Hi Mika,
I am a little bit puzzled here. The commit message just says that you
changed the implementation of the power saving with the exact same
behavior... At least that's what I understand.
Currently, the devices should be put on sleep if nobody is reading,
and back alive if a reader arrives.
I think there is a gain with the patch, but my knowledge of the pm
subsystem is far too limited to see it :(
> Signed-off-by: Mika Westerberg
> ---
> drivers/hid/i2c-hid/i2c-hid.c | 81
> ---
> 1 file changed, 54 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index d1f81f52481a..ff767d03d60e 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -454,10 +455,18 @@ static void i2c_hid_init_reports(struct hid_device *hid)
> return;
> }
>
> + /*
> +* The device must be powered on while we fetch initial reports
> +* from it.
> +*/
> + pm_runtime_get_sync(&client->dev);
> +
> list_for_each_entry(report,
> &hid->report_enum[HID_FEATURE_REPORT].report_list, list)
> i2c_hid_init_report(report, inbuf, ihid->bufsize);
>
> + pm_runtime_put(&client->dev);
> +
> kfree(inbuf);
> }
>
> @@ -703,8 +712,8 @@ static int i2c_hid_open(struct hid_device *hid)
>
> mutex_lock(&i2c_hid_open_mut);
> if (!hid->open++) {
> - ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> - if (ret) {
> + ret = pm_runtime_get_sync(&client->dev);
dummy question (kind of late here...). Is there a counter of how many
get/put has been called in pm_runtime which could allow us to get rid
of the hid->open count?
> + if (ret < 0) {
> hid->open--;
> goto done;
> }
> @@ -712,7 +721,7 @@ static int i2c_hid_open(struct hid_device *hid)
> }
> done:
> mutex_unlock(&i2c_hid_open_mut);
> - return ret;
> + return ret < 0 ? ret : 0;
> }
>
> static void i2c_hid_close(struct hid_device *hid)
> @@ -729,37 +738,17 @@ static void i2c_hid_close(struct hid_device *hid)
> clear_bit(I2C_HID_STARTED, &ihid->flags);
>
> /* Save some power */
> - i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
> + pm_runtime_put(&client->dev);
> }
> mutex_unlock(&i2c_hid_open_mut);
> }
>
> -static int i2c_hid_power(struct hid_device *hid, int lvl)
> -{
> - struct i2c_client *client = hid->driver_data;
> - struct i2c_hid *ihid = i2c_get_clientdata(client);
> - int ret = 0;
> -
> - i2c_hid_dbg(ihid, "%s lvl:%d\n", __func__, lvl);
> -
> - switch (lvl) {
> - case PM_HINT_FULLON:
> - ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> - break;
> - case PM_HINT_NORMAL:
> - ret = i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
> - break;
> - }
> - return ret;
> -}
> -
> static struct hid_ll_driver i2c_hid_ll_driver = {
> .parse = i2c_hid_parse,
> .start = i2c_hid_start,
> .stop = i2c_hid_stop,
> .open = i2c_hid_open,
> .close = i2c_hid_close,
> - .power = i2c_hid_power,
If I understand correctly, here you are trying to fix hidraw (with
i2c_hid tramsport) which used to set_power on/off twice with the first
reader, right?
I don't think we have other i2c_hid users of hid_hw_power, but I am a
little bit worried of simply removing the callback.
What if we just change i2c_hid_set_power in i2c_hid_power by the
corresponding pm_runtime calls?
> .request = i2c_hid_request,
> };
>
> @@ -973,13 +962,17 @@ static int i2c_hid_probe(struct i2c_client *client,
> if (ret < 0)
> goto err;
>
> + pm_runtime_get_noresume(&client->dev);
> + pm_runtime_set_active(&client->dev);
> + pm_runtime_enable(&client->dev);
> +
> ret = i2c_hid_fetch_hid_descriptor(ihid);
> if (ret < 0)
> - goto err;
> + goto err_pm;
>
> ret = i2c_hid_init_irq(client);
> if (ret < 0)
> - goto err;
> + goto err_pm;
>
> hid = hid_allocate_device();
>
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On 01/28/2014 10:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
> On 01/28/2014 08:32 AM, David Rientjes wrote:
> > On Wed, 22 Jan 2014, David Rientjes wrote:
> >
> >>>arch/x86/mm/numa.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> >>> index 81b2750..ebefeb7 100644
> >>> --- a/arch/x86/mm/numa.c
> >>> +++ b/arch/x86/mm/numa.c
> >>> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> >>>}
> >>>}
> >>>
> >>> +static nodemask_t numa_kernel_nodes __initdata;
> >>>static void __init numa_clear_kernel_node_hotplug(void)
> >>>{
> >>>int i, nid;
> >>> - nodemask_t numa_kernel_nodes;
> >>>unsigned long start, end;
> >>>struct memblock_type *type =&memblock.reserved;
> >>>
> >>
> >> Isn't this also a bugfix since you never initialize numa_kernel_nodes
when
> >> it's allocated on the stack with NODE_MASK_NONE?
> >>
> >
> > This hasn't been answered and the patch still isn't in linux-kernel yet
> > Dave tested it as good. I'm suspicious of the changelog that indicates
> > this nodemask is the result of a stack overflow itself which only
manages
> > to reproduce itself in the init patch slightly more than 50% of the
time.
> > How is that possible?
> >
> > I think the changelog should indicate this also fixes an uninitialized
> > nodemask issue.
>
> Hi David,
>
> I'm still working on this problem, but unfortunately nothing new for now.
> And the test till now shows no more problem here.
>
> I'm digging into it, but need more time.
>
> I'll resend a new patch and modify the changelog soon. Before we find the
> root cause, I think we can use this patch as a temporary solution.
Ok, I hit the 2nd bug again (oops in next_zones_zonelist...)
I did a bisect with the patch above applied each step of the way.
This time I got a plausible looking result
I cannot reproduce this. Would you please share how to reproduce it ?
Or does it just happen during the booting ?
a0acda917284183f9b71e2d08b0aa0aea722b321 is the first bad commit
commit a0acda917284183f9b71e2d08b0aa0aea722b321
Author: Tang Chen
Date: Tue Jan 21 15:49:32 2014 -0800
acpi, numa, mem_hotplug: mark all nodes the kernel resides un-hotpluggable
Reverting this commit of course removes the whole function from above,
so we haven't really learned anything new, other than that commit is broken,
even after the above fix-up.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On 01/28/2014 10:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
> On 01/28/2014 08:32 AM, David Rientjes wrote:
> > On Wed, 22 Jan 2014, David Rientjes wrote:
> >
> >>>arch/x86/mm/numa.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> >>> index 81b2750..ebefeb7 100644
> >>> --- a/arch/x86/mm/numa.c
> >>> +++ b/arch/x86/mm/numa.c
> >>> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> >>>}
> >>>}
> >>>
> >>> +static nodemask_t numa_kernel_nodes __initdata;
> >>>static void __init numa_clear_kernel_node_hotplug(void)
> >>>{
> >>>int i, nid;
> >>> - nodemask_t numa_kernel_nodes;
> >>>unsigned long start, end;
> >>>struct memblock_type *type =&memblock.reserved;
> >>>
> >>
> >> Isn't this also a bugfix since you never initialize numa_kernel_nodes
when
> >> it's allocated on the stack with NODE_MASK_NONE?
> >>
> >
> > This hasn't been answered and the patch still isn't in linux-kernel yet
> > Dave tested it as good. I'm suspicious of the changelog that indicates
> > this nodemask is the result of a stack overflow itself which only
manages
> > to reproduce itself in the init patch slightly more than 50% of the
time.
> > How is that possible?
> >
> > I think the changelog should indicate this also fixes an uninitialized
> > nodemask issue.
>
> Hi David,
>
> I'm still working on this problem, but unfortunately nothing new for now.
> And the test till now shows no more problem here.
>
> I'm digging into it, but need more time.
>
> I'll resend a new patch and modify the changelog soon. Before we find the
> root cause, I think we can use this patch as a temporary solution.
Ok, I hit the 2nd bug again (oops in next_zones_zonelist...)
I did a bisect with the patch above applied each step of the way.
This time I got a plausible looking result
a0acda917284183f9b71e2d08b0aa0aea722b321 is the first bad commit
commit a0acda917284183f9b71e2d08b0aa0aea722b321
Author: Tang Chen
Date: Tue Jan 21 15:49:32 2014 -0800
acpi, numa, mem_hotplug: mark all nodes the kernel resides un-hotpluggable
Reverting this commit of course removes the whole function from above,
so we haven't really learned anything new, other than that commit is broken,
even after the above fix-up.
If we revert this commit, memory hot-remove won't be able to work.
Let's try to fix it before the merge window is close.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpuset: update MAINTAINERS entry
Add mailing list and tree tag to the entry. Signed-off-by: Li Zefan --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8285ed4..81bcbe0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2376,8 +2376,10 @@ F: tools/power/cpupower/ CPUSETS M: Li Zefan +L: cgro...@vger.kernel.org W: http://www.bullopensource.org/cpuset/ W: http://oss.sgi.com/projects/cpusets/ +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git S: Maintained F: Documentation/cgroups/cpusets.txt F: include/linux/cpuset.h -- 1.8.0.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/
Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
> Thanks, it was a great help as it uncovered a few issues in fringe arch
> that I didn't have toolchains for, and I've fixed all of those up.
>
> I've noticed that powerpc has been un-buildable for a while now; I have
> used this hack patch locally so I could run the ppc defconfigs to check
> that I didn't break anything. Maybe useful for linux-next in the
> interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Can you and/or Aneesh submit that as a proper patch (with S-O-B
etc...) ?
Thanks !
Cheers,
Ben.
> Paul.
> --
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
> b/arch/powerpc/include/asm/pgtable-ppc64.h
> index d27960c89a71..d0f070a2b395 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma,
> unsigned long address,
> pmd_t *pmdp);
>
> #define pmd_move_must_withdraw pmd_move_must_withdraw
> -typedef struct spinlock spinlock_t;
> -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> - spinlock_t *old_pmd_ptl)
> +struct spinlock;
> +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> + struct spinlock *old_pmd_ptl)
> {
> /*
>* Archs like ppc64 use pgtable to store per pmd
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote:
> Hi Lars/Vinod,
> >> The question here i think would be waht this device supports? Is the
> >> hardware
> >> capable of doing interleaved transfers, then would make sense.
> >
> > The hardware does 2D transfers. The parameters for a transfer are height,
> > width and stride. That's only a subset of what interleaved transfers can be
> > (xt->num_frames must be one for 2d transfers). But if I remember correctly
> > there has been some discussion on this in the past and the result of that
> > discussion was that using interleaved transfers for 2D transfers is
> > preferred over adding a custom API for 2D transfers.
>
> I went through the prep_interleaved_dma API and I see only one descriptor
> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame
> buffers (can be more in future), isn't it less efficient compared to the
> prep_slave_sg where we get a single sg list and can prepare all the
> descriptors
> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me
> know your opinions.
Well the descriptor maybe one, but that can represent multiple frames, for
example 16 as in your case. Can you read up the documentation of how multiple
frames are passed. Pls see include/linux/dmaengine.h
/**
* Interleaved Transfer Request
*
* A chunk is collection of contiguous bytes to be transfered.
* The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
* ICGs may or maynot change between chunks.
* A FRAME is the smallest series of contiguous {chunk,icg} pairs,
* that when repeated an integral number of times, specifies the transfer.
* A transfer template is specification of a Frame, the number of times
* it is to be repeated and other per-transfer attributes.
*
* Practically, a client driver would have ready a template for each
* type of transfer it is going to need during its lifetime and
* set only 'src_start' and 'dst_start' before submitting the requests.
*
*
* | Frame-1| Frame-2 | ~ | Frame-'numf' |
* |==.===...=...|==.===...=...| ~ |==.===...=...|
*
*== Chunk size
*... ICG
*/
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: fixed: update to devm_* API
Update the code to use devm_* API so that driver core will manage
resources.
Signed-off-by: Manish Badarkhe
---
Changes since V1:
1. Updated driver to use "devm_kzalloc" to "kstrdup".
2. Updated commit message.
Not tested on any board.
:100644 100644 5ea64b9... e9763a4... M drivers/regulator/fixed.c
drivers/regulator/fixed.c | 42 --
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 5ea64b9..e9763a4 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -132,15 +132,15 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
GFP_KERNEL);
if (drvdata == NULL) {
dev_err(&pdev->dev, "Failed to allocate device data\n");
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
- drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
+ drvdata->desc.name = devm_kzalloc(&pdev->dev,
+ strlen(config->supply_name) + 1,
+ GFP_KERNEL);
if (drvdata->desc.name == NULL) {
dev_err(&pdev->dev, "Failed to allocate supply name\n");
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
drvdata->desc.type = REGULATOR_VOLTAGE;
drvdata->desc.owner = THIS_MODULE;
@@ -149,13 +149,13 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
drvdata->desc.enable_time = config->startup_delay;
if (config->input_supply) {
- drvdata->desc.supply_name = kstrdup(config->input_supply,
- GFP_KERNEL);
+ drvdata->desc.supply_name = devm_kzalloc(&pdev->dev,
+ strlen(config->input_supply) + 1,
+ GFP_KERNEL);
if (!drvdata->desc.supply_name) {
dev_err(&pdev->dev,
"Failed to allocate input supply\n");
- ret = -ENOMEM;
- goto err_name;
+ return -ENOMEM;
}
}
@@ -186,11 +186,12 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
cfg.driver_data = drvdata;
cfg.of_node = pdev->dev.of_node;
- drvdata->dev = regulator_register(&drvdata->desc, &cfg);
+ drvdata->dev = devm_regulator_register(&pdev->dev, &drvdata->desc,
+ &cfg);
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
dev_err(&pdev->dev, "Failed to register regulator: %d\n", ret);
- goto err_input;
+ return ret;
}
platform_set_drvdata(pdev, drvdata);
@@ -199,24 +200,6 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
drvdata->desc.fixed_uV);
return 0;
-
-err_input:
- kfree(drvdata->desc.supply_name);
-err_name:
- kfree(drvdata->desc.name);
-err:
- return ret;
-}
-
-static int reg_fixed_voltage_remove(struct platform_device *pdev)
-{
- struct fixed_voltage_data *drvdata = platform_get_drvdata(pdev);
-
- regulator_unregister(drvdata->dev);
- kfree(drvdata->desc.supply_name);
- kfree(drvdata->desc.name);
-
- return 0;
}
#if defined(CONFIG_OF)
@@ -229,7 +212,6 @@ MODULE_DEVICE_TABLE(of, fixed_of_match);
static struct platform_driver regulator_fixed_voltage_driver = {
.probe = reg_fixed_voltage_probe,
- .remove = reg_fixed_voltage_remove,
.driver = {
.name = "reg-fixed-voltage",
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
On Sun, Jan 26, 2014 at 06:39:21PM +0100, Lars-Peter Clausen wrote:
> On 01/26/2014 02:59 PM, Vinod Koul wrote:
> > On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
> >> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
> >>> Hi Lars,
> >>>
> >>> On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen
> >>> wrote:
> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
> [...]
> > +/**
> > + * xilinx_vdma_device_control - Configure DMA channel of the device
> > + * @dchan: DMA Channel pointer
> > + * @cmd: DMA control command
> > + * @arg: Channel configuration
> > + *
> > + * Return: '0' on success and failure value on error
> > + */
> > +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> > + enum dma_ctrl_cmd cmd, unsigned
> > long arg)
> > +{
> > + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> > +
> > + switch (cmd) {
> > + case DMA_TERMINATE_ALL:
> > + xilinx_vdma_terminate_all(chan);
> > + return 0;
> > + case DMA_SLAVE_CONFIG:
> > + return xilinx_vdma_slave_config(chan,
> > + (struct xilinx_vdma_config *)arg);
>
> You really shouldn't be overloading the generic API with your own
> semantics.
> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> >>>
> >>> Ok. The driver needs few additional configuration from the slave
> >>> device like Vertical
> >>> Size, Horizontal Size, Stride etc., for the DMA transfers, in that case
> >>> do you
> >>> suggest me to define a separate dma_ctrl_cmd like the one
> >>> FSLDMA_EXTERNAL_START
> >>> defined for Freescale drivers?
> >>
> >> In my opinion it is not a good idea to have driver implement a generic API,
> >> but at the same time let the driver have custom semantics for those API
> >> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
> >> values passed to gpio_set_value instead of 0 and 1. It completely defeats
> >> the purpose of a generic API, namely that you are able to write generic
> >> code
> >> that makes use of the API without having to know about which implementation
> >> API it is talking to. The dmaengine framework provides the
> >> dmaengine_prep_interleaved_dma() function to setup two dimensional
> >> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
> >
> > The question here i think would be waht this device supports? Is the
> > hardware
> > capable of doing interleaved transfers, then would make sense.
>
> The hardware does 2D transfers. The parameters for a transfer are height,
> width and stride. That's only a subset of what interleaved transfers can be
> (xt->num_frames must be one for 2d transfers). But if I remember correctly
> there has been some discussion on this in the past and the result of that
> discussion was that using interleaved transfers for 2D transfers is
> preferred over adding a custom API for 2D transfers.
Yup that would be my recomendation. Moving this driver to interleaved API seems
right to me
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Fix coding style errors
I corrected several coding errors.
Signed-off-by: Brandon Stewart
---
drivers/macintosh/adb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
index 53611de..dd3f49a 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -623,7 +623,7 @@ do_adb_query(struct adb_request *req)
{
int ret = -EINVAL;
- switch(req->data[1]) {
+ switch (req->data[1]) {
case ADB_QUERY_GETDEVINFO:
if (req->nbytes < 3)
break;
@@ -792,8 +792,9 @@ static ssize_t adb_write(struct file *file, const char
__user *buf,
}
/* Special case for ADB_BUSRESET request, all others are sent to
the controller */
- else if ((req->data[0] == ADB_PACKET) && (count > 1)
- && (req->data[1] == ADB_BUSRESET)) {
+ else if (req->data[0] == ADB_PACKET &&
+ req->data[1] == ADB_BUSRESET &&
+ count > 1) {
ret = do_adb_reset_bus();
up(&adb_probe_mutex);
atomic_dec(&state->n_pending);
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3 v2] pinctrl-adi2: change irq_base from usigned int to int
From: Sonic Zhang
Negative irq_base means there is no fixed Linux irq mappings are created from
the platform data.
The driver calls irq_create_mapping to allocate a virtual Linux irq.
Signed-off-by: Sonic Zhang
---
v2-changes:
- reword the patch description
drivers/pinctrl/pinctrl-adi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
index e8120fa..9fb53c9 100644
--- a/drivers/pinctrl/pinctrl-adi2.c
+++ b/drivers/pinctrl/pinctrl-adi2.c
@@ -173,7 +173,7 @@ struct adi_pinctrl {
struct gpio_port {
struct list_head node;
void __iomem *base;
- unsigned int irq_base;
+ int irq_base;
unsigned int width;
struct gpio_port_t *regs;
struct gpio_port_saved saved_data;
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rcu] c0f4dfd4f9: -65% softirqs.RCU
On Mon, Jan 27, 2014 at 09:06:02AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 24, 2014 at 07:11:30PM +0800, Fengguang Wu wrote:
> > On Mon, Jan 20, 2014 at 08:41:00PM -0800, Paul E. McKenney wrote:
> > > On Mon, Jan 20, 2014 at 08:29:12PM +0800, Fengguang Wu wrote:
> > > > On Sun, Jan 19, 2014 at 03:11:14PM -0800, Paul E. McKenney wrote:
> > > > > On Sun, Jan 19, 2014 at 08:16:08PM +0800, Fengguang Wu wrote:
> > > > > > Hi Paul,
> > > > > >
> > > > > > Just FYI, we noticed the following changes (which looks good) on
> > > > > > old commit
> > > > > > c0f4dfd4f9 ("rcu: Make RCU_FAST_NO_HZ take advantage of numbered
> > > > > > callbacks")
> > > > > > in test case dd-write/4HDD-JBOD-cfq-btrfs-1dd:
> > > > > >
> > > > > > b11cc5 (parent) c0f4dfd4f90f1667d234d21f1
> > > > > > --- -
> > > > > > 213757 ~ 4% -65.4% 73929 ~ 3% softirqs.RCU
> > > > > > 21193 ~ 5% -36.5% 13451 ~ 4% softirqs.SCHED
> > > > > > 2036 ~ 4% -59.4%825 ~ 3% vmstat.system.cs
> > > > > >1304520 ~ 4% -59.2% 532451 ~ 3%
> > > > > > perf-stat.context-switches
> > > > > > 95685 ~ 4% -44.0% 53598 ~ 2% perf-stat.cpu-migrations
> > > > >
> > > > > Glad it helped! IIRC, this same commit increased latencies due to
> > > > > synchronize_rcu() latency increasing. So this is the good side of
> > > > > that other not-so-good result. ;-)
> > > >
> > > > If you care it and there is a low cost way for user space to get that
> > > > synchronize_rcu() latency, I'd be eager to collect it in my tests. :)
> > >
> > > Would a kernel module that measured the latency be OK, or do you need
> > > some system call that is exposed to synchronize_rcu() latency?
> >
> > Kernel module should be good enough for me. Perhaps something like
> > kernel/latencytop.c?
>
> So you are looking for something that measures synchronize_rcu() latency
> for the synchronize_rcu() calls that occur naturally in the kernel, rather
> than having a focused microbenchmark?
Yes, then I can measure the synchronize_rcu() latency in all the tests
I run, including the possible focused microbenchmarks on RCU. :)
btw, I've measured the overheads of CONFIG_SCHEDSTATS which is
required for running latencytop, and it seems acceptable:
x86_64-lkp x86_64-lkp+CONFIG_SCHEDST
--- -
174190 ~ 0% -4.1% 167062 ~ 0%
lkp-snb01/micro/hackbench/1600%-threads-pipe
158995 ~ 1% -3.1% 154094 ~ 0%
lkp-snb01/micro/hackbench/1600%-threads-socket
333186 ~ 1% -3.6% 321156 ~ 0% TOTAL hackbench.throughput
x86_64-lkp x86_64-lkp+CONFIG_SCHEDST
--- -
278 ~ 0% -3.4%269 ~ 0%
lkp-a04/micro/netperf/120s-200%-TCP_MAERTS
632 ~ 1% -2.9%613 ~ 1%
lkp-a04/micro/netperf/120s-200%-TCP_SENDFILE
280 ~ 1% -3.7%270 ~ 0%
lkp-a04/micro/netperf/120s-200%-TCP_STREAM
1191 ~ 1% -3.2% 1153 ~ 1% TOTAL netperf.Throughput_Mbps
x86_64-lkp x86_64-lkp+CONFIG_SCHEDST
--- -
386 ~ 0% -2.1%378 ~ 0%
lkp-a04/micro/netperf/120s-200%-TCP_CRR
2057 ~ 0% -3.6% 1982 ~ 0%
lkp-a04/micro/netperf/120s-200%-TCP_RR
2518 ~ 0% -1.4% 2482 ~ 0%
lkp-a04/micro/netperf/120s-200%-UDP_RR
4962 ~ 0% -2.4% 4843 ~ 0% TOTAL netperf.Throughput_tps
x86_64-lkp x86_64-lkp+CONFIG_SCHEDST
--- -
37316711 ~ 0% -0.9% 36976450 ~ 0%
nhm-white/sysbench/oltp/600s-100%-100
37316711 ~ 0% -0.9% 36976450 ~ 0% TOTAL oltp.rw_requets
x86_64-lkp x86_64-lkp+CONFIG_SCHEDST
--- -
2665479 ~ 0% -0.9%2641175 ~ 0%
nhm-white/sysbench/oltp/600s-100%-100
2665479 ~ 0% -0.9%2641175 ~ 0% TOTAL oltp.transactions
x86_64-lkp x86_64-lkp+CONFIG_SCHEDST
--- -
68.50 ~ 0% -0.2% 68.39 ~ 0% xps2/micro/pigz/100%
68.50 ~ 0% -0.2% 68.39 ~ 0% TOTAL pigz.throughput
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: usbhid: quirk for CY-TM75 75 inch Touch Overlay
Hi,
On Mon, Jan 27, 2014 at 6:02 PM, Yufeng Shen wrote:
> There is timeout error during initialization:
> kernel: [ 11.733104] hid-multitouch 0003:1870:0110.0001:
> usb_submit_urb(ctrl) failed: -1
> kernel: [ 11.734093] hid-multitouch 0003:1870:0110.0001: timeout
> initializing reports
>
> Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.
Could you please test the quirk HID_QUIRK_NO_INIT_INPUT_REPORTS instead?
The patch is perfectly fine, but usually when it fails, only the input
reports are non-readable, whereas features should. This way, you will
still get the value of the features, which _may_ be sensible for the
maxcontact information.
BTW, HID_QUIRK_NO_INIT_INPUT_REPORTS has been introduced in v3.12 and
is the default for Win 8 certified devices.
Cheers,
Benjamin
>
> Signed-off-by: Yufeng Shen
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/usbhid/hid-quirks.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index f9304cb..ece2997 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -636,6 +636,7 @@
>
> #define USB_VENDOR_ID_NEXIO0x1870
> #define USB_DEVICE_ID_NEXIO_MULTITOUCH_420 0x010d
> +#define USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750 0x0110
>
> #define USB_VENDOR_ID_NEXTWINDOW 0x1926
> #define USB_DEVICE_ID_NEXTWINDOW_TOUCHSCREEN 0x0003
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 0db9a67..be5270a 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -74,6 +74,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28,
> HID_QUIRK_NOGET },
> { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN,
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1,
> HID_QUIRK_NO_INIT_REPORTS },
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" 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] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
> On 01/28/2014 08:32 AM, David Rientjes wrote:
> > On Wed, 22 Jan 2014, David Rientjes wrote:
> >
> >>> arch/x86/mm/numa.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> >>> index 81b2750..ebefeb7 100644
> >>> --- a/arch/x86/mm/numa.c
> >>> +++ b/arch/x86/mm/numa.c
> >>> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> >>> }
> >>> }
> >>>
> >>> +static nodemask_t numa_kernel_nodes __initdata;
> >>> static void __init numa_clear_kernel_node_hotplug(void)
> >>> {
> >>> int i, nid;
> >>> -nodemask_t numa_kernel_nodes;
> >>> unsigned long start, end;
> >>> struct memblock_type *type =&memblock.reserved;
> >>>
> >>
> >> Isn't this also a bugfix since you never initialize numa_kernel_nodes when
> >> it's allocated on the stack with NODE_MASK_NONE?
> >>
> >
> > This hasn't been answered and the patch still isn't in linux-kernel yet
> > Dave tested it as good. I'm suspicious of the changelog that indicates
> > this nodemask is the result of a stack overflow itself which only manages
> > to reproduce itself in the init patch slightly more than 50% of the time.
> > How is that possible?
> >
> > I think the changelog should indicate this also fixes an uninitialized
> > nodemask issue.
>
> Hi David,
>
> I'm still working on this problem, but unfortunately nothing new for now.
> And the test till now shows no more problem here.
>
> I'm digging into it, but need more time.
>
> I'll resend a new patch and modify the changelog soon. Before we find the
> root cause, I think we can use this patch as a temporary solution.
Ok, I hit the 2nd bug again (oops in next_zones_zonelist...)
I did a bisect with the patch above applied each step of the way.
This time I got a plausible looking result
a0acda917284183f9b71e2d08b0aa0aea722b321 is the first bad commit
commit a0acda917284183f9b71e2d08b0aa0aea722b321
Author: Tang Chen
Date: Tue Jan 21 15:49:32 2014 -0800
acpi, numa, mem_hotplug: mark all nodes the kernel resides un-hotpluggable
Reverting this commit of course removes the whole function from above,
so we haven't really learned anything new, other than that commit is broken,
even after the above fix-up.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] x86, mpx: extend siginfo structure to include bound violation information
On 01/28/2014 05:58 AM, Andy Lutomirski wrote: On 01/26/2014 01:08 AM, Qiaowei Ren wrote: (Why on earth does Intel not expose this stuff in cr2 or an MSR or something?) I guess it is due to some design reason. Thanks, Qiaowei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] mm, hugetlb: use vma_resv_map() map types
On Mon, 2014-01-27 at 16:03 -0500, Naoya Horiguchi wrote: > On Sun, Jan 26, 2014 at 07:52:23PM -0800, Davidlohr Bueso wrote: > > From: Joonsoo Kim > > > > Util now, we get a resv_map by two ways according to each mapping type. > > This makes code dirty and unreadable. Unify it. > > > > Reviewed-by: Aneesh Kumar K.V > > Signed-off-by: Joonsoo Kim > > Signed-off-by: Davidlohr Bueso > > Reviewed-by: Naoya Horiguchi > > There are a few small nitpicking below ... Will update, 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 3/8] mm, hugetlb: fix race in region tracking
On Mon, 2014-01-27 at 20:53 -0500, Naoya Horiguchi wrote:
> Hi Davidlohr,
>
> On Mon, Jan 27, 2014 at 01:44:02PM -0800, Davidlohr Bueso wrote:
> > On Mon, 2014-01-27 at 16:02 -0500, Naoya Horiguchi wrote:
> > > On Sun, Jan 26, 2014 at 07:52:21PM -0800, Davidlohr Bueso wrote:
> > > > From: Joonsoo Kim
> > > >
> > > > There is a race condition if we map a same file on different processes.
> > > > Region tracking is protected by mmap_sem and
> > > > hugetlb_instantiation_mutex.
> > > > When we do mmap, we don't grab a hugetlb_instantiation_mutex, but only
> > > > the,
> > > > mmap_sem (exclusively). This doesn't prevent other tasks from modifying
> > > > the
> > > > region structure, so it can be modified by two processes concurrently.
> > > >
> > > > To solve this, introduce a spinlock to resv_map and make region
> > > > manipulation
> > > > function grab it before they do actual work.
> > > >
> > > > Acked-by: David Gibson
> > > > Signed-off-by: Joonsoo Kim
> > > > [Updated changelog]
> > > > Signed-off-by: Davidlohr Bueso
> > > > ---
> > > ...
> > > > @@ -203,15 +200,23 @@ static long region_chg(struct resv_map *resv,
> > > > long f, long t)
> > > > * Subtle, allocate a new region at the position but make it
> > > > zero
> > > > * size such that we can guarantee to record the reservation. */
> > > > if (&rg->link == head || t < rg->from) {
> > > > - nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
> > > > - if (!nrg)
> > > > - return -ENOMEM;
> > > > + if (!nrg) {
> > > > + spin_unlock(&resv->lock);
> > >
> > > I think that doing kmalloc() inside the lock is simpler.
> > > Why do you unlock and retry here?
> >
> > This is a spinlock, no can do -- we've previously debated this and since
> > the critical region is quite small, a non blocking lock is better suited
> > here. We do the retry so we don't race once the new region is allocated
> > after the lock is dropped.
>
> Using spinlock instead of rw_sem makes sense.
> But I'm not sure how the retry is essential to fix the race.
> (Sorry I can't find the discussion log about this.)
> As you did in your ver.1 (https://lkml.org/lkml/2013/7/26/296),
> simply doing like below seems to be fine to me, is it right?
>
> if (&rg->link == head || t < rg->from) {
> nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
> if (!nrg) {
> chg = -ENOMEM;
> goto out_locked;
> }
> nrg->from = f;
> ...
> }
That's nice and simple because we were using the rwsem version.
>
> In the current version nrg is initialized to NULL, so we always do retry
> once when adding new file_region. That's not optimal to me.
Right, the retry can only occur once.
>
> If this retry is really essential for the fix, please comment the reason
> both in patch description and inline comment. It's very important for
> future code maintenance.
So we locate the corresponding region in the reserve map, and if we are
below the current region, then we allocate a new one. Since we dropped
the lock to allocate memory, we have to make sure that we still need the
new region and that we don't race with the new status of the reservation
map. This is the whole point of the retry, and I don't see it being
suboptimal.
We just cannot retake the lock after we get the new region and just add
it to to the list.
>
> And I noticed another point. I don't think the name of new goto label
> 'out_locked' is a good one. 'out_unlock' or 'unlock' is better.
What worries me more is that we're actually freeing a valid new region
(nrg) upon exit. We certainly don't do so in the current code, and it
doesn't seem to be a leak. Instead, we should be doing:
if (&rg->link == head || t < rg->from) {
if (!nrg) {
spin_unlock(&resv->lock);
nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
if (!nrg)
return -ENOMEM;
goto retry;
}
nrg->from = f;
nrg->to = f;
INIT_LIST_HEAD(&nrg->link);
list_add(&nrg->link, rg->link.prev);
chg = t - f;
goto out;
}
...
out:
spin_unlock(&resv->lock);
return chg;
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [lm-sensors] lm90 driver no longer working on PCs in 3.13
On 01/27/2014 03:58 PM, Mark Brown wrote:
On Mon, Jan 27, 2014 at 03:41:35PM -0800, Guenter Roeck wrote:
I'll test Mark's two patches on my system and let you know the results.
After looking some more into it, those _may_ actually fix the problem at least
for systems supporting ACPI. No promise, though, and I am not sure if that
would be sufficient (it may still not work on non-ACPI PCs). But then who
They should fix ACPI systems, if they don't we need to fix them further
- that case should just work, it was an oversight not to have a patch
like the ACPI one in already. I'm not sure how many non-ACPI PCs still
exist, we're definitely talking about things over 10 years old (even
before PCs became ACPI only they started to have ACPI present which
should be sufficient).
Jean, I'm doing a writeup but it's probably not going to be done today.
I confirmed that your two patches ("regulator: core: Correct default
return value for full constraints" and "ACPI: Flag use of ACPI and ACPI
idioms for power supplies to regulator API") together fix the problem
with the lm90 driver, at least for ACPI based systems.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev] [PATCH] f2fs: use inode mutex to keep atomicity of f2fs_falloc
Previously without protection of inode mutex, f2fs_falloc and other data correlated operations will interfere with each other. So let's use inode mutex to keep atomicity of f2fs_falloc. Signed-off-by: Chao Yu --- fs/f2fs/file.c |5 + 1 file changed, 5 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 85e91ca..ece380f 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -559,6 +559,8 @@ static long f2fs_fallocate(struct file *file, int mode, if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) return -EOPNOTSUPP; + mutex_lock(&inode->i_mutex); + if (mode & FALLOC_FL_PUNCH_HOLE) ret = punch_hole(inode, offset, len); else @@ -568,6 +570,9 @@ static long f2fs_fallocate(struct file *file, int mode, inode->i_mtime = inode->i_ctime = CURRENT_TIME; mark_inode_dirty(inode); } + + mutex_unlock(&inode->i_mutex); + trace_f2fs_fallocate(inode, mode, offset, len, ret); return ret; } -- 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/
[f2fs-dev] [PATCH] f2fs: introduce ra_meta_pages to readahead CP/NAT/SIT pages
This patch help us to cleanup the readahead code by merging ra_{sit,nat}_pages
function into ra_meta_pages.
Additionally the new function is used to readahead cp block in
recover_orphan_inodes.
Signed-off-by: Chao Yu
---
fs/f2fs/checkpoint.c | 78 ++
fs/f2fs/f2fs.h | 10 +++
fs/f2fs/node.c | 38 +---
fs/f2fs/segment.c| 43 +---
4 files changed, 90 insertions(+), 79 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 293d048..a1986c3 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -75,6 +75,82 @@ out:
return page;
}
+inline int get_max_meta_blks(struct f2fs_sb_info *sbi, int type)
+{
+ switch (type) {
+ case META_NAT:
+ return NM_I(sbi)->max_nid / NAT_ENTRY_PER_BLOCK;
+ case META_SIT:
+ return SIT_BLK_CNT(sbi);
+ case META_CP:
+ return 0;
+ default:
+ BUG();
+ }
+}
+
+/*
+ * Readahead CP/NAT/SIT pages
+ */
+int ra_meta_pages(struct f2fs_sb_info *sbi, int start, int nrpages, int type)
+{
+ struct address_space *mapping = sbi->meta_inode->i_mapping;
+ struct page *page;
+ block_t blk_addr, prev_blk_addr = 0;
+ int blkno = start;
+ int max_blks = get_max_meta_blks(sbi, type);
+
+ struct f2fs_io_info fio = {
+ .type = META,
+ .rw = READ_SYNC | REQ_META | REQ_PRIO
+ };
+
+ for (blkno = start; blkno < start + nrpages; blkno++) {
+
+ switch (type) {
+ case META_NAT:
+ /* get nat block addr */
+ if (unlikely(blkno >= max_blks))
+ blkno = 0;
+ blk_addr = current_nat_addr(sbi,
+ blkno * NAT_ENTRY_PER_BLOCK);
+ break;
+ case META_SIT:
+ /* get sit block addr */
+ if (unlikely(blkno >= max_blks))
+ goto out;
+ blk_addr = current_sit_addr(sbi,
+ blkno * SIT_ENTRY_PER_BLOCK);
+ if (blkno != start && prev_blk_addr + 1 != blk_addr)
+ goto out;
+ prev_blk_addr = blk_addr;
+ break;
+ case META_CP:
+ /* get cp block addr */
+ blk_addr = blkno;
+ break;
+ default:
+ BUG();
+ }
+
+ page = grab_cache_page(mapping, blk_addr);
+ if (!page)
+ continue;
+ if (PageUptodate(page)) {
+ mark_page_accessed(page);
+ f2fs_put_page(page, 1);
+ continue;
+ }
+
+ f2fs_submit_page_mbio(sbi, page, blk_addr, &fio);
+ mark_page_accessed(page);
+ f2fs_put_page(page, 0);
+ }
+out:
+ f2fs_submit_merged_bio(sbi, META, READ);
+ return blkno - start;
+}
+
static int f2fs_write_meta_page(struct page *page,
struct writeback_control *wbc)
{
@@ -285,6 +361,8 @@ void recover_orphan_inodes(struct f2fs_sb_info *sbi)
start_blk = __start_cp_addr(sbi) + 1;
orphan_blkaddr = __start_sum_addr(sbi) - 1;
+ ra_meta_pages(sbi, start_blk, orphan_blkaddr, META_CP);
+
for (i = 0; i < orphan_blkaddr; i++) {
struct page *page = get_meta_page(sbi, start_blk + i);
struct f2fs_orphan_block *orphan_blk;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index af51a0b..69ffc1b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -88,6 +88,15 @@ enum {
SIT_BITMAP
};
+/*
+ * For CP/NAT/SIT readahead
+ */
+enum {
+ META_CP,
+ META_NAT,
+ META_SIT
+};
+
/* for the list of orphan inodes */
struct orphan_inode_entry {
struct list_head list; /* list head */
@@ -1158,6 +1167,7 @@ void destroy_segment_manager_caches(void);
*/
struct page *grab_meta_page(struct f2fs_sb_info *, pgoff_t);
struct page *get_meta_page(struct f2fs_sb_info *, pgoff_t);
+int ra_meta_pages(struct f2fs_sb_info *, int, int, int);
long sync_meta_pages(struct f2fs_sb_info *, enum page_type, long);
int acquire_orphan_inode(struct f2fs_sb_info *);
void release_orphan_inode(struct f2fs_sb_info *);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b0649b7..2f7ae6f 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -82,42 +82,6 @@ static struct page *get_next_nat_page(struct f2fs_sb_info
*sbi, nid_t nid)
return dst_page;
}
-/*
- * Readahead NAT pages
- */
-static void ra_nat_pages(struct f2fs_sb_info *sbi, int nid)
-{
- struct address_space *mapping = META_MAPPING(sbi);
- struct
Re: [RFC][PATCH] module: allow multiple calls to MODULE_DEVICE_TABLE() per module
Greg Kroah-Hartman writes:
> On Mon, Jan 27, 2014 at 08:09:55PM +0100, Tom Gundersen wrote:
>> Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where
>> the
>> second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
>> the modaliases being exposed.
>>
>> This fixes the problem by including the name of the device_id table in the
>> __mod_*_device_table alias, allowing us to export several device_id tables
>> per module.
>>
>> Suggested-by: Kay Sievers
>> Cc: Dmitry Torokhov
>> Cc: Greg Kroah-Hartman
>> Cc: Rusty Russell
>> ---
>> include/linux/module.h | 2 +-
>> scripts/mod/file2alias.c | 14 +-
>> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> Ah, very nice, I've wanted this for a while now, it would make a number
> of different drivers much smaller and simpler to add new device ids to
> (no multiple lists of ids, one for the module loader and one for the
> sub-driver that is in the single file.)
You never asked :(
I've applied, this, but I'm actually amazed this patch works. C is
weird sometimes. It changes declarations of the form:
extern const struct pci_device_id __mod_pci_device_id_table
__attribute__ ((unused, alias("e1000_pci_tbl"));
Into:
extern const struct pci__e1000_pci_tbl_device_id
__mod_pci__e1000_pci_tbl_device_id_table
__attribute__ ((unused, alias("e1000_pci_tbl"));
Now, that's a completely unknown type, but gcc doesn't care because it's
just an extern declaration. It does insert the alias, which is all we
care about.
We would normally use a special section for this, so it's mainly
historical. Now we have DEFINE_PCI_DEVICE_TABLE etc, we should
use those to put it in a special section (eg. "pci_ids") and
grab that directly.
Volunteers welcome :)
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] module: allow multiple calls to MODULE_DEVICE_TABLE() per module
Tom Gundersen writes:
> Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where the
> second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
> the modaliases being exposed.
No Signed-off-by?
Thanks,
Rusty.
>
> This fixes the problem by including the name of the device_id table in the
> __mod_*_device_table alias, allowing us to export several device_id tables
> per module.
>
> Suggested-by: Kay Sievers
> Cc: Dmitry Torokhov
> Cc: Greg Kroah-Hartman
> Cc: Rusty Russell
> ---
> include/linux/module.h | 2 +-
> scripts/mod/file2alias.c | 14 +-
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 15cd6b1..7732d76 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -143,7 +143,7 @@ extern const struct gtype##_id __mod_##gtype##_table
> \
> #define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
> _description)
>
> #define MODULE_DEVICE_TABLE(type,name) \
> - MODULE_GENERIC_TABLE(type##_device,name)
> + MODULE_GENERIC_TABLE(type##__##name##_device,name)
>
> /* Version of form [:][-].
> Or for CVS/RCS ID version, everything but the number is stripped.
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 2370863..6778381 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -42,7 +42,7 @@ typedef unsigned char __u8;
>
> /* This array collects all instances that use the generic do_table */
> struct devtable {
> - const char *device_id; /* name of table, __mod__device_table. */
> + const char *device_id; /* name of table, __mod___*_device_table.
> */
> unsigned long id_size;
> void *function;
> };
> @@ -146,7 +146,8 @@ static void device_id_check(const char *modname, const
> char *device_id,
>
> if (size % id_size || size < id_size) {
> fatal("%s: sizeof(struct %s_device_id)=%lu is not a modulo "
> - "of the size of section __mod_%s_device_table=%lu.\n"
> + "of the size of "
> + "section __mod_%s___device_table=%lu.\n"
> "Fix definition of struct %s_device_id "
> "in mod_devicetable.h\n",
> modname, device_id, id_size, device_id, size, device_id);
> @@ -1206,7 +1207,7 @@ void handle_moddevtable(struct module *mod, struct
> elf_info *info,
> {
> void *symval;
> char *zeros = NULL;
> - const char *name;
> + const char *name, *identifier;
> unsigned int namelen;
>
> /* We're looking for a section relative symbol */
> @@ -1217,7 +1218,7 @@ void handle_moddevtable(struct module *mod, struct
> elf_info *info,
> if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
> return;
>
> - /* All our symbols are of form __mod_XXX_device_table. */
> + /* All our symbols are of form
> __moddevice_table. */
> name = strstr(symname, "__mod_");
> if (!name)
> return;
> @@ -1227,7 +1228,10 @@ void handle_moddevtable(struct module *mod, struct
> elf_info *info,
> return;
> if (strcmp(name + namelen - strlen("_device_table"), "_device_table"))
> return;
> - namelen -= strlen("_device_table");
> + identifier = strstr(name, "__");
> + if (!identifier)
> + return;
> + namelen = identifier - name;
>
> /* Handle all-NULL symbols allocated into .bss */
> if (info->sechdrs[get_secindex(info, sym)].sh_type & SHT_NOBITS) {
> --
> 1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[V0 PATCH] pvh: Disable PSE feature for now
Until now, xen did not expose PSE to pvh guest, but a patch was submitted to xen list to enable bunch of features for a pvh guest. PSE has not been looked into for PVH, so until we can do that and test it to make sure it works, disable the feature to avoid flood of bugs. Signed-off-by: Mukesh Rathor --- arch/x86/xen/enlighten.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index a4d7b64..4e952046 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1497,6 +1497,11 @@ static void __init xen_pvh_early_guest_init(void) xen_have_vector_callback = 1; xen_pvh_set_cr_flags(0); +/* pvh guests are not quite ready for large pages yet */ +setup_clear_cpu_cap(X86_FEATURE_PSE); +setup_clear_cpu_cap(X86_FEATURE_PSE36); + + #ifdef CONFIG_X86_32 BUG(); /* PVH: Implement proper support. */ #endif -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pvh: disable pse feature for now
Konrad, Following will turn off PSE in linux until we can get to it. It's better to turn it off here than in xen, so if BSD gets there sooner, they are not dependent on us. thanks Mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio_balloon: don't call virtio_has_feature() twice on init_vqs()
Hi Rusty,
On Tue, Jan 28, 2014 at 10:48:31AM +1030, Rusty Russell wrote:
> Leandro Dorileo writes:
> > Cchange init_vqs() to avoid calling twice the virtio_has_feature()
> > - attempting to find out if VIRTIO_BALLOON_F_STATS_VQ feature was
> > negotiated -
> > consequently we prevent unnecessarily running the drivers' feature_table
> > more
> > than needed.
> >
> > Signed-off-by: Leandro Dorileo
>
> Hi Leandro,
>
> This seems like a premature optimization. The current code is
> fairly clear, and there's no performance issue with init_vqs.
>
Indeed, rethinking the patch and reviewing the code path it seems to be no gain,
It's just called on probe and restore operations. As you said a premature
optimization.
Thanks...
> Am I missing something?
> Rusty.
>
> > ---
> > drivers/virtio/virtio_balloon.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_balloon.c
> > b/drivers/virtio/virtio_balloon.c
> > index 34bdaba..41771c1 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -320,19 +320,21 @@ static int init_vqs(struct virtio_balloon *vb)
> > vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request
> > };
> > const char *names[] = { "inflate", "deflate", "stats" };
> > int err, nvqs;
> > + bool stats;
> >
> > /*
> > * We expect two virtqueues: inflate and deflate, and
> > * optionally stat.
> > */
> > - nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2;
> > + stats = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ);
> > + nvqs = stats ? 3 : 2;
> > err = vb->vdev->config->find_vqs(vb->vdev, nvqs, vqs, callbacks, names);
> > if (err)
> > return err;
> >
> > vb->inflate_vq = vqs[0];
> > vb->deflate_vq = vqs[1];
> > - if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > + if (stats) {
> > struct scatterlist sg;
> > vb->stats_vq = vqs[2];
> >
> > --
> > 1.8.5.3
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Leandro Dorileo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
On Mon, Jan 27, 2014 at 4:55 PM, Bjorn Helgaas wrote:
> We're only seeing Arnd's side of the conversation on linux-pci.
> Tanmay, are your messages being rejected because they're too "fancy",
> per the definition here: http://vger.kernel.org/majordomo-info.html ?
>
Thanks for pointing out. I am not sure though what's being detected as
fancy. I checked that my emails are received as plaintext on
majordomo. They are also displayed fine on LKML.
In this email, I have tried to keep the format of to: and cc: same as
first email in the thread. Not sure if this fixes the problem.
Again.. sorry for spamming.
> On Sat, Jan 25, 2014 at 1:11 PM, Arnd Bergmann wrote:
>> On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
>>> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar wrote:
>>> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann wrote:
>>> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
>>
>>> >>
>>> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32
>>> >>> *lanes)
>>> >>> +{
>>> >>> + void *csr_base = port->csr_base;
>>> >>> + u32 val32;
>>> >>> + u64 start_time, time;
>>> >>> +
>>> >>> + /*
>>> >>> + * A component enters the LTSSM Detect state within
>>> >>> + * 20ms of the end of fundamental core reset.
>>> >>> + */
>>> >>> + msleep(XGENE_LTSSM_DETECT_WAIT);
>>> >>> + port->link_up = 0;
>>> >>> + start_time = jiffies;
>>> >>> + do {
>>> >>> + val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
>>> >>> + if (val32 & LINK_UP_MASK) {
>>> >>> + port->link_up = 1;
>>> >>> + port->link_speed = PIPE_PHY_RATE_RD(val32);
>>> >>> + val32 = readl(csr_base + BRIDGE_STATUS_0);
>>> >>> + *lanes = val32 >> 26;
>>> >>> + }
>>> >>> + time = jiffies_to_msecs(jiffies - start_time);
>>> >>> + } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
>>> >>> +}
>>> >>
>>> >> Maybe another msleep() in the loop? It seems weird to first do an
>>> >> unconditional sleep but then busy-wait for the result.
>>> >
>>> > ok.
>>>
>>> This loop can execute for maximum 4 msec. So putting msleep(1) won't
>>> get us much.
>>
>> 4 msec is still quite a long time for a busy loop that can be spent doing
>> useful work in another thread.
>>
>>> >>
>>> >> Another general note: Your "compatible" strings are rather unspecific.
>>> >> Do you have a version number for this IP block? I suppose that it's
>>> >> related
>>> >> to one that has been used in other chips before, or will be used in
>>> >> future
>>> >> chips, if it's not actually licensed from some other company.
>>> >
>>> > I will have to check this.
>>> >
>>>
>>> We have decided to stick with current compatible string for now.
>>
>> Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
>> product and you won't be doing any new chips based on the same hardware
>> components?
>>
>> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/21] pinctrl: mvebu: restructure and remove hardcoded addresses from Dove pinctrl
This patch set is one required step for Dove to hop into mach-mvebu. Until now, pinctrl-dove was hardcoding some registers that do not directly belong to MPP core registers. This is not compatible with what we want for mach-mvebu. Unfortunately, the common pinctrl driver part has a design flaw, that requires some restructuring. As Thomas pointed out, the redesign taken in v1 [1] is not sufficient for possible future Orion5x SoC pinctrl. The "common" part of the patch set therefore, overhawls MVEBU pinctrl to remove any register mangling from the common pinctrl driver and moves it into SoC specific drivers instead. The "Dove" part of the patch set removes all hardcoded addresses from pinctrl-dove by either requesting additional resources or a syscon provided regmap for global config registers. As this changes existing driver to DT binding relationship, all additional resources are probed in a backward compatible way. If the corresponding resource cannot be found, we derive it from the existing pinctrl resource and warn about the old DTB firmware. Patches 1 to 4 remain unchanged: Patch 1 and 2 add or update binding documentation for dove, global config syscon, and pinctrl-dove. The latter also documents missing reg property requirement for other mvebu pinctrl nodes. Patch 3 and 4 add the new pinctrl reg property values and global config register syscon to exisiting dove.dtsi. Patches 5-8 now prepare to fix the misdesign of common mvebu pinctrl driver, that requested the resource instead of getting it from the SoC specific driver stub: Patch 5 temporarily adds passing the base address the common driver and moves resource requests to the SoC specific drivers. Patch 6 adds some useful mask/shift defines. Patches 7 and 8 allow to identify mpp pin ranges by NULL mpp name instead of special get/set callbacks. Patches 9-12 provide SoC specific callbacks for mpp ctrl registers even if they match the standard layout. This then allows patches 13 and 14 to get rid of base addresses and the temporary address passing. Patches 15-20 comprise the rebased hardcoded address removal for Dove from v1. Patch 21 finally consolidates Dove pmu mpp definition by exploiting auto-numbering of mpp names. The patch set is still based on pre-v3.14-rc1 mainline. It has been boot tested on Dove and compile tested only for Kirkwood, Armada 370 and XP. [1] https://lkml.org/lkml/2014/1/25/131 Sebastian Hesselbarth (21): devicetree: bindings: add missing Marvell Dove SoC documentation devicetree: bindings: update MVEBU pinctrl binding documentation ARM: dove: add additional pinctrl registers ARM: dove: add global-config register node pinctrl: mvebu: prepare to fix misdesigned resource allocation pinctrl: mvebu: add common mpp reg defines to mvebu pinctrl include pinctrl: mvebu: move generic group name generation pinctrl: mvebu: remove checks for mpp_get/set pinctrl: mvebu: dove: provide generic mpp callbacks pinctrl: mvebu: kirkwood: provide generic mpp callbacks pinctrl: mvebu: armada-370: provide generic mpp callbacks pinctrl: mvebu: armada-xp: provide generic mpp callbacks pinctrl: mvebu: remove unused macros and functions pinctrl: mvebu: remove base address from common driver pinctrl: mvebu: dove: request additional resources pinctrl: mvebu: dove: request syscon regmap for global registers pinctrl: mvebu: dove: use remapped mpp base registers pinctrl: mvebu: dove: use remapped mpp4 register pinctrl: mvebu: dove: use remapped pmu_mpp registers pinctrl: mvebu: dove: use global register regmap pinctrl: mvebu: dove: consolidate auto-numbered pmu mpp ranges .../devicetree/bindings/arm/marvell,dove.txt | 22 ++ .../pinctrl/marvell,armada-370-pinctrl.txt | 1 + .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt | 1 + .../bindings/pinctrl/marvell,dove-pinctrl.txt | 1 + .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt | 1 + .../bindings/pinctrl/marvell,mvebu-pinctrl.txt | 2 +- arch/arm/boot/dts/dove.dtsi| 10 +- drivers/pinctrl/mvebu/Kconfig | 1 + drivers/pinctrl/mvebu/pinctrl-armada-370.c | 34 +- drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 38 ++- drivers/pinctrl/mvebu/pinctrl-dove.c | 374 + drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 39 ++- drivers/pinctrl/mvebu/pinctrl-mvebu.c | 94 +- drivers/pinctrl/mvebu/pinctrl-mvebu.h | 16 +- 14 files changed, 388 insertions(+), 246 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/marvell,dove.txt --- Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Thomas Petazzoni Cc: Russell King Cc: Linus Walleij Cc: devicet...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bo
[PATCH v2 07/21] pinctrl: mvebu: move generic group name generation
MVEBU SoC pinctrl allows SoC specific drivers to pass a range of mpp
pins without a corresponding name. Each pin in this range is then
translated into a single-pin group with an auto-generated name. To allow
some redesign of the driver, move name generation for those pin ranges
down to where the groups are created.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Linus Walleij
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 90c35b20a7af..375666b0abc3 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -631,7 +631,6 @@ int mvebu_pinctrl_probe(struct platform_device *pdev, void
__iomem *base)
pctl->desc.npins = 0;
for (n = 0; n < soc->ncontrols; n++) {
struct mvebu_mpp_ctrl *ctrl = &soc->controls[n];
- char *names;
pctl->desc.npins += ctrl->npins;
/* initial control pins */
@@ -649,14 +648,6 @@ int mvebu_pinctrl_probe(struct platform_device *pdev, void
__iomem *base)
}
/* generic mvebu register control */
- names = devm_kzalloc(&pdev->dev, ctrl->npins * 8, GFP_KERNEL);
- if (!names) {
- dev_err(&pdev->dev, "failed to alloc mpp names\n");
- return -ENOMEM;
- }
- for (k = 0; k < ctrl->npins; k++)
- sprintf(names + 8*k, "mpp%d", ctrl->pid+k);
- ctrl->name = names;
pctl->num_groups += ctrl->npins;
}
@@ -689,7 +680,18 @@ int mvebu_pinctrl_probe(struct platform_device *pdev, void
__iomem *base)
pctl->groups[gid].npins = ctrl->npins;
/* generic mvebu register control maps to a number of groups */
- if (!ctrl->mpp_get && !ctrl->mpp_set) {
+ if (!ctrl->name) {
+ char *names = devm_kzalloc(&pdev->dev,
+ ctrl->npins * 8, GFP_KERNEL);
+ if (!names) {
+ dev_err(&pdev->dev, "failed to alloc mpp
names\n");
+ return -ENOMEM;
+ }
+ for (k = 0; k < ctrl->npins; k++)
+ sprintf(names + 8*k, "mpp%d", ctrl->pid+k);
+ ctrl->name = names;
+
+ pctl->groups[gid].name = &ctrl->name[0];
pctl->groups[gid].npins = 1;
for (k = 1; k < ctrl->npins; k++) {
--
1.8.5.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/
Re: [PATCH 3/8] mm, hugetlb: fix race in region tracking
Hi Davidlohr,
On Mon, Jan 27, 2014 at 01:44:02PM -0800, Davidlohr Bueso wrote:
> On Mon, 2014-01-27 at 16:02 -0500, Naoya Horiguchi wrote:
> > On Sun, Jan 26, 2014 at 07:52:21PM -0800, Davidlohr Bueso wrote:
> > > From: Joonsoo Kim
> > >
> > > There is a race condition if we map a same file on different processes.
> > > Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex.
> > > When we do mmap, we don't grab a hugetlb_instantiation_mutex, but only
> > > the,
> > > mmap_sem (exclusively). This doesn't prevent other tasks from modifying
> > > the
> > > region structure, so it can be modified by two processes concurrently.
> > >
> > > To solve this, introduce a spinlock to resv_map and make region
> > > manipulation
> > > function grab it before they do actual work.
> > >
> > > Acked-by: David Gibson
> > > Signed-off-by: Joonsoo Kim
> > > [Updated changelog]
> > > Signed-off-by: Davidlohr Bueso
> > > ---
> > ...
> > > @@ -203,15 +200,23 @@ static long region_chg(struct resv_map *resv, long
> > > f, long t)
> > >* Subtle, allocate a new region at the position but make it zero
> > >* size such that we can guarantee to record the reservation. */
> > > if (&rg->link == head || t < rg->from) {
> > > - nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
> > > - if (!nrg)
> > > - return -ENOMEM;
> > > + if (!nrg) {
> > > + spin_unlock(&resv->lock);
> >
> > I think that doing kmalloc() inside the lock is simpler.
> > Why do you unlock and retry here?
>
> This is a spinlock, no can do -- we've previously debated this and since
> the critical region is quite small, a non blocking lock is better suited
> here. We do the retry so we don't race once the new region is allocated
> after the lock is dropped.
Using spinlock instead of rw_sem makes sense.
But I'm not sure how the retry is essential to fix the race.
(Sorry I can't find the discussion log about this.)
As you did in your ver.1 (https://lkml.org/lkml/2013/7/26/296),
simply doing like below seems to be fine to me, is it right?
if (&rg->link == head || t < rg->from) {
nrg = kmalloc(sizeof(*nrg), GFP_KERNEL);
if (!nrg) {
chg = -ENOMEM;
goto out_locked;
}
nrg->from = f;
...
}
In the current version nrg is initialized to NULL, so we always do retry
once when adding new file_region. That's not optimal to me.
If this retry is really essential for the fix, please comment the reason
both in patch description and inline comment. It's very important for
future code maintenance.
And I noticed another point. I don't think the name of new goto label
'out_locked' is a good one. 'out_unlock' or 'unlock' is better.
Thanks,
Naoya Horiguchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Fixed some coding style problems
On Mon, 2014-01-27 at 19:43 -0600, Brandon Stewart wrote:
[]
> diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
[]
> @@ -624,8 +623,7 @@ do_adb_query(struct adb_request *req)
> {
> int ret = -EINVAL;
>
> - switch(req->data[1])
> - {
> + switch(req->data[1]) {
switch (req->data[1]) {
> @@ -794,8 +792,8 @@ static ssize_t adb_write(struct file *file, const char
> __user *buf,
> }
> /* Special case for ADB_BUSRESET request, all others are sent to
> the controller */
> - else if ((req->data[0] == ADB_PACKET)&&(count > 1)
> - &&(req->data[1] == ADB_BUSRESET)) {
> + else if ((req->data[0] == ADB_PACKET) && (count > 1)
> + && (req->data[1] == ADB_BUSRESET)) {
else if (req->data[0] == ADB_PACKET &&
req->data[1] == ADB_BUSRESET &&
count > 1) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Fixed some coding style problems
Signed-off-by: Brandon Stewart
---
drivers/macintosh/adb.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
index 04a5049..53611de 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -38,7 +38,7 @@
#include
#include
-#include
+#include
#ifdef CONFIG_PPC
#include
#include
@@ -193,8 +193,7 @@ static int adb_scan_bus(void)
break;
noMovement = 0;
- }
- else {
+ } else {
/*
* No devices left at address i; move the
* one(s) we moved to `highFree' back to i.
@@ -502,7 +501,7 @@ void
adb_input(unsigned char *buf, int nb, int autopoll)
{
int i, id;
- static int dump_adb_input = 0;
+ static int dump_adb_input;
unsigned long flags;
void (*handler)(unsigned char *, int, int);
@@ -624,8 +623,7 @@ do_adb_query(struct adb_request *req)
{
int ret = -EINVAL;
- switch(req->data[1])
- {
+ switch(req->data[1]) {
case ADB_QUERY_GETDEVINFO:
if (req->nbytes < 3)
break;
@@ -697,7 +695,7 @@ static ssize_t adb_read(struct file *file, char __user *buf,
int ret = 0;
struct adbdev_state *state = file->private_data;
struct adb_request *req;
- DECLARE_WAITQUEUE(wait,current);
+ DECLARE_WAITQUEUE(wait, current);
unsigned long flags;
if (count < 2)
@@ -794,8 +792,8 @@ static ssize_t adb_write(struct file *file, const char
__user *buf,
}
/* Special case for ADB_BUSRESET request, all others are sent to
the controller */
- else if ((req->data[0] == ADB_PACKET)&&(count > 1)
- &&(req->data[1] == ADB_BUSRESET)) {
+ else if ((req->data[0] == ADB_PACKET) && (count > 1)
+ && (req->data[1] == ADB_BUSRESET)) {
ret = do_adb_reset_bus();
up(&adb_probe_mutex);
atomic_dec(&state->n_pending);
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] LED updates for 3.14
Hi Linus
Basically this cycle is most cleanup for LED subsystem.
Please consider the following changes since commit
802eee95bde72fd0cd0f3a5b2098375a487d1eda:
Linux 3.13-rc6 (2013-12-29 16:01:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for-next
for you to fetch changes up to 3cb6f44aedf519dce4a9106dec675b94d675c539:
leds: s3c24xx: Remove hardware.h inclusion (2014-01-27 17:28:53 -0800)
Alexander Shiyan (2):
leds: leds-mc13783: Remove duplicate field in platform data
leds: leds-mc13783: Remove unneeded mc13xxx_{un}lock
Chen Gang (1):
drivers: leds: leds-tca6507: check CONFIG_GPIOLIB whether
defined for 'gpio_base'
Milo Kim (2):
leds: lp5521/5523: Fix multiple engine usage bug
leds: lp5523: Support LED MUX configuration on running a pattern
NeilBrown (3):
LEDS: tca6507 - fix bugs in parsing of device-tree configuration.
LEDS: tca6507: add device-tree support for GPIO configuration.
LEDS: tca6507 - fix up some comments.
Olof Johansson (1):
leds: pwm: Remove a warning on non-DT platforms
Sachin Kamat (2):
leds: kirkwood: Cleanup in header files
leds: s3c24xx: Remove hardware.h inclusion
Xiubo Li (1):
leds: leds-pwm: fix duty time overflow.
ZHAO Gang (1):
leds: replace list_for_each with list_for_each_entry
Documentation/devicetree/bindings/leds/tca6507.txt | 16 ++
Documentation/leds/leds-lp55xx.txt | 10 +-
arch/arm/mach-imx/mach-mx31moboard.c | 16 +-
drivers/leds/led-triggers.c| 15 +-
drivers/leds/leds-lp5521.c | 18 +-
drivers/leds/leds-lp5523.c | 20 +-
drivers/leds/leds-lp55xx-common.c | 2 +
drivers/leds/leds-mc13783.c| 89 +
drivers/leds/leds-pwm.c| 9 +-
drivers/leds/leds-s3c24xx.c| 3 +-
drivers/leds/leds-tca6507.c| 207 -
include/linux/mfd/mc13xxx.h| 37 +++-
.../linux/platform_data/leds-kirkwood-netxbig.h| 8 +-
include/linux/platform_data/leds-kirkwood-ns2.h| 8 +-
14 files changed, 227 insertions(+), 231 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: bcm281xx: Use "unsigned gpio" consistently throughout the code
This patch removes some inconsistencies caused by the use of "int gpio"
in some parts of the code and "unsigned gpio" in others.
Signed-off-by: Markus Mayer
Reviewed-by: Tim Kryger
---
drivers/gpio/gpio-bcm-kona.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index e5aa4d0..b4f20f7 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -323,7 +323,7 @@ static void bcm_kona_gpio_irq_ack(struct irq_data *d)
{
struct bcm_kona_gpio *kona_gpio;
void __iomem *reg_base;
- int gpio = d->hwirq;
+ unsigned gpio = d->hwirq;
int bank_id = GPIO_BANK(gpio);
int bit = GPIO_BIT(gpio);
u32 val;
@@ -344,7 +344,7 @@ static void bcm_kona_gpio_irq_mask(struct irq_data *d)
{
struct bcm_kona_gpio *kona_gpio;
void __iomem *reg_base;
- int gpio = d->hwirq;
+ unsigned gpio = d->hwirq;
int bank_id = GPIO_BANK(gpio);
int bit = GPIO_BIT(gpio);
u32 val;
@@ -365,7 +365,7 @@ static void bcm_kona_gpio_irq_unmask(struct irq_data *d)
{
struct bcm_kona_gpio *kona_gpio;
void __iomem *reg_base;
- int gpio = d->hwirq;
+ unsigned gpio = d->hwirq;
int bank_id = GPIO_BANK(gpio);
int bit = GPIO_BIT(gpio);
u32 val;
@@ -386,7 +386,7 @@ static int bcm_kona_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
{
struct bcm_kona_gpio *kona_gpio;
void __iomem *reg_base;
- int gpio = d->hwirq;
+ unsigned gpio = d->hwirq;
u32 lvl_type;
u32 val;
unsigned long flags;
--
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] [RESEND] wistron_btns: FS AMILO Pro 8210 support
Hi Jakub,
On Tue, Jul 02, 2013 at 05:20:48PM +0200, Jakub Bogusz wrote:
> (sorry, I forgot to attach the actual patch in my previous message)
>
> Hello,
>
> The attached patch adds Fujitsu-Siemens AMILO Pro 8210 support to
> wistron_btns driver.
>
> I already sent it in 2011, but there was no feedback.
> It still applies to linux 3.10 sources.
I just stumbled upon your patch in my LKML archives. It looks quite
reasonable, I will be applying it.
Thanks.
>
>
> --
> Jakub Boguszhttp://qboosh.pl/
> This patch adds Fujitsu-Siemens AMILO Pro 8210 support to wistron_btns driver.
>
> Functions are very similar to already supported AMILO Pro 3505, but 8210
> has WIFI led.
>
> Such functionality is needed to enable WiFi under Linux on 8210 when it cold
> boots with hardware rfkill enabled, without booting another operating system
> or running custom utility that calls appropriate BIOS function.
>
> Signed-off-by: Jakub Bogusz
>
> --- linux-2.6.37/drivers/input/misc/wistron_btns.c.orig 2011-01-05
> 01:50:19.0 +0100
> +++ linux-2.6.37/drivers/input/misc/wistron_btns.c2011-02-19
> 07:51:36.0 +0100
> @@ -278,6 +278,16 @@
> { KE_END, 0 }
> };
>
> +static struct key_entry keymap_fs_amilo_pro_v8210[] __initdata = {
> + { KE_KEY, 0x01, {KEY_HELP} }, /* Fn+F1 */
> + { KE_KEY, 0x06, {KEY_DISPLAYTOGGLE} }, /* Fn+F4 */
> + { KE_BLUETOOTH, 0x30 }, /* Fn+F10 */
> + { KE_KEY, 0x31, {KEY_MAIL} }, /* mail button */
> + { KE_KEY, 0x36, {KEY_WWW} }, /* www button */
> + { KE_WIFI, 0x78 }, /* satelite dish button */
> + { KE_END, FE_WIFI_LED }
> +};
> +
> static struct key_entry keymap_fujitsu_n3510[] __initdata = {
> { KE_KEY, 0x11, {KEY_PROG1} },
> { KE_KEY, 0x12, {KEY_PROG2} },
> @@ -655,6 +665,15 @@
> .driver_data = keymap_fs_amilo_pro_v3505
> },
> {
> + /* Fujitsu-Siemens Amilo Pro Edition V8210 */
> + .callback = dmi_matched,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pro Series V8210"),
> + },
> + .driver_data = keymap_fs_amilo_pro_v8210
> + },
> + {
> /* Fujitsu-Siemens Amilo M7400 */
> .callback = dmi_matched,
> .matches = {
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/4] x86: intel-mid: add Merrifield platform support
Hi Bjorn, On Mon, Jan 27, 2014 at 05:52:30PM -0700, Bjorn Helgaas wrote: > On Mon, Dec 16, 2013 at 1:07 PM, David Cohen > wrote: > > This code was partially based on Mark Brown's previous work. > > > > Signed-off-by: David Cohen > > Signed-off-by: Fei Yang > > Cc: Mark F. Brown > > Cc: Kuppuswamy Sathyanarayanan > > I know this has already been merged to Linus' tree, but it looks funny to me. > > > --- a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > > +++ b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h > > @@ -16,3 +16,4 @@ > > */ > > extern void * __cpuinit get_penwell_ops(void) __attribute__((weak)); > > extern void * __cpuinit get_cloverview_ops(void) __attribute__((weak)); > > +extern void * __init get_tangier_ops(void) __attribute__((weak)); > > We should use "__weak" instead of the gcc-specific "__attribute__((weak))". > > I don't think it's a good idea to use __weak on a declaration in a > header file. If there are ever multiple definitions of the symbol, > they are *all* made weak symbols, and one is chosen based on link > order, which is error-prone. I only see one definition now, but the > whole point of weak is to allow multiple definitions, so this looks > like a problem waiting to happen. See 10629d711ed, for example. > > It look me a bit to figure out that these get_*_ops() functions are > used by INTEL_MID_OPS_INIT, which constructs the name using a macro, > so grep/cscope/etc. don't see any users. A comment pointing to > INTEL_MID_OPS_INIT would be helpful. > > What's the reason for making these symbols weak? Normally we use weak > to make a generic default version of a function, while allowing > architectures to replace the default with their own version if > necessary. But I don't see that happening here. Maybe I'm just > missing it, like I missed the uses of get_tangier_ops(), et al. Intel mid was implemented in such way that we should select which soc to be used in compilation time. Depending on the selection, mfld.c or mrfl.c could not be compiled then some symbols wouldn't be available. But IMHO this is a bad legacy design that exists in there, so I started to rework it as you can see in this commit: commit 4cb9b00f42e07830310319a07e6c91413ee8153e Author: David Cohen Date: Mon Dec 16 17:37:26 2013 -0800 x86, intel-mid: Remove deprecated X86_MDFLD and X86_WANT_INTEL_MID configs I'm sending more patches soon and getting rid of intel_mid_weak_decls.h file is in my TODO list. Br, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 00/16] Volatile Ranges v10
On Mon, Jan 27, 2014 at 05:09:59PM -0800, Taras Glek wrote: > > > John Stultz wrote: > >On 01/27/2014 04:12 PM, Minchan Kim wrote: > >>On Mon, Jan 27, 2014 at 05:23:17PM -0500, KOSAKI Motohiro wrote: > >>>- Your number only claimed the effectiveness anon vrange, but not file > >>>vrange. > >>Yes. It's really problem as I said. > >> From the beginning, John Stultz wanted to promote vrange-file to replace > >>android's ashmem and when I heard usecase of vrange-file, it does make sense > >>to me so that's why I'd like to unify them in a same interface. > >> > >>But the problem is lack of interesting from others and lack of time to > >>test/evaluate it. I'm not an expert of userspace so actually I need a bit > >>help from them who require the feature but at a moment, > >>but I don't know who really want or/and help it. > >> > >>Even, Android folks didn't have any interest on vrange-file. > > > >Just as a correction here. I really don't think this is the case, as > >Android's use definitely relies on file based volatility. It might be > >more fair to say there hasn't been very much discussion from Android > >developers on the particulars of the file volatility semantics (out > >possibly not having any particular objections, or more-likely, being a > >bit too busy to follow the all various theoretical tangents we've > >discussed). > > > >But I'd not want anyone to get the impression that anonymous-only > >volatility would be sufficient for Android's needs. > Mozilla is starting to use android's ashmem for discardable memory > within a single process: > https://bugzilla.mozilla.org/show_bug.cgi?id=748598 . > > Volatile ranges do help with that specific(uncommon?) use of ashmem. Thanks for the info. I'd like to ask a question. Do you prefer fvrange(fd, offset, len) or fadvise(fd, offset, len, advise) inteface rather than current vrange syscall interface for vrange-file? Because I think it would remove unnecessary mmap/munmap syscall for vrange interface as well as out of address space in 32bit machine. > > For Mozilla sharing memory across processes via ashmem is not a > nearterm project. It's something that is likely to require > significant rework. Process-local discardable memory can be > retrofited in a more straight-forward fashion. > > Taras -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ACPI: reduce log level for message "ACPI: \_PR_.CPU4: failed to get CPU APIC ID"
On 2014/1/28 8:28, Rafael J. Wysocki wrote:
> On 1/28/2014 1:18 AM, David Rientjes wrote:
>> On Mon, 27 Jan 2014, Jiang Liu wrote:
>>
>>> diff --git a/drivers/acpi/acpi_processor.c
>>> b/drivers/acpi/acpi_processor.c
>>> index c9311be..c29c2c3 100644
>>> --- a/drivers/acpi/acpi_processor.c
>>> +++ b/drivers/acpi/acpi_processor.c
>>> @@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct
>>> acpi_device *device)
>>> apic_id = acpi_get_apicid(pr->handle, device_declaration,
>>> pr->acpi_id);
>>> if (apic_id < 0) {
>>> -acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n");
>>> +acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n");
>>> return -ENODEV;
>>> }
>> Don't we already leave some artifact in the kernel log at boot about apic
>> ids that don't get registered? I'm wondering if we should have this
>> warning at all.
>
> It is useful for knowing that there are potentially broken objects in
> the ACPI tables.
And it's very useful to identify BIOS bug in case of CPU hot-addition.
It caused our test team about 1 week to identify BIOS bug in CPU
hot-addition, so I added this debug message.
Thanks!
Gerry
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] de-asmify the x86-64 system call slowpath
On Mon, Jan 27, 2014 at 06:39:31PM +0100, Oleg Nesterov wrote: > On 01/27, Al Viro wrote: > > > > BTW, there's an additional pile of obfuscation: > > /* work to do on interrupt/exception return */ > > #define _TIF_WORK_MASK \ > > (0x & \ > > ~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT| \ > >_TIF_SINGLESTEP|_TIF_SECCOMP|_TIF_SYSCALL_EMU)) > > > > /* work to do on any return to user space */ > > #define _TIF_ALLWORK_MASK \ > > ((0x & ~_TIF_SECCOMP) | _TIF_SYSCALL_TRACEPOINT | \ > > _TIF_NOHZ) > > Heh, yes ;) > > > Why is _TIF_UPROBE *not* a part > > of _TIF_DO_NOTIFY_MASK, for example? > > Yes, please see another email. That is why uprobe_deny_signal() > sets TIF_NOTIFY_RESUME along with TIF_UPROBE. *grumble* Can it end up modifying *regs? From very cursory reading of kernel/events/uprobe.c it seems to do so, so we probably want to leave via iretq if that has hit, right? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 15/21] pinctrl: mvebu: dove: request additional resources
Dove pinctrl also requires additional registers to control all pins.
This patch requests resources for mpp4 and pmu-mpp register ranges.
As this changes DT to driver requirements, fallback to hardcoded
resources, if the corresponding DT regs have not been set.
Also, WARN about old DT binding usage to encourage users to update
their DTBs.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v1->v2:
- add FW_BUG to WARN message
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Linus Walleij
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pinctrl/mvebu/pinctrl-dove.c | 39 +++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 98f8cae72ace..bb7ff396ddd1 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -22,6 +22,11 @@
#include "pinctrl-mvebu.h"
+/* Internal registers can be configured at any 1 MiB aligned address */
+#define INT_REGS_MASK ~(SZ_1M - 1)
+#define MPP4_REGS_OFFS 0xd0440
+#define PMU_REGS_OFFS 0xd802c
+
#define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde0)
#define DOVE_MPP_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0200)
#define DOVE_PMU_MPP_GENERAL_CTRL (DOVE_MPP_VIRT_BASE + 0x10)
@@ -56,6 +61,8 @@
#define CONFIG_PMU BIT(4)
static void __iomem *mpp_base;
+static void __iomem *mpp4_base;
+static void __iomem *pmu_base;
static int dove_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
unsigned long *config)
@@ -802,13 +809,43 @@ static int dove_pinctrl_probe(struct platform_device
*pdev)
{
const struct of_device_id *match =
of_match_device(dove_pinctrl_of_match, &pdev->dev);
- struct resource *mpp_res;
+ struct resource *mpp_res, *res;
+ struct resource res_fallback;
mpp_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mpp_base = devm_ioremap_resource(&pdev->dev, mpp_res);
if (IS_ERR(mpp_base))
return PTR_ERR(mpp_base);
+ /* prepare fallback resource */
+ memcpy(&res_fallback, mpp_res, sizeof(struct resource));
+ res_fallback.start = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res) {
+ dev_warn(&pdev->dev, "falling back to hardcoded MPP4
resource\n");
+ adjust_resource(&res_fallback,
+ (mpp_res->start & INT_REGS_MASK) + MPP4_REGS_OFFS, 0x4);
+ res = &res_fallback;
+ }
+ mpp4_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mpp4_base))
+ return PTR_ERR(mpp4_base);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!res) {
+ dev_warn(&pdev->dev, "falling back to hardcoded PMU
resource\n");
+ adjust_resource(&res_fallback,
+ (mpp_res->start & INT_REGS_MASK) + PMU_REGS_OFFS, 0x8);
+ res = &res_fallback;
+ }
+ pmu_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pmu_base))
+ return PTR_ERR(pmu_base);
+
+ /* Warn on any missing DT resource */
+ WARN(res_fallback.start, FW_BUG "Missing pinctrl regs in DTB. Please
update your firmware.\n");
+
pdev->dev.platform_data = (void *)match->data;
/*
--
1.8.5.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/
